GNU IceCat 68.2.0esr: Problems in password fields
Hi, I upgraded my system today and I've noticed some problems when trying to write passwords in login pages: * The text cursor is not shown. * Writing is horribly slow. * The input method indicator in the GNOME desktop (top right) disappears/reappears erratically. Anyone else experiencing this? --- https://sirgazil.bitbucket.io/
Re: ntpd: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Eccomi! On Sun, 3 Nov 2019 15:23:01 -0500 Leo Famulari wrote: > > Hm... I'm not sure but I have a guess. > > By default, ntpd will not change your clock if it is very wrong. If it > is only a couple minutes wrong, then ntpd will slowly adjust the time, > but if it is wrong by some large threshold, ntpd will simply give up. > > However, you can run ntpd with '-g, --panicgate', which will allow > ntpd to make big adjustments to your clock. In Guix, this is called > 'allow-large-adjustment?' and we made it the default in September > 2019. [1] I tried launching ntpd with root adding the specified options, but it actually returns the following issue: ntpd[1162]: Command line: ntpd -g --panicgate ntpd[1164]: proto: precision = 1.746 usec (-19) ntpd[1164]: getconfig: Couldn't open : No such file or directory ntpd[1164]: unable to bind to wildcard address :: - another process may be running - EXITING couldn't simply kill the running process since it would respawn instantly. > Maybe your system has not been updated since then? As root, can you > check with `guix describe` and let us know exactly what it says? Indeed i didn't update root's profile since this system's installation back on Jul 22! Generation 1Jul 22 2019 19:17:54 file name: /var/guix/profiles/system-1-link canonical file name: /gnu/store/8ls7mlpn7vx2szd7ayy8isryjnfkab3w-system label: GNU with Linux-Libre 5.1.2 bootloader: grub root device: UUID: 9b3e267c-cb01-4121-a7d1-9d5b60a2e5cf kernel: /gnu/store/mmnl20fg05w8gzzsp4d8dvagmdn1vjil-linux-libre-5.1.2/bzImage Generation 2Nov 04 2019 14:38:46(current) file name: /var/guix/profiles/system-2-link canonical file name: /gnu/store/l4xssjf25si0zkfwqmp3lir2a4x8zjh0-system label: GNU with Linux-Libre 5.3.8 bootloader: grub root device: UUID: 9b3e267c-cb01-4121-a7d1-9d5b60a2e5cf kernel: /gnu/store/9l8z8k5ya6g9vwzn1jcba9qdlfhf6xhd-linux-libre-5.3.8/bzImage I imagine reason why pull generations only shows the last one: Generation 1Nov 04 2019 10:17:44(current) guix d258d9c repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: d258d9c7d222e6b64531c14293f41bd8d62ea4f7 > If that's the root cause, try doing, as root, `guix pull && guix > system reconfigure [...] && reboot` to get the new NTP service. Or > you could try a more targeted fix by adding the > 'allow-large-adjustment? #t' flag to your config.scm. Please ask on > IRC #guix if you need help :) > > [1] > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=08b4a10fa6bc535cd99d65f0233dd027153878eb The new generation actually introduces two unexpected elements: a. At the login section it proposes both gnome and mate environment (which is correctly usable only the latter) b. Once i login on Mate's de, i'm unable to use any menu's application (suggests something similar to "unable to spawn proccess gio-launch-desktop - missing directory") I wonder if i actually performed corectly root's commands, by accessing it via "sudo su -", is it the right way? (i remember there was a better one but couldn't find it on the manual) As you suggest i'll bring this quest onto irc so i can solve it in shared mode Grazie mille! Matias Jose Seco Baccanelli pgp9y852QXpiD.pgp Description: OpenPGP digital signature
Re: Building "special" binary bundles (i.e. not using guix pack)
On Mon, Nov 4, 2019 at 9:53 AM Thompson, David wrote: > > Sure, I could just grab a bunch of pre-built stuff from Debian's > repositories and stuff it in a tarball, but I want to use Guix in > order to have a reproducible toolchain and because this bundle will > include several Guile libraries that would be a pain to build without > Guix. I want to be able to say "Here, use this convenient binary > bundle. If you're curious what's Furthermore, I really want to see > Guix fill this particular niche because it could lead to an > Appimage-like feature in Guix itself. Oops! Looks like I accidentally deleted some text here. The part in quotes should read: "Here, use this convenient binary bundle. If you're curious what's inside and how it is made, here is the code used to build it." Yours in neverending typos, - Dave
Re: `guix install protobuf:static` headers?
Hi,
Thank you for the explanations.
On Sun, 3 Nov 2019 at 18:19, Marius Bakke wrote:
>
> zimoun writes:
> > What should be the correct behaviour of "out" vs "static"?
>
> 'static' outputs typically contain *only* the .a libraries, as you
> found. If you want the headers, you need to add protobuf:out too.
I am still confused.
--8<---cut here---start->8---
$ guix install protobuf@2.6 -p /tmp/proto
$ ls /tmp/proto/include/google/protobuf/
--8<---cut here---start->8---
And 22 files live there. Headers found. :-)
However, is it expected that LIBRARY_PATH is not set?
--8<---cut here---start->8---
$ cat /tmp/proto/etc/profile
# Source this file to define all the relevant environment variables in Bash
# for this profile. You may want to define the 'GUIX_PROFILE' environment
# variable to point to the "visible" name of the profile, like this:
#
# GUIX_PROFILE=/path/to/profile ; \
# source /path/to/profile/etc/profile
#
# When GUIX_PROFILE is undefined, the various environment variables refer
# to this specific profile generation.
export
PATH="${GUIX_PROFILE:-/gnu/store/m26p44mxy4k79gzy18nq2nivygrdmkm5-profile}/bin${PATH:+:}$PATH"
--8<---cut here---end--->8---
> I think there were proposals to start using a 'dev' output for headers
> and such, but don't know if it got anywhere.
Moreover, the static libraries are also installed with simply
"protobuf@2.6.0:out".
I have tried to adapt the definition of protobuf adding a "lib" flag.
But it fails with "cycle detected in the references of". Roptat
explained on IRC how to track the issue and before investigating some
time, I would like to be sure to well understand. :-)
Thank you,.
All the best,
simon
Building "special" binary bundles (i.e. not using guix pack)
Hello all, First, context and parameters: I have a project for which I'd like to release pre-built binaries that will "just work" on major FHS-based distributions such as Ubuntu and Fedora. As far as native executables go, this bundle requires Guile and roughly a dozen C shared libraries. The goal is to compile guile and the additional libraries in such a way that there is *no* runpath information embedded in the ELF files. The goal is *not* to ship a complete graph, down to glibc, like 'guix pack' would do. Instead, I'm taking the more traditional approach of bundling only the libraries that I cannot assume will be on the user's system (say, libvorbis) and assuming that others (like libx11) will be there. Everything included in the bundle needs to be built against a glibc version that is the most compatible across other distros right now. I believe that version is 2.27. Sure, I could just grab a bunch of pre-built stuff from Debian's repositories and stuff it in a tarball, but I want to use Guix in order to have a reproducible toolchain and because this bundle will include several Guile libraries that would be a pain to build without Guix. I want to be able to say "Here, use this convenient binary bundle. If you're curious what's Furthermore, I really want to see Guix fill this particular niche because it could lead to an Appimage-like feature in Guix itself. Now, onto my issues. I have experimented with a few different approaches for building the bundle but haven't had success with any: 1) Using Guix packages as-is and using patchelf to strip runpath information. This honestly came very close to working for me, and I think I could probably make it work with a little more debugging, but it's very hacky and unsatisfying. The biggest issue is that because Guix builds everything with glibc 2.29 these days, I have to bundle glibc 2.29, *including the dynamic linker* so I can actually run Guile. I sent a bundle to a friend to test and it didn't work, but they couldn't tell me what the backtrace was because their system locales were incompatible and thus Guile couldn't failed to print a backtrace. I could ship glibc 2.29 locales in the bundle, too, but that was the last straw for me. How much more stuff would I have to shove into this bundle before it worked reliably? When the easy but hacky solution starts to lose the easy part, it's time to move on. 2) Use a special GCC toolchain sans ld-wrapper and with a few other tweaks to keep runpaths away. This seemed promising but, because there's no runpaths, configure scripts would fail. Although the scripts could compile test programs, running those test programs failed because they were unable to find libraries. Setting LD_LIBRARY_PATH doesn't work because then the configure script doesn't work at all because now binaries built against glibc 2.29 are trying to link against libraries built against 2.27 and everything explodes. I was able to hack around this for a little while by passing "LDFLAGS=-static-libgcc" to configure scripts, but eventually I ran into a configure script that linked against more than libgcc in its test programs (if you're curious, libvorbis builds a program linked against libogg when running ./configure) and I was out of luck. When autoconf-generated configure scripts cannot run test executables, they say something to effect of "are you cross-compiling? use the --host flag". So, I got to thinking: Should I reframe this as a cross-compilation? It certainly seems like I'm dealing with a special target system. Which leads me to... 3) Performing a cross-build. It seems a little weird to cross-compile for x86_64 on a machine that is natively x86_64, but I suppose it makes sense because I'm targeting a foreign type of system. However, I was unable to get this to work because Guix was trying to build tons of stuff from source, from gcc to Linux headers. I assumed I was doing something wrong and aborted this process. I'm not so good at navigating the cross-compilation code in Guix right now. So, now I'd like to ask: Does anyone which approach I *should* be taking here? Does anyone have any experience they can offer? Carl Dong shared his approach to building bitcoin using Guix with me (see: https://github.com/dongcarl/bitcoin-guix/blob/master/packages.scm) which enabled me to try out approach #2 and #3, but it doesn't seem like an exact fit, though I could just be misunderstanding something. My hunch is that #3 is the correct approach, but it's unclear how I setup the proper cross-compilation environment with my special gcc toolchain. I hope I've explained myself somewhat clearly. Any guidance appreciated! If you've read this far, thank you! - Dave
“Managing Servers with GNU Guix: A Tutorial”
Hello Guix! Jakob wrote a great tutorial on how to use ‘guix deploy’ to deploy Guix System to one machine or to several virtual private servers (VPSs): https://guix.gnu.org/blog/2019/managing-servers-with-gnu-guix-a-tutorial/ Give it a spin, and spread the word! Ludo’.
Re: “Guix Profiles in Practice”
Hello, Jonathan Frederickson skribis: > On Nov 3, 2019, at 9:24 AM, Ludovic Courtès wrote >> Now, this would be very much stateful: you can’t tell in advance whether >> you’re going to build a new profile based on the current Guix, or >> whether you’re going to reuse a previously cached profile that could be >> arbitrarily old. That doesn’t sound great. > > What if something identifying the profile (directory name? config file?) > included info about the Guix revision it was built from? That way a profile > would be reused if it’s built from the same Guix revision, but if you switch > revisions it’d be rebuilt. Then in that case you’re just looking for a form of caching, is that correct? If ‘guix environment’ were 10 times faster, it’d be just fine, right? (It’s not getting 10 times faster any time soon I’m afraid :-), but just to make sure I understand whether we’re talking about a UI issue or a performance issue.) Thanks, Ludo’.
Re: “Guix Profiles in Practice”
Ludovic Courtès writes: > That sounds like a good idea. ‘guix develop’ could keep the profiles it > manages under ~/.cache/guix. > > Now, this would be very much stateful: you can’t tell in advance whether > you’re going to build a new profile based on the current Guix, or > whether you’re going to reuse a previously cached profile that could be > arbitrarily old. That doesn’t sound great. This could be fixed, maybe the following way: - Dump the channel specifications for every profile in etc/channel-spec.scm for instance. - Merge Konrad's time-machine script so that we can easily reuse a channel specification to activate a profile. > Perhaps we should focus on improving the performance of ‘guix > environment’ first and foremost? But isn't it orthogonal to this issue? As I understand it, the current discussion is about "pinning" profiles. Should any dependency get garbage collected, an environment will need Internet access to refetch the missing parts; I think this is what we are trying to avoid, regardless of how fast `guix environment` is. What about `guix environment --pin` instead of `guix develop`? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
