<jlicht>what was the amount of packages that decides whether an update goes to master vs core-updates? <Apteryx>rekado: berlin.guixsd.org has been steadily serving substitutes to my machine; great work & thanks! :) <mwette>hi all. I'm trying to build guix 0.13.0 on Centos 7.3 and getting, during guix/tests/http.go, a fail with backtrace that says: <mwette>ERROR: In procedure private-lookup: No variable bound to make-vector in module (guile) <mwette>I installed guile 2.2.2, and many other latest. <mwette>Any idea what could be the problem? <brendyn>finally updating after 3 months is proving to be a nightmare <mwette>Oh well ... it looks like `make install' is running along OK so far <Apteryx>brendyn: what problems are you hitting? <brendyn>just mysteries. i reconfigured and had gnome with network manager, then reconfigured and it somehow went back to having wicd <brendyn>like it downgraded back to where i started somehow <brendyn>root no longer has access to guix, except when i use sudo there is one version of guix, and without sudo references a different version <brendyn>so now im running /gnu/store/...guix.../bin/guix pull directly from the store on what appears to be the latest version i have <bnw>I'm getting "ERROR: X.509 certificate of 'git.savannah.gnu.org' could not be verified", what's the preferred way of working around or bypass this? <bnw>still not sure how should I do ***jonsger1 is now known as jonsger
<efraim>Should GNOME-desktop have udev support? I don't use it, just saw it go by while buildig <efraim>should gnome-desktop have udev support? <brendyn>so for some reason when i do /gnu/store/.../.../guix --version as my user, i get 20170802.11, but as root i guet some long hash. it's directly calling the same guix version <efraim>brendyn: when was the last time you ran guix pull as root? <efraim>alternatively, you could run `sudo -E guix --version' <brendyn>just a minute ago. but before that it's been 2 months or so <brendyn>root doesn't have things like `which' and `whereis' <brendyn>i pulled, reconfigured and rebooted. but now guix pull doesn't work on my regular users <brendyn>it errors sayinng mkdir doesn't have sufficient permissions <bnw>guix package -i guix got me an older guix version? Is this normal? <bnw>ACTION just messed around with guix, since it is now much faster to install guix package (x KBps to xxx KBps, sometimes even reach 1.x MiB/s now <civodul>"guix package -i guix" installs the Guix snapshot that's defined in your current Guix <civodul>so it's necessarily older than the current one <civodul>on GuixSD use "guix pull && guix system reconfigure" to upgrade Guix and the rest <bnw>And the later would resulted to X509 certificates error <bnw>Then I run guix package -i nss-certs, got an error with python 2.7.2 (but I forgot the exact error msg) <bnw>I'm currently running guix package -i guix --fallback <bnw>civodul, no. On Debian <civodul>ah wait, looks like that's what you were trying to do <civodul>hmm, what was the python error then? <bnw>The python error appeared when I run "guix package -i nss-certs", guix suggested me to run using --fallback option. So I did, I saw it compiled python 2.7.2 <civodul>weird, i do see substitutes for Python 2.7.13 <bnw>X509 error appeared again when tried pulling snapshot v0.13.0 <civodul>bnw: are SSL_CERT_FILE & co. correctly set? <bnw>Since "guix pull" didn't complained, I thought it would fetch the one in the git repo <bnw>Then I run guix package -i guix and got guix 0.11. It was a surprise. <bnw>civodul, I didn't set "SSL_CERT_FILE & co." <bnw>I did "X.509 Certificates" part in the manual, (failed to install nss-certs, but success building nss-certs from source I think <civodul>what's the exact error that you get? <bnw>civodul, I will try to find out after "guix package -i guix --fallback" finished. <catonano_>I wonder if anyone would suggest me anything about how to troubleshoot my Postgresql issue (I posted on the dev mailing list about it) <bnw>btw, is guile-2.2 included in guix? I couldn't find it when searched. I could see there was guile2.2-json or similar <civodul>bnw: yes, see "guix package -A guile" <civodul>catonano_: you did get some feedback, didn't you? <civodul>ACTION is pretty ignorant about all things SQL <catonano_>civodul: I opened a new thread yesterday night <bnw>Only guile 1.8.8 and 2.0.12 presented in "guix package -A guile". Maybe my guix are too old. <bnw>"guix package -i guix --fallback" waited quite some time at "PASS: 1bit-mutex 2 /glib/1bit-mutex/pointer" <civodul>could you use paste.lisp.org, which is accessible to Tor users? <bnw>Oh, didn't know that <bnw>ERROR: Throw to key `gnutls-error' with args `(#<gnutls-error-enum Error while reading file.> set-certificate-credentials-x509-trust-file!)' ***fr33domlover is now known as fr33domlover1
<catonano_>civodul: I just forcefully emptied the /var/lib/postgres/data folder and now it runs. So it seems ***fr33domlover1 is now known as fr33domlover
<bnw>get around it with changing the https link to http. p_q <civodul>bnw: you downgraded guix, as we discussed earlier, which is not going to fly <civodul>you need to "guix package --roll-back" <civodul>also, what's the error that produces the above gnutls-error? <civodul>it's important to always paste both the command and its output <civodul>otherwise we may misunderstand each other :-) ***fr33domlover is now known as fr33domlover1
***fr33domlover1 is now known as fr33domlover
<bnw>Didn't know this bypassed the CA validation ***fr33domlover is now known as fr33domlover1
***fr33domlover1 is now known as fr33domlover
<bnw>running guix (GNU Guix) 20170911.09 now <bnw>Why are all guile version named "guile"? How should I install specific version? <bnw>I went back to gen 3 and tried install nss-certs again. This time that python error didn't appeared. Maybe it's some bug that's been fixed? <civodul>without more details, it's hard to tell what the bug is and whether it was fixed <bnw>civodul, nice @2.2.2 <bnw>I didn't look at detail of guix manual, just searched and jumped around <bnw>got "find-files: /gnu/store/p0ygwmwspjpn4pwnla3p26n0xrypzdxv-python-2.7.13/share/man/man1/python.1: No such file or directory" when "guix package -i python@2.7.13" <bnw>Although by listing gens, I could see a new gen and python is installed. <bnw>I deleted previous gen 4 and 5, installed nss-certs and python 2.7.13, and got new gen 4 and 5, will gen 6 be overwrite if I install something new? Tempted to try :-) <bnw>got warning: collision encountered: /gnu/store/wak3m4kdkgw010qn1ksnqlggvklp4b24-gmp-6.1.2/share/info/gmp.info-1.gz /gnu/store/6k08nkddnrb15h5pwp1s0fa94mr1qas9-gmp-6.1.1/share/info/gmp.info-1.gz <efraim>civodul: what if someone modifies their store in place to serve up malicious unverified substitutes? <civodul>efraim: that's ok! 'guix substitutes' tells the daemon what the hash should be, and the daemon checks that that's what it gets <civodul>so this part is the same as what we currently have <efraim>So it checks the hash after it downloads the substitute? <civodul>efraim: now, you're welcome to share your questions and concerns on the list! <ng0>civodul: I had some time to wait on a support request / action, I collected sizes on noto. Will send it in a mail as soon as the last 3 archives finish <ng0>first comment on cjk tagged tarball size: wtf. <ng0>"unknown time remaining 1.0GiB" <ng0>in parallel this is the git checkout with all of its history (cjk only): Receiving objects: 35% (217/609), 753.61 MiB | 422.00 KiB/s <civodul>ng0: i just commented on the issue, let's keep the discussion on debbugs <ng0>I agree, I just wanted to express my reaction on the size of most of the source archives. wow <jlicht>thanks apteryx[m] for answering my question from last night ;-) <jlicht>Is `substitute*'-ing runtime dependencies preferred to using `wrap-program' for runtime dependencies? <apteryx[m]>civodul: interesting to see s vulnerability different than the usual C out of bound thing... Looks like its caused by eval? <civodul>apteryx[m]: it's about interpreting "enriched text" in message-mode, the thing used by email clients <Apteryx>Should I report this kind of thing: collision encountered: /gnu/store/zkrfy7yd05v6d9614hqyc7s1178mc8r0-inkscape-0.92.1/share/icons/hicolor/icon-theme.cache /gnu/store/l3db81gi51d0j8q8f35fq2sra2c3c6x4-gnucash-2.6.17/share/icons/hicolor/icon-theme.cache /gnu/store/62956n8habdbx6h3yin5vvsrbx02wbmj-vinagre-3.22.0/share/icons/hicolor/icon-theme.cache ? <Apteryx>Well, there's alss xdg-mime-database and shared-mime-info clashing. <civodul>Apteryx: these are "known annoyance", but maybe if you report it we'll get around to fixing it at last :-) <jlicht>What are some ongoing efforts on `guix pull' using quite some RAM? I used to have a decrepit eeepc running some services in my home network, but guix pull either crashes or is very slow (with a big swap file) <efraim>iirc andy and ludo say its a guile issue. In the mean time I'm running from git <jlicht>if only I could offload to my much faster desktop machine ;-) <jlicht>but that is definitely a workable solution to my issue. Thanks efraim <Apteryx>jlicht: I plan to do just this (offload to my desktop)! <Apteryx>Has anyone a small function that returns the debbugs web page URL of the bug I'm looing at in debbugs-gnu interface? <Apteryx>Eh, I might just hack it, it looks trivial. <Apteryx>so just prefix the bug number by that static part ;) <jonsger>Apteryx: maybe we could have a small bot like sneek who do that in irc <lfam>Apteryx: The master / staging / core-updates rebuild limits are 300, 1200, 1200+, unless the guideline was recently changed <lfam>We should not push changes that require >300 rebuilds to the master branch <lfam>Also, Apteryx, I think it's better to use URLs like <https://bugs.gnu.org/26877>, since they will probably last longer. The other URLs "hardcode" the Debbugs implementation details which are subject to change <lfam>I like this recent change re: subsitute servers <lfam>It does open people up to bugs in the code that is invoked when substituting and hashing the downloads, but that's not very different from how we download package sources <civodul>right, and that code that ensures the actual hash is as advertised is already there, and is already a crucial element <lfam>I'm wondering if there is a "canonical" source for the berlin.guixsd.org signing key. I see it in maintenance.git, but that's not very discoverable <civodul>see the "substitute, corrupt output hash" test in tests/store.scm <lfam>It would be nice to put it on the web page of berlin.guixsd.org, but it seems like that is redirecting to mirror.guixsd.org <civodul>lfam: it's bayfront.guixsd.org.pub, currently in the repo <lfam>Ah, the same key is used in both places? <civodul>but actually, with the new substitute code, you don't need to register the new key <lfam>Right, but I'm also interested in the things built by berlin <lfam>And maybe they aren't reproducible, I dunno <lfam>Changing the subject, I'm hoping to package some software that might (not totally sure yet) really want to have a .git repo available while building. <lfam>I'd hate to have to mirror a tarball fo the full Git repo, but I don't see another way without breaking the functional model <civodul>lfam: you mean it needs the .git directory while building? <lfam>Yes, unless I can find a way to work around it <civodul>perhaps we could see what it needs it for <lfam>Yes, I need to get deeper <civodul>maybe just to generate a version string <civodul>in which case we could do that off-line <lfam>I've been going back and forth between the Julia and Go build systems. Each time I get stuck, I've learned something I can use for the other one <civodul>sometimes it's good to switch to something simpler to keep motivated :-) <jlicht>Apteryx: How can one offload guix pull (or equivalent shenanigans /w git)? <Apteryx>Actually I'm not clear on how offload works (yet), what I was thinking of doing was to use "guix publish" on the desktop machine which would be installed with the same (or a superset) config as my laptop. There would be a cronjob doing guix pull & guix package -u regurlary so that all the packages I use would be present and up-to-date on the desktop, ready to be fetched as substitutes from my laptop. <bavier>lfam: iirc davexunit struggled with ruby packages that want to have .git directories while building <lfam>Ah, interesting news, bavier. I'll have to ask him for the details <efraim>Apteryx: sounds like a use case for cuirass <bavier>lfam: I suppose though the solution would depend, as civodul suggested, on what the git repo is being used for during the build <lfam>Yeah, and I haven't figured that out completely yet <lfam>I'm still trying to avoid needing it <davexunit>lfam: IIRC the ruby build system depends on git and creates a git repo as an initial build step <Apteryx>lfam: ohh, thanks for correcting me about the change limits. I must have read that 1800 from civodul on a core-updates thread and thought it was about the mainline master... <Apteryx>lfam: thanks for the URL format. More concise too! <jlicht>regardless of the specific limits, sqlite updates definitely go to core-updates (3800 according to `guix refresh -l <...>') <jlicht>what are the contribution guidelines for core-updates? I hope I am not expected to build and test ~3800 packages before sending my patches o.O <lfam>The core-updates branch may not even build right onw <lfam>As long as the change seems sensible, you can send it in for review <lfam>That branch just collects patches for a while, then we try building it and iron out the kinks <efraim>I normally build out to the package i'm updating <jlicht>that was what my trusty pc has been doing this afternoon ;-) <jlicht>but my patch will just update two version strings (and hashes), quite trivial really <janneke>davexunit: i'd like to uncarefully label it as: `npm is a very popular build system' <jlicht>davexunit: wait what. What are these people talking about? <janneke>if you do not understand guix/nix's essential features and junk them then yeah, things can be "more simple" <jlicht>maybe this is the Emacs-stockholm-syndrome talking, but to me, being unable to use your day-to-day language for building complex systems seems like a pretty big drawback :S <lfam>HN is a great site for neophytes to reinvent entire fields of study from scratch in a couple hours <bavier>davexunit: a good portion of the comments can be summarized as "I have no idea what I'm talking about, but why is software complicated?" <jlicht>bavier: that is still a valid question to always keep in mind though (after the ", but") <jlicht>and in a sense, having reproducible builds simplifies reasoning about software a lot. It's just that the mechanism to achieve this is non-trivial <bavier>jlicht: indeed :) but not constructive in this HN thread <davexunit>the suckless mindset has a wide reach, it seems. <lfam>The problem with those HN commenters is that they weren't actually interested in the "but". They just wanted to have their naive ideas validated <jlicht>It might make for an interesting FAQ-like entry "Why is guix so 'complicated' compared to <insert whatever non-equivalent build-tool/ad-hoc package manager du-jour here>?" <lfam>Maybe... but all the others are also super-complicated when you look closely at them ;) <efraim>how much ram does monero need to build? <efraim>c++ just crashed on me with 4GB ram and 4GB swap <bavier>does the guix/packages webpage need some attention? hasn't been updated since august 26 <catonano>I want to post a quite long piece of code. Can I paste it in the body of the message on the mailing list or should I paste it in paste.lisp.org ? <lfam>catonano: It's better on the mailing list <kahiru>hey, I just spun up a vm using the provided guix vm image. Is there a config.scm for that image anywhere on that vm or do I have to create one completely from scratch? <catonano>I misspelled their name amd yet they understood o_O ***luto__ is now known as luto
<catonano>I'd like to reply to the Cyril Roelandt who sent a patch series to the dev mailing list bt I'm not sure exactly what to write to them. Maybe there is some place that has not been updated yet and still instructs people to send patches to the dev mailing list ? <marusich>Is there a good resource for figuring out why a given website "doesn't work" in Icecat? <marusich>I always find it difficult to comprehend why a site that works in Firefox fails to work in Icecat even after I have disabled the blocking mechanisms and enabled the javascript for the website in question. I suppose there are more detailed things I am unaware of. <catonano>marusich: because IceCat is based on an older version of Firefox <jonsger1>marusich: I had also huge problems with Icecat (don't use it anymore). you could maybe go to about:config, klick on "status" and watch out those preferences who have status "modified" <marusich>It's such a bummer that a lot of websites I want to use, like my banking website, don't work with it (or even the GNOME browser, "Web") <marusich>jonsger1, I appreciate the suggestion, but that sounds tedious, and I wouldn't feel super comfortable nullifying the changes that the Icecat devs have made to try to make the browser more freedom/privacy friendly. <marusich>Maybe if there were a way to do that on a per website basis? <jonsger1>marusich: yes, than have fun with broken websites <civodul>marusich: FWIW, i've never seen a web site that "doesn't work" with IceCat, though i've had to turn off LibreJS <civodul>i use "Web" only occasionally but it seems to be okay too <civodul>dunno, maybe i only visit simple web sites ;-) <bavier>I've not had troubles with icecat either <bavier>I prefer it with privacy-badger add-on over "Web", whose "block ads" preferences option doesn't seem to work for me <Apteryx>hey marusich, I think the single settings which made the biggest change for me was allowing cookies/javascript for 3rd party (coming from other domain names than the one you are visiting). This was a simple option in the UI (not in about:config) if I recall correctly. Now everything works! <Apteryx>(well this and disabling LibreJS of course)