IRC channel logs

2017-05-18.log

back to list of logs

<apteryx[m]>civodul: I'm not sure what's to be done about it, but if IIRC an admin of this room (you?) only needs to give consent.
<apteryx[m]>Kẏra: could you remind civodul and I how it works to have this channel bridged with #guix:matrix.org ?
<jackhill>civodul: thanks. I guess I had the new Guix code but it was still using the old Guile for some reason.
<thekyriarchy>yeah, so there's a matrix <--> irc bot that can be used to bridge matrix channels with irc channels (as well as other types)
<thekyriarchy>there's basically a reserved namespace for irc users/channels to be represented
<thekyriarchy>and in the other direction it automatically generates irc handles for matrix users based on their username (unless they have manually set one differently)
<thekyriarchy>on both sides, admins have the same ability to kick or ban any users
<thekyriarchy>ops*
<thekyriarchy>matrix just offers a much nicer interface for new users, which is pretty nice
<apteryx[m]>Kẏra: OK, thanks for explaining. What would be required of the current channel admin(s) such as civodul to have this going?
<thekyriarchy>someone in the room needs to have ops at the time
<thekyriarchy>and if they give consent i can push a button which will prompt a bot to msg them asking if they would like the room bridged, at which point they can push the button or not
<apteryx[m]>OK, so IIUC, if an admin agrees to this then you can initiate the process from the matrix side and all they have to do is confirm to the bot that they do want this to happen?
<apteryx[m]>Kẏra: One last question: who are the admin(s) of the #guix:matrix.org channel? I presume you are one of them?
<thekyriarchy>currently myself, i can grant ops to civodul as well if its a concern
<apteryx[m]>civodul: If you have read the matrix bridging discussion above and would like to proceed, we only need you to confirm, as an admin of this channel, that you'd like this to happen. Then Kyra, as the admin of #guix:matrix.org can initiate the process described above.
<lfam>Does anyone have a Guix package of matrix?
<apteryx[m]>lfam: Not yet, but the weechat script to enable matrix supports sounds like an easy target.
<lfam>That sounds like a good first step
<lfam>Then we can all join the fun :)(
<lfam>I mean, :)
<apteryx[m]>Right :) Its on my to-do list.
<thekyriarchy>there are mobile apps, and the browser version works on all platforms
<lfam>Very cool
<lfam>civodul is not around right now. I recommend sending mail to <guix-devel@gnu.org>
<apteryx[m]>OK! I can take care of that later. Kyra, you could you pm me your email address on matrix so that I can add you to that guix-devel thread?
<ryanwatkins>Hey guys, I am having some trouble getting a guile module I have recently packaged to be recognised by guile, do I need to make my package definition slightly different perhaps?
<lfam>Hey ryanwatkins! I probably can't help, but if nobody else pipes up, you might find good advice on #guile, or <help-guix@gnu.org>
<ryanwatkins>lfam: okay :D
<ryanwatkins>This is the definition I am trying to create, it installs correctly - http://paste.lisp.org/display/346976
<lfam>The only advice I have is to check the value of GUILE_LOAD_PATH
<ryanwatkins>lfam: gotcha, presumably somewhere when I install the package should also match the GUILE_LOAD_PATH right?
<ryanwatkins>lfam: presumably the output should state it?
<lfam>ryanwatkins: I'm not sure... I'm not a very strong Schemer yet
<ryanwatkins>lfam: me too unfortunately :D
<lfam>But my understanding is that variable tells Guile where to look for modules
<lfam>Try #guile :)
<brendyyn>ryanwatkins: You don't need guile-2.2 any more since guile 2.2.2 is the latest guile now
<brendyyn>("guile" ,guile)
<ryanwatkins>brendyyn: okay lemme try that...
<ryanwatkins>oh damn, how do I update all my guix packages again, forgot the command...
<ryanwatkins>I think I have an old guile on 2.2.0
<ryanwatkins>guix pull right?
<lfam>`guix pull` updates the package definitions available to your user. Then do `guix package -u .` to update your installed packages
<retard>I'm having trouble getting my system to build. What's the minimum I need to do to my config file for a barebones build?
<lfam>retard: Can you clarify what goes wrong? The os-config-bare-bones.texi template should suffice, as long as you make the necessary changes to the bootloader and file-systems sections
<retard>lfam: you're referring to this: https://www.gnu.org/software/guix/manual/html_node/Using-the-Configuration-System.html#Using-the-Configuration-System ?
<lfam>retard: Yes, that section of the manual is generated from this example, whose filename I got wrong a minute ago! https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/examples/bare-bones.tmpl
<lfam>The .texi file I mentioned is generated from that file
<retard>What goes wrong is I get gzip: stdin: unexpected end of file , next line reads guix substitute: error: corrupt input while restoring "gnu/store/q13cpi...../lib/libz.s0.1.2.8' from #{read pipe}#
<lfam>retard: Can you share the full URL that fails?
<lfam>retard: And in the meantime, you can work around the problem with --fallback (the error message should suggest this)
<lfam>This will build the package from source while we remove this truncated file from the mirror
<retard>lfam: yeah, can't copy and paste since diff machine but one sec
<retard>lfam: typing --fallback resulted in command not found.. Probably a dumb oversight there on my end :)
<lfam>That's an option you can pass to whatever command failed :)
<lfam>If you can get that full URL, I'll be able to have it removed from the mirror.
<retard>Ahhh I see! Hahaha ok looks like I'm rolling again, thanks!
<lfam>Otherwise, it will be removed automatically after some period of time
<retard>Am I safe to libreboot with GuixSD?
<lfam>It works but, if I understand correctly, requires some special actions
<retard>Do you know where I might read more about these special actions?
<lfam>GuixSD tries to install it's own copy of GRUB which I believe conflicts with libreboot. You can pass '--no-bootloader' (or '--no-grub', for older copies of Guix), to `guix system init`. However, I recommend you do a little more research, since I've never tried this myself.
<lfam>I found this slightly old guide: https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00925.html
<lfam>I still recommend digging a little further
<lfam>The `deco` command mentioned there has been renamed to `herd`
<lfam>I'd hate for you to break a system you already have installed. Please search on the archives of <guix-devel@gnu.org> and <help-guix@gnu.org>, and possible <bug-guix@gnu.org>.
<retard>Ok, thanks for the resources!
<lfam>Currently, we're refactoring the bootloader code in GuixSD. Hopefully this will lead to an easier time for libreboot user
<lfam>s
<retard>Oh, you help develop?
<retard>contribute code?
<lfam>Yes, but I'm not that familiar with libreboot. That's why I'm hesitant to advise you to go ahead :)
<retard>Man that's awesome, I'd like to be able to contribute someday. I'm just a noobie thogh
<retard>*though
<lfam>Everyone starts somewhere :) We are always happy to help newbies get started. No patch is too trivial; no question too obvious!
<retard>would you recommend just following this? https://debbugs.gnu.org/
<lfam>That's the bug tracker for *all* GNU packages. This is the Guix bug tracker: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix
<lfam>These are our official instructions about contributing to the project: https://www.gnu.org/software/guix/manual/html_node/Contributing.html
<retard> lfam: thanks for the link, I'll definately check that out! I've been wanting to contribute somehow.
<DoublePlusGood23>rekado: how do I reconfigure my system to use guile 2.2? I had done it earlier, but it didn't change much.
<DoublePlusGood23>Also, the offloading docs reference the $GUILE_LOAD_PATH but I'm unsure where to export it exactly - server side it is empty.
<lfam>DoublePlusGood23: Recently, Guix switched to Guile 2.2 by default. So, if you've done `guix pull && guix system reconfigure` recently, you're using Guile 2.2
<lfam>Remember, though, that individual users also have their own Guix packages, so they need to do `guix pull && guix package --upgrade .`
<DoublePlusGood23>lfam: `guix pull` still seems to use 2.0.x on my GuixSD install, but it uses 2.2 on my ubuntu desktop install.
<Apteryx>Arg. I have guile-2.0.14 in my profile, and I didn't install it explicitly. I guess it got pulled as a "propagated-input" ?
<Apteryx>I think I also have guile@2.2, but the 2.0 seems to take precedence in my PATH
<Apteryx>This causes weird errors when I use Geiser to compile a package I'm working on (compiles with 2.0, but all the .go file in the checkout were compiled with 2.2)
<Apteryx>Maybe we could have guile binaries like guile2.0 or guile2.2 like Python does, so that if multiple versions are in the path they can still be used.
<Apteryx>Oh, maybe I talk too soon. It was coming from my system profile. If I do 'guix package -i guile' the correct 2.2.2 guile version in my profile takes precedence over that. So I'm happy! :)
<happy_gnu>paroneayea: hi
<DoublePlusGood23>Anyone using an offload server?
<retard>Is it normal for a GuixSD install to take 60+ minutes? Last command I entered was guix system init /mnt/etc/config.scm /mnt
<lfam>retard: It could be normal if you have to compile some packages
<brendyyn>It took me about 3 days
<retard>damn lol
<brendyyn>But a new release is coming any day now, 0.13
<mr-mustache>I finally got a 'bare-bones' GuixSD system up on my laptop (no X, very basic); did a 'guix pull' and tried to run 'reconfigure', that failed and suggested '--fallback'. that has failed too with an unhelpful error message about 'build failed: ... guix-0.12.0-11.ce92d26.drv'. Any idea where I can find more detailed info on what exactly failed?
<lfam>mr-mustache: Hm, not great! Are there any messages above 'build failed'?
<lfam>retard: You can check what is left to be done by opening another TTY and running the same command with '--dry-run'
<mr-mustache>lfam: looks like the first message that might be useful is: make[2]: *** [Makefile:5149: make-go] Error 139
<lfam>Hm, I'm trying to reproduce
<lfam>Perhaps it's related to <https://bugs.gnu.org/26976>
<Apteryx>I'm trying to package matrix-client for emacs. For the tests, it uses "ert-runner". I added a phase for that + ert-runner as a native input + emacs-el-mock as native-input, but I still get: Cannot open load file: No such file or directory, el-mock
<Apteryx>See: http://paste.lisp.org/display/346988
<Apteryx>Am I suppose to patch a hard ref somewhere?
<Apteryx>Or... do I not have a choice but to use propagated inputs?
<Apteryx>I think we shouldn't do this for emacs-minimal: delete 'install-site-start
<Apteryx>It's probably why it can't see el-mock
<rekado>Apteryx: could you send this to either guix-devel or bug-guix? I hadn’t have problems with Emacs finding elisp packages that were among the inputs, so maybe this is just a problem with this package?
<Apteryx>rekado: 'emacs or 'emacs-minimal?
<Apteryx>'emacs has guix-emacs.el call in site-start.el which does some magic to find other packages' elisp dirs
<Apteryx>(and the emacs-build-system uses 'emacs-minimal by default)
<Apteryx>Hm. Looks like guix-emacs doesn't help. I rebuilt emacs-minimal with it and got the same result.
<Apteryx>Maybe el-mock is simply not autoloaded... Although it I install it in my user profile it works just right... I don't get it.
<Apteryx>If I open --ad-hoc minimal-emacs in pure environment of 'my-emacs-matrix-client' package and do (require 'el-mock) it works.
<Apteryx>So it's just ert-runner which doesn't see el-mock library for some reason
<Apteryx>I think because of the wrapper of ert-runner :(. There's an export EMACSLOADPATH in the script.
<Apteryx>Must make it blind to any other dependencies not listed in its explicitly wrapped dependencies.
<Apteryx>Hm. Apparently the trailing ':' in EMACSLOADPATH means that it should also be looking at the usual locations.
<Apteryx>Which the wrapper script does.
<buenouanq>hi guix
<buenouanq>headed in to Boston tonight
<buenouanq>gonna visit the FSF headquarters tomorrow
<Apteryx>buenouanq: cool!
<buenouanq>need a place to shower and park if anyone wants to help me out
<buenouanq>you can come to DSO with me in the evening too if it's not yet sold out :3
<Apteryx>What is DSO?
<Apteryx>Could someone explain to me by what mecanism Emacs in Guix finds the .el files if not by the 'magic' emacs-guix?
<buenouanq>the Dark Star Orchestra
<Apteryx>Ooh
<buenouanq>they are the current incarnation of the Grateful Dead
<buenouanq>playing at the Wilbur tomorrow night
<buenouanq>I'm doing the whole north east tour
<reepca>Is there any documentation for guile-sqlite3 available? The repository has a blank ChangeLog, NEWS, and README file and no documentation other than the code.
<buenouanq>this will be show 6 of 13
<Apteryx>buenouanq: Wow! Big trip :)
<buenouanq>no better place to be
<reepca>but on the other hand, how better to learn to read scheme than necessity? ¯\\_(ツ)_/¯
<buenouanq>fuck new york though, I just got a huge parking ticket because their signs aren't clear and mean different things from what I'm used to
<jlicht>hello guix
<efraim>hi!
<civodul>Hello Guix!
<wingo>moin :)
<efraim>Hi!
<efraim>glib tests from staging failing on aarch64
<rekado>Hi Guix
<rekado>yesterday’s problems have been fixed. I had a dependency cycle.
<rekado>as I rebased patches I accidentally dropped one
<efraim>yay for it being fixed
<rekado>so I still had icedtea-7 depend on “ant” (not “ant-bootstrap”), which is built with icedtea-8, which is built with “icedtea-7”
<efraim>oops
<rekado>it would be nice if Guix would detect this and abort with a helpful message
<catonano>a nightmare
<efraim>you didn't get a vm buffer overflow?
<efraim>or whatever the fancy error is for that
<rekado>not with guile 2.2.2
<rekado>it just hang there
<rekado>strace showed that it was continously lstat’ing guix/build/utils.scm
<rekado>on the topic of cuirass: it looks like it still aborts when it failed to fetch substitutes.
<rekado>I suppose we don’t see this on bayfront because we don’t use substitutes there.
<rekado>once it fails with a missing substitute (when they are enabled) the service is dead
<rekado>So!
<rekado>let’s write a CTAN importer to warm up~
<mekeor>awesome idea :)
<davidl>I ran guix init and got that python 2.7.12.drv failed and with the next lines saying that gcr, gobject-introspection, mesa, samba and gvfs "1 dependencies couldn't be built". How should I solve that?
<rekado>davidl: does it tell you to try again with “--fallback”?
<davidl>rekado: no
<davidl>I already ran it with --fallback.
<davidl>I have been trying for about 6 days now to get a setup with GPT, LUKS and BTRFS working.
<rekado>isn’t python 2.7.13 the latest version?
<rekado>are you using a recent copy of Guix?
<davidl>no I didn't run guix pull, because I have had a lot of issues when upgrading prior to running guix init.
<davidl>but you think I should do that?
<rekado>I don’t know.
<rekado>If you used the last release there still should be substitutes
<rekado>so I don’t know why it would try to build python locally
<rekado>and then fail doing so
<davidl>I have been building a lot recently.
<rekado>davidl: that doesn’t seem right
<davidl>could it have anything to do with not using ext4 and DOS ?
<rekado>no
<rekado>when you retry without --fallback what does it tell you?
<davidl>Ill try that.
<davidl>if I get a failed build, should I empty the target partition rerunning guix init?
<davidl>before* rerunning
<davidl>rekado: it says that phase check failed after 10 seconds, that builder for guix-0.12.drv failde with exit code 1.
<rekado>davidl: I don’t know enough about your system, but if there’s a test failure for the Guix package I would run “guix pull” first.
<davidl>rekado: ok, thanks.
<davidl>it's a libreboot X200, reinstalling guix on it from scratch.
***Sn0wDay__ is now known as Sn0wDay
<civodul>rekado: CTAN importer, yay! :-)
<civodul>you're tackling the big issues these days: Java, and now TeX Live
<m-o>hi civodul ! i'm trying to unrevert (guix git) module. In build-self.scm, is it ok if guile-git does not have a 2.0 revision like ssh and json ?
<rekado>davidl: ah, I have the same machine, libreboot and all
<rekado>davidl: if you’re also using full disk encryption you may find that libreboot won’t be able to find grub on the encrypted disk
<rekado>davidl: I’m usually unlocking the disk in grub’s command line interface (cryptomount -a), and then pass control to that grub with “configfile (crypto0)/boot/grub/grub.cfg
<civodul>m-o: yes it's ok! just make sure the machinery DTRT when guile-git is missing, like i did for guile-json
<civodul>and hi! :-)
<rekado>hi phant0mas!
<m-o`>civodul: ok, thanks !
<phant0mas>Hello rekado :D
<rekado>phant0mas: since the last release have there been more hurdish things that you think ought to be mentioned in the NEWS file for the next release?
<rekado>BTW, I unbroke the glibc-hurd package. Sorry for the delay!
<davidl>rekado: yes Im doing it that way too :-) except on my other libreboot which I have reflashed appropriately and put the cryptkey in initrd :-P
<phant0mas>rekado: while there was a lot of Hurd related work lately, it was mostly bug fixing
<phant0mas>so it can allow me to finaly push the bootstrap-binaries
<phant0mas>but until that I don't think we should mention anything
<rekado>okay
<rekado>thank you for your efforts!
<rekado>I’m sorry I haven’t been able to contribute anything so far.
<rekado>It’s the next big project on my wishlist
<phant0mas>don't worry about it, you already have lots of work with guix already
<phant0mas>and you do an awesome jobs! :)
<civodul>heya phant0mas!
<phant0mas>hey civodul I have started to tackle the guile test problems one by one on Hurd
<phant0mas>I sent a patch to Andy two days ago about two tests that were failing and methalo_ investigated
<civodul>phant0mas: nice!
<civodul>great to see progress on this front
<efraim>Do we have transitive trust for substitutes?
<civodul>efraim: no, we don't have "delegation"
<civodul>that is, ideally, hydra.gnu.org could provide "delegation certificates" for its build machines
<civodul>such that if you have hydra.gnu.org's key in /etc/guix/acl, the build machines would be trusted as well
<civodul>is that what you had in mind?
<efraim>Or detached signatures
<efraim>If you trust my aarch64 board and it trusts two others and offloads to them
<civodul>yeah, i see
<civodul>we should do that in (guix pki) at some point
<civodul>yay bayfront has built qt@5.8
<efraim>I think I last tested monolithic qt upgrade to 5.7 and it compiled fine
<ng0>as my email has not arrived at the list yet: would someone know what exactly needs to be done for running a mirror? it is not documented, past replies did not help and just using the mirror.conf with some simple-services + nginx service did not get any caching going so far.
<ng0>I think so far it is "oh you know, just do this and that and a bit more of that and you have a mirror, no biggie, no documentation hint needed"
<ng0>could a missing root directory in the server block of the mirror lead to this? we are pretty inconsistent in what is used.. mirror.conf just uses www-data as user for example
<rekado>ng0: have you looked at the actual operating-system configuration of the mirror?
<ng0>yeah, definitely some hick up of the nginx.. my sites are not accessible anymore.
<ng0>yes, and I am using something comparable
<ng0>I could show you a webview link if the nginx were accesible.
<rekado>I cannot help with this now
<civodul>rekado: i was thinking we could do an HTML rendering on the web site of 'NEWS', using a simple Org parser; WDYT?
<ng0>I don't expect you to. it's just, I think it would be good to have a small documentation item on this.
<rekado>civodul: do we have a simple Org parser or would we write one?
<civodul>rekado: yes there's one in guile-present, i just tried
<civodul>seems to work well
<rekado>neat!
<civodul>i'll see if i can do something
<civodul> https://www.gnu.org/software/guix/packages/reproducibility.html <- only 15% "for which we could not conclude"
<civodul>and 15% non-reproducible
<civodul>would be nice to bring it below 10%
<Sleep_Walker>amazing
<rekado>civodul: lowering that number is part of the master’s / internship project here at the MDC.
<rekado>we’re still looking for suitable applicants
<efraim>Marius has(had?) a mirror, don't remember anything about his setup other than it was through AWS
<efraim>ng0: ^^
<rekado>I have a CTAN importer now, but… it’s ugly.
<rekado>looks like there are no versioned tarballs on CTAN
<rekado>we will also need a ctan-build-system, which shouldn’t be too hard to write
<rekado>also, there’s no easy way to determine dependencies
<rekado>so all the importer does is convert XML to a package expression
<rekado>XML like this: https://www.ctan.org/xml/1.2/pkg/piff
<rekado>(and it downloads and hashes the sources)
<rekado>here’s a daily mirror archive: https://ctanmirror.speedata.de/2017-05-18/
<efraim>rekado: factor out the xml parsing, look at this: https://sourceforge.net/projects/msmtp/rss
<rekado>efraim: I’m just using (sxml simple) and (sxml xpath)
<efraim>rekado: sounds great
<rekado>hmm, maybe I should restrict the importer to fetch from the texlive SVN only
<rekado> http://www.tug.org/svn/texlive/trunk/Master/texmf-dist/source
<civodul>rekado: cool that you already have an importer
<civodul>rekado: in other news, i'm adding an 'update-NEWS' Makefile target
<civodul>following janneke's advice
<rekado>civodul: excellent!
<rekado>the importer would be a little less like our traditional importers
<rekado>since there are no versioned archives I think I must declare a global SVN revision and fetch the sources at that revision from SVN
<efraim>Like the bioconductor one?
<rekado>or maybe I can obtain the revision of just the package from SVN
<rekado>efraim: the bioconductor importer doesn’t do this yet, but I think it may need to that too.
<rekado>for the CTAN importer I’m getting all info (including the tarball and version number) from CTAN, but maybe that’s wrong.
<rekado>maybe it should be a texlive importer and only get the info from texlive SVN
<rekado>SVN seems to record revisions per directory
<rekado>so it’s possible to do without a global SVN revision here.
<rekado>I’ll just have to ignore the CTAN version number and replace it with the texlive SVN revision for the directory under http://www.tug.org/svn/texlive/trunk/Master/texmf-dist/source/latex/
<rekado>(and maybe sibling directories under source/)
<rekado>I’ll be quiet in a moment, but here’s a last update: we would want to take from the latest tag, not ‘trunk’. All directories have the same revision for the latest tag ‘texlive-2016.0’, so individual version numbers for packages doesn’t even make sense.
<rekado>all packages would just have version ‘texlive-2016.0’ (tag name) or ‘41289’ (the revision)
<rekado>the importer would have to allow overriding of the tag
<reepca>... question, is "guix hash" supposed to give different hashes for normal files depending on whether the --recursive flag is used?
<reepca>file-hash in guix/scripts/hash.scm uses open-sha256-port for non-recursive, but port-sha256 (which first converts to nar before hashing) when it's recursive.
<civodul>reepca: yes, it gives different hashes depending on whether --recursive is used
<civodul>and yes, --recursive really means "convert to nar, hash the nar"
<wingo>ACTION didn't know that :)
<civodul>instead of just "hash the input file"
<civodul>:-)
<reepca>ACTION didn't know that either
<efraim>Is it possible to compare the SVN revision and the tag name to see which is newer and create a custom version, like 2016.0-41289
<efraim>rekado: ^^
<efraim>can't work on it now, but on aarch64 'guix package -A foo' shows no output, but 'guix package --search=foo' or '--show=foo' works
<rekado>efraim: I think we don’t want to just use the latest SVN revision.
<efraim>True
<rekado>to update to the next release we will only have to check if a tag with a higher revision exists, and then use that for all packages.
<rekado>but I must admit that I find texlive rather confusing
<rekado>at the very least we will be able to break apart the big texlive package
<rekado>but I’m not sure a regular importer is actually very useful
<civodul>rekado: how would you go about merging only parts of master in version-0.13.0, without cherry-picking individual commits?
<rekado>civodul: I would not. I would only cherry-pick commits.
<civodul>heh ok :-)
<rekado>or merge, then interactive rebase to delete the commits
<rekado>bleh, svn:// is blocked here, so I can’t continue with the Texlive work in the office.
<efraim>They don't want you committing secrets to an off-site repo
<Apteryx>Could someone explain to me by what means are our elisp files discovered by emacs-minimal?
<mr-mustache>lfam: thanks! I suspect you're right; I get these sorts of failures on different packages when I messed around with X11 (caribou in that case)
<Apteryx>The only mechanism that I can see for elisp discovery is defined in our "emacs" package, by adding some logic to the site-start.el file.
<rekado>Apteryx Have you checked the build system?
<Apteryx>rekado: Oh, maybe through the autoload mechanism
<Apteryx>rekado: I hadn't checked there, thanks :)
<Apteryx>hmm, if I understand correctly, the autoload files are put under each package's ../share/emacs/site-lisp/guix.d/, so that's not the mechanism by which these are found.
<Apteryx>There needs to be something else that tells Emacs: "look for ever packages-item/share/emacs/site-lisp/guix.d/" for your elisp discovery.
<efraim>speaking of the emacs-build-system, can someone with emacs knowledge check out the emacs portion of my translate-shell package?
***andreh1 is now known as andreh
<Apteryx>rekado: The build environment doesn't include a profile, right?
<Apteryx>I finished my analysis. The only reason emacs knows about some-emacs-package/share/emacs/site-lisp/guix.d/ installed libraries is because of guix-emacs.el which is called in the site-start.el file. This only works in the presence of a profile.
<Apteryx>In other words, there is no automated mechanism right now to simply specify other emacs dependencies at build time and expect the emacs-minimal or even emacs to pick those up (emacs-minimal lacks site-start.el file, and more problematic, there are no profile at build time)
<Apteryx>So it looks like my work around will be to manually hack a working EMACSLOADPATH envar with my extra dependency guix.d directory.
<quiliro>hello
<bavier>hi quiliro
<quiliro>I would like to install guixsd to be an offline installation server
<quiliro>i can stay 4 or 5 hours....would anyone please guide me?
<quiliro>now i can connect the machine to the lan...but i only have one monitor
<quiliro>and keyboard
<quiliro>i have parabola on the current machine
<quiliro>and parabola on the other machine too
<quiliro>(the future server
<quiliro>)
<quiliro>hi bavier....long time no see!
<quiliro>bavier: it is a real problem not being able to tinker with guixsd offline
<bavier>quiliro: I can imagine
<quiliro>i could just install a base installation with nginx and then mirror hydra...what do you think?
<bavier>quiliro: I think the nginx mirroring happens on-demand
<bavier>so I don't know if that would be useful for you in an offline setting.
<bavier>you could set the server up with a guix-publish service, then prime the store by doing some 'guix build ...'
<bavier>that would hopefully pull substitutes from hydra
<bavier>and as backup you could 'guix build --sources=transitive ...' so that the server can serve sources for anything else
<bavier>I think it would be nice to offer a "sources dvd" iso image like e.g. Trisquel does
<bavier>ACTION afk
<quiliro>bavier: those solutions would not server me because i would need to install all served packages...i need not to install but to serve packages
<OriansJ>janneke: bad news, module/mes/read-0-32.mo when built from source seems to have a different sha256sum than the one checked into the repo (also you are right about build times, 4 Hours and 57Minutes for single core 512MB vm >.<)
<janneke>OriansJ: ugh! hopefully I just goofed and did not regenerate read-0-32.mo when I should have
<janneke>OriansJ: I'm not too worried whenever it was not bit-reproducible it was usually something silly
<janneke>but thanks a lot for checking!
<janneke>i'll have a look over here
<janneke>OriansJ: when I regenerate the .mo for 0.6 using Guile, like so:
<janneke>make clean-mo all-mo
<janneke>commit d4420bbc Release 0.6.
<janneke>i get a modified mo :-(, sha256sum:
<janneke>69e446c318e0fd43f53f9481fae05a4b5c784c1717d3dc694189be72e4bad191 module/mes/read-0-32.mo
<janneke>ACTION failed to add make clean-mo make all-mo to `make release' target :-(
<OriansJ>janneke: I think we should break mes into discrete and easy to audit chunks, that way it will be easier for me to help.
<OriansJ>janneke: You are willing to pull from github right?
<janneke>OriansJ: mes tries to do *everything* right now
<janneke>that's mainly because it's convenient and i don't see (or look for) another way
<janneke>sure, I'll pull from github -- it's just not recommended by the fsf, so I try not to use or advertise it
<janneke>if you see ways to break-up mes, and/or make it more accessible, that's great!
<janneke>also, I'd be very happy to answer any questions you may have to get you involved [and help with the breakup]
<OriansJ>janneke: well your build process already is made up of multiple pieces, so breaking it up there would be reasonable
<OriansJ>as for the recommended by the fsf, that is why I migrated stage0 from github to savannah
<OriansJ>Once we have it into smaller pieces, it should be easier to pin point major performance problem areas
<janneke>that would be nice, i have no hard data about performance bottlenecks, only some suspicions -- terriblbe
<OriansJ>janneke: I guess those are the first things about mes that I am going to work on
<janneke>OriansJ: I suspect not having real modules but one global namespace is a problem, assq has been the biggest problem
<janneke>also, possibly the way I handle my stack and continuations (push_cc/pop_cc)
<janneke>but it is very well possible that there's something that I don't see
<civodul>anyone willing to augment the "Noteworthy bug fixes" section of NEWS on the 'version-0.13.0' branch?
<OriansJ>janneke: performance is always measure then tweak and measure again
<m-o>civodul: i may have found a guix pull bug here : https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26987
<janneke>OriansJ: yeah...
<janneke>ACTION just removed regexps from guile-1.8's getopt-long, for Mes
<janneke>working on -c option for mescc
<civodul>m-o: thanks for the heads-up! there's no shortage of ugly bugs today :-)
<civodul>if you find a way to fix it, i'm interested
<m-o>civodul: i'll investigate tomorrow :)
<slyfox>civodul: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26805#34 fixed all of 'delete' collisions of modify-phases for me in core-updates.
<civodul>slyfox: awesome!
<civodul>sorry i've been postponing stuff related to core-updates
<civodul>i've enough on my plate right now ;-)
<civodul>but i'll get back to that afterwards!
<slyfox>yeah, sure. looks like release is imminent :)
<civodul>it's been imminent for too long already!
<roelj>Which font was used for the GuixSD text next to the logo on the website?
<rekado>oof, I just noticed that our ancient version of java-hamcrest-core has long been replaced with java-hamcrest.
<rekado>The artifact name had changed so I didn’t find the latest version back then.
<civodul>roelj: not sure, you could check the svg in guix-artwork.git
<rekado>oh, never mind. Junit really does depend on that ancient version of hamcrest.
<rekado>weird.
<roelj>civodul: The SVGs don't have the font information..
<roelj>civodul: I think it's just DeJaVu Sans, but the spacing is off..
<civodul>roelj: you could email sirgazil, who made the logo