IRC channel logs


back to list of logs

<rekado_>gah, we really need to do something about *tex*
<rekado_>many of our packages are incomplete because 1) I didn’t know about the tlpdb and 2) the svn-fetch method isn’t really suitable for TeX live.
<rekado_>I’ma write that texlive-fetch method
<erudition>bricewge: oh, okay. well I'm not sure if it will still ask for my password, like that bug, because for me it simply stops gdm from launching altogether
<erudition>but thanks
<ArneBab>civodul: I’ll try mpv once I restarted.
<rekado_>I have an svn-multi-fetch and an svn-multi-reference; also have texlive-origin which uses the former two.
<rekado_>looks much cleaner.
<rekado_>I’ll have to use this on core-updates, though.
<civodul>rekado_: neat
<civodul>why core-updates?
<mbakke>Looks like many staging builds failed because the builders ran out of disk space.
<mbakke>civodul, rekado: It would be neat to get python-on-guile working with glibc. I used this snippet to try it:
<rvgn>Hello Guix!
<rvgn>kmicu Regarding our discussion about virt-manager, what type for network setup you use for your VM? I tried both "bridge" and "passthrough", but network connection is never present for the VM.
<noobly>anyone feel likek helping a noob configure a dual boot w/ another linux distro?
<noobly>another existing and wokring distro, that is
<zacts>noobly: you can also install guix the package manager on-top of an existing distro if you want
<zacts>like if you didn't want to install GuixSD proper
<noobly>i want the hole shebang
<zacts>ah ok
<noobly>thanks though
<noobly>just not sure how to configure the 'bootloader' function. I've got dev/sda[1,6], where they are, respectively, labeled grub, boot, swap, gentoo_rootfs, guixsd_rootfs and share
<noobly>does guixsd image ship with a pastebin utility by chance? D:
*rekado started a wip-texlive branch
<elais>Has anyone experienced problems trying to set the correct time zone in gnome?
<elais>The gui ignores my settings and I'm wondering if there was a config file that sets the timezone separately from config.scm
<rekado>elais: I’m not very familiar with this, but I wonder if that’s because a writeable settings backend is missing at runtime.
<rekado>GNOME applications will fall back to a dummy settings backend when a writable backend cannot be started via D-Bus.
<rekado>this might be an instance of this behaviour.
<rekado>to diagnose this it might be useful to see what the application prints when it is run in a terminal.
<rekado>when I try to change the time or timezone I see this in the terminal: Could not set system timezone: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.timedate1 was not provided by any .service files
<rekado>looks like we need to add a package providing org.freedesktop.timedate1 and install it in a location that is searched for .service files.
<rekado>I don’t know what that package would be, but it should probably be included in the gnome meta-package.
<elais>I'll look into don't that in the morning
<nckx>sneek: later tell noobly: Depends on whether your system is UEFI (target "/boot/efi") or not (target "/dev/sda") [this will overwrite your Gentoo GRUB and not detect other operating systems!] or (target #f) for no bootable GRUB (you can ‘configfile $guix_partition/boot/grub/grub.cfg’ from Gentoo's GRUB).
<sneek>Will do.
<nckx>sneek: later tell noobly: We don't ship with a pastebin tool but ‘guix install wgetpaste’ → ‘wgetpaste -s dpaste <$stdin’.
<nckx>sneek: Whew. All the botsnacks.
<jlicht>hey guix!
<pkill9>i hate when im bikeshedding
<OriansJ>pkill9: with yourself or with others?
<pkill9>with myself, but with others is also annoying
<OriansJ>pkill9: perhaps the solution is let others who care deal with the painting of the shed and accept that it is going to be ugly
<OriansJ>even the most beatiful marble sculptures were ugly for most of the process of creation
<pkill9>that's a good way of looking at it :)
<OriansJ>pkill9: just ignore the ugly bits until after you cleared out most of the rock in the way of creating your masterpiece ^_^
<bzp>hi all
<bzp>since I do so that to do this algorithm with functions and counterfoils with elisp
<quiliro>hola bzp
<quiliro>bzp: Ĉu vi parolas Esperanto?
<quiliro>bzp: Do you speak Spanish?
<jlicht>rekado: what are your plans for the texlive branch?
<quiliro>I think he wanted to ask was how to translate that paste from Java to Scheme.
<quiliro>I am talking about bzp which is not on the channel any more
<rekado>jlicht: I’ll follow the tlpdb and go through all texlive-* packages we have to ensure that they contain all files they should.
<rekado>jlicht: this means deprecating a bunch of partial packages and replacing them with something new.
<rekado>all of them should use texlive-origin, which uses svn-multi-fetch to fetch multiple locations from an SVN repository.
<rekado>that sort of thing
<pkill9>why does running `guix environment --container --ad-hoc coreutils` and then running "ls /" list fewer directories than afterwards running `guix container <pid> exec ls /`?
<pkill9>well, i had to replace "ls" used with `guix container` with the store path to ls
<jlicht>rekado: perhaps you could massage the output of the tlpdb parser so that you can at least do this programmatically?
<rekado>jlicht: for the existing packages it’s really human work.
<rekado>I need to figure out if something should be a package at all.
<rekado>texlive-dvips, for example, shouldn’t exist.
<rekado>it cuts across *several* packages
<rekado>of course I’d like to have an importer as well, but that’s much less important to me.
<jlicht>rekado: ah that clarifies a lot. That seems like a very boring job though...
<nellastro>hello everybody! Has anyone ever managed to extract an AppImage on GuixSD? It should unpack itself by invoking ./appimage --extract-image, but clearly the executable assumes the FHS so when I run the above command i get bash: ./appimage: no such file or directory. Any ideas? I thought to do this inside a FHS compliant container (that has /bin/sh an
<nellastro>d/or /bin/bash), but I have no clue about how to do that in GuixSD. Is this even feasable? Thanks a lot
<minall>Hello guix!
<minall>I tried to use a configuration from another pc, succesfuly reconfigured, but I forgot that it had different users, so 2 more users we're created, and the one that I already had, erased..
<minall>when I noticed, I reconfigured again but adding my missing user, and now I'm stuck with a problem that appears when I try to login to my user
<minall>Unable to cd to /home/USER
<quiliro>minall: did you search the mailing list?
<minall>Nope!, I'm on it
<quiliro>please check that and this chat log
<minall>But I'm thinking about just remove the user and add a new one
<minall>this day exactly?
<quiliro>although i have not tried searching the could be dificult to search by term
<quiliro>maybe the mailing list only
<quiliro>minall: maybe that would work by removing that user's directory
<minall>yes! that
<quiliro>minall: but it would be great to search the mailing list and report there what you did did not report your success on you last mailing list post. please will serve other users
<minall>I'll do!
<quiliro>minall: it may even serve you in the future
<quiliro>gotta go...told you i would stay only until 12
<minall>yes, sadly I couln't connect after...
<rekado>nellastro: I think that’s because the glibc loader isn’t where the appimage expects it to be.
<rekado>you may be able to just link it to /lib
<nellastro>rekado: i tried ldd appimage and i got "not a dynamic executable"
<nellastro>should i just set LIBRARY_PATH?
<rekado>LIBRARY_PATH has no effect
<rekado>and LD_LIBRARY_PATH would likely be wrong
<rekado>this fails much earlier
<rekado>what kind of file is this appimage?
<nellastro>a binary blob
<rekado>if it is an executable it should have the loader file name embedded
<nellastro>how can i get the loader name?
<rekado>is this what “file appimage” says?
<nellastro>here's the output of "file appimage"
<nellastro>"ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/, for GNU/Linux 2.6.18, stripped"
<nellastro>so i guess the problem is /lib64/
<rekado>nellastro: exactly.
<nellastro>i was looking on google
<nellastro>should i set LD_PRELOAD?
<rekado>all you need to do is make it available
<rekado>this file is provided by glibc. Link it to /lib64.
<rekado>it’s called lib/ in the glibc package output.
<nellastro>can i link the appimage in place?
<nellastro>without recompiling, i mean
<rekado>nellastro: you only need to link the glibc package’s lib/ to /lib64/
<rekado>that should satisfy the appimage and all should be just fine.
<nellastro>thank you very much, i'll try right away.
<pinusc>Hi all, first time guix user here. I'm having a bunch of issues migrating my setup from arch
<pinusc>Like, my /bin is empty, so all my scripts with #!/bin/bash don't work, because there's no /bin/bash
<pinusc>What is the idiomatic guix approach to fixing this?
<rekado>pinusc: /bin/sh will always be available on POSIX systems.
<pinusc>Yeah, /bin/sh is there
<pinusc>/bin/bash and /bin/zsh aren't though
<pinusc>So is there a way to make them "appear", perhaps as symlinks of the actual binaries? Or are my scripts doomed to fail?
<mbakke>pinusc: You can use 'special-files-service-type' to create such symlinks.
<mbakke>and 'extra-special-file' :)
<pinusc>Ooh, I see
<pinusc>Thank you
<pinusc>Okay, I have one more question
<pinusc>I installed the xinit package (trying to run bspwm), but when I try to run startx, it doesn't work
<pinusc>It tries to run a server in /gnu/store/....-xinit-.../bin/X, but there is no such file
<pinusc>Since there's literally a missing file in a directory managed by guix, is there a chance this is actually a bug in the package?
<rekado>pinusc: it might be a problem with the reference to X that “startx” retains, but we don’t start X like that anyway — instead we use a service for that.
<mbakke>IIRC a discussion about startx not working properly on Guix... You might have better luck by using a display manager.
<pinusc>Yeah, I was actually trying to use startx to debug a display manager
<pinusc>I can't seem to get bspwm to start with either GDM or SLiM, for some reason
<rekado>pinusc: could you please send details to Maybe there’s someone who can help you.
<mbakke>pinusc: Right. Did the GDM log files produce anything useful?
<pinusc>I don't think so
<pinusc>But since I've restarted there seems to be no gdm log files
<bricewge>Never contributed to Guix before, I think I have a patch that fixes, should I send it to the issue or to guix-patches?
<detran>hello, I'm trying to install guix in a qemu vm, and I've followed the manual to get it running. However, I don't understand how to launch the graphical installer. It wasn't present in the boot menu
<bricewge>jonsger: Ok, thanks!
<zacts>hello #guix
<zacts>I have an idea with guix.
<zacts>I wonder about creating a personalized side distro with guix that I can then share with others.
<zacts>like, it reminds me of some of the concepts of the HURD
<zacts>as a normal user you can start contributing translators and implement your own system services
<zacts>well to do this with guix, but you are implementing your own packages as a normal user and then sharing this with others
<zacts>it's like you could start with a default GuixSD distro and then evolve your own flavor while running it, and then share that flavour
<pkill9>i think it would technically count as a separate distro if you fork the guix source
<pkill9>otherwise to me it still falls under being a Guix System
<zacts>pkill9: well, it's more like having a Guix within GuixSD
<zacts>multiple Guix within GuixSD
<zacts>you share your individual Guix modules and packages to be used on-top of GuixSD
<zacts>so each user can install GuixSD, and then they can install their own flavour of Guix via the shared Guixpkgs
<zacts>analogous perhaps to how normal users on the Hurd can author their own translators for user services like filesystems, etc... and then share those with others running Hurd
<zacts>so yeah, it would be a way to kind of fork GuixSD without forking it. More like flavoring and customizing your own Guix packages to be used within GuixSD
<zacts>like a tree-branchlike way of viewing it. Oh and another kind of interesting idea I had is to switch between them, kind of like bedrock linux
<zacts>so you can have one flavour of GuixSD running, and then say you want to switch to another more unstable version for a particular app for a sec, then you can do that without conflicts
<zacts>bedrock (gnu)/linux
<MH026>are you describing Gentoo with overlays?
<zacts>I'm unfortunately not familiar enough with Gentoo to know
<zacts>It's like being able to weave in and out between various flavors of a distro reliably while running the distro
<zacts>and then customize your own flavour while running it
<zacts>but Guix / Nix could do this reliably with no crashes and all of that, and if it did explode you can just rollback
<zacts>and it's efficient with resources too for this kind of idea
<zacts>but like I could host my own Guix package server on git or something, with my particular flavor of Guix packages
<zacts>you could weave in-and-out of this and other shared packages.
<zacts>similar to bedrock above
<zacts>anyway, I'm kind of flooding the channel with this, so I'll just explore and read a bit of the doc first I think.
<zacts>(thinking out loud a bit), but can I as a normal user create a Guix package and then easily share that package with others to use?
<dustyweb>I could really use some urgent help for a topic which is a bit out of my league :)
<dustyweb>has anyone set up a package definition for a from-git-checkout version of linux
<dustyweb>as opposed to a release tarball
<civodul>i haven't tried
<civodul>i supposed you could do "guix build linux-libre --with-git-url=..."
<civodul>zacts: what you describe looks like "channels":
<dustyweb>civodul: I tried setting up an inherited package but
<dustyweb>I'm getting an error on building that I'm not when checking out from a tarball :(
<dustyweb>I'm not sure what step they run in the tarball that I need to add
<zacts>civodul: cool
<civodul>dustyweb: ah that i don't know :-/
<zacts>I'll check it out
<zacts>yes I think this is it!
<zacts>let me read a bit more and try it out
<civodul>great then :-)
<dustyweb>it's failing on "make oldconfig"... I'm guessing I need to do something fairly differently
<zacts>note: I still need to install gnu guix on my laptop, but I'm currently running NixOS.
<zacts>I just discovered that GuixSD supports my wifi out of the box
<zacts>which is pretty nice
<dustyweb>unfortunately my old laptop was dying and I have to build an upstream kernel to support this hardware
<dustyweb>or rather, for the laptop I emergency-bought from a retail store
<dustyweb>but it's their from-git code
<dustyweb>it requires a kernel from latest git
<dustyweb>maybe I should email help-guix
<civodul>hmm no idea
<civodul>it might be something peculiar about this version of Linux
*kmicu bets on a regression, especially in kernel Linux’s master.
<civodul>happily i never touched this package over the last few years :-)
<zacts>I have a couple of other ideas? but I don't know how viable or useful they might be.
<zacts>one idea is that guile supports more than just guile scheme for a language
<zacts>I wonder if users could author guix packages in a syntax/language other than guile scheme
<zacts>as much as I think s-expr syntax is pretty elegant, many users still prefer something more Bash-like or Ruby-like, or whatever.
<zacts>don't know, just a gist of an idea that I thought of
<zacts>may or may not be a good idea
<rekado>zacts: Guile supports more than one language. But within Guix we’ll stick with Scheme.
<dustyweb>well shot an email to help-guix
<dustyweb>guess we'll find out
<kmicu>zacts: You could use Wisp if parens hugs are not acceptable ;)
<rekado>(not directly possible yet)
<zacts>oh cool
<zacts>Wisp looks neat
<MH026>I just cant get used to anything Lisp for the life of me
<MH026>I am learning just how to do packages and that'll be the end haha
<zacts>another idea that I had for GuixSD, is a GUI interface into the package manager.
<rekado>MH026: you can generate package expressions from JSON.
<rekado>zacts: that’s on the road map.
<zacts>or a fork of GuixSD for everyday users who don't know programming languages and don't ever want to
<zacts>cool rekado
<rekado>zacts: would you like to work on the GUI?
<zacts>rekado: is it guile scheme?
<zacts>rekado: I don't have the time nor skill probably right now for that
<rekado>zacts: a fork of the Guix System without its core features wouldn’t make much sense.
<zacts>rekado: ok
<rekado>you don’t need to know Scheme to use Guix.
<MH026>I feel like every distro tries that, I cant see my dad make deb packages either. With enough momentum GuixSD will get that far
<zacts>rekado: I'm thinking of a system that could target an audience like Trisquel Gnu/Linux targetted
<rekado>I don’t see why Guix System couldn’t do that.
<rekado>paroneayea: any idea why gnu/machine/ssh.scm isn’t included in the output of “guix pull”?
*kmicu would target those folks with Trisquel plus Guix, the package manager ;)
<zacts>let me install GuixSD this evening, and I'll try it out and learn how to actually use it.
<zacts>I need to read the doc too
<zacts>rekado: I'm thinking that my contributions could likely be packages
<kmicu>sneek: what is GuixSD?
<sneek>GuixSD is deprecated. Use Guix System instead.
<rekado>hmm, looks like we should use “svn export” instead of “svn checkout” followed by deletion of the .svn directory.
<rekado>“export” won’t include the .svn directory.
<zacts>I need to actually inform myself via the doc and trying out Guix/Guix System/etc...
<zacts>so I'll do this this weekend
<zacts>this evening (2-3 hours) likely
<rekado>take your time.
<kmicu>Happy Guixing! ( ^_^)/
<zacts>thanks :-)
<paroneayea>rekado: did you see the push I made?
<paroneayea>and the email followup I made to guix-devel?
<paroneayea>I pushed a patch from jakob
<zacts>It might get me to switch back to emacs again.
<zacts>ok, bbl
<rekado>paroneayea: I guess my reply hasn’t made it to the list yet…
<rekado>paroneayea: commit 834b8a4110758bec27753976ec0fe77cd4c32e30 doesn’t solve the problem.
<paroneayea>rekado: ah
<paroneayea>I'm not sure why
<paroneayea>rekado: I also don't have time to investigate :(
<paroneayea>I'm desparately trying to fix the laptop mess I'm in within the next few hours
<rekado>oh, good luck with that!