python-pytest in references graph

python-pytest in references graph

[Roel Janssen]

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

Re: python-pytest in references graph

[Maxime Devos]

[-- 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 --]

Re: python-pytest in references graph

[Roel Janssen]

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

Re: python-pytest in references graph

[Lars-Dominik Braun]

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

Re: python-pytest in references graph

[bokr]

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

Re: python-pytest in references graph

[Tobias Geerinckx-Rice]

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.

Re: python-pytest in references graph

[Bengt Richter]

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