<buenouanq>has anyone introduced Guix and GuixSD to RMS yet? <jmd>How can I change the directory which guix build uses for its temp directory ? <rekado_>maybe these no-subject messages are created when people want to comment on a bug (or close it) by sending email *directly* to <number>@debbugs.gnu.org. <rekado_>when using the Emacs interface to debbugs having emails without subject is not a big problem as you can still see them in a single thread. <rekado_>the problem does not seem to be *caused* by debbugs.el, though. It appears to be a user decision to send email directly to the bug address (without replying or using the Emacs interface). <efraim>as a non-emacs user, there's not a lot of other choices. are they the "maintenance emails"? <rekado_>efraim: what do you mean by “not a lot of other choices”? It is possible to *reply all* to debbugs emails, which keeps the subject line intact and is registered by debbugs. <rekado_>there’s no technical need for no-subject emails sent directly to the bug address <jmd>Do we have a policy on when it is ok to disable the test phase on packages? <rekado_>we usually only do this for good reasons. What counts as a good reason varies. <civodul>jmd: roughly, when there's an upstream bug, or when there's an inherent reason why the test cannot run in the chroot, or when it'd be really really hard to fix (e.g., gcc) <jmd>Ok. Does "I can't be bothered to fix it" count as a good reason? <civodul>you'd have to phrase it differently ;-) <jmd>ok. I'll think of a diplomatic way to say that and send a patch for review. <civodul>jmd: but do document the problem in a comment <jmd>How do I specify the build dir to guix build? <civodul>the /tmp/guix-build file name is fixed <efraim>rekado_: I meant email was the only option I found, not that no subject emails are normal <jmd>civodul: I thought I recall a recent conversation where we said users could specify it. <jmd>So TMPDIR has to be passed to the daemon?? You can't change it from the guix ui ? <roelj>Cool! Removing /gnu/store/.links can be "repaired" with guix gc --verify=contents,repair. <roelj>So in case your rsync screws up on hardlinks, this is a nice way to deduplicate your store again. <rekado_>I found the most likely cause for irreproducibility in R’s rdb files. <rekado_>it’s in “src/library/methods/R/trace.R” where an environment is created with a “dateCreated” timestamp. <rekado_>that gets embedded in the database(s), and then the thing is gzipped. <rekado_>I don’t know if it’s okay to replace that time stamp, or if this will break the tracing behaviour. <civodul>note that there might also be a gzip timestamp <efraim>python-minimal on core-updates x86_64 Fatal Python error: getentropy() failed <efraim>any special flags for the filesystem on an external hdd? <efraim>Im going to have some Shepherd questions later when I can get around to debugging it <adfeno>Hi all! Is there any progress on packaging Ring? Did someone pick-up the work that Mr(s). Gradl made? <adfeno>I'll try experimenting with it a little more. <civodul>adfeno: no progress that i know of, but it'd be great! <adfeno>Last time I checked, the packagers were trying to find ways to tell Ring to recognize a "GNOME Schema" (or something similar). <adfeno>And then I remembered that I once saw a similar error with Abiword, and someone already patched Abiword. <adfeno>So I figured that, if we manage to keep up the work, we might be able to test if similar fix applies to the case of Ring <civodul>right, for glib schemas, usually the answer is glib-or-gtk-build-system <adfeno>civodul: Indeed... I'll look into it once I can recunstruct all the patchs related to Ring that aren't in master, so I can use the missing packages locally only. <davexunit>the guile-fibers is messed up. doesn't install compiled files to the right place. <davexunit>so when you load the (fibers) module it re-compiles everything <wingo>davexunit: you need a new fibers release or something? <davexunit>which reminds me that I am confused where the right place for compiled modules even is <davexunit>guile libraries seem to have several different places they like to put things <davexunit>and guix's GUILE_LOAD_COMPILED_PATH is similarly confusing <davexunit>wingo: just a new package, I guess. I was just trying to give it a whirl last night. ***Piece_Maker is now known as Acou_Bass
<wingo>one day we need to fix guix to put load paths into the store :P <wingo>i.e instead of being /gnu/store/a:/gnu/store/b it should be /gnu/store/c where c contains links to the members of a and b <wingo>will avoid the N^2 lookup problem we have now for rpaths etc <wingo>applies to PATH, GUILE_LOAD_PATH, rpaths; many things in guix <rekado_>this doesn’t sound too difficult to implement, actually <wingo>yeah i agree, i just never have a round tuit :) <wingo>(classic dad-joke "i'll do it when i get a round tuit" etc; sorry for the jokesplain, and also the joke) <roelj>Doesn't it make things even more complex? <roelj>Could've expected that answer :P <roelj>But, then load paths are built by a derivation as well? <rekado_>you’d have a derivation that builds a union and then use that union as the input. <wingo>a bit more build-time work, but faster run-time <wingo>because a path lookup only goes to one directory, not N <roelj>Not much build-time work I suppose. <roelj>I remember a discussion on that <roelj>Are you implying I'm old now? ;) <wingo>for libraries for example, we add one rpath per library, so with N libraries you have N rpaths, and they are searched in order <wingo>so first lib takes 1 lookup, second takes 2, Nth takes N <davexunit>I remember talking about guix at an FSF event in 2013. we're old now. <roelj>But.. why don't we link the libraries with an absolute path again? <rekado_>roelj: it’s more than just libraries. <wingo>that's just the way elf works. but same thing for $PATH, many other things. <rekado_>PYTHONPATH would benefit from this, PERL5LIB, R_LIBS_SITE, etc <roelj>Ah, I should probably read about rpath more to understand this <roelj>they get out of hand indeed.. ;) <rekado_>roelj: you can look at it with readelf <rekado_>roelj: e.g. readelf -d $(readlink -f $(which .emacs-25.1-real)) <rekado_>you’ll see that the RUNPATH field is just a long list of directories that will be consulted to resolve the library names to paths. <wingo>yeah. or do an "strace guile -c 1 2>&1 | grep open | grep '\\.so'" for example <roelj>So, in "Library runpath", it needs to loop over all directories there.. <roelj>Yeah, that's quite inefficient indeed.. <roelj>And shared libraries have such a rpath as well? <wingo>well each library is only loaded once per process, so it doesn't come from there <wingo>just look at what happens in the guile case looking for libm, for example <wingo>looks in the libffi rpath, in the libgc rpath, it's like a children's story really ;) <civodul>RUNPATH is an issue, but otherwise, any time we create a profile, there's only one entry in the search path <civodul>actually, instead of using RUNPATH, we might be able to squeeze in the absolute file name of libraries as NEED <civodul>i vaguely remember someone proposed it in the past <wingo>a single rpath would work just as well tho, no? <civodul>all it'd take is ld-wrapper replacing each -lfoo with /gnu/store/.../libfoo.so <wingo>if we used this strategy for rpaths <wingo>k. whatever's easiest of course :) <civodul>but that makes an extra store item and extra symlink dereference <wingo>ACTION goes back to spectator mode :) <davexunit>I haven't done much guixing lately. gonna try to upgrade guile-next to 2.1.8 <rekado_>having a single union directory as the rpath might make it easier to provide relocatable binaries, no? <wingo>i am not sure if it is an additional symlink reference <wingo>because already e.g. /gnu/store/6k08nkddnrb15h5pwp1s0fa94mr1qas9-gmp-6.1.1/lib/libgmp.so.10 is a symlink <davexunit>guile 2.1.8 should build reproducibly, right? <wingo>which is what ld.so finds for libgmp.so.10 <wingo>could be there's probs, dunno <davexunit>my computer at work is much more powerful than any computer I own so I'll build it there <davexunit>oh except guix is trying to rebuild the world... <davexunit>I've been having this problem on my laptop lately <davexunit>I haven't updated guix in over a month because when I try it rebuilds the world <rekado_>davexunit: do you get the same behaviour without grafts? <civodul>davexunit: if you do a --rounds=2 build of guile-next, let us know how it goes :-) <civodul>efraim: the NixOS folks have 96-core Cavium ThunderX machines building for aarch64 <davexunit>rekado_: I guess it wasn't rebuilding the world but rebuilding bash? <davexunit>I got alarmed when I saw the bootstrap binaries being downloaded <civodul>davexunit: probably due to the recent Bash CVE <civodul>OrangeShark: oops, i didn't, that fixed it :-) <civodul>i think it'd be nice if this were done automatically or something <civodul>otherwise you may get lots of bug reports ***E4xoi is now known as exio4
<adfeno>How do I inherit the opendht package definition and also replace the snippet in the "origin" for another one of my own? <OrangeShark>civodul: yeah, I agree. libgit2 needs to initialize a lot of stuff before it works which is why they have these functions to initialize and also to shut it down. I think most bindings don't automatically do that <adfeno>I mean: I want to reuse the package definition, and most parts of the origin definition, modifying only the snippet inside origin. <civodul>wingo: so i can do "guix pack guile-next" and that gives me a 23 MiB compressed binary tarball with Guile <davexunit>civodul: there's lots of C libraries that require initialize/terminate function calls that I'm never sure of how to handle nicely in Guile <davexunit>on one hand, I don't really want loading a module to have such side-effects <davexunit>especially if initialization can be parameterized. <davexunit>on the other hand, we can see that it's error prone to ask users to do it <civodul>davexunit: in (guix gcrypt) i call it from the top-level, which has pros and cons, i agree <davexunit>would a special form be that way to go? (with-git (do-some-stuff)) <civodul>people may still forget to use the special form :-/ <adfeno>I must go now, have to do some job hunting :) <davexunit>civodul: but you don't see it as particularly bad to initialize from the top-level? <civodul>davexunit: i think it's ok if it's really lightweight initialization that doesn't take any arguments <davexunit>a potential issue though is that if module loading was multi-threaded <davexunit>in SDL2 the init function needs to be called from the main thread <davexunit>a lot of SDL2 calls are limited to the main thread <civodul>in that case you probably have to expose it <davexunit>I guess just documenting it well is the best thing I can do <civodul>wingo: and "guix pack guile-next guix" gives me a 52M tarball (with 2.0 + 2.2 + guix + guile-json etc.) <civodul>it's a generalization of the thing that creates the Guix binary tarball <civodul>wingo suggested to publish a binary tarball of 2.2.0 on the D day <davexunit>if we drop the tarball for people to try it out, do they need to be root to unpack it and try it out? <catonano>what's the guile trick to cd to a specific directory ? Like, I need qmake to be called from within a speciic directory <sneek>erliphant, you have 1 message. <sneek>erliphant, ng0 says: sorry I can't help you at the moment, for questions regarding hydra or cuirass you better direct the question at the guix-devel at gnu.org list <erliphant>i am building a package that has its dependencies compiled and in the store. However, the build process seems to want to access the source of the dependency even though it is already compiled. Is this expected? <jmd>erliphant: Well, some packages are written like that. <erliphant>@jmd - I wrote the package definition. The only interesting thing is that the dependent package uses a file:// url <erliphant>jmd: also the dependent package is a propagated-input. To be specific both packages are Python packages that I defined myself <erliphant>jmd: Ignore me .. I think I worked it out. Probably just a problem between keyboard and chair. Thanks for your input. <manganesio>Nothing special if I recall correctly. But you could read the gnu-system-discuss archives for example. <Acou_Bass>i dont want to put words in his mouth, but i imagine he doesnt take any 'hard' stance on it, 'as long as its free software im happy' hehe <bavier`>did we have someone working on a darcs package? <civodul>bavier`: i think there's something on bugs.gnu.org/guix-patches <bavier`>hmm, I wonder why the source links aren't getting the commit id embedded... <civodul>oh right you fixed that, didn't you? <civodul>the guix-artwork.git checkout on hydra.gnu.org was stale, sorry about that <bavier`>speaking of guix-artwork, I really like the website suggestions floating around on guix-devel ***jonsger1 is now known as jonsger
<catonano>Trying to build a package. In "build.sh" called from the makefile there's a test looking for a ".git" folder containing a config file. If it doesn't find them it prints a message complaining that the project can be built from a git checkout only. And it quits. Like this http://paste.lisp.org/display/341129 <catonano>thing is, in thhe tar.gz there is no ".git" folder <catonano>the right thing would be to go on their mailing list and complain that this is a bug <catonano>the corner cutting solution could be to move to the git download <bavier`>catonano: is the tarball from github or such? <catonano>bavier`: no, the tarball is from a ftp site <bavier`>oh, then that would seem a bug indeed. <bavier`>having it available over ftp suggests they manually make the tarball, rather than an automatically-created like github provides, <CharlieBrown>quiliro: Ho, bone. Kial vi uzis Esperantan vorton en angla babilo? <CharlieBrown>Ho... "funkcionas" ne estas vorto, sed "funkcias" estas. <CharlieBrown>Ankau, mi ne scias ke vi tute parolis Esperante chi tie. Tre bone! :) <quiliro>CharlieBrown: ĉu vi estas angla babilon? mi pensas ke ĉio estas internacia babilo. Do, mi uzas internacian lingvon. <catonano>bavier`: ok, I subscribed to their mailing list <quiliro>ni uzu ĉien babilon pri guix kaj guixsd <bavier`>catonano: but in the meantime, using git-fetch is fine <CharlieBrown>quiliro: Mi scias ke vi estas hispanoparolanto, char vi skribis "verbo"-on. <quiliro>CharlieBrown: ĉu vi estas anglaparlanto? <CharlieBrown>quiliro: Mi ankau havas malrapidan komputilon. Ghi estas ThinkPad X200. <quiliro>CharlieBrown: vi povas uvi virtualan maĉinon <catonano>bavier`: I don't understand the answer :-/ <CharlieBrown>quiliro: Ne, mi ne povas uzi VM-on, char Libreboot havas problemojn. <bavier`>catonano: perhaps it means that we shouldn't be using the pkg/pip/build.sh script <quiliro>CharlieBrown: heroo estas "heroe" en anglo <quiliro>estas mian heroon pri vi uzas programaron liberon 100% <bavier`>catonano: just a quick look in the source suggests that the source tarball is useless <quiliro>CharlieBrown: Ĉu vi uzas surtablan komputilon xfce? <bavier`>catonano: that's a start. I can't understand what that package is doing with it's python. I hope you can decipher it more <bavier`>catonano: oh, it has two separate components <quiliro>bonan. mi devas iri. mi estas malŝata kaj estas malfrua. ĝis revido! \\o <bavier`>catonano: the "runtime" is built with qmake, and from the "web" directory, you might be able to just to a standard `pythong setup.py` <bavier`>catonano: good luck though, libraries.txt says it needs jQuery :( <catonano>I was mumbling to just bundle all those web things as if they were binary resources. It's not ideal but I'd love to have this thing <CharlieBrown>catonano: Are you one of those people who live in GuixSD? <bavier`>CharlieBrown: I like your XFCE theme <CharlieBrown>bavier`: Thanks. It's Numix with a mixed icon set of Numix and Feiance, IIRC. <catonano>CharlieBrown: Are you suggesting that I'm letting this thing slip out o hand ? <CharlieBrown>catonano: It's good if you can live in GuixSD. I envy you. <catonano>CharlieBrown: I've been using it or a few days now <CharlieBrown>I switched to Parabola because I'm tired of distro hopping. <catonano>I've been liiving in Fedora for a very long time <CharlieBrown>I've thought about doctoring up Slackware to be free, and using it. <CharlieBrown>I decided to use Parabola; it's the most up to date and backward-compatible distro. I would do Debian, but I don't trust those devilish double-talkers. <catonano>CharlieBrown: No, I couldn't know how. By the way, I used Fedora because I enjoyed the suupport. <CharlieBrown>catonano: Yeah, Fedora and Debian have good community support. Although... Debian makes you freeze your packages until they become so stale that you choke on them. <CharlieBrown>I've stopped trying to rely on others for support, and just use the Parabola/Arch Wiki. <catonano>bavier`: pgadmin3 is not supported anymore :-/ <bavier`>catonano: right, but it is probably still useful, and is packaged by many other distros still <bavier`>if 3 and 4 are very different, it probably wouldn't hurt to have packages for both, even 