IRC channel logs


back to list of logs

<epronk>janneke: /gnu/store/deadbeef1234-system/boot starts with : (eval-when (expand load eval)
<sneek>epronk, you have 1 message.
<sneek>epronk, janneke says: re: dumb-init(1), is your dumb-init instead of doing exec invoking guile+shepherd?
<epronk>sneek: My Ubuntu kernel in lxd can't run /gnu/store/deadbeef1234-system/boot directly so I try to wrap it with a bash script.
***Piece_Maker is now known as Acou_Bass
<janneke>Morning Guix!
<janneke>epronk: ah, you need to wrap.
<janneke>the pstree output suggests that your dumb-init wrapper remains to be the parent (1) and invokes shepherd instead of exec'ing it?
<reepca>Well, radeon r5 230 should arrive next week, according to h-node that should work for the multiple displays. In the meantime, do we have any variables along the lines of NIX_STORE_DIR in the scheme code?
<efraim>reepca: there is in the configure script and 'guix import nix', but I've never looked at that part
<rekado>Hi Guix
<rekado>buenouanq: I really don’t like wikis for things like this. It’s all in the manual. If the manual is not explicit enough we should change the manual.
<rekado>buenouanq: our workflow for packaging is to send email to guix-patches followed by patches.
<rekado>buenouanq: a wiki will not be useful for that.
<rekado>we also don’t have a github-like workflow but an email-based workflow.
<buenouanq>I think there was maybe a misunderstanding in whatever I said.
<rekado>so instead of pull requests you send email to That mailing list is backed by debbugs, so we also don’t need Github issues.
<rekado>sneek: later tell jsierles Code review happens on guix-patches, but since it uses debbugs you don’t have to browse the mailing list manually to access past discussions. You can use the debbugs interface, which is/looks like/behaves like a regular bug tracker (except that you don’t need an account).
<sneek>Got it.
<buenouanq>a common question people come here and ask is `is anyone packaging/working on/thinking about X?'
<buenouanq>I was just thinking aloud about how answers to this might be found.
<rekado>all of this depends on how and if it’s going to be used.
<buenouanq>Mailing lists could work, but more would have to use it for this.
<rekado>a lot of people do use guix-patches
<buenouanq>maybe it's just me who needs to then
<rekado>buenouanq: but you are right that usually people do not announce well in advance what they are working on.
<rekado>but I suppose that’s because packaging usually doesn’t take a lot of time.
<rekado>(except for things like splitting up texlive, etc)
<buenouanq>if they did or there was a place made to cultivate and record that, they might find more help is available
<rekado>I’ve also asked on guix-devel whether anyone would like to take care of haskell updates.
<rekado>for very large projects like that announcing makes sense, but in the past this was rather ad-hoc.
<brendyn>If i want to start packaging something, I'm not going to bother writing down the fact that I'm doing so, apart from maybe mentioning it irc
<rekado>reepca My GPU is just the built-in VGA chip on my X200S laptop.
<rekado>reepca multiple displays do work fine for me, though I’m not using them regularly.
<rekado>sneek: later tell quiliro Re mirror: Have my previous hints about how to set it up not been helpful? Is there something specific you need help with?
<sneek>Got it.
<rekado>sneek: later tell quiliro Re python/Qt: You have to make sure that you’re using Python from Guix and that the PYTHONPATH variable only lists module paths from Guix.
<sneek>Will do.
<brendyn>are there any instructions on how to setup ssh for guix copy?
<efraim>I couldn't get it to work on my aarch64 boards so I have them both acting as substitutes for each other
<cbaines>mbakke, just seen your message about . I don't have anything to do with that, apart from ordering a couple of t-shirts for myself, it's all sirgazil as far as I'm aware.
<reepca>it looks like what I'm looking for is %store-directory, is that right?
<reepca>Now if I could just find something like that for the name of the directory I currently know as "db", that'd be great.
<cbaines>reepca, what is in this "db" directory? Do you have an absolute path I can look at on my machine?
<reepca>in the C++ code I believe it's called nixDBPath
<reepca>it's got the sqlite database with information about what's in the store and what references what
<cbaines>I haven't encoutered that yet, hopefully someone else has
<rekado>reepca: I think you can override the directory with NIX_DB_DIR
<rekado>see nix/libstore/
<ng0>"ERROR: Could not read ISO9669 primary volume descriptor from "/dev/sda1" … hur oO this system sat happily running for some time and the update reported no errors
<ng0>Okay, this is expected as the nginx config contained a try on running a buildserver which I did put on halt for now
<ng0>no, that's not the issue.
<epronk>janneke: Does kernel run guile script /gnu/store/abcd123-system/boot directly?
<janneke>epronk: hi! Err, dunno! Let's google that?
<janneke>epronk: btw, is there a reason you dislike dummy-init (1) in pstree, besides the fact that it looks silly? (i guess there is...)
<epronk>Using the dumb-init could work, but it just starts shepherd, but not the child processes I see in qemu.
<epronk>janneke: /gnu/store/abcd123-system/boot does a bit more then just execl shepherd.
<janneke>epronk: shepherd is not started in the right way/does not find its config?
<janneke>epronk: ehh, some env mangling?
<janneke>(i thought that was it) does it do even more?
<janneke>ACTION needs to to afk for a bit bbl
<epronk>janneke: Yes, I think the env that's get passed is not identical. lxd just lacks any logging so starting is hit or mis. No logging, no console.
<epronk>janneke: so I tried: /gnu/store/abcd124-guile-2.0.14/bin/guile /gnu/store/abcd123-system/boot
<epronk>When I boot the guixsd-usb-install in qemu the console looks fine until it switches font. From the point on the console has redraw issues.
<thomasd>On GuixSD, I seem to have broken my guix installation... I get a ton of warnings about “loading compiled file ${HOME}/.config/guix/latest/... failed”, and guix pull fails with “error: libtiff-CVE-2017-7593.patch: patch not found”. What's a strategy to fix this?
<janneke>epronk: this one?
<janneke>let me have a look
<epronk>janneke: yes. The point where it starts fbcon it all goes snowy. I'll try nofb as param in grub
<janneke>ACTION is not quick enough with F12
<epronk>janneke has fast hardware
<janneke>Hmm, does qemu say: press `ESC' for boot menu?
<janneke>yeah, it's ESC with my qemu, not F12
<janneke>epronk: story of my life ;-)
<epronk>weird. F12 works for me
<janneke>booting now, when is fbcon?
<epronk>janneke: frame buffer console?
<janneke>i'm at: root@gnu ~# .. no problems
<janneke>epronk: yeah, i know what--but it all scrolls so fast...or do you enter fbcon manually?
<catonano>thomasd: t happened to me too, recently
<epronk>janneke: no, was just trying to read during bootup what the last thing is I can read read before the screen goes bzr.
<catonano>thomasd: point .config/guix/latest to a fresh checked out (and freshhely buiilt) branch
<catonano>orr even don't poiint it
<catonano>then ./pre-inst-env guix pull
<thomasd>catonano: yes, I'm doing that right now
<catonano>tis will run guiix pull from within the checked out branch, thhat's supposed to be sane
<thomasd>initially I panicked a little, because not even the checked out branch would run (due to my having run guix gc beofre :) )
<catonano>I panicked too
<catonano>but it's actually easy
<thomasd>luckily, I could adapt the #!/.../guile shebang in scripts/guix to point to a guile version that was still installed
<janneke>epronk: scrolled back, i don't see a reference to `fbcon' weird
<janneke>when is that in the boot process, any pointers?
<thomasd>though I wonder how I ended up with the broken guix in the first place, and if it could've been fixed without a working checkout...
<rekado>thomasd I wonder too.
<rekado>if we switch to using a profile instead of a single “latest” link it should be very easy to recover.
<thomasd>I still have it in the store, willing to do forensics :)
<janneke>epronk: i'm using qemu-2.9.0 -- do you use -enable-kvm and do you have rw permissions for /dev/kvm ?
<thomasd>could it be related to the fact that I have guile-2.2 in my profile, but the old guix was still on guile-2.0? I get errors like “not an ELF file” or “Invalid or incomplete multibyte or wide character”
<catonano>ah ! Not an elf file ! I got that too !
<catonano>I even opened a tread on the mailing list
<catonano>thomasd: here
<epronk>janneke: just after ssh-daemon has been started. waiting for udevd...
<thomasd>catonano: yes, that looks like exactly the situation i'm in
<thomasd>strange. but the problem should disappear once we've completely switched to guile-2.2
<epronk>janneke: FDC, cirrusfb and then *zap*
<epronk>janneke: I filmed it with my phone. I learned that from testers.
<janneke>epronk: way cool hack!
<janneke>ACTION was /does/ epronk catch that?
<janneke>epronk: here's what i'm doing: qemu-system-x86_64 -net user,hostfwd=tcp::2233-:22 -net nic,model=virtio -enable-kvm -m 1G -boot menu=on -drive file=guixsd.img -drive file=guixsd-usb-install-0.13.0.x86_64-linux
<epronk>janneke: aha! qemu -vga std
<catonano>thomasd: it disappeared for me
<epronk>janneke: the default is that cirrusfb
<catonano>now I'm gonna listen to the Sussman's talk about generic operations :-)
<janneke>epronk: guess that became the default in 2.2?
<janneke>what version of qemu are you using?
<epronk>janneke: 2.0.0; Ubuntu 14.04.5 LTS (sorry)
<janneke>epronk: no need to `sorry' -- it would be good to add a note to the documentation about -vga std and qemu < 2.2
<janneke>or at least send a mail to for others to find
<epronk>janneke: I'll post that there.
<jlicht>hello guix
<thomasd>catonano: have fun :)
<brendyn>Anyone thought of building a Guix version of Replicant?
<Sleep_Walker>is Replicant using bionic or libc?
<Sleep_Walker>glibc I mean
<janneke>epronk: thanks!
<brendyn>Don't know, I'd have to look it up
<Sleep_Walker>it seems to be bionic
<brendyn>What significance does this have?
<ng0>though i don't know bionic, so I'll be silent
<brendyn>I see. Sounds like real hard work
<Sleep_Walker>1] Replicant is using another libc - bionic which we don't have
<brendyn>I wonder though, how would we organise something like Replicant in the Guix git repo?
<Sleep_Walker>2] if you'd want some phone with vendor binaries, you need some glue via libhybris - not something one would like to do with FSF endorsed distro
<brendyn>Would we just chuck all the android packages together in gnu/packages/?
<Sleep_Walker>or you could use some open HW solution
<Sleep_Walker>all in all - it's huge amount of work and not a bit related to Guix for long time
<Sleep_Walker>package management for such android could be doable in the end :)
<brendyn>I just find it interesting to think about how it would be done in theory
<ng0>think about theory long enough and you end up doing it because no one is doing it :)
<brendyn>I also wonder, how will we organise different GuixSD spins, like Scientific Guix? Currently we just have a couple example configs
<ng0>in their own projects
<ng0>the amount of developers in Guix can't handle ALL of it. eventually you will have projects which track and work together with GuixSD (like I do, though nothing of downloadable nature is there yet) or fork GuixSD for some reason.. the repetive circle of operating systems
<rekado>brendyn: Scientific Guix is called just Guix :)
<brendyn>ok Unscientific Guix.
<Sleep_Walker>brendyn: I'd like to see Android interface on top of Linux ecosystem as well
<ng0>if you're good, it can be done with just upstreaming everything, keeping changes in a GUIX_PACKAGE_PATH repo and write config.scm's for systems and altering what generates disk-image… and some more.
<rekado>Sleep_Walker: do you mean Android on GNU?
<brendyn>I think it would be fun to use guix tools to launch qemu vms of android
<rekado>glibc is not Linux, it’s the GNUest of them all :)
<jsierles>if i want to trigger guix builds remotely, can I call the daemon directly via rpc or should i wrap the command line client?
<sneek>Welcome back jsierles, you have 1 message.
<sneek>jsierles, rekado says: Code review happens on guix-patches, but since it uses debbugs you don’t have to browse the mailing list manually to access past discussions. You can use the debbugs interface, which is/looks like/behaves like a regular bug tracker (except that you don’t need an account).
<jsierles>ideally I could just point 'guix', running in a docker container, to a remote daemon.
<rekado>jsierles: an intermediate step is to use Guix as a library
<rekado>jsierles: remote daemons work already. You can use SSH to connect to a remote daemon.
<jsierles>rekado: how does that work?
<rekado>before that feature was implemented by Ludo we would use socat to forward the domain socket over TCP
<rekado>let me check the manual
<jsierles>didn't see anything in the manual about that.
<jsierles>ah, nevermind, i see it now
<rekado>the index item “SSH access to build daemons” explains it
<jsierles>ok. can i specify an ssh key location for the client?
<rekado>jsierles: with .ssh/config probably
<jsierles>ok, will try that
<rekado>I think for Guix we will
<rekado>…deviate from the Texlive directory layout
<jsierles>guess there isn't much difference between that and running the 'guix' command line over ssh
<rekado>jsierles: there is!
<jsierles>whats the diff?
<rekado>jsierles: if you run guix locally you can use local modules
<rekado>it just connects to the daemon remotely
<rekado>if you run guix itself over ssh, you can only use modules that are available on the remote
<jsierles>hmm. then could i share the store read-only to clients?
<jsierles>so /gnu/store would be the same for all clients, and GUIX_PACKAGE_PATH could be different.
<rekado>that’s right
<jsierles>but all builds would happen on the remote daemon
<rekado>(or wherever the daemon offloads work to)
<jsierles>nice one. so could I build a docker image using guix to provide the guix tool?
<rekado>uhm… I guess you could.
<rekado>we have a “guix” package.
<jsierles>alright. just wondering if that's better than using something line alpine.
<jsierles>the goal there is just to have a minimal container to run that can trigger a build from anywhere in our cluster (docker based)
<rekado>alpine doesn’t make much sense
<rekado>because no Guix software will use the libc from alpine
<rekado>or any other library for that matter.
<jsierles>yeah. i just found an old image on alpine
<rekado>so you’re just carrying binary cruft
<jsierles>which is actually for running the daemo
<jsierles>ideally i can use guix to build two docker images. one for running the daemon and another for the client.
<jsierles>i know it might be better to run GuixSD. but that seems like it would be some work to do on google compute engine.
<jsierles>now we run coreos which uses docker to run everything.
<rekado>jsierles: I think you just need to use “guix pack -f docker guix” and it will give you the image for the daemon and the client.
<jsierles>rekado: yep that seems to work nicely
<jsierles>has anyone installed guixsd on GCE or aws?
<rekado>I have not, but I read of attempts to run GuixSD on some virtual server hosters.
<civodul>rekado: though "-f docker" doesn't support --localstatedir, i think
<civodul>so it produces an "inert" image
<jsierles>whats that?
<jsierles>i see in the manual
<jsierles>shouldn't it be OK to mount those directories from the host?
<jsierles>i wouldn't keep such state inside the container.
<civodul>jsierles: IOW, it would give you a Guix that you cannot really use to install software
<jsierles>civodul: i see. no way to generate the local state database after packing the software? for example when it runs for the first time.
<Sleep_Walker>rekado: yes, Android packaged as GUI, with linux distro bellow, Android apps support, etc.
<rekado>Sleep_Walker: I find the term “linux distro” really hard to accept :)
<civodul>jsierles: we should just fix 'guix pack -f docker --localstatedir' :-)
<jsierles>civodul: i see. maybe i don't understand. do all clients need their own local state dir, or just the daemon?
<rekado>Sleep_Walker: for some time now I’ve shifted to just calling the system “GNU”.
<Sleep_Walker>rekado: sorry, I mean any free OS, regardless kernel
<rekado>Sleep_Walker: isn’t that what an Android emulator would do?
<jsierles>and if i were to share a store across servers, would i also be sharing local state dir?
<rekado>jsierles: here at the institute we have a cluster with hundreds of nodes. All of them mount the same store over NFS (read-only).
<civodul>jsierles: sorry i didn't follow the beginning of the discussion, so i wouldn't want to say stupid things
<Sleep_Walker>rekado: I don't know. Can you make a call with Android emulator?
<rekado>jsierles: the localstatedir is for the daemon to store, well, local state.
<jsierles>rekado: right. so just /gnu/store is mounted. /var is only important for the daemon.
<rekado>Sleep_Walker: I don’t know anything about Android. I think that wouldn’t work.
<rekado>jsierles: a part of /var/guix is also needed by the client
<rekado>jsierles: that’s where profile links are stored
<rekado>jsierles: so in our setup here I export /var/guix/profiles as a writeable share.
<jsierles>rekado: I see. so your clients mount /gnu/store read-only, and /var/guix/profiles as writeable.
<rekado>jsierles: without write access you can still use “guix build” and “guix environment”, but you cannot use “guix package”
<rekado>in your case you might not need it if all you do is run “guix pack”
<jsierles>rekado: might not need which?
<jsierles>ah, the writeable database. i would still need /gnu/store and any other local modules mounted read-only.
<rekado>jsierles: your clients might not need write access to /var/guix/profiles
<jsierles>so for now, I can use alpine to run the daemon.
<rekado>the database should not be writeable except for the daemo
<jsierles>as seen here
<jsierles>this will move the local state dir into /var at build time. so this image will include that dir
<jsierles>so maybe I can initialize /var/guix once on my server. then mount the 'inert' image but with /var/guix mounted into it.
<civodul>jsierles: the problem is that you'd be mounting the "wrong" database
<civodul>that is, /var/guix/db/db.sqlite would not correspond to the actual /gnu/store
<jsierles>civodul: if they are both initialized at the same time, why would it be an issue?
<jsierles>for example, if i copy the distribution var/guix to a mounted volume, and then run 'guix pull'.
<civodul>jsierles: if you're sure that they match, that's fine
<jsierles>civodul: guess i'm not clear on how they match
<jsierles>it looks like the database is distributed with the store. then, you use 'guix pull' to update the store. that also updates the database. i'd guess if i lose the database, it's bad
<rekado>jsierles: whenever the store is modified (by the daemon) the database gets an update.
<rekado>jsierles: you should not modify the store manually, nor should the database be changed.
<rekado>it’s important that the two stay in sync
<jsierles>ok. but guix comes with a pre-populated database right?
<jsierles>what happens to it when you 'guix pull'?
<rekado>interesting comment in the LaTeX docs under the section “Build Hints”: “The most important advice I can give: ‘Forget it’!”
<epronk>janneke: trying a different approach, mounting the usb-install image via loopback and add Ubuntu kernel, so I can try booting in qemu.
<rekado>jsierles: what the database initially contains (if anything) depends on how you install Guix.
<rekado>jsierles: one installation method is to unpack a pre-populated store; that contains a matching db.
<ng0>rekado: such encouragment \\o/
<ng0>Texinfo - Abandon hope all ye who enter here
<ng0>eh.. LaTeX
<jsierles>rekado: i see. makes sense.
<jsierles>are there security concerns allowing users to issue remote builds? in other words, could they do anything destructive with a read-only store? or just clog up the build server (for example)
<janneke>epronk: nice!
<rekado>jsierles: I think the only thing they can do is denial of service by flooding the daemon with requests.
<janneke>the -vga std thingy does not work?
<janneke>ACTION checks down-under time
<jsierles>rekado: since the result of 'guix pack' is written to the store, it should be available on the client then. and the client could do something with it, like push a docker image to a registry
<epronk>janneke: vga -std does work. I'm just lazy and don't want to do an install. I want to replace libre kernel with ubuntu kernel and see how it breaks.
<janneke>epronk: yeah, install sux0rz
<janneke>*is a lot of trouble esp. if it can be avoided
<epronk>janneke: install in qemu needs qemu bridge network because installer wants to download additional stuff.
<rekado>epronk: if all you want is replace the kernel package why don’t you use Guix for that?
<janneke>epronk: you don't need bridge, i don't think so
<janneke>the qemu curses as shown in the manual should suffice [note: ping won't work]
<epronk>janneke: I'll have another try to get that working.
<ng0>git-predicate is strange. when I add this to the guix-env.scm I have in gnunet it just sits there doing nothing at all.
<janneke>ACTION goes afk for a bit
<ng0> #:select? (git-predicate %source-dir))) where %source-dir has been defined before
<mbakke>re: android: IIRC android (bionic?) does not support RUNPATH, so Guix on phones (let's make this happen!) would have to run "below" android :-)
<mbakke>I wonder why locales are not set up for my user on this newly-provisioned machine
<mbakke>as a side note, qemu and tmux behaves very strangely when no LANG or LC_ is set
<rekado>ha, I just built texlive-latex-base
<rekado>next step is to test it by building a simple texlive package that depends on latex
<mbakke>rekado: that was fast! \\o/
<rekado>this really works! I just built the amsmath package with latex-base.
<rekado>time to write a texlive-build-system to keep the definitions simple.
<bavier`>rekado: cool!
<janneke>rekado: great!
<civodul>rekado: thoughts on ?
<Apteryx>Is it me or emacs-guix doesn't know about packages defined in GUIX_PACKAGE_PATH?
<Apteryx>rekado: Thanks for the texlive effort! It'll be a huge improvement over the 4 GiB archive download ;)
<civodul>Apteryx: i think it's you :-)
<CharlieBrown>I followed the instructions to import a nix package. I got this result:
<Apteryx>I have a 'emacs.scm' package under ~/src/my-guix-packages which defines "emacs-matrix-client", the GUIX_PACKAGE_PATH is set to ~/src/my-guix-packages; yet when doing M-x guix b "emacs-matrix-client" it doesn't know about it.
<Apteryx>civodul: I hope so :)
<Apteryx>Maybe the system emacs.scm is shadowing the GUIX_PACKAGE_PATH completely... although this behaviour would be different than when using Guix UI.
<Apteryx>("guix build emacs-matrix-client" works just fine from the cli)
<civodul>CharlieBrown: you need to make sure 'nix-instantiate' is in $PATH
<civodul>Apteryx: maybe GUIX_PACKAGE_PATH is not defined in the environment of emacs itself?
<Apteryx>civodul: I tried M-x getenv and it GUIX_PACKAGE_PATH points to the right location... hmm. I'll restart emacs to make sure.
<civodul>yeah dunno, it works for me™
<Apteryx>civodul: OK, after renaming my module to my-emacs.scm *and* restarting Emacs, it works.
<Apteryx>civodul: Do you sometimes use same module names (such as emacs.scm) to hold extra emacs packages?
<civodul>the name in 'define-module' and the file name must match
<civodul>emacs.scm is the file name, not the module name :-)
<civodul>but for my own modules i use a different name space
<civodul>not (gnu packages ...)
<Apteryx>OK. So my module name was simply (emacs) then.
<Apteryx>And now I've made it (my-emacs)
<civodul>ok, not sure why it would matter
<Apteryx>civodul: Hmm. I've renamed to 'emacs.scm' and (define-module (emacs) ...), restarted Emacs, and guix-emacs still finds it. Not how I got to my original problem in the first place. Sorry for the noise :)
<Apteryx>Looks like "restarting Emacs" was the cure.
<civodul>ok :-)
<CharlieBrown>civodul, I can't find nix-instantiate.
<lfam>CharlieBrown: It's from Nix. Is Nix installed?
<CharlieBrown>Why would nix be installed?
<lfam>Well, you are trying to use a Nix program (nix-instantiate). So, it's a reasonable question
<CharlieBrown>No, I don't. But if I had Nix installed, I would give up on packaging this, because I don't care how the program runs. I just want it installed.
<CharlieBrown>Installing Nix...
<lfam>In many cases, the Nix importer will not offer a finished Guix package anyways. It can only do the basics.
<Apteryx>civodul: Oh, looks like if the definition of a package is new (fresh written), guix-emacs won't find it. That's when I must restart Emacs.
<civodul>CharlieBrown: if you don't have Nix installed, then "guix import nix" is probably not what you want, is it?
<civodul>it might be just as productive to do the packaging work directly
<Apteryx>Or maybe I had to compile it before... I had the "no code for module (emacs)" error before I did C-c C-k to build the module with Geiser.
<CharlieBrown>Also, it's ugly that I have to write inputs twice as both a string and a quoted atom, when in Nix you just type it once.
<Apteryx>guix downlod "git-url" always give me a different hash than when I build the package :/
<thomassgn>hey, anyone running vagrant or docker?
<lfam>civodul, mbakke: What's the status of core-updates? Is it frozen?
<civodul>lfam: kinda, although i just pushed changes :-)
<lfam>Heh, okay
<civodul>i think i'm waiting for staging to be merged
<civodul>which maybe we should do now?
<civodul>yesterday i started an eval of core-updates but it was canceled
<lfam>I sat out this staging cycle, so I don't know :)
<civodul>same for me :-)
<civodul>mbakke said it's pretty much ready though
<lfam>Right, there were some scattered failures IIRC
<civodul>maybe we should all pick one
<lfam>I asked about core-updates because I'm wondering if we can switch to the Artifex Ghostscript in this cycle or wait for the next cycle
<civodul>lfam: in this cycle, definitely
<civodul>because it's a safe change and we haven't built anything this far
<lfam>Well, we'd be going from Ghostscript 9.14.0 to 9.21.0, so it might not be "safe"
<lfam>Although I wonder how many features of Ghostscript are actually used by the main users, groff, curl, and cairo
<civodul>"reasonably safe"
<civodul>i think it's just about processing good old PostScript
<civodul>and the PS standard is almost immutable nowadays, i think
<lfam>Okay, you convinced me :) I'll prepare patches to switch over completely
<civodul>awesome :-)
<civodul>you actually posted some already no?
<lfam>They were an intermediate that added a new package artifex-ghostscript. I built groff, curl, and cairo against this new package.
<civodul>ah ok
<civodul>well i guess we can switch directly
<civodul>and probably call it "ghostscript"
<lfam>Right, that was my goal
<civodul>it would have been ideal to get an official statement from Didier Link
<civodul>at the GNU level we should probably officially give up on GNU Ghostscript
<civodul>but of course discussing this may be tedious :-)
<azazel>gnu ghostscript has been around for ages...
<lfam>I started this work after reviewing the discussion with Didier from late 2016. He said he would merge the security patches that Mark ported, but that didn't happen.
<civodul>yeah i know
<civodul>so in practice it's pretty much abandoned
<lfam>That was my conclusion
<civodul>so you should definitely go ahead
<civodul>all i'm saying is that it's a bit sad that we're not able to address such issues at the GNU level
<civodul>a rant if you want ;-)
<lfam>Time to enjoy a glass of that fine wine you have nearby :)
<janneke>civodul: not able...yet
<alezost>Apteryx: you don't need to restart Emacs: just the *Guix REPL*, then after it will be restarted (when you do "M-x guix-generations" or any other command), it will read all the packages again, including the new ones you added
<alezost>I meant "just kill the *Guix REPL*"
<apteryx[m]>alezost: OK! Thanks for the tip!
<ng0>I'm updating neomutt now. I just couldn't be bothered to do it earlier.
<ng0>Or is someone else doing it already?
<ng0>side question.. I have this in my package-path repo, working: I doubt it is fit for Guix upstream because of the distribution note.
***Introoter is now known as covfefe_the_grea
<ryanwatkins>Hey guys, how do I find the .xinitrc that is created by cons'ing wm's in the guix system config?
<civodul>s/guys/people/ :-)
<civodul>ryanwatkins: there's no .xinitrc created
<civodul>only the WM provide .desktop files, and those are looked up by the login manager (SLiM)
<civodul>the .desktop files are in /run/current-system/profile/share/applications
<CharlieBrown> Can url-fetch handle zip?
<ryanwatkins>civodul: ahh, but then how could one do some-wm > some.log ?
<ryanwatkins>to pipe the output to somewhere
<bavier`>CharlieBrown: yes, you just need to make sure the "unzip" package is in native-inputs
<civodul>ryanwatkins: good question, you can't really do that
<civodul>you could watch the output on tty7 maybe
<CharlieBrown>civodul: In my local dialect, "hey people" is rude and "hey guys" is gender-neutral.
<ryanwatkins>civodul: I think it is /run/current-system/profile/share/xsessions
<civodul>oh right
<ryanwatkins>civodul: how does one observe tty7
<ryanwatkins>civodul: but tty7 appears to be my X11
<ryanwatkins>civodul: so maybe tty1?
<CharlieBrown>I give up on this package def.
<bavier`>CharlieBrown: dino looks like a nice program
<SovereignBleak>So I'm *just* getting my feet wet with Guix after building a minimum system some time ago (finally!) and in my quest for sourcing the nonfree firmware my computer needs I stumbled upon this person's config.scm that looks awfully like he wrote a bunch of Scheme that replaces the Linux-libre kernel with mainline and pulls in the Iwlwifi for Intel cards:
<SovereignBleak>Is that reality? I haven't yet learned enough Scheme to know for sure by looking at it.
<bavier`>SovereignBleak: indeed, that's what's happening
***covfefe_the_grea is now known as Introoter
<civodul>ryanwatkins: oh right, tty1
<CharlieBrown>What the... I did that one-liner to install Nix. Now, I can't do nix-env -i dino. :-(
<sneek>Welcome back bms_, you have 1 message.
<sneek>bms_, OriansJ says: that I am looking forward to his next update on Coquillage
<janneke>Hi bms_!
<bms_>Hello. Sorry about my disappearance. I haven't given up.
<bms_>How are you?
<rain1>wb :)
<janneke>i made a bit of progress towards compiling tcc.c
<gazon>hi #quix o/ -- is intended to assist with installing guixsd in a vm? if so, how is is supposed to be used? similarly to the usb image, but connected to the vm as a disk?
<janneke>and had quite some nice chats with OriansJ
<janneke>next up now is to change my lambda-based .o format into OriansJ' hex2
<lfam>gazon: It's not for installing GuixSD in a VM, but instead for running GuixSD in a VM. It's a regular GuixSD operating system image, not an installer.
<gazon>i see, so might one use it as a backing store to a copy-on-write disk?
<janneke>bms_: not sure if i had the chance to tell you...when i started my scheme interpreter in C i was thinking of it as a prototype that would have to be redone in assembly, once i got it working and small enough
<bms_>I don't think we've actually ever talked.
<thomassgn>humm, I get match errors on some package names that I think should be correct, I put a paste up of my config and the output (with errors) of my guix system reconfigure here:
<thomassgn>If I remove the package names listed it reconfigures my system as expected, but I would prefer to have at least my default terminal in there
<bavier`>thomassgn: the package variable is named "isc-bind" so as not to conflict with the 'bind' procedure in guile
<janneke>bms_: you mentioned writing a scheme interpreter in assembly?
<pmikkelsen>hello guix!
<rekado>what license are these TeX metafont fonts?
<rekado>they have this borderline non-free license statement
<rekado>saying that you may not change them unless you rename them.
<Gamayun>rekado: I vaguely recall some hubbub about those ...
<janneke>rekado: Knuth License?
<janneke>probably out of respect for DK that all the software didn't get renamed instantly ;-)
<Gamayun>LPPL / GUST as far as I can figure out..?
<Gamayun>"The reason this requirement is acceptable for LaTeX is that TeX has a facility to allow you to map file names, to specify “use file bar when file foo is requested”. With this facility, the requirement is merely annoying; without the facility, the same requirement would be a serious obstacle, and we would have to conclude it makes the program nonfree."
<slyfox>when guix unpacks tarball which timestamp does it chose to force on unpacked files? '0'?
<thomassgn>bavier`: aha. I think you just taught me a bit about guile error messages. (: Thanks