time-bomb and CI? (was bug#69800: kcalendarcore time-bomb)

time-bomb and CI? (was bug#69800: kcalendarcore time-bomb)

[Simon Tournier]

Hi,

Reading this message [1]:

-------------------- Start of forwarded message --------------------
Subject: bug#69800: kcalendarcore is a time bomb
To: 69800@debbugs.gnu.org
Date: Thu, 14 Mar 2024 20:20:43 +0100
From:  Vivien Kraus via Bug reports for GNU Guix <bug-guix@gnu.org>

Dear Guix,

Kcalendarcore does not build anymore. According to CI, it stopped
working this march, on gnome-team and rust-branch (I can’t build it
either on master).

http://ci.guix.gnu.org/search?query=kcalendarcore

Best regards,

Vivien
-------------------- End of forwarded message --------------------

and this fix:

        * gnu/packages/kde-frameworks.scm (kcalendarcore) [#:phases]: Add
        'disable-failing-test.

My question is: Could we automatically detect by CI such time-related
test?


Other said, would it be possible to have one (or more) node that build
with a date in the future?  Say 3 years.  In Bordeaux?  Or in Berlin?
Using the “Dolorean VM” [2], it could be nice to setup one node.

Some packages would be build by this node.  Somehow, it means some
random-selected packages would be built in the future.  All in all and
considering the rate of building, it would help us to detect problematic
packages.  And fix them now avoid to break “guix time-machine” in the
future.

Well, I am trying to have a more systematic approach here at work – bah
not sure it will see the light –, so still awaiting, having one node in
the future would help, IMHO.

WDYT?

Cheers,
simon

PS: Do we speak about bug of year 2038? ;-)

1: bug#69800: kcalendarcore is a time bomb
Vivien Kraus via Bug reports for GNU Guix <bug-guix@gnu.org>
Thu, 14 Mar 2024 20:20:43 +0100
id:994ee26ab0444037bcc93ee91af18e5a0b389c33.camel@planete-kraus.eu
https://issues.guix.gnu.org/69800
https://issues.guix.gnu.org/msgid/994ee26ab0444037bcc93ee91af18e5a0b389c33.camel@planete-kraus.eu
https://yhetil.org/guix/994ee26ab0444037bcc93ee91af18e5a0b389c33.camel@planete-kraus.eu

2:
https://guix.gnu.org/en/blog/2024/adventures-on-the-quest-for-long-term-reproducible-deployment

Re: time-bomb and CI? (was bug#69800: kcalendarcore time-bomb)

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]

On 2024-05-06, Simon Tournier wrote:
> -------------------- Start of forwarded message --------------------
> Subject: bug#69800: kcalendarcore is a time bomb
> To: 69800@debbugs.gnu.org
> Date: Thu, 14 Mar 2024 20:20:43 +0100
> From:  Vivien Kraus via Bug reports for GNU Guix <bug-guix@gnu.org>
>
> Dear Guix,
>
> Kcalendarcore does not build anymore. According to CI, it stopped
> working this march, on gnome-team and rust-branch (I can’t build it
> either on master).
>
> http://ci.guix.gnu.org/search?query=kcalendarcore
>
> Best regards,
>
> Vivien
> -------------------- End of forwarded message --------------------
>
> and this fix:
>
>         * gnu/packages/kde-frameworks.scm (kcalendarcore) [#:phases]: Add
>         'disable-failing-test.
>
> My question is: Could we automatically detect by CI such time-related
> test?
>
>
> Other said, would it be possible to have one (or more) node that build
> with a date in the future?  Say 3 years.  In Bordeaux?  Or in Berlin?
> Using the “Dolorean VM” [2], it could be nice to setup one node.

This would also be good for checking reproducible builds, as time is one
of the harder things to normalize in the guix (or any) build
environment!

I would recommend using some padded days, e.g. 3 x 365 days + 31 days +
1 day (leap years) + 1 day (for good measure), as this maximises the
chance that embedded day, month and year will always be different.


> PS: Do we speak about bug of year 2038? ;-)

Either speak now or wait for the inevitible! :)


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: time-bomb and CI? (was bug#69800: kcalendarcore time-bomb)

[Ludovic Courtès]

Hi,

Simon Tournier <zimon.toutoune@gmail.com> skribis:

> Other said, would it be possible to have one (or more) node that build
> with a date in the future?  Say 3 years.  In Bordeaux?  Or in Berlin?
> Using the “Dolorean VM” [2], it could be nice to setup one node.

[...]

> https://guix.gnu.org/en/blog/2024/adventures-on-the-quest-for-long-term-reproducible-deployment

Yes!

As I wrote in the blog post above, I think the best way to help get
there is to work on optimizing the ‘virtual-build-machine’ service a
bit, along the lines noted in the blog post above (SSH over AF_VSOCK,
guest store overlaid over the host store itself mounted as virtiofs,
etc.).

The second best way is to propose a patch against maintenance.git adding
‘virtual-build-machine’ services to some of the build machines (similar
to how we add childhurds to some of them) so we can start experimenting.
It’ll be kinda random—some builds will be offloaded to the VMs, some
won’t—but it’s a start.

Ludo’.