bug#25476: Hunting: pivot-root test fails on foreign distro
Hi, zimoun skribis: > This bug seems fixed by a1a8b7f2e20513a3ad968e74e7ec52546404e3c6 as > explained here [1]. Well this commit fixes one of the issues discussed here (the utmpx test failure), but not the ‘pivot-root’ test failure itself. However, it seems that the ‘pivot-root’ test is now skipped in practice on most systems so… Turns out I found how to make it work again in commit 1deca767be1b84b96633e317f3fcdd5165f95df3. Let me know if anything’s amiss. Finally closing! :-) Ludo’.
bug#39468: Openbox - Calculator does not load
> Date: Mon, 10 Feb 2020 23:19:42 +0100 > From: Marius Bakke mba...@fastmail.com > To: Gábor Boskovits boskov...@gmail.com, "Scott C. MacCallum" > > > > > Cc: "39...@debbugs.gnu.org" 39...@debbugs.gnu.org > Subject: bug#39468: Openbox - Calculator does not load > Message-ID: 87d0am2igx@devup.no > Content-Type: text/plain; charset="utf-8" > > Gábor Boskovits boskov...@gmail.com writes: > > > I believe we could do something along these lines: > > > > 1. Provide an openbox-minimal and an openbox entry. > > 2. openbox minimal would do what openbox does right now > > 3. define a %openbox-recommended-packages list that makes most of it work > > 4. the openbox entry would append the %openbox-recommended-packages to > > the package list. > > > > This sounds like a good idea. Any volunteers for a patch? > > I'm not sure we need openbox-minimal even, most users will probably > tweak %base-packages after installation and choose the set they want. > -- next part -- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 487 bytes > Desc: not available > URL: > https://lists.gnu.org/archive/html/bug-guix/attachments/20200210/f4dd65e4/attachment.sig > > -- I volunteer. Please be patient with me though, this will be my first bug fix. :)
bug#25476: Hunting: pivot-root test fails on foreign distro
Hi Ludo, On Tue, 11 Feb 2020 at 12:35, Ludovic Courtès wrote: > zimoun skribis: > > > This bug seems fixed by a1a8b7f2e20513a3ad968e74e7ec52546404e3c6 as > > explained here [1]. > > Well this commit fixes one of the issues discussed here (the utmpx test > failure), but not the ‘pivot-root’ test failure itself. D'oh! I missed this part. > However, it seems that the ‘pivot-root’ test is now skipped in practice > on most systems so… Ok so let if the bug show up again. :-) > Turns out I found how to make it work again in commit > 1deca767be1b84b96633e317f3fcdd5165f95df3. Let me know if anything’s > amiss. Cool! Thank you for the fix. Cheers, simon
bug#39562: python-keras build fails: test_selu: Not equal to tolerance rtol=1e-07, atol=0
This resembles to the babl issue we are having. Is it possible that this is hardware related? Pierre Neidhardt ezt írta (időpont: 2020. febr. 11., Ke 16:19): > Tests fail with: > > --8<---cut here---start->8--- > === FAILURES > === > __ test_selu > ___ > > def test_selu(): > x = K.placeholder(ndim=2) > f = K.function([x], [activations.selu(x)]) > alpha = 1.6732632423543772848170429916717 > scale = 1.0507009873554804934193349852946 > > positive_values = get_standard_values() > result = f([positive_values])[0] > assert_allclose(result, positive_values * scale, rtol=1e-05) > > negative_values = np.array([[-1, -2]], dtype=K.floatx()) > > result = f([negative_values])[0] > true_result = (np.exp(negative_values) - 1) * scale * alpha > > > assert_allclose(result, true_result) > E AssertionError: > E Not equal to tolerance rtol=1e-07, atol=0 > E > E Mismatch: 50% > E Max absolute difference: 1.1920929e-07 > E Max relative difference: 1.0726715e-07 > Ex: array([[-1.111331, -1.520167]], dtype=float32) > Ey: array([[-1.111331, -1.520167]], dtype=float32) > > tests/keras/activations_test.py:226: AssertionError > --8<---cut here---end--->8--- > > See attached log. > > -- > Pierre Neidhardt > https://ambrevar.xyz/ >
bug#27894: Building Guix fails without '/etc/services'
I run into this bug now on openSUSE Tumbleweed. The reason is that on TW `/etc/services` got moved to `/usr/etc/services`. What would be required to support that use case?
bug#27894: Building Guix fails without '/etc/services'
On 11.02.20 21:40, Julien Lepiller wrote:> This is somewhat similar to what happens on android, and probably any systen using an alternate libc. Guix uses its own libc that expects an /etc/services and other files. I guess a symlink from /etc to /usr/etc is all you need?. Yes a symlink does resolve it. But doing it on all my systems is annoying :P But I wonder how much effort would be required to make this hardcoding of `/etc/services` more flexible. I'm mean Tumbleweed uses glibc. The only thing different is that they are moving all/most of config files from /etc to /usr/etc for $reason.
bug#27894: Building Guix fails without '/etc/services'
Le 11 février 2020 15:10:16 GMT-05:00, Jonathan Brielmaier a écrit : >I run into this bug now on openSUSE Tumbleweed. The reason is that on >TW >`/etc/services` got moved to `/usr/etc/services`. > >What would be required to support that use case? This is somewhat similar to what happens on android, and probably any systen using an alternate libc. Guix uses its own libc that expects an /etc/services and other files. I guess a symlink from /etc to /usr/etc is all you need?
bug#39571: evolution and bogofilter
Hello, I'm trying to get spam filtering working in evolution. According to evolution docs, evolution is supposed to use either bogofilter or spam assassin. I am focusing on bogofilter since guix has a bogofilter package. I have set all settings in evolution according to the evolution docs from the help menu, but cannot get confirmation either than spam filtering is actually working, or that evolution is in fact interacting with bogofilter to build a words database. As part of that, I'm trying to confirm if guix has correct options for that built into evolution, to properly interact with bogofilter binary. On the one hand: - I see in source code of evolution guix pacakage that there is a bogofilter module - I see in built guix package that there is a .so library for bogofilter - I see, through gsettings, that there is a schema for evolution- bogofilter """ gsettings get org.gnome.evolution.bogofilter command '' """ On the other hand: - I selected all enable junk mail processing options in the preferences menu and on the account level menu - I can mark items and junk mail or not junk mail, but there is no feed back as to whether a filter is doing anything - I tried marking a bunch of items as junk mail and not junk mail, to train bogofilter - It does not appear that anything is automatically being marked as junk - if I just run bogofilter command at a shell, I get message """ Can't open file 'wordlist.db' in directory '/home/christopher/.bogofilter'. error #2 - No such file or directory. Remember to register some spam and ham messages before you use bogofilter to evaluate mail for its probable spam status! """ As though no database has been created yet. Thinking maybe some bogofilter path or option not set during package build. Tried to confirm this viewing build log from guix-build, but since I have already built the package once from source, I cannot figure out how to get guix-build to let me build it again. -- Christopher Howard Enterprise Solutions Manager Alaska Satellite Internet PO Box 70, Ester, AK 99725 3239 La Ree Way, Fairbanks, AK 99709 907.451.0088 1.888.396.5623 www.alaskasatelliteinternet.com
bug#39571: evolution and bogofilter
Quick update: I tried settings the path myself in gnome schema to point to the bogofilter binary in my profile. After restarting evolution, I see now there is a words database in my home directory. So, this may be the solution for me. However, it still leaves open the question of whether guix evolution pacakge should be providing paths for bogofilter or spamassassin at compile time, either by default or as an option. It seems that if you do nothing, by default users of evolution have no spam filtering, although it looks like they do. -- Christopher Howard Enterprise Solutions Manager Alaska Satellite Internet PO Box 70, Ester, AK 99725 3239 La Ree Way, Fairbanks, AK 99709 907.451.0088 1.888.396.5623 www.alaskasatelliteinternet.com
bug#39352: guix pull failing on aarch64
Ludo said: > I believe the problem is not deterministic, so it may be that retrying > ‘guix pull’ will work… I take back what I said; I tried one more time today just out of curiosity, and it actually succeeded. I tried four more times afterward though and it failed the same way as it has before. So just as you said, it's not deterministic, but it fails much more often than not in my particular situation. If there's any extra information I can give that could help people debug this, please let me know. Hunting down a hard to reproduce error is the worst. :)
