IRC channel logs
2018-01-03.log
back to list of logs
<amz3>rekado: the error is very strange, you can reproduce using: <amz3>that said, I think the issue is not in guix but I don't understand why it fails only using guix <amz3>basically, it seems like the database is opened before the unittests runs for each unittests files <rekado>amz3: have you tried disabling parallel testing? <g_bor>rekado: I've found a way to get past the warning that ant does not find junit in my java8 branch. If I add ant-junit to inputs then that warning goes away. <g_bor>rekado: I have another problem with this however, it seems that tests are not found this way. Do you have any idea what might cause that? <rekado>g_bor: the ant-build-system looks for tests in some directory. The directory can be overridden in the arguments field. <g_bor>Ok, thanks for that. I will check it. <g_bor>I've set a few patches that might go individually to core-updates, I think this is due only in the next update cycle. Once those are pushed I will send a patch series solving the hamcrest-core issue. <g_bor>I have a questin, though. If we have a package, and we also have a bootstrap version of it, then is there any policy how to use inherit in this case? <g_bor>Should the two definitions be independent? If we intend to separate language bootsrap, then that might be a good idea... However inheriting is less code... I don't know... <g_bor>And if I do inherit, should I inherit the default from the bootsrap version? <rekado>g_bor: I prefer to have a more complicated package inherit from a simpler package. <rekado>they are still separate packages <rekado>it’s just that an inherited package takes on the parent’s fields when they are not specified. <g_bor>Ok, I just used the same principle in my patches, so I think it will be fine then. <fis>Hi, I'm currently running guix on top of Fedora. I got wonder what if I install guix via guix. <fis>Will it mess up with the original one? <rekado>how did you install Guix on Fedora? <fis>Binary install, described in the doc. <rekado>ok. Any package you install via Guix is going to have their own directory in /gnu/store. <rekado>so there won’t be any conflicts. <rekado>conflicts only arise in the user environment <rekado>when you install the “guix” package via Guix there will be a new directory in /gnu/store for that dated version of Guix. <rekado>how this affects your environment depends on your environment variables. <rekado>however, Guix will always look for .config/guix/latest <rekado>so when you’ve run “guix pull” it will be prefered over the modules that come with the installed Guix. <rekado>if all that sounds confusing: don’t worry. Just use “guix pull”, don’t install the “guix” package. <fis>Alright, thanks. Just out of curiosity. <fis>Another not related question. I have tried to package some stuffs not already in the repo yet (sent to patches). I got curious about the original design choice of guix. Unlike nix or any other managers I know, packages recipes in guix are coupled with guix itself(stored in one git repo). Is there any reason to do that? <dvn>anyone in Berlin want come join GNUnet and secushare hackers? We're working towards using guix in our everyday development, and CI. <dvn>We're meeting everyday at onionspace the rest of the week and weekend. :) <str1ngs>dvn: unfortunately I live in NA, but I'm interested in guix and gnunet integration <lfam>sneek later tell fis: By keeping the package definitions and the rest of the Guix code in the same repo, we avoid having to maintain an API between them, which allows us to work more quickly than otherwise. <lfam>sneek later tell fis: You might compare it to how Linux keeps its drivers in the same repo as the kernel itself <amz3>rekado: indeed, running 'guix build -c 1 -f guix.scm' makes it work <str1ngs>dvn: do you know how to publish a directory then recursively download? I can share, but when I download using a hash all I get is a directory file. I can't find any documentation on how to recursively download a directory <dvn>str1ngs: maybe we move to freenode/#gnunet? <wingo>question for yall. what ath9k wireless card in that laptop pci format should i get in order to have free firmware? <janneke>wingo: that's possibly not your size/form factor. i found getting the right size/slot type pretty difficult <lfam>Hmm, seeing several of these on core-updates: error: ‘uintptr_t’ undeclared (first use in this function) <ArneBab_xo>Hi, ArneBab here, only for a short note: I had problems with guix pull which disappeared when I explicitly ran guix package -i guix. If that is a general thing, it could be useful to mention in the docs to install guix as first thing after guix is working. <ArneBab_xo>(I’m currently mostly cut off from communication) <lfam>ArneBab_xo: On GuixSD or another distro? <lfam>Okay, thanks for the note <str1ngs>I did not thing guix package -i guix was required <lfam>ArneBab_xo: If you have time, sending details about the problems to the mailing list would be helpful <lfam>In general, it shouldn't be necessary to install the guix package on foreign distros. Instead, unprivileged users should be able to use the package symlinked from root's profile to /usr/local/bin/guix <ArneBab_xo>I did not yet clear up whether I’m allowed to send to the ML from work. <ArneBab_xo>(I started a month ago and am busy learning the ropes) <ArneBab_xo>lfam: is it possible that the guix in roots profile can get too old to work after guix pull? <ArneBab_xo>(I did not touch the root profile at all after the initial installation) <lfam>Yes, but it depends on the details of the problems you experienced <ArneBab_xo>I’ll see whether I can get get the tracebacks to you <ArneBab_xo>and whether I can reproduce it by removing guix from the user profile <ArneBab_xo>besides: it’s really nice to have guix at work - thank you for your great work on it! <str1ngs>ArneBab_xo: this is a possibility where root profile gets to old. but it could be resolved by guix package -i guix as root. maybe that is what you meant earlier? <ArneBab_xo>I did guix package -i guix as unpriviledged user <str1ngs>how long ago did you install guix ? assuming from binary? <lfam>If you have time, I think you should try uninstalling guix from the unprivileged users profile and upgrading the guix package in root's profile <ArneBab_xo>hm … I’m not completely sure whether I did sudo guix pull … <ArneBab_xo>I’ll try to recheck tomorrow (need to go purely by memory right now) <lfam>`sudo --login guix pull` to be sure it works for root <ArneBab_xo>I installed a month ago from binary (around 2017-12-04) <str1ngs>ArneBab_xo: I think lfam suggestion is a good place to start. <ArneBab_xo>I’ll do that - I guess it will also update the build users? <lfam>ArneBab_xo: Yes, after you restart the guix-daemon. The guix-daemon is provided by root's guix package <str1ngs>I don't think you'll need to make changes to build server <ArneBab_xo>I need to get going again -- thank you again! I took a note in my paper notebook to try sudo --login guix pull <mb[m]1>Bah, the elogind system test fails with 234.4. <lfam>mb[m]1: I'm looking into core-updates problems with libtirpc, rpcbind, nfs-utils, etc <mb[m]1>lfam: Great! elogind fails on CU as well, which prompted my update journey (the problem is gone in 234). <lfam>"Update journey" is a good way to describe these things <mb[m]1>The GRUB test failure surprised me, since I had built it successfully before the latest full-rebuild changes. Not sure what's up. <str1ngs> mb[m]1 possible race condition in tests maybe? due to parallelization <mb[m]1>str1ngs: Don't think so, the failure seems consistent. <mb[m]1>Speaking of GRUB, it also fails with qemu 2.11...we'll have to fix that soonish. <lfam>The GRUB tests are really flaky <lfam>Yeah, I noticed that about QEMU and GRUB. <lfam>I'm surprised there is still no discussion on the GRUB mailing lists about that. I guess that not many people are running the tests <lfam>I didn't look closely at the failures yet but I also suspect it's related to the QEMU command-line invocation because almost all the GRUB tests failed <mb[m]1>So elogind 234 fails to start due to "permission denied".....somewhere. <lfam>Hm... in my experience that message is sometimes misleading. It could also be a nonexistent executable <mb[m]1>Aha, the D-BUS policy files have a new default location... that might be related. <mb[m]1>In maybe 8 years of building custom kernels, this is the first time I've had to run `make oldconfig` in a teeny version update. I guess this page table isolation stuff is serious. <lfam>"All three attack variants can allow a process with normal user privileges to perform unauthorized reads of memory data, which may contain sensitive information such as passwords, cryptographic key material, etc." <lfam>It sounds like game over for protected kernel memory <lfam>I guess they will publish their full report soon <lfam>I'm super impressed by the work of P0. They are behind most of the major bug findings recently <mb[m]1>That post explains why my Android got "security patch level January 5" today as well. <mb[m]1>Security patches from the future! <lfam>I wonder if my phone will ever get updated <mb[m]1>Lineage probably gets them in a few weeks/months.. <lfam>I can't really handle a custom phone OS or managing the updates myself. I really need a phone vendor that handles their responsibility for security updates <lfam>But it seems there is only one :( <mb[m]1>lfam: Then you're pretty much stuck with the Pixel/Nexus line, indeed.. <lfam>I prefer going with the Pixel / Nexus stuff though <mb[m]1>Ooh, setting "--with-dbuspolicydir" back to "$out/etc/dbus-1/system.d" made the elogind test pass. I'll bounce it off guix-patches and test it on a few systems.