IRC channel logs


back to list of logs

<Jfault>guving into GuixSD (within QEMU) right now!
<Jfault>is `guix system init /mnt/etc/config.scm /mnt` supposed to produce output?
<fpss>sorry for the connection troubles :(
<fpss>ok, booting with grub and efi seems to be just a clusterfsck of confusion when it comes to documentation on the web :)
<rekado>looks like we forgot to update gfortran to gfortran-5 on core-updates.
<efraim>we also forgot to update bigloo's emacs version to 25 when that happened, but I'm guessing that's less of a big deal
***kelsoo1 is now known as kelsoo
<civodul>Hello Guix!
<snape>civodul: I did a review (my first, hope it helps) on the tlp service. Do you think I could push it, or should I wait for another reviewer?
<snape>(hello civodul)
<civodul>snape: i can take a quick look if you want, but in general, if you're confident, you can push it
<civodul>we can always fix later
<civodul>snape: the only very minor thing i see is in guix.texi, where i'd add an @uref pointing to the TLP web site
<civodul>and perhaps a sentence saying how it compares to upower
<civodul>but we can always do that later
<civodul>snape: at any rate, thanks a lot for reviewing patches!
<civodul>it's very very helpful
<snape>np :)
<snape>thanks for checking. I think Mathieu saw your comments on guix.texi
<Mathieu>hi !
<Mathieu>thanks for your reviews civodul & snape :)
<Mathieu>I'll send a v3 to improve documentation then !
<civodul>hey, hi Mathieu!
<civodul>didn't know you were hanging out here ;-)
<civodul>Mathieu: thanks for all the good patches, BTW!
<Mathieu>snape told me to have a look, we are coworkers :)
<thomasd>ACTION finally gave in and configured Gnus
<Mathieu>civodul: my pleasure :)
<thomasd>should be easier to comment on patches now :)
<Mathieu>I'm having a hard time working on bootloader patches, but I hope to come up with some thing next week or so.
<amz3>héllo #guix :)
<efraim>looking at the code again, I think tweaking the xz calls in guix/scripts/pack.scm and guix/utils.scm should give us parallel compression/decompression
<civodul>Mathieu: oh you're working with snape? fun :-)
<civodul>efraim: what do you mean?
<efraim>if we pass '-T0' to xz then it will use all available cores when compressing, and if it was compressed in parallel it will decompress in parallel
<efraim>it should dramatically speed up patching sources
<rekado>thomasd: what email client do you normally use?
<thomasd>“Mew” I remember you mentioned that patching debbugs-gnu to use another mail client shouldn't be hard, but I thought just using Gnus would be the way of least resistance :)
<rekado>I got it to work with mu4e; it can either be used with your regular mudir or a separate one (with some annoying limitations).
<rekado>haven’t tried “Mew” so far.
<rekado>ACTION goes afk for a meeting
<snape>I got mu4e to work with debbugs-gnu pretty easily
<thomasd>snape: what did you do? Is there any documentation on that? pastes welcome :)
<snape>thomasd: I did this:
<snape>It might not be perfect though, but it does the job
<snape>improvments welcome :)
<snape>well, the "interactive" is probably not needed, first improvement.
<thomasd>so, AFAIU, you replace the function to open a report in gnus, by a search for the related message in mu4e?
<thomasd>I think I could try to cook up something like the existing 'debbugs-read-emacs-bug-with-rmail.
<snape>thomasd: yes, that's what i did
<thomasd>I can't steal it as it is, but you've inspired me :)
<snape>np :) I tried different things, but I don't want to download the message on the fly as does debbugs-read-emacs-bug-with-rmail
<snape>it's slower and useless, since I usually already have the message in my mailbox
<snape>and that would make it not usable when I don't have internet
<thomasd>good points, I'll have to think of something. I think emacs-debbugs doesn't work w/o internet either, though?
<snape>right :) Unless you already have the buffer
<thomasd>Ideally, I would have a separate debbugs mailbox, and only download the messages if they're not already in that mailbox. Getting this right is some work indeed :)
<snape>yes, and there is some work to convert the mbox to maildir format
<snape>because mu only understand maildir format, if I remember well
<snape>and you'll also have to check that the messages you download are not already present, which is.. difficult
<thomasd>yes, though I don't use mu, but mew (still have to check how it handles messages internally)
<thomasd>yes, though the messages have some unique identifiers, I think?
<snape>you download a mbox, that is a package, that contains several messages
<snape>maybe that mbox has an id, and unless it changes you don't have to download it again
<snape>but I fear if it changes you have to download the whole mbox again
<snape>and anyway, in order to check, you *have* to download the mbox so...
<snape>or you have to find another way
<snape>I find it inconvenient
<snape>my solution has the benefit of being very simple
<snape>as long as you suscribe to the right list
<thomasd>yes, what I'm wishing for is certainly not easy. There's also debbugs-get-message, but that would require converting a bunch of strings to an e-mail message “mew” understands :)
<snape>ok, good luck then :)
***Piece_Maker is now known as Acou_Bass
<fps>hmm, i can't guix pull on this guixsd system installed from 0.12 installer either..
<fps>python again fails at exactly 12MB
<fps>something killed the process i think
<fps>oh that was actually installing git..
<fps>with the guix installed inot the system
<thomasd>looking at guile-emacs build failure on core-updates, it fails because of the libjpeg version check, but I don't understand how that check can fail
<tmssen>Hi, trying write a definition of wkhtmltopdf; and figuring out how to package and contribute packages. I have a definition I think is getting close to useable-ish, but running 'C-c . b' in emacs in guix-devel-mode gives me 'ERROR: In procedure #<procedure 57ac8e0 at <current input>:76:14 ()>: Unbound variable: wkhtmltopdf'
<tmssen>how can it not be bound? I can call guix build wkhtmltopdf outside emacs, it gives me other errors but recognizes the definition, I think...
<rekado>snape: that requires that you are subscribed to the list(s) and have a copy of the messages.
<rekado>what I wrote downloads the mbox, turns it into a maildir, indexes that and opens mu4e on that maildir.
<rekado>this allows me to unsubscribe from guix-patches because I can fetch the emails on demand.
<efraim>I wonder if there's some ncurses program that will do that, I'm currently mostly downloading the mbox and opening with mutt
<rekado>mutt reads mbox files directly, doesn’t it?
<pmikkelsen>Hello guix
<thomasd>so is everybody is secretely struggling with debbugs? :) rekado: can you paste your maildir-stuff? It sounds a bit like what I'd like to do for mew.
<efraim>rekado: it does, but I haven't figured out how to point it at the mbox while its not local
<snape>rekado: yes I understand, although fetching emails on demand is much slower.
<snape>rekado: do you have a way to download the mbox only when you need it? That is, only when there is a new message in the bug thread?
***jonsger1 is now known as jonsger
***jonsger1 is now known as jonsger
<rekado>thomasd: I’m a bit short on time this week, which I’d need to turn this into a patch I could share. Eventually, I’ll prepare a patch for the debbugs Emacs package.
<thomasd>rekado: ok, I'll watch this space then
<rekado>snape: I don’t know how to determine whether *all* emails are available locally.
<rekado>to do that I’d have to fetch the mbox anyway
<rekado>not sure if we can get the required info through the debbugs API
<pareidolia>civodul: I was wondering (I'm reading the arxiv paper on Guix right now) whether there has been a paper on g-exprs since?
<civodul>pareidolia: unfortunately no
<civodul>i did talk about it at the Scheme workshop though
<civodul>(you can skip the intro)
<civodul>this video is actually awful, urgh
<pareidolia>civodul: I know that passage very well, it immediately intrigued me
<pareidolia>civodul: Especially the remarks about debugging/stacktraces/context
<civodul>yeah Hop is the only system i know of that does something sensible
<civodul>but the context lends itself better to that
<pareidolia>Do you see this as something that can be improved on our side, or as a dead end?
<civodul>the debugging story could be improved, but "it's complicated" because we don't want changes in the source location to lead a different derivation
<civodul>also, my biased view is that it's not too bad currently: you get an ugly backtrace for code that in the gexp itself, but a proper backtrace for that part of the code that's in modules
<civodul>(because modules are compiled etc.)
<civodul>so overall i don't see it as a priority
<civodul>i'm biased, though
<pareidolia>civodul: And if there were to be an exploitable student?
<civodul>ah ha! :-)
<civodul>why not
<civodul>you feel motivated? :-)
<pareidolia>I feel motivated by my present lack of MSc diploma
<civodul>heh, okay
<civodul>the difficulty here is that i don't know how to achieve this
<civodul>so that'd require research and discussion
<civodul>but maybe that makes it a good topic in this case?
<pareidolia>From the perspective of a master's thesis, that's the big question
<civodul>the other limitations in gexps might also be worth looking at
<pareidolia>civodul: Other limitations?
<civodul>those listed in the slides
<civodul>like modules in scope
<pareidolia>You mean the need for explicit "use-modules" statements?
<civodul>right, and the fact that a gexp doesn't know what modules it needs
<civodul>for gexps that are inserted in other gexps
<civodul>there's no notion of what bindings are visible at the top level
<efraim>I feel like I'm making progress on MIT-Scheme for aarch64, but really I'm delaying on libevent@2.1, mysql and 'make check'
<pareidolia>That seems like a worthwhile thing to improve
<pareidolia>civodul: I guess I'd read up on Hop
<pareidolia>If there are other things on your wishlist, I'd sure like to hear
<erliphant>so I'm building a Python package that I defined myself. I notice that the build seems to finish with a graft. I've not requested any grafts - does anybody know why this happens?
<efraim>The grafts are earlier in the dependency tree
<erliphant>So I effectively end up with two builds? Because of the graft?
<erliphant>Upstream graft?
<erliphant>My build finishes with: grafting '/gnu/store/cjjdyqdhcjvw1zmwalwsc2nxmnhn86xq-python2-somepackage-0.0.1' -> '/gnu/store/scg8xi49lvnfyc51yfa16c1x4z896p8l-python2-somepackage-0.0.1'...
<thomasd>I think a dependency of your pacakge is grafted, therefore yours is grafted as well
<thomasd>indeed you will end up with both versions in the store. (though I suppose the ungrafted version can be garbage collected afterwards)
<erliphant>thomasd: thanks. This is interesting because it seems that I need this second package if I want to use this build for substituting. But I don't get it if I export the environment I built it in
<erliphant>thomasd: what i'm doing is building on one machine and exporting it to a central server where I run "guix publish". However, the export is incomplete because it is missing this graft.
<civodul>erliphant: grafts are always computed locally
<civodul>on purpose: the assumption is that it's faster to compute it locally than to download it
<erliphant>I see .. but that means that it needs the package source to be available?
<erliphant>civodul: I don't really want builds to run on all my production hosts. There are firewalls etc that mean that they won't be able to connect to source repos. I'd like to build centrally and publish the changes. Is this not possible with grafts?
<civodul>erliphant: the grafting process is purely local, it shouldn't require access to the internet etc.
<rekado>erliphant: it doesn’t need the sources.
<civodul>for instance publishes all the ungrafted substitutes as well as all the replacements
<rekado>it’s not a traditional build.
<civodul>and then users graft the replacements locally
<erliphant>civodul: I see.. the problem is that I don't think that the graft ends up in the environment, so I can't export as a substitute. Maybe I should look to the --missing flag to transfer the build.
<erliphant>civodul: rather than relying on the environment as the closure of packages that should be exported
<erliphant>thanks rekado and civodul - this information has been very, very helpful.
<civodul>erliphant: you could try 'guix copy' also
<erliphant>civodul: thanks! .. will take a look
<amz3>In the past I used to have guix git as the root of my user guix install
<amz3>wait forget about it
<amz3>btw, I discovered "guix pull --rebase" which makes it possible to work on packages while publishing patches
<amz3>previously I was using branches but this was overhelming
<catonano>amz3: guix pull --rebase ?
<catonano>I use branchhes too, when I do that and I am overwhelmed too
<amz3>ah sorry, that's a typo, I mean "git pull --rebase"
<catonano>ah ;-)
<efraim>I git fetch and then 'git rebase origin/master' from the branch
<amz3>ah ok so you have a brach which you rebase against origin/master?
<catonano>amz3: II don't know about efraim. I Ido have a branch that I rebase against master
<catonano>this is somethhing thhat I learned to do only very recently
<amz3>ah ok
<amz3>I also learned about that recently
<amz3>I did 'guix environment guix'
<amz3>then ./bootstrap && ./configure and I get the following error:
<amz3>configure: checking for guile 2.2
<amz3>configure: checking for guile 2.0
<amz3>configure: found guile 2.0
<amz3>checking for guile... /home/amirouche/.guix-profile/bin/guile
<amz3>configure: error: found development files for Guile 2.0, but /home/amirouche/.guix-profile/bin/guile has effective version 2.2
<amz3>indeed I have guile 2.2 installed in my user profile
<amz3>also I have zsh as shell installed from my host
<lfam>amz3: Try `guix environment --pure guix`
<amz3>same error
<amz3>I will chsh /bin/bash and try again
<lfam>I can't reproduce the error building the master branch, but my `guix` is running core-updates, so it's probably different from yours
<lfam>I'd try it with `guix environment --container` to be sure it's not a problem with the environment
<amz3>I did chsh /bin/bash and restarted my DE
<amz3>and it works :)
<lfam>Huh, weird! I use Zsh too
<amz3>I use guix over ubuntu
<amz3>do you recommend to move to my profile to guix git?
<amz3>to replace 'guix pull' ?
<efraim>i have a branch i'm slowly working on updating modular-qt to 5.8.0, currently thats my only "personal" branch
<kyamashita>amz3: I'm fairly sure that you can cd into a git checkout of guix and run `./pre-inst-env guix package -u.` to update all your packages to the versions in the git repository.
<kyamashita>I feel like I'm missing something though...
<amz3>kyamashita: if if guix package -i something inside the environment, does it update my profile?
<cbaines>Does anyone know a way of adding actions to a shepherd service defined through Guix? I've had a look, and it looks to me like the shepherd-service-file doesn't support that yet. I'm also quite unsure how to implement it, as getting the g-exps and make-actions macro to work together looks quite tricky...
<kyamashita>amz3: It should.
<cbaines>(I also noticed that the shepherd docs are wrong about actions, where it says "(It actually is a hash currently.)" it looks like a list to me)
<amz3>so, I changed guile-2.0 to guile-2.2 for guile-cairo in gtk.scm and I get the following error during 'make check' ;;; ERROR: failed to create path for auto-compiled file "/tmp/guix-build-guile-cairo-1.4.1.drv-0/guile-cairo-1.4.1/tests/unit-tests/./api-stability.scm"
<amz3>when I run, guix build -K guile-cairo, it fails too. BUT, if I 'cd' into the build directory and do 'make check' it says all tests passed
<kyamashita>amz3: Did you load the build's environment variables, too? `source /tmp/guix-build-guile-cairo-1.4.1.drv-0/environment-variables`
<amz3>kyamashita: tx
<amz3>the tests pass nonetheless 'guild compile' fails for some reason
<amz3>it's not guild, it's guile that tries to compile the file but fails to create the .go file for some reason
<amz3>which user does the build process?
<kyamashita>amz3: Any one of the users in the guixbuild group.
<amz3>ah yes tx again
<amz3>I have also this error appearing at the very beggining of guix build
<amz3>I also have this message: substitute: warning: failed to install locale: Invalid argument
<amz3>even if I set GUIX_LOCPATH for the root and my user
<amz3>and install glib locales package
<kyamashita>amz3: The make_objcode_from_file error is probably from a malformed ELF header, though it doesn't look malformed from what I can see.
<kyamashita>amz3: The second error I haven't figured out yet. I get the same thing on my computer running Trisquel.
<amz3>I think the guix daemon is running without the correct GUIX_LOCPATH or something
<erliphant>I'm getting a crash in guix copy. It seems to crashing in the ssh file transfer code. Has anybody seen this / got a workaround?
<erliphant>specifically the interesting bit of the traceback is:
<erliphant>In guix/ssh.scm:
<erliphant> 150: 1 [send-files # # # ...]
<erliphant>In unknown file:
<erliphant> ?: 0 [length #<unspecified>]
<erliphant>and the error is: ERROR: In procedure length: Wrong type argument in position 1: #<unspecified>
<erliphant>Copy fails for everything that I've tried.
<ILostMyPassword_>Hello, I'm reading some of the guix bug reports and finding many that basically say the "bug is fixed", but I can still find the bugs here:
<ILostMyPassword_>One example is here:
<ILostMyPassword_>Should I reply to all of these bug reports and say, "This bug report can probably be closed." Or is that not helpful?
<bavier1>ILostMyPassword_: that bug is marked as "done"
<ILostMyPassword_>bavier: Why is it listed on
<ILostMyPassword_>Shouldn't it go away if it's done?
<ILostMyPassword_>or archived?
<ILostMyPassword_>How about confirming that a bug exists? Like I follow what the bug says causes the error, and say that I found the same issue.
<kyamashita>ILostMyPassword_: I think that a bug marked "done" is resolved. Note that I haven't used the web interface of debbugs yet.
<ILostMyPassword_>kyamashita: I'm talking about unresolved bugs now. If I confirm the bug locally, should I write back and say, "Yes this bug exists. I had the exact some issue on my Macbook 7,1." ?
<ILostMyPassword_>kyamashita: Do you use gnus?
<kyamashita>ILostMyPassword_: Wait. If you mean for interacting with debbugs, I use the debbugs Emacs package from the ELPA repo.
<jorgesumle>Hi can someone help me with the partitioning?
<efraim>If you confirm the issue still exists that's also helpful
<jorgesumle>I'm installing Guix in a real computer, that has openSUSE. I want to replace openSUSE
<jorgesumle>There is a partition called /dev/sda (Size type 512M EFI System) Should I delete that one?
<efraim>I haven't installed guix on a machine with uefi before
<kyamashita>jorgesumle: I wouldn't delete EFI system partitions, just to be safe.
<kyamashita>FWIW, I haven't installed Guix on a UEFI machine either.
<ILostMyPassword_>jorgesumle: I would take a look at the arch wiki...
<ILostMyPassword_>My computer supports uefi, but I set it up to use the older format, because that's what I know to install.
<jorgesumle>I'll see how far I can get, thanks
<ILostMyPassword_>jorgesumle: You probably want to use ext4 as all of your filesystems. You could also use xfs too, but generally ext4 will be faster from what I hear.
<ILostMyPassword_>don't use btrfs. A ton of distributions have tried switching to it, and no one has yet. (I don't think). Filesystems are hard to do right.
<kyamashita>You can shrink an ext4 partition later, too. XFS doesn't allow shrinking.
<kyamashita>ACTION is afk
<slyfox>hydra returns 504 HTTP errors frequently
<jorgesumle>I got an error during the installation.
<jorgesumle>herd start cow-store /mnt
<jorgesumle>gives me the following error:
<jorgesumle>ERROR: In procedure mount: mount "/.rw-store" on "/gnu/store": Invalid argument
<jorgesumle>There was another line before the error ->>> herd: exception caught while executing 'start' on service 'cow-store'
<ng0>it's been years since I've used modular kernel insteads of costum build ones (or had to care about its effects).. now switching disks in between core2duo systems works. and I assumed that the same disk could be used in an i7 system, as we don't apply any architecture specific options.. but I'm getting dropped straight back to the uefi/legacy boot screen
<ng0>I was able to boot from the installer of Guix. So I assume that a system build on core2duo is incompatible with i7 in some way. correct?
<ng0>I just had 10 minutes with this system, so maybe the previous dangerous cyber-pathogen still has some leftovers on there which are still in the way.
<ng0>(otherwise known as windows 10)
<fps>if an efi boot works correctly partly depends on the firmware. if it's a certified windows 10 x86_64 system then you MUST be able to disable secure boot in the firmware
<ng0>I've set uefi boot to "both" and "legacy first" currently
<fps>what kind of bootloader is installed on the disk?
<fps>grub in the MBR with a separate boot/ partition?
<ng0>the disk has GRUB from Guix, the disk i keep switching in systems, but there's also an Windows Bootloader.. so I guess maybe the previous owner forgot to tell me about an msata or second disk
<fps>so the partition table is GPT? does there also exist a partition of type 'EFI System"?
<fps>then the disk possibly doesn't have a legacy boot available, so the EFI boot takes over..
<ng0>it wouldn't be that much of a problem to redo the system, but we haven't documented uefi guixsd well enough that I could just do it now within 5 minutes
<ng0>no, there's certainly no efi partition on the disk. but maybe elsewhere
<fps>you mean on another disk in the system?
<ng0>I wouldn't know where this windows bootloader should come from
<fps>i'm still noob wrt to efi, but there is a way to interact with the boot manager in the firmware by way of efibootmgr
<fps>it might still have an entry for windows 10 in it
<fps>try efibootmgr -v
<fps>anyways, have a refreshing rest :)
<ng0>ls /dev/sd<tab> gives no different disk than the usb disk I am on currently and the internal ssd
<ng0>if only chroot was fully functional from within the installer usb.. that would help maybe to try and fix some things that way
<slyfox>i'd imagine i7 as a strict superset of core2duo instruction set wise
<ng0>oh found the issue
<ng0>"The laptop can not boot from a GPT disk in Legacy BIOS mode, it is necessary to either switch to UEFI booting or create a MBR Partition Table. "
<ng0>as far as I remember the disk has gpt. explains it.
<ng0>do changes (append) to /proc/cmdline stick around after a reboot or is there something you have to do differently on GuixSD?