IRC channel logs


back to list of logs

<thomassgn>If I installed guixsd on a usb stick, could I easily make it work as a live USB?
<thomassgn>or what would not work?
<buenouanq>as I understand it, the installer \\emph{is} a live image
<baconicsynergy>Hello! I finally successfully installed guixsd :)
<buenouanq>concrats baconicsynergy
<buenouanq>welcome to the future
<baconicsynergy>it feels so great!!
<baconicsynergy>Gonna submit my first bug report too, attempting to install tuxguitar gave me a segfault
<baconicsynergy>Can anyone else replicate it?
***Apteryx_ is now known as Apteryx
<Apteryx>sneek: Later, tell alezost that it doesn't seem to be a pinentry issue, as I tried the following: It seems that buenouanq was right that my keys were made with GnuPG v1 and I was trying to use those with GnuPG v2. The error message is misleading.
<sneek>Apteryx, you have 1 message.
<sneek>Apteryx, alezost says: re "No pinentry" error: the problem is gpg doesn't know where pinentry is placed, so gpg-agent has be started with --pinentry-program option. One way to do it is to put "pinentry-program /home/<you>/.guix-profile/bin/pinentry" to your ~/.gnupg/gpg-agent.conf
<Apteryx>sneek: botsnack
<Apteryx>sneek: Later, told alezost that the problem was two-folded: 1) I needed to re-import my keys into gnupg v2 after exporting them from gnupg v1. 2) To get gpg v2 happy, I needed to point it to my pinentry program as you recommended. Thanks :)
<Apteryx>sneek: Later, tell alezost that the problem was two-folded: 1) I needed to re-import my keys into gnupg v2 after exporting them from gnupg v1. 2) To get gpg v2 happy, I needed to point it to my pinentry program as you recommended. Thanks :).
<Apteryx>buenouanq: You were wondering how to migrate from gnupg v1 to gnupg v2, right? I did this just now, it was a matter of exporting the key material from v1 and reimporting it from v2, as apparently the keys are not stored in the same format.
<Apteryx>Got this from:
<buenouanq>neat, thanks
<ecraven>davexunit: well, why should I not set state with the config?
<Apteryx>buenouanq: Also, you'll want to configure the pinentry-program option in ~/.gnupg/gpg-agent.conf to something like /home/youruser/.guix-profile/bin/pinentry. I believe gpg-agent should be smarter and just look for "pinentry" instead of some hardcoded path, but this does the trick for now.
<ecraven>isn't everything state on a guixsd system? why should I *not* be able to set ssh keys, create user accounts, and do whatever else?
<ecraven>I don't (necessarily) want them in the store, I want them deployed to the user's home (or in whatever other way so that they are honoured)
<ecraven>I do understand that putting files in users' homes is kind of a no-go, but I don't really see how adding the ssh key is really different from creating the user account in the first place
<ecraven>also, sorry if I didn't explain this properly, but I'm not talking about private ssh keys, but about authorized_keys, so I can actually login to the machine
<buenouanq>Apteryx: I didn't have any issues with pinentry - But I installed pinentry-gnome and am just using it with claws-mail.
<efraim>it turns out my build-slave had the wrong guile-load-path or something set from before the last merge
<efraim>also, is the staging branch also for ungrafting?
<civodul>Hello Guix!
<rekado>today I'm trying to speed up Guix on NFS by not using NFS.
<rekado>writing locally, using inotify to detect changes, then push these changes to NFS.
<rekado>I don't like how hackish this sounds but the performance is just too bad here.
<rekado>for almost every operation one of these pesky .nfsXXXXX files is created and modified which indicates that the NFS server is lagging
<rekado>inotify tells me that I might need to act on MOVED_TO, CLOSE_WRITE, and ATTRIB syscalls
<rekado>guess I can ignore all the other syscalls on the store.
<jmd>rekado: What kind of NFS are you using?
<rekado>we have a ZFS black box which exports a file system via NFS.
<rekado>in other words: the worst kind
<jmd>Yeah is it NFSv2 3 or 4 ?
<jmd>and did I understand correctly - you are NFS mounting /gnu/store ?
<rekado>it's NFSv3
<rekado>all of /gnu is on NFS, this is /gnu/store and /gnu/var (aka localstatedir)
<jmd>Presumably you're running a foreign distro, not GuixSD?
<rekado>yes, it's CentOS 6
<jmd>If there is any chance of moving to NFSv4 that would probably work better.
<jmd>Otherwise, I can only suggest tweeking the mount options.
<rekado>NFSv4 is feared by the admins here for some reason. It's very unlikely they'll switch until v3 is no longer available.
<rekado>they tried once before and broke things in the process, so they are wary of a second attempt
<rekado>I already tweaked the mount options to the extent possible.
<rekado>At this point I think I need to hack beyond NFS and take advantage of the fact that the store is append-only (ignoring GC for now)
<rekado>with inotify I can detect when the daemon is done working on a store item, so I could move /gnu to local storage and then push only the new store items to NFS
<civodul`>rekado: which Guix operations are slow on this NFS store exactly?
<civodul`>(sorry, i keep forgeting the details, my memory must be filtering out things that cause bad feelings ;-))
<rekado>civodul: I can't pinpoint just one operation.
<rekado>*everything* is slow.
<rekado>even just downloading things
<rekado>which I think is bound by disk IO
<rekado>pretty sure that's misconfiguration on the side of the NFS black box
<rekado>but being that it's a black box we can't fix it without involving Oracle
<rekado>file servers at the MC
<rekado>*at the MDC are a big pain point
<civodul>the thing is, derivation builds take place on /tmp, except the final copy operation when the derivation succeeds
<civodul>oh but yeah, RPCs that add things to the store may be slow
<civodul>and there are lots of reads are from the store, of course
<rekado>reads are very slow, too.
<rekado>grafting is terribly slow, despite all the performance improvements in guix
<rekado>it's pretty acceptable without NFS
<jmd>Silly question: What is the use case? Why do you want to NFS mount the store?
<jmd>Generally speaking, NFS is less reliable than local filesystems.
<rekado>we want to use central IT services for storage instead of exporting /gnu from our tiny virtual machine
<rekado>the file server is used everywhere, so if it goes down nobody can work anyway.
<rekado>synchronised outage :)
<rekado>but if our central Guix server goes down and with it the whole store then running jobs on the cluster will fail.
<rekado>and that's not okay
<jmd>So far as I know, it's not possible to share a store between multiple installations.
<rekado>but we do
<rekado>because actually we only have one installation
<rekado>that's our VM where the daemon runs
<rekado>it's the only node with write access to the store.
<jmd>and the statedir?
<rekado>every other cluster node treats the store like just another shared file system (read-only)
<rekado>the profile directories are writeable on all nodes
<rekado>so that people can manage their profiles
<rekado>but all access to the daemon is central
<rekado>(we use a wrapper that forwards RPCs to the daemon on the VM)
<rekado>what's good about this is that we don't need to maintain multiple independent Guix installations on countless workstations and nodes
<rekado>users manage their profiles across all machines by going through the central daemon
<rekado>so they can use the very same software on the cluster as on their workstations
<jmd>I thought that user profiles are simply simlinks to the store.
<rekado>to create a new profile generation a new store item has to be created
<rekado>and then Guix changes the target of a symlink in the profiles directory
<rekado>with this central approach users can still use their own version of Guix; we just centralise storage.
<jmd>This is an experimental branch?
<rekado>no, it's master
<rekado>all of this already works out of the box; only a little plumbing is needed
<rekado>(like providing a wrapper script for Guix)
<civodul>the days of the wrapper script are counted :-)
<rekado>looking forward to retiring it!
<rekado>civodul: in the inotify log I see that near the end of building a package there are a lot of syscalls like this:
<rekado>/gnu/store/ CREATE .tmp-link-24757-1804289383
<rekado>/gnu/store/ MOVED_FROM .tmp-link-24757-1804289383
<rekado>several pages full of .tmp-link creation and moving
<rekado>(that's before grafting)
<rekado>and right before deleting the chroot and the lock file
<rekado>don't know what that is
<civodul>did you try --disable-deduplication? :-)
<civodul>that's definitely i/o intensive
<rekado>that's on my list for today
<civodul>so if you have enough disk space, just disable it
<civodul>or disable it temporarily just to see how it affects performance
<thomassgn>derp, so guixsd doesn't currently work with gpt it seems?
<jmd>thomassgn: I have never tried, but I don't see why it shouldn't work.
<thomassgn>keep getting ext2 embedding errors from grub-install
<thomassgn>am reinstalling on mbr now...
<thomassgn>oh, jmd ^^ :)
<ng0>gpt works here
<sneek>Welcome back ng0, you have 2 messages.
<sneek>ng0, galex-713 says: yeah solved the gnupg-2.1.15 install problem long time ago
<sneek>ng0, galex-713 says: then I tried to see how could I use the same keypair for both gpg and ssh (and tls) and failed (to understand and find the correct informations about gpg-agent and stuff like key formats-keygrip)… so I’ll try another time
<ng0>kay.. whatever the context was.
<ng0>sneek you are slow
<ng0>all the 0ad dependencies are merged. I can give packaging it another try, leaving out nvidia-texture-tools and using the bundled one it needs anyway because of applied bundled patches.
<thomassgn>ng0: oh, huh. since I allready restarted to build the config I'll leave it as is for now. Might look into it if needed later on though- do you have anything gpt related in your configs?
<ng0>the system should really not care at that low level
<ng0>i have grub_boot, /boot , / , /home as partitions
<iyzsong>when using GPT, grub need a special BIOS boot parition.
<thomassgn>ok, I was struggling finding a way of setting the device for grub-configuration. It's a system with several disks. I thought I had a grub boot partition, but maybe I didn't configure it properly
<iyzsong>there is no configure for that in guix, I think grub will pick the BIOS boot partition automaticlly if you have one.
<thomassgn>wtf, now I get the same error on an mbr setup...
<thomassgn>I'll get ssh running and paste the config soon
<thomassgn>I removed some things, but still get the same error (output with error at bottom):
<iyzsong>thomassgn: the '(device ..)' in grub-configuration usually need to be a disk device like "/dev/sda", not a partition.
<thomassgn>ofcourse. derp. For some reason I've had a comment from the generated grub.cfg in the back of my mind telling me it should be a fs... :P
***GrimKrie- is now known as GrimKriegor
<paroneayea>had the not fun experience this morning of trying to do a webrtc call through either epiphany or icecat on guixsd
<paroneayea>didn't really have luck
<paroneayea>my microphone didn't show up in icecat :)
<paroneayea>it seems to show up in pavucontrol...
<paroneayea>it would be nice to test some VoiP type stuff in GuixSD and do a community #guix call in it to verify that we get far enough
<ng0>webrtc requires features which are not present in icecat
<ng0>i think
<ng0>tox (the software) is not really good for videocalls
<ng0>ring, no idea
<paroneayea>well we clearly want ring :)
<ng0>we don't have mumble so far
<paroneayea>it would be nice to have Mumble yes
<paroneayea>I was just typing htat ;)
<ng0>i'm worried about etheureum servers for signups for ring
<ng0>blockchain is horrible and olgarchic
<ng0>but for the moment it could be better than skype
<ng0>where I have my 2nd "you are sending spam" verification in 4 weeks now
<paroneayea>a lot of things are called "blockchain" these days which aren't very similar to bitcoin, but yes
<paroneayea>I didn't know ethereum was required for ring though
<ng0>ethereum is similar to bitcoin
<ng0>no, they have plans for this
<ng0>bitmessage uses blockchain but scales (so far) okay'ish
<civodul>taylan: did you eventually solve that FileChooser schema issue with Conkeror?
<civodul>i'm experiencing it now so i sympathize a lot more ;-)
<ng0>icecat doesn't allow editing of search engine keywords.. :/
<rekado>what does that mean?
<ng0>about:preferences#search you can edit the urls and properties in normal firefox
<ng0>so when I add and change the url to an .onion it works, but in icecat i don't even get to the edit dialogue
<ng0>should be in about:config
<ng0>but in about:preferences it is normally
<ng0>no, it's not in about:config
<rekado>there's keyword.URL in about:config --- doesn't that do what you want?
<taylan>civodul: for now I've installed the gtk+ package into my profile manually, then set XDG_DATA_DIRS=~/.guix-profile/share:/usr/share:/usr/local/share
<taylan>civodul: maybe gtk+ should be propagated by icecat...
<ng0>in firefox, you can add through me about page of it, and then edit it to use another url
<ng0>this is not possible in icecat, for whatever obscure reason
<ng0>what i mean is, you can edit the property of an added 'one-click search engine'
<civodul>taylan: i'm looking into it, but it seems it's really a matter of using glib-or-gtk-build-system
<civodul>which would mean that icecat has the same problem since the switch to GTK+3
<taylan>civodul: FYI I also had another issue with icecat 45-gnu1-beta: it crashes after a while when (I think) I leave Twitter open. maybe a memory leak. I'm back to 38 for now...
<ng0>maybe there's some lines in the icecat code we need to remove to get the functionality to edit search engines back
<civodul>yeah, 45 is known to be crashy, but that's a different story...
<taylan>civodul: I don't use the guix conkeror package by the way, I just run "icecat -app ~/src/conkeror/application.ini" where ~/src/conkeror is a git checkout of conkeror
<ng0>paroneayea: from news of ring beta 2: A global account identification mechanism based on blockchain implementation on an Ethereum technology.
<civodul>taylan: ok
<paroneayea>ng0: hm, too bad... I thought the fingerprints as id system was brilliant
<rekado>ng0: does this work in firefox at the same version as the one our icecat is based on?
<ng0>i currently have no old firefox.
<ng0>I know that it used to work for a long time
<ng0>predating 45
***d__ is now known as Guest45177
<ng0>paroneayea: which features of firefox are needed for webrtc videochat to function? i think some of the defaults of icecat disable features needed
<ng0>or whatever is patched out
<davexunit>probably needs mp4 support
<davexunit>which we don't have
<davexunit>not sure if we can have it or not
<ng0>is that openh264 ?
<paroneayea>hm I think daala can be used
<paroneayea>so h.264 isn't necessary for webrtc
<ng0>h264 is disabled in icecat
<paroneayea>yep I know
<ng0>so we can build --with-daala or however that would work?
<Apteryx>ng0: IceCat 45 is much more stable for me that 38 was.
<paroneayea>with sites / clients supporting daala, it should work (assuming --with-daala is what's needed to enable that)
<Apteryx>It still crash occasionally
<ng0>i didn't talk about crashes..
<Apteryx>ooh, sorry, that reply was meant to civodul.
<ng0>using outdated browsers is no solution to crashing not-so-old ones though
<ng0>oh, read it the wrong way around
<ng0>what about the tor description patch? can someone review and maybe apply it?
<ng0>one of the remaining problems about 0ad is the bundled mozjs. it wouldn't be so much of a problem if they would not apply patches
<ng0>i think it would be easier to package mozjs-31.2.0(...) and somehow make 0ad use that
<ng0>hm.. but even if there's a system package, how to apply the patches which only live in the source of 0ad? just assume that mozjs-31 will just work despite the note that it needs these exact changes for the 0ad engine?
<bavier>ng0: what are the nature of the patches?
<ng0>how am I supposed to treat this: ERROR: Throw to key `gnutls-error' with args `(#<gnutls-error-enum A TLS warning alert has been received.> handshake)'.
<ng0>bavier: let me read them again, it's been a while
<ng0> i think we can use a system provided one
<bavier>ng0: appears so
<ng0>there's just the mozilla tls failure before it gets downloaded to store
<ng0>it's because of a recent commit ludovic made, but which one?
<ng0>i can't find it.
<bavier>ng0: git bisect?
<ng0>can I add some "ignore tls error" in the package? if it fails here, it will fail on hydra
<bavier>what's the url?
<ng0> which redirects to
<ng0>well the version of 0ad I package has 31.2.0.rc0, but there was a new 0ad release
<bavier>ng0: I get the same tls handshake error with an older guix for that url
<ng0>works in the webbrowser
<ng0>can we make guix ignore the tls error?
<ng0>otherwise we can not package 0ad until mozjs 38 lands on ftp, which can take months, years, whoknows
<ng0>I could use fedora mirrors
<ng0>or debian, or whoever provides unchanged tar.bz2
<bavier>we point to debian mirrors for many other source
<bavier>that should be fine here too
<davexunit>sad, there's a decent amount of resistance to reproducible builds among GNU maintainers.
<ng0>bavier: fedora is so far the only distro carrying version 38
<ng0>but i don't know if/where they store tarballs
<bavier>davexunit: oh?
<ng0>i could get a source from nixpkgs when they update 0ad
<ng0>an update of 0ad would require them to include mozjs 38
<ng0>are freebsd distfiles compiled for bsd or upstream sources?
<ng0>i found this:
<ng0>which is not optimal.. but it's difficult to find sources
<ng0>it has the same size as the source
<ng0>would diffoscope tell me if it's 1:1 the same?
<ng0>or, how can I diff tar.bz2 files?
<bavier>ng0: 'guix hash' would produce the same value
<ng0>ah, yes
<bavier>if they were the same, that is
<ng0>thanks :)
<ng0>same hash
<ng0>i will comment that, the link worked. fedora provides no tarballs, debian doesn#t have it, gentoo only keeps stable releases, nixos doesn't have version 38 yet, archlinux only has it in aur so no tarball, ...
<ng0>should I make (source (uri a list which includes the original source in case it gets functional one day?
<bavier>ng0: seems like a good idea
<jmd>How do I set a new file-system-service? The manual doesn't explain this.
<efraim>sneek: later tell lfam try out qsyncthingtray I don't have a system tray ATM to try it out
<sneek>Got it.
<efraim>sneek: botsnack
<thomassgn>how do I find what package module a package is in?
<jmd>thomassgn: I use grep.
<ng0>or guix package -s
<efraim>packages build in order now? `guix build foo bar baz' used to build baz, bar, foo
<ng0>where does the python module "xpt" come from, which package provides it?
<ng0>could be that this is something which needs to be bundled
<jmd>efraim: I thought they built in parallel
<efraim>I can only build one at a time
<thomassgn>I keep having 'ip addr' and ifconfig hang and lock my console. kill -9 has no effect. I have got networking running on one ethernet port earlier, but not now. Any tips?
<chatter>allah is doing
<chatter>sun is not doing allah is doing
<chatter>moon is not doing allah is doing
<chatter>stars are not doing allah is doing
<chatter>planets are not doing allah is doing
<chatter>galaxies are not doing allah is doing
<chatter>oceans are not doing allah is doing
<chatter>mountains are not doing allah is doing
<chatter>trees are not doing allah is doing
<chatter>mom is not doing allah is doing
<chatter>dad is not doing allah is doing
<chatter>boss is not doing allah is doing
<chatter>job is not doing allah is doing
<chatter>dollar is not doing allah is doing
<chatter>degree is not doing allah is doing
<chatter>medicine is not doing allah is doing
<chatter>customers are not doing allah is doing
<chatter>you can not get a job without the permission of allah
<chatter>you can not get married without the permission of allah
<Gottox>~~ C:::::::(.(.)
<chatter>nobody can get angry at you without the permission of allah
<chatter>light is not doing allah is doing
<chatter>fan is not doing allah is doing
<chatter>businessess are not doing allah is doing
<chatter>america is not doing allah is doing
<chatter>fire can not burn without the permission of allah
<ng0>so I take it no one is around with op for this channel
<chatter>knife can not cut without the permission of allah
<chatter>rulers are not doing allah is doing
<chatter>governments are not doing allah is doing
<ng0>bavier: do you have op? or do you know who does?
<chatter>sleep is not doing allah is doing
<chatter>hunger is not doing allah is doing
<ng0>combo breaker
<chatter>food does not take away the hunger allah takes away the hunger
<chatter>water does not take away the thirst allah takes away the thirst
<chatter>seeing is not doing allah is doing
<chatter>hearing is not doing allah is doing
<chatter>seasons are not doing allah is doing
<chatter>weather is not doing allah is doing
<chatter>humans are not doing allah is doing
<chatter>animals are not doing allah is doing
<chatter>the best amongst you are those who learn the quran and teach it
<ng0>or davexunit. someone has to have ops... otherwise I recommend to give more people in other timezones op
<chatter>one letter read from book of allah amounts to one good deed and allah multiplies one good deed ten times
<chatter>hearts get rusted as does iron with water to remove rust from heart recitation of quran and rememberance of death
<chatter>heart is likened to a mirror
<Fuchs>chatter: hi
<chatter>when a person commits one sin a black dot sustains the heart
<davexunit>I don't think I have ops
<davexunit>Fuchs: thanks!
<ng0>i dropped a message in #freenode about it
<alezost>ouch, someone wanted to make allah great again
<ng0>spam is spam, no matter the content
<Fuchs>it's a known issue, I took care of it, poke me if it returns. Thanks :)
<davexunit>argh GNU maintainers are some of the most stubborn people I've ever encountered
<albertoefg>hello :)
<alezost>Apteryx: I've read the logs, glad to see you figured out those gpg/pinentry problems. BTW to make sneek leave a message for someone, you need to write "later tell" not "Later, tell"
<albertoefg>anyone wants to join us on Libre Game Night
<davexunit>should've known better than to chime in on g-p-d
<albertoefg>we only play free games :)
<albertoefg>we play every week at a different time so any time zone can join
<alezost>albertoefg: thanks for the link! :-)
<albertoefg>u can join us on #lgn
<janneke>davexunit: ...some GNU maintainers
<ng0>does someone know why openssl is not reproducible yet?
<ng0>or at least why it is reported as not deterministic?
<janneke>$ sudo rm -r /tmp/guix-build-*
<janneke>sudo: /home/janneke/src/verum/.profile/bin/sudo must be owned by uid 0 and have the setuid bit set
<janneke>...and i was so happy with my upgrade ;-)
<jmd>davexunit: He does have a point. Dropping timestamps from ar makes dependencies
<davexunit>so that needs fixing, but I think he is looking for ways to dismiss reproducible builds
<janneke>we really need a make replacement in guile and get rid of this timestamp madness
<davexunit>just like eli seems to be doing
<jmd>Things which have evolved over 40 years take time to change.
<janneke>davexunit: oh, i should look into that
<davexunit>I don't fully understand that particular problem, all I know is that it doesn't seem to be a problem in Guix
<davexunit>but it's been made clear to me over the few years I've been involved with GNU that GNU maintainers *hate* change.
<jmd>Well we have had *some* problems.
<davexunit>or at least there are a group of particularly vocal maintainers that attempt to block any progress that GNU makes.
<janneke>i've tried to replace autotools...
<davexunit>it was a constant source of stress during the year I worked for the FSF
<jmd>GNU is conservative. Sure.
<janneke>amend the coding standards for c++
<davexunit>for example, I gave a good effort to get out of a CVS repo and into a git repo
<bavier>there is some benefit to consistency
<davexunit>it was blocked over and over.
<bavier>but at the same time opening avenues for progress
<janneke>bavier: agreed, i'm really bad at seeing that, i know
<bavier>janneke, OriansJ: I was wondering if it might be nice to have a bootstrapping discussion at LibrePlanet
<bavier>the theme is "Roots of Freedom", so it would seem like an appropriate topic
<janneke>bavier: that would be nice, however it would be a bit of a challenge to go there
<bavier>janneke: understood, I was thinking about making the trek
<bavier>but some collaboration in a talk proposal and slides perhaps
<janneke>bavier sure
<bavier>janneke: cool, I'll be in touch
<civodul>yay for repro builds in the GCS!
<davexunit>civodul: unfortunately, many maintainers feel there are significant downsides to reproducible builds.
<davexunit>I think perhaps you could put to rest some of those fears
<bavier>is there an archive of the discussion?
<davexunit>it's not a public list
<bavier>ah, ok
<davexunit>civodul: hah, and now your mail has entered my inbox
<civodul>that this list is private sucks
<civodul>thanks davexunit for monitoring that thread, BTW :-)
<civodul>it's ok that people have questions about repro builds, we just need to explain it more
<bavier>summary of the opposing arguments?
<davexunit>something about gnu ar being reproducible breaks things
<davexunit>and something about recording the CPU that was used to build the software being useful
<civodul>took just a year for it to happen
<ng0>mozjs-38.2.1.rc0 .pc file is named "js.pc", can this be the reason why pkg-config does not find it?
<bavier>ng0: depends on what other packages expect it to be called, I guess
<bavier>ng0: is it installed in the proper directory?
<ng0>the build system of 0ad is, well spock would say "fascinating."
<ng0>so i have to search a while for the right makefile
<ng0>js.pc lists no version
<ng0>is this normal?
<ng0>I don't know much about pkg-config
<bavier>no, I would expect that might break something
<ng0>ok, so i need to patch mozjs
<jmd>Does anyone have an example configuration of file-system-service-type ?
<bavier>idk how `pkg-config --exists js >= ...` would be expected to work in that case
<jmd>or even a description - it's not mentioned in the manual.
<ng0>bavier: ah.. yeah
<baconicsynergy>helloooo and good morning
<bavier>hello baconicsynergy
<baconicsynergy>hello bavier
<baconicsynergy>everything seems to be going rather swimmingly with guixsd, but i have an interesting issue
<baconicsynergy>I attempted to install libreoffice, and I can confirm that its placed within /gnu/store/*
<baconicsynergy>but it isn't present within my .guix-profile directory
<baconicsynergy>and thus isn't available in my path
<bavier>baconicsynergy: you installed with `guix package -i libreoffice`?
<baconicsynergy>after running guix pull
<baconicsynergy>its the last little issue before I can use GuixSD as my main work distro!
<baconicsynergy>I'm not too upset, this is too much fun
<bavier>baconicsynergy: I think the executable might be called "soffice"
<baconicsynergy>you are the best
<baconicsynergy>a little unconventional, no?
<bavier>baconicsynergy: it's unconventional in that we tend to stick with what upstream uses. Most other distros change the libreoffice binary names or include symlinks, etc
<civodul>we could include that symlink if everybody else does
<jmd>All other distros I've used also call it "soffice".
<civodul>me too, but i haven't used that many distros ;-)
<ng0>we should symlink it..
<baconicsynergy>i agree. im about to make an alias right now
<bavier>baconicsynergy: good luck with guix! thanks for asking
<baconicsynergy>absolutely! np. ill be around for a while
<jmd>If we do decide to do that, perhaps we can also have some other common ones, like lex -> flex, yacc -> bison, cc -> gcc etc.
<ng0>soffice is pressumably from "Star Office" whic hit used to be once upon a time
<ng0>sometimes upstream sucks, so we have to make the changes.
<baconicsynergy>Now that's some interesting trivia
<ng0>i'm just guessing based on the applkications history
<ng0>and I think pybitmessage should use python3 and pyqt5, but they don't think it's an important issue (the pyqt5), so either upstream fixes it at some point, or I will when I make space for that
<ng0>i think i will finish the 0ad before the end of the year
<ng0>and then I will leave games to those who like to package games
<bavier>ng0: :)
***kelsoo1 is now known as kelsoo