IRC channel logs


back to list of logs

<d1rewolf>Hi guys. I am currently using Nix and depend on some non free packages. I read somewhere online and a comment that Nix packages are compatible with guix. Is this truly the case?
<lfam>d1rewolf: The package definitions are not compatible. It's possible for Guix to share a store with Nix. I'm not sure, but I expect that would prevent the use of substitutes for Guix packages.
<lfam>Sharing the store:
<ivegotasthma>lfam: I'm still getting the same error
<ivegotasthma>I used the commands you gave for the network setup
<lfam>ivegotasthma: What version of QEMU are you using? Did you verify the signature of the downloaded image?
<ivegotasthma>lfam: qemu is 3.0.0 and the signature check wants public key of guixsd devs
<ivegotasthma>by running `gpg --verify guixsd...filename...sig`
<lfam>You need to get the key, like this: `gpg --keyserver hkps:// --recv-keys $FOO` where $FOO is the fingerprint
<ivegotasthma>seems to be good
<ivegotasthma>huh, works now
<lfam>Hm, not great that it works so inconsistently...
<d1rewolf>lfam: hmmm...sharing the store. does that mean you can use both guix and nix on the same system?
<lfam>d1rewolf: Yes, but you can also do that with separate stores
<lfam>Just run them both side by side
<d1rewolf>lfam: ah....k. interesting
<d1rewolf>lfam: which would you consider more stable/secure? nixos or guixsd? (not trying to start a holy war)
<ecbrown>if you take e.g. OpenBSD and open all the ports and use bad passwords and this and that then "the most secure os in the world" is insecure
<apteryx>is anyone well versed in TeX build system?
<d1rewolf>ecbrown: sure, that's true. I mean by default
<d1rewolf>which has the better security story? which is quicker to patch vulnerabilities when they come out. that sort of thing
<bavier>for patches that fix a "bug", is it better to send to bug-guix rather than guix-patches?
<mange>Is there already a bug for the thing you're fixing? If not, I would post it to guix-patches.
<bavier>no existing bug afaik
<nckx>+1 guix-patches.
<apteryx>how should I add tex libraries as dependencies? inputs, native-inputs or propagated-inputs?
<apteryx>they are inputs to another tex library that I'm trying to package.
<mange>My guess would be propagated-inputs, but I don't actually know.
<apteryx>my library seems to be compiled down to a jadetex.fmt file, so I'll try native... then inputs... and last propagated if it's unusable otherwise ;)
<apteryx>also, how should I name TeX libraries pulled from CTAN rather than TeXlive? ctan-marvosym? or stick to texlive-marvosym since I'm using the texlive-build-system?
<bavier>apteryx: is the library also available from the texlive tree?
<bavier>unless there's a good reason, I think we should pull our tex package from there
<apteryx>bavier: the texlive importer failed to find it and looking at the texlive subversion repo I couldn't either.
<apteryx>but confusingly, it's packaged (well, bundled) on debian as texlive-fonts-recommended
<apteryx>ah, nevermind, it seems to exist in texlive here:
<apteryx>err, this is texlive itself.
<apteryx>this doesn't work for some reason: 'guix import texlive marvosym'
<apteryx>The reason being: URL 'svn://' doesn't exist
<bavier>apteryx: debian's texlive-fonts-recommended is a "meta" package, we have e.g. texlive-fonts-ec and texlive-fonts-rsfs, which are bundled in texlive-fonts-recommended in debian
<apteryx>bavier: yeah. So I'd like to package it alone, but can't find the sources in the texlive repo, although it's supposed to exist there.
<apteryx>this one's called texlive-marvosym but it fetches the sources from ctan:
<apteryx>I think I'll do just that :)
<bavier>apteryx: I found this but haven't found the rest
<bavier>looks like they take the afm and type1 files from texmf-dist/fonts/afm/public/marvosym and texmf-dist/fonts/type1/public/marvosym
<bavier>err, actually, the afm and type1 and generated from the truetype "source"
<apteryx>OK. I think it'll be better to use ctan as a source, since it seems any other font type is derived from *.ttf
<apteryx>as can be read here:
<apteryx>I'll try downloading the fonts and regenerating the extra formats using the shell scripts under source/
<bavier>yeah, if we can run those scripts from texlive, it'd make for easier packaging on our side
<bavier>reminds me I need to try to finish up my texlive-generic-xypic package
<ng0>d1rewolf: wrt patch application time it depends. I think most security patches are applied very fast, regular patches can take a long time depending on time people have on QA
<ng0>d1rewolf: essentially that is what you mean. when a security bug is found, how fast is it fixed upon suggestion or patch sent in
<ng0>for example our icecat package could be considered more up to dat ethan the original sources - we have a long series of patches taken directly from firefox for this
<ng0>it usually depends on the packages and people looking out for them.
<civodul>Hello Guix!
<civodul>hey mange
<civodul>how's everything?
<mange>Pretty good, thanks! How are you?
<civodul>i'm good!
<civodul>i'm glad i found out the story with eudev
*civodul goes grab coffee
<mange>Yeah, I'm glad you figured it out, too! I had wondered whether it was related to the system* definitions, and so I replaced the system* reference in the service with (@ (guile) system*), but I don't think that fixed it. I haven't actually checked that you fix works for me, but I'll try it out tonight.
<janneke>Hello Guix!
<civodul>hey janneke!
<civodul>mange: yeah the #:replace thing behaved badly
<mange>I read the Guile manual about #:replace and it sounds pretty dangerous. Surely it should be up to the importing module whether it functions as a replacement, not the exporting module.
<civodul>not necessarily
<civodul>sometimes you want to provide features that extend what Guile provides
<civodul>but yeah, it remains somewhat dangerous
<mange>I understand the rationale, but I think having the provider declare "this function is equivalent to a core function" will invariably have edge cases, and if that import happens silently (rather than the importing module requesting it) then it can happen accidentally.
<janneke>hi civodul!
<mange>Anyway, we don't need to debate the Guile module system in #guix.
<civodul>mbakke: i just noticed that the evaluation at failed
<civodul>mbakke: probably we need to merge master into core-updates and start from there (i fixed the issue in commit 13512e1b8f63b4d8fcb188fac992aa390149fe65)
<snape>hi guix!
<civodul>hello snape!
<nly>How can I see (guix packages) in emacs?
<divansantana>nly: guix package -i emacs-guix then M-x guix-info
<nly>For example I want to see what `define-module` and `#:use-module` do in (define-module (gnu packages hello) #:use-module (guix packages))
<nick-12398121231>Hi everyone, I am trying to extract a rar archive, but I can't find the relevant utility or tool to do so, I believe the normal approach for other distros is to use unrar, but I can't seem to find it. Does anyone have any suggestions?
<nly>Try p7zip
<nly>guix package -i p7zip
<nly>The command is 7z
<roptat>hi guix!
<nick-12398121231>Yeah I have tried using 7zip but it does not work and rar does not appear in the list of supported filetypes output by "7z i". I have also tried installing file-roller (aka gnome archive-manager?) but that throws an error that is supposedly fixed by installing unrar.
<civodul>nick-12398121231: i believe the problem is that there are no maintained free implementations of "unrar" (there used to be one but it's unmaintained and in rather bad shape, IIRC)
<civodul> <- will we finally build stuff on Jan. 1st, 1970? :-)
<nick-12398121231>Ah ok, good to know at least. I may have to risk it and manually package it this time. But thanks for the heads up.
<nly>found the definitions I was looking for, but I was expecting emacs to be aware of all the things in a scheme file.
<nly>No, I forgot I was in *info* not in scheme file
<mbakke>civodul: Do you think it's safe to start a core-updates eval on Hydra?
<g_bor>hello guix!
<g_bor>I have two questions. 1. How to proceed with Outreachy? 2. Anyone going to the Reproducible Build Summit?
<d1rewolf>ng0: cool, thx. Are there docs covering the okay review/approval process?
<thorwil>hello guix!
<thorwil>i'm trying to use substitute* to replace a line tha starts with "GIMP_LIBDIR = ". neiter "GIMP_LIBDIR = .*" nor "GIMP_LIBDIR = .*$" seem to do the trick. so what's the right regexp?
<ng0>d1rewolf: if it's not in the manual, ask people
<thorwil>actually, "GIMP_LIBDIR = .*" is right, though it swallows a newline i have to add to the replacement 0.o
<janneke>g_bor 2: i would like to go but haven't looked if i can make those days free
<civodul>hey mbakke!
<civodul>mbakke: like i wrote, we can do it if/once the relevant commit has been merged
<mbakke>sup civodul
<civodul>lemme know when you think it's ok!
<mbakke>core-updates has been merged already! :)
<mbakke>civodul: I'll push the magic button then.
<civodul>seriously? :-)
<mbakke>I mean that the missing commit was merged :P
<civodul>cool :-)
<civodul>so yes, go ahead
<mbakke>It's alive:
<janneke>oh, guess i'll rebase wip-bootstrap on the new core-updates
<janneke>--system on guix graph, nice
<reepca>So I just recently rebooted this system and now there's this really weird behavior where moving the mouse accelerates the cursor instead of just moving it. So I can leave the mouse perfectly still and the cursor keeps flying across the screen.
<reepca>Anyone ever encounter anything like that?
***rekado_ is now known as rekado
<reepca>but only on the horizontal axis for some reason
<efraim>reepca: is it a macbook?
*janneke pushes rebased wip-bootstrap
<reepca>efraim: nope, pretty generic desktop.
<efraim>interesting, its a known bug on macbooks
*efraim runs afk for a few minutes
<ng0>is rb-general@ the list where we share reproducibility patches with other OS'? upstream probably rejected my patch as they work on the next major version (and new codebase) of the software already.
<katco>if i need to send a revision to a patch, do i send a diff of master -> change, or a diff of patch N-1 -> patch?
<janneke>does this guix offload test failure sound familiar? guix offload: error: build failed: implementation cannot deal with > 32-bit integers
<roptat>weird, I'm downloading the source of a package and it's stopping midway, resulting in a hash mismatch (instead of a network error)
<roptat>I've tried multiple times and it's failing at random points in the file...
<g_bor>Hello guix!
<rekado>g_bor: hello!
<rekado>g_bor: what do you think about extending the Outreachy project description a little?
<rekado>g_bor: I think it would be good to have some clear milestones and to mention that the goal is a collection of ~3 min videos.
<rekado>(otherwise it might be overwhelming)
<g_bor>Fine, let's do that. Also, do we have to do anything else right now, or in the near future?
<g_bor>I guess that videos regarding installation would be about the first milestone. Wdyt?
<g_bor>I was thinking along the lines: installation, daily tasks, other useful/clever tricks, packaging. How does that sound?
<g_bor>I think that a minimal deliverable should be pictures, and textual script, both with timing data. Audio would be nice, but not requied.
<rekado>g_bor: it would still be nice if we had more co-mentors for this project. That’s the only thing we would need to do right now.
<rekado>other things we should do now is to help applicants make their first contributions.
<rekado>I agree about the deliverables.
<rekado>It would be good if the intern prepared something like a Makefile or an executable script that would render videos from a subtitle file, an (optionally translated) audio track, and a slide show.
<rekado>script with timing data sounds a lot like a regular old subtitle file, actually
<rekado>for the videos I thought that it might be useful to get inspiration from
<rekado>these are very short demos of neat things that one would otherwise not know about.
<rekado>our videos should not be narrated screencasts like that, but I think it’s nice to have videos that focus on just one thing.
<rekado>e.g. roll-backs
<g_bor>yes, a subtitle file is ok.
<nly>When running (package-name hello) in guix repl I get: warning possibly unbound variable `package-name`
<nly>Not `package-name` but `hello` is missing
<pkill9>nly: how do you open a guix REPL?
<civodul>g_bor: i'll likely attend the R-B summit, and was wondering whether to have a Guix meeting the day before is several of us can come (i could probably arrange a meeting room)
<civodul>arf, too late
<nly>Using emacs-guix package, I run M-x guix then interactively enter the repl
<civodul>sneek: later tell g_bor i'll likely attend the R-B summit, and was wondering whether to have a Guix meeting the day before is several of us can come (i could probably arrange a meeting room)
<sneek>Got it.
<mbakke>Hmm the new WebKitGTK requires GCC 6 or later to build, but then dependents fail to link with errors such as:
<mbakke>/gnu/store/l4sc9zjvqai3l7p4mbywh7kk97c2fv5y-webkitgtk-2.22.1/lib/ undefined reference to `__divmodti4@GCC_7.0.0'
<janneke>sneek: later tell civodul: guix meeting before r-b would be nice (if i can manage to be there)
<sneek>Will do.
<janneke>sneek: botsnack!
<mbakke>janneke: I'm going to try updating to GCC 7 on wip-bootstrap real soon.
<janneke>mbakke: whoa!
<janneke>that would be nice
<divansantana>silly q. Whats the command to suspend it guix. I can't find it. Would prefer to suspend while open then close the lid to later find it overheated. :)
<pkill9>divansantana: `loginctl suspend` i think
<janneke>mbakke: i've been adopting the habit of hard resetting wip-bootstrap, i have no plans to do so but if we do we should co-ordinate
<mbakke>janneke: It's OK, I'm no stranger to rebasing ;-) I doubt I will have to do changes "down the chain" anyway.
*mbakke build hello on wip-bootstrap
<janneke>mbakke: wip-bootstrap was over a year old, with 209 i reset it quite a number of times
<mbakke>janneke: Much appreciated! Really impressed that you squeezed it down to just a handful commits.
*janneke is very happy that at least four people now have built/are building wip-bootstrap!
<janneke>mbakke: tnx ;-)
<janneke>interestingly, the rebase i did this afternoon on the new core-updates, did not trigger a rebuild of `hello'
<mbakke>janneke: core-updates is 'frozen', so no big changes from here on.
<janneke>ah i see, /me is rather green wrt the release/core-/update process
<RetardedOnion>does anyone use guixsd for a website with php, mariadb n stuff?
<g_bor>hello guix!
<sneek>Welcome back g_bor, you have 1 message.
<sneek>g_bor, civodul says: i'll likely attend the R-B summit, and was wondering whether to have a Guix meeting the day before is several of us can come (i could probably arrange a meeting room)
<g_bor>civodul: fine, I intend to be there
<ng0>is this in HH again?
<ng0>oh.. sorry. hamburg
<g_bor>is someone coordinating r-b on behalf of guix, or should I contact them directly?
<rekado>ng0: in Paris.
<ng0>oh, ok
<rekado>sneek: later tell civodul mumi now shows changed message subjects
<rekado>sneek: botsnack
<ng0>close enoughgh :)
<divansantana>pkill9: brill. Thanks!
<janneke>g_bor: my agenda is free for R-B, same question here wrt "registration"
<g_bor>rekado: i will have a lool at expanding the project description tomorrow.
*vagrantc hopes to make it to the r-b summit
<roptat>it's ok to break some packages in intermediate commits as long as they build in the last commit, right?
*janneke hopes to meet vagrantc again
<g_bor>roptat: what is the status of the postgres extension patch?
<roptat>g_bor: waiting for your comment :)
<g_bor>also, I did not try yet if hstore works?
*divansantana attempting to compile chromium. It's failed a few times. This time it's verbose. Greatful to mbakke for the work for this. That manifest looks impressive.
<g_bor>oops. looking at that now
<roptat>I haven't tested hstore
<g_bor>roptat: this look really good, I would like to test it tomorrow, and have a look at the doc changes.
<mbakke>janneke: Interestingly gcc-cross-boot0 (GCC7) built fine without a hacks I needed previously -- although it fails at the install phase (like in that libstdc++ comment).
*g_bor trying to get an osm database and tileserver up and running
<janneke>mbakke: \o/
<janneke>good news and can be so time consuming to fix things like these
<mbakke>janneke: I'll dig into the Makefile/install issues.
<janneke>mbakke: hmm, could it be that previously the a %bootstrap-gcc-4.7.4 compiler was used?
<mbakke>janneke: Yes I think so.
<janneke>now, gcc-mesboot is used, which is gcc-4.9.4
<mbakke>Nice :-)
<janneke>well...i didn't manage to build gcc-boot0 at all with gcc-4.7.4
<janneke>so in the end i added an extra gcc-4.9.4 to the mesboot stage
<janneke>however, if this solves a problem with gcc-boot0, that's great :-)
<g_bor>janneke: I have seen that there was progress on the x86_64 line, but do not know the details.
<janneke>g_bor: i managed to graft the x86_64-linux GuixSD bootstrap onto the i686-linux mesboot!
<janneke>most recent commit on wip-bootstrap
<janneke>g_bor: civodul and you inspired me to look at that...i got the impression that you were very busy the past days so i started looking myself, it proved relatively easy
<g_bor>wow, that is nice. I am on mobile now, but will have a look
<janneke>yeah -- i would have guessed that it might be weeks of work, also on Mes C Library -- but you were right!
<g_bor>oops. I am low battery... See you later
<mbakke>janneke: Which version of libtool are we using?
<mbakke>Possibly one bundled in GCC? Hmm.
<janneke>mbakke: no idea!
<efraim>rekado: python2-scikit-learn probably shouldn't return #t from the test phase, there's already an invoke
<mbakke>I see this in the build log: libtool: link: (cd ".libs" && rm -f "" && ln -s "" "" --- yet no to be found.
<janneke>mbakke: interesting...have you seen my 'libtool-workaround phase in gcc-boot0?
<mbakke>janneke: I saw one in libstdc++.
*mbakke checks
<mbakke>janneke: Never mind, yeah I saw that and thought it was in libstdc++.
<mbakke>Ah, libstcdc++ has another hack :-)
<janneke>yup -- ugh :)
<georges-duperon>Hi! guix build --check hello, hangs in the tests for guile (no CPU activity, plenty of free RAM, plenty of free disk space). Is this a known problem?
<georges-duperon>It hangs at this point: Testing /tmp/guix-build-guile-2.2.3.drv-0/guile-2.2.3/meta/guile ... with GUILE_LOAD_PATH=/tmp/guix-build-guile-2.2.3.drv-0/guile-2.2.3/test-suite
<divansantana>mbakke: should chromium from the channel combile with the latest guix pull? Or do I need to check out a particular branch. Currently after doing guix pull and install it fails with
<bavier`>trying to create a "guile2.0-gcrypt" package, notice that "package-for-guile-2.0" is not exported from (gnu packages guile), no problem, just define-public, nope, circular module dependencies...
<bavier`>ugh, and trying to define it anywhere else also leads to "unbound variable" errors
<roptat>is there a procedure to remove a character from a string? I want "7.06" -> "706"
<bavier`>roptat: maybe not the best, but works: (string-join (string-split "7.06" #\.) "")
<mbakke>divansantana: I think the actual error message was lost in that paste.
<mbakke>How much memory do you have?
<bavier`>roptat: or, after reading the manual: (string-delete #\. "7.06")
<roptat>bavier`: nice, thanks :)
<ng0>divansantana: 8 GB RAM + at least 9 GB swap will make the build not run out of memory
<ng0>I compile chromium on 8GB RAM + 20 GB swap
<ng0>if oom was the issue here, i did not read the link
<divansantana>mbakke:16G. Hmm. Maybe my compile server ran out of space. Let me try again.
<divansantana>ng0: cool ta
<mbakke>divansantana: It could be that 16GiB is not enough, try adding some swap.
<divansantana>mbakke: cool, thanks
<jabranham>Just found out about the berlin build server. Any reason *not* to enable it as a substitute server?