* bug#25205: Guix Wikipedia page logo updated
@ 2016-12-22 7:49 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2016-12-22 7:49 UTC (permalink / raw)
To: 25205
[-- Attachment #1.1: Type: text/plain, Size: 334 bytes --]
Guix,
[First debbugs post, let's hope this works.]
I've updated the Guix Wikipedia page to use the new ‘unified’ logo.
Since Wikimedia rejects our SVG, I had to resort to copy-pasting the
original image in Inkscape and saving it as a new file.
It wasn't pretty, but the new logo sure is.
Kind regards,
T G-R
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 476 bytes --]
^ permalink raw reply [relevance 99%]
* bug#25273: [ng0@libertad.pw: 'mc' package needs some fixes]
@ 2016-12-26 14:09 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2016-12-26 14:09 UTC (permalink / raw)
To: ng0, 25273
[-- Attachment #1.1: Type: text/plain, Size: 436 bytes --]
Guix, ng0,
On 26/12/16 14:07, ng0 wrote:
> Some extension of mc will make the size of its graph grow.
> I personally don't care about the size, but others might. So:
I share your (lack of) concern.
> should I follow my vim example and put those changes into mc-full
Even then, the broken^Wminimal variant will need its own set of patches
to properly search $PATH instead of using obsolute paths.
Hap hols,
T G-R
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 476 bytes --]
^ permalink raw reply [relevance 99%]
* bug#26201: No notification of cache misses when downloading substitutes
@ 2017-03-21 2:46 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2017-03-21 2:46 UTC (permalink / raw)
To: dian_cecht; +Cc: 26201
[-- Attachment #1.1: Type: text/plain, Size: 574 bytes --]
Hullo,
On 21/03/17 02:44, dian_cecht@zoho.com wrote:
> Just ran guix pull and guix package -u, and found some of the programs
> download VERY slowly (<100kb/s, usually around 95). I asked on #guix
> and lfam mentioned it was probably a cache miss.
Do you mean that *substitutes* existed, but were not yet on
mirror.hydra.gnu.org and so were silently proxied from the much slower
hydra.gnu.org?
Or did Guix fall back to downloading *source* tarballs from some slow
upstream to build locally?
(I've no access to IRC at the mo'.)
Kind regards,
T G-R
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 476 bytes --]
^ permalink raw reply [relevance 99%]
* bug#26201: No notification of cache misses when downloading substitutes
@ 2017-03-21 3:57 99% ` Tobias Geerinckx-Rice
0 siblings, 2 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2017-03-21 3:57 UTC (permalink / raw)
To: dian_cecht; +Cc: 26201
[-- Attachment #1.1: Type: text/plain, Size: 1687 bytes --]
Ahoy,
On 21/03/17 03:52, dian_cecht@zoho.com wrote:
> The URL displayed during the download was mirror.hydra.gnu.org.
> [...] It was a binary download, not source.
Oh, OK. I'm not an expert on how Hydra's set up these days, but will
assume it's not too different from my own (a fast nginx proxy_cache,
mirror.hydra.gnu.org, in front of a slower build farm, hydra.gnu.org).
Whenever you're the first to request a substitute, mirror.hydra.gnu.org
transparently forwards the request to hydra.gnu.org.
The latter has to compress the response on the fly, leading to much
slower transfer speeds. It slowly sends it back to the mirror, which
slowly sends it on to you while also saving it on disc so all subsequent
downloads will be fast — by Hydra standards – and not involve hydra.gnu.org.
Maybe you knew all this, but it's also the reason that...
> On 21/03/17 02:44, dian_cecht@zoho.com wrote:
> It would be nice if there was some notification that a cache miss
> happened and the download will likely be slow, otherwise a user might
> wonder what problem there is with their connection.
...I'm afraid this makes no sense from guix's point of view.
The term ‘cache miss’ here is an implementation detail of our current
Hydra set-up, not something guix can or IMO should care about. There are
hundreds of reasons why your connection might be slow at any given time.
Guix should just tell you so (it does), not guess why. Or worse: know.
(But if others disagree, we'll have to extend the Hydra API to somehow
relay this information to the client, in the spirit of the modern Web.)
HTTP 200½: OK, fine, but it's Going to Suck.
T G-R
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 476 bytes --]
^ permalink raw reply [relevance 99%]
* bug#26201: No notification of cache misses when downloading substitutes
@ 2017-03-21 6:21 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2017-03-21 6:21 UTC (permalink / raw)
To: dian_cecht; +Cc: 26201
[-- Attachment #1.1: Type: text/plain, Size: 1761 bytes --]
Mornin',
On 21/03/17 05:48, dian_cecht@zoho.com wrote:
> I'm not suggesting having Guix tell me why my network is slow,
I never mentioned your network. Your proxied connection to a substitute
server, yes. And, well, this very bug report is for Guix to tell you why
that's slow...
> only if the download might be slow because it's having to pull from
> hydra.gnu.org.
(Side note: ‘it’ here is mirror.hydra.gnu.org, never a well-configured
Guix client.)
So to implement this, the client would need to display a ‘warning‘
message or flag sent by the substitute server, to notify the user that
their download might be slower... sometimes... by an unknown amount...
possibly?
But see, that wouldn't be true at all on my system (and surely others),
despite being set up nearly identically to Hydra. On the other hand, my
home download speed fluctuates wildly, even between simultaneous
connections to the same server. Whether or not a file is cached makes no
difference. To be told would be noise at best, misleading at worst.
I'd be against this only for those reasons, but I promise I'm not.
It's just all a bit vague, 's all, and my personal opinion is that once
the vagueness is resolved, not much will remain. But who knows.
> AFAIK, Guix devs are working on a replacement for the current build
> system, so the sane option wouldn't be extending the current hydra
> system to handle a new API call, but to try and work this type of
> feature into the next system.
My point is that it wouldn't be sane, and would be an ugly hack in
either system. Cuirass isn't really different from Hydra is this regard.
Me shut up now :-) I'm more interested in what others have to say.
Kind regards,
T G-R
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 476 bytes --]
^ permalink raw reply [relevance 99%]
* bug#26201: No notification of cache misses when downloading substitutes
@ 2017-03-21 14:55 87% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2017-03-21 14:55 UTC (permalink / raw)
To: dian_cecht; +Cc: 26201
[-- Attachment #1.1.1: Type: text/plain, Size: 1684 bytes --]
Hullo!
On 21/03/17 07:49, dian_cecht@zoho.com wrote:
> I'm not sure how any of this matters. If you are running a local
> Hydra instance or whatever, then I'd assume you'd be aware of what,
> if any, problems that could arise.
It matters for the reasons mentioned. It's not a ‘local Hydra’ & I have
no idea what problems you're talking about.
My problem is that every invocation of Guix already fills several
screens with Guile cache misses. Adding another warning (‘warning! the
system is working exactly as designed!’) will only serve to make those
other warnings look less silly, and I think that would be a shame.
To clarify:
- Warnings should be scary because warnings should be actionable.
There's nothing the user can or needs to do about a cache miss.
- It would be randomly shown to everyone, since this happens constantly.
- The behaviour warned about is not incorrect or abnormal.
- As already noted, it's how caching works.
> I don't see how this would have to be "an ugly hack". It's simply a
> query and response. The simplest way I can see for this to work would
> be for mirror.hydra to either just send the requested file, or a
> response that the file isn't cached then start to trickle the file on
> to the client.
Well, yeah... That's the ugly hack. :-)
It's not that your suggestion's hard to implement. In fact, it's
just one line for nginx (which it turns out I already had):
add_header X-Cache-Status $upstream_cache_status;
and 6 lines of lightly-tested Guile (attached)¹. And presto. This thing.
Doesn't mean we should.
Kind regards,
T G-R
¹: Why? Practice. Irony. Light masochism.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1.2: 0001-http-client-Warn-on-proxy-cache-misses.patch --]
[-- Type: text/x-patch; name="0001-http-client-Warn-on-proxy-cache-misses.patch", Size: 3052 bytes --]
From 6d459a442d73628a0628385283c7cf04dff1b797 Mon Sep 17 00:00:00 2001
From: Tobias Geerinckx-Rice <me@tobias.gr>
Date: Tue, 21 Mar 2017 15:31:56 +0100
Subject: [PATCH] http-client: Warn on proxy cache misses.
Still not a good idea.
* guix/http-client.scm (http-fetch): Add #:peek-behind-proxy parameter
to expose caching proxy implementation details as a scary warning.
* guix/scripts/substitute.scm (fetch): Use it.
---
guix/http-client.scm | 10 +++++++++-
guix/scripts/substitute.scm | 3 ++-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/guix/http-client.scm b/guix/http-client.scm
index 6874c51..2366f5e 100644
--- a/guix/http-client.scm
+++ b/guix/http-client.scm
@@ -2,6 +2,7 @@
;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017 Ludovic Courtès <ludo@gnu.org>
;;; Copyright © 2015 Mark H Weaver <mhw@netris.org>
;;; Copyright © 2012, 2015 Free Software Foundation, Inc.
+;;; Copyright © 2017 Tobias Geerinckx-Rice <me@tobias.gr>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -222,7 +223,8 @@ or if EOF is reached."
(define* (http-fetch uri #:key port (text? #f) (buffered? #t)
keep-alive? (verify-certificate? #t)
- (headers '((user-agent . "GNU Guile"))))
+ (headers '((user-agent . "GNU Guile")))
+ (peek-behind-cache? #f))
"Return an input port containing the data at URI, and the expected number of
bytes available or #f. If TEXT? is true, the data at URI is considered to be
textual. Follow any HTTP redirection. When BUFFERED? is #f, return an
@@ -253,8 +255,14 @@ Raise an '&http-get-error' condition if downloading fails."
(http-get uri #:streaming? #t #:port port
#:keep-alive? #t
#:headers headers))
+ ((headers)
+ (response-headers resp))
((code)
(response-code resp)))
+ (when (and peek-behind-cache?
+ (equal? (assoc-ref headers 'x-cache-status) "MISS"))
+ (warning (_ "the caching proxy is working properly!~%"))
+ (warning (_ "and there's nothing you can do about it.~%")))
(case code
((200)
(values data (response-content-length resp)))
diff --git a/guix/scripts/substitute.scm b/guix/scripts/substitute.scm
index faeb019..4a4f115 100755
--- a/guix/scripts/substitute.scm
+++ b/guix/scripts/substitute.scm
@@ -216,7 +216,8 @@ provide."
(unless (or buffered? (not (file-port? port)))
(setvbuf port _IONBF)))
(http-fetch uri #:text? #f #:port port
- #:verify-certificate? #f))))))
+ #:verify-certificate? #f
+ #:peek-behind-cache? #t))))))
(else
(leave (_ "unsupported substitute URI scheme: ~a~%")
(uri->string uri)))))
--
2.9.3
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 476 bytes --]
^ permalink raw reply related [relevance 87%]
* bug#26201: No notification of cache misses when downloading substitutes
@ 2017-03-21 16:07 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2017-03-21 16:07 UTC (permalink / raw)
To: dian_cecht; +Cc: 26201
[-- Attachment #1.1: Type: text/plain, Size: 624 bytes --]
On 21/03/17 16:32, dian_cecht@zoho.com wrote:
> Unless mirror.hydra randomly loses data in it's cache from hydra, it
> won't be random in the least.
It will. Whether one is first to download from the cache after the
substitute is built is essentially random.
> Quite frankly I'd like someone else to take a look at this bug,
Glad you agree.
> if for no other reason than I'm not sure if we're communicating clearly
> with each other here. Most of what you are saying makes no sense
> whatsoever and seems to miss the point I have attempted to make.
I assure you it does not.
Kind regards,
T G-R
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 476 bytes --]
^ permalink raw reply [relevance 99%]
* bug#26201: No notification of cache misses when downloading substitutes
@ 2017-03-21 17:08 99% ` Tobias Geerinckx-Rice
0 siblings, 2 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2017-03-21 17:08 UTC (permalink / raw)
To: ludo; +Cc: 26201
[-- Attachment #1.1: Type: text/plain, Size: 2686 bytes --]
Ludo',
On 21/03/17 17:43, Ludovic Courtès wrote:
> I think there’s room for improvement in our nginx config at
> <https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/nginx/mirror.conf>.
>
> For instance, I just discovered ‘proxy_cache_lock’ while looking at
> <http://nginx.org/en/docs/http/ngx_http_proxy_module.html>; looks useful
> in reducing load on hydra.gnu.org. Surely there are other ways to tweak
> caching.
Indeed! For reference, here's my cache configuration.
That's right. Now you can all¹ steal some criminally overpriced Belgian
bandwidth!
server {
server_name substitutes.tobias.gr;
listen [::]:443 ssl http2;
listen 443 ssl http2;
# FIXME move to main LE cert
ssl_certificate substitutes.pem;
ssl_certificate_key substitutes.key;
# "" means ‘inherit from upstream’ here.
add_header Cache-Control "";
# So does ‘off’. This is all a bit hacky.
expires off;
proxy_hide_header Set-Cookie;
proxy_ignore_headers Set-Cookie;
# Almost all traffic is already compressed.
gzip off;
...
location / {
limit_except GET { deny all; }
proxy_pass SUPER_SEKRIT_BACKEND;
# https://www.nginx.com/blog/nginx-caching-guide
add_header X-Cache-Status $upstream_cache_status;
proxy_cache default;
# We allow only GET requests, so don't waste key space:
proxy_cache_key "$request_uri";
proxy_cache_lock on;
proxy_cache_lock_timeout 3h; #yolo
proxy_cache_use_stale error timeout
http_500 http_502 http_503 http_504;
}
...
}
I'm sure it's hardly optimal (or, erm, ‘good’) either but it works.
> Besides, I’d like to use ‘guix publish’ on hydra.gnu.org. I suspect
> it’s going to be faster than Starman (the HTTP server behind Hydra), and
> also it uses an in-process gzip by default, as opposed to bzip2 which is
> what Hydra uses (better compression ratio, but super CPU-intensive).
Back when I used Hydra-the-software I do so briefly and I think it
worked. But no hard tests.
> At any rate, clients should not paper over server-side performance
> issues IMO.
Entirely off-topic, but this 'tude is a part of what drew me to Guix in
the first place. So, like, thanks, in general :-)
Kind regards,
T G-R
¹: Just put it *after* mirror.hydra.gnu.org, OK?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 476 bytes --]
^ permalink raw reply [relevance 99%]
* bug#26201: hydra.gnu.org uses ‘guix publish’ for nars and narinfos
@ 2017-03-23 18:52 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2017-03-23 18:52 UTC (permalink / raw)
To: mhw; +Cc: 26201, guix-sysadmin
[-- Attachment #1.1: Type: text/plain, Size: 750 bytes --]
Mark,
On 23/03/17 19:36, Mark H Weaver wrote:
> One question: what will happen in the case of multiple concurrent
> requests for the same nar? Will multiple nar-pack-and-bzip2 processes
> be run on-demand?
I think this used to be the case with the previous nginx configuration,
but the recent changes pushed by Ludo' were aimed in part at preventing
that.
> Recall that the nginx proxy will pass all of those requests through,
Are you sure? I was under the impression¹ that this is exactly what
‘proxy_cache_lock on;’ prevents. I'm no nginx guru, obviously, so please
— anyone! — correct me if I'm misguided.
Kind regards,
T G-R
¹:
https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_lock
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 476 bytes --]
^ permalink raw reply [relevance 99%]
* bug#26201: hydra.gnu.org uses ‘guix publish’ for nars and narinfos
@ 2017-03-23 19:25 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2017-03-23 19:25 UTC (permalink / raw)
To: ludo; +Cc: 26201
[-- Attachment #1.1: Type: text/plain, Size: 1209 bytes --]
Ludo',
On 22/03/17 23:06, Ludovic Courtès wrote:
> Tobias Geerinckx-Rice <me@tobias.gr> skribis:
>> proxy_cache_lock on;
>> proxy_cache_lock_timeout 3h; #yolo
>> proxy_cache_use_stale error timeout
>> http_500 http_502 http_503 http_504;
> I didn’t fully understand the docs for the last 3 directives here. For
> instance, what happens when 10 clients do GET /nar/xyz-texlive? Do the
> 9 unlucky clients wait for 3 hours and then get 404?
From ‘proxy_cache_lock’ [1]:
“When enabled, only one request at a time will be allowed to populate
a new cache element identified according to the proxy_cache_key
directive by passing a request to a proxied server. Other requests
of the same cache element will either wait for a response to appear
in the cache or the cache lock for this element to be released, up
to the time set by the proxy_cache_lock_timeout directive.”
Hmm. Good point: ‘to appear in the cache’, when we don't cache 404s or
even 410s.
I don't actually know.
Kind regards,
T G-R
[1]:
https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_lock
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 476 bytes --]
^ permalink raw reply [relevance 99%]
* bug#26201: hydra.gnu.org uses ‘guix publish’ for nars and narinfos
@ 2017-03-26 17:35 99% ` Tobias Geerinckx-Rice
2017-03-27 18:47 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2017-03-26 17:35 UTC (permalink / raw)
To: mhw; +Cc: 26201, guix-sysadmin
[-- Attachment #1.1: Type: text/plain, Size: 2091 bytes --]
Mark,
On 24/03/17 09:12, Mark H Weaver wrote:
> IIUC, with "proxy_cache_lock on", we have two choices of how other
> client requests will be treated:
>
> [badly, ed.]
Eh. You're probably (and disappointingly) right.
When configuring my little cache, I had a clear idea of how such a cache
should work (basically, your last scenario below), then looked at the
nginx documentation to find what I had in mind. ‘proxy_cache_lock’ matched.
I should have been more pessimistic and done more testing.
Shame on me, &c. Too much other things on my mind. :-/
> Or at least that's what I'd expect based on my reading of the nginx docs
> linked above. I haven't tried it.
I can try to do some simple tests tomorrow.
> IMO, the best solution is to *never* generate nars on Hydra in response
> to client requests, but rather to have the build slaves pack and
> compress the nars, copy them to Hydra, and then serve them as static
> files using nginx.
A true mirror at last! Do we have the disc space for that?
And could Hydra actually handle compressing *everything*, without an
infinitely growing back-log? I don't have access to any statistics, but
I'm guessing that a fair number of package+versions are never actually
requested, and hence never compressed. This would change that.
> A far inferior solution, but possibly acceptable and closer to the
> current approach, would be to arrange for all concurrent responses for
> the same nar to be sent incrementally from a single nar-packing process.
> More concretely, while packing and sending a nar response to the first
> client, the data would also be written to a file. Subsequent requests
> for the same nar would be serviced using the equivalent of:
>
> tail --bytes=+0 --follow FILENAME
>
> This way, no one would have to wait an hour to receive the first byte.
^ This is so obviously the right solution, that it would be
disappointing if nginx really couldn't be made to do it. It already
buffers proxy responses to a temporary file anyway...
Kind regards,
T G-R
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 476 bytes --]
^ permalink raw reply [relevance 99%]
* bug#26201: hydra.gnu.org uses ‘guix publish’ for nars and narinfos
2017-03-26 17:35 99% ` Tobias Geerinckx-Rice
@ 2017-03-27 18:47 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2017-03-27 18:47 UTC (permalink / raw)
To: 26201
[-- Attachment #1.1: Type: text/plain, Size: 808 bytes --]
Guix,
On 26/03/17 19:35, Tobias Geerinckx-Rice wrote:
> I can try to do some simple tests tomorrow.
Two observations:
- ‘proxy_cache_lock_timeout’ alone won't suffice to serialise requests;
‘proxy_cache_lock_age’ must also be set to an equally ridiculously
long span. Otherwise, multiple requests will still be sent to ‘guix
publish’ if they are more than 5s apart. Bleh.
(The problem then becomes that clients will stall while the file is
being cached, as explained by Mark. curl patiently waited.)
- Say client A requests a nar from ‘guix publish’ (no nginx involved).
If another client requests the same nar while A's still downloading,
‘guix publish’ will... silently drop A's connection?
I was not expecting this.
Kind regards,
T G-R
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 476 bytes --]
^ permalink raw reply [relevance 99%]
* bug#26764: Problem building master
@ 2017-05-03 19:06 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2017-05-03 19:06 UTC (permalink / raw)
To: maxim.cournoyer, 26764
[-- Attachment #1.1: Type: text/plain, Size: 281 bytes --]
Indeed.
On 03/05/17 20:59, Maxim Cournoyer wrote:
> After doing 'guix pull' to get latest master branch, `guix environment
> guix' fails while compiling the new sources: [...]
Reverting dcb95c1fc936d74dfdf84b7e59eff66cb99c5a63 seems to fix it.
Kind regards,
T G-R
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 504 bytes --]
^ permalink raw reply [relevance 99%]
* bug#27373: Update Knot DNS to 2.5.1.
@ 2017-06-15 10:01 99% Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2017-06-15 10:01 UTC (permalink / raw)
To: 27373
[-- Attachment #1.1: Type: text/plain, Size: 462 bytes --]
Guix,
Knot DNS >=2.5 uses a new, LMDB-based (DNSSEC) key database format. It
ships a new ‘pykeymgr’ script to manually migrate keys from the older
JSON format.
These patches update Knot to 2.5.1, add the required python-lmdb
bindings, and throw in a real LMDB description for good measure.
I use Knot 2.5.1 & DNSSEC but haven't any 2.4-format key databases to
import. If you do, your feedback would be very welcome.
Kind regards,
T G-R
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 504 bytes --]
^ permalink raw reply [relevance 99%]
* bug#27735: Unbootable images with GuixSD on... "GuixSD"
@ 2017-07-17 14:40 94% Tobias Geerinckx-Rice
2017-07-17 14:51 95% ` bug#27735: [PATCH 1/2] build, vm: Use a slightly less generic label Tobias Geerinckx-Rice
0 siblings, 2 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2017-07-17 14:40 UTC (permalink / raw)
To: 27735
[-- Attachment #1.1: Type: text/plain, Size: 2287 bytes --]
Guix,
[I lost most hours of sleep to this. I might ramble more than usual.]
The default label for images was recently changed[1] to "GuixSD".
While I think it's a fine label, that's also a problem: I've been using
it for years for my root partitions. And when one broke last night, I
couldn't use the GuixSD installer to rescue it.
The installer's now expects exactly one "GuixSD" partition when booting
— at least on UEFI. If the GRUB finds two, the GRUB will randomly
choose. In my case, the GRUB chose a frozen system.
(With a black screen that made debugging hell, but that's probably an
unrelated effect of the roughness of our UEFI support.)
The real problem here is that we're using a label as a UUID.
From gnu/build/vm.scm:
;; Create a tiny configuration file telling the embedded grub
;; where to load the real thing.
(call-with-output-file grub-config
(lambda (port)
(format port
"insmod part_msdos~@
search --set=root --label GuixSD~@
configfile /boot/grub/grub.cfg~%")))
I'm not the first to think so, as noted in gnu/system/vm.scm:
(define root-label
;; Volume name of the root file system. Since we don't know which
device
;; will hold it, we use the volume name to find it (using the UUID would
;; be even better, but somewhat less convenient.)
(normalize-label "GuixSD"))
I like that understatement. I'm not sure how to go about creating a
reproducible almost-UUID based on the store hash and passing it to all
the right places in a reasonably non-horrible manner either, random
hacker. And it would mean even more work and testing after all the
heroic effort on the new installer image + UEFI support by Danny,
Marius, and others.
Until it does happen, I suggest we change the name to "GuixSD-image"[2].
Still fragile, but not the PR fail that ‘don't call your GuixSD file
system GuixSD or it will break GuixSD’ would be.
Zzz,
T G-R
[1]:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=651de2bdb5fd451c50933dcf8d647d470d826261
[2]: Or whatever. I remember someone (Danny?) calling "-image" an
implementation detail. I think it's a description of the end result.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 504 bytes --]
^ permalink raw reply [relevance 94%]
* bug#27735: [PATCH 1/2] build, vm: Use a slightly less generic label.
2017-07-17 14:40 94% bug#27735: Unbootable images with GuixSD on... "GuixSD" Tobias Geerinckx-Rice
@ 2017-07-17 14:51 95% ` Tobias Geerinckx-Rice
1 sibling, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2017-07-17 14:51 UTC (permalink / raw)
To: 27735
* gnu/build/vm.scm (initialize-hard-disk): Use "GuixSD-image" as label.
* gnu/system/install.scm (installation-os): Likewise.
* gnu/system/vm.scm (system-disk-image): Likewise.
---
Or GuixSD-bikeshed or whatever.
gnu/build/vm.scm | 7 +++++--
gnu/system/install.scm | 2 +-
gnu/system/vm.scm | 2 +-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/gnu/build/vm.scm b/gnu/build/vm.scm
index d8c53ef37..e71b1b92e 100644
--- a/gnu/build/vm.scm
+++ b/gnu/build/vm.scm
@@ -354,7 +354,7 @@ SYSTEM-DIRECTORY is the name of the directory of the 'system' derivation."
(error "failed to create GRUB EFI image"))))
(define* (make-iso9660-image grub config-file os-drv target
- #:key (volume-id "GuixSD") (volume-uuid #f))
+ #:key (volume-id "GuixSD-image") (volume-uuid #f))
"Given a GRUB package, creates an iso image as TARGET, using CONFIG-FILE as
Grub configuration and OS-DRV as the stuff in it."
(let ((grub-mkrescue (string-append grub "/bin/grub-mkrescue")))
@@ -440,11 +440,14 @@ passing it a directory name where it is mounted."
;; Create a tiny configuration file telling the embedded grub
;; where to load the real thing.
+ ;; XXX This is quite fragile, and can leave the system in an unusable
+ ;; state when there's more than one volume with this label present.
+ ;; Reproducible (not-)UUIDs could reduce the risk but not eliminate it.
(call-with-output-file grub-config
(lambda (port)
(format port
"insmod part_msdos~@
- search --set=root --label GuixSD~@
+ search --set=root --label GuixSD-image~@
configfile /boot/grub/grub.cfg~%")))
(display "creating EFI firmware image...")
diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index f9aa7f673..866440eb4 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -306,7 +306,7 @@ Use Alt-F2 for documentation.
;; the appropriate one.
(cons* (file-system
(mount-point "/")
- (device "GuixSD")
+ (device "GuixSD-image")
(title 'label)
(type "ext4"))
diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
index dd9be2c6f..6e06781d5 100644
--- a/gnu/system/vm.scm
+++ b/gnu/system/vm.scm
@@ -345,7 +345,7 @@ to USB sticks meant to be read-only."
;; Volume name of the root file system. Since we don't know which device
;; will hold it, we use the volume name to find it (using the UUID would
;; be even better, but somewhat less convenient.)
- (normalize-label "GuixSD"))
+ (normalize-label "GuixSD-image"))
(define file-systems-to-keep
(remove (lambda (fs)
--
2.13.1
^ permalink raw reply related [relevance 95%]
* bug#27735: [PATCH 1/2] build, vm: Use a slightly less generic label.
@ 2017-07-17 17:58 99% ` Tobias Geerinckx-Rice
1 sibling, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2017-07-17 17:58 UTC (permalink / raw)
To: dannym, 27735
[-- Attachment #1.1: Type: text/plain, Size: 234 bytes --]
Danny,
On 17/07/17 19:20, Danny Milosavljevic wrote:
> Dash is invalid. Otherwise OK!
Good to know (I consider you an expert on file system label esoterica,
mainly so I don't have to be). Thanks!
Kind regards,
T G-R
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 504 bytes --]
^ permalink raw reply [relevance 99%]
* bug#27735: Unbootable images with GuixSD on... "GuixSD"
@ 2017-07-17 18:12 99% ` Tobias Geerinckx-Rice
2017-07-17 18:37 99% ` Tobias Geerinckx-Rice
1 sibling, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2017-07-17 18:12 UTC (permalink / raw)
To: dannym; +Cc: 27735
[-- Attachment #1.1: Type: text/plain, Size: 1041 bytes --]
On 17/07/17 19:17, Danny Milosavljevic wrote:> Hi T G-R,
> Yeah, that was me. I don't understand how an actual operating system
> on a drive is an image. Maybe I'm old-fashioned, dunno, but I think
> an image is something that is made up by light rays on a screen, not
> the real object. In the case of computing an image is a backup file
> of a drive, not what is on the drive to begin with.
>
> Also, even if it were an image, the image shouldn't say "<foo> image"
> in the image itself. A mirror which doesn't add anything to your
> image when you look into it, either :)
I agree completely. I've become so used to dd'ing ISOs to USB drives
that I've come to think *only* in terms of fake discs, but you're right.
I chose ‘image’ reluctantly, because my first ideas (‘installer’, ‘vm’)
were even less relevant: this label's used for all disc images. Oh well.
We could choose the worst and ugliest label possible: that'd compel
someone to fix this!
(No. "GuixSD_image" it is.)
Thanks,
T G-R
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 504 bytes --]
^ permalink raw reply [relevance 99%]
* bug#27735: Unbootable images with GuixSD on... "GuixSD"
2017-07-17 18:12 99% ` Tobias Geerinckx-Rice
@ 2017-07-17 18:37 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2017-07-17 18:37 UTC (permalink / raw)
To: 27735-done
[-- Attachment #1.1: Type: text/plain, Size: 88 bytes --]
Done with commit 0862b95433cacf91e44248097caa09119fc532a6.
Kind regards,
T G-R
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 504 bytes --]
^ permalink raw reply [relevance 99%]
* bug#27735: [PATCH 1/2] build, vm: Use a slightly less generic label.
@ 2017-07-18 12:30 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2017-07-18 12:30 UTC (permalink / raw)
To: ludo, dannym; +Cc: 27735
[-- Attachment #1.1: Type: text/plain, Size: 235 bytes --]
Ludo',
On 18/07/17 12:09, Ludovic Courtès wrote:
> Can we do ‘string-map’ to replace dash with underscore, just like we did
> ‘normalize-label’?
That would have been a better approach. :-)
Kind regards,
T G-R
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 504 bytes --]
^ permalink raw reply [relevance 99%]
* bug#27735: Unbootable images with GuixSD on... "GuixSD"
@ 2017-07-18 15:09 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2017-07-18 15:09 UTC (permalink / raw)
To: ludo, dannym; +Cc: 27735
[-- Attachment #1.1: Type: text/plain, Size: 1483 bytes --]
Ludo',
On 18/07/17 13:49, Ludovic Courtès wrote:
> What about generating a UUID in a deterministic yet somewhat unique
> fashion along these lines (untested):
Not great, but I can't think of a better way. :-)
> + (define root-uuid
> + ;; UUID of the root file system, computed in a deterministic fashion.
> + (if (string=? "iso9660" file-system-type)
> + (let ((pad (compose (cut string-pad <> 2 #\0)
> + number->string)))
> + (string->iso9660-uuid
> + (string-append "1970-01-01-"
> + (pad (hash name 24))
> + (pad (hash file-system-type 60))
> + (pad (hash (operating-system-host-name os) 60)))))
> + (uint-list->bytevector
> + (list (hash (string-append file-system-type name)
> + (expt 2 64))
> + (hash (operating-system-host-name os)
> + (expt 2 64)))
> + (endianness little)
> + 8)))
> +
Why not throw SIZE into this mix as well?
When building without ‘--image-size’ (the default nowadays), it's a
function of the exact size of the entire graph and reasonably sensitive
to most kinds of input changes.
> We cannot use the store file name’s hash, unfortunately, because the
> UUID has to be given on the “host side.”
That is unfortunate, but a best-effort heuristic will do.
Kind regards,
T G-R
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 504 bytes --]
^ permalink raw reply [relevance 99%]
* bug#27735: Unbootable images with GuixSD on... "GuixSD"
@ 2017-07-18 20:42 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2017-07-18 20:42 UTC (permalink / raw)
To: ludo; +Cc: 27735
[-- Attachment #1.1: Type: text/plain, Size: 366 bytes --]
Ludo',
On 18/07/17 20:59, Ludovic Courtès wrote:
>> Why not throw SIZE into this mix as well?
>
> Because it can be the symbol 'guess or a number, so that makes things
> needlessly complicated IMO.
Of course. Thanks for your patience. I got completely lost in the
gexp/ungexps of expression->derivation-in-linux-vm. Stupid.
Kind regards,
T G-R
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 504 bytes --]
^ permalink raw reply [relevance 99%]
* bug#29593: [web site] Broken links in the HTML manual
@ 2017-12-06 19:35 93% Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2017-12-06 19:35 UTC (permalink / raw)
To: 29593
Guix,
[Opening a new bug for these, rather than further overloading #29591.]
I'm celebrating the new Guix web with a quick and certainly incomplete
sweep for dead links in the HTML manual at gnu.org. I think (though I
have no data to back this up) that a significant number of newer users
are far more likely to use this version than any copy shipped with Guix.
Young people and their webs and all that.
So far, I've found the following:
- Defining Packages[0]:
“GNU configuration triplets” is broken.
It points inside the Guix manual, not autoconf's.
- Package Management[1]:
“The Emacs-Guix Reference Manual” is broken.
It points to a URI with duplicate ‘/index.html’s.
- Using the Offload Facility[2]:
“Converting keys” points to #Converting-keys, the target site uses
#Converting%20keys. I don't know who's right. The page still loads
so the user can navigate manually, but it would still be nice to fix.
- Formatting Code[3]:
Similarly points to ‘index.html/Development.html’ when it should use
only ‘Development.html’.
- Networking Services[4]:
“lsh-make-seed” and “lshd basics” also use bad anchors, so the user
has to search and scroll.
- The Perfect Setup[5]:
“Introduction in the Geiser User Manual” is a broken link.
- Continuous Integration[6]:
“Associations Lists in GNU Guile Reference Manual” is broken.
It points inside the Guix manual, not Guile's.
- Mapped Devices[7]:
“Translators in The GNU Hurd Reference Manual” is broken.
It points inside the Guix manual, not The Hurd's.
- Documentation[8]:
“Getting Started in Info: An Introduction” is broken.
Even without any Texinfo knowledge, I thought this would be easy to
quickly fix myself. I had no such luck.
Kind regards,
T G-R
[0]:
https://www.gnu.org/software/guix/manual/html_node/Defining-Packages.html
[1]:
https://www.gnu.org/software/guix/manual/html_node/Package-Management.html
[2]:
https://www.gnu.org/software/guix/manual/html_node/Daemon-Offload-Setup.html
[3]: https://www.gnu.org/software/guix/manual/html_node/Formatting-Code.html
[4]:
https://www.gnu.org/software/guix/manual/html_node/Networking-Services.html
[5]:
https://www.gnu.org/software/guix/manual/html_node/The-Perfect-Setup.html
[6]:
https://www.gnu.org/software/guix/manual/html_node/Continuous-Integration.html
[7]: https://www.gnu.org/software/guix/manual/html_node/Mapped-Devices.html
[8]: https://www.gnu.org/software/guix/manual/html_node/Documentation.html
^ permalink raw reply [relevance 93%]
* bug#29593: [web site] Broken links in the HTML manual
@ 2017-12-07 22:52 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2017-12-07 22:52 UTC (permalink / raw)
To: ludo; +Cc: 29593
Ludo',
Ludovic Courtès wrote on 07/12/17 at 22:11:
> most of them are Texinfo links derived from what doc/htmlxref.cnf specifies.
Thanks! I thought as much. I thought these would be trivial to fix, but
it's a bit more involved than just twiddling some URIs. I'll take
another look.
> I’ll see if I can get around to fixing those
This bug serves mainly to keep track of what needs fixing and remind
myself to do so. I don't expect anyone to jump.
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#29674: Ceph creates Btrfs subvolumes on Btrfs during tests.
@ 2017-12-12 16:13 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2017-12-12 16:13 UTC (permalink / raw)
To: ludo, rhelling; +Cc: 29674
Ludovic Courtès wrote on 12/12/17 at 17:03:
> So does guix-daemon systematically leave /tmp/guix-build-ceph* behind it?
Almost certainly. I can confirm several hundred previously unknown
subvolumes filling up my btrfs substitute server. Time to clean up.
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#29674: Ceph creates Btrfs subvolumes on Btrfs during tests.
@ 2017-12-27 23:16 99% ` Tobias Geerinckx-Rice
2017-12-28 4:30 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2017-12-27 23:16 UTC (permalink / raw)
To: rhelling, 29674
[-- Attachment #1.1: Type: text/plain, Size: 339 bytes --]
Rutger,
Rutger Helling wrote on 27/12/17 at 23:50:
> This bug has been open for quite a while now.
> If there are no objections in the next few days, I'd like to disable the
> tests entirely for now with a FIXME on finding and disabling only the
> offending tests.
No objections if it's in a few days.
Kind regards,
T G-R
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 248 bytes --]
^ permalink raw reply [relevance 99%]
* bug#29674: Ceph creates Btrfs subvolumes on Btrfs during tests.
2017-12-27 23:16 99% ` Tobias Geerinckx-Rice
@ 2017-12-28 4:30 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2017-12-28 4:30 UTC (permalink / raw)
To: rhelling, 29674
[-- Attachment #1.1: Type: text/plain, Size: 225 bytes --]
Tobias Geerinckx-Rice wrote on 28/12/17 at 00:16:
> No objections if it's in a few days.
Actually, the fix I was hacking on appears as dead an end as all the others.
No objections any day.
Kind regards,
T G-R
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 248 bytes --]
^ permalink raw reply [relevance 99%]
* bug#30113: SVN checkouts without descriptive file names
@ 2018-01-14 16:43 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2018-01-14 16:43 UTC (permalink / raw)
To: boskovits, leo; +Cc: 30113
Gábor Boskovits wrote on 14/01/18 at 17:13:
> Maybe we could use guix to check for these, and some
> other things could also be spotted.
> WDYT?
Agreed, I think.
I don't see how defaulting to ‘...${VCS_TYPE}-checkout’ ever makes sense
or saves effort.
We should be able to improve the quality of these guesses: the
repository URI is about as likely to be foo://bar/<package>... as a
regular tarball URI.
Or we make a file-name mandatory for certain methods.
*goes to look at the actual code*,
T G-R
^ permalink raw reply [relevance 99%]
* bug#30113: SVN checkouts without descriptive file names
@ 2018-01-14 19:34 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-01-14 19:34 UTC (permalink / raw)
To: boskovits; +Cc: 30113
Gábor Boskovits wrote on 14/01/18 at 20:28:
> Here is the lint log, it did not run to completion, it has an error at
> the end.
I started ‘guix lint’ after my first message too; with some luck it will
(eventually...) complete.
Thanks,
T G-R
^ permalink raw reply [relevance 99%]
* bug#30785: Man pages truncated, repeated
@ 2018-03-12 21:24 99% Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2018-03-12 21:24 UTC (permalink / raw)
To: 30785
Guix,
Perhaps he's just getting old, but our man has a tendency to forget
where he was, start over from the beginning, and repeat himself several
times:
$ guix package -i knot rofi
$ man 5 knot.conf | grep -E '^(NAME|DESCRIPTION)'
NAME
DESCRIPTION
NAME
DESCRIPTION
NAME
DESCRIPTION
NAME
DESCRIPTION
NAME
$
There's also some stderr...
<standard input>:25: error: end of file while defining macro
`UNINDENT'
...but I think that's just a symptom of the input being cut short; man
rofi(1) prints no such error yet suffers the same fate.
The affected man pages themselves are not truncated, nor do they repeat:
$ zgrep '\.SH' `man -w knot.conf`
.SH NAME
.SH DESCRIPTION
.SH COMMENTS
.SH INCLUDES
.SH MODULE SECTION
.SH SERVER SECTION
.SH KEY SECTION
.SH ACL SECTION
.SH CONTROL SECTION
.SH STATISTICS SECTION
.SH KEYSTORE SECTION
.SH SUBMISSION SECTION
.SH POLICY SECTION
.SH REMOTE SECTION
.SH TEMPLATE SECTION
.SH ZONE SECTION
.SH LOGGING SECTION
.SH AUTHOR
.SH COPYRIGHT
$
However, even longer man pages such as bash(1) render without fail, so
there might be something special about the two examples above that
triggers this behaviour.
Kind regards,
T G-R
Sent from a Web browser. Excuse or enjoy my brevity.
^ permalink raw reply [relevance 99%]
* bug#30785: Man pages truncated, repeated
@ 2018-03-13 22:01 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-03-13 22:01 UTC (permalink / raw)
To: ludo; +Cc: 30785
Ludo',
On 2018-03-13 22:34, ludo@gnu.org wrote:
>> However, even longer man pages such as bash(1) render without fail, so
>> there might be something special about the two examples above that
>> triggers this behaviour.
>
> I suspect something wrong with ‘knot.conf.5.gz’, but I don’t have
> tangible evidence.
Yup, that's about as far as I got before giving up and submitting to the
wisdom of the crowd. We need someone who knows something — anything —
about man pages, or someone who can reproduce this on another distro. I
had no luck searching for similar bug reports.
...or do you mean with the knot.conf page *specifically*, as opposed to
the rofi one? Is your suspicion based on something you saw in there?
It's not the .gz part: opening the uncompressed page with man directly
has the same result.
--
For the record: apparently this doesn't happen on Debian, according to
some fellow on IRC named ‘civodul’. There goes my brief hope that this
was an (exclusively) upstream problem after all.
Kind regards,
T G-R
Sent from a Web browser. Excuse or enjoy my brevity.
^ permalink raw reply [relevance 99%]
* bug#30890: Hash mismatch for /gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids
@ 2018-03-21 15:46 99% ` Tobias Geerinckx-Rice
2018-03-21 16:08 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2018-03-21 15:46 UTC (permalink / raw)
To: Vivien Kraus; +Cc: 30890
Vivien,
On 2018-03-21 12:05, Vivien Kraus wrote:
> Could someone confirm this hash?
I can confirm both.
> sha256 hash mismatch for output path
> `/gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids'
> expected: 17rg5i0wbyk289gr8v4kgvnc9q5bidz7ldcvv9x58l083wn16hq3
> actual: 1wzkaan87ncx80hgddii01cqk5gw8mrm5kb2xf6w9fwa4h53gin5
Here's the beginning of a very long diff between those two:
--- 17rg5i0wbyk289gr8v4kgvnc9q5bidz7ldcvv9x58l083wn16hq3 (old)
+++ 1wzkaan87ncx80hgddii01cqk5gw8mrm5kb2xf6w9fwa4h53gin5 (‘new’)
@@ -1,16 +1,10 @@
#
# List of USB ID's
#
-# Maintained by Stephen J. Gowdy <linux.usb.ids@gmail.com>
-# If you have any new entries, please submit them via
-# http://www.linux-usb.org/usb-ids.html
-# or send entries as patches (diff -u old new) in the
-# body of your email (a bot will attempt to deal with it).
-# The latest version can be obtained from
-# http://www.linux-usb.org/usb.ids
+# Maintained by Vojtech Pavlik <vojtech@suse.cz>
+# If you have any new entries, send them to the maintainer.
#
-# Version: 2017.02.12
-# Date: 2017-02-12 20:34:05
+# $Id: usb.ids,v 1.111 2003-01-02 13:05:30 vojtech Exp $
If those dates are at all reliable, we're now downloading a very old
copy. Which this suggests:
$ wc -l OLD NEW # ‘NEW’ being SVN upstream
20663 OLD
4043 NEW
I've not actually been following this thread so I don't know what that
means, but it looks like simply using the CVS revision as the SVN one
might not work.
Kind regards,
T G-R
Sent from a Web browser. Excuse or enjoy my brevity.
^ permalink raw reply [relevance 99%]
* bug#30890: Hash mismatch for /gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids
2018-03-21 15:46 99% ` Tobias Geerinckx-Rice
@ 2018-03-21 16:08 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2018-03-21 16:08 UTC (permalink / raw)
To: 30890
[-- Attachment #1: Type: text/plain, Size: 456 bytes --]
I couldn't resist, of course.
On 2018-03-21 16:46, Tobias Geerinckx-Rice wrote:
> I've not actually been following this thread so I don't know what that
> means, but it looks like simply using the CVS revision as the SVN one
> might not work.
The attached patch solves this by simply updating usb.ids to the latest
revision.
I'm building it on the slowest laptop I could find.
Kind regards,
T G-R
Sent from a Web browser. Excuse or enjoy my brevity.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gnu-libosinfo-Update-usb.ids.patch --]
[-- Type: text/x-diff; name=0001-gnu-libosinfo-Update-usb.ids.patch, Size: 1562 bytes --]
From 0d73f1481bf732147af7751a6ae58114bd3876db Mon Sep 17 00:00:00 2001
From: Tobias Geerinckx-Rice <me@tobias.gr>
Date: Wed, 21 Mar 2018 16:59:31 +0100
Subject: [PATCH 1/2] gnu: libosinfo: Update usb.ids.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This follows up commit 0def9120882f90372fd6bb2e80e8330d67745610, which
tried to use the CVS ID as the SVN revision, which unfortunately doesn't
work.
* gnu/packages/virtualization.scm (libosinfo)[native-inputs]: Update
revision and hash for ‘usb.ids’.
---
gnu/packages/virtualization.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gnu/packages/virtualization.scm b/gnu/packages/virtualization.scm
index 37bf09f23..de01e0163 100644
--- a/gnu/packages/virtualization.scm
+++ b/gnu/packages/virtualization.scm
@@ -281,11 +281,11 @@ server and embedded PowerPC, and S390 guests.")
("usb.ids"
,(origin
(method url-fetch)
- (uri "https://svn.code.sf.net/p/linux-usb/repo/trunk/htdocs/usb.ids?r=1551")
+ (uri "https://svn.code.sf.net/p/linux-usb/repo/trunk/htdocs/usb.ids?r=2681")
(file-name "usb.ids")
(sha256
(base32
- "17rg5i0wbyk289gr8v4kgvnc9q5bidz7ldcvv9x58l083wn16hq3"))))))
+ "1m6yhvz5k8aqzxgk7xj3jkk8frl1hbv0h3vgj4wbnvnx79qnvz3r"))))))
(home-page "https://libosinfo.org/")
(synopsis "Operating system information database")
(description "libosinfo is a GObject based library API for managing
--
2.15.1
^ permalink raw reply related [relevance 99%]
* bug#30890: Hash mismatch for /gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids
@ 2018-03-21 17:05 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-03-21 17:05 UTC (permalink / raw)
To: Vivien Kraus; +Cc: 30890
Vivien,
On 2018-03-21 18:01, Vivien Kraus wrote:
> Sorry for the mess with the mails. This new versions and its hash work
> for me, thanks!
I didn't notice a mess :-)
Works here too. Pushed as 0d73f1481bf732147af7751a6ae58114bd3876db.
Kind regards,
T G-R
Sent from a Web browser. Excuse or enjoy my brevity.
^ permalink raw reply [relevance 99%]
* bug#30890: Hash mismatch for /gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids
@ 2018-03-21 17:24 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-03-21 17:24 UTC (permalink / raw)
To: Vivien Kraus; +Cc: 30890
Vivien,
On 2018-03-21 7:54, Vivien Kraus wrote:
> I don't know on what the hash depends; maybe it also depends on the
> URL?
It depends only on the contents. This allows us to use a list of
different URIs (see the lsof package for an example) or try many
different mirror://s as long as they serve the right file.
> Should I change the hash in virtualization.scm?
In general: yes, but not without prior investigation.
The server might be serving a temporary error page instead of a usable
tarball (SF.net is currently notorious for doing so), or the tarball
might have been updated in-place (and you'll have to manually diff the
contents to make sure it's legitimate), or it might just be a problem
with your network, or...
Pushing a hash update without explanation in the commit message will
result in lots of spam from people like me. Avoid that.
Kind regards,
T G-R
Sent from a Web browser. Excuse or enjoy my brevity.
^ permalink raw reply [relevance 99%]
* bug#30006: bzip2 does not provide libbz2.so
@ 2018-03-23 12:19 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2018-03-23 12:19 UTC (permalink / raw)
To: Marius Bakke; +Cc: 30006
Marius,
On 2018-03-23 13:02, Marius Bakke wrote:
> diff --git a/gnu/packages/compression.scm
> b/gnu/packages/compression.scm
> index b158feac4..fd111e579 100644
> --- a/gnu/packages/compression.scm
> +++ b/gnu/packages/compression.scm
> @@ -272,6 +272,9 @@ file; as a result, it is often used in conjunction
> with \"tar\", resulting in
> (lambda* (#:key outputs #:allow-other-keys)
> (let* ((out (assoc-ref outputs "out"))
> (libdir (string-append out "/lib")))
> + ;; The Make target above does not create "libbz2.so",
> only
> + ;; the versioned libs, so we have to create it
> ourselves.
> + (symlink "libbz2.so.1.0" "libbz2.so")
How about symlinking to (string-append ... version) directly?
Seems more robust & worked fine when I tried it, I think.™
Kind regards,
T G-R
Sent from a Web browser. Excuse or enjoy my brevity.
^ permalink raw reply [relevance 99%]
* bug#30006: bzip2 does not provide libbz2.so
@ 2018-03-24 1:17 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-03-24 1:17 UTC (permalink / raw)
To: Marius Bakke; +Cc: 30006
Marius, Mark,
On 2018-03-23 21:50, Mark H Weaver wrote:
> Hi,
>
> Tobias Geerinckx-Rice <me@tobias.gr> writes:
>
>> On 2018-03-23 13:02, Marius Bakke wrote:
>>> diff --git a/gnu/packages/compression.scm
>>> b/gnu/packages/compression.scm
>>> index b158feac4..fd111e579 100644
>>> --- a/gnu/packages/compression.scm
>>> +++ b/gnu/packages/compression.scm
>>> @@ -272,6 +272,9 @@ file; as a result, it is often used in
>>> conjunction with \"tar\", resulting in
>>> (lambda* (#:key outputs #:allow-other-keys)
>>> (let* ((out (assoc-ref outputs "out"))
>>> (libdir (string-append out "/lib")))
>>> + ;; The Make target above does not create "libbz2.so",
>>> only
>>> + ;; the versioned libs, so we have to create it
>>> ourselves.
>>> + (symlink "libbz2.so.1.0" "libbz2.so")
>>
>> How about symlinking to (string-append ... version) directly?
>> Seems more robust & worked fine when I tried it, I think.™
>
> In general, the version numbers at the end of shared library names like
> "libbz2.so.1.0" do not necessarily match the version number of the
> corresponding source release. Therefore, I don't think we should write
> code that assumes that those two versions will coincide.
Do note that I'm not suggesting doing so in general; just in the case of
bzip2 where that rule does historically hold. If that ever changes, so
will the ‘1.0’ assumption.
(I did substitute ‘version’ for the ‘version-major+minor’ I actually
used for... simplicity, I guess, which was probably ill advised.)
> However, I agree that it would be better not to hardcode the "1.0". I
> would suggest using 'find-files' to find the versioned shared library,
> and to verify that there is exactly one match. (ice-9 match) provides
> an elegant way to check for a singleton list while matching its
> element.
I wasn't aware of such an elegant possibility. A perfect fit IMO :-)
Thanks,
T G-R
Sent from a Web browser. Excuse or enjoy my brevity.
^ permalink raw reply [relevance 99%]
* bug#31321: perl-test-www-mechanize: Duplicate 'native-inputs' field.
@ 2018-05-07 22:00 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-05-07 22:00 UTC (permalink / raw)
To: 31321
/me perks ears
I didn't know about this bug, but I'm glad it is fixed!
Kind regards,
T G-R
On Mon, May 7, 2018 at 10:02 PM, Mark H Weaver <mhw@netris.org> wrote:
> This bug was fixed in commit a7e8e75c4b34a3bebae1efb139e18924761a603c
> by
> Tobias Geerinckx-Rice <me@tobias.gr>. I'm closing this bug now.
>
> Thanks,
> Mark
>
>
>
^ permalink raw reply [relevance 99%]
* bug#31652: Use of ‘keymap’ vs. ‘layout’ in manual
@ 2018-05-30 3:49 99% Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-05-30 3:49 UTC (permalink / raw)
To: 31652
Guix,
Grepping the manual for ‘keyboard layout’ will get you to section
6.1.4.1 (setting the layout temporarily during installation using
loadkeys), but not 6.2.7.1 where you might learn about using
console-keymap-service to make the change permanent.
This bug is a reminder to myself to replace at least one
occurrence of ‘keymap’ with the common term.
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#32058: mysql build fails on d88b29d6b78482cdb05ac714984f6a27195e3d37
@ 2018-07-05 11:31 86% ` Tobias Geerinckx-Rice
2018-08-15 23:15 97% ` bug#32058: [PATCH] gnu: mysql: Fix build Tobias Geerinckx-Rice
1 sibling, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-07-05 11:31 UTC (permalink / raw)
To: Nils Gillmann; +Cc: 32058
ng0,
Thanks!
Nils Gillmann wrote:
> Since I do not have the time to work on this, but there seems to
> be no open bug:
>
> mysql started a couple of commits ago (since last core-updates
> merge?) to fail
> its build.
I noticed this yesterday, too. In the meantime, I've tried
updating MySQL to 5.7.22 (one never knows) and poking at some
random bits but that didn't help.
> [build output snipped]
There's actually an error message[0]. Did it not show up in your
logs? I'd consider that a bug too.
If I had to guess I'd say that a GCC bump's to blame. Or maybe
Boost, though that seems unlikely.
Unfortunately, I also don't have the time to debug this now or
indeed the next month.
Kind regards,
T G-R
[0]:
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:
In function ‘void handle_gis_exception(const char*)’:
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:37:81:
error: expected unqualified-id before ‘&’ token
catch (const
boost::geometry::detail::self_get_turn_points::self_ip_exception
&)
^
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:37:81:
error: expected ‘)’ before ‘&’ token
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:37:81:
error: expected ‘{’ before ‘&’ token
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:37:82:
error: expected primary-expression before ‘)’ token
catch (const
boost::geometry::detail::self_get_turn_points::self_ip_exception
&)
^
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:42:3:
error: expected primary-expression before ‘catch’
catch (const boost::geometry::empty_input_exception &)
^
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:46:3:
error: expected primary-expression before ‘catch’
catch (const boost::geometry::inconsistent_turns_exception &)
^
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:50:3:
error: expected primary-expression before ‘catch’
catch (const boost::geometry::exception &)
^
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:54:3:
error: expected primary-expression before ‘catch’
catch (const std::bad_alloc &e)
^
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:58:3:
error: expected primary-expression before ‘catch’
catch (const std::domain_error &e)
^
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:62:3:
error: expected primary-expression before ‘catch’
catch (const std::length_error &e)
^
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:66:3:
error: expected primary-expression before ‘catch’
catch (const std::invalid_argument &e)
^
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:70:3:
error: expected primary-expression before ‘catch’
catch (const std::out_of_range &e)
^
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:74:3:
error: expected primary-expression before ‘catch’
catch (const std::overflow_error &e)
^
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:78:3:
error: expected primary-expression before ‘catch’
catch (const std::range_error &e)
^
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:82:3:
error: expected primary-expression before ‘catch’
catch (const std::underflow_error &e)
^
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:86:3:
error: expected primary-expression before ‘catch’
catch (const std::logic_error &e)
^
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:90:3:
error: expected primary-expression before ‘catch’
catch (const std::runtime_error &e)
^
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:94:3:
error: expected primary-expression before ‘catch’
catch (const std::exception &e)
^
/tmp/guix-build-mysql-5.7.21.drv-0/mysql-5.7.21/sql/item_geofunc_internal.cc:98:3:
error: expected primary-expression before ‘catch’
catch (...)
^
make[2]: *** [sql/CMakeFiles/sql.dir/build.make:583:
sql/CMakeFiles/sql.dir/item_geofunc_internal.cc.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory
'/tmp/guix-build-mysql-5.7.21.drv-0/build'
^ permalink raw reply [relevance 86%]
* bug#32058: [PATCH] gnu: mysql: Fix build.
2018-07-05 11:31 86% ` Tobias Geerinckx-Rice
@ 2018-08-15 23:15 97% ` Tobias Geerinckx-Rice
1 sibling, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2018-08-15 23:15 UTC (permalink / raw)
To: 32058
MySQL demands boost@1.59.0, and lying about it no longer works:
sql/item_geofunc_internal.cc: In function ‘void handle_gis_exception(const char*)’:
sql/item_geofunc_internal.cc:37:81: error: expected unqualified-id before ‘&’ token
catch (const boost::geometry::detail::self_get_turn_points::self_ip_exception &)
^
[...]
* gnu/packages/databases.scm (boost-for-mysql): New variable.
(mysql)[inputs]: Use that instead of the regular boost.
[arguments]: Remove now-unnecessary ‘patch-boost-version’ phase.
---
ng0, Ricardo,
I went on holiday and forgot about this bug. A healthy sign.
Here's the straightforward fix to unbreak the current build.
I suggest we get 5.x working soon (I'll bump it to 5.7.23 if this fix
is acceptable) and update to 8.x later, when/if somebody's willing to
work on it. I'm not.
Kind regards,
T G-R
gnu/packages/databases.scm | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm
index 87c925a6b..cb77edeaf 100644
--- a/gnu/packages/databases.scm
+++ b/gnu/packages/databases.scm
@@ -548,6 +548,22 @@ RDBMS systems (which are deep in functionality).")
;; Some parts are licensed under the Apache License
license:asl2.0))))
+(define boost-for-mysql
+ (package
+ (inherit boost)
+ (version "1.59.0")
+ (source (origin
+ (method url-fetch)
+ (uri (string-append
+ "mirror://sourceforge/boost/boost/" version "/boost_"
+ (string-map (lambda (x) (if (eq? x #\.) #\_ x)) version)
+ ".tar.bz2"))
+ (sha256
+ (base32
+ "1jj1aai5rdmd72g90a3pd8sw9vi32zad46xv5av8fhnr48ir6ykj"))))))
+
+;; XXX When updating, check whether boost-for-mysql is still needed.
+;; It might suffice to patch ‘cmake/boost.cmake’ as done in the past.
(define-public mysql
(package
(name "mysql")
@@ -588,15 +604,6 @@ RDBMS systems (which are deep in functionality).")
"-DINSTALL_MYSQLTESTDIR="
"-DINSTALL_SQLBENCHDIR=")
#:phases (modify-phases %standard-phases
- (add-after
- 'unpack 'patch-boost-version
- (lambda _
- ;; Mysql wants boost-1.59.0 specifically
- (substitute* "cmake/boost.cmake"
- (("59")
- ,(match (string-split (package-version boost) #\.)
- ((_ minor . _) minor))))
- #t))
(add-after
'install 'remove-extra-binaries
(lambda* (#:key outputs #:allow-other-keys)
@@ -611,7 +618,7 @@ RDBMS systems (which are deep in functionality).")
`(("bison" ,bison)
("perl" ,perl)))
(inputs
- `(("boost" ,boost)
+ `(("boost" ,boost-for-mysql)
("libaio" ,libaio)
("ncurses" ,ncurses)
("openssl" ,openssl)
--
2.18.0
^ permalink raw reply related [relevance 97%]
* bug#32459: Strace 4.24 doesn't build
@ 2018-08-16 18:14 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2018-08-16 18:14 UTC (permalink / raw)
To: Clément Lassieur; +Cc: 32459
Clément,
Clément Lassieur wrote:
> Strace 4.24 doesn't build (on my machine).
>
> Once I had:
>
> FAIL: trace_personality_32.gen.test
>
> And another time:
>
> FAIL: trace_personality_regex_32.gen.test
> FAIL: trace_stat_like.gen.test
> FAIL: trace_stat.gen.test
> FAIL: trace_statfs_like.gen.test
> FAIL: trace_question.gen.test
>
> And a third time:
>
> FAIL: trace_personality_regex_x32.gen.test
> FAIL: trace_personality_64.gen.test
>
> So it's undeterministic.
Thanks for the report. I can't reproduce this failure.
I've successfully built[0] strace@4.24 five times so far, on a
modest 4-core x86-64 machine. All builds are bit-identical.
Does disabling build and/or test parallelism make a difference?
Kind regards,
T G-R
[0]: /gnu/store/9pxi8mhvcrd9wlllfsl2rs104qc38z8r-strace-4.24
^ permalink raw reply [relevance 99%]
* bug#32360: gst-plugins-base has test failures (when built as a dependency)
@ 2018-08-18 11:34 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-08-18 11:34 UTC (permalink / raw)
To: Pjotr Prins, Leo Famulari; +Cc: 32360-done
Pjotr, Leo, Guix,
Pjotr Prins wrote:
> Someone still needs to push the patch.
I went ahead and did so in
399c5fafcdb2d0c13ab51e4ab57d451d2c7cb1bd
since it's not really acceptable to have this broken in master.
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#32459: Strace 4.24 doesn't build
@ 2018-08-18 11:36 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-08-18 11:36 UTC (permalink / raw)
To: Clément Lassieur; +Cc: 32459-done
Clément,
Clément Lassieur wrote:
> I was using a modest 32-core x86-64 machine.
I always forget who owns that one :-)
> Tobias Geerinckx-Rice <me@tobias.gr> writes:
>
>> Does disabling build and/or test parallelism make a difference?
>
> Yes, it works with '#:parallel-tests? #f'!
Great! Fix pushed in 72e782b2b587d05e89b2ca9b27b30c93653760f5.
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#32058: [PATCH] gnu: mysql: Fix build.
@ 2018-08-20 18:33 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-08-20 18:33 UTC (permalink / raw)
To: 32058-done
Marius Bakke wrote:
> Tobias Geerinckx-Rice <me@tobias.gr> writes:
[...]
>> * gnu/packages/databases.scm (boost-for-mysql): New variable.
>> (mysql)[inputs]: Use that instead of the regular boost.
>> [arguments]: Remove now-unnecessary ‘patch-boost-version’
>> phase.
>
> Ouch. Boost is a *huge* library, but now that we no longer use
> the
> MySQL package as the main MySQL library (e.g. for Qt), giving it
> a
> different boost version seems reasonable to me.
Pushed in 7cbf06d8c2935abfc6c688cf3f9b99e0e5393960,
bumped in 8ecf3f7ea515d555e978bea3c1610d44345a44ee.
Thanks!
T G-R
^ permalink raw reply [relevance 99%]
* bug#32789: Bash finds old version of guix after guix pull
@ 2018-09-21 8:05 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-09-21 8:05 UTC (permalink / raw)
To: Alex Branham; +Cc: 32789
Alex,
Alex Branham wrote:
> After installing guixsd (0.15) on a VM and doing "guix pull",
> "guix --version"
> gives 0.14-<stuff>.
>
> I asked about this on IRC a few weeks ago and got a helpful
> answer. All
> I needed to do to fix is was to run a simple bash command.
> Unfortunately, I've forgotten what that was :-(
Was it
$ set +h
?
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#32855: sshuttle /usr/bin/env
@ 2018-09-27 19:11 99% ` Tobias Geerinckx-Rice
1 sibling, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-09-27 19:11 UTC (permalink / raw)
To: Nam Nguyen; +Cc: 32855
Hullo,
Thanks for the report!
Nam Nguyen wrote:
> sshuttle is a python program that uses /usr/bin/env at line 196
> of:
> /gnu/store/...-sshuttle-0.78.4/lib/python3.6/site-packages/sshuttle/client.py
> ['sudo', '-p', '[local sudo] Password: ', '/usr/bin/env',
>
> Trying to run sshuttle on GuixSD results in:
> $ sshuttle -r user@server.com 0/0 -x server.com
> sudo: /usr/bin/env: command not found
This means that sshuttle on vanilla GuixSD has been broken ever
since I added it in 2016, which saddens me. I guess nobody else
uses it or, like me, they happen to also have a /usr/bin/env
symlink.
> Here is a potential fix that I recycled from sshoot's recipe. I
> tested it,
> and it works.
>
> $ diff
> ~/.config/guix/current/share/guile/site/2.2/gnu/packages/vpn.scm
> ~/vpn.scm
> 349a350,357
>> (arguments
>> '(#:phases
>> (modify-phases %standard-phases
>> (add-after 'unpack 'patch-paths
>> (lambda _
>> (substitute* "sshuttle/client.py"
>> (("/usr/bin/env") (which "env")))
>> #t)))))
I'll push this soon. Is it all right if I mention your name &
e-mail in the commit message?
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#32855: sshuttle /usr/bin/env
@ 2018-09-27 22:04 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2018-09-27 22:04 UTC (permalink / raw)
To: Nam Nguyen; +Cc: 32855-done
Nam Nguyen wrote:
> Yes, feel free to mention my name and e-mail.
Pushed as 6a6f7488df1794828e1845eaaf2c1c911c8e3e54.
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#32845: guix.info: Missing manual
@ 2018-09-28 20:39 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-09-28 20:39 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: Pierre Neidhardt, 32845
Ludo', Guix,
Ludovic Courtès wrote:
> Ricardo Wurmus <rekado@elephly.net> skribis:
>> “certbot” can be used with manual DNS validation, which
>> requires us to deploy a DNS TXT record. This can be automated
>> with
>> certbot hooks (scripts that have access to the token that
>> should be
>> published via environment variables) or through JSON mode,
>> which returns
>> an object with the token that can be processed through other
>> means.
>
> I didn’t know about all this! Looks like our Certbot service
> doesn’t
> support it though?
Not out of the box, and last time I checked vanilla certbot didn't
provide an nsupdate (RFC2136) hook alongside all the DNSaaS API
rubbish.
But it's certainly possible, and wonderfully stable once set
up. t.gr runs entirely on GuixSD + Knot + DNS-validated LE certs.
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#32855: sshuttle /usr/bin/env
@ 2018-09-30 11:52 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2018-09-30 11:52 UTC (permalink / raw)
To: Nam Nguyen; +Cc: 32855
Hullo,
Nam Nguyen wrote:
> Hi Tobias,
>
> After testing, I think the /bin/sh substitution introduced a
> regression.
>
> Lines in question:
> (substitute* "sshuttle/ssh.py"
> ;; Perhaps this is unreachable, but don't let's take risks.
Oh, the irony.
> (("/bin/sh") (which "sh")))
This is just wrong: it calls the client's /gnu/store/.../sh on the
server.
> $ sshuttle -r user <at> server.com 0/0 -x server.com
> ksh: /gnu/store/rb...-bash-minimal-4.4.19/bin/sh: not found
> client: fatal: server died with error code 127
>
> The server I am sshing to is not running GuixSD. It is trying to
> find
> /gnu/store/.../bin/sh but it doesn't exst.
That's a good point (all my remotes run GuixSD, hiding the bug).
> The only requirements on the server side should be Python.
It's all well & good for upstream to say that (they do), but if
they explicitly call /bin/sh on the server then it's just not
true. A POSIX-compliant 'sh' was always an unstated server-side
dependency, and Guix happens to be very good at finding (and
breaking :-) those.
The hard-coded '/bin/' kluge was accepted later¹. Can't fathom
why. If brianmay's last comment is still true they'll accept the
correct 'exec sh' solution too.
Could you check whether replacing '(which "sh")' with '"sh"'
works? It does for me.
> Should those lines should be removed? I tested without, and it
> seems to work okay,
> at least for my particular setup: GuixSD client --> non-GuixSD
> server.
Wouldn't that break [any client -> vanilla GuixSD server] cases?
No denying that this regression needs to be fixed,
though. Apologies for breaking your 'flow.
> I suppose we have to state the assumptions of whether the client
> and
> server are running Guix or not, and arrive at good defaults.
I'd like to avoid such assumptions in general, and entirely on the
Internet.
Kind regards,
T G-R
1. https://github.com/sshuttle/sshuttle/pull/77
^ permalink raw reply [relevance 99%]
* bug#32855: sshuttle /usr/bin/env
@ 2018-10-06 14:49 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-10-06 14:49 UTC (permalink / raw)
To: Marius Bakke; +Cc: 32855, Nam Nguyen
Marius,
Marius Bakke wrote:
> Note that /bin/sh is present even on vanilla GuixSD.
Thanks. I should probably give this vanilla GuixSD of which you
speak a try some time :-)
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#33189: Touchpad tap
@ 2018-10-29 0:44 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-10-29 0:44 UTC (permalink / raw)
To: Luther Thompson, znavko; +Cc: 33189, Pierre Neidhardt, help-guix
Luther,
Luther Thompson wrote:
> Section \"InputClass\"
> Identifier \"touchpad-all\"
> MatchIsTouchpad \"on\"
> Option \"DisableWhileTyping\" \"on\"
> Option \"Tapping\" \"on\"
> EndSection"
[...]
> Neither DisableWhileTyping nor Tapping has any effect. I also
> set the
> corresponding settings in Gnome Tweaks > Keyboard & Mouse >
> Touchpad.
> If I need a Driver field or some specific Identifier, I haven't
> been
> able to find a way to determine the correct info for those
> fields.
Here's what I use:
Section \"InputClass\"
Identifier \"Touchpads\"
Driver \"libinput\"
MatchDevicePath \"/dev/input/event*\"
MatchIsTouchpad \"on\"
Option \"DisableWhileTyping\" \"on\"
Option \"MiddleEmulation\" \"on\"
Option \"ClickMethod\" \"clickfinger\"
Option \"Tapping\" \"on\"
Option \"TappingButtonMap\" \"lrm\"
Option \"TappingDrag\" \"on\"
Option \"ScrollMethod\" \"twofinger\"
Option \"NaturalScrolling\" \"true\"
EndSection
xinput(1) calls it an 'ETPS/2 Elantech Touchpad'.
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#33234: Guix (weather): there can be only one
@ 2018-11-02 1:35 99% Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-11-02 1:35 UTC (permalink / raw)
To: Bug Guix
Guix,
Two simultaneous ‘guix weather’s on the same machine will step on
each others' toes and die.
They were running in two separate repositories, both vanilla
sv:guix, one at v0.15.0, the other on master (7a7c91a).
Both aborted like this:
λ ./pre-inst-env guix weather
--substitute-urls=https://munich.tobias.gr
computing 7,850 package derivations for x86_64-linux...
looking for 8,167 store items on https://munich.tobias.gr...
updating substitutes from 'https://munich.tobias.gr'...
19.7%[my \n]
guix weather: error: rename-file: No such file or directory
The second one displayed a different percentage and package count
but was otherwise identical.
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#33300: hplip 3.18.9 contains non-free binary blobs
@ 2018-11-07 13:09 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-11-07 13:09 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 33300
Ludo',
How horrid.
Ludovic Courtès wrote:
> I tried removing them with a snippet (patch attached), but
> installation
> eventually fails while trying to link against libImageProcessor,
> which
> is now missing.
If I correctly read the Debian maintainer's post in the bug you
linked[0], it's possible to revert only the libImageProcessor
infec^Waddition. If it's all right with everyone, I'd like to give
that a try first. Say by tomorrow? Or do you want to revert first
& ask such questions later?
> + ;; This trick changes the behavior of the
> + ;; 'install-data-hook' target so that it
> doesn't install the
> + ;; binary blobs.
> + (substitute* "Makefile.in"
> + (("^UNAME =.*")
> + "UNAME = free-software-only-thanks\n")
Nice. I wish it worked.
Aside, -ish: looks like most distributions there found out about
this file due to some failing sanity check. Perhaps we could add
our own, in ‘guix lint’ or at build time, to warn about ELF files
and other suspicious binaries in post-snippet sourceballs?
No idea if it's worth the trouble/performance hit/false-positive
rate, of course. That's for the ner^Wgods to decide.
Kind regards,
T G-R
[0]: https://bugs.launchpad.net/hplip/+bug/1785230/comments/6
^ permalink raw reply [relevance 99%]
* bug#33470: (Significantly) negative number of packages in profile
@ 2018-11-22 23:28 66% Tobias Geerinckx-Rice
2018-11-23 6:30 99% ` bug#33470: Confusing spinner artefacts Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2018-11-22 23:28 UTC (permalink / raw)
To: 33470
Guix,
λ ~/guix/pre-inst-env guix package -i w3m --fallback
The following package will be installed:
w3m 0.5.3+git20180125 \
/gnu/store/142jvbxhbi1i93g07p01czawbgx0cf1r-w3m-0.5.3+git20180125
The following derivations will be built:
/gnu/store/pr0bmfzzf4cs6zrmdk4h51kp9d79f4hh-profile.drv
/gnu/store/x3cjs296jg3gvdf9qz1ql4fwxrwdwi25-xdg-mime-database.drv
building
/gnu/store/x3cjs296jg3gvdf9qz1ql4fwxrwdwi25-xdg-mime-database.drv...
building
/gnu/store/pr0bmfzzf4cs6zrmdk4h51kp9d79f4hh-profile.drv...
-119 packages in profile
^^^^
I'm sure I have more packages installed than that.
λ ~/guix/pre-inst-env guix describe
Git checkout:
repository: /home/nckx/guix
branch: master
commit: eff8e0b4d9d4b818150f64e151227e03fdcb5aab
Kind regards,
T G-R
---------- dump ----------
λ ~/guix/pre-inst-env guix package -l
Generation 100 Oct 23 2018 14:27:29
swaks 20170101.0 out
/gnu/store/2k4wv49p735a31cx9qvlzgsk4lni1nqb-swaks-20170101.0
whois 5.3.0 out
/gnu/store/4jfjqhy9hw89qiqj5083v15naqzqfqva-whois-5.3.0
scsh 0.0.0-1.1144324 out
/gnu/store/b2msqfgngkir6a941710hc4d8vzjq7v7-scsh-0.0.0-1.1144324
zathura-ps 0.2.6 out
/gnu/store/6pfgxrvlrhxb1pss27d9z6xr9xfa6ghw-zathura-ps-0.2.6
zathura-cb 0.1.8 out
/gnu/store/8j19d0a9rsq3wcb6kkw9h4zxdkjm6hvs-zathura-cb-0.1.8
zathura-pdf-mupdf 0.3.3 out
/gnu/store/ddkmjqv6cwsgld40fja61vq2w6fasypw-zathura-pdf-mupdf-0.3.3
zathura-pdf-poppler 0.2.9 out
/gnu/store/iy4js2lisaw07cs71x598hrlb3myw0cw-zathura-pdf-poppler-0.2.9
isync 1.3.0 out
/gnu/store/a9x440fkc6gwrpvybjxcf7s6z0nyrwir-isync-1.3.0
msmtp 1.6.6 out
/gnu/store/f0vyrzx0w158ryvx1yjay666sabi8k0v-msmtp-1.6.6
qemu 2.11.1 out
/gnu/store/ipbcgcpbdg2255q70ryzsd7xd395phdv-qemu-2.11.1
ffmpeg 3.4.2 out
/gnu/store/y74367k1v6j06kmw2wj0pihvj57a2k8m-ffmpeg-3.4.2
file 5.32 out
/gnu/store/3cgvz2nsnnw3g4qr8aff6wbzfjing78r-file-5.32
tig 2.3.3 out
/gnu/store/bw245nqfb9h8ckfyxwj7c5rja863xsgs-tig-2.3.3
htop 2.1.0 out
/gnu/store/qzmp5xx0791azah0045fnrs90qsb8hh7-htop-2.1.0
lsof 4.89 out
/gnu/store/ximgskyhyqab1bff2s184dmsr940pnm9-lsof-4.89
calibre 3.17.0 out
/gnu/store/3cakwl6xrgx044srdyi11rxv55lsq6g6-calibre-3.17.0
subversion 1.8.19 out
/gnu/store/76lrqklypvfbxhaszahashaaprrxd468-subversion-1.8.19
python 3.6.3 out
/gnu/store/6zwqlrzz12sjnp06nh807kmy5q3zymwl-python-3.6.3
unzip 6.0 out
/gnu/store/isp3x3aaviiivbh7vlvifh62dj3dqkzb-unzip-6.0
groff-minimal 1.22.3 out
/gnu/store/h08h7gqfhddrfz3xcrvfzcy6bxfw2bk0-groff-minimal-1.22.3
gnome-screenshot 3.22.0 out
/gnu/store/swxiln1xxwilz7gx8h3b4qb33sn5ngvi-gnome-screenshot-3.22.0
mpv 0.28.2 out
/gnu/store/knvbjjji40w6zr6b3qj4zi197pmmhnxy-mpv-0.28.2
xrandr 1.5.0 out
/gnu/store/zpwjgwplf55qj1r265mlcrr6ql7ykpp6-xrandr-1.5.0
rtorrent 0.9.6 out
/gnu/store/7id38fn691x9gaqy90gjknca1szl1xvr-rtorrent-0.9.6
xinput 1.6.2 out
/gnu/store/chgp6za601rn2wb6hvbs8cfp7s0ckppf-xinput-1.6.2
iptables 1.6.2 out
/gnu/store/41rikmdib0m3cp6r5jr4f0zjyndzvzxi-iptables-1.6.2
diffoscope 90 out
/gnu/store/6ml5q2cbp58rsixb1bk2iv2c171w9wwk-diffoscope-90
dosfstools 4.1 out
/gnu/store/0sq2nflm42x0znkv44add0gk82khkcb6-dosfstools-4.1
curl 7.59.0 out
/gnu/store/apag6f24mhl9n4m5hqqkm0ami55qwl33-curl-7.59.0
gnupg 2.2.5 out
/gnu/store/786hivv148yyqy0fj916fm7dak413p17-gnupg-2.2.5
pinentry-tty 1.1.0 out
/gnu/store/m658iqv98lawvdv0zlpflr6xb33f5wjn-pinentry-tty-1.1.0
man-pages 4.15 out
/gnu/store/zycx8pgdxq9yl7ck8x20inz85r8q24qm-man-pages-4.15
openssl 1.1.0h out
/gnu/store/3yv5ff4rjkk60fxrflkp2rmxq51bfwv8-openssl-1.1.0h
guile-readline 2.2.3 out
/gnu/store/5gsdfszh82w4cxg4rsb4xg7mzmcg92f4-guile-readline-2.2.3
vinagre 3.22.0 out
/gnu/store/c4w61zcjvp6y40jimlr7w5sq278j1zjc-vinagre-3.22.0
netcat 0.7.1 out
/gnu/store/dal34nyrjixsf8rgb94v4qival2d2v7q-netcat-0.7.1
weechat 2.1 out
/gnu/store/9ilksi6ah4c3lfwlbgbw86g042zjb6jk-weechat-2.1
patchelf 0.8 out
/gnu/store/sfjlb5hz37747zzlxpgbq4qs8by2zi1q-patchelf-0.8
bind 9.12.1 utils
/gnu/store/bvzaa5h7rr6p4cnd9n0q8l7yb96d0pmw-bind-9.12.1-utils
gucharmap 3.18.0 out
/gnu/store/bssfydz90hmp7q7k94n3bj9qkaxs7jns-gucharmap-3.18.0
xterm 333 out
/gnu/store/c7yw6sldf7x6kpi46yzhnh1iish8xjqg-xterm-333
rofi 1.5.1 out
/gnu/store/14kklyizabkgskk38il00wgc332k7zg7-rofi-1.5.1
pavucontrol 3.0 out
/gnu/store/sf6ssa0pyl9x2ln0l4rl90jqxarsjj6y-pavucontrol-3.0
sshfs-fuse 2.10 out
/gnu/store/3wk9k3c02wwj2g0yxz3hz3q953az4anc-sshfs-fuse-2.10
xdg-utils 1.1.2 out
/gnu/store/qjlfrhbk3cvilwpbfiddfvijv4zizmg6-xdg-utils-1.1.2
cool-retro-term 1.0.1-1.dd799cf out
/gnu/store/yg0ashnnj7xw4qbyqavl0qpmilrdr6r0-cool-retro-term-1.0.1-1.dd799cf
termite 13 out
/gnu/store/p1057wlkfkk6860vajwv1fhxz8cfm40g-termite-13
nload 0.7.4 out
/gnu/store/i8gwm64d6wrxlmmw40msp5z47lbp3mxw-nload-0.7.4
surfraw 2.2.9 out
/gnu/store/kn4syx1ypqg3qy82449wls6jj27f0szc-surfraw-2.2.9
texlive 2017 out
/gnu/store/nmgmg2x56jj7v6xh1c3hwvnfhz8n6fv8-texlive-2017
pulseaudio 11.1 out
/gnu/store/k4fz7nijl7vhjwwn7h8x0s03jnnpnjh6-pulseaudio-11.1
mrrescue 1.02e out
/gnu/store/v3cb5ncdykwapfg6kfb8bv4zqd9n22dp-mrrescue-1.02e
aircrack-ng 1.2-rc4 out
/gnu/store/cf9f64nx1wmxdg087mzddani5j60nh04-aircrack-ng-1.2-rc4
st 0.8.1 out
/gnu/store/nqq17vskm242gxxq6ygfdwz1w0rgnqa0-st-0.8.1
mupdf 1.13.0 out
/gnu/store/z8lvrigd48ha0hq8vgzc85s8lps5gjhc-mupdf-1.13.0
cpufrequtils 0.3 out
/gnu/store/dc0cyls6h3fmzfan7klwvscs5rn0qhqv-cpufrequtils-0.3
git 2.18.0 out
/gnu/store/w9qwlwpfmhkyj6rqk3rvkk1a89vmymqf-git-2.18.0
git 2.18.0 send-email
/gnu/store/pvj35w3xlfvxdw3gljxxba2xjm2v7958-git-2.18.0-send-email
borg 1.1.6 out
/gnu/store/zwd5cmy10nwhrdv7lwggxpai1b6lqyqm-borg-1.1.6
mame 0.200 out
/gnu/store/03qc0fwx27rb0zmzf34l9xwgmpd4i570-mame-0.200
entr 3.6 out
/gnu/store/vpq5cmpzj6k85vsgs3yp9w4vi0dz14vj-entr-3.6
nmap 7.70 out
/gnu/store/8wm2wclxdn57kw074rkkmq2x9ycjw5jf-nmap-7.70
font-tamzen 1.11.4 out
/gnu/store/s0r4gl3mskw20zpgk0k3x48yzhcnyba7-font-tamzen-1.11.4
font-google-noto 20170403 out
/gnu/store/v3wzvibzxmhfdb03m55w7cbh4w9wqq4d-font-google-noto-20170403
emacs-mu4e-conversation 20180722-2.223cc66 out
/gnu/store/j5sp2wxyqkf87i2020fs65lhbkjypwly-emacs-mu4e-conversation-20180722-2.223cc66
nano 2.9.8 out
/gnu/store/89g2i8xliv4xr5xydkldl24gv99ayrqq-nano-2.9.8
sakura 3.6.0 out
/gnu/store/zf5n3r06dy1mhi3nyk89c3vw8dszv1d8-sakura-3.6.0
redshift 1.12 out
/gnu/store/ipkn1mbfp69b1mxa2b27ak7fslwnqhy7-redshift-1.12
xclip 0.13 out
/gnu/store/1gia6yrf70wx9nhi7f6ldzh5xq71jhpg-xclip-0.13
guile-gcrypt 0.1.0 out
/gnu/store/qbzw2ygy1nq2h0nq6sl9cgg1c5mq5g8z-guile-gcrypt-0.1.0
youtube-dl 2018.09.08 out
/gnu/store/k7w8gkdghzs4xzz80iwm376hqjfsgbfz-youtube-dl-2018.09.08
inkscape 0.92.3 out
/gnu/store/drq0v1w1h96v4zqh53wjalkn1fzgyzhf-inkscape-0.92.3
font-awesome 4.7.0 out
/gnu/store/a4cm5m2dbcmfgly3azq97vwvqmg26382-font-awesome-4.7.0
font-inconsolata 0.80 out
/gnu/store/01bcbixm2152fz2v6246rlpxvkp56iz9-font-inconsolata-0.80
font-ubuntu 0.83 out
/gnu/store/h3wxrw76q31j2h84dkp1i9cdsnf8sbsj-font-ubuntu-0.83
font-dejavu 2.37 out
/gnu/store/9915gq2d5g7p320bsh1w063zydakr5jn-font-dejavu-2.37
font-bitstream-vera 1.10 out
/gnu/store/cfm09sjwqb21lfskam3i0m3lajyym9j9-font-bitstream-vera-1.10
font-lato 2.010 out
/gnu/store/5dr02g4gs51gqsnfyfcjk21cl9wmsq2y-font-lato-2.010
font-gnu-freefont-ttf 20120503 out
/gnu/store/frpf3q56jxixhyimj2zjn14723xfcn20-font-gnu-freefont-ttf-20120503
font-liberation 2.00.1 out
/gnu/store/pggkzsi8a19lj4hv968qclf0785g0pgx-font-liberation-2.00.1
font-linuxlibertine 5.3.0 out
/gnu/store/k0krbnmzjh34rjpr3nf4j5dppr9xabxg-font-linuxlibertine-5.3.0
font-terminus 4.40 out
/gnu/store/1annn8mhg79cvk996zg2jc4fw6gj29vy-font-terminus-4.40
font-tex-gyre 2.005 out
/gnu/store/ypf0ljwkb7gvv5br5r5brr31ik1c0c59-font-tex-gyre-2.005
font-anonymous-pro 1.002 out
/gnu/store/rnsbd0y52px08s387jf36q91sdbg1myw-font-anonymous-pro-1.002
font-fantasque-sans 1.7.2 out
/gnu/store/y092nrcg5xc4y4nbsv8hfqd8h5zck4nl-font-fantasque-sans-1.7.2
font-hack 3.002 out
/gnu/store/qsz98jfp5z1zjwzv0a81x77prkqk72n6-font-hack-3.002
font-adobe-source-code-pro 2.030R-ro-1.050R-it out
/gnu/store/yir27vnb3r7sbsxz9kkcva609m8mx0z4-font-adobe-source-code-pro-2.030R-ro-1.050R-it
font-fira-mono 3.206 out
/gnu/store/kjx6f5iq60hyn1kck2ifps6ahkni77r6-font-fira-mono-3.206
font-fira-sans 4.202 out
/gnu/store/3p1ayi28bqf7qclylpb9bb974ir3bikr-font-fira-sans-4.202
font-fira-code 1.205 out
/gnu/store/hq1mqq77r9hxj4q8lnca6z0jij1nllmr-font-fira-code-1.205
font-iosevka 1.12.5 out
/gnu/store/yf58x3kdyhvjya3dddk1k9malk312srs-font-iosevka-1.12.5
font-go 20170330-1.f03a046 out
/gnu/store/vkmmab58s8jbjz1c051wdnpw013cs89z-font-go-20170330-1.f03a046
font-dosis 1.7 out
/gnu/store/z7fn8ffa9gl6i7jr3c1vsxf81kcxna4y-font-dosis-1.7
font-alias 1.0.3 out
/gnu/store/gml2b7v00vd7bad86slagrfdbrc0g02r-font-alias-1.0.3
adwaita-icon-theme 3.26.1 out
/gnu/store/8cw4g99r25qf8w9mgxgl0xk4s76q2914-adwaita-icon-theme-3.26.1
simple-scan 3.24.1 out
/gnu/store/75a8y5d1phx2vcjgdpsh34rwj9853kg6-simple-scan-3.24.1
rename 1.00 out
/gnu/store/p7b0pjf5ir5afdzh3pvxpbw1i9cy2zf6-rename-1.00
sshuttle 0.78.4 out
/gnu/store/xjivz9qflswgp9bc9nak3q1rabhkahdw-sshuttle-0.78.4
icecat 60.2.0-gnu1 out
/gnu/store/nzznfmrphjpwqcrxmpimln892p74gf6y-icecat-60.2.0-gnu1
radeontop 1.1 out
/gnu/store/cvws710rrskbxsxsdz98182adyd1z20m-radeontop-1.1
bastet 0.43.2 out
/gnu/store/k8jafidh0nz0my1p8k56gcgv09cyl7vi-bastet-0.43.2
freedroidrpg 0.16.1 out
/gnu/store/mmvpas82yc0m8sc61da3zb7dvxs8zm0k-freedroidrpg-0.16.1
sqlcrush 0.1.5-1.b5f6868 out
/gnu/store/f6r2w71cxr6mp7n1hxcvkvhij5mzl5ws-sqlcrush-0.1.5-1.b5f6868
gcc-toolchain 8.2.0 out
/gnu/store/7arj5zd8z78v67jk4bvhi17bm4xppjma-gcc-toolchain-8.2.0
smartmontools 6.6 out
/gnu/store/rhyibi61b2mi3rqx3yjmvbig370l4xcd-smartmontools-6.6
wget 1.19.5 out
/gnu/store/r2lzy5abk6lfwq83518vfikyra4570l4-wget-1.19.5
hangups 0.4.6 out
/gnu/store/d0skl2qzpac35hw6pvzih7hb22pzlynb-hangups-0.4.6
Generation 101 Oct 24 2018 01:52:32
+ wavemon 0.8.2 out
/gnu/store/bb4m4mvwqx6gvman7ly5icpmczb707cf-wavemon-0.8.2
Generation 102 Oct 24 2018 03:08:40
+ powertop 2.9 out
/gnu/store/zdvakmbpahdaz8pfw6mfn73b9d4f711w-powertop-2.9
Generation 103 Oct 24 2018 04:11:57
+ cool-retro-term 1.0.1-1.dd799cf out
/gnu/store/y5xygarvdzh5s4vsh00d7k5xjvhdvpdi-cool-retro-term-1.0.1-1.dd799cf
- cool-retro-term 1.0.1-1.dd799cf out
/gnu/store/yg0ashnnj7xw4qbyqavl0qpmilrdr6r0-cool-retro-term-1.0.1-1.dd799cf
Generation 104 Oct 24 2018 05:08:13
+ icecat 60.2.0-gnu1 out
/gnu/store/qaw98ynqs5b4xvmzk9qgqg9n8384ss9i-icecat-60.2.0-gnu1
- icecat 60.2.0-gnu1 out
/gnu/store/nzznfmrphjpwqcrxmpimln892p74gf6y-icecat-60.2.0-gnu1
Generation 105 Oct 25 2018 03:41:38
+ lz4 1.8.1.2 out
/gnu/store/sc5szp6bii3alww8dlyr7g4v84jz5i6i-lz4-1.8.1.2
Generation 106 Oct 25 2018 17:55:22
+ recutils 1.7 out
/gnu/store/hsdjmvcg3gwgs8gfww8c4d3xwfxkdsw1-recutils-1.7
Generation 107 Oct 26 2018 00:47:22
+ emacs-guix 0.5 out
/gnu/store/9lgy8b3wwp183h7lzcvmqmhvrkli6yfw-emacs-guix-0.5
Generation 108 Oct 26 2018 18:02:31
+ shellcheck 0.5.0 out
/gnu/store/1daixfbhmv4p9n63kwbznj16d7mrwn6q-shellcheck-0.5.0
Generation 109 Oct 31 2018 23:45:34
+ iperf 3.1.7 out
/gnu/store/4qkgariddrhy4s62rq546kzz6x3s08wv-iperf-3.1.7
Generation 110 Nov 11 2018 01:45:22
+ encfs 1.9.5 out
/gnu/store/dbdcnja43iyfmfz5hgvq5n824x3x72kp-encfs-1.9.5
Generation 111 Nov 14 2018 20:12:00
+ ntfs-3g 2017.3.23 out
/gnu/store/ybim7azfyjf2afwz194y2hfx5a3j4mb5-ntfs-3g-2017.3.23
Generation 112 Nov 15 2018 05:50:21
+ icecat 60.3.0-gnu1 out
/gnu/store/x3nd9rnvccwfjl09ic0hs0rpzrbi6i0c-icecat-60.3.0-gnu1
- icecat 60.2.0-gnu1 out
/gnu/store/qaw98ynqs5b4xvmzk9qgqg9n8384ss9i-icecat-60.2.0-gnu1
Generation 113 Nov 16 2018 22:48:03
+ oath-toolkit 2.6.2 out
/gnu/store/lmdy7vgrjxk06gmc4im43yl295cz8jr2-oath-toolkit-2.6.2
Generation 114 Nov 19 2018 23:15:23
+ dmidecode 3.2 out
/gnu/store/2rgdx676sczbwfml95sj2lkkx0ln6vrm-dmidecode-3.2
Generation 115 Nov 21 2018 14:48:54
+ youtube-dl 2018.11.07 out
/gnu/store/n99k6vw2d5al5g1a9gqg314pcnpvq00a-youtube-dl-2018.11.07
- youtube-dl 2018.09.08 out
/gnu/store/k7w8gkdghzs4xzz80iwm376hqjfsgbfz-youtube-dl-2018.09.08
Generation 116 Nov 22 2018 22:34:53
- mame 0.200 out
/gnu/store/03qc0fwx27rb0zmzf34l9xwgmpd4i570-mame-0.200
Generation 117 Nov 22 2018 23:59:52 (current)
+ w3m 0.5.3+git20180125 out
/gnu/store/142jvbxhbi1i93g07p01czawbgx0cf1r-w3m-0.5.3+git20180125
^ permalink raw reply [relevance 66%]
* bug#33470: Confusing spinner artefacts
2018-11-22 23:28 66% bug#33470: (Significantly) negative number of packages in profile Tobias Geerinckx-Rice
@ 2018-11-23 6:30 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2018-11-23 6:30 UTC (permalink / raw)
To: 33470
Heh,
Tobias Geerinckx-Rice wrote:
> -119 packages in profile
> ^^^^
>
> I'm sure I have more packages installed than that.
Not much later, it clicked:
λ ~/guix/pre-inst-env guix ...
building /gnu/store/eee...-profile.drv...
|119 packages in profile
λ
I'd just got lucky spinning the Wheel of Guix.
So this bug isn't as interesting as I thought, but it's ugly and a
little annoying.
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#33470: Confusing spinner artefacts
@ 2018-11-23 14:00 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-11-23 14:00 UTC (permalink / raw)
To: Gábor Boskovits; +Cc: 33470
Gábor,
Thanks for your suggestion.
Gábor Boskovits wrote:
> Tobias Geerinckx-Rice ezt írta (időpont: 2018. nov. 23., P,
> 7:43):
>> -119 packages in profile
>> |119 packages in profile
[...]
> I feel that simply inserting some whitespace between the spinner
> and
> the text would make this less problematic.
> WDYT?
That would kill the ‘-119’ red herring but it's still ugly.
> Do you have any better suggestion?
I'd expect such droppings not to happen at all.
I regret that I haven't had time to look at the ‘new’
pretty-printing code (port?) yet, but it should be possible to
clear the spinner before a new line. If that's much harder than it
ought to be, our red herring's more of a red flag.
>> ugly and a little annoying,
T G-R
^ permalink raw reply [relevance 99%]
* bug#33703: youtube-dl man page is not complete
@ 2018-12-11 12:47 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-12-11 12:47 UTC (permalink / raw)
To: swedebugia; +Cc: 33703
swedebugia,
swedebugia wrote:
> It seems truncated and the section "format selection" is
> missing.
Thanks for the report! It's a bit short :-)
I'd like to mark this as duplicate of #30785[1] but won't for now,
since I can't reproduce your findings:
~ λ youtube-dl --version
2018.11.07
~ λ man --version
man 2.8.3
~ λ guix --version
guix (GNU Guix) 0.16.0-3.6ddc63e […]
~ λ man youtube-dl | egrep '^[A-Z ]+$'
NAME
SYNOPSIS
DESCRIPTION
OPTIONS
CONFIGURATION
OUTPUT TEMPLATE
FORMAT SELECTION
VIDEO SELECTION
FAQ
DEVELOPER INSTRUCTIONS
BUGS
COPYRIGHT
However! I can no longer reproduce #30785 either:
~ λ man 5 knot.conf | grep -E '^(NAME|DESCRIPTION)'
NAME
DESCRIPTION
Probably because the bug is locale-related and I've got broken
locales after the last release. Are the pages mentioned in bug
#30785 truncated for you, too?
Kind regards,
T G-R
[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30785
^ permalink raw reply [relevance 99%]
* bug#33647: First `guix pull' behaves unexpectedly
@ 2018-12-19 19:27 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2018-12-19 19:27 UTC (permalink / raw)
To: swedebugia; +Cc: 33647
swedebugia wrote:
> egil@parabola:~$ time hash pacman
>
> real 0m0,000s
> user 0m0,000s
> sys 0m0,000s
>
> So it won't and any measuable overhead to just call this in the
> end of
> guix package after updating the symlinks to the new profile
> generation.
Do you mean to put something like
guix() {
command "$1" "$@"
hash "$1"
}
in the default /etc/profile (or wherever such things belong)?
I think this is far too intrusive and magical to do by default,
considering its limited one-time-only usefulness. The same goes
for patching shells.
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#34276: ‘guix system disk-image’ successfully builds a bad image
@ 2019-02-01 15:57 93% Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-02-01 15:57 UTC (permalink / raw)
To: 34276
Hullo!
I wanted to install this ‘Guix’ thing that everyone's so hyped up
about.
I have a small forgotten script in my ~/guix.git that runs:
./pre-inst-env guix system disk-image --fallback
--image-size=1.5G \
gnu/system/install.scm
This was written back when 1.5G was higher than the default.
Now it's much lower and too small to store all the Guix. However,
the command completes ‘successfully’:
copying 422 store items [#########:
In srfi/srfi-1.scm:
466:18 19 (fold #<procedure 1a60440 at ice-9/ftw.scm:452:38
(sub?> ?)
In unknown file:
18 (_ #<procedure 1917270 at ice-9/ftw.scm:454:44 ()>
#<p?> ?)
In ice-9/ftw.scm:
452:32 17 (loop _ _ #(21 1706421 16749 3 0 0 0 4096 1548869386
?) ?)
In srfi/srfi-1.scm:
466:18 16 (fold #<procedure 1a60160 at ice-9/ftw.scm:452:38
(sub?> ?)
In unknown file:
15 (_ #<procedure 1917240 at ice-9/ftw.scm:454:44 ()>
#<p?> ?)
In ice-9/ftw.scm:
452:32 14 (loop _ _ #(21 1739151 16749 3 0 0 0 4096 1548869386
?) ?)
In srfi/srfi-1.scm:
466:18 13 (fold #<procedure 1b8f8c0 at ice-9/ftw.scm:452:38
(sub?> ?)
In unknown file:
12 (_ #<procedure 1b5bc90 at ice-9/ftw.scm:454:44 ()>
#<p?> ?)
In ice-9/ftw.scm:
452:32 11 (loop _ _ #(21 1772091 16749 13 0 0 0 4096 1548869389
?) ?)
In srfi/srfi-1.scm:
466:18 10 (fold #<procedure 1b8f280 at ice-9/ftw.scm:452:38
(sub?> ?)
In unknown file:
9 (_ #<procedure 1a56750 at ice-9/ftw.scm:454:44 ()>
#<p?> ?)
In ice-9/ftw.scm:
452:32 8 (loop _ _ #(21 2132258 16749 98 0 0 0 4096 1548869432
?) ?)
In srfi/srfi-1.scm:
466:18 7 (fold #<procedure 140dd20 at ice-9/ftw.scm:452:38
(sub?> ?)
In unknown file:
6 (_ #<procedure 19ea030 at ice-9/ftw.scm:454:44 ()>
#<p?> ?)
In ice-9/ftw.scm:
452:32 5 (loop _ _ #(21 4589344 16749 24 0 0 0 4096 1548869676
?) ?)
In srfi/srfi-1.scm:
466:18 4 (fold #<procedure 1969540 at ice-9/ftw.scm:452:38
(sub?> ?)
In unknown file:
3 (_ #<procedure 1725750 at ice-9/ftw.scm:454:44 ()>
#<p?> ?)
In ice-9/ftw.scm:
482:39 2 (loop _ _ #(21 4589402 16749 3 0 0 0 4096 1548869687
?) ?)
In ./guix/build/utils.scm:
312:27 1 (_
"/gnu/store/ricf82z3mqqrqim67jz3jlsglfm1g1a8-linux-?" ?)
In unknown file:
0 (copy-file
"/gnu/store/ricf82z3mqqrqim67jz3jlsglfm1g1a?" ?)
ERROR: In procedure copy-file:
In procedure copy-file: No space left on device
^MESC[Kcopying 422 store items
boot program
'/gnu/store/lbvrvrlqab4qpw9f907na445kppmknab-linux-vm-loader'
terminated, rebooting
[ 1071.512054] Unregister pv shared memory for cpu 0
[ 1071.522414] reboot: Restarting system
[ 1071.542285] reboot: machine restart
successfully built
/gnu/store/lbyq5790j5hfq3spbm76i1yw3sj41l8b-disk-image.drv
/gnu/store/dby523cy1l4wrqi8wwmk5ln9qr7g5mh8-disk-image
Kind regards,
T G-R
Sent from my GNU Emacs
^ permalink raw reply [relevance 93%]
* bug#34568: flash-image.armhf-linux appears to succeed, when it actually failed
@ 2019-02-19 6:30 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-02-19 6:30 UTC (permalink / raw)
To: Mark H Weaver; +Cc: 34568
Mark,
Not much help, but:
Mark H. Weaver wrote:
> The following build appears to have succeeded:
>
> https://hydra.gnu.org/build/3378988
>
> but if you look at the tail of the build log, it seems that it
> actually
> failed:
>
> https://hydra.gnu.org/build/3378988/log/tail-reload
This looks very similar to #34276.
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#34642: clipit cannot be started by awesomewm or rofi
@ 2019-02-25 0:04 99% ` Tobias Geerinckx-Rice
2019-02-25 0:10 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2019-02-25 0:04 UTC (permalink / raw)
To: Bradley Haggerty; +Cc: 34642
Bradley,
Bradley Haggerty wrote:
> After a recent update, clipit no longer starts with my wm
> session. I cannot
> launch it from rofi either. It has a tray icon and you can open
> a search
> with ctrl-alt-f, so it's easy to see when it's not running. I
> can launch it
> from a terminal, but I cannot close the terminal and keep it
> going. I tried
> running 'clipit &' and closing the shell, I tried using
> nohup. Doesn't work.
I use clipit without issue… but I also never launch it in the
background. :-)
It's hard to tell, but it might be this[0] upstream issue and
might be fixed here[1].
Kind regards,
T G-R
[0]: https://github.com/CristianHenzel/ClipIt/issues/87
[1]: https://github.com/CristianHenzel/ClipIt/pull/109
^ permalink raw reply [relevance 99%]
* bug#34642: clipit cannot be started by awesomewm or rofi
2019-02-25 0:04 99% ` Tobias Geerinckx-Rice
@ 2019-02-25 0:10 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-02-25 0:10 UTC (permalink / raw)
To: Bradley Haggerty; +Cc: 34642
Tobias Geerinckx-Rice wrote:
> It's hard to tell, but it might be this[0] upstream issue and
> might be
> fixed here[1].
If so, it should be fixed upstream.
Are you comfortable building clipit from this[2] commit and
testing that?
Kind regards,
T G-R
[0]: https://github.com/CristianHenzel/ClipIt/issues/87
[1]: https://github.com/CristianHenzel/ClipIt/pull/109
[2]:
https://github.com/CristianHenzel/ClipIt/commit/2c6e47b108b3dd7415c0c81b29201f1b9004e5cb
^ permalink raw reply [relevance 99%]
* bug#34768: guix-daemon tmpfs out of space on parabola
@ 2019-03-06 14:31 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-03-06 14:31 UTC (permalink / raw)
To: swedebugia; +Cc: 34768
Hullo,
swedebugia wrote:
> I'm trying to build New Moon (unbranded palemoon browser) in
> parabola.
> The tmpfs i 2G which is way too little it seems.
>
> I read the man page of guix-daemon and the manual and could not
> find a
> way to point guix-daemon to another tmpdir than /tmp.
Well, TMPDIR= should Just Work :-)
You'll have to set it to the environment of guix-daemon (and
restart the daemon) for it to have any effect. How that's done
depends on your service manager/init system.
I guess a ‘set-tmpdir’ RPC could be added to the protocol. I
haven't thought through the security implications, and IMO it's
just papering over the real bug, which is…
> Is this a bug?
Not sure what exactly you're referring to, but yes, I do think
that using /tmp instead of /var/tmp (or any non-tmpfs) is a bug by
modern(?) conventions. It's guaranteed to break eventually on
almost every non-Guix System, and when it doesn't it's an abuse of
RAM and swap space.
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* Re: ffmpeg: error while loading shared libraries: (...): file too short
@ 2019-03-09 20:28 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-03-09 20:28 UTC (permalink / raw)
To: Alex Vong; +Cc: guix-devel, bug-guix
Alex,
Something is amiss on your box.
Alex Vong wrote:
> Does anyone has the same problem with ffmpeg from latest master?
> I've
> got the following error:
>
> ========================================================================
> alexvong1995@debian:~$ ffmpeg --help
> ffmpeg: error while loading shared libraries:
> /gnu/store/4hcr7ygdhaxws6q5dj806cbvq0dkfgkw-ffmpeg-4.1.1/lib/libavdevice.so.58:
> file too short
> ========================================================================
--8<---------------cut here---------------start------------->8---
λ file -L
/gnu/store/4hcr7ygdhaxws6q5dj806cbvq0dkfgkw-ffmpeg-4.1.1/lib/libavdevice.so.58
/gnu/store/4hcr7ygdhaxws6q5dj806cbvq0dkfgkw-ffmpeg-4.1.1/lib/libavdevice.so.58:
ELF 64-bit LSB pie executable x86-64, version 1 (SYSV),
dynamically linked, stripped
λ ls -lh
/gnu/store/4hcr7ygdhaxws6q5dj806cbvq0dkfgkw-ffmpeg-4.1.1/lib/libavdevice.so.58.5.100
-r-xr-xr-x 2 root root 152K Jan 1 1970
/gnu/store/4hcr7ygdhaxws6q5dj806cbvq0dkfgkw-ffmpeg-4.1.1/lib/libavdevice.so.58.5.100
--8<---------------cut here---------------end--------------->8---
Have you fsck'd your file system lately?
T G-R
^ permalink raw reply [relevance 99%]
* bug#34799: font breakage, square boxes, font-terminus
@ 2019-03-10 11:16 97% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-03-10 11:16 UTC (permalink / raw)
To: Bradley Haggerty; +Cc: 34799
[-- Attachment #1: Type: text/plain, Size: 984 bytes --]
Bradley,
Bradley Haggerty wrote:
> This issue may be a lot simpler than it initially seemed. I've
> had success
> upgrading all those packages except for font-terminus. I also
> realized that
> the broken font in all places I can think of was the same. It
> was Terminus.
> So, this bug is likely specific to font-terminus and for now I
> will just
> hold it back in my upgrades.
I updated font-terminus from 4.40 to 4.47 in commit 73c5c482. I
wonder if your problem could be caused by this intermediate
upstream change[0]:
Version 4.46:
The X11 8-bit code pages are not installed by default.
Indeed, I'd noticed that some half of the 4.40 files were
‘missing’ from 4.47, but my fonts continued to work just fine and
we don't (usually…) diverge from upstream without good reason.
This is probably a good reason :-) Does the attached patch fix
your problem?
Kind regards,
T G-R
[0]: http://terminus-font.sourceforge.net
[-- Attachment #2: 0001-XXX-gnu-font-terminus-Install-X11-8-bit-code-pages.patch --]
[-- Type: text/x-patch, Size: 1678 bytes --]
From 0d9b645937abfdddaf3d8088f81c58220c8d0026 Mon Sep 17 00:00:00 2001
From: Tobias Geerinckx-Rice <me@tobias.gr>
Date: Sun, 10 Mar 2019 12:12:08 +0100
Subject: [PATCH] XXX gnu: font-terminus: Install X11 8-bit code pages.
* gnu/packages/fonts.scm (font-terminus)[arguments]: Add a new phase
to build & install 8-bit fonts that were installed by default pre-4.46.
---
gnu/packages/fonts.scm | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/fonts.scm b/gnu/packages/fonts.scm
index 296e46ec6f..0d327a51b7 100644
--- a/gnu/packages/fonts.scm
+++ b/gnu/packages/fonts.scm
@@ -360,7 +360,16 @@ Biolinum is available in both Regular and Bold weights.")
("pkg-config" ,pkg-config)
("python" ,python)))
(arguments
- `(#:tests? #f)) ; no test target in tarball
+ `(#:tests? #f ; no test target in tarball
+ #:phases
+ (modify-phases %standard-phases
+ (add-after 'install 'install-more-bits
+ ;; X11 8-bit code pages are not installed by default (they were
+ ;; until version 4.46). Install them manually.
+ ;; XXX This builds at least as many fonts as the ‘build’ phase
+ ;; does. Split up into build- and install- when merging?
+ (lambda* (#:key make-flags outputs #:allow-other-keys)
+ (apply invoke "make" "install-pcf-8bit" make-flags))))))
(home-page "http://terminus-font.sourceforge.net/")
(synopsis "Simple bitmap programming font")
(description "Terminus Font is a clean, fixed-width bitmap font, designed
--
2.20.1
^ permalink raw reply related [relevance 97%]
* bug#34806: `guix build inkscape` fails
@ 2019-03-10 18:25 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2019-03-10 18:25 UTC (permalink / raw)
To: Marius Bakke; +Cc: 34806
Marius,
Marius Bakke wrote:
> Trying to run `guix build inkscape` on current master branch
> yields...
>
> gnu/packages/gnome.scm:5687:15: error: inkscape: unbound
> variable
> hint: Did you forget a `use-modules' form?
>
> What's going on here?
This might've been caused by 10bd288, and would then've fixed in
6845ab5.
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#34806: `guix build inkscape` fails
@ 2019-03-10 19:10 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2019-03-10 19:10 UTC (permalink / raw)
To: Marius Bakke; +Cc: 34806
Marius,
Marius Bakke wrote:
> Actually I think this goes as far back as
> a76d0f032b6d4148bd36dcb640109fae20922bbc. For some reason it
> only
> appears to be a problem when doing `guix build inkscape`.
Weird:
λ ./pre-inst-env guix build inkscape
/gnu/store/5myjx607cr0hyywvgqyg5ssd3r2yf5dz-inkscape-0.92.4
λ git describe
v0.16.0-3106-g41ce92501b
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#34806: `guix build inkscape` fails
@ 2019-03-10 20:26 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-03-10 20:26 UTC (permalink / raw)
To: Marius Bakke; +Cc: 34806
Marius,
Marius Bakke wrote:
> Does it work without './pre-inst-env'?
λ time guix pull
…
real 29m0.672s
user 23m22.689s
sys 0m32.778s
# So there's a reason I don't use ‘guix pull’.
λ guix build inkscape
gnu/packages/gnome.scm:5687:15: error: inkscape: unbound
variable
hint: Did you forget a `use-modules' form?
Oh.
T G-R
^ permalink raw reply [relevance 99%]
* bug#34850: ghc compiling error
@ 2019-03-13 22:48 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-03-13 22:48 UTC (permalink / raw)
To: mikadoZero; +Cc: 34850
mikadoZero,
mikadoZero wrote:
> `guix describe`
> guix fd4c7a0
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: fd4c7a098a508c1de7a8513c0f3d88d5a0df12e7
>
> I have ghc in my system configuration file. I have just done a
> pull and
> reconfigure.
>
> `which ghc`
> /run/current-system/profile/bin/ghc
>
> I created a one line hello world program:
>
> ```haskell
> main = putStrLn "hello, world"
> ```
>
> Then I tried to compile it with ghc. I get this error.
>
> `ghc Main`
> [1 of 1] Compiling Main ( Main.hs, Main.o )
> gcc: error trying to exec 'as': execvp: No such file or
> directory
> `gcc' failed in phase `Assembler'. (Exit code: 1)
>
> I have tested compiling the same hello world program with the
> same ghc
> command and it works fine on a none Guix System.
Does the other system have ‘as’ installed? Install the
‘gcc-toolchain’ package that provides it and try again.
Usually, this kind of error means that ghc needs to be patched to
invoke ‘as’ from an absolute file name instead of searching $PATH.
There may have been good reasons not to do this (such as closure
size), or it might be an oversight.
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#34799: font breakage, square boxes, font-terminus
@ 2019-03-14 21:34 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-03-14 21:34 UTC (permalink / raw)
To: Bradley Haggerty; +Cc: 34799
Bradley,
Bradley Haggerty wrote:
> Sorry for the late reply. I've got a couple other guix issues
> I'm
> struggling to sort out recently as well.
No problem. I hope you get them resolved. I can only say that
Guix is worth it.
> Tobias Geerinckx-Rice said:
>>Does the attached patch fix your problem?
>
> I'm a bit of a novice. Can you (or someone else) explain how I
> apply this
> patch file?
You'd clone the Guix git repository from Savannah, ‘git am’ the
patch e-mail in question, then follow the instructions in section
14.2 (Running Guix Before It Is Installed) of the manual using
‘./pre-inst-env guix package -i font-terminus’ to install the
patched package.
However, you won't need to do any of that today. :-)
I was already on the fence about just pushing this change anyway,
and remembering the existence of outputs sealed the deal. I
always forget that they exist. Installing ‘font-terminus’ still
gives you the upstream selection, but could you
$ guix pull
$ guix package -i font-terminus:pcf-8bit
$ fc-cache -fr
verify that the above command worked:
$ fc-list | grep ter-116b
…are/fonts/terminus/ter-116b.pcf.gz: Terminus:style=Bold
and see if your font situation improves?
If Terminus is actually unusable without those files, I'll add
them back to :out.
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#34886: [Web page] Screenshot alignment (and listing?)
@ 2019-03-16 19:22 99% Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2019-03-16 19:22 UTC (permalink / raw)
To: 34886
Guix,
The full-sized screenshots at
https://www.gnu.org/software/guix/screenshots/gnome/ look
awkwardly left-aligned to me[0].
Is this intentional? A browser bug? This is in Icecat 60.5.1 on
Guix System.
Bonus wishlist bug(?): I was going to link to just
https://www.gnu.org/software/guix/screenshots/ above, but that
gives me an Apache directory index.
Now I'm a fan of sites that don't blanket-404 directories for
whatever misguided reason, but this should probably be its own
(pretty) page.
Kind regards,
T G-R
[0]: https://www.tobias.gr/far-left-guix.png
^ permalink raw reply [relevance 99%]
* bug#34886: [Web page] Screenshot alignment (and listing?)
@ 2019-03-17 15:48 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2019-03-17 15:48 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: sirgazil, 34886
Ludo',
Ludovic Courtès wrote:
> Tobias Geerinckx-Rice <me@tobias.gr> skribis:
>
>> The full-sized screenshots at
>> https://www.gnu.org/software/guix/screenshots/gnome/ look
>> awkwardly
>> left-aligned to me[0].
>>
>> Is this intentional? A browser bug? This is in Icecat 60.5.1
>> on Guix
>> System.
>
> The problem is that this secreenshot that I added a couple of
> days ago
> has a ratio of 4/3 instead of 16/9 (I think?).
While true (I noticed that too), that's not the problem here. The
image above is 16:something, but still isn't centred. And even
so, …
> Alternately, or in addition to that, it’d be great if the web
> site would
> automatically do the right thing regardless of the aspect ratio
> of the
> screenshot. WDYT, sirgazil?
…my thoughts exactly :-)
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#35010: Many CPAN download URLs are no longer available
@ 2019-03-27 0:31 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2019-03-27 0:31 UTC (permalink / raw)
To: Mark H Weaver; +Cc: 35010
[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]
Mark,
[Quick stream-of consciousness reply on a train, whee.]
Mark H. Weaver wrote:
> At least some, and probably most, of these URIs were updated
> quite
> recently. For example, the 'perl-mouse', 'perl-carp-clan', and
> 'perl-file-temp' were all updated on March 23, and presumably
> the source
> URIs worked at that point, but then all three URIs had to be
> updated two
> days later to fix the broken download links.
- The wave of Perl updates this March was me, using ‘guix refresh
-u’ (and manually checking for breakages, of course).
I never use ‘guix refresh’, until after about a year I forget why,
use ‘guix refresh’ once, and promptly remember.
The updater for CPAN packages is at best caveat-quality. It
helpfully downloads the updated tarball to the store, but doesn't
update the URL. Since the file is in the store, everything works
fine on the updater's machine, then breaks everywhere else.
Background: the problem here is that CPAN URLs contain the
uploader name, e.g. (Karen?) ETHER(idge) in the case of
mirror://cpan/authors/id/E/ET/ETHER/URI-1.76.tar.gz
which doesn't change every VERSION (so the problem is somewhat
hidden) but more frequently than the author/maintainer would.
I'm planning on finally taking care this problem after I get home
(and after I finally get the Overdrives set up, cough), either by
making the CPAN updater also rewrite URL fields (if possible?), or
finding out whether there's a way to construct these URLs without
using the uploader name, or… well, that's all I have for now.
- While fixing the remaining fallout from this, I did find a few
other broken CPAN links for packages that I hadn't recently
touched. Updating them broke others, so I just left them alone.
I don't know if these are more broken refreshes from longer ago
that went unnoticed (so basically nobody uses these packages),
or if there's another unrelated problem.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35010: Many CPAN download URLs are no longer available
@ 2019-03-27 18:40 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-03-27 18:40 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 35010
[-- Attachment #1: Type: text/plain, Size: 669 bytes --]
Ludo',
Ludovic Courtès wrote:
> Commit 42314ffa072f31cc1cb44df38b1f8fcca19d9d3c should fix this.
> I should have let [you?] figure it out ;-), but somehow I ended
> up investigating too much, bah!
Now I had time to rant about package names. Win-win! …wait
> Let me know what you think.
[…]
> In the meantime, to fix the Perl packages, you could maybe run:
>
> guix lint -c source $(guix package -A ^perl-)
>
> Then you could perhaps comment the ‘version>?’ test in (guix
> upstream)
> to force ‘guix package -u’ to update these seemingly up-to-date
> packages.
I'll deffo give it a try. Thanks!
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#34886: [Web page] Screenshot alignment (and listing?)
@ 2019-03-28 12:48 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-03-28 12:48 UTC (permalink / raw)
To: sirgazil; +Cc: 34886
[-- Attachment #1: Type: text/plain, Size: 188 bytes --]
sirgazil,
sirgazil wrote:
> I pushed a fix for this.
That was fast. Thank you!
I guess the live Web site still needs to be rebuilt or poked in
some way. Ludo'?
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35047: "Running the Test Suite" root user
@ 2019-03-30 13:50 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-03-30 13:50 UTC (permalink / raw)
To: mikadoZero; +Cc: 35047
[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]
mikadoZero,
mikadoZero wrote:
> Looking at "2.3 Running the Test Suite" of the manual it does
> not
> mention that tests should be run as a non root user.
I guess this is one of those (Unix-)cultural knowledge things: it
wouldn't even occur to me to build or test anything as root unless
explicitly asked to do so :-)
> The test `tests/pack` fails when `make check` is run as a root
> user. It
> does not fail when run as a non root user. I found this example
> by
> running `make check TESTS="tests/pack.scm"`. Is this an issue
> for many
> tests?
>
> I can prepare a patch for the relevant part (parts if this also
> applies
> to `make check-system` as well) in "2.3 Running the Test Suite"
> of the
> manual.
Thanks for the offer! I think adding yet another gotcha to the
manual should be a last resort, though. Many people still miss
them and get into trouble (and on to IRC).
Could we, in order of preference:
- make these tests pass even when run as root? (I guess not?)
- skip them and add ‘n tests not run as root’ to the final tally?
- refuse to even start the test suite as root?
What ‘root’ means here will depend on why these tests are failing.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35048: Evolution Mail Client - Unable to add account
@ 2019-03-30 15:12 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-03-30 15:12 UTC (permalink / raw)
To: Raghav Gururajan; +Cc: 35048
[-- Attachment #1.1: Type: text/plain, Size: 700 bytes --]
Raghav,
Raghav Gururajan wrote:
> When I click "Apply" at the last step of "Add Account Wizard", I
> am getting the error "The name
> org.gnome.evolution.dataserver.Sources5 was not provided by any
> .service files".
If you're comfortable installing packages from Guix source, could
you give the attached patch a try? (If you're not, I urge you to
try anyway — it's not that hard :-)
It's a stab in the dark, since I can't actually run evolution
myself:
$ evolution
…
(evolution:24611): GLib-GIO-ERROR **: 16:03:44.198: Settings
schema
'org.gnome.desktop.lockdown' is not installed
Trace/breakpoint trap
$
Ah, GNOME.
Kind regards,
T G-R
[-- Attachment #1.2: 0001-gnu-evolution-Propagate-evolution-data-server.patch --]
[-- Type: text/x-patch, Size: 1475 bytes --]
From accd1c79a52dd7d267cf13cc67cfdd8c8a8e160c Mon Sep 17 00:00:00 2001
From: Tobias Geerinckx-Rice <me@tobias.gr>
Date: Sat, 30 Mar 2019 16:06:08 +0100
Subject: [PATCH] gnu: evolution: Propagate evolution-data-server.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* gnu/packages/gnome.scm (evolution)[inputs]: Move evolution-data-server…
[native-inputs]: …here.
---
gnu/packages/gnome.scm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 060379aba9..a6395974b0 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -7584,7 +7584,6 @@ generic enough to work for everyone.")
("itstool" ,itstool)))
(inputs
`(("enchant" ,enchant)
- ("evolution-data-server" ,evolution-data-server) ; must be the same version
("gcr" ,gcr)
("gnome-autoar" ,gnome-autoar)
("gnome-desktop" ,gnome-desktop)
@@ -7598,6 +7597,8 @@ generic enough to work for everyone.")
("openldap" ,openldap)
("webkitgtk" ,webkitgtk)
("ytnef" ,ytnef)))
+ (propagated-inputs
+ `(("evolution-data-server" ,evolution-data-server))) ; must be same version
(home-page "https://gitlab.gnome.org/GNOME/evolution")
(synopsis "Manage your email, contacts and schedule")
(description "Evolution is a personal information management application
--
2.21.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply related [relevance 99%]
* bug#35210: Error building linux-libre on Overdrive 1000
@ 2019-04-09 19:37 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-04-09 19:37 UTC (permalink / raw)
To: Andreas Enge; +Cc: Guix-devel, 35210
[-- Attachment #1: Type: text/plain, Size: 256 bytes --]
Andreas,
Andreas Enge wrote:
> I confirm after just trying to reconfigure, with commit
> 36dbad3858ca4229e9ec319bd4983fca7835067d.
> Cc-ing the bug tracker.
Thanks! I wasn't expecting to hit an ‘actual’ bug. Yaay.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35242: Backtrace on building with load path
@ 2019-04-12 12:40 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-04-12 12:40 UTC (permalink / raw)
To: brettg, 35242
[-- Attachment #1: Type: text/plain, Size: 166 bytes --]
Brett,
brettg@posteo.net wrote:
> Backtrace:
Could you ‘export COLUMNS’ so we can see the backtrace in its
untruncated glory?
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35268: guix system won't open config files in tmpfs
@ 2019-04-14 21:22 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-04-14 21:22 UTC (permalink / raw)
To: 35268
[-- Attachment #1: Type: text/plain, Size: 295 bytes --]
rendaw,
What kind of environment are you in? The Guix 0.16.0 live
installer image? Something else?
rendaw wrote:
> I think there's two issues here:
[...]
> 2. The error message is misleading
Too early to proclaim that. It could be a namespace issue, for
example.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35301: Guix's Eolie pushes google.com as default search and home page
@ 2019-04-17 2:07 99% Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-04-17 2:07 UTC (permalink / raw)
To: 35301
[-- Attachment #1: Type: text/plain, Size: 656 bytes --]
Guix,
After installing the eolie Web browser from Guix and opening it
for the first time, it immediately loads www.google.com. This was
an unpleasant surprise to me (I lead a sheltered life) and I
consider it a bug.
From cursory source-pokin's it seems pretty trivial to change the
default start page to guix.info or about:blank.
However, www.google.com is also used as the default search engine
when the user mistypes a URL or searches from the navigation bar.
Not good! There doesn't seem to be a way to disable that, only to
change the providers.
Built-in alternatives are DuckDuckGo and Qwant. Are they any
better?
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35382: I found a bug in guix pull \o/ (maybe)
@ 2019-04-22 16:10 99% Tobias Geerinckx-Rice
[not found] ` <handler.35382.B.155594948512132.ack@debbugs.gnu.org>
0 siblings, 2 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-04-22 16:10 UTC (permalink / raw)
To: 35382
[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]
Guix,
I ran into the following running ‘guix pull’ from the 0.16.0
aarch64 binary tarball on the original Overdrive OpenSUSE.
Apologies for the truncation, but this happened over the serial
console. I'm running ‘guix pull’ with output redirection now, and
it's been running for a suspiciously long time without errors…
Kind regards,
T G-R
=== 8< ---
In ./guix/monads.scm:
482:9 8 (_ _)
In ./guix/gexp.scm:
573:13 7 (_ _)
In ./guix/store.scm:
1667:8 6 (_ _)
1690:38 5 (_ #<store-connection 256.99 3680d420>)
In ./guix/packages.scm:
936:16 4 (cache! #<weak-table 421/883> #<package
guile-ssh@0.11?> ?)
In ./guix/grafts.scm:
314:4 3 (graft-derivation #<store-connection 256.99 3680d420>
# ?)
192:4 2 (references-oracle #<store-connection 256.99
3680d420> #)
201:20 1 (_ _ _)
In ./guix/store.scm:
1203:15 0 (_ #<store-connection 256.99 3680d420> _ _)
./guix/store.scm:1203:15: Throw to key `srfi-34' with args
`(#<condition &store-protocol-error [message: "build .
guix pull: error: You found a bug: the program
'/gnu/store/j3sfsynqhkdcp4gjr558xdfqszjb6n45-compute-guix-derivat'
failed to compute the derivation for Guix (version:
"56a4858210ebaf45c32dc99bdfbd12b9bc5a234e"; system: "aarch64;
host version: "0.16.0"; pull-version: 1).
Please report it by email to <bug-guix@gnu.org>.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35382: I found a bug in guix pull \o/ (maybe)
@ 2019-04-23 13:37 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-04-23 13:37 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 35382
[-- Attachment #1: Type: text/plain, Size: 366 bytes --]
Ludo',
Oh, I just replied to close this bug since it was easily (if
slowly) worked around by using an intermediate commit.
Ludovic Courtès wrote:
> Often there’s a more useful hint above; could you paste the
> missing bits
> that came just before? :-)
Heh. Nope. Managed to overwrite the log file with unexpected
success.
Thanks,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35382: I found a bug in guix pull \o/ (maybe)
[not found] ` <handler.35382.B.155594948512132.ack@debbugs.gnu.org>
@ 2019-04-23 13:34 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-04-23 13:34 UTC (permalink / raw)
To: 35382-done
[-- Attachment #1: Type: text/plain, Size: 631 bytes --]
Tobias Geerinckx-Rice wrote:
> ./guix/store.scm:1203:15: Throw to key `srfi-34' with args
> `(#<condition &store-protocol-error [message: "build .
> guix pull: error: You found a bug: the program
> '/gnu/store/j3sfsynqhkdcp4gjr558xdfqszjb6n45-compute-guix-derivat'
> failed to compute the derivation for Guix (version:
> "56a4858210ebaf45c32dc99bdfbd12b9bc5a234e"; system: "aarch64;
> host version: "0.16.0"; pull-version: 1).
I can avoid this by pulling from
--commit=15dca289b8bd1418c5f5f3b545cb497497cad02e. Then I can
pull to HEAD just fine.
Closing since that's a good enough work-around for me :-)
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35395: GUIX website redirections are failing
@ 2019-04-23 15:40 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-04-23 15:40 UTC (permalink / raw)
To: 35395
[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]
Boruch,
Boruch Baum wrote:
> The guix homepage[1] links to other pages[2][3] that claim
> "Redirecting
> to the new page location... ", but they don't, at least not for
> me using
> emacs-w3m and firefox-esr v60.
The links aren't broken, but implemented in a very… special way:
~ λ curl
https://www.gnu.org/software/guix/manual/html_node/Features.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<title>Page has moved! — GNU Guix</title>
<noscript><meta http-equiv="refresh" content="0;
url=../en/html_node/Features.html"></noscript>
</head>
<body onload="window.location =
'../en/html_node/Features.html';">
[…]
I.e. inject arbitrary code into the user's browser and if it
catches us, fall back to http-equiv hackery. Not good!
The fix is to send out real (HTTP 307/302) redirections, but the
problem might be that gnu.org won't let us.
Kind regards,
T G-R
> This is also the case from the guix 'help' page[4] link to the
> system
> manual[5]. Other links[6][7] on that page do work.
>
> references:
> [1] https://www.gnu.org/software/guix/
> [2]
> https://www.gnu.org/software/guix/manual/html_node/Features.html
> [3]
> https://www.gnu.org/software/guix/manual/html_node/Using-the-Configuration-System.html
> [4] https://www.gnu.org/software/guix/help/
> [5]
> https://www.gnu.org/software/guix/manual/html_node/GNU-Distribution.html
> [6] https://www.gnu.org/manual/
> [7] https://www.gnu.org/software/guix/manual/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35417: Tor Service
@ 2019-04-24 18:53 99% ` Tobias Geerinckx-Rice
1 sibling, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-04-24 18:53 UTC (permalink / raw)
To: 35417-done
[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]
Raghav,
Raghav Gururajan wrote:
> Including "tor-service-type" does not invoke and add "tor"
> package into
> the system.
To use the ‘tor’ command, like any other package, you must install
the ‘tor’ package into either the system profile (using
SYSTEM-PACKAGES) or that of your user (using ‘guix package’).
I'd recommend SYSTEM-PACKAGES in this case so the tor commands
will always match the version of Tor used by the service.
This is by design; services can't pollute the environment of
users, including the system profile. That's a good thing.
> Therefore, "tor-service-type" is of little or no use, if it does
> not
> invoke and add "tor" package into the system.
That's just not true. The tor service does its job and works just
fine without the ‘tor’ command. I just checked both of my Tor
nodes (both run Guix :-) and neither of them have ‘tor’ installed
into any profile. Nyx and herd (and emacs torrc) are all I need
to administrate them.
I'm closing this because there's no bug here…
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35416: OpenVPN Client Service
@ 2019-04-25 18:40 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-04-25 18:40 UTC (permalink / raw)
To: 35416
[-- Attachment #1: Type: text/plain, Size: 732 bytes --]
Raghav,
Raghav Gururajan wrote:
> Including "openvpn-client-service-type" does not invoke and add
> "openvpn" package into the system.
This is basically bug #35417, so I'm going to merge (and close)
both of them. You'll find that this is true for all services, and
these are not bugs. Really! :-)
> Therefore, "openvpn-client-service-
> type" is of no use, if it does not invoke and add "openvpn"
> package
> into the system.
Strongly disagree.
What's ‘invoke’ supposed to mean here? The openvpn service *does*
invoke openvpn.
If you want (your) user to do the same, like all packages, openvpn
must be added to SYSTEM-PACKAGES or installed into their own
profile.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35417: closed (Re: Tor Service)
@ 2019-04-25 18:31 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-04-25 18:31 UTC (permalink / raw)
To: 35417
[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]
Raghav,
Raghav Gururajan wrote:
> DOUBT!
‘Doubt is an uncomfortable condition,
but certainty is a ridiculous one.’
— Voltaire, more or less
> So the package "tor" actually used when using the service
> "tor-service-type". Then why the package "tor" isn't added to
> the system as it is not showing up in the system packages list?
‘…why should it be’? :-)
I think the confusion here stems from vague terms like ‘added to
the system’. It sounds like you're still adjusting to Guix
vs. traditional FHS distributions where everything is thrown into
one big pile — which is completely understandable!
As you found out, all the Tor service really does is start the
‘tor’ binary. Hence, Tor is indeed installed to your store
(/gnu/store/*-tor-*/bin/tor) and is invoked by the Shepherd when
your system starts.
But that's completely unrelated to your system profile (which is
what I think you mean by ‘system packages list’; the profile
generated from the SYSTEM-PACKAGES field of your
OPERATING-SYSTEM). To use Tor from the command line, simply add
‘tor’ to that field.
Unlike other distributions, Guix System doesn't make a package's
binaries available to *all users* merely because a *service*
depends on them. The two steps are (rightly) completely separate.
Does that help?
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* Re: Transmission BitTorrent Client
@ 2019-04-26 21:59 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-04-26 21:59 UTC (permalink / raw)
To: guix-devel; +Cc: bug-guix
[-- Attachment #1: Type: text/plain, Size: 616 bytes --]
Raghav,
Raghav Gururajan wrote:
> I tried installing the package "Transmission". It is not showing
> up in
> GNOME Menu.
Transmission's GTK GUI interface is in a separate package output
(to keep the main output from depending on GTK+, which is quite
huge). Install ‘transmission:gui’ and you'll be happy.
The :gui output also provides a .desktop file that should make
things like GNOME add it to their launcher.
> Typing "transmission" on terminal also not starting the
> application.
The command is ‘transmission-gtk’; ‘transmission’ doesn't exist.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35551: package gcc does not depend on binutils and glibc
@ 2019-05-04 0:20 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-04 0:20 UTC (permalink / raw)
To: 35551; +Cc: Bruno Haible, 35551-done
[-- Attachment #1: Type: text/plain, Size: 421 bytes --]
Bruno,
Welcome!
Nicolas Goaziou wrote:
> You are really looking for `gcc-toolchain' package. See section
> 2.6.6 in
> the manual.
Yup! :-)
‘Toolchain’ exactly describes what you're looking for, so I'm
going to go ahead and close this bug.
(Speaking as a user, I'd be annoyed to the point of switching if
my distro installed ‘binutils’ when asked for ‘gcc’.)
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35583: Setting a GRUB keyboard-layout breaks GRUB… and Linux‽
@ 2019-05-05 16:27 97% Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-05 16:27 UTC (permalink / raw)
To: 35583
[-- Attachment #1: Type: text/plain, Size: 2714 bytes --]
Guix,
Some (=none) of you might remember my X keyboard woes on #guix,
where I was stuck without a backspace key or the key below it (\,
|) on my ThinkPad X230T's US keyboard. Both sent out
‘XF86ScreenSaver’ codes instead.
I tried dozens of things, both in my system configuration and by
running random stateful xkb commands (naughty), and managed to
‘fix’ the bug without ever finding the cause (very naughty).
I think I was looking for it in all the wrong places. Something
goes wrong before the kernel even boots. Here's my
keyboard-layout:
(keyboard-layout
(keyboard-layout
"us" "dvp" ;
kaufmann.no/roland/dvorak
#:model "thinkpad" ; pc104, pc105, thinkpad,
…
#:options ; list of XKB Option
strings
(list "" ; unset all inherited
options
"caps:shiftlock" ; Shift Lock affects all
keys
"shift:breaks_caps" ; Shift cancels Caps Lock
"compose:102" ; next to left Shift on
pc105
"lv3:ralt_switch" ; key to choose 3rd level
"nbsp:level3n" ; nbsp @lv3, thin nbsp
@lv4
"numpad:shift3" ; Num Lock: Shift chooses
lv3
"kpdl:semi" ; key pad semicolon @lv3
"misc:typo" ; add extra typographic
chars
"ctrl:swapcaps" ; onwards for great Emacs
"terminate:ctrl_alt_bksp"))) ; zap X just to watch it
die
Here's what works just fine:
(service slim-service-type
(slim-configuration
(xorg-configuration
(xorg-configuration
(keyboard-layout keyboard-layout)
…
However, today I tried to (re-)add it to GRUB, too, and ended up
writing the following comment:
(bootloader
(bootloader-configuration
(bootloader grub-efi-bootloader)
;; XXX Strange bug: GRUB can read the LUKS passphrase, but
afterwards (at
;; the menu screen) no longer responds to key presses. Even
stranger: it
;; makes my X230T's backspace key send ‘XF86ScreenSaver’s even
on Linux.
;; (keyboard-layout keyboard-layout)
(target "/boot/efi")
(timeout 1))))
This is 100% reproducible.
I'll try to narrow it down a bit, but the combination of losing my
actual work-workstation (which is also my funstation) while
entering my passphrase 5 times, every time, makes that an
unpleasant and tedious affair.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 97%]
* bug#35588: [PATCH] ui: Search matches additional package outputs.
@ 2019-05-05 21:41 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-05 21:41 UTC (permalink / raw)
To: 35588
* guix/ui.scm (%package-metrics): Add a PACKAGE-OUTPUTS metric with a
relevance of 1.
* guix/scripts/package.scm (process-query)<search>: Add the
REGEXP/NEWLINE flag.
---
mikadoZero, Guix,
Here's a patch to match package outputs (except ‘out’, since it can't affect the relative score) in ‘guix search’.
Before:
~ λ guix search ernel-patch
# nothing
After:
~ λ guix search ernel-patch
name: wireguard
version: 0.0.20190406
outputs: out kernel-patch
…
~ λ guix search ^ernel-patch
# nothing
While the new REGEXP/NEWLINE flag affects how all fields are matched, I don't think it actually changes anything in practice without the second hunk.
If there's a possibility that it might, I'd split this into two commits.
Kind regards,
T G-R
guix/scripts/package.scm | 3 ++-
guix/ui.scm | 6 ++++++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
index aa27984ea2..a31e78484e 100644
--- a/guix/scripts/package.scm
+++ b/guix/scripts/package.scm
@@ -751,7 +751,8 @@ processed, #f otherwise."
(('query 'search rx) rx)
(_ #f))
opts))
- (regexps (map (cut make-regexp* <> regexp/icase) patterns)))
+ (regexps (map (cut make-regexp* <> regexp/icase regexp/newline)
+ patterns)))
(leave-on-EPIPE
(let-values (((packages scores)
(find-packages-by-description regexps)))
diff --git a/guix/ui.scm b/guix/ui.scm
index 92c845e944..f2466b605b 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -1404,6 +1404,12 @@ score, the more relevant OBJ is to REGEXPS."
;; of regexps.
`((,package-name . 4)
+ ;; Separate package outputs by newlines to match regexps like "^tools$".
+ ;; Hard-codedly ignore ‘out’ since it presumably exists for every package.
+ (,(lambda (package)
+ (string-join (delete "out" (package-outputs package))
+ "\n")) . 1)
+
;; Match regexps on the raw Texinfo since formatting it is quite expensive
;; and doesn't have much of an effect on search results.
(,(lambda (package)
--
2.21.0
^ permalink raw reply related [relevance 99%]
* bug#35604: Is the top bootloader entry for previous generations the current one?
@ 2019-05-06 18:52 99% ` Tobias Geerinckx-Rice
2019-05-06 18:59 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-06 18:52 UTC (permalink / raw)
To: pelzflorian (Florian Pelz); +Cc: 35604
[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]
Florian,
pelzflorian (Florian Pelz) wrote:
> GRUB’s boot menu displays a menuentry for booting the current
> generation and a submenu with entries for previous generations.
> However, it is not clear if the generation at the top of the
> submenu
> is the current generation or if it is one generation before.
The current generation is by definition not a previous one and
shouldn't appear in the ‘previous’ list, but I see how it could be
confusing. Especially once possible language barriers and
translations are added to the mix.
> I would prefer to resolve this by displaying the current
> generation’s
> generation number and date outside the submenu as is done for
> the
> previous generations in the submenu.
It makes for an uglier boot menu, which sounds silly, but I've
noticed that the more numbers and symbols are on a screen, the
more likely ‘non-geeks’ are to ignore the whole thing as something
not meant for them to understand. Especially a black one :-) I
see it as part of GNU's values to counter that attitude.
How about changing ‘previous generations’ to ‘all generations’,
and have it include the current generation at the top (now with #
and date, maybe ‘(current)’ appended)?
That way we can keep the default nice and friendly and skimmable
in ~5s, and the overview is actually a complete overview.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35604: Is the top bootloader entry for previous generations the current one?
2019-05-06 18:52 99% ` Tobias Geerinckx-Rice
@ 2019-05-06 18:59 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-06 18:59 UTC (permalink / raw)
To: 35604
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
Tobias Geerinckx-Rice wrote:
> How about changing ‘previous generations’ to ‘all generations’,
> and
> have it include the current generation at the top (now with #
> and
> date, maybe ‘(current)’ appended)?
>
> That way we can keep the default nice and friendly and skimmable
> in
> ~5s, and the overview is actually a complete overview.
I'd like to give this patch a try, by the way, if it's considered
acceptable. Good excuse to dive into Guix's grub code a tiny bit.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35586: GNOME
@ 2019-05-06 19:20 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-06 19:20 UTC (permalink / raw)
To: Raghav Gururajan; +Cc: 35586
[-- Attachment #1: Type: text/plain, Size: 1907 bytes --]
Raghav,
Thanks for taking a look at this. I'm sure there's plenty to be
improved in how we package a large collection of software like
GNOME in an intuitive way.
Raghav Gururajan wrote:
> The following gnome core applications have already been included
> in
> guix's gnome package but requires correct renaming?
>
> epiphany --> gnome-web
Using ‘correct’ here is a bit strong.
~ λ guix install epiphany
~ λ gnome-web
bash: gnome-web: command not found
~ λ epiphany
# browsin' time
While we don't blindly name packages after the binaries they
provide, of course, a look at the project's own publications
doesn't reduce the confusion. Ironic.
“Web is the web browser for the GNOME desktop and for elementary
OS,
based on the popular WebKit engine. It offers a simple, clean,
beautiful view of the web featuring first-class GNOME and
Pantheon
desktop integration. Its code name is Epiphany.
You may install Web from the software repositories of most
Linux
operating systems, where it is normally packaged as
"epiphany-browser" or "epiphany". ”[0]
The README[1] mainly, but not exclusively, talks about ‘Epiphany’.
Even the two URLs balance each other out. I don't think there's
enough here to justify gross renaming, and in the name of all
that's holy let's avoid another mass renaming incident.
Personally, I think adding ‘GNOME Foo’ to the synopses of all
these packages is sufficient (epiphany does this by coincidence,
calling itself the ‘GNOME web browser’). Eventually, this could
be another use for the separate (G)UI display name field as
suggested in the games thread. :-)
Package names aren't opaque identifiers, but they can be a little
technical IMO.
Kind regards,
T G-R
[0]: https://wiki.gnome.org/Apps/Web
[1]: https://github.com/GNOME/epiphany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35606: Gajim
@ 2019-05-06 19:40 89% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-06 19:40 UTC (permalink / raw)
To: Raghav Gururajan, Clément Lassieur, Ricardo Wurmus; +Cc: 35606
[-- Attachment #1: Type: text/plain, Size: 3994 bytes --]
Raghav, Clément, Ricardo, Guix,
Raghav Gururajan wrote:
> ## Versions
> - OS: Linux
Never heard of that OS… ;-)
> - GTK+ Version: 3.24.7
> - PyGObject Version: 3.28.3
> - python-nbxmpp Version: 0.6.10
> - Gajim Version: 1.1.3
Thanks for these, but providing the output of ‘guix describe’
instead (and making sure both your system and user's packages have
been fully updated to that version) would be even more
informative.
> ## Traceback
I can't reproduce this, by the way (output below). Gajim opens a
window and a welcome wizard (which I close). Then I'm left with
the main window where all the menus work… but all options are
greyed out (except a few under ‘View’). So the programme isn't
frozen, but I can't close it, not even using my window manager's
key bindings. Hence the SIGINT at the end.
Very strange. Is anyone successfully using Gajim on Guix System?
Clément? Ricardo?
Kind regards,
T G-R
~ λ gajim
(..gajim-real-real:23682): dbind-WARNING **: 21:27:06.317: AT-SPI:
Error retrieving accessibility bus address:
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus
was not provided by any .service files
creating /home/nckx/.config/gajim directory
creating /home/nckx/.cache/gajim directory
creating /home/nckx/.local/share/gajim directory
creating /home/nckx/.local/share/gajim/certs directory
creating /home/nckx/.local/share/gajim/debug directory
creating /home/nckx/.local/share/gajim/plugins_data directory
creating /home/nckx/.config/gajim/pluginsconfig directory
creating /home/nckx/.config/gajim/localcerts directory
creating /home/nckx/.cache/gajim/plugins_download directory
creating /home/nckx/.local/share/gajim/plugins directory
creating /home/nckx/.cache/gajim/avatars directory
creating /home/nckx/.config/gajim/theme directory
Traceback (most recent call last):
File
"/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/application.py",
line 221, in _activate
self.interface.run(self)
File
"/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/gui_interface.py",
line 2550, in run
app.plugin_manager = plugins.PluginManager()
File
"/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/plugins/helpers.py",
line 129, in __call__
cls.instance = super(Singleton, cls).__call__(*args, **kwargs)
File
"/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/plugins/pluginmanager.py",
line 115, in __init__
pc = self.scan_dir_for_plugins(path)
File
"/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/plugins/helpers.py",
line 114, in wrapper
result = f(*args, **kwargs)
File
"/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/plugins/pluginmanager.py",
line 598, in scan_dir_for_plugins
if not os.path.isdir(path):
File
"/gnu/store/h8l1pby3cm6b4fxsfwwr65b4d1hyh6cs-python-3.7.0/lib/python3.7/genericpath.py",
line 42, in isdir
st = os.stat(s)
TypeError: stat: path should be string, bytes, os.PathLike or
integer, not NoneType
06/05/19 21:27:07 (E) gajim.notify Notifications D-Bus connection
failed
Traceback (most recent call last):
File
"/gnu/store/lzzphfg2hf52h1cb2dbvz3qvz2ca26na-gajim-1.1.3/lib/python3.7/site-packages/gajim/notify.py",
line 96, in on_proxy_ready
self.daemon_capabilities = proxy.GetCapabilities()
File
"/gnu/store/f34bv1iaghh7hsymqm57abi8p1lyavv6-python-pygobject-3.28.3/lib/python3.7/site-packages/gi/overrides/Gio.py",
line 204, in __call__
None)
GLib.GError: g-dbus-error-quark:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.freedesktop.Notifications was not provided by any .service
files (2)
^CSIGINT/SIGTERM received
~ λ
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 89%]
* bug#35561: Fresh install, guix pull exits with error, hash mismatch
@ 2019-05-06 22:59 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-06 22:59 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 35561, Calle Kabo
[-- Attachment #1: Type: text/plain, Size: 430 bytes --]
Ludo',
Ludovic Courtès wrote:
> These 3 files are now available from https://ci.guix.gnu.org as
> substitutes:
Thanks! I tried to help Calle with this on IRC yesterday but had
to make due with my own little build farm (which had already
collected 2 of the 3 files) and scp…
Did you do a fancier version of this, or is there a better
(automated?) way we could handle this in future?
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35566: Dvorak keyboard layout in graphical installl mode
@ 2019-05-07 13:23 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-07 13:23 UTC (permalink / raw)
To: Daniel Dinnyes; +Cc: 35566
[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]
Daniel, Guix,
Ludovic Courtès wrote:
> Daniel Dinnyes <dinnyesd@gmail.com> skribis:
>> I found that in the graphical install mode, while
>> being asked for keyboard layout, there was no option for Dvorak
>> layout.
> The Dvorak layout is there, but maybe not where you expect: you
> have to
> first select, say, the “English (US)” layout, which brings you
> to a
> second page where you can choose a variant, one of which is
> Dvorak
> (screenshot below.)
Not bein' snarky here: where else would you expect it to be? I've
never seen the DSK categorised as anything but ‘US (Dvorak)’. The
layout itself is pretty anglocentric, and even (I mean: of course)
the UK Dvorak subtly differs from the US one.
I assume this isn't the first time you've installed a GNU/Linux
distribution, so I'm curious where you found it on others. Do
they flat-out alias ‘Dvorak’ to the US variant? Not convinced we
should emulate that.
Side note: the Debian (or was it Ubuntu?) installer has a great
feature to help you figure out your keyboard layout in the minimum
number of keystrokes. I wonder if we could use that decision tree
data in our own installer. IME most people have no idea what the
name of their keyboard layout is; it's always ‘er, the regular
one?’ to them.
Imma check it out,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35561: Fresh install, guix pull exits with error, hash mismatch
@ 2019-05-07 16:13 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-07 16:13 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 35561
[-- Attachment #1: Type: text/plain, Size: 705 bytes --]
Ludo',
Ludovic Courtès wrote:
> The reason substitutes were not used is that Guix cached the
> fact that
> substitutes weren’t available. They became available in the
> meantime
> but the cached entry hasn’t expired yet.
>
> To work around it, you could wait some more :-), or you can do:
>
> guix pull --substitute-urls=https://berlin.guixsd.org
>
> berlin.guixsd.org provides the same contents as ci.guix.gnu.org.
> However, that will trick Guix into building a fresh cache for
> that
> machine.
I just ‘sudo rm -rf /var/guix/substitute/cache/*’ when this
happens, and it seems to work, but I'm curious why you didn't
recommend it here.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35551: package gcc does not depend on binutils and glibc
@ 2019-05-07 16:23 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-07 16:23 UTC (permalink / raw)
To: Bruno Haible; +Cc: 35551
[-- Attachment #1: Type: text/plain, Size: 729 bytes --]
Bruno,
Bruno Haible wrote:
>> (Speaking as a user, I'd be annoyed to the point of switching
>> if
>> my distro installed ‘binutils’ when asked for ‘gcc’.)
>
> Well, 'guix install emacs' installs more than emacs as well:
> graphviz, ghostscript, python, fftw, cups, ...
Oh, we're talking about different things then.
Installing (in any sense) emacs will add its dependencies to the
store (your ‘install’), but doesn't propagate them into the
profile (my ‘install’):
~ λ guix environment --pure --ad-hoc emacs
~ λ dot
bash: dot: command not found
I tend to avoid the unqualified term ‘install’ on Guix for this
reason. Sorry for the confusion!
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35551: guix search
@ 2019-05-10 23:41 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-10 23:41 UTC (permalink / raw)
To: Bruno Haible; +Cc: 35551-done
[-- Attachment #1: Type: text/plain, Size: 884 bytes --]
Bruno Haible wrote:
> Mark H Weaver wrote:
>> If we add functionality that calls out to the network in
>> response to a
>> package search, e.g. to query popularity ratings or package
>> file
>> listings, we should make sure the user knows it's happening,
>> and provide
>> a way to disable it. Some users may not want information about
>> their
>> package searches to be leaked to the outside world.
>
> Good point.
>
> Would it be more acceptable, upon 'guix search', to download an
> incremental
> update of a package popularity database, and do the search
> locally? This
> way, only the fact that the user has been doing a 'guix search'
> would be
> leaked to the outside world, not the search term.
I don't think Mark intended to present it as a good idea at all…
;-)
Popularity is irrelevant to search relevance.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35683: wishlist: addessing statefulness of .cache(s)
@ 2019-05-11 11:45 99% ` Tobias Geerinckx-Rice
1 sibling, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-11 11:45 UTC (permalink / raw)
To: 35683
[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]
ehlo Giovanni,
Giovanni Biscuolo wrote:
> AFAIU unfortunately we have application/library state all over
> .cache(s)
> that sometimes crashes software *and* trying to fix this
> upstream it's
> _not_ an option [1]
Oh. That's… disappointing to say the least, since these are both
upstream bugs that Guix can't fix :-(
What exactly did you ask? What was their response?
> often users have to delete something in some .cache by guessing,
> "just"
> to solve some strange software crash (this is common to all
> distros)
I have never had to do this, ever.
> maybe an activation service extension proposed by Ricardo (see
> above)
> is the right solution: I'll try to make a summary of prevoius
> discussions on this topic on guix-devel to help address this
> (class of)
> issue(s)... sorry I cannot help coding it
We can randomly delete whole caches in the user's stead but it's
never the ‘right’ solution. Only the application can manage its
caches properly. I still hope this is possible in both cases
here.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35683: wishlist: addessing statefulness of .cache(s)
@ 2019-05-11 11:51 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-11 11:51 UTC (permalink / raw)
To: Julien Lepiller; +Cc: 35683
[-- Attachment #1: Type: text/plain, Size: 220 bytes --]
Julien,
Julien Lepiller wrote:
> I wonder if we could mount a tmpfs on .cache? Would that be
> enough?
Seems a shame to waste RAM like that, when we could (ab)use FUSE:
<https://github.com/xrgtn/nullfs>.
;-)
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35623: FW: bug#35623: guix pull failed on RHEL7
@ 2019-05-11 19:07 99% ` Tobias Geerinckx-Rice
2019-05-11 21:42 99% ` Tobias Geerinckx-Rice
0 siblings, 2 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-11 19:07 UTC (permalink / raw)
To: Ludovic Courtès, 35623
[-- Attachment #1: Type: text/plain, Size: 360 bytes --]
Ludo',
Ludovic Courtès wrote:
> Commit 48d498c2c3984784336b27ba5e261319f3ac6a3a lets HOME pass
> through, which should sidestep the problem you encountered.
This breaks ‘guix pull’, but I can't for the life of me see how
HOME is being applied here.
Could you enlighten me?
Kind regards,
T G-R
[0]: https://paste.debian.net/1083404/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35623: FW: bug#35623: guix pull failed on RHEL7
2019-05-11 19:07 99% ` bug#35623: FW: " Tobias Geerinckx-Rice
@ 2019-05-11 21:42 99% ` Tobias Geerinckx-Rice
1 sibling, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-11 21:42 UTC (permalink / raw)
To: Ludovic Courtès, 35623
[-- Attachment #1: Type: text/plain, Size: 360 bytes --]
Tobias Geerinckx-Rice wrote:
> Ludovic Courtès wrote:
>> Commit 48d498c2c3984784336b27ba5e261319f3ac6a3a lets HOME pass
>> through, which should sidestep the problem you encountered.
>
> This breaks ‘guix pull’, but I can't for the life of me see how
> HOME
> is being applied here.
I've reverted the change for now.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35623: FW: bug#35623: guix pull failed on RHEL7
@ 2019-05-12 22:47 99% ` Tobias Geerinckx-Rice
2019-05-12 23:09 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-12 22:47 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 35623-done
[-- Attachment #1: Type: text/plain, Size: 204 bytes --]
Ludovic Courtès wrote:
> e0244eb7a2290781ef490b6cedbd9c753caf6004.
Hmm. I guess I'll give ‘SRFI-45 - Primitives for Expressing
Iterative Lazy Algorithms’(?) a read, then.
Thanks,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35623: FW: bug#35623: guix pull failed on RHEL7
2019-05-12 22:47 99% ` Tobias Geerinckx-Rice
@ 2019-05-12 23:09 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-12 23:09 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 35623-done
[-- Attachment #1: Type: text/plain, Size: 444 bytes --]
Tobias Geerinckx-Rice wrote:
> Ludovic Courtès wrote:
>> e0244eb7a2290781ef490b6cedbd9c753caf6004.
>
> Hmm. I guess I'll give ‘SRFI-45 - Primitives for Expressing
> Iterative
> Lazy Algorithms’(?) a read, then.
Never mind, that was the first ‘->’ that looked relevant at first
glance but it's metasyntactic like most ‘->’s in the Guile manual…
I found it in the Guix manual, of course.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35759: [Manual installation] ‘mount /mnt’'s in the ‘Partitioning’ section.
@ 2019-05-16 1:54 99% Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-16 1:54 UTC (permalink / raw)
To: 35759
[-- Attachment #1: Type: text/plain, Size: 845 bytes --]
Guix,
[This is for after 1.0.1, but I'd forget otherwise.]
This happened to a new user on IRC tonight, and I understand their
logic. After guided partitioning (using the installer),
installation failed, and they decided to continue manually.
Here's where they started:
3.6 Manual Installation
=======================
…
* Menu:
* Keyboard Layout and Networking and Partitioning:: Initial
setup.
* Proceeding with the Installation:: Installing.
Having just ‘partitioned’, they ‘proceeded’. The first task in
that section is ‘herd start cow-store’, which fails because /mnt
isn't mounted yet. According to our manual, that's also part of
‘partitioning’. Eh. I get why, but would prefer to reorganise
this a bit to make such errors less likely.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35800: [art] "GuixSD" on xfce screenshot
@ 2019-05-19 19:54 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-19 19:54 UTC (permalink / raw)
To: 35800
[-- Attachment #1.1: Type: text/plain, Size: 421 bytes --]
swedebugia wrote:
> http://guix.gnu.org/screenshots/xfce/
>
> replace/remove "SD"
>
> I did a quick edit of the png - see attached.
Thanks!
As much as I like the ‘GNU Guix: the System THEY don't want you to
know about!’ censorship vibe, here's a slightly more subtle
attempt based on the current Icecat rendering of guix.gnu.org.
It even uses HTTPS, for extra security.
Kind regards,
T G-R
[-- Attachment #1.2: guix-xfce-mockup.png --]
[-- Type: image/png, Size: 218408 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35800: [art] "GuixSD" on xfce screenshot
@ 2019-05-20 12:21 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-20 12:21 UTC (permalink / raw)
To: Ludovic Courtès, swedebugia; +Cc: 35800
[-- Attachment #1: Type: text/plain, Size: 201 bytes --]
Ludovic Courtès wrote:
> How does that sound? :-)
…a lot less funny? :-(
Swedebugia, would you like to do that boring ‘VM’ thing instead
(and convert it to PNG)?
Thanks,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35864: ~/.local/bin is missing in default PATH on Guix System
@ 2019-05-23 14:55 99% ` Tobias Geerinckx-Rice
1 sibling, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-23 14:55 UTC (permalink / raw)
To: 35864
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
pelzflorian (Florian Pelz) wrote:
> ~/.local/bin should be added to the PATH environment variable by
> default, see
So ~/.local/bin is a relatively recent systemd thing[1], replacing
the conventional ~/bin.
My theory is that it's intended for users of graphical file
browsers (where the traditional ~/bin is a bit too prominent even
for my tastes), but I use it too.
It's trivial to augment $PATH yourself, whether or not your
distribution is systemd-based.
> <https://unix.stackexchange.com/questions/316765/which-distributions-have-home-local-bin-in-path>.
That link doesn't support adding (or not adding) it.
Kind regards,
T G-R
[1]:
https://www.freedesktop.org/software/systemd/man/file-hierarchy.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35864: ~/.local/bin is missing in default PATH on Guix System
@ 2019-05-23 19:31 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-23 19:31 UTC (permalink / raw)
To: 35864
[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]
pelzflorian (Florian Pelz) wrote:
> Adding ~/.local/bin to the PATH is common on other distros.
This is what still needs to be established: is it? Which ones?
Is it merely a side-effect of them using systemd? And most
crucially: does it mean that Guix needs to add it too? What about
~/bin?
I'm was just interested in the (ideally: your) arguments for doing
so, not a link to a discussion site. If it really breaks things
that should work, I'm all in favour of adding it to the default
skeleton, if not /etc/profile itself.
> When compiling and installing software as a user without making
> a package
> for it, I want to configure it with --prefix=$HOME/.local so I
> can
> install without sudo. Then I want to be able to run:
>
> myprog
>
> instead of
>
> PATH=$HOME/.local/bin myprog
You can already easily add custom directories to $PATH in your
.bash_profile, if my understanding of bash's complicated set of
configuration files is still accurate. That's where I set it,
anyway:
~ λ grep PATH= .bash_profile
PATH="$HOME/.local/bin:$PATH"
and it's always worked fine. :-)
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35864: ~/.local/bin is missing in default PATH on Guix System
@ 2019-05-23 19:35 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-23 19:35 UTC (permalink / raw)
To: pelzflorian (Florian Pelz); +Cc: 35864
[-- Attachment #1: Type: text/plain, Size: 434 bytes --]
pelzflorian (Florian Pelz) wrote:
>> That link doesn't support adding (or not adding) it.
>
> The people who responded accept that it is a bug in Ubuntu.
Whoa! This is not a fair summary. The only ‘bug’ there is that
Ubuntu (and RHEL's?) *implementation* was buggy, nothing more.
Nowhere is it implied that a distribution not adding .local/bin to
people's PATH is in any way ’buggy’.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35942: guix install: environment variable message is very confusing
@ 2019-05-28 12:08 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-28 12:08 UTC (permalink / raw)
To: 35942
[-- Attachment #1: Type: text/plain, Size: 293 bytes --]
Robert,
Robert Vollmert wrote:
> Suggestion to instead print:
>
> Set the following environment variables to use <package> right
> away:
Thanks for the bug report! Related (not duplicate) thread:
<https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00362.html>
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#35995: Installer: GUIX_IMAGE as /dev/sda on some hardware?
[not found] ` <874l5amhc8.fsf@gnu.org>
@ 2019-05-31 22:16 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-05-31 22:16 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 35995, guix-devel
[-- Attachment #1: Type: text/plain, Size: 669 bytes --]
Ludovic Courtès wrote:
> Danny Milosavljevic <dannym@scratchpost.org> skribis:
>> Grub already can search by uuid or label (via "search --fsuuid"
>> and
>> "search --label", respectively). IF you specify an uuid or
>> label
>> in your operating-system configuration it will use that.
>
> These are concerned with file system UUIDs/labels, whereas this
> issue is
> about disk IDs, AIUI. Or am I missing something?
This. Also, this only affects grub-install—not ‘grub
run-time’—which runs under the Hurd/Linux/…, unless I, too, am
missing something, and this entire thread collapses in a cacophony
of confusion.
G'night,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36135: [PATCH 3/2] installer: Hide the Wi-Fi passphrase by default.
@ 2019-06-08 15:43 99% ` Tobias Geerinckx-Rice
1 sibling, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-06-08 15:43 UTC (permalink / raw)
To: 36132; +Cc: 36135
* gnu/installer/newt/wifi.scm (run-wifi-password-page):
Add an #:INPUT-SHOW-CHECKBOX? to the input page.
---
Guix,
This adds a ‘[ ] Show’ checkbox to the newt installer's Wi-Fi passphrase input field, which has also been requested at least twice now. Most recently here[0].
Kind regards,
T G-R
[0]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36135
gnu/installer/newt/wifi.scm | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gnu/installer/newt/wifi.scm b/gnu/installer/newt/wifi.scm
index 1cb2ef2df3..040e013293 100644
--- a/gnu/installer/newt/wifi.scm
+++ b/gnu/installer/newt/wifi.scm
@@ -1,6 +1,7 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2018 Mathieu Othacehe <m.othacehe@gmail.com>
;;; Copyright © 2019 Meiyo Peng <meiyo@riseup.net>
+;;; Copyright © 2019 Tobias Geerinckx-Rice <me@tobias.gr>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -88,7 +89,8 @@ nmc_wifi_strength_bars."
(define (run-wifi-password-page)
"Run a page prompting user for a password and return it."
(run-input-page (G_ "Please enter the wifi password.")
- (G_ "Password required")))
+ (G_ "Password required")
+ #:input-show-checkbox? #t))
(define (run-wrong-password-page service-name)
"Run a page to inform user of a wrong password input."
--
2.21.0
^ permalink raw reply related [relevance 99%]
* bug#36135: installer wifi password prompt
@ 2019-06-08 20:11 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2019-06-08 20:11 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 36135
[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]
Ludo',
Ludovic Courtès wrote:
> Tobias Geerinckx-Rice <me@tobias.gr> skribis:
>
>> * gnu/installer/newt/wifi.scm (run-wifi-password-page):
>> Add an #:INPUT-SHOW-CHECKBOX? to the input page.
>
> [...]
>
>> + #:input-show-checkbox? #t))
>
> It’s called #:input-hide-checkbox? AFAICS.
Yes. See the other patches in this ad-hoc ‘series’.
> You can double-check that it builds without warnings with:
>
> guix system vm -v2 gnu/system/install.scm
Sure, I guess, but could you explain the point of doing so?
Reproducibility by others? I don't think patches like these
should be pushed with such light testing, and I don't see how this
can be tested in a VM.
Hence the dusty Dell Latitude mentioned earlier ;-)
It smells funny.
> Please add a “Partly fixes …” line. This fixes both the
> password length
> and the password visibility issues since ‘run-input-page’ will
> now use
> FLAG-SCROLL.
Yah, I didn't merge the bugs for that reason, and because I'm
still trying to fix more bugs (well, mainly waiting for dd while
doing other stuff, since this can't be tested in a VM…)
Thanks!
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36135: installer wifi password prompt
@ 2019-06-10 22:36 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-06-10 22:36 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: 36135
[-- Attachment #1: Type: text/plain, Size: 487 bytes --]
Hah,
Ludovic Courtès wrote:
> No argument here! The patch referred to a keyword argument that
> does
> not exist, which is why I’m indeed suggesting more testing.
> Simply
> looking at the compiler warnings would have raised a flag.
There were no warnings and the code itself runs fine (believe me,
I've run it way too often already -_-') because this was written
on top of #36132.
I guess I was optimistic about its speedy acceptance.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36254: Acknowledgement (Youtube-Viewer)
@ 2019-06-17 1:14 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-06-17 1:14 UTC (permalink / raw)
To: Raghav Gururajan; +Cc: 36254
[-- Attachment #1: Type: text/plain, Size: 802 bytes --]
Raghav,
Raghav Gururajan wrote:
> it appears "youtube-viewer" (both GUI and CUI) opens video
> without
> "youtube-dl" ONLY IF the video format is of lower quality.
> So most videos like songs from VEVO channels does not open and
> require
> "youtube-dl" as a dependency.
Test videos about GNU Guix, on the other hand, opened fine.
...
> SUGGESTION: Bundling "youtube-dl" with "youtube-viewer" as a
> dependency.
We only unbundle software in Guix, but I've added youtube-dl as
an input and patched youtube-viewer to use it in
58637415bedb8a91d916ab6ed6f318f7b7023c00.
I can now successfully play ‘Dmitri Shostakovich - Waltz No. 2
(by TheWickedNorth)’ which failed to play before.
Could you confirm whether this solves your problem?
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36262: cannot install bootloader to root partition
@ 2019-06-17 17:08 99% ` Tobias Geerinckx-Rice
2 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2019-06-17 17:08 UTC (permalink / raw)
To: znavko; +Cc: 36262
[-- Attachment #1: Type: text/plain, Size: 560 bytes --]
Znavko,
znavko@disroot.org wrote:
> bug#36262: cannot install bootloader to root partition
Installing GRUB to your root partition isn't supported, and should
never be necessary anyway.
> Hello! I was not able to install Guix having 2 partitions:
> /dev/sda1 ext4 Linux filesystem
> /dev/sda2 Linux Swap
This is a strange partition layout; it's missing a ‘BIOS boot
partition’ and can never work without forcing GRUB to do something
it doesn't like to do.
Did you create this layout manually? If so, why?
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36262: cannot install bootloader to root partition
@ 2019-06-17 17:09 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-06-17 17:09 UTC (permalink / raw)
To: Danny Milosavljevic; +Cc: 36262
[-- Attachment #1: Type: text/plain, Size: 217 bytes --]
Danny,
Danny Milosavljevic wrote:
> which grub is that? grub-efi?
i386-pc, so ‘BIOS’ (which means it's trying to use blocklists,
which is fragile & won't work without --force).
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36262: cannot install bootloader to root partition
@ 2019-06-18 2:33 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-06-18 2:33 UTC (permalink / raw)
To: znavko; +Cc: 36262
[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]
Znavko,
znavko@disroot.org wrote:
> I have another laptop (Lenovo G50-30) where Guix works on this
> partition layout I've made manually:
>
> # fdisk -l /dev/sda
> ...
^ You removed the most important part, please don't do this on
help lists.
Still, we can tell that this is an ‘mbr’ layout:
> Device Boot Start End Sectors Size Id Type
> /dev/sda1 2048 230000000 229997953 109.7G 83 Linux
> /dev/sda2 230000640 234441647 4441008 2.1G 82 Linux
> swap / Solaris
^^^^^^^^^^^^^^^^^^^^^^^
> But all the new installations on other two notebooks with the
> same layout do not work.
They aren't the same: the one in your screenshot is a completely
different ‘gpt’ layout.
Hence my unanswered question:
> Did you create this layout manually? If so, why?
Although now I suspect there was no reason and that the installer
isn't to blame.
So you can either:
- throw away your existing layout and create new MBR disklabel.
Your partitioning software will ask you or provide an option
somewhere. Since modern partitioning software leaves a huge gap
before the first partition, GRUB will nestle cosily into that
first unused ~MiB.
- keep it as GPT (it has some minor features MBR doesn't), and
create an additional GPT ‘BIOS boot partition’ as recommended
before. It only needs to be a few 100 KiB, so I use the space
before the first partition (= before the first megabyte; turning
off ‘alignment’ in your partitioning software). This tiny
partition is for use by GRUB, and GRUB alone: do not format or
mount it.
Both options work equally well, but you need to choose.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36262: cannot install bootloader to root partition
@ 2019-06-18 2:59 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-06-18 2:59 UTC (permalink / raw)
To: Mark H Weaver; +Cc: 36262
[-- Attachment #1: Type: text/plain, Size: 163 bytes --]
Mark H Weaver wrote:
> FWIW, I used this partition layout for years, including on Guix
> systems,
> and it worked fine.
Impossible, sorry.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36333: Misleading hint for url-fetch
@ 2019-06-22 20:23 99% Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-06-22 20:23 UTC (permalink / raw)
To: 36333
[-- Attachment #1: Type: text/plain, Size: 420 bytes --]
Guix,
I just encountered the following:
foo.scm:4:2: error: url-fetch: unbound variable
hint: Did you forget `(use-modules (guix build download))'?
Actually importing that module, instead of (guix download), will
cause some other very hard-to-debug error that I can't remember
but coincidentally helped someone fix on #guix the other day.
Now I understand how they got to that bad place.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36363: let's encrypt hash mismatch
@ 2019-06-24 18:44 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-06-24 18:44 UTC (permalink / raw)
To: julien lepiller; +Cc: 36363
[-- Attachment #1: Type: text/plain, Size: 836 bytes --]
Julien,
Julien Lepiller wrote:
> trying to run guix pull on the overdrive at my place to try and
> fix a
> bug in openssh which doesn't start at boot, I get this error
> message:
[…]
> letsencryptauthorityx3.pem 2KiB 385KiB/s 00:00
> [##################] 100.0% sha256 hash mismatch
> for /gnu/store/1drx7dy1zakc0xs60nb0im1jbvxp11dj-isrgrootx1.pem:
> expected hash:
> 0zhd1ps7sz4w1x52xk3v7ng6d0rcyi7y7rcrplwkmilnq5hzjv1y
> actual hash:
> 0zycy85ff9ga53z1q03df89ka9iihb9p8bjhw056rq2y4rn3b6ac
This will keep happening until we find(/create) a versioned URL
for these files. Let's Encrypt like to change them in place.
The last time this happened they'd added CR/LF line endings for no
reason at all, but this time I don't have the old version around
anymore…
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36371: guix build --with-git-reference=…
@ 2019-06-25 9:24 99% Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-06-25 9:24 UTC (permalink / raw)
To: 36371
[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]
Guix,
bricewge on #guix informed me that there's no way to pass a git
tag as source transformation option. Indeed:
‘--with-commit=PACKAGE=COMMIT’
This is similar to ‘--with-branch’, except that it builds
from
COMMIT rather than the tip of a branch. COMMIT must be a
valid Git
commit SHA1 identifier.
is quite different from (guix git-download)'s pleasantly liberal
notion of commit:
(git reference
(url "git://foo.org/fizbo")
(commit "fizbo-4.5")) ; tag yay
bricewge suggested that a single ‘--with-git-ref[erence]=’ could
replace both ‘--with-branch’ and a new ‘--with-tag’, and I agree.
(Although I prefer the full spelling, of course :-)
Two questions:
- Is this really not supported yet, or am I missing the obvious?
- Why is the (extremely) git-specific ‘--with-commit=’ option not
called ‘--with-git-commit=’? Was it intended to be more generic
than it is now? Should the new option be ‘--with-reference=’ as
well? That's pushing it a little far. And three questions in
one; I'm cheating.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36394: guix.gnu.org/packages lists incorrect sqlite versions
@ 2019-06-26 18:14 99% Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-06-26 18:14 UTC (permalink / raw)
To: 36394
[-- Attachment #1: Type: text/plain, Size: 698 bytes --]
Guix,
The package list at <https://guix.gnu.org/packages/S/page/4/>
displays the wrong versions for sqlite:
sqlite 3.26.0
sqlite 3.26.0
sqlite-with-column-metadata 3.26.0
Which should be:
$ guix pull && guix package -A ^sqlite
sqlite 3.26.0 …
sqlite 3.24.0 …
sqlite-with-column-metadata 3.24.0 …
At first glance it looks like the Web list iterates over package
names instead of package records, then looks up the ‘default’
package for each name … but packages like ‘gcc-objc’[0] are
listed correctly, so maybe that's not what's happening.
Noticed by sebboh on #guix.
Kind regards,
T G-R
[0]: https://guix.gnu.org/packages/G/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36257: Youtube-Dl-GUI
@ 2019-07-02 21:17 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-07-02 21:17 UTC (permalink / raw)
To: 36257
[-- Attachment #1: Type: text/plain, Size: 407 bytes --]
Raghav,
Raghav Gururajan wrote:
> SUGESSTION: May be missing ".desktop" file?
Unfortunately it's missing from the project, not just our package.
I've hacked something together roughly based on [0] (thanks!) and
my own readings, and pushed that. This only addresses that part
of this bug.
Kind regards,
T G-R
[0]:
https://git.parabola.nu/abslibre.git/tree/pcr/youtube-dl-gui/youtube-dl-gui.desktop
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36574: The installer recommends wrong initrd module names
@ 2019-07-10 11:15 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-07-10 11:15 UTC (permalink / raw)
To: 36574
[-- Attachment #1: Type: text/plain, Size: 277 bytes --]
Hullo,
Meiyo Peng wrote:
> So the problem is that the Guix installer recommends wrong
> initrd module
> names to user.
Do you think this is the revenge of [0]? If so, could you merge
the two?
Kind regards,
T G-R
[0]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34902
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36584: [Mumi] issues.guix.gnu.org doesn't mention bug-guix@
@ 2019-07-10 21:56 99% Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-07-10 21:56 UTC (permalink / raw)
To: 36584
[-- Attachment #1: Type: text/plain, Size: 240 bytes --]
Guix, Ricardo,
What the subject says. Actually, the whole welcome message is a
bit outdated (though I hadn't noticed either): it doesn't jive
with the common understanding of ‘issue’ in the subdomain.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36614: rust@1.36's hash is incorrect.
@ 2019-07-12 13:16 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2019-07-12 13:16 UTC (permalink / raw)
To: 36614-done; +Cc: Ivan Petkov
[-- Attachment #1: Type: text/plain, Size: 963 bytes --]
Pierre, Ivan,
Pierre Langlois wrote:
> From
> https://static.rust-lang.org/dist/rustc-1.36.0-src.tar.gz...
> downloading from
> https://static.rust-lang.org/dist/rustc-1.36.0-src.tar.gz...
> rustc-1.36.0-src.tar.gz 147.5MiB
> 1.6MiB/s 01:35 [##################] 100.0%
> sha256 hash mismatch for
> /gnu/store/jm9xvf6qy4zxkb7rkmpz8ygf55l8v8v5-rustc-1.36.0-src.tar.gz:
> expected hash:
> 18r688ih4xi9m8gv55g1amb8inrwkdxp5fbcqb6i4gqxi90l3i0m
> actual hash:
> 06xv2p6zq03lidr0yaf029ii8wnjjqa894nkmrm6s0rx47by9i04
I get that too.
> Hopefully it's not unstable :-/.
Since release archives are signed that would imply some horrible
things about their key management, so I doubt it very much. I
guess we'll find out.
I've gone ahead and pushed a fix since the signature checked out.
I'm closing this bug for now...
However, I'd be interested to know what the previous hash
described. Do you still have that file around, Ivan?
Thanks,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36614: rust@1.36's hash is incorrect.
@ 2019-07-12 17:26 99% ` Tobias Geerinckx-Rice
2019-07-12 17:27 87% ` Tobias Geerinckx-Rice
1 sibling, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-07-12 17:26 UTC (permalink / raw)
To: Ivan Petkov; +Cc: 36614-done
[-- Attachment #1: Type: text/plain, Size: 2384 bytes --]
Ivan,
Ivan Petkov wrote:
> My apologies, this was all partly my fault. I do have the old
> source lying
> around, diffing the two (attached) reveals that the changelog
> and one source
> file actually changed.
>
> A bit more detailed context:
> The rust project makes pre-release sources available for testing
> ahead of
> the formal release, and the process is meant to shake out any
> potential bugs.
> I tested with the prerelease build originally, and after the
> real release
> came out I updated the package URL to the formal release and
> immediately
> rebuilt successfully.
No apologies necessary. It's nice to know that our Rust updates
will always follow swiftly on the heels of upstream as long as you
take care of them. However, please make sure to check the
signature (.asc) once the final release is cut; one never knows...
> I'm not 100% sure if maybe guix reused the cached tarball I had
> from earlier,
> or whether the prerelease source was immediately upgraded to the
> formal release
> and fixed shortly after. (I did try rebuilding right before
> pushing the change
> out which succeeded with no changes, which I'm guessing is
> because guix did
> not redownload the tarball and why I didn't notice the hash
> mismatch).
Yes, this is exactly what happened. I consider this is a feature
of Guix, even though it can feel like a gotcha sometimes. :-)
We often tend to think of the source URL(s) as an ‘identifier’ of
the source file. However, it is nothing more than a hint about
its *location*. The only authoritative identifier of its
*content* is the hash: to get *this file* (content hash), try
looking *here* (location: URL).
One origin may have 0 or more source URLs: Guix will try them all
until it downloads something matching the hash (and if even that
fails it will try some implicit ones like tarballs.nixos.org).
‘Unique’ identifier (hash)
├ maybe you can *find* it here (URL)
├ or here (another URL)
├ hell maybe here I don't know (yet another URL)
⋮
Guix cares only about the content of the file; it doesn't care or
even remember how it got it. Or: if you change the download hint
(release URL in this case), Guix won't care, because you didn't
change the hash.
I hope that makes some sense,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36614: rust@1.36's hash is incorrect.
2019-07-12 17:26 99% ` Tobias Geerinckx-Rice
@ 2019-07-12 17:27 87% ` Tobias Geerinckx-Rice
2019-07-12 17:34 99% ` Tobias Geerinckx-Rice
1 sibling, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2019-07-12 17:27 UTC (permalink / raw)
To: Ivan Petkov; +Cc: 36614
[-- Attachment #1: Type: text/plain, Size: 5155 bytes --]
Ivan,
On Jul 12, 2019, at 6:16 AM, Tobias Geerinckx-Rice <me@tobias.gr>
wrote:
> I've gone ahead and pushed a fix since the signature checked
> out. I'm closing this bug for now...
Unfortunately, the build still fails for me. See below.
Kind regards,
T G-R
--8<---------------cut here---------------start------------->8---
|
||________________________________________________________________________-
in this macro invocation (#5)
4 | | types {
... |
7 | / | impl_error_chain_processed ! {
8 | | | types { $ error_name , $ error_kind_name , $
result_ext_name ; } $ ( $ rest )
9 | | | * } /// Convenient wrapper around `std::Result`.
| |_|________- in this macro invocation (#6)
... |
91 | | ( ref foreign_err ) => { foreign_err . cause ( ) }
) * _ => None } } } } }
| | ^^^^^
... |
154 | | move || { $ crate :: ChainedError :: from_kind (
callback ( ) . into ( ) ) }
155 | | ) } } } ;
| | -
| | |
| | in this expansion of
`impl_error_chain_processed!` (#4)
| |______________in this expansion of
`impl_error_chain_processed!` (#5)
| in this expansion of
`impl_error_chain_processed!` (#6)
|
::: <::error_chain::error_chain::error_chain macros>:1:1
|
1 | / ( $ ( $ block_name : ident { $ ( $ block_content :
tt ) * } ) * ) => {
2 | | error_chain_processing ! {
| ______|_-
3 | | | ( { } , { } , { } , { } ) $ ( $ block_name { $
( $ block_content ) * } ) *
4 | | | } } ;
| | |_-___- in this expansion of `error_chain!` (#1)
| |________|
| in this macro invocation (#2)
|
::: src/tools/rust-installer/src/lib.rs:21:5
|
21 | / error_chain!{
22 | | foreign_links {
23 | | Io(::std::io::Error);
24 | |
StripPrefix(::std::path::StripPrefixError);
25 | | WalkDir(::walkdir::Error);
26 | | }
27 | | }
| |____________- in this macro invocation (#1)
Finished release [optimized] target(s) in 1m 36s
Error: failed to generate installer
Caused by: failed to copy
'/tmp/guix-build-rust-1.36.0.drv-0/rustc-1.36.0-src/build/tmp/dist/rust-docs-1.36.0-x86_64-unknown-linux-gnu-image/share/doc/rust/html/unstable-book/library-features/weak-counts.html'
to
'/tmp/guix-build-rust-1.36.0.drv-0/rustc-1.36.0-src/build/tmp/dist/rust-docs-1.36.0-x86_64-unknown-linux-gnu/rust-docs/share/doc/rust/html/unstable-book/library-features/weak-counts.html'
Caused by: No space left on device (os error 28)
command did not execute successfully:
"/tmp/guix-build-rust-1.36.0.drv-0/rustc-1.36.0-src/build/x86_64-unknown-linux-gnu/stage0-tools-bin/fabricate"
"generate" "--product-name=Rust-Documentation"
"--rel-manifest-dir=rustlib"
"--success-message=Rust-documentation-is-installed." "--image-dir"
"/tmp/guix-build-rust-1.36.0.drv-0/rustc-1.36.0-src/build/tmp/dist/rust-docs-1.36.0-x86_64-unknown-linux-gnu-image"
"--work-dir"
"/tmp/guix-build-rust-1.36.0.drv-0/rustc-1.36.0-src/build/tmp/dist"
"--output-dir"
"/tmp/guix-build-rust-1.36.0.drv-0/rustc-1.36.0-src/build/dist"
"--package-name=rust-docs-1.36.0-x86_64-unknown-linux-gnu"
"--component-name=rust-docs"
"--legacy-manifest-dirs=rustlib,cargo"
"--bulk-dirs=share/doc/rust/html"
expected success, got: exit code: 1
failed to run:
/tmp/guix-build-rust-1.36.0.drv-0/rustc-1.36.0-src/build/bootstrap/debug/bootstrap
install
Build completed unsuccessfully in 0:01:54
Backtrace:
5 (primitive-load
"/gnu/store/n6nh9mqsd8grd10f532z8nswnlj…")
In ice-9/eval.scm:
191:35 4 (_ _)
In srfi/srfi-1.scm:
863:16 3 (every1 #<procedure a6c980 at
/gnu/store/cmlwy3sxnq9yf…> …)
In
/gnu/store/cmlwy3sxnq9yfp75w80par5imvyg143f-module-import/guix/build/gnu-build-system.scm:
799:28 2 (_ _)
In ice-9/eval.scm:
619:8 1 (_ #(#(#<directory (guile-user) 5ce140>) (("o…" . #)
…)))
In
/gnu/store/cmlwy3sxnq9yfp75w80par5imvyg143f-module-import/guix/build/utils.scm:
616:6 0 (invoke _ . _)
/gnu/store/cmlwy3sxnq9yfp75w80par5imvyg143f-module-import/guix/build/utils.scm:616:6:
In procedure invoke:
Throw to key `srfi-34' with args `(#<condition &invoke-error
[program: "./x.py" arguments: ("install") exit-status: 1
term-signal: #f stop-signal: #f] 9f04c0>)'.
note: build failure may have been caused by lack of free disk
space
builder for
`/gnu/store/cknk6wa34h04vqb7qwdlzx36xx2j4n54-rust-1.36.0.drv'
failed with exit code 1
build of
/gnu/store/cknk6wa34h04vqb7qwdlzx36xx2j4n54-rust-1.36.0.drv failed
View build log at
'/var/log/guix/drvs/ck/nk6wa34h04vqb7qwdlzx36xx2j4n54-rust-1.36.0.drv.bz2'.
guix build: error: build of
`/gnu/store/cknk6wa34h04vqb7qwdlzx36xx2j4n54-rust-1.36.0.drv'
failed
~/guix ⑂nckx-master✱ λ
--8<---------------cut here---------------end--------------->8---
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 87%]
* bug#36614: rust@1.36's hash is incorrect.
2019-07-12 17:27 87% ` Tobias Geerinckx-Rice
@ 2019-07-12 17:34 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-07-12 17:34 UTC (permalink / raw)
To: Ivan Petkov; +Cc: 36614
[-- Attachment #1: Type: text/plain, Size: 196 bytes --]
Tobias Geerinckx-Rice wrote:
> Caused by: No space left on device (os error 28)
Eh, never mind, I managed to copy, paste, & send an entire e-mail
while missing this line.
👍,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36743: Claws-Mail Issues
@ 2019-07-20 17:10 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-07-20 17:10 UTC (permalink / raw)
To: 36743
[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]
Raghav,
Raghav Gururajan 写道：
> Hello Guix!
>
> I tried to use claws-mail in guix. There are two following
> issues:
>
> 1) Error "Encryption System not found"
> 2) Error "Dictionary System not found"
>
> To reproduce these errors, one can install claws-mail, enable
> spell-
> checking + digital signing/encryption of all emails; and attempt
> to
> compose an email. The error will pop-up.
Have you tried installing the packages that provide these
functions into your profile? You'll have to figure out what they
are, but I'm guessing ‘Encryption System’ is gnupg. ;-)
This is really a bug in Claws (‘unhelpful error messages’), not
Guix.
Just adding gnupg to the claws-mail closure (an exta 26.5 MiB or
4%) does not appeal to me personally, especially since the same
message for dictionaries would remain anyway (they are optional by
definition). I think improving the error messages is a better
approach.
It's not our habit to do so, but perhaps we could patch them to
explicitly say ‘please install the "gnupg" package’ if upstream
is unresponsive.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36634: ATTENTION REQUIRED
@ 2019-07-25 19:36 99% ` Tobias Geerinckx-Rice
2019-07-25 20:01 99% ` Tobias Geerinckx-Rice
0 siblings, 1 reply; 143+ results
From: Tobias Geerinckx-Rice @ 2019-07-25 19:36 UTC (permalink / raw)
To: Raghav Gururajan; +Cc: 36634
Raghav,
On Thu, Jul 25, 2019 at 11:46 AM, Raghav Gururajan
<raghavgururajan@disroot.org> wrote:
> Hello Guix!
>
> I posted the bug on libvirt mail list few days ago
> (https://www.redhat.
> com/archives/libvir-list/2019-July/msg01309.html). It appears the bug
> has now been fixed
> (https://github.com/libvirt/libvirt/commit/759bf903a
> 6c24a8efa25c7cf4b099d952eda9bd3).
>
> Could anyone please update the libvirt package/service to this latest
> build?
I will do so swiftly since I updated libvirt to the 'broken' version
(although I never had any troubles like yours). Thank you for
reporting this upstream.
A personal note: I find this new wave of 'ATTENTION REQUIRED' messages
quite the opposite of motivating and pleasant. I'm honestly not sure
what result you expect from them. I fear it may backfire.
You are very welcome to contribute patches yourself! I don't mean
'patches or GTFO', I mean 'please dive in, the water's great'. The
reviewers don't bite. You don't need to be a programmmer; I'm not.
You've been part of our discussions for a while, you obviously care
about Guix and Free software, and particularly about certain Gnome and
'desktop-demographic' packages that are clearly under-maintained or
even missing because we're missing people like you. Learning to create
and maintain them yourself is hardly more work than trying to herd
volunteers like this -- and a hell of a lot more fun.
Kind regards,
T G-R
^ permalink raw reply [relevance 99%]
* bug#36634: ATTENTION REQUIRED
2019-07-25 19:36 99% ` Tobias Geerinckx-Rice
@ 2019-07-25 20:01 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-07-25 20:01 UTC (permalink / raw)
To: Raghav Gururajan; +Cc: 36634-done
[-- Attachment #1: Type: text/plain, Size: 517 bytes --]
Tobias Geerinckx-Rice 写道：
>> Could anyone please update the libvirt package/service to this
>> latest
>> build?
>
> I will do so swiftly since I updated libvirt to the 'broken'
> version
> (although I never had any troubles like yours). Thank you for
> reporting this upstream.
I have applied ‘your’ patch in
41097b2dee9367974c6dd16ac1ba2ee945457237.
I'm closing this bug for now. However, could you update and
confirm that this actually solves the problem?
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36862: Root-owned /var/cache/fontconfig sometimes exists, shouldn't.
@ 2019-07-30 22:37 99% Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-07-30 22:37 UTC (permalink / raw)
To: 36862
[-- Attachment #1: Type: text/plain, Size: 364 bytes --]
Guix,
Just leaving this here so I don't forget.
Sometimes fonts break, and after a few frustrating, impotent runs
of ‘fc-cache -rv’ you notice:
/var/cache/fontconfig: not cleaning unwritable cache directory
Deleting this stale (root-owned) directory makes fonts fun again.
Happens about once or twice a month here.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36900: key-mon crashes on launch
@ 2019-08-02 23:21 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-08-02 23:21 UTC (permalink / raw)
To: 36900
[-- Attachment #1: Type: text/plain, Size: 216 bytes --]
Jesse,
Jesse Gibbons 写道：
> I will see if updating python2-xlib fixes this, and if so I will
> send a
> patch.
>
> Any objections?
On the contrary. That's exactly what we want!
Thanks,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#36896: [PATCH] added gsettings-desktop-schema to progragated inputs
@ 2019-08-05 20:30 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-08-05 20:30 UTC (permalink / raw)
To: 36896, Martin Becze, Ricardo Wurmus
[-- Attachment #1: Type: text/plain, Size: 515 bytes --]
Martin, Ricardo,
I agree with Ricardo (here and in matters of fonts) that
propagation is to be avoided at all reasonable costs, so…
Martin Becze 写道：
> The terminator packagage propagates gsetting-desktop-schema as
> well
> but maybe its also doing the wrong thing?
…that was a mistake, in retrospect, fixed in
96681d4be101c771fafd4257aca471685119fedd.
You can probably apply that same fix directly to Evolution. There
should be no need to propagate anything.
Thanks!
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [relevance 99%]
* bug#37905: (no subject)
@ 2019-10-24 16:36 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2019-10-24 16:36 UTC (permalink / raw)
To: 37905-done
[-- Attachment #1: Type: text/plain, Size: 95 bytes --]
…and adjusted in commit 70a4fb6f983f05b5630cf8c7d85c3143b6d5523b.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [relevance 99%]
* bug#40613: (no subject)
@ 2020-04-14 0:55 99% ` Tobias Geerinckx-Rice
0 siblings, 0 replies; 143+ results
From: Tobias Geerinckx-Rice @ 2020-04-14 0:55 UTC (permalink / raw)
To: 40591, 40593, 40616, 40613
[-- Attachment #1: Type: text/plain, Size: 247 bytes --]
For the record (and any reviewers), these patches should be
applied in order:
#40591 emacs-org-roam
#40593 emacs-uml-mode
#40616 emacs-4clojure
#40613 emacs-typing
They're not interdependent, just patch-context-dependent.
Kind regards,
T G-R
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [relevance 99%]
Results 1-143 of 143 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2016-12-15 15:32 bug#25205: Guix package is using the GuixSD logo instead of the Guix logo Luis Felipe López Acevedo
2016-12-22 7:49 99% ` bug#25205: Guix Wikipedia page logo updated Tobias Geerinckx-Rice
2016-12-26 2:46 bug#25273: [ng0@libertad.pw: 'mc' package needs some fixes] Leo Famulari
2016-12-26 12:49 ` ng0
2016-12-26 13:07 ` ng0
2016-12-26 14:09 99% ` Tobias Geerinckx-Rice
2017-03-21 1:44 bug#26201: No notification of cache misses when downloading substitutes dian_cecht
2017-03-21 2:46 99% ` Tobias Geerinckx-Rice
2017-03-21 2:52 ` dian_cecht
2017-03-21 3:57 99% ` Tobias Geerinckx-Rice
2017-03-21 4:48 ` dian_cecht
2017-03-21 6:21 99% ` Tobias Geerinckx-Rice
2017-03-21 6:49 ` dian_cecht
2017-03-21 14:55 87% ` Tobias Geerinckx-Rice
2017-03-21 15:32 ` dian_cecht
2017-03-21 16:07 99% ` Tobias Geerinckx-Rice
2017-03-21 16:43 ` Ludovic Courtès
2017-03-21 17:08 99% ` Tobias Geerinckx-Rice
2017-03-22 22:06 ` Ludovic Courtès
2017-03-23 19:25 99% ` bug#26201: hydra.gnu.org uses ‘guix publish’ for nars and narinfos Tobias Geerinckx-Rice
2017-03-22 22:22 ` Ludovic Courtès
2017-03-23 18:36 ` Mark H Weaver
2017-03-23 18:52 99% ` Tobias Geerinckx-Rice
2017-03-24 8:12 ` Mark H Weaver
2017-03-26 17:35 99% ` Tobias Geerinckx-Rice
2017-03-27 18:47 99% ` Tobias Geerinckx-Rice
2017-05-03 18:59 bug#26764: Problem building master Maxim Cournoyer
2017-05-03 19:06 99% ` Tobias Geerinckx-Rice
2017-06-15 10:01 99% bug#27373: Update Knot DNS to 2.5.1 Tobias Geerinckx-Rice
2017-07-17 14:40 94% bug#27735: Unbootable images with GuixSD on... "GuixSD" Tobias Geerinckx-Rice
2017-07-17 14:51 95% ` bug#27735: [PATCH 1/2] build, vm: Use a slightly less generic label Tobias Geerinckx-Rice
2017-07-17 17:20 ` Danny Milosavljevic
2017-07-17 17:58 99% ` Tobias Geerinckx-Rice
2017-07-18 10:09 ` Ludovic Courtès
2017-07-18 12:30 99% ` Tobias Geerinckx-Rice
2017-07-17 17:17 ` bug#27735: Unbootable images with GuixSD on... "GuixSD" Danny Milosavljevic
2017-07-17 18:12 99% ` Tobias Geerinckx-Rice
2017-07-17 18:37 99% ` Tobias Geerinckx-Rice
2017-07-18 11:49 ` Ludovic Courtès
2017-07-18 15:09 99% ` Tobias Geerinckx-Rice
2017-07-18 18:59 ` Ludovic Courtès
2017-07-18 20:42 99% ` Tobias Geerinckx-Rice
2017-12-06 19:35 93% bug#29593: [web site] Broken links in the HTML manual Tobias Geerinckx-Rice
2017-12-07 21:11 ` Ludovic Courtès
2017-12-07 22:52 99% ` Tobias Geerinckx-Rice
2017-12-12 10:28 bug#29674: Ceph creates Btrfs subvolumes on Btrfs during tests Rutger Helling
2017-12-12 12:52 ` Ludovic Courtès
2017-12-12 13:10 ` Rutger Helling
2017-12-12 13:23 ` Rutger Helling
2017-12-12 16:03 ` Ludovic Courtès
2017-12-12 16:13 99% ` Tobias Geerinckx-Rice
2017-12-12 20:19 ` Ludovic Courtès
2017-12-27 22:50 ` Rutger Helling
2017-12-27 23:16 99% ` Tobias Geerinckx-Rice
2017-12-28 4:30 99% ` Tobias Geerinckx-Rice
2018-01-06 13:29 bug#30006: bzip2 does not provide libbz2.so Ludovic Courtès
2018-03-23 12:02 ` Marius Bakke
2018-03-23 12:19 99% ` Tobias Geerinckx-Rice
2018-03-23 20:50 ` Mark H Weaver
2018-03-24 1:17 99% ` Tobias Geerinckx-Rice
2018-01-14 16:02 bug#30113: SVN checkouts without descriptive file names Leo Famulari
2018-01-14 16:13 ` Gábor Boskovits
2018-01-14 16:43 99% ` Tobias Geerinckx-Rice
2018-01-14 16:53 ` Danny Milosavljevic
2018-01-14 17:43 ` Gábor Boskovits
2018-01-14 19:28 ` Gábor Boskovits
2018-01-14 19:34 99% ` Tobias Geerinckx-Rice
2018-03-12 21:24 99% bug#30785: Man pages truncated, repeated Tobias Geerinckx-Rice
2018-03-13 21:34 ` Ludovic Courtès
2018-03-13 22:01 99% ` Tobias Geerinckx-Rice
2018-03-20 23:10 bug#30890: Hash mismatch for /gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids Vivien Kraus
2018-03-21 0:19 ` Danny Milosavljevic
2018-03-21 6:54 ` Vivien Kraus
2018-03-21 17:24 99% ` Tobias Geerinckx-Rice
2018-03-21 11:05 ` Vivien Kraus
2018-03-21 15:46 99% ` Tobias Geerinckx-Rice
2018-03-21 16:08 99% ` Tobias Geerinckx-Rice
2018-03-21 17:01 ` Vivien Kraus
2018-03-21 17:05 99% ` Tobias Geerinckx-Rice
2018-04-30 17:56 bug#31321: perl-test-www-mechanize: Duplicate 'native-inputs' field Mark H Weaver
[not found] ` <Mark H. Weaver's message of "Mon, 30Apr 2018 13:56:25 -0400">
2018-05-07 20:02 ` Mark H Weaver
2018-05-07 22:00 99% ` Tobias Geerinckx-Rice
2018-05-30 3:49 99% bug#31652: Use of ‘keymap’ vs. ‘layout’ in manual Tobias Geerinckx-Rice
2018-07-05 10:24 bug#32058: mysql build fails on d88b29d6b78482cdb05ac714984f6a27195e3d37 Nils Gillmann
2018-07-05 11:31 86% ` Tobias Geerinckx-Rice
2018-08-15 23:15 97% ` bug#32058: [PATCH] gnu: mysql: Fix build Tobias Geerinckx-Rice
2018-08-16 15:30 ` Marius Bakke
2018-08-20 18:33 99% ` Tobias Geerinckx-Rice
2018-08-03 11:38 bug#32360: gst-plugins-base has test failures (when built as a dependency) Björn Höfling
2018-08-17 17:16 ` Leo Famulari
2018-08-17 18:05 ` Leo Famulari
2018-08-17 21:50 ` Björn Höfling
2018-08-18 10:46 ` Pjotr Prins
2018-08-18 11:34 99% ` Tobias Geerinckx-Rice
2018-08-16 17:59 bug#32459: Strace 4.24 doesn't build Clément Lassieur
2018-08-16 18:14 99% ` Tobias Geerinckx-Rice
2018-08-16 18:46 ` Clément Lassieur
2018-08-18 11:36 99% ` Tobias Geerinckx-Rice
2018-09-20 21:49 bug#32789: Bash finds old version of guix after guix pull Alex Branham
2018-09-21 8:05 99% ` Tobias Geerinckx-Rice
2018-09-26 10:33 bug#32845: guix.info: Missing manual Pierre Neidhardt
2018-09-26 18:01 ` Ricardo Wurmus
2018-09-26 19:44 ` Pierre Neidhardt
2018-09-26 20:10 ` Ricardo Wurmus
2018-09-27 13:46 ` Ludovic Courtès
2018-09-27 15:28 ` Ricardo Wurmus
2018-09-28 20:03 ` Ludovic Courtès
2018-09-28 20:39 99% ` Tobias Geerinckx-Rice
2018-09-27 18:23 bug#32855: sshuttle /usr/bin/env Nam Nguyen
2018-09-27 19:11 99% ` Tobias Geerinckx-Rice
2018-09-27 19:22 ` Nam Nguyen
2018-09-27 22:04 99% ` Tobias Geerinckx-Rice
2018-09-29 22:40 ` Nam Nguyen
2018-09-30 11:52 99% ` Tobias Geerinckx-Rice
2018-10-06 14:19 ` Marius Bakke
2018-10-06 14:49 99% ` Tobias Geerinckx-Rice
2018-10-28 18:40 Touchpad tap znavko
2018-10-28 20:02 ` Pierre Neidhardt
2018-10-28 23:49 ` Luther Thompson
2018-10-29 0:44 99% ` bug#33189: " Tobias Geerinckx-Rice
2018-11-02 1:35 99% bug#33234: Guix (weather): there can be only one Tobias Geerinckx-Rice
2018-11-07 10:19 bug#33300: hplip 3.18.9 contains non-free binary blobs Ludovic Courtès
2018-11-07 13:09 99% ` Tobias Geerinckx-Rice
2018-11-22 23:28 66% bug#33470: (Significantly) negative number of packages in profile Tobias Geerinckx-Rice
2018-11-23 6:30 99% ` bug#33470: Confusing spinner artefacts Tobias Geerinckx-Rice
2018-11-23 10:28 ` Gábor Boskovits
2018-11-23 14:00 99% ` Tobias Geerinckx-Rice
2018-12-06 14:56 bug#33647: First `guix pull' behaves unexpectedly Diego Nicola Barbato
2018-12-06 15:42 ` Ricardo Wurmus
2018-12-06 23:06 ` Ludovic Courtès
2018-12-07 8:36 ` Diego Nicola Barbato
2018-12-07 13:30 ` Ludovic Courtès
2018-12-19 12:49 ` Diego Nicola Barbato
2018-12-19 17:37 ` swedebugia
2018-12-19 19:27 99% ` Tobias Geerinckx-Rice
2018-12-11 8:24 bug#33703: youtube-dl man page is not complete swedebugia
2018-12-11 12:47 99% ` Tobias Geerinckx-Rice
2019-02-01 15:57 93% bug#34276: ‘guix system disk-image’ successfully builds a bad image Tobias Geerinckx-Rice
2019-02-19 5:58 bug#34568: flash-image.armhf-linux appears to succeed, when it actually failed Mark H Weaver
2019-02-19 6:30 99% ` Tobias Geerinckx-Rice
2019-02-24 23:41 bug#34642: clipit cannot be started by awesomewm or rofi Bradley Haggerty
2019-02-25 0:04 99% ` Tobias Geerinckx-Rice
2019-02-25 0:10 99% ` Tobias Geerinckx-Rice
2019-03-06 14:04 bug#34768: guix-daemon tmpfs out of space on parabola swedebugia
2019-03-06 14:31 99% ` Tobias Geerinckx-Rice
2019-03-09 20:10 bug#34797: ffmpeg: error while loading shared libraries: (...): file too short Alex Vong
2019-03-09 20:28 99% ` Tobias Geerinckx-Rice
2019-03-10 2:48 bug#34799: font breakage, square boxes Bradley Haggerty
2019-03-10 2:55 ` bug#34799: font breakage, square boxes, font-terminus Bradley Haggerty
2019-03-10 11:16 97% ` Tobias Geerinckx-Rice
2019-03-14 15:14 ` Bradley Haggerty
2019-03-14 21:34 99% ` Tobias Geerinckx-Rice
2019-03-10 16:41 bug#34806: `guix build inkscape` fails Marius Bakke
2019-03-10 18:25 99% ` Tobias Geerinckx-Rice
2019-03-10 18:53 ` Marius Bakke
2019-03-10 19:10 99% ` Tobias Geerinckx-Rice
2019-03-10 19:24 ` Marius Bakke
2019-03-10 20:26 99% ` Tobias Geerinckx-Rice
2019-03-13 22:30 bug#34850: ghc compiling error mikadoZero
2019-03-13 22:48 99% ` Tobias Geerinckx-Rice
2019-03-16 19:22 99% bug#34886: [Web page] Screenshot alignment (and listing?) Tobias Geerinckx-Rice
2019-03-17 15:33 ` Ludovic Courtès
2019-03-17 15:48 99% ` Tobias Geerinckx-Rice
2019-03-18 18:34 ` sirgazil
2019-03-28 12:48 99% ` Tobias Geerinckx-Rice
2019-03-26 21:18 bug#35010: Many CPAN download URLs are no longer available Mark H Weaver
2019-03-27 0:31 99% ` Tobias Geerinckx-Rice
2019-03-27 14:07 ` Ludovic Courtès
2019-03-27 18:40 99% ` Tobias Geerinckx-Rice
2019-03-30 12:47 bug#35047: "Running the Test Suite" root user mikadoZero
2019-03-30 13:50 99% ` Tobias Geerinckx-Rice
2019-03-30 14:02 bug#35048: Evolution Mail Client - Unable to add account Raghav Gururajan
2019-03-30 15:12 99% ` Tobias Geerinckx-Rice
[not found] <87h8b7nt2i.fsf@nckx>
2019-04-09 18:18 ` Error building linux-libre on Overdrive 1000 Andreas Enge
2019-04-09 19:37 99% ` bug#35210: " Tobias Geerinckx-Rice
2019-04-12 5:13 bug#35242: Backtrace on building with load path brettg
2019-04-12 12:40 99% ` Tobias Geerinckx-Rice
2019-04-14 8:52 bug#35268: guix system won't open config files in tmpfs rendaw
2019-04-14 21:22 99% ` Tobias Geerinckx-Rice
2019-04-17 2:07 99% bug#35301: Guix's Eolie pushes google.com as default search and home page Tobias Geerinckx-Rice
2019-04-22 16:10 99% bug#35382: I found a bug in guix pull \o/ (maybe) Tobias Geerinckx-Rice
2019-04-23 13:16 ` Ludovic Courtès
2019-04-23 13:37 99% ` Tobias Geerinckx-Rice
[not found] ` <handler.35382.B.155594948512132.ack@debbugs.gnu.org>
2019-04-23 13:34 99% ` Tobias Geerinckx-Rice
2019-04-23 14:29 bug#35395: GUIX website redirections are failing Boruch Baum
2019-04-23 15:40 99% ` Tobias Geerinckx-Rice
2019-04-24 16:23 OpenVPN Client Service Raghav Gururajan
2019-04-25 18:40 99% ` bug#35416: " Tobias Geerinckx-Rice
2019-04-24 16:34 Tor Service Raghav Gururajan
2019-04-24 18:53 99% ` bug#35417: " Tobias Geerinckx-Rice
2019-04-25 9:10 ` bug#35417: closed (Re: Tor Service) Raghav Gururajan
2019-04-25 18:31 99% ` Tobias Geerinckx-Rice
2019-04-25 3:42 Raghav Gururajan
2019-04-26 17:35 Transmission BitTorrent Client Raghav Gururajan
2019-04-26 21:59 99% ` Tobias Geerinckx-Rice
2019-05-03 22:57 bug#35551: package gcc does not depend on binutils and glibc Bruno Haible
2019-05-03 23:27 ` Nicolas Goaziou
2019-05-04 0:20 99% ` Tobias Geerinckx-Rice
2019-05-04 1:34 ` Bruno Haible
2019-05-07 16:23 99% ` Tobias Geerinckx-Rice
2019-05-10 21:15 ` bug#35551: guix search Ludovic Courtès
2019-05-10 22:04 ` Mark H Weaver
2019-05-10 22:38 ` Bruno Haible
2019-05-10 23:41 99% ` Tobias Geerinckx-Rice
2019-05-04 7:43 bug#35561: Fresh install, guix pull exits with error, hash mismatch Calle Kabo
2019-05-06 22:33 ` Ludovic Courtès
2019-05-06 22:59 99% ` Tobias Geerinckx-Rice
2019-05-06 23:20 ` Calle Kabo
2019-05-07 8:13 ` Ludovic Courtès
2019-05-07 16:13 99% ` Tobias Geerinckx-Rice
2019-05-04 20:04 bug#35566: Dvorak keyboard layout in graphical installl mode Daniel Dinnyes
2019-05-07 12:48 ` Ludovic Courtès
2019-05-07 13:23 99% ` Tobias Geerinckx-Rice
2019-05-05 16:27 97% bug#35583: Setting a GRUB keyboard-layout breaks GRUB… and Linux‽ Tobias Geerinckx-Rice
2019-05-05 18:20 bug#35586: GNOME Raghav Gururajan
2019-05-06 19:20 99% ` Tobias Geerinckx-Rice
2019-05-05 19:39 bug#35588: guix package --search does not search output names Chris Marusich
2019-05-05 21:41 99% ` bug#35588: [PATCH] ui: Search matches additional package outputs Tobias Geerinckx-Rice
2019-05-06 16:35 bug#35604: Is the top bootloader entry for previous generations the current one? pelzflorian (Florian Pelz)
2019-05-06 18:52 99% ` Tobias Geerinckx-Rice
2019-05-06 18:59 99% ` Tobias Geerinckx-Rice
2019-05-06 19:21 bug#35606: Gajim Raghav Gururajan
2019-05-06 19:40 89% ` Tobias Geerinckx-Rice
2019-05-07 18:03 bug#35623: guix pull failed on RHEL7 Karrick McDermott
2019-05-11 19:07 99% ` bug#35623: FW: " Tobias Geerinckx-Rice
2019-05-11 21:42 99% ` Tobias Geerinckx-Rice
2019-05-12 22:19 ` Ludovic Courtès
2019-05-12 22:47 99% ` Tobias Geerinckx-Rice
2019-05-12 23:09 99% ` Tobias Geerinckx-Rice
2019-05-11 7:32 bug#35683: wishlist: addessing statefulness of .cache(s) Giovanni Biscuolo
2019-05-11 7:43 ` Julien Lepiller
2019-05-11 11:51 99% ` Tobias Geerinckx-Rice
2019-05-11 11:45 99% ` Tobias Geerinckx-Rice
2019-05-16 1:54 99% bug#35759: [Manual installation] ‘mount /mnt’'s in the ‘Partitioning’ section Tobias Geerinckx-Rice
2019-05-19 19:19 bug#35800: [art] "GuixSD" on xfce screenshot swedebugia
2019-05-19 19:54 99% ` Tobias Geerinckx-Rice
2019-05-20 7:30 ` Ludovic Courtès
2019-05-20 12:21 99% ` Tobias Geerinckx-Rice
2019-05-23 12:27 bug#35864: ~/.local/bin is missing in default PATH on Guix System pelzflorian (Florian Pelz)
2019-05-23 14:17 ` Ricardo Wurmus
2019-05-23 15:31 ` pelzflorian (Florian Pelz)
2019-05-23 19:31 99% ` Tobias Geerinckx-Rice
2019-05-23 14:55 99% ` Tobias Geerinckx-Rice
2019-05-23 15:54 ` pelzflorian (Florian Pelz)
2019-05-23 19:35 99% ` Tobias Geerinckx-Rice
2019-05-28 11:17 bug#35942: guix install: environment variable message is very confusing Robert Vollmert
2019-05-28 12:08 99% ` Tobias Geerinckx-Rice
[not found] <874l5i52i1.fsf@roquette.mug.biscuolo.net>
[not found] ` <87r28mzqxv.fsf@nckx>
[not found] ` <87y32u3c9f.fsf@roquette.mug.biscuolo.net>
[not found] ` <87o93mwr4b.fsf@gnu.org>
[not found] ` <87a7f6qygw.fsf@nckx>
[not found] ` <87ftox11nu.fsf@roquette.mug.biscuolo.net>
2019-05-29 20:19 ` bug#35995: Installer: GUIX_IMAGE as /dev/sda on some hardware? Danny Milosavljevic
[not found] ` <874l5amhc8.fsf@gnu.org>
2019-05-31 22:16 99% ` Tobias Geerinckx-Rice
2019-06-08 13:15 bug#36135: installer wifi password prompt Julien Lepiller
2019-06-08 15:43 99% ` bug#36135: [PATCH 3/2] installer: Hide the Wi-Fi passphrase by default Tobias Geerinckx-Rice
2019-06-08 19:42 ` bug#36135: installer wifi password prompt Ludovic Courtès
2019-06-08 20:11 99% ` Tobias Geerinckx-Rice
2019-06-10 21:38 ` Ludovic Courtès
2019-06-10 22:36 99% ` Tobias Geerinckx-Rice
2019-06-16 23:44 bug#36254: Youtube-Viewer Raghav Gururajan
[not found] ` <handler.36254.B.156072868111528.ack@debbugs.gnu.org>
2019-06-17 0:49 ` bug#36254: Acknowledgement (Youtube-Viewer) Raghav Gururajan
2019-06-17 1:14 99% ` Tobias Geerinckx-Rice
2019-06-17 2:13 bug#36257: Youtube-Dl-GUI Raghav Gururajan
2019-07-02 21:17 99% ` Tobias Geerinckx-Rice
2019-06-17 11:25 bug#36262: cannot install bootloader to root partition znavko
2019-06-17 14:53 ` Danny Milosavljevic
2019-06-17 17:09 99% ` Tobias Geerinckx-Rice
2019-06-17 17:08 99% ` Tobias Geerinckx-Rice
2019-06-17 22:59 ` Mark H Weaver
2019-06-18 2:59 99% ` Tobias Geerinckx-Rice
2019-06-17 17:11 ` znavko
2019-06-18 2:33 99% ` Tobias Geerinckx-Rice
2019-06-22 20:23 99% bug#36333: Misleading hint for url-fetch Tobias Geerinckx-Rice
2019-06-24 17:23 bug#36363: let's encrypt hash mismatch Julien Lepiller
2019-06-24 18:44 99% ` Tobias Geerinckx-Rice
2019-06-25 9:24 99% bug#36371: guix build --with-git-reference=… Tobias Geerinckx-Rice
2019-06-26 18:14 99% bug#36394: guix.gnu.org/packages lists incorrect sqlite versions Tobias Geerinckx-Rice
2019-07-10 10:57 bug#36574: The installer recommends wrong initrd module names Meiyo Peng
2019-07-10 11:15 99% ` Tobias Geerinckx-Rice
2019-07-10 21:56 99% bug#36584: [Mumi] issues.guix.gnu.org doesn't mention bug-guix@ Tobias Geerinckx-Rice
2019-07-12 9:41 bug#36614: rust@1.36's hash is incorrect Pierre Langlois
2019-07-12 13:16 99% ` Tobias Geerinckx-Rice
2019-07-12 16:33 ` Ivan Petkov
2019-07-12 17:26 99% ` Tobias Geerinckx-Rice
2019-07-12 17:27 87% ` Tobias Geerinckx-Rice
2019-07-12 17:34 99% ` Tobias Geerinckx-Rice
2019-07-13 5:06 bug#36634: Virtual Machine Manager (virt-manager) Raghav Gururajan
2019-07-25 9:46 ` bug#36634: ATTENTION REQUIRED Raghav Gururajan
2019-07-25 19:36 99% ` Tobias Geerinckx-Rice
2019-07-25 20:01 99% ` Tobias Geerinckx-Rice
2019-07-20 16:20 bug#36743: Claws-Mail Issues Raghav Gururajan
2019-07-20 17:10 99% ` Tobias Geerinckx-Rice
2019-07-30 22:37 99% bug#36862: Root-owned /var/cache/fontconfig sometimes exists, shouldn't Tobias Geerinckx-Rice
2019-08-01 22:14 bug#36896: Evolution needs gsettings-desktop-schemas Martin Becze
2019-08-02 2:28 ` bug#36896: [PATCH] added gsettings-desktop-schema to progragated inputs null
2019-08-05 11:40 ` Ricardo Wurmus
2019-08-05 19:17 ` Martin Becze
2019-08-05 20:30 99% ` Tobias Geerinckx-Rice
2019-08-02 22:40 bug#36900: key-mon crashes on launch Jesse Gibbons
2019-08-02 23:21 99% ` Tobias Geerinckx-Rice
2019-10-24 16:22 bug#37905: psmisc-23.2.tar.xz was updated in place Tobias Geerinckx-Rice via Bug reports for GNU Guix
2019-10-24 16:36 99% ` bug#37905: (no subject) Tobias Geerinckx-Rice
2020-04-14 0:11 bug#40613: [PATCH] gnu: Add emacs-typing Alberto Eleuterio Flores Guerrero
2020-04-14 0:55 99% ` bug#40613: (no subject) Tobias Geerinckx-Rice
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).