***jonsger1 is now known as jonsger
<bnw>Can someone provide more info on requirement for the repo, such as size, which upstream repo should they mirror from etc. Thanks. <Apteryx>Hmm. Anyone got past this problem recently? "Makefile.am:458: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS" when attempting to make guix from git in a guix environment. <Apteryx>I've rerun ./bootstrap && ./configure --localstatedir=/var but it didn't improve the situation. <Apteryx>Hmm, maybe "make clean" helped... it's building stuff now. ***kelsoo1 is now known as kelsoo
<bnw>What is the preferred upstream repo if one wants to mirror GuixSD? And how much space does GuixSD upstream take currently? <Apteryx>To give you an idea, my local git checkout ".git" folder weights 241M. <bnw>Apteryx, Thank you. I'm looking into it. <bnw>Apteryx, I think the GuixSD should be larger since it contains all the thousands of pre-built packages. <Apteryx>bnw: You are confusing git repo & package server. <Apteryx>The git repo only holds textual recipes of the packages, not built objects. <Apteryx>Or maybe you want to mirror what's served by mirror.hydra.gnu.org? <bnw>What I want to mirror (to mainland China) is GuixSD so that people inside mainland can install GuixSD faster. <bnw>Not me mirroring. But I am asking USTC or/and TUNA to mirror the GuixSD repo. <Apteryx>My knowledge pretty much stops there unfortunately. I believe you'd have to duplicate the hydra setup or its intended replacement, cuirass. <Apteryx>Otherwise there seems to be a lower level mechanism which allows sharing guix packages over an HTTP server (guix publish). But you'd still need something to periodically pull the latest guix & build (and retain) as much as it can, which I believe is what hydra & cuirass do. <Apteryx>I'm sure someone more knowledgable will chip in! <bnw>Apteryx, I'm curious about whether there is a complete list of GuixSD substitute repo. If there is one. Maybe people from USTC and TUNA can choose from the nearest/fastest mirror for the first mirroring action. <Apteryx>Oh right. I was forgetting you'd simply like rsync'ing the full thing. I'm not sure if the servers available offer such an interface, but it's worth asking. <bnw>Apteryx, good night. :-) ***Piece_Maker is now known as Acou_Bass
***ShalokShalom_ is now known as ShalokShalom
<bnw>Hi civodul, which is the preferred upstream repo URL if one wants to mirror GuixSD? And how much space is required? <bnw>Is there a list of all available mirror sites on the guix project site? <civodul>BTW, "repo" makes me think of Git repos <thomasd_>So having just run `guix gc` in my xfce4 desktop, I have a question/suggestion for improvement :) <civodul>i'd call these "substitute servers" or something like that instead <efraim>i found the flag --disable-build-date for mpv, looks promising <thomasd_>the "launcher" desktop items in ~/.config/xfce4/panel/ contain references to store items, like /gnu/store/...-exo-0.10.3/bin/exo-open, which are subject to garbage collection <thomasd_>I think they could be replaced by /run/current-system/profile/bin/exo-open <civodul>yeah, either that or just "exo-open" <civodul>thomasd_: could you file a bug for this? <civodul>which doesn't mean you shouldn't try fixing it as well, mind you ;-) <civodul>hopefully this kind of issues is relatively easy to fix <efraim>nope, result differs, but at least its a step <civodul>bnw: if these orgs can afford it, i'd even suggest building things for themselves <civodul>that would avoid making hydra.gnu.org a single point of failure/trust <thomasd_>civodul: I expect it can't be that difficult. Will definitely have a look. <bnw>BTW, is there a script former mirror site used to sync the content that they can used as a reference? <civodul>efraim: glad you're looking into it! <efraim>its the excuse I use to watch programs build :) <civodul>bnw: no, as i wrote earlier, we currently don't have a way to rsync things; instead we use nginx as a cache <bnw>civodul, Maybe, USTC upgrade their hardware a couple of weeks ago. <civodul>it runs Cuirass (to build things) + 'guix publish' <bnw>civodul, How much space is required now? <civodul>bnw: for all 4 architectures, mirror.hydra.gnu.org uses 1.3T <civodul>and that's also with maybe 3-4 months worth of builds <bnw>civodul, Wow, that's not small size/workload. :-) <civodul>but if you have just one architecture, it's more reasonable <efraim>what about an nginx mirror? it'll try to hit the mirror, fall back to hydra, time-out, and then when you try again the mirror will have cached it <civodul>yeah, that's the first option we discussed <bnw>civodul, How about amd64 alone? <civodul>bnw: no concrete figures, but you could more or less divide by 4 i guess <efraim>although from that is 15-30 GB of source files <civodul>efraim: BTW thanks for updating glibc and grep in core-updates <civodul>i think we should start building it soonish <civodul>there's one last thing i'm considering for that branch, which is reproducible Guile <efraim>Sounds good. I wanted to get aarch64 in, but it can wait <efraim>when I checked forever ago, bootstrap guile and gcc-4.9.3 weren't reproducable <civodul>re aarch64, it may still be possible actually? <civodul>i mean, let's try to get as much of your changes in there <civodul>csanchezdll: what's up with PPC? :-) <efraim>i'll try tonight to send what I have to the list, some of it is ready <efraim>last I heard csanchezdll was going to rebuild the bootstrap binaries, so I assume the same issues I'm having, with "something wrong" with bootstrap bash <csanchezdll>civodul: sadly not much lately, since christmas I have been quite busy :( <csanchezdll>efraim is right, and I have a kind of tutorial/log of what I did incluing bash debugging and such <csanchezdll>tried to upload it to a git-pages created blog, but something went wrong and I have not had time to look at it <rekado>CharlieBrown: after reading through all the messages I had missed I decided that #libreboot is not a place I'd like to be at. <csanchezdll>I work on a small tech startup and we have a new ASIC tapeout in a month, hopefully after that I will have some time back for hacking hobbies ;) <civodul>csanchezdll: woow, i can imagine you already have enough pressure, indeed! <efraim>all I know is that my bash from june worked, and my one from october doesn't, so its somewhere in between <csanchezdll>efraim: the "something wrong" can be related to the problem I posted in the list regarding the getcwd failing? <efraim>that would be an obvious thing to check <efraim>i thought all of those got committed <csanchezdll>could be, I posted what I think was the cause and the fix, but "evidence" was not enough and I was the only one getting the problem so I guess it just slipped away <csanchezdll>I made some further investigations which confirmed the cause, which is basically: <csanchezdll>bash includes its own copy of getcwd which fails for bind mounts, because it tries to detect mount points by comparing the device field of some structure (I don't remember the details) <csanchezdll>it only happens for cross-compiled bash'es, because glibc getcwd is used usually, and that one works ok <csanchezdll>but when cross-compiling, configure cannot check whether getcwd works correctly so it makes bash uses its own (buggy) version <csanchezdll>I sent a patch with worked ir around by forcing configure to asume system getcwd works (which is true in our case becase we know we are using glibc) <efraim>i'll find the patch and toss it in my core-updates tree and rebuild the aarch64 bootstrap binaries, hopefully it won't have to build up and back down <civodul>i remember hitting that getcwd issue long ago in another context <civodul>i think it was a problem with the cross-compilation configury <civodul>did you try looking it up in the ML archive? <efraim>my search for getcwd came up with the mingw patchset also <civodul>we should apply it if it was not applied <civodul>it can even go on master i think, because it seems to only touch the cross-compilation part <csanchezdll>I have a (not very well edited) version of the debugging process described in text mode, my plan is to publish in on blog form once I get some time <civodul>take your time, you can polish it as time permits <civodul>efraim: could you apply the patch (after checking it does not trigger a full rebuild)? <efraim>civodul: sure, i was going to try it out on core-updates first though :) <rekado>I'm still having problems with "guix build --check" <rekado>Now I want to build it again to check that it's reproducible (I know it's not) <rekado>but "guix build --check -K r" just gives me this output: <rekado>grafting '/gnu/store/das1i1pm54dj6lbdcsw5w0sdwhccyj1a-r-3.3.2' -> '/gnu/store/pd44fkh8cdfjws9ai2x1sw3ryanxmifd-r-3.3.2'... <rekado>/gnu/store/pd44fkh8cdfjws9ai2x1sw3ryanxmifd-r-3.3.2 <efraim>civodul csanchezdll I read the thread, and I forgot to include a comment when committing :/ <rekado>efraim: thanks, --no-grafts works. (I'm sure I tried this before, but not today :)) <efraim>ok, built new bootstrap-binaries with the patch applied, i'll find out in ~75 minutes if it worked <roelj>What do I need to do to get ant (from GNU Guix) to be able to download things from HTTPS resources? <roelj>Is there a separate certificates thing for Java programs? <civodul>rekado: try "guix build r --check --no-grafts" <civodul>remember that grafting creates a separate derivation <civodul>roelj: that was discussed recently on help-guix, lemme see if i can find it <roelj>civodul: Oh thanks. I found it. <csanchezdll>efraim: thanks, please let us know whether it works now <roelj>rekado: Any ideas? I now run 'ant -Djavax.net.ssl.trustStore=~/.guix-profile/etc/ssl/certs' <rekado>roelj: we have a build phase to generate the trust store. <rekado>roelj: but it's disabled for version 7. <rekado>You can't use the certs directly. <roelj>Version 7, is that icedtea@3? <roelj>How can I use it indirectly? <rekado>take a look at the "install-keystore" phase of icedtea-6 <rekado>it goes through all certs, runs keytool on the extracted key data and ... that's it. <roelj>Maybe that should become a profile hook ... <rekado>sorry, it's disabled in icedtea-8 (version 3.x), not icedtea-7 (version 2.x) <roelj>Right. Well, I'll figure it out I guess <rekado>there's a FIXME comment in the guts of icedtea-8. <rekado>icedtea is a build system for the openjdk <rekado>it's a distribution of the OpenJDK <rekado>it's a collection of patches and makefiles; you still need to download the JDK source releases. <efraim>my aarch64 machine is on glibc right now, and its been ~90 minutes since it started, so I think the current bootstrap binaries are a success! <csanchezdll>the problem can be reproduced easily out of the building process, to check whether binaries are good or not <efraim>I just copied the bash over to bootstrap/aarch64-Linux/, think I should've updated my whole patch set for the whole set for testing it? <csanchezdll>cause the step that triggers the problem used unpacked bootstrap binaries <csanchezdll>AFAIU the single static bash executable that is in bootstrap/<arch> only gets used at the very begginning <efraim>it causes a full rebuild when I replace just bash, but I didn't think about replacingall of static-binaries.tar.xz, when we had that tar issue I replaced just the tar in bootstrap/aarch64-linux <csanchezdll>because tar got triggered at a different point of the building process <csanchezdll>basically those single binaries are used to unpack static binaries, guile, compilers ang glibc <csanchezdll>probabbly you need to replace both, but for sure you need to replace static-binaries.tar.xz <rekado>looks like R 3.3.2 has only merged the reproducibility fix for DESCRIPTION files, but not for rds, rdb, rdx files <roelj>rekado: I might be onto the problem with icedtea@3.3.0 and the 'install-keystore phase problem. <roelj>rekado: I believe the minimum key length has been upped and some certificates fall below that minimum.. Excluding those seems to work (I still have to rerun a couple of times because there are multiple certificates that have this problem). <roelj>rekado: Certificates with a key length of 384 bits seem to be the problem. <rekado>I lost patience when I added this to the other icedteas and couldn't figure out why it fails for the latest version. <roelj>rekado: I'll try to get it working by filtering these certs out.. <roelj>There are 14 certificates that would have to be left out <rekado>it's better to have it working for most certs than not at all. <roelj>I wonder why they are even in the nss-certs.. 384 bit.. that's pretty low <roelj>ACTION starts another rebuild of icedtea@3.3.0 <roelj>Hopefully I didn't miss any certificate this time :/ <roelj>Damn.. forgot one that has 256 bit instead of 384 bit! <roelj>At this point I'd wish builds could continue at a certain phase <roelj>The build failed with ERROR: In procedure copy-file: Permission denied. :( <roelj>civodul: I'm trying to fix the icedtea@3.3.0 keystore. <roelj>civodul: There are 15 certificates that cannot be imported, due to (I believe) an algorithm difference. <clacke[m]>I don't have LWN, so I can only see that he's talking about Propellor, which is a pretty cool project. I didn't know he's still working on it. <clacke[m]>Sort of touches on the guix realm, as it's using a functional language to describe systems. But Propellor is in Haskell and works more along the sort of salt / puppet / chef route, with an existing imperative OS that you modify. <civodul>clacke[m]: yeah that was another interesting article <civodul>i like the safeties that type-checking safety, but i'm unsure whether this really matters in the big picture <civodul>i mean "statically-typed Puppet" is nice, but "whatever-typed GuixSD/NixOps" provides guarantees of another kind that are maybe more important <slyfox>still, it's sad to see simple mistakes like argument type mismatch in a program that ran for 30 minutes <rekado>yeah, I sometimes wished Guile had some form of contracts. <rekado>in static typing you can have an Any type to get what you know from dynamic typing. <rekado>Haskell has various implementations of this; one of them is the "vault" library for persistent storage of values of arbitrary type. <OrangeShark>there is a typed language for guile, I recall seeing releases posted on the guile mailing list <efraim>Built my bootstrap binaries without my grep workaround, rebuilding now :/ <paroneayea>looking forward to seeing the new debbugs instance for guix :) <jmi2k>debbugs is that new way of submitting packages? <rekado>I’m currently playing around with Mu-guile <rekado>debbugs is what we use for dealing with bugs <paroneayea>rekado: you and I started out talking about our guilt about worrying about things moving slower than we like <paroneayea>but fosdem makes me feel like we're really making progress over this last year :) <rekado>jmi2k: to submit bug reports you just send email to bug-guix@gnu.org. <rekado>jmi2k: we want to have a similarly simple way to track package submissions <jmi2k>jmi2k: yes, that's what I heard <jmi2k>If a version has a hyphen should I convert it to a dot? Like in 0-8 <efraim>i was going to update guile-next the other day, but it took me 4 hours to build <roelj>I'm running into an error preparing for GuixSD: guix system: error: no target of type 'polkit' for service #<<service> ... <roelj>Is anyone willing to share his/her system configuration? <rekado>it requires a couple of additional files (udev rules and xorg config), but that’s not so important. <roelj>rekado: Thanks! This is already helpful :) <alezost>roelj: polkit is the default service of %desktop-services; you can add it simply with (polkit-service) <efraim>take a week off and oss-sec is overflowing <roelj>alezost: Should that be in the (services (cons* ...))? <alezost>yes, don't you use %desktop-services ? <roelj>alezost: No.. But I probably should then. <alezost>roelj: you shouldn't. I don't use %desktop-services <roelj>Oh.. I see.. I had both %desktop-services and %base-services. <alezost>it can't work, because %base-services is a part of %desktop-services <roelj>Yeah.. I figured that out :) <roelj>The %desktop-services contains a lot <roelj>rekado: Why do you have gnome-themes-standard in the (packages ...) field? <alezost>rekado: you don't need 'iproute' in your packages since it is a part of %base-packages <catonano>roelj: I' d love to see someone else' s system conf too <roelj>catonano: If I get mine to work, I'll post it too <jmi2k>Why does `sudo su` not work? I've just noticed it, it asks my sudo password and then the root account's one <roelj>jmi2k: I don't know, but does 'sudo -i' work as expected? <jmi2k>roelj: yes. In fact, I'll use it. TIL <paroneayea>davexunit_: btw git-predicate is now in guix master, so you can use that instead of git-file? in your guix.scm files if you want to cut them down a bit <davexunit_>one step further would be to have a procedure that did the (local-file ...) stuff <bavier`>paroneayea: is the 'description' field in that guix.scm correct? <paroneayea>not obvious at all that I'm just copy-pasta'ing from previous projects huh? ;)