<ng0>davexunit: seems like for thunderbird I disable rust <ngz>Building another Scribus right now. <ngz>It really looks like a kludge, but at least, it works. <ngz>Note that, at the end of the build process, I get a lot of "warning: RUNPATH contains bogus entries: ("lib/scribus/plugins/")". Could it be related? <mb[m]1>ngz: I doubt that is related to the wrapper. Great that you got it working :) <ngz>No, I meant, could this be related to the initial issue? <ngz>Let's send this on guix-patches@gnu.org then. <mb[m]1>Now, an even better approach than wrapping would be to substitute the "python" invokation with something such as (string-append (assoc-ref inputs "python") "/bin/python"), although that's not always easily feasible. <ngz>Unfortunately, I cannot find where Python is launched. <taohansen>ng0: can i see your gpg-agent configs again? <taohansen>can't remember the git route to get to yours <taohansen>trying to use it as an ssh-agent but it seems to be failing hard <ngz>bavier, mb[m]1: I have to go now. Thanks for the help. <taohansen>looks like civodul does: "eval `gpg-agent --daemon --enable-ssh-support --write-env-file ***Guest55552 is now known as sturm
***sturm is now known as Guest17724
<guoruei>NO ! I am in gNewSense GNU/Linux team <civodul>m-o: i'll look at the let-system thing today <m-o>civodul: i bought an odroid xu4, if qemu can use kvm it may speed things up ! <efraim>who was looking for someone from gNewSense? <efraim>civodul: currently net-tools and inetutils both produce an ifconfig binary, do we want to start stripping net-tools of some of its binaries? <civodul>m-o: nice! i have a brand new Olimex A20-linuxo-something, though it failed to boot yesterday <civodul>but yeah, we should be able to do nice things :-) <Dima__>I'm trying to install guixsd with an encrypted partition, on a gpt drive, but I got an error from grub-install <Dima__>Maybe because I used /dev/sda1 instead of /dev/sda; how can I pick up from last step? <efraim>i'm pretty sure i'm the only user of tilda, every time i launch tilda it creates a new config <brendyn>What does SpyBlock do that ublock origin doesn't? <kristofer>I am having some trouble building guix from git. ERROR: gzip: unbound variable while trying to load guix/scripts/pack.scm <kristofer>I'm trying to build in a guix environment guix <kristofer>I added a package for guile-wiredtiger and wanted to guix lint before sending a patch <rekado_>kristofer: could you tell us how to reproduce this error? What are the steps you took after cloning the git repository? <kristofer>git clone --recursive git://git.savannah.gnu.org/guix.git <kristofer>./bootstrap && ./configure --localstatedir=/var && make <kristofer>weirdly, in the repl gzip is defined as a guix package <kristofer>but using the build system apparently undefined <civodul>kristofer: could you paste the exact error messages? it might be on several lines <civodul>more precisely: the command, and the output <kristofer>M-. from gzip in guix/scripts/pack.scm takes me right to the package definition of gzip <rekado>kristofer: I cannot reproduce this. <roptat_>did you modify anything in your checkout yet? <kristofer>how do ya'll setup your guix environment for guix development? maybe I overlooked something <brendyn>then probably there is an error in your edits <kristofer>I have been using the package definition for a few days.. guix environment artanis --ad-hoc -l /path/to/guile-wiredtiger/guix.scm <roptat_>kristofer: I simply use a script that does guix environment guix --ad-hoc git help2man gnutls guile-git $@ <roptat_>but I don't think what's after --ad-hoc is needed <kristofer>roptat_: yeah a clean git checkout origin/master has no trouble building. I must have done something bizarre and can't track it down <brendyn>kristofer: run git diff origin/master..master and have a look through your changes perhaps? <kristofer>yeah I added #:use-module (gnu packages guile) to gnu/packages/databases.scm and a package definition <rekado_>kristofer: could you show us the diff? And the full error message as civodul previously requested? <kristofer>it has to be something in the package definition. builds fine before my changes <rekado_>kristofer: first error is the license field <rekado_>kristofer: in this module all licenses are prefixed with the “license:” symbol <rekado_>(the other problems are only stylistic errors) <kristofer>yeah with the diff the build fails because gzip is unbound but without a clean checkout it works fine <rekado_>do you still get the error after fixing the license field? <rekado_>when you run “./pre-inst-env guix build guile-wiredtiger” what do you get? <rekado_>another thing that’s missing is #:use-module (guix git-download) <kristofer>do I have to make install to test the changes? <kristofer>it's looking in my ~/.guix-profile for packages instead of the working directory <kristofer>./pre-inst-env guix lint guile-wiredtiger -- package not found <rekado>kristofer: “./pre-inst-env guix lint guile-wiredtiger” from the source directory is correct. Do you get more lines of output? <davexunit>ACTION tried to upgrade rust to 1.19.0 and failed <davexunit>AFAICT it's impossible to build it without network access <davexunit>also I realized that 1.21.0 is the latest so I'm trying that now <davexunit>the problem is that in order to build rust you need to use cargo, rust's package manager. <bavier>oh right, the cargo dependency is a relatively new thing iirc <davexunit>not only do you need a bootstrap rust compiler, you need cargo to fetch rust code to build the new compiler <bavier>debian doesn't seem to offer any help on the circular dependency bit <efraim>would it be better to keep the version we have now and use that to build the next version and so on? <efraim>IIRC debian uses their current packages to build the next round <davexunit>efraim: we already use a bootstrap rust compiler <vagrantc>alright, built a new installer image, and encrypted root worked with very little fuss! <efraim>right but I thought you had to update the bootstrap compiler to build the next one <davexunit>I think the solution to the problem may be in the package definition for cargo <OnlyHuman>hi wingo was just trying to make rpm og elogind for a pclinuxos sysvit distro but keep getting build erros <davexunit>I'm convinced that language developers just love pain <lfam>It's not terribly different from building GCC, right? ;) <davexunit>so our cargo package has to download all the source code to all the dependencies separately, generate checksums for them, and then write out a .cargo/config file so that the bootstrap cargo won't try to access the network <davexunit>in order to build the compiler you need an earlier version of the compiler, but you also need the package manager <lfam>Hm... sounds like a meaty project that somebody can feel proud of completing ;) <lfam>Some of those steps will have to be short-circuited so that we can download stuff out of band <lfam>It's okay, that happens to all of us. The good news about this case is that I'm sure someone will be motivated to continue, since Rust has so much momentum <benny>I'm interested but it doesn't sound like a good first task ;) <davexunit>and historically upstream laughs at stuff like this <lfam>I'm sure we'll get there :) I didn't get any help from the Go team either <benny>having read their issue tracker a bit I don't think rust would laugh at this <benny>you may have some people that don't see the value of improving it because rustup works in so many situations <CcxWrk>I know the Nix/Pijul guys have something for this. I think they called it Carnifex? <bavier>imho it's a serious language adoption issue <davexunit>the problem is that guix is the only project that cares <CcxWrk>For translating crates into nixexprs. <kmicu>[jokin'] Quickly! Change name from Guix to Quantum and GuixSD to QuantumSD. There is soo much hype! :) <lfam>davexunit: Does Nix allow network access in the Rust build environment? <lfam>Or, how do they deal with it? <CcxWrk>So you don't have to use Cargo to get the deps anymore. <davexunit>lfam: I don't know but from what I've seen they don't care about reproducibility or bootstrappability <lfam>Yes, they have different values, but the daemon implementation is still very similar <davexunit>they care about it only when it's trivial to do <kmicu>Nix cares, some of big Nixpkgs parts do not care. It is a difference. <lfam>So the "download while building" thing would be a problem for them too <davexunit>as soon as its hard they punt and just package whatever <CcxWrk>Nix has Mozilla-provided official repo with Rust binaries IIRC. <davexunit>we use a binary-only version of rust in order to bootstrap our own compiler <davexunit>it's so frustrating that nix seems to get all the attention <lfam>Well, they had a bit of a head start <lfam>I think we are doing okay considering that <kmicu>Nixpkgs is MIT so corporations use it, write blogs, users write blogs b/c reproducible binaries or FHS wrappers let them play games or use Firefox Quantum. It is not surprising they get more attention. <kmicu>(It is like Arch vs Parabola, Ubuntu vs Trisquel and so on.) <lfam>I think it's not exactly comparable to those distro pairs <lfam>In those cases, the free variants are the same thing minus the non-free parts. Whereas Guix is not the same thing as Nix, but has its own advantages and disadvantages <kmicu>lfam: I am (alas still) Nix(OS) user, but I also have GuixSD systems, and from my perspective Guix is the same thing, but libre. <lfam>Fair enough. As a "user" I can see how they seem very similar <kmicu>Oh c'mon. Guix source still has Nix code in it. <bavier>kmicu: 5% according to openhub, and even that portion is modified from Nix's version <kmicu>Yes, but that is the important part. Store. <davexunit>the daemon is not where the interesting code is <kmicu>And still 5% is not 'essentially 0 code with Nix'. <bavier>imho the store/daemon is not the important part <davexunit>we just need to get rid of that c++ code so people will shut up about it <kmicu>We will see if you will be able to compile and run Guix w/o it. <kmicu>I know that. But please state facts. <kmicu>Sharing essentialy 0 code with Nix is not true. <kmicu>Do not count Guix/Nixpkgs parts. Only the tool code. <kmicu>It is not silly, b/c it confuses people. <kmicu>There is ~100 \\bnix_.* variables in Guix source and you say 'Guix shares essentially 0 code with Nix'. And you still need that Nix leftovers to *compile* Guix. <lfam>Hi, there is no need for this discussion to become an argument. We have a cordial relationship with the Nix project and do not hide that we still use some Nix code <lfam>My understanding is that our implementation is sui generis from package to derivation, and for all the user-facing code. <janneke>Here, here. Moreover, the main reason that we work to replace the Nix C++ code with Guile is a pragmatic one, it will enable some critically nice features. <lfam>Going from derivation to store object, we use the daemon code forked from Nix. I don't understand that level very well, so I'm not sure exactly what does what down there <kmicu>I understand all of that. I am familiar with Nix code base and Guix code base. I migrated almost all my hardware to Guix(SD). But pretending that Guix is special or novel will always trigger me. Guix still uses http://hydra.gnu.org/ <kmicu>Paraphrasing Malcom from Six Sense, when I use Guix "I see Nix parts everywhere". <bavier>I only thought momentarily about that recently. <vagrantc>so, i've managed to install guixsd to an encrypted partition, and it booted and all that ... then i updated the config to include a desktop environment, that seemed to go well <vagrantc>but when i boot, now grub doesn't find the initrd ... but the initrd it's referencing is clearly there <vagrantc>also, that grub still tries to boot even after it failed to load the initrd is... surprising <lfam>Much thanks to rekado and civodul for doing the boring work of splitting up those huge package modules! <kristofer>do I have to subscribe to guix-patches to submit a patch? <bavier>kristofer: no, you can just send it <lfam>vagrantc: Looks like nobody here right now has advice. I recommend sending a message to <help-guix@gnu.org> <lfam>Hm, I wonder if we can drop ((guix build graft) mkdir-p*) now? <lfam>AFAIK that bug has been fixed in the Guile we use <bavier>lfam: I think we're currently trying to support back to 2.0.9 <lfam>I'll send my patch anyways and mention that we can just add a code comment about that <bavier>configure.ac:87: PKG_CHECK_MODULES([GUILE], [guile-2.0 >= 2.0.9]) <lfam>Right. I'll just add the comment directly :) <bavier>lfam: thanks for the attention to detail :) <bavier>hm, looking at configure.ac I'm reminded that we don't quite comply with the gnu coding standards wrt installation directory handling <bavier>e.g. we don't support `make install prefix=...` <lfam>What do you think of this comment? Is it accurate? "Although this is fixed in our binary distribution of Guix, we aim to support Guile >= 2.0.9, which does not include the fix." <bavier>lfam: how about something like: "We need this as long as we support Guile < 2.0.13"? <CharlieBrown>I installed Kodi on a foreign distro. How do Kodi addons work in Guix? Kodi crashed. <civodul>CharlieBrown: did it crash while loading addons? <janneke>CharlieBrown: i'm using kodi on GuixSD, not using any/many addons though <civodul>sometimes during "guix lint" the NIST web site (for CVEs) seems to hang