Adding build status to the package list table

Adding build status to the package list table

[Roel Janssen]

Dear list,

The list of packages included in Guix [1] provides links to the build
status of each package in the details.  I would like to provide this
information in a column after "Package details", either as an icon or as
a count (e.g. 3/4 builds succeeded).  This provides a nicer overview for
the current status of the package.

The information is available in Hydra.  I read in this [2] ML thread
that Hydra can already output the information needed in JSON format.

I believe the impact will be fairly low, since all I plan on doing is
modify the website/www/packages.scm file in the artwork repository to
generate a fourth column on the table.

WDYT?

Kind regards,
Roel Janssen

[1]: https://www.gnu.org/software/guix/package-list.html
[2]: https://lists.gnu.org/archive/html/guix-devel/2015-09/msg00468.html

Re: Adding build status to the package list table

[Mark H Weaver]

Roel Janssen <roel@gnu.org> writes:

> The list of packages included in Guix [1] provides links to the build
> status of each package in the details.  I would like to provide this
> information in a column after "Package details", either as an icon or as
> a count (e.g. 3/4 builds succeeded).  This provides a nicer overview for
> the current status of the package.

Sounds good to me, but I'm not sure that either a single icon or a count
will be very useful.

We currently support four architectures: x86_64-linux, i686-linux,
armhf-linux, and mips64el-linux.  There will likely be a fifth for the
Hurd as well.

If the status is to be useful, users will need to see at a glance if the
package builds on their chosen architecture.  A count like 2/4 or 3/4
doesn't tell me whether the package works on armhf.

So, I think we'd actually need one new column for each supported
architecture.  I could imagine more clever solutions as well, but
somehow it needs to indicate *which* architectures the package builds
on, not just how many.

Does that make sense?

      Mark

Re: Adding build status to the package list table

[Eric Bavier]

On 2015-11-19 13:57, Mark H Weaver wrote:
> Roel Janssen <roel@gnu.org> writes:
> 
>> The list of packages included in Guix [1] provides links to the build
>> status of each package in the details.  I would like to provide this
>> information in a column after "Package details", either as an icon or 
>> as
>> a count (e.g. 3/4 builds succeeded).  This provides a nicer overview 
>> for
>> the current status of the package.
> 
> Sounds good to me, but I'm not sure that either a single icon or a 
> count
> will be very useful.
> 
> We currently support four architectures: x86_64-linux, i686-linux,
> armhf-linux, and mips64el-linux.  There will likely be a fifth for the
> Hurd as well.
> 
> If the status is to be useful, users will need to see at a glance if 
> the
> package builds on their chosen architecture.  A count like 2/4 or 3/4
> doesn't tell me whether the package works on armhf.
> 
> So, I think we'd actually need one new column for each supported
> architecture.  I could imagine more clever solutions as well, but
> somehow it needs to indicate *which* architectures the package builds
> on, not just how many.

I agree.

Could we add a small icon in the expanded view next to the current links 
that indicate pass/fail for that architecture?  This could possibly in 
addition to the summary count in the collapsed view.

-- 
`~Eric

Re: Adding build status to the package list table

[Roel Janssen]

Eric Bavier writes:

> On 2015-11-19 13:57, Mark H Weaver wrote:
>> Roel Janssen <roel@gnu.org> writes:
>> 
>>> The list of packages included in Guix [1] provides links to the build
>>> status of each package in the details.  I would like to provide this
>>> information in a column after "Package details", either as an icon or 
>>> as
>>> a count (e.g. 3/4 builds succeeded).  This provides a nicer overview 
>>> for
>>> the current status of the package.
>> 
>> Sounds good to me, but I'm not sure that either a single icon or a 
>> count
>> will be very useful.
>> 
>> We currently support four architectures: x86_64-linux, i686-linux,
>> armhf-linux, and mips64el-linux.  There will likely be a fifth for the
>> Hurd as well.
>> 
>> If the status is to be useful, users will need to see at a glance if 
>> the
>> package builds on their chosen architecture.  A count like 2/4 or 3/4
>> doesn't tell me whether the package works on armhf.
>> 
>> So, I think we'd actually need one new column for each supported
>> architecture.  I could imagine more clever solutions as well, but
>> somehow it needs to indicate *which* architectures the package builds
>> on, not just how many.
>
> I agree.
>
> Could we add a small icon in the expanded view next to the current links 
> that indicate pass/fail for that architecture?  This could possibly in 
> addition to the summary count in the collapsed view.

I think that would be a good idea. Adding icons per architecture next to
the current links in the expanded view.

Then have one column with an indicator for overall success or
failure. Whether this is a count or an icon, I don't know which would be
better. I think visually, an icon would be better. A count would be a
little more informing.

Having four (and in the future five) columns, each with an icon, would
be too much I think.

Re: Adding build status to the package list table

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

> The list of packages included in Guix [1] provides links to the build
> status of each package in the details.  I would like to provide this
> information in a column after "Package details", either as an icon or as
> a count (e.g. 3/4 builds succeeded).  This provides a nicer overview for
> the current status of the package.

That’s appealing.  However, it entails NUM-ARCHES × NUM-PACKAGES HTTP
requests, just when loading the page.  That seems unreasonable.

What about instead showing icons just in the expanded view, and making
the requests lazily, when the user asks for the expanded view?

The top of the page could still show the success rate maybe (it’s
possible to get that in a single HTTP request, IIRC.)

I agree with Mark et al. that showing one icon per architecture in the
expanded view would be nice.

Thanks,
Ludo’.

Re: Adding build status to the package list table

[Mark H Weaver]

Roel Janssen <roel@gnu.org> writes:

> Eric Bavier writes:
>
>> On 2015-11-19 13:57, Mark H Weaver wrote:
>>> Roel Janssen <roel@gnu.org> writes:
>>> 
>>>> The list of packages included in Guix [1] provides links to the build
>>>> status of each package in the details.  I would like to provide this
>>>> information in a column after "Package details", either as an icon or 
>>>> as
>>>> a count (e.g. 3/4 builds succeeded).  This provides a nicer overview 
>>>> for
>>>> the current status of the package.
>>> 
>>> Sounds good to me, but I'm not sure that either a single icon or a 
>>> count
>>> will be very useful.
>>> 
>>> We currently support four architectures: x86_64-linux, i686-linux,
>>> armhf-linux, and mips64el-linux.  There will likely be a fifth for the
>>> Hurd as well.
>>> 
>>> If the status is to be useful, users will need to see at a glance if 
>>> the
>>> package builds on their chosen architecture.  A count like 2/4 or 3/4
>>> doesn't tell me whether the package works on armhf.
>>> 
>>> So, I think we'd actually need one new column for each supported
>>> architecture.  I could imagine more clever solutions as well, but
>>> somehow it needs to indicate *which* architectures the package builds
>>> on, not just how many.
>>
>> I agree.
>>
>> Could we add a small icon in the expanded view next to the current links 
>> that indicate pass/fail for that architecture?  This could possibly in 
>> addition to the summary count in the collapsed view.
>
> I think that would be a good idea. Adding icons per architecture next to
> the current links in the expanded view.
>
> Then have one column with an indicator for overall success or
> failure.

What does "overall success or failure" mean?  If a package builds
successfully on i686 and armhf, and fails on x86_64 and mips64el, does
that count as an "overall success" or an "overall failure"?

> Whether this is a count or an icon, I don't know which would be
> better. I think visually, an icon would be better. A count would be a
> little more informing.
>
> Having four (and in the future five) columns, each with an icon, would
> be too much I think.

I'm sorry if it seems like too much, but for the reasons I gave above, a
count or boolean is essentially useless, because it doesn't tell people
whether it works on their architecture of interest.

      Mark

Re: Adding build status to the package list table

[Roel Janssen]

Ludovic Courtès writes:

> Roel Janssen <roel@gnu.org> skribis:
>
>> The list of packages included in Guix [1] provides links to the build
>> status of each package in the details.  I would like to provide this
>> information in a column after "Package details", either as an icon or as
>> a count (e.g. 3/4 builds succeeded).  This provides a nicer overview for
>> the current status of the package.
>
> That’s appealing.  However, it entails NUM-ARCHES × NUM-PACKAGES HTTP
> requests, just when loading the page.  That seems unreasonable.

Maybe we could instead determine the build status at the time we
generate the website's package list?

That would entail NUM-ARCHES × NUM-PACKAGES HTTP requests just once
every time we generate the page.   I believe this is once a day.  Can
Hydra handle this amount of HTTP requests?

Re: Adding build status to the package list table

[Pjotr Prins]

> Maybe we could instead determine the build status at the time we
> generate the website's package list?

Or trigger the page generation on a build. I don't think that will be
a problem for Hydra compared to other activity ;)

Pj.
-- 

Re: Adding build status to the package list table

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

> Ludovic Courtès writes:
>
>> Roel Janssen <roel@gnu.org> skribis:
>>
>>> The list of packages included in Guix [1] provides links to the build
>>> status of each package in the details.  I would like to provide this
>>> information in a column after "Package details", either as an icon or as
>>> a count (e.g. 3/4 builds succeeded).  This provides a nicer overview for
>>> the current status of the package.
>>
>> That’s appealing.  However, it entails NUM-ARCHES × NUM-PACKAGES HTTP
>> requests, just when loading the page.  That seems unreasonable.
>
> Maybe we could instead determine the build status at the time we
> generate the website's package list?

IMO it wouldn’t be very useful since the list is updated once a day.

Ludo’.

Re: Adding build status to the package list table

[Roel Janssen]

Mark H Weaver writes:

> Roel Janssen <roel@gnu.org> writes:
>
>> Eric Bavier writes:
>>
>>> On 2015-11-19 13:57, Mark H Weaver wrote:
>>>> Roel Janssen <roel@gnu.org> writes:
>>>> 
>>>>> The list of packages included in Guix [1] provides links to the build
>>>>> status of each package in the details.  I would like to provide this
>>>>> information in a column after "Package details", either as an icon or 
>>>>> as
>>>>> a count (e.g. 3/4 builds succeeded).  This provides a nicer overview 
>>>>> for
>>>>> the current status of the package.
>>>> 
>>>> Sounds good to me, but I'm not sure that either a single icon or a 
>>>> count
>>>> will be very useful.
>>>> 
>>>> We currently support four architectures: x86_64-linux, i686-linux,
>>>> armhf-linux, and mips64el-linux.  There will likely be a fifth for the
>>>> Hurd as well.
>>>> 
>>>> If the status is to be useful, users will need to see at a glance if 
>>>> the
>>>> package builds on their chosen architecture.  A count like 2/4 or 3/4
>>>> doesn't tell me whether the package works on armhf.
>>>> 
>>>> So, I think we'd actually need one new column for each supported
>>>> architecture.  I could imagine more clever solutions as well, but
>>>> somehow it needs to indicate *which* architectures the package builds
>>>> on, not just how many.
>>>
>>> I agree.
>>>
>>> Could we add a small icon in the expanded view next to the current links 
>>> that indicate pass/fail for that architecture?  This could possibly in 
>>> addition to the summary count in the collapsed view.
>>
>> I think that would be a good idea. Adding icons per architecture next to
>> the current links in the expanded view.
>>
>> Then have one column with an indicator for overall success or
>> failure.
>
> What does "overall success or failure" mean?  If a package builds
> successfully on i686 and armhf, and fails on x86_64 and mips64el, does
> that count as an "overall success" or an "overall failure"?

Initially, I was thinking:
When a package has been successfully built on 4/4 architectures, that
would be "success". When a build fails on some architecture, that would
indicate "failure".

That is, if all architectures are treated equally important to Guix.

So in your example, that would count as an "overall failure".

Instead we could use a percentage, in your example that would be 2/4 =
50%. That would still be useless to someone who wants to know whether
the package builds on a specific platform. He could then look in the
detailed view to find that out.

>> Whether this is a count or an icon, I don't know which would be
>> better. I think visually, an icon would be better. A count would be a
>> little more informing.
>>
>> Having four (and in the future five) columns, each with an icon, would
>> be too much I think.
>
> I'm sorry if it seems like too much, but for the reasons I gave above, a
> count or boolean is essentially useless, because it doesn't tell people
> whether it works on their architecture of interest.

You're right. But if you're interested in a single architecture, you
would ideally want to see a single icon as well (that of your
architecture).

Re: Adding build status to the package list table

[Roel Janssen]

Ludovic Courtès writes:

> Roel Janssen <roel@gnu.org> skribis:
>
>> Ludovic Courtès writes:
>>
>>> Roel Janssen <roel@gnu.org> skribis:
>>>
>>>> The list of packages included in Guix [1] provides links to the build
>>>> status of each package in the details.  I would like to provide this
>>>> information in a column after "Package details", either as an icon or as
>>>> a count (e.g. 3/4 builds succeeded).  This provides a nicer overview for
>>>> the current status of the package.
>>>
>>> That’s appealing.  However, it entails NUM-ARCHES × NUM-PACKAGES HTTP
>>> requests, just when loading the page.  That seems unreasonable.
>>
>> Maybe we could instead determine the build status at the time we
>> generate the website's package list?
>
> IMO it wouldn’t be very useful since the list is updated once a day.

Ok. If we can instead fetch the status of all packages on all
architectures in one HTTP request (using javascript on the client-side),
would that be acceptable? The size of the build status information
should be about the same size as the list of packages.

For this we need a supporting API call of course.

Re: Adding build status to the package list table

[Pjotr Prins]

On Sat, Nov 21, 2015 at 04:24:50PM +0100, Roel Janssen wrote:
> > IMO it wouldn’t be very useful since the list is updated once a day.
> 
> Ok. If we can instead fetch the status of all packages on all
> architectures in one HTTP request (using javascript on the client-side),
> would that be acceptable? The size of the build status information
> should be about the same size as the list of packages.
> 
> For this we need a supporting API call of course.

Sounds good to me as long as it also looks nice for people who switch
JS off.

Pj.
-- 

Re: Adding build status to the package list table

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

> Ludovic Courtès writes:
>
>> Roel Janssen <roel@gnu.org> skribis:
>>
>>> Ludovic Courtès writes:
>>>
>>>> Roel Janssen <roel@gnu.org> skribis:
>>>>
>>>>> The list of packages included in Guix [1] provides links to the build
>>>>> status of each package in the details.  I would like to provide this
>>>>> information in a column after "Package details", either as an icon or as
>>>>> a count (e.g. 3/4 builds succeeded).  This provides a nicer overview for
>>>>> the current status of the package.
>>>>
>>>> That’s appealing.  However, it entails NUM-ARCHES × NUM-PACKAGES HTTP
>>>> requests, just when loading the page.  That seems unreasonable.
>>>
>>> Maybe we could instead determine the build status at the time we
>>> generate the website's package list?
>>
>> IMO it wouldn’t be very useful since the list is updated once a day.
>
> Ok. If we can instead fetch the status of all packages on all
> architectures in one HTTP request (using javascript on the client-side),
> would that be acceptable? The size of the build status information
> should be about the same size as the list of packages.

This would be OK, yes.  We just need to make sure Hydra executes said
request in a reasonable amount of CPU time.

Thanks,
Ludo’.

Re: Adding build status to the package list table

[Roel Janssen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: 0001-website-packages-Add-build-status-icons-in-the-expan.patch --]
[-- Type: text/x-patch, Size: 14877 bytes --]

From a37d4ff3d0a0abe676ce7458d11f8797d6bd30ac Mon Sep 17 00:00:00 2001
From: Roel Janssen <roel@gnu.org>
Date: Tue, 24 Nov 2015 14:08:34 +0100
Subject: [PATCH] website: packages: Add build status icons in the expanded
 view.

* website/www/packages.scm (package->sxml): Wrap the build status link in a div
  and prepend an icon to the div.
* website/static/base/js/packages.js (show_hide): Fetch build status on expand.
---
 website/static/base/css/packages.css               |   5 +++-
 website/static/base/img/status-icons/0.png         | Bin 0 -> 821 bytes
 website/static/base/img/status-icons/1.png         | Bin 0 -> 732 bytes
 website/static/base/img/status-icons/2.png         | Bin 0 -> 777 bytes
 website/static/base/img/status-icons/3.png         | Bin 0 -> 736 bytes
 website/static/base/img/status-icons/4.png         | Bin 0 -> 753 bytes
 website/static/base/img/status-icons/5.png         | Bin 0 -> 777 bytes
 website/static/base/img/status-icons/undefined.png | Bin 0 -> 746 bytes
 website/static/base/img/status-icons/unknown.png   | Bin 0 -> 746 bytes
 website/static/base/js/packages.js                 |  27 +++++++++++++++++++++
 website/www/packages.scm                           |   9 +++++--
 11 files changed, 38 insertions(+), 3 deletions(-)
 create mode 100644 website/static/base/img/status-icons/0.png
 create mode 100644 website/static/base/img/status-icons/1.png
 create mode 100644 website/static/base/img/status-icons/2.png
 create mode 100644 website/static/base/img/status-icons/3.png
 create mode 100644 website/static/base/img/status-icons/4.png
 create mode 100644 website/static/base/img/status-icons/5.png
 create mode 100644 website/static/base/img/status-icons/undefined.png
 create mode 100644 website/static/base/img/status-icons/unknown.png

diff --git a/website/static/base/css/packages.css b/website/static/base/css/packages.css
index d9771be..97d0345 100644
--- a/website/static/base/css/packages.css
+++ b/website/static/base/css/packages.css
@@ -61,4 +61,7 @@ a#top {
 a#top:hover, a#top:focus {
     background-color:#333;
     color:#fff;
-}
\ No newline at end of file
+}
+img.status-icon {
+    padding-right: 1em;
+}
diff --git a/website/static/base/img/status-icons/0.png b/website/static/base/img/status-icons/0.png
new file mode 100644
index 0000000000000000000000000000000000000000..3940d8c499c1867d5de7cc2608b5829683bea8ac
GIT binary patch
literal 821
zcmV-51Iqk~P)<h;3K|Lk000e1NJLTq000mG000mO1^@s6AM^iV00001b5ch_0Itp)
z=>Px#24YJ`L;(K){{a7>y{D4^000SaNLh0L01FcU01FcV0GgZ_00007bV*G`2ipq}
z5eooq^e|2U00Om1L_t(I%YBkfXdP7)$A9O}+?jckycm-vY74g6SWRAP#DxaL>c;M*
zpf0o})LKZ@Qd?+OD)_NbyQvG2qDVhnxN+k`M7oXON@9~f(^5Aj&=0Me#3XNK?!Cvw
zdr4`l9{9t7bMEi_;r@mHsQyp-hk9#$!$u@rUA!{0bZBY*-}Yp!89CM9{GM4x&pf>A
z@lE5$8yiLkda}Dvl*M9!i@(oZo|>O}?cBulw-0==m5Z-jxCvN){N>o!jg5~y_lK<L
zuf@C+coZekh%L#zIzU}6T%GxJdiPJS-|67==&>rdN2{8}*AiS}AvWzL7to?bv|5m_
zDp9LC+?<&C7(hl&H4v|ZF1OdpdP<eI<ugmLZGbNe-W`0I9-r{e^oLqoc9Q(nO3%GI
zSDN#CW(l!*BiI<9SX`Fia!c8rQubuD>M1+#dxnD>Uu3-hQAkq>HpX?ulK=)lBY85!
zh7cPnE4b9+a!b)&V_WY-oV@1<H~b<`H}|79BE&`!vwa;P$lZwGC9rSsS+;kNQAEl>
z*3S?1_wWQByL^CP1QkF;ROkbU0TjK4>ToWpd~p8(08XrY&-2MRg7C!kqx@MeU_(Fx
zpg~2sa?^niXT=3^MZxADcQCay&Hj7`8%z(oe*1{#!X-@Mh)Rz*k8wc=;q1tnZS8Mt
ze7-evUD;|?&$P-@S*Qi}ZF+&ew3lPozasHM+^UFIN|NP5?cXh(d+F!smK+S99-Z`A
ze4@-OK8|oU!W)Pr!uWtG9g*{zv?__pYG-p|_M2M(9mrb_dEYI24W$aYHc?DsH10AI
z8z!3*GoRg&#Pvj;92s*e$JOgo>e>W}1c~|1pa*~1+q}g8lrfo!JAE|t_R#Q_H#a}H
zel3xxb5w43AV36IAO&h2t-&f_wW9)XfCuy+W?2{|woAuj00000NkvXXu0mjf(}aDt

literal 0
HcmV?d00001

diff --git a/website/static/base/img/status-icons/1.png b/website/static/base/img/status-icons/1.png
new file mode 100644
index 0000000000000000000000000000000000000000..74e9c24557c30fd12a6e66ce8f1efc3d67af234f
GIT binary patch
literal 732
zcmV<20wev2P)<h;3K|Lk000e1NJLTq000mG000mO1^@s6AM^iV00001b5ch_0Itp)
z=>Px#24YJ`L;(K){{a7>y{D4^000SaNLh0L01FcU01FcV0GgZ_00007bV*G`2ipq}
z5eYDP8)9Gp00LY|L_t(I%YBkhNK{c2#((#|``-L%Msg$<uCf-1Gbt2gB2f_0E{GO^
zi-Hy@g)UmO3L>IKi%42jxCnx9<)TH4Kw4Rw7M3}hpd0O<5&h9oXWqQ`?rHI66tnu^
zz=iMJ@0|0Uqxc6Vpw)$Tz*b@EAbk8=o~l2JKmjNkr#E}z_)xm*&@QJb2O@;ue^8lx
z_n|cQ;!=KX{aG>FK%um<DNz4B?U~Wck*+hU{8Pe(Sw(13fM|to*&{SGtM%7!?zgX1
zE^qHZbK9i3>ZZV?!AXENF=s=Fd<fPctUy@iN+IGdfGWm0%}$c9ZWg=@I0lj(ZP-t<
zV8O}vP#%9p7(uX#1S_b(C(!{_T>#JwY7a~T92a)pdO&XUJ*n;<cAPp(<D-`}-g%61
z!AYRB2aZGkhLbaf@%bFG*ou7VM3yfc5D^ivR_a(jw_lbzk;UD}Tn;;97>#SkPBfxo
zN3;ezH$ipe2B_E~|K3IH!c?5CK`9i9+@^rAgdo`1F!$tnyx!|b)dw4q7#v0yjzR=j
z5Q`uzZ3u`kW&>0dLR100uN#21{!Ug04##sgwG#Re1z<yzSjLK~w#K)R^b(Z4EaGNR
z#(=lC1%7>w8+5Y--%5mjyoG8BY4>rq+`+V_&q?u6r+_3F7nA`6Yy?pi#7FEp%2qg?
zw>;e<05I)vEi~L*)rhZ9A|QZP;0cnkC^w)lZyDZpiFHgWI&l~Z6vx6EYXpq&T!##F
zz&!tfPDAa0aYms13AEM8BsjIA>dy`oG3f#cAXSUHSOAoPN-aX-rOI!a(edPD>Lcy|
O0000<MNUMnLSTZibUPFP

literal 0
HcmV?d00001

diff --git a/website/static/base/img/status-icons/2.png b/website/static/base/img/status-icons/2.png
new file mode 100644
index 0000000000000000000000000000000000000000..7f9534472ef236d718d71627c233d8f9f7172ee1
GIT binary patch
literal 777
zcmV+k1NQuhP)<h;3K|Lk000e1NJLTq000mG000mO1^@s6AM^iV00001b5ch_0Itp)
z=>Px#24YJ`L;(K){{a7>y{D4^000SaNLh0L01FcU01FcV0GgZ_00007bV*G`2ipq}
z5eXC9d=nA?00N0gL_t(I%YBngNK{c2fWP~m&#^Z;)+Cw^R%U-%Bt@YMQAs!bxTqk)
zl%RqZ?pg#vv?vJL<RWkpxCqOQ5z%5GEf5P!Xb}#AAQ6g*<L`{qyqS6P?z=5!Ml{F+
z=ib9T=Y02Y?>U11$eAjt4wq9a1n%@aq48hLv7K}@W%iqA=?Fe4UtA2fDCcXtN{?Ms
zOTk7p@+>gheV&T|-52zYJdsNt7=>GHyt&b)Us;TK)X!N<B-5Y(LxX)4h6?zl82sY)
z_6F(R0s!c2;c2nSJ)a5wLhu$qeqIJ(J76VY^$)CD5Vg4bYJ?sD(a{7_Qd(pZE-i)<
z9~60DZ}lPU$TUhpQJ|jb&^WOaEU%-MqKMTvp0{JzdT0htR&&4DOOwA4c6y<;>p7>d
z_9MeXlpSc`)b$}s$|{+ic#m`uwgZmC^27||8h|cnHuAue4`u-@h57)fx%QcZ?Sp_~
z{(BEz6Fdgw8z^0;2|xo78oP82G!1kO5{o|we|wm7^ZV0nQY(|>Vl;se0{;d;DHf!Q
za$Rs7C^_CmS;HfgOn{pv(AtML(1;^Jx*%PYQY>r$q-5AmBN8^mlVI+t2O#vaj>*><
z8?%Z;5>htUX@ryvceZ4|@lpc?{vr~kKGbd>!smhVKpAc_i~?L?va)6oiNi_^wG>75
zeMAQ`%hVjsu}T(PMZ2pYC1E`lCuTv!g5^k>wKzoMsHlaoQd|zrFtw$T0J@raU>H2k
zzK2koe40S%8p4s>=^x=m?p)stn3!SoNCodSK@G5fbGs_V2ixJ?z$nAp&6Jj>k(YzF
z)lu7ef}<O^Y3Ny=_;(gWwi*NQ06VgpgQbB4kj$zBNI?Aspg;nIJS#=r00000NkvXX
Hu0mjfD62|e

literal 0
HcmV?d00001

diff --git a/website/static/base/img/status-icons/3.png b/website/static/base/img/status-icons/3.png
new file mode 100644
index 0000000000000000000000000000000000000000..6405a3ab3a4972cc05901bc318e887632bc698a7
GIT binary patch
literal 736
zcmV<60w4W}P)<h;3K|Lk000e1NJLTq000mG000mO1^@s6AM^iV00001b5ch_0Itp)
z=>Px#24YJ`L;(K){{a7>y{D4^000SaNLh0L01FcU01FcV0GgZ_00007bV*G`2ipq}
z5jhfbJr#EV00Ll1L_t(I%YBkfNK{c6hM#lJow@VVm>L=7N@<~^ViKgHX@PB9)FKL^
zMNrb;BB)gm(JBaXRbh)LB3iU;5sYn8A?QcS(IVRwqJ)M`(_HV|d%hNTR7mTC4-VhY
z`@V<oRs16+cGBQ%Aq&`Gk;#r3zHKz8Rv!6YXdQ!mzd4ra92iP9@7ZdqYe6i*(jwl>
zhp&a#BWGH2rDszIGPL9hYXB?D)BDZSbVv7L6)Z^b{j*XMf`FhfwT(ieP8IVLx3f9#
z>^cQgecW);Tz1mnq`|nLV^PnRAzX%_7-jhv7h6ZU1)%c1AOUsGCg$UtAyx&B3vOc*
zvh)cNFxz|Z^5X<P_&<^I63Sn|ZJ)r`tz)2LTrdeR$%wi7_#J95eI%LfA>Da|nsZ}R
zpL~FcgOfmM7n}@(02%;8zjh+YCJE)qdjO=4j*>k11OWfdO-!;f;~>h=w+f&XHE2)@
zlm<Kh4*%7)r~oXFoI(~RQM$6BQ7CHH6bN&Kh*+=z#M({}@4AYF9!Q8gFpR11M=W4L
zEP^n%3Scd{FhJQd*b?Y%-2fEt@1ppyE8<8s5PD#Juw|5l<feNoXPn$k!l|JYuR>x~
zDC2@#zXS1RBOj;?!H)t#Y4r-y`~m~u0JOcuo7&4@xyaoR&@L=5&!QYazy<}Z58@&A
zH!Acww9ZHsGhGQCt`|UjixOGu#Wj*qC@0`_%S(ng1ORy7OFNpOK(Q}~1P}v^@LYwQ
zZy)Ci{|TMa(YFBexQ*<iHkwwN35}_cs=pN|z*NXwAX&*3urg2ryh;W@2*@9rOzSdr
S7VOsm0000<MNUMnLSTYk-#HQh

literal 0
HcmV?d00001

diff --git a/website/static/base/img/status-icons/4.png b/website/static/base/img/status-icons/4.png
new file mode 100644
index 0000000000000000000000000000000000000000..6b6fca4619ca2cb3537b7fc629e15cfda9e170af
GIT binary patch
literal 753
zcmV<N0uKF&P)<h;3K|Lk000e1NJLTq000mG000mO1^@s6AM^iV00001b5ch_0Itp)
z=>Px#24YJ`L;(K){{a7>y{D4^000SaNLh0L01FcU01FcV0GgZ_00007bV*G`2iyf2
z0U`zi%4o9y00MDIL_t(I%YD<!Yh6_o2JqiL=bo6iS|5$cz$P&<(m@SGQS8J)VnPK=
z2URS6pd#qhiQ-sC`WIMQArM4ypbk0_9klouRH_AAW2;S|P<yLQ8clBQd29zak&uE5
zHhb;G`q=AR-&$<5SKC{6Kf5N`H_7w^^uw`^WP7^W_CUSi;Af))$M^0Y>)FxWNfq6^
zwe0NWg=;5%UVI6sw&sVek0Wiqc&$5mb}?;>^Yunp%UbcQV5qki2h%Fd{#~8;py}mJ
zOuFg3n0c=^IQDxHHS;3e*~UFJ?n-EH<7QEXpYkYYd^E9izViKl6&y(P-d(eNU&6hC
zt~GXzkI64z6eB$oPx$5Q@BGujjmY(i#UT4~U6DY0>dj7KcM!WvranAr`iBdK#ve2K
z%#5eM`qsXW=5!TwC3NEc%Ih!GHYzxrIlVKncV|Lhjlq#IPo2FWmZgxkSf1YVuq#*Q
z{gHDma=rA)Z0=yP!J{_`Vj4&z`TRv!-+qIT5Tk`x4l5RZl~$yIq=o6D<%>bRB$SZ?
zz55Rsc;|hw*`TUCczjmJqZ0}gkt&Lj-yk`fQAMZLD;ij7uw&{uaPILvetdFwOQyjg
zt0fKMI-%s7=Qn#W6J&jv=B5fgYxEBfi1n+WDY2ASmT)7A^-4I|Y++NlMD<8w0sCX1
znQ?1n#Y$wU<j)xW6~!gOawV)rGZXDDoy)gP;-So28Sj?FqSf6HB8W+A?n9G9bGf<O
zCK1k8&Wxl!O&Ljo;SdRd5CnX_8cly(IOG59jtymCD)rE0VtC7Mx2@w=3JEf_qhsT2
jtdksTSjD=Q+9mu8Bv<9ht)gHV00000NkvXXu0mjfiH2Nr

literal 0
HcmV?d00001

diff --git a/website/static/base/img/status-icons/5.png b/website/static/base/img/status-icons/5.png
new file mode 100644
index 0000000000000000000000000000000000000000..7f9534472ef236d718d71627c233d8f9f7172ee1
GIT binary patch
literal 777
zcmV+k1NQuhP)<h;3K|Lk000e1NJLTq000mG000mO1^@s6AM^iV00001b5ch_0Itp)
z=>Px#24YJ`L;(K){{a7>y{D4^000SaNLh0L01FcU01FcV0GgZ_00007bV*G`2ipq}
z5eXC9d=nA?00N0gL_t(I%YBngNK{c2fWP~m&#^Z;)+Cw^R%U-%Bt@YMQAs!bxTqk)
zl%RqZ?pg#vv?vJL<RWkpxCqOQ5z%5GEf5P!Xb}#AAQ6g*<L`{qyqS6P?z=5!Ml{F+
z=ib9T=Y02Y?>U11$eAjt4wq9a1n%@aq48hLv7K}@W%iqA=?Fe4UtA2fDCcXtN{?Ms
zOTk7p@+>gheV&T|-52zYJdsNt7=>GHyt&b)Us;TK)X!N<B-5Y(LxX)4h6?zl82sY)
z_6F(R0s!c2;c2nSJ)a5wLhu$qeqIJ(J76VY^$)CD5Vg4bYJ?sD(a{7_Qd(pZE-i)<
z9~60DZ}lPU$TUhpQJ|jb&^WOaEU%-MqKMTvp0{JzdT0htR&&4DOOwA4c6y<;>p7>d
z_9MeXlpSc`)b$}s$|{+ic#m`uwgZmC^27||8h|cnHuAue4`u-@h57)fx%QcZ?Sp_~
z{(BEz6Fdgw8z^0;2|xo78oP82G!1kO5{o|we|wm7^ZV0nQY(|>Vl;se0{;d;DHf!Q
za$Rs7C^_CmS;HfgOn{pv(AtML(1;^Jx*%PYQY>r$q-5AmBN8^mlVI+t2O#vaj>*><
z8?%Z;5>htUX@ryvceZ4|@lpc?{vr~kKGbd>!smhVKpAc_i~?L?va)6oiNi_^wG>75
zeMAQ`%hVjsu}T(PMZ2pYC1E`lCuTv!g5^k>wKzoMsHlaoQd|zrFtw$T0J@raU>H2k
zzK2koe40S%8p4s>=^x=m?p)stn3!SoNCodSK@G5fbGs_V2ixJ?z$nAp&6Jj>k(YzF
z)lu7ef}<O^Y3Ny=_;(gWwi*NQ06VgpgQbB4kj$zBNI?Aspg;nIJS#=r00000NkvXX
Hu0mjfD62|e

literal 0
HcmV?d00001

diff --git a/website/static/base/img/status-icons/undefined.png b/website/static/base/img/status-icons/undefined.png
new file mode 100644
index 0000000000000000000000000000000000000000..1d982e9ca39ac1cd59445ef529e8741e30d9b7ae
GIT binary patch
literal 746
zcmV<G0u}v<P)<h;3K|Lk000e1NJLTq000mG000mO1^@s6AM^iV00001b5ch_0Itp)
z=>Px#24YJ`L;(K){{a7>y{D4^000SaNLh0L01FcU01FcV0GgZ_00007bV*G`2ipq}
z5iuw2S6f^F00L@BL_t(I%YBm1OI1-2$3N%Cz4yH*L>8H31r|iLYGcr*T13l&QWph5
z1t}p>geirag4EYS7e$M}Tve!T3JU5EXjg#{6yYK*w35tU@7;UuIj6;aW*RjxFmvX7
zzw@181pl(DgY{J9b_0%|3!@azPT)NVvEtiu)-wd1&8XtY$wT$EeS0^p+fbd4a2|e?
zVn(NC#$S$oX)U!kK3iWLX8KCg9|TL_TaQQfZQXc$+6w=EE*8#9z$5T%s|tKgfOzxy
z+nw^|V{Lyc=p8N+=G%#K5amDz;AB>l4pIYg8R8No<x6xl^=AY<L*Q%;QGSYi6+{Jy
z@|@mL!$3nF04H9J^Kk5Y1}-mpN(+M0Y(&?oMAF#|N?$~W5QGrr$QKF>G}JL(woE6E
z2m7{Us=^4uP!I$V7Fqx@jZ*DLDv%nqMnw@v-p<hSA!goXQ>ZY?#!?!T_DFF6Kvy<V
zjT9gy2+6z?JpG#D53dE_%)2=(S*_AjfT&(3a7^LcF1!;s2iAg1xjhjx9y{)TS^#gs
zyUg((m|PygyB9bsNYiZFCZ<*z+BQe@ZqFl48BCJZtO1(}oP9}gq@uvY{V3gyPCQBp
zgkW;U@%l%J>BQm|<}zSX29tP<adb2duD*j-!sxEhAxbH{4zLJ7pmF%r;B4x>F#?ku
zrK9o5N&<l1kuL4+^+IXZ2T56o$`v{!Mn`_JutuaxpW{m7y}vJU>7o149_f9bw&tL=
z27purq)I=xo(o(%@sa<SB+ThbtT=yjH?22z{%#b6suGLU3Iw2l0EmEm#h1toP^x$g
cq<{tdFX?&$j<f=7dH?_b07*qoM6N<$f>m@rG5`Po

literal 0
HcmV?d00001

diff --git a/website/static/base/img/status-icons/unknown.png b/website/static/base/img/status-icons/unknown.png
new file mode 100644
index 0000000000000000000000000000000000000000..1d982e9ca39ac1cd59445ef529e8741e30d9b7ae
GIT binary patch
literal 746
zcmV<G0u}v<P)<h;3K|Lk000e1NJLTq000mG000mO1^@s6AM^iV00001b5ch_0Itp)
z=>Px#24YJ`L;(K){{a7>y{D4^000SaNLh0L01FcU01FcV0GgZ_00007bV*G`2ipq}
z5iuw2S6f^F00L@BL_t(I%YBm1OI1-2$3N%Cz4yH*L>8H31r|iLYGcr*T13l&QWph5
z1t}p>geirag4EYS7e$M}Tve!T3JU5EXjg#{6yYK*w35tU@7;UuIj6;aW*RjxFmvX7
zzw@181pl(DgY{J9b_0%|3!@azPT)NVvEtiu)-wd1&8XtY$wT$EeS0^p+fbd4a2|e?
zVn(NC#$S$oX)U!kK3iWLX8KCg9|TL_TaQQfZQXc$+6w=EE*8#9z$5T%s|tKgfOzxy
z+nw^|V{Lyc=p8N+=G%#K5amDz;AB>l4pIYg8R8No<x6xl^=AY<L*Q%;QGSYi6+{Jy
z@|@mL!$3nF04H9J^Kk5Y1}-mpN(+M0Y(&?oMAF#|N?$~W5QGrr$QKF>G}JL(woE6E
z2m7{Us=^4uP!I$V7Fqx@jZ*DLDv%nqMnw@v-p<hSA!goXQ>ZY?#!?!T_DFF6Kvy<V
zjT9gy2+6z?JpG#D53dE_%)2=(S*_AjfT&(3a7^LcF1!;s2iAg1xjhjx9y{)TS^#gs
zyUg((m|PygyB9bsNYiZFCZ<*z+BQe@ZqFl48BCJZtO1(}oP9}gq@uvY{V3gyPCQBp
zgkW;U@%l%J>BQm|<}zSX29tP<adb2duD*j-!sxEhAxbH{4zLJ7pmF%r;B4x>F#?ku
zrK9o5N&<l1kuL4+^+IXZ2T56o$`v{!Mn`_JutuaxpW{m7y}vJU>7o149_f9bw&tL=
z27purq)I=xo(o(%@sa<SB+ThbtT=yjH?22z{%#b6suGLU3Iw2l0EmEm#h1toP^x$g
cq<{tdFX?&$j<f=7dH?_b07*qoM6N<$f>m@rG5`Po

literal 0
HcmV?d00001

diff --git a/website/static/base/js/packages.js b/website/static/base/js/packages.js
index c8d9fc4..246d828 100644
--- a/website/static/base/js/packages.js
+++ b/website/static/base/js/packages.js
@@ -1,5 +1,27 @@
 /* license: CC0 */
 
+function set_build_status (pkg_string)
+{
+  /* Find the element to put the status icon in. */
+  var pkgIcon = document.getElementById("icon-"+ pkg_string);
+
+  /* Don't bother when the icon doesn't exist. */
+  if (pkgIcon != null)
+  {
+    var xhttp = new XMLHttpRequest();
+    xhttp.onreadystatechange = function() {
+      if (xhttp.readyState == 4 && xhttp.status == 200) {
+
+          /* The API call returns JSON. Parse it, and change the icon's source. */
+          var pkgInfo = JSON.parse(xhttp.responseText);
+          pkgIcon.src = "../static/base/img/status-icons/"+ pkgInfo[0]["buildstatus"] + ".png";
+      }
+    }
+    xhttp.open("GET", "http://hydra.gnu.org/api/latestbuilds?nr=1&project=gnu&jobset=master&job="+ pkg_string, true);
+    xhttp.send();
+  }
+}
+
 function show_hide(idThing)
 {
   if(document.getElementById && document.createTextNode) {
@@ -9,6 +31,11 @@ function show_hide(idThing)
     var thingLink = thing.previousSibling.lastChild.firstChild;
     if (thing) {
       if (thing.style.display == "none") {
+        var column = thing.parentNode;
+        var pkg_icons = column.getElementsByTagName('img')
+        for (var i=0; i < pkg_icons.length; i++) {
+            set_build_status (pkg_icons[i].id.slice(5));
+        }
         thing.style.display = "";
         thingLink.data = 'Collapse';
       } else {
diff --git a/website/www/packages.scm b/website/www/packages.scm
index caf54dd..1375486 100644
--- a/website/www/packages.scm
+++ b/website/www/packages.scm
@@ -162,11 +162,16 @@ decreasing, is 1."
 
   (define (status package)
     (define (url system)
-      `(a (@ (href ,(string-append "http://hydra.gnu.org/job/gnu/master/"
+      `(div (img (@ (src ,(image-url "status-icons/unknown.png"))
+                    (id ,(string-append "icon-" (package-full-name package) "." system))
+                    (class "status-icon")
+                    (alt "Unknown")
+                    (title "Unknown")))
+            (a (@ (href ,(string-append "http://hydra.gnu.org/job/gnu/master/"
                                    (package-full-name package) "."
                                    system))
              (title "View the status of this architecture's build at Hydra"))
-          ,system))
+          ,system)))
 
     `(div "status: "
           ,(list-join (map url
-- 
2.5.0


[-- Attachment #2: Type: text/plain, Size: 2560 bytes --]


Ludovic Courtès writes:

> Roel Janssen <roel@gnu.org> skribis:
>
>> Ludovic Courtès writes:
>>
>>> Roel Janssen <roel@gnu.org> skribis:
>>>
>>>> Ludovic Courtès writes:
>>>>
>>>>> Roel Janssen <roel@gnu.org> skribis:
>>>>>
>>>>>> The list of packages included in Guix [1] provides links to the build
>>>>>> status of each package in the details.  I would like to provide this
>>>>>> information in a column after "Package details", either as an icon or as
>>>>>> a count (e.g. 3/4 builds succeeded).  This provides a nicer overview for
>>>>>> the current status of the package.
>>>>>
>>>>> That’s appealing.  However, it entails NUM-ARCHES × NUM-PACKAGES HTTP
>>>>> requests, just when loading the page.  That seems unreasonable.
>>>>
>>>> Maybe we could instead determine the build status at the time we
>>>> generate the website's package list?
>>>
>>> IMO it wouldn’t be very useful since the list is updated once a day.
>>
>> Ok. If we can instead fetch the status of all packages on all
>> architectures in one HTTP request (using javascript on the client-side),
>> would that be acceptable? The size of the build status information
>> should be about the same size as the list of packages.
>
> This would be OK, yes.  We just need to make sure Hydra executes said
> request in a reasonable amount of CPU time.

I've attached a patch that adds status icons to the links in the
expanded view. It only loads when the user clicks on "expand". We might
need to add a HTTP header from the GNU server to allow loading data from
external sources:

  https://en.wikipedia.org/wiki/Cross-origin_resource_sharing

I hope my commit message is OK this way.

For fetching all statuses in one API call, I would like to propose
adding a function to Hydra that can return the status in an array like
the following JSON code:

[
  {"timestamp":1447890755,"buildstatus":0,"job":"a2ps-4.14.x86_64-linux","jobset":"master","project":"gnu","system":"x86_64-linux","nixname":"a2ps-4.14","finished":1,"id":812555},
  {"finished":1,"id":811961,"system":"i686-linux","nixname":"a2ps-4.14","project":"gnu","jobset":"master","job":"a2ps-4.14.i686-linux","timestamp":1447890647,"buildstatus":0},
  {"timestamp":1447890485,"buildstatus":0,"job":"a2ps-4.14.armhf-linux","nixname":"a2ps-4.14","system":"armhf-linux","id":811309,"finished":1,"jobset":"master","project":"gnu"},
  ...
]

Then I could add columns to the table with build status icons. I don't
know the Hydra code (or Perl), so I wonder if anyone else has the time
and wants to add the API call.

Thank you,
Roel

Re: Adding build status to the package list table

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

> I've attached a patch that adds status icons to the links in the
> expanded view. It only loads when the user clicks on "expand".

This is great!

Minor things: I would move the patch list above the status, and remove
the “status:” heading.

> We might need to add a HTTP header from the GNU server to allow
> loading data from external sources:
>
>   https://en.wikipedia.org/wiki/Cross-origin_resource_sharing

Indeed, because here the requests get blocked.  Could you get in touch
with webmasters@gnu.org and report back?

> I hope my commit message is OK this way.

It’s almost perfect.  ;-)  The only missing bits are the changes to
packages.css that are not mentioned, and the added files that must be
listed.

> For fetching all statuses in one API call, I would like to propose
> adding a function to Hydra that can return the status in an array like
> the following JSON code:
>
> [
>   {"timestamp":1447890755,"buildstatus":0,"job":"a2ps-4.14.x86_64-linux","jobset":"master","project":"gnu","system":"x86_64-linux","nixname":"a2ps-4.14","finished":1,"id":812555},
>   {"finished":1,"id":811961,"system":"i686-linux","nixname":"a2ps-4.14","project":"gnu","jobset":"master","job":"a2ps-4.14.i686-linux","timestamp":1447890647,"buildstatus":0},
>   {"timestamp":1447890485,"buildstatus":0,"job":"a2ps-4.14.armhf-linux","nixname":"a2ps-4.14","system":"armhf-linux","id":811309,"finished":1,"jobset":"master","project":"gnu"},
>   ...
> ]
>
> Then I could add columns to the table with build status icons. I don't
> know the Hydra code (or Perl), so I wonder if anyone else has the time
> and wants to add the API call.

I’d rather avoid hacking it, to be honest ;-), but I don’t mind if
someone else does, of course.

Thank you!

Ludo’.

Re: Adding build status to the package list table

[Roel Janssen]

Ludovic Courtès writes:

> Roel Janssen <roel@gnu.org> skribis:
>
>> I've attached a patch that adds status icons to the links in the
>> expanded view. It only loads when the user clicks on "expand".
>
> This is great!
>
> Minor things: I would move the patch list above the status, and remove
> the “status:” heading.

I'll update the patch.

>> We might need to add a HTTP header from the GNU server to allow
>> loading data from external sources:
>>
>>   https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
>
> Indeed, because here the requests get blocked.  Could you get in touch
> with webmasters@gnu.org and report back?

I've contacted them, but haven't had a response. I'll report back when I
have a response.

>> I hope my commit message is OK this way.
>
> It’s almost perfect.  ;-)  The only missing bits are the changes to
> packages.css that are not mentioned, and the added files that must be
> listed.

I'll update the patch.

Thanks,
Roel

Re: Adding build status to the package list table

[Roel Janssen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: 0001-website-packages-Add-build-status-icons-in-the-expan.patch --]
[-- Type: text/x-patch, Size: 14654 bytes --]

From 738c4035b3f8978622e96c83c9bd7b9679ce747c Mon Sep 17 00:00:00 2001
From: Roel Janssen <roel@gnu.org>
Date: Mon, 4 Jan 2016 21:05:02 +0100
Subject: [PATCH] website: packages: Add build status icons in the expanded
 view.

* website/www/packages.scm (package->sxml): Wrap the build status link in a div
  and prepend an icon to the div.
* website/static/base/js/packages.js (show_hide): Fetch build status on expand.
* website/static/base/css/packages.css (img.status-icon): Added css for icon padding.
* website/static/base/img/status-icons/0.png: Add icon.
* website/static/base/img/status-icons/1.png: Add icon.
* website/static/base/img/status-icons/2.png: Add icon.
* website/static/base/img/status-icons/3.png: Add icon.
* website/static/base/img/status-icons/4.png: Add icon.
* website/static/base/img/status-icons/5.png: Add icon.
* website/static/base/img/status-icons/undefined.png: Add icon.
---
 website/static/base/css/packages.css               |   5 +++-
 website/static/base/img/status-icons/0.png         | Bin 0 -> 821 bytes
 website/static/base/img/status-icons/1.png         | Bin 0 -> 732 bytes
 website/static/base/img/status-icons/2.png         | Bin 0 -> 777 bytes
 website/static/base/img/status-icons/3.png         | Bin 0 -> 736 bytes
 website/static/base/img/status-icons/4.png         | Bin 0 -> 753 bytes
 website/static/base/img/status-icons/5.png         | Bin 0 -> 777 bytes
 website/static/base/img/status-icons/undefined.png | Bin 0 -> 746 bytes
 website/static/base/js/packages.js                 |  27 +++++++++++++++++++++
 website/www/packages.scm                           |  15 ++++++++----
 10 files changed, 41 insertions(+), 6 deletions(-)
 create mode 100644 website/static/base/img/status-icons/0.png
 create mode 100644 website/static/base/img/status-icons/1.png
 create mode 100644 website/static/base/img/status-icons/2.png
 create mode 100644 website/static/base/img/status-icons/3.png
 create mode 100644 website/static/base/img/status-icons/4.png
 create mode 100644 website/static/base/img/status-icons/5.png
 create mode 100644 website/static/base/img/status-icons/undefined.png

diff --git a/website/static/base/css/packages.css b/website/static/base/css/packages.css
index d9771be..97d0345 100644
--- a/website/static/base/css/packages.css
+++ b/website/static/base/css/packages.css
@@ -61,4 +61,7 @@ a#top {
 a#top:hover, a#top:focus {
     background-color:#333;
     color:#fff;
-}
\ No newline at end of file
+}
+img.status-icon {
+    padding-right: 1em;
+}
diff --git a/website/static/base/img/status-icons/0.png b/website/static/base/img/status-icons/0.png
new file mode 100644
index 0000000000000000000000000000000000000000..3940d8c499c1867d5de7cc2608b5829683bea8ac
GIT binary patch
literal 821
zcmV-51Iqk~P)<h;3K|Lk000e1NJLTq000mG000mO1^@s6AM^iV00001b5ch_0Itp)
z=>Px#24YJ`L;(K){{a7>y{D4^000SaNLh0L01FcU01FcV0GgZ_00007bV*G`2ipq}
z5eooq^e|2U00Om1L_t(I%YBkfXdP7)$A9O}+?jckycm-vY74g6SWRAP#DxaL>c;M*
zpf0o})LKZ@Qd?+OD)_NbyQvG2qDVhnxN+k`M7oXON@9~f(^5Aj&=0Me#3XNK?!Cvw
zdr4`l9{9t7bMEi_;r@mHsQyp-hk9#$!$u@rUA!{0bZBY*-}Yp!89CM9{GM4x&pf>A
z@lE5$8yiLkda}Dvl*M9!i@(oZo|>O}?cBulw-0==m5Z-jxCvN){N>o!jg5~y_lK<L
zuf@C+coZekh%L#zIzU}6T%GxJdiPJS-|67==&>rdN2{8}*AiS}AvWzL7to?bv|5m_
zDp9LC+?<&C7(hl&H4v|ZF1OdpdP<eI<ugmLZGbNe-W`0I9-r{e^oLqoc9Q(nO3%GI
zSDN#CW(l!*BiI<9SX`Fia!c8rQubuD>M1+#dxnD>Uu3-hQAkq>HpX?ulK=)lBY85!
zh7cPnE4b9+a!b)&V_WY-oV@1<H~b<`H}|79BE&`!vwa;P$lZwGC9rSsS+;kNQAEl>
z*3S?1_wWQByL^CP1QkF;ROkbU0TjK4>ToWpd~p8(08XrY&-2MRg7C!kqx@MeU_(Fx
zpg~2sa?^niXT=3^MZxADcQCay&Hj7`8%z(oe*1{#!X-@Mh)Rz*k8wc=;q1tnZS8Mt
ze7-evUD;|?&$P-@S*Qi}ZF+&ew3lPozasHM+^UFIN|NP5?cXh(d+F!smK+S99-Z`A
ze4@-OK8|oU!W)Pr!uWtG9g*{zv?__pYG-p|_M2M(9mrb_dEYI24W$aYHc?DsH10AI
z8z!3*GoRg&#Pvj;92s*e$JOgo>e>W}1c~|1pa*~1+q}g8lrfo!JAE|t_R#Q_H#a}H
zel3xxb5w43AV36IAO&h2t-&f_wW9)XfCuy+W?2{|woAuj00000NkvXXu0mjf(}aDt

literal 0
HcmV?d00001

diff --git a/website/static/base/img/status-icons/1.png b/website/static/base/img/status-icons/1.png
new file mode 100644
index 0000000000000000000000000000000000000000..74e9c24557c30fd12a6e66ce8f1efc3d67af234f
GIT binary patch
literal 732
zcmV<20wev2P)<h;3K|Lk000e1NJLTq000mG000mO1^@s6AM^iV00001b5ch_0Itp)
z=>Px#24YJ`L;(K){{a7>y{D4^000SaNLh0L01FcU01FcV0GgZ_00007bV*G`2ipq}
z5eYDP8)9Gp00LY|L_t(I%YBkhNK{c2#((#|``-L%Msg$<uCf-1Gbt2gB2f_0E{GO^
zi-Hy@g)UmO3L>IKi%42jxCnx9<)TH4Kw4Rw7M3}hpd0O<5&h9oXWqQ`?rHI66tnu^
zz=iMJ@0|0Uqxc6Vpw)$Tz*b@EAbk8=o~l2JKmjNkr#E}z_)xm*&@QJb2O@;ue^8lx
z_n|cQ;!=KX{aG>FK%um<DNz4B?U~Wck*+hU{8Pe(Sw(13fM|to*&{SGtM%7!?zgX1
zE^qHZbK9i3>ZZV?!AXENF=s=Fd<fPctUy@iN+IGdfGWm0%}$c9ZWg=@I0lj(ZP-t<
zV8O}vP#%9p7(uX#1S_b(C(!{_T>#JwY7a~T92a)pdO&XUJ*n;<cAPp(<D-`}-g%61
z!AYRB2aZGkhLbaf@%bFG*ou7VM3yfc5D^ivR_a(jw_lbzk;UD}Tn;;97>#SkPBfxo
zN3;ezH$ipe2B_E~|K3IH!c?5CK`9i9+@^rAgdo`1F!$tnyx!|b)dw4q7#v0yjzR=j
z5Q`uzZ3u`kW&>0dLR100uN#21{!Ug04##sgwG#Re1z<yzSjLK~w#K)R^b(Z4EaGNR
z#(=lC1%7>w8+5Y--%5mjyoG8BY4>rq+`+V_&q?u6r+_3F7nA`6Yy?pi#7FEp%2qg?
zw>;e<05I)vEi~L*)rhZ9A|QZP;0cnkC^w)lZyDZpiFHgWI&l~Z6vx6EYXpq&T!##F
zz&!tfPDAa0aYms13AEM8BsjIA>dy`oG3f#cAXSUHSOAoPN-aX-rOI!a(edPD>Lcy|
O0000<MNUMnLSTZibUPFP

literal 0
HcmV?d00001

diff --git a/website/static/base/img/status-icons/2.png b/website/static/base/img/status-icons/2.png
new file mode 100644
index 0000000000000000000000000000000000000000..7f9534472ef236d718d71627c233d8f9f7172ee1
GIT binary patch
literal 777
zcmV+k1NQuhP)<h;3K|Lk000e1NJLTq000mG000mO1^@s6AM^iV00001b5ch_0Itp)
z=>Px#24YJ`L;(K){{a7>y{D4^000SaNLh0L01FcU01FcV0GgZ_00007bV*G`2ipq}
z5eXC9d=nA?00N0gL_t(I%YBngNK{c2fWP~m&#^Z;)+Cw^R%U-%Bt@YMQAs!bxTqk)
zl%RqZ?pg#vv?vJL<RWkpxCqOQ5z%5GEf5P!Xb}#AAQ6g*<L`{qyqS6P?z=5!Ml{F+
z=ib9T=Y02Y?>U11$eAjt4wq9a1n%@aq48hLv7K}@W%iqA=?Fe4UtA2fDCcXtN{?Ms
zOTk7p@+>gheV&T|-52zYJdsNt7=>GHyt&b)Us;TK)X!N<B-5Y(LxX)4h6?zl82sY)
z_6F(R0s!c2;c2nSJ)a5wLhu$qeqIJ(J76VY^$)CD5Vg4bYJ?sD(a{7_Qd(pZE-i)<
z9~60DZ}lPU$TUhpQJ|jb&^WOaEU%-MqKMTvp0{JzdT0htR&&4DOOwA4c6y<;>p7>d
z_9MeXlpSc`)b$}s$|{+ic#m`uwgZmC^27||8h|cnHuAue4`u-@h57)fx%QcZ?Sp_~
z{(BEz6Fdgw8z^0;2|xo78oP82G!1kO5{o|we|wm7^ZV0nQY(|>Vl;se0{;d;DHf!Q
za$Rs7C^_CmS;HfgOn{pv(AtML(1;^Jx*%PYQY>r$q-5AmBN8^mlVI+t2O#vaj>*><
z8?%Z;5>htUX@ryvceZ4|@lpc?{vr~kKGbd>!smhVKpAc_i~?L?va)6oiNi_^wG>75
zeMAQ`%hVjsu}T(PMZ2pYC1E`lCuTv!g5^k>wKzoMsHlaoQd|zrFtw$T0J@raU>H2k
zzK2koe40S%8p4s>=^x=m?p)stn3!SoNCodSK@G5fbGs_V2ixJ?z$nAp&6Jj>k(YzF
z)lu7ef}<O^Y3Ny=_;(gWwi*NQ06VgpgQbB4kj$zBNI?Aspg;nIJS#=r00000NkvXX
Hu0mjfD62|e

literal 0
HcmV?d00001

diff --git a/website/static/base/img/status-icons/3.png b/website/static/base/img/status-icons/3.png
new file mode 100644
index 0000000000000000000000000000000000000000..6405a3ab3a4972cc05901bc318e887632bc698a7
GIT binary patch
literal 736
zcmV<60w4W}P)<h;3K|Lk000e1NJLTq000mG000mO1^@s6AM^iV00001b5ch_0Itp)
z=>Px#24YJ`L;(K){{a7>y{D4^000SaNLh0L01FcU01FcV0GgZ_00007bV*G`2ipq}
z5jhfbJr#EV00Ll1L_t(I%YBkfNK{c6hM#lJow@VVm>L=7N@<~^ViKgHX@PB9)FKL^
zMNrb;BB)gm(JBaXRbh)LB3iU;5sYn8A?QcS(IVRwqJ)M`(_HV|d%hNTR7mTC4-VhY
z`@V<oRs16+cGBQ%Aq&`Gk;#r3zHKz8Rv!6YXdQ!mzd4ra92iP9@7ZdqYe6i*(jwl>
zhp&a#BWGH2rDszIGPL9hYXB?D)BDZSbVv7L6)Z^b{j*XMf`FhfwT(ieP8IVLx3f9#
z>^cQgecW);Tz1mnq`|nLV^PnRAzX%_7-jhv7h6ZU1)%c1AOUsGCg$UtAyx&B3vOc*
zvh)cNFxz|Z^5X<P_&<^I63Sn|ZJ)r`tz)2LTrdeR$%wi7_#J95eI%LfA>Da|nsZ}R
zpL~FcgOfmM7n}@(02%;8zjh+YCJE)qdjO=4j*>k11OWfdO-!;f;~>h=w+f&XHE2)@
zlm<Kh4*%7)r~oXFoI(~RQM$6BQ7CHH6bN&Kh*+=z#M({}@4AYF9!Q8gFpR11M=W4L
zEP^n%3Scd{FhJQd*b?Y%-2fEt@1ppyE8<8s5PD#Juw|5l<feNoXPn$k!l|JYuR>x~
zDC2@#zXS1RBOj;?!H)t#Y4r-y`~m~u0JOcuo7&4@xyaoR&@L=5&!QYazy<}Z58@&A
zH!Acww9ZHsGhGQCt`|UjixOGu#Wj*qC@0`_%S(ng1ORy7OFNpOK(Q}~1P}v^@LYwQ
zZy)Ci{|TMa(YFBexQ*<iHkwwN35}_cs=pN|z*NXwAX&*3urg2ryh;W@2*@9rOzSdr
S7VOsm0000<MNUMnLSTYk-#HQh

literal 0
HcmV?d00001

diff --git a/website/static/base/img/status-icons/4.png b/website/static/base/img/status-icons/4.png
new file mode 100644
index 0000000000000000000000000000000000000000..6b6fca4619ca2cb3537b7fc629e15cfda9e170af
GIT binary patch
literal 753
zcmV<N0uKF&P)<h;3K|Lk000e1NJLTq000mG000mO1^@s6AM^iV00001b5ch_0Itp)
z=>Px#24YJ`L;(K){{a7>y{D4^000SaNLh0L01FcU01FcV0GgZ_00007bV*G`2iyf2
z0U`zi%4o9y00MDIL_t(I%YD<!Yh6_o2JqiL=bo6iS|5$cz$P&<(m@SGQS8J)VnPK=
z2URS6pd#qhiQ-sC`WIMQArM4ypbk0_9klouRH_AAW2;S|P<yLQ8clBQd29zak&uE5
zHhb;G`q=AR-&$<5SKC{6Kf5N`H_7w^^uw`^WP7^W_CUSi;Af))$M^0Y>)FxWNfq6^
zwe0NWg=;5%UVI6sw&sVek0Wiqc&$5mb}?;>^Yunp%UbcQV5qki2h%Fd{#~8;py}mJ
zOuFg3n0c=^IQDxHHS;3e*~UFJ?n-EH<7QEXpYkYYd^E9izViKl6&y(P-d(eNU&6hC
zt~GXzkI64z6eB$oPx$5Q@BGujjmY(i#UT4~U6DY0>dj7KcM!WvranAr`iBdK#ve2K
z%#5eM`qsXW=5!TwC3NEc%Ih!GHYzxrIlVKncV|Lhjlq#IPo2FWmZgxkSf1YVuq#*Q
z{gHDma=rA)Z0=yP!J{_`Vj4&z`TRv!-+qIT5Tk`x4l5RZl~$yIq=o6D<%>bRB$SZ?
zz55Rsc;|hw*`TUCczjmJqZ0}gkt&Lj-yk`fQAMZLD;ij7uw&{uaPILvetdFwOQyjg
zt0fKMI-%s7=Qn#W6J&jv=B5fgYxEBfi1n+WDY2ASmT)7A^-4I|Y++NlMD<8w0sCX1
znQ?1n#Y$wU<j)xW6~!gOawV)rGZXDDoy)gP;-So28Sj?FqSf6HB8W+A?n9G9bGf<O
zCK1k8&Wxl!O&Ljo;SdRd5CnX_8cly(IOG59jtymCD)rE0VtC7Mx2@w=3JEf_qhsT2
jtdksTSjD=Q+9mu8Bv<9ht)gHV00000NkvXXu0mjfiH2Nr

literal 0
HcmV?d00001

diff --git a/website/static/base/img/status-icons/5.png b/website/static/base/img/status-icons/5.png
new file mode 100644
index 0000000000000000000000000000000000000000..7f9534472ef236d718d71627c233d8f9f7172ee1
GIT binary patch
literal 777
zcmV+k1NQuhP)<h;3K|Lk000e1NJLTq000mG000mO1^@s6AM^iV00001b5ch_0Itp)
z=>Px#24YJ`L;(K){{a7>y{D4^000SaNLh0L01FcU01FcV0GgZ_00007bV*G`2ipq}
z5eXC9d=nA?00N0gL_t(I%YBngNK{c2fWP~m&#^Z;)+Cw^R%U-%Bt@YMQAs!bxTqk)
zl%RqZ?pg#vv?vJL<RWkpxCqOQ5z%5GEf5P!Xb}#AAQ6g*<L`{qyqS6P?z=5!Ml{F+
z=ib9T=Y02Y?>U11$eAjt4wq9a1n%@aq48hLv7K}@W%iqA=?Fe4UtA2fDCcXtN{?Ms
zOTk7p@+>gheV&T|-52zYJdsNt7=>GHyt&b)Us;TK)X!N<B-5Y(LxX)4h6?zl82sY)
z_6F(R0s!c2;c2nSJ)a5wLhu$qeqIJ(J76VY^$)CD5Vg4bYJ?sD(a{7_Qd(pZE-i)<
z9~60DZ}lPU$TUhpQJ|jb&^WOaEU%-MqKMTvp0{JzdT0htR&&4DOOwA4c6y<;>p7>d
z_9MeXlpSc`)b$}s$|{+ic#m`uwgZmC^27||8h|cnHuAue4`u-@h57)fx%QcZ?Sp_~
z{(BEz6Fdgw8z^0;2|xo78oP82G!1kO5{o|we|wm7^ZV0nQY(|>Vl;se0{;d;DHf!Q
za$Rs7C^_CmS;HfgOn{pv(AtML(1;^Jx*%PYQY>r$q-5AmBN8^mlVI+t2O#vaj>*><
z8?%Z;5>htUX@ryvceZ4|@lpc?{vr~kKGbd>!smhVKpAc_i~?L?va)6oiNi_^wG>75
zeMAQ`%hVjsu}T(PMZ2pYC1E`lCuTv!g5^k>wKzoMsHlaoQd|zrFtw$T0J@raU>H2k
zzK2koe40S%8p4s>=^x=m?p)stn3!SoNCodSK@G5fbGs_V2ixJ?z$nAp&6Jj>k(YzF
z)lu7ef}<O^Y3Ny=_;(gWwi*NQ06VgpgQbB4kj$zBNI?Aspg;nIJS#=r00000NkvXX
Hu0mjfD62|e

literal 0
HcmV?d00001

diff --git a/website/static/base/img/status-icons/undefined.png b/website/static/base/img/status-icons/undefined.png
new file mode 100644
index 0000000000000000000000000000000000000000..1d982e9ca39ac1cd59445ef529e8741e30d9b7ae
GIT binary patch
literal 746
zcmV<G0u}v<P)<h;3K|Lk000e1NJLTq000mG000mO1^@s6AM^iV00001b5ch_0Itp)
z=>Px#24YJ`L;(K){{a7>y{D4^000SaNLh0L01FcU01FcV0GgZ_00007bV*G`2ipq}
z5iuw2S6f^F00L@BL_t(I%YBm1OI1-2$3N%Cz4yH*L>8H31r|iLYGcr*T13l&QWph5
z1t}p>geirag4EYS7e$M}Tve!T3JU5EXjg#{6yYK*w35tU@7;UuIj6;aW*RjxFmvX7
zzw@181pl(DgY{J9b_0%|3!@azPT)NVvEtiu)-wd1&8XtY$wT$EeS0^p+fbd4a2|e?
zVn(NC#$S$oX)U!kK3iWLX8KCg9|TL_TaQQfZQXc$+6w=EE*8#9z$5T%s|tKgfOzxy
z+nw^|V{Lyc=p8N+=G%#K5amDz;AB>l4pIYg8R8No<x6xl^=AY<L*Q%;QGSYi6+{Jy
z@|@mL!$3nF04H9J^Kk5Y1}-mpN(+M0Y(&?oMAF#|N?$~W5QGrr$QKF>G}JL(woE6E
z2m7{Us=^4uP!I$V7Fqx@jZ*DLDv%nqMnw@v-p<hSA!goXQ>ZY?#!?!T_DFF6Kvy<V
zjT9gy2+6z?JpG#D53dE_%)2=(S*_AjfT&(3a7^LcF1!;s2iAg1xjhjx9y{)TS^#gs
zyUg((m|PygyB9bsNYiZFCZ<*z+BQe@ZqFl48BCJZtO1(}oP9}gq@uvY{V3gyPCQBp
zgkW;U@%l%J>BQm|<}zSX29tP<adb2duD*j-!sxEhAxbH{4zLJ7pmF%r;B4x>F#?ku
zrK9o5N&<l1kuL4+^+IXZ2T56o$`v{!Mn`_JutuaxpW{m7y}vJU>7o149_f9bw&tL=
z27purq)I=xo(o(%@sa<SB+ThbtT=yjH?22z{%#b6suGLU3Iw2l0EmEm#h1toP^x$g
cq<{tdFX?&$j<f=7dH?_b07*qoM6N<$f>m@rG5`Po

literal 0
HcmV?d00001

diff --git a/website/static/base/js/packages.js b/website/static/base/js/packages.js
index c8d9fc4..246d828 100644
--- a/website/static/base/js/packages.js
+++ b/website/static/base/js/packages.js
@@ -1,5 +1,27 @@
 /* license: CC0 */
 
+function set_build_status (pkg_string)
+{
+  /* Find the element to put the status icon in. */
+  var pkgIcon = document.getElementById("icon-"+ pkg_string);
+
+  /* Don't bother when the icon doesn't exist. */
+  if (pkgIcon != null)
+  {
+    var xhttp = new XMLHttpRequest();
+    xhttp.onreadystatechange = function() {
+      if (xhttp.readyState == 4 && xhttp.status == 200) {
+
+          /* The API call returns JSON. Parse it, and change the icon's source. */
+          var pkgInfo = JSON.parse(xhttp.responseText);
+          pkgIcon.src = "../static/base/img/status-icons/"+ pkgInfo[0]["buildstatus"] + ".png";
+      }
+    }
+    xhttp.open("GET", "http://hydra.gnu.org/api/latestbuilds?nr=1&project=gnu&jobset=master&job="+ pkg_string, true);
+    xhttp.send();
+  }
+}
+
 function show_hide(idThing)
 {
   if(document.getElementById && document.createTextNode) {
@@ -9,6 +31,11 @@ function show_hide(idThing)
     var thingLink = thing.previousSibling.lastChild.firstChild;
     if (thing) {
       if (thing.style.display == "none") {
+        var column = thing.parentNode;
+        var pkg_icons = column.getElementsByTagName('img')
+        for (var i=0; i < pkg_icons.length; i++) {
+            set_build_status (pkg_icons[i].id.slice(5));
+        }
         thing.style.display = "";
         thingLink.data = 'Collapse';
       } else {
diff --git a/website/www/packages.scm b/website/www/packages.scm
index 6ea974b..69b0623 100644
--- a/website/www/packages.scm
+++ b/website/www/packages.scm
@@ -167,14 +167,18 @@ decreasing, is 1."
 
   (define (status package)
     (define (url system)
-      `(a (@ (href ,(string-append "http://hydra.gnu.org/job/gnu/master/"
+      `(div (img (@ (src ,(image-url "status-icons/undefined.png"))
+                    (id ,(string-append "icon-" (package-full-name package) "." system))
+                    (class "status-icon")
+                    (alt "Unknown")
+                    (title "Unknown")))
+            (a (@ (href ,(string-append "http://hydra.gnu.org/job/gnu/master/"
                                    (package-full-name package) "."
                                    system))
              (title "View the status of this architecture's build at Hydra"))
-          ,system))
+          ,system)))
 
-    `(div "status: "
-          ,(list-join (map url
+    `(div ,(list-join (map url
                            (lset-intersection
                             string=?
                             %hydra-supported-systems
@@ -229,8 +233,9 @@ description-ids as formal parameters."
                     (a (@ (href ,(package-home-page package))
                           (title "Link to the package's website"))
                        ,(package-home-page package))
-                    ,(status package)
                     ,(patches package)
+                    (br)
+                    ,(status package)
                     ,(if js?
                          (insert-js-call description-ids)
                          ""))))))
-- 
2.5.0


[-- Attachment #2: Type: text/plain, Size: 1190 bytes --]


Ludovic Courtès writes:

> Roel Janssen <roel@gnu.org> skribis:
>
>> I've attached a patch that adds status icons to the links in the
>> expanded view. It only loads when the user clicks on "expand".
>
> This is great!
>
> Minor things: I would move the patch list above the status, and remove
> the “status:” heading.

I made these changes.  I inserted a line break between the patch list
and the build status icons because I think that looks a little less
messy.

>> We might need to add a HTTP header from the GNU server to allow
>> loading data from external sources:
>>
>>   https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
>
> Indeed, because here the requests get blocked.  Could you get in touch
> with webmasters@gnu.org and report back?

At last!  I received an e-mail today that the sysadmins made the change
to allow fetching data from hydra.gnu.org.  So now it should work once
it is uploaded to gnu.org.

>> I hope my commit message is OK this way.
>
> It’s almost perfect.  ;-)  The only missing bits are the changes to
> packages.css that are not mentioned, and the added files that must be
> listed.

I hope it's perfect now.

Kind regards,
Roel Janssen

Re: Adding build status to the package list table

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

> Ludovic Courtès writes:
>
>> Roel Janssen <roel@gnu.org> skribis:

[...]

>>> We might need to add a HTTP header from the GNU server to allow
>>> loading data from external sources:
>>>
>>>   https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
>>
>> Indeed, because here the requests get blocked.  Could you get in touch
>> with webmasters@gnu.org and report back?
>
> At last!  I received an e-mail today that the sysadmins made the change
> to allow fetching data from hydra.gnu.org.  So now it should work once
> it is uploaded to gnu.org.

Good!  I applied the patch and deployed the new web page:

  https://www.gnu.org/software/guix/packages/

However, it’s still failing:

  17:00:49.802 Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://hydra.gnu.org/api/latestbuilds?nr=1&project=gnu&jobset=master&job=aspell-dict-es-1.11-2.armhf-linux. (Reason: CORS header 'Access-Control-Allow-Origin' missing).1 <unknown>

Ideas?

Thank you!
Ludo’.

Re: Adding build status to the package list table

[Roel Janssen]

Ludovic Courtès writes:

> Roel Janssen <roel@gnu.org> skribis:
>
>> Ludovic Courtès writes:
>>
>>> Roel Janssen <roel@gnu.org> skribis:
>
> [...]
>
>>>> We might need to add a HTTP header from the GNU server to allow
>>>> loading data from external sources:
>>>>
>>>>   https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
>>>
>>> Indeed, because here the requests get blocked.  Could you get in touch
>>> with webmasters@gnu.org and report back?
>>
>> At last!  I received an e-mail today that the sysadmins made the change
>> to allow fetching data from hydra.gnu.org.  So now it should work once
>> it is uploaded to gnu.org.
>
> Good!  I applied the patch and deployed the new web page:
>
>   https://www.gnu.org/software/guix/packages/
>
> However, it’s still failing:
>
>   17:00:49.802 Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://hydra.gnu.org/api/latestbuilds?nr=1&project=gnu&jobset=master&job=aspell-dict-es-1.11-2.armhf-linux. (Reason: CORS header 'Access-Control-Allow-Origin' missing).1 <unknown>
>
> Ideas?

Yes, I think it only works when the origin is hydra.gnu.org.  I
contacted the sysadmins again to figure this out.  Could you leave the
page there for a couple of days?  That way I can give them a live
example.

Thanks,
Roel

Re: Adding build status to the package list table

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

> Ludovic Courtès writes:
>
>> Roel Janssen <roel@gnu.org> skribis:
>>
>>> Ludovic Courtès writes:
>>>
>>>> Roel Janssen <roel@gnu.org> skribis:
>>
>> [...]
>>
>>>>> We might need to add a HTTP header from the GNU server to allow
>>>>> loading data from external sources:
>>>>>
>>>>>   https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
>>>>
>>>> Indeed, because here the requests get blocked.  Could you get in touch
>>>> with webmasters@gnu.org and report back?
>>>
>>> At last!  I received an e-mail today that the sysadmins made the change
>>> to allow fetching data from hydra.gnu.org.  So now it should work once
>>> it is uploaded to gnu.org.
>>
>> Good!  I applied the patch and deployed the new web page:
>>
>>   https://www.gnu.org/software/guix/packages/
>>
>> However, it’s still failing:
>>
>>   17:00:49.802 Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://hydra.gnu.org/api/latestbuilds?nr=1&project=gnu&jobset=master&job=aspell-dict-es-1.11-2.armhf-linux. (Reason: CORS header 'Access-Control-Allow-Origin' missing).1 <unknown>
>>
>> Ideas?
>
> Yes, I think it only works when the origin is hydra.gnu.org.  I
> contacted the sysadmins again to figure this out.  Could you leave the
> page there for a couple of days?  That way I can give them a live
> example.

Sure.

But indeed, there’s no ‘Access-Control-Allow-Origin’ HTTP header
returned for <https://www.gnu.org/software/guix/packages/>.

Ludo’.

Re: Adding build status to the package list table

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

> Ludovic Courtès writes:

[...]

>> Good!  I applied the patch and deployed the new web page:
>>
>>   https://www.gnu.org/software/guix/packages/
>>
>> However, it’s still failing:
>>
>>   17:00:49.802 Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://hydra.gnu.org/api/latestbuilds?nr=1&project=gnu&jobset=master&job=aspell-dict-es-1.11-2.armhf-linux. (Reason: CORS header 'Access-Control-Allow-Origin' missing).1 <unknown>
>>
>> Ideas?
>
> Yes, I think it only works when the origin is hydra.gnu.org.  I
> contacted the sysadmins again to figure this out.  Could you leave the
> page there for a couple of days?  That way I can give them a live
> example.

Any update on this?

I’m asking because we’ll need something similar to display the contents
of <http://static.fsf.org/nosvn/banners/2015fundraiser/guix-fundraiser-2016.html>
on the page.

Thanks,
Ludo’.

Re: Adding build status to the package list table

[Roel Janssen]

Ludovic Courtès writes:

> Roel Janssen <roel@gnu.org> skribis:
>
>> Ludovic Courtès writes:
>
> [...]
>
>>> Good!  I applied the patch and deployed the new web page:
>>>
>>>   https://www.gnu.org/software/guix/packages/
>>>
>>> However, it’s still failing:
>>>
>>>   17:00:49.802 Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://hydra.gnu.org/api/latestbuilds?nr=1&project=gnu&jobset=master&job=aspell-dict-es-1.11-2.armhf-linux. (Reason: CORS header 'Access-Control-Allow-Origin' missing).1 <unknown>
>>>
>>> Ideas?
>>
>> Yes, I think it only works when the origin is hydra.gnu.org.  I
>> contacted the sysadmins again to figure this out.  Could you leave the
>> page there for a couple of days?  That way I can give them a live
>> example.
>
> Any update on this?

No, but I keep on trying..

> I’m asking because we’ll need something similar to display the contents
> of <http://static.fsf.org/nosvn/banners/2015fundraiser/guix-fundraiser-2016.html>
> on the page.

On my next attempt to get an answer, I'll include the request for
'static.fsf.org'.

Greetings,
Roel

Re: Adding build status to the package list table

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

> Ludovic Courtès writes:
>
>> Roel Janssen <roel@gnu.org> skribis:

[...]

>>> Yes, I think it only works when the origin is hydra.gnu.org.  I
>>> contacted the sysadmins again to figure this out.  Could you leave the
>>> page there for a couple of days?  That way I can give them a live
>>> example.
>>
>> Any update on this?
>
> No, but I keep on trying..

Bah.  :-/

>> I’m asking because we’ll need something similar to display the contents
>> of <http://static.fsf.org/nosvn/banners/2015fundraiser/guix-fundraiser-2016.html>
>> on the page.
>
> On my next attempt to get an answer, I'll include the request for
> 'static.fsf.org'.

Cool.  Maybe you could Cc the list, too.  I think it’s probably fine to
re-ping them now anyway.  :-)

Thanks,
Ludo’.

Re: Adding build status to the package list table

[Roel Janssen]

Ludovic Courtès writes:

> Roel Janssen <roel@gnu.org> skribis:
>
>> Ludovic Courtès writes:
>>
>>> Roel Janssen <roel@gnu.org> skribis:
>>>
>>>> Ludovic Courtès writes:
>>>>
>>>>> Roel Janssen <roel@gnu.org> skribis:
>>>
>>> [...]
>>>
>>>>>> We might need to add a HTTP header from the GNU server to allow
>>>>>> loading data from external sources:
>>>>>>
>>>>>>   https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
>>>>>
>>>>> Indeed, because here the requests get blocked.  Could you get in touch
>>>>> with webmasters@gnu.org and report back?
>>>>
>>>> At last!  I received an e-mail today that the sysadmins made the change
>>>> to allow fetching data from hydra.gnu.org.  So now it should work once
>>>> it is uploaded to gnu.org.
>>>
>>> Good!  I applied the patch and deployed the new web page:
>>>
>>>   https://www.gnu.org/software/guix/packages/
>>>
>>> However, it’s still failing:
>>>
>>>   17:00:49.802 Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://hydra.gnu.org/api/latestbuilds?nr=1&project=gnu&jobset=master&job=aspell-dict-es-1.11-2.armhf-linux. (Reason: CORS header 'Access-Control-Allow-Origin' missing).1 <unknown>
>>>
>>> Ideas?
>>
>> Yes, I think it only works when the origin is hydra.gnu.org.  I
>> contacted the sysadmins again to figure this out.  Could you leave the
>> page there for a couple of days?  That way I can give them a live
>> example.
>
> Sure.
>
> But indeed, there’s no ‘Access-Control-Allow-Origin’ HTTP header
> returned for <https://www.gnu.org/software/guix/packages/>.

I've got a response, and it might be easier than I thought it would be.

We need to add the following line to the response header at
hydra.gnu.org:

  Access-Control-Allow-Origin: "http://www.gnu.org"

Here's how to do it:
  http://enable-cors.org/server_nginx.html

Which boils down to adding this line to the nginx config:
  add_header 'Access-Control-Allow-Origin' 'http://www.gnu.org';

Kind regards,
Roel

Re: Adding build status to the package list table

[Ludovic Courtès]

Roel Janssen <roel@gnu.org> skribis:

> We need to add the following line to the response header at
> hydra.gnu.org:
>
>   Access-Control-Allow-Origin: "http://www.gnu.org"
>
> Here's how to do it:
>   http://enable-cors.org/server_nginx.html
>
> Which boils down to adding this line to the nginx config:
>   add_header 'Access-Control-Allow-Origin' 'http://www.gnu.org';

OK, I’ve done that for /api requests (with the full URI, that is
<https://www.gnu.org/software/guix/packages/> and variants thereof).
Now, when clicking on “Expand”, IceCat no longer complains about CORS,
but it fails to expands and reports this:

  Blocked loading mixed active content
  "http://hydra.gnu.org/api/latestbuilds?nr=1&project=gnu&jobset=master&job=adwaita-icon-theme-3.18.0.x86_64-linux"

with a link to:

  https://developer.mozilla.org/en-US/docs/Security/MixedContent

Ideas?

Ludo’.

Re: Adding build status to the package list table

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> Roel Janssen <roel@gnu.org> skribis:
>
>> We need to add the following line to the response header at
>> hydra.gnu.org:
>>
>>   Access-Control-Allow-Origin: "http://www.gnu.org"
>>
>> Here's how to do it:
>>   http://enable-cors.org/server_nginx.html
>>
>> Which boils down to adding this line to the nginx config:
>>   add_header 'Access-Control-Allow-Origin' 'http://www.gnu.org';
>
> OK, I’ve done that for /api requests (with the full URI, that is
> <https://www.gnu.org/software/guix/packages/> and variants thereof).
> Now, when clicking on “Expand”, IceCat no longer complains about CORS,
> but it fails to expands and reports this:
>
>   Blocked loading mixed active content
>   "http://hydra.gnu.org/api/latestbuilds?nr=1&project=gnu&jobset=master&job=adwaita-icon-theme-3.18.0.x86_64-linux"
>
> with a link to:
>
>   https://developer.mozilla.org/en-US/docs/Security/MixedContent

This is because the current page is encrypted but the content from hydra
is not.  Can we serve hydra.gnu.org/api over HTTPS?

~~ Ricardo

Re: Adding build status to the package list table

[Roel Janssen]

Ricardo Wurmus writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Roel Janssen <roel@gnu.org> skribis:
>>
>>> We need to add the following line to the response header at
>>> hydra.gnu.org:
>>>
>>>   Access-Control-Allow-Origin: "http://www.gnu.org"
>>>
>>> Here's how to do it:
>>>   http://enable-cors.org/server_nginx.html
>>>
>>> Which boils down to adding this line to the nginx config:
>>>   add_header 'Access-Control-Allow-Origin' 'http://www.gnu.org';
>>
>> OK, I’ve done that for /api requests (with the full URI, that is
>> <https://www.gnu.org/software/guix/packages/> and variants thereof).
>> Now, when clicking on “Expand”, IceCat no longer complains about CORS,
>> but it fails to expands and reports this:
>>
>>   Blocked loading mixed active content
>>   "http://hydra.gnu.org/api/latestbuilds?nr=1&project=gnu&jobset=master&job=adwaita-icon-theme-3.18.0.x86_64-linux"
>>
>> with a link to:
>>
>>   https://developer.mozilla.org/en-US/docs/Security/MixedContent
>
> This is because the current page is encrypted but the content from hydra
> is not.  Can we serve hydra.gnu.org/api over HTTPS?

I think that would fix this problem.

However, if I browse explicitly to:
http://gnu.org/software/guix/packages  (the insecure version), I get the 
following error message:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://hydra.gnu.org/api/latestbuilds?nr=1&project=gnu&jobset=master&job=acme-0.2.0.i686-linux. (Reason: CORS header 'Access-Control-Allow-Origin' does not match 'https://www.gnu.org/software/guix/packages, https://www.gnu.org/software/guix/packages/, https://www.gnu.org/software/guix/packages/index.html, https://gnu.org/software/guix/packages/, http://www.gnu.org/software/guix/packages, http://www.gnu.org/software/guix/packages/, http://www.gnu.org/software/guix/packages/index.html, http://gnu.org/software/guix/packages/').

This is because (at least in my browser), the origin is set to
"http://www.gnu.org" instead of the full path.  So could you include
"http://www.gnu.org" in the list as well?

Thanks,
Roel