unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* python-pytest in references graph
@ 2022-07-24 20:25 Roel Janssen
  2022-07-24 21:01 ` Maxime Devos
  0 siblings, 1 reply; 7+ messages in thread
From: Roel Janssen @ 2022-07-24 20:25 UTC (permalink / raw)
  To: guix-devel

Dear Guix,

I'm trying to understand the output of:
$ guix graph --type=references python-rdflib | dot -Tsvg -o rdflib.svg

Particularly, I'm looking at why python-pytest has an input arrow from python-rdflib, while it's
"only" a native-input?  I thought the "references" graph type would only include run-time
references, but I don't know what happens in this case.

What am I missing?

Thank you for your time.

Kind regards,
Roel Janssen



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: python-pytest in references graph
  2022-07-24 20:25 python-pytest in references graph Roel Janssen
@ 2022-07-24 21:01 ` Maxime Devos
  2022-07-25  5:59   ` Roel Janssen
  2022-07-25  6:23   ` Lars-Dominik Braun
  0 siblings, 2 replies; 7+ messages in thread
From: Maxime Devos @ 2022-07-24 21:01 UTC (permalink / raw)
  To: Roel Janssen, guix-devel


[-- Attachment #1.1.1: Type: text/plain, Size: 932 bytes --]


On 24-07-2022 22:25, Roel Janssen wrote:
> I'm trying to understand the output of:
> $ guix graph --type=references python-rdflib | dot -Tsvg -o rdflib.svg
>
> Particularly, I'm looking at why python-pytest has an input arrow from python-rdflib, while it's
> "only" a native-input?  I thought the "references" graph type would only include run-time
> references, but I don't know what happens in this case.
>
> What am I missing?

It should, but sometimes there are bugs in the package definition or 
build system, in this case causing python-rdflib to refer to the 
native-input python-pytest.  Likely it's the 'add-install-to-path' phase 
adding too much, a known issue, which could be solved by separating 
inputs and native-inputs on the build side when compiling natively (and 
not only when cross-compiling) (currently they are merged together into 
'inputs'), though non-trivial.

Greetings,
Maxime.


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: python-pytest in references graph
  2022-07-24 21:01 ` Maxime Devos
@ 2022-07-25  5:59   ` Roel Janssen
  2022-07-25  6:23   ` Lars-Dominik Braun
  1 sibling, 0 replies; 7+ messages in thread
From: Roel Janssen @ 2022-07-25  5:59 UTC (permalink / raw)
  To: Maxime Devos, guix-devel

On Sun, 2022-07-24 at 23:01 +0200, Maxime Devos wrote:
> 
> On 24-07-2022 22:25, Roel Janssen wrote:
> > I'm trying to understand the output of:
> > $ guix graph --type=references python-rdflib | dot -Tsvg -o rdflib.svg
> > 
> > Particularly, I'm looking at why python-pytest has an input arrow from python-rdflib, while it's
> > "only" a native-input?  I thought the "references" graph type would only include run-time
> > references, but I don't know what happens in this case.
> > 
> > What am I missing?
> 
> It should, but sometimes there are bugs in the package definition or 
> build system, in this case causing python-rdflib to refer to the 
> native-input python-pytest.  Likely it's the 'add-install-to-path' phase 
> adding too much, a known issue, which could be solved by separating 
> inputs and native-inputs on the build side when compiling natively (and 
> not only when cross-compiling) (currently they are merged together into 
> 'inputs'), though non-trivial.

Thanks for your explanation! I see indeed that in the build output a couple
of programs include pytest in their "GUIX_PYTHONPATH".

Kind regards,
Roel Janssen


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: python-pytest in references graph
  2022-07-24 21:01 ` Maxime Devos
  2022-07-25  5:59   ` Roel Janssen
@ 2022-07-25  6:23   ` Lars-Dominik Braun
  2022-07-25 13:12     ` bokr
  1 sibling, 1 reply; 7+ messages in thread
From: Lars-Dominik Braun @ 2022-07-25  6:23 UTC (permalink / raw)
  To: Maxime Devos; +Cc: Roel Janssen, guix-devel

Hi,

> It should, but sometimes there are bugs in the package definition or 
> build system, in this case causing python-rdflib to refer to the 
> native-input python-pytest.  Likely it's the 'add-install-to-path' phase 
> adding too much, a known issue, which could be solved by separating 
> inputs and native-inputs on the build side when compiling natively (and 
> not only when cross-compiling) (currently they are merged together into 
> 'inputs'), though non-trivial.
the issue is indeed a known bug https://issues.guix.gnu.org/25235

Lars



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: python-pytest in references graph
  2022-07-25  6:23   ` Lars-Dominik Braun
@ 2022-07-25 13:12     ` bokr
  2022-07-25 14:41       ` Tobias Geerinckx-Rice
  0 siblings, 1 reply; 7+ messages in thread
From: bokr @ 2022-07-25 13:12 UTC (permalink / raw)
  To: Lars-Dominik Braun; +Cc: Maxime Devos, Roel Janssen, guix-devel

On +2022-07-25 08:23:57 +0200, Lars-Dominik Braun wrote:
> Hi,
> 
> > It should, but sometimes there are bugs in the package definition or 
> > build system, in this case causing python-rdflib to refer to the 
> > native-input python-pytest.  Likely it's the 'add-install-to-path' phase 
> > adding too much, a known issue, which could be solved by separating 
> > inputs and native-inputs on the build side when compiling natively (and 
> > not only when cross-compiling) (currently they are merged together into 
> > 'inputs'), though non-trivial.
> the issue is indeed a known bug https://issues.guix.gnu.org/25235
> 
> Lars
> 
>
what's up^H^H down with that URL??
-----------cut here---------------start------------->8---
[15:03 ~/bs]$ ping -c 3 issues.guix.gnu.org
PING issues.guix.gnu.org (141.80.181.40) 56(84) bytes of data.
64 bytes from 141.80.181.40 (141.80.181.40): icmp_seq=1 ttl=46 time=88.7 ms
64 bytes from 141.80.181.40 (141.80.181.40): icmp_seq=2 ttl=46 time=81.10 ms
64 bytes from 141.80.181.40 (141.80.181.40): icmp_seq=3 ttl=46 time=81.7 ms

--- issues.guix.gnu.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 81.727/84.125/88.669/3.214 ms
[15:03 ~/bs]$ wl-paste 
https://issues.guix.gnu.org/25235
[15:04 ~/bs]$ wget https://issues.guix.gnu.org/25235 >> gxiss23235.txt
--2022-07-25 15:05:57--  https://issues.guix.gnu.org/25235
Resolving issues.guix.gnu.org (issues.guix.gnu.org)... 141.80.181.40
Connecting to issues.guix.gnu.org (issues.guix.gnu.org)|141.80.181.40|:443... connected.
HTTP request sent, awaiting response... 502 Bad Gateway
2022-07-25 15:05:57 ERROR 502: Bad Gateway.
-----------cut here---------------end--------------->8---

--
Regards,
Bengt Richter


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: python-pytest in references graph
  2022-07-25 13:12     ` bokr
@ 2022-07-25 14:41       ` Tobias Geerinckx-Rice
  2022-07-25 17:32         ` Bengt Richter
  0 siblings, 1 reply; 7+ messages in thread
From: Tobias Geerinckx-Rice @ 2022-07-25 14:41 UTC (permalink / raw)
  To: guix-devel, bokr, Lars-Dominik Braun; +Cc: Maxime Devos, Roel Janssen

Hi Bengt,

Berlin is currently in a degraded state (probably a Shepherd bug).  The main Web site works, although it's probably not being updated, and last I checked substitutes did to, but issues. is down and I don't think Cuirass is building new substitutes.

We can't remotely reset the machine, so we wait until somebody can.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: python-pytest in references graph
  2022-07-25 14:41       ` Tobias Geerinckx-Rice
@ 2022-07-25 17:32         ` Bengt Richter
  0 siblings, 0 replies; 7+ messages in thread
From: Bengt Richter @ 2022-07-25 17:32 UTC (permalink / raw)
  To: Tobias Geerinckx-Rice
  Cc: guix-devel, Lars-Dominik Braun, Maxime Devos, Roel Janssen

Hi Tobias,

On +2022-07-25 14:41:15 +0000, Tobias Geerinckx-Rice wrote:
> Hi Bengt,
> 
> Berlin is currently in a degraded state (probably a Shepherd bug).  The main Web site works, although it's probably not being updated, and last I checked substitutes did to, but issues. is down and I don't think Cuirass is building new substitutes.
> 
> We can't remotely reset the machine, so we wait until somebody can.
> 
> Kind regards,
> 
> T G-R
> 
> Sent on the go.  Excuse or enjoy my brevity.

From tracepath, it seems to stop at some "RIPE" server[1]:
--8<---------------cut here---------------start------------->8---
[18:02 ~/bs]$ wl-paste 
11:  cr-tub2-be10.x-win.dfn.de                           102.352ms asymm 10 
12:  kr-mdcbln1.x-win.dfn.de                             110.156ms asymm 10 
13:  141.80.238.11                                        93.580ms asymm 17 
14:  no reply
--8<---------------cut here---------------end--------------->8---

FWIW:
[1] whois 141.80.238.11 >> whois.141.80.238.11.txt
and copying some lines from the less view:

--8<---------------cut here---------------start------------->8---
less whois.141.80.238.11.txt
[18:05 ~/bs]$ wl-paste 
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '141.80.0.0 - 141.80.255.255'
--8<---------------cut here---------------end--------------->8---

I guess their server would be the one that couldn't get anything from
where my wget failed:
--8<---------------cut here---------------start------------->8---
Connecting to issues.guix.gnu.org (issues.guix.gnu.org)|141.80.181.40|:443... connected.
HTTP request sent, awaiting response... 502 Bad Gateway
2022-07-25 15:05:57 ERROR 502: Bad Gateway.
--8<---------------cut here---------------end--------------->8---

How hard would it be to set up some kind of fail-over at issues.guix.gnu.org
(which presumably resolves ok internally) to say, e.g.

--8<---------------cut here---------------start------------->8---
    We know issues.guix.gnu.org (141.80.181.40)
    has been down since YYYY-MM-DD hh:mm:ss, sorry.
    Admin notified YYYY-MM-DD hh:mm:ss who replied:
    
    Fix ETA: ...
--8<---------------cut here---------------end--------------->8---
I.e., IWBN to get something informative from gnu rather than some net
error code :)

Is there an easy way to determine on the serving server how it is
responding to requests from the internet and switch/restore if down/up?

Or would you have to resort to some kind of periodic selfie-probe via
SSH/VPN to a cooperating mirror server?
(amateur idea :)

BTW, a good solution for informatiive status in place of error codes
might be applicable to other server stoppages and problems too, n'est-ce pas?

--
Regards,
Bengt Richter


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-07-25 17:33 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-24 20:25 python-pytest in references graph Roel Janssen
2022-07-24 21:01 ` Maxime Devos
2022-07-25  5:59   ` Roel Janssen
2022-07-25  6:23   ` Lars-Dominik Braun
2022-07-25 13:12     ` bokr
2022-07-25 14:41       ` Tobias Geerinckx-Rice
2022-07-25 17:32         ` Bengt Richter

Code repositories for project(s) associated with this 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).