El 20/3/25 a las 15:29, Jeremy Bícha escribió:
Thank you for this wonderful project and for raising the severity to
serious since it's clearly easier to fix the bugs in Unstable now
rather than as Stable Updates later.
Thanks go to the Release Managers, more specifically Paul Gevers,
who allowe
On Sun, Jan 5, 2025 at 11:56 AM Santiago Vila wrote:
> This is an update for my previous MBF announcement here:
Thank you for this wonderful project and for raising the severity to
serious since it's clearly easier to fix the bugs in Unstable now
rather than as Stable Updates later.
I think your
On Sun, Jan 05, 2025 at 11:58:40PM +0100, Chris Hofstaedtler wrote:
> Maybe you can consider using a time namespace (unshare -T) and
> change the system date/time in that namespace.
As those jobs already run in throw away VM, just change the system time.
You have to change it back to be able to ta
El 15/2/25 a las 10:44, Paul Gevers escribió:
Can the Release Managers suggest a calendar for raising those bugs,
first to important, then to serious?
What I had in mind was that you'd file the bugs and after some time (say, one
or two months) raised them, giving maintainers a bit more time th
Hi Santiago
Sorry for dropping the ball on this.
On 05-01-2025 17:56, Santiago Vila wrote:
I was told that it was ok to consider those bugs as "RC for trixie"
but I was also requested to be nice when reporting those bugs, so I have
been reporting them as severity:normal (except when the future
* Chris Hofstaedtler , 2025-01-05 23:58:
Maybe you can consider using a time namespace (unshare -T) and change
the system date/time in that namespace.
I don't think that would work. From time_namespaces(7):
"Note that time namespaces do not virtualize the CLOCK_REALTIME clock.
Virtualization
On Sun, 05 Jan 2025 at 23:58:40 +0100, Chris Hofstaedtler wrote:
> as we've seen in the time_t-64 transition, programs that interpose
> library calls like this are extremely hard to get right and very
> brittle.
>
> I would strongly suggest to not put new load-bearing stuff on top of
> such a prog
On Sun, Jan 05, 2025 at 11:58:40PM +0100, Chris Hofstaedtler wrote:
> Maybe you can consider using a time namespace (unshare -T) and
> change the system date/time in that namespace.
I'd also strongly suggest to do a full archive rebuild in such namespace
comparing that with a full archive rebuild
[ moving technical discussion to -devel, as -release was
just to ask RM for a calendar to raise severities ]
[ Bcc to Holger on this one ]
El 5/1/25 a las 23:59, Holger Levsen escribió:
so what did you use?
I still change the system clock. So, the same you did.
On Sun, Jan 05, 2025 at 09:28:24PM +0100, Santiago Vila wrote:
> > Did you use libfaketime in this round of rebuilds?
> No, I did not use libfaketime yet (sorry).
so what did you use?
setting the system time to the future (like we've been doing for
tests.reproducible-builds.org/debian for many
Hi,
* Otto Kekäläinen [250105 21:54]:
> Thanks for encouragement. I filed
> https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/411 and will
> continue research on libfaketime/datefudge in CI there.
as we've seen in the time_t-64 transition, programs that interpose
library calls like this a
El 5/1/25 a las 21:07, Otto Kekäläinen escribió:
This is an update for my previous MBF announcement here:
https://lists.debian.org/debian-devel/2024/05/msg00414.html
I did another test rebuild and found 11 new packages failing
in the not-so-distant future. I also found another package
for which
Thanks for encouragement. I filed
https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/411 and will
continue research on libfaketime/datefudge in CI there.
Em 5 de janeiro de 2025 15:28:24 GMT-05:00, Santiago Vila
escreveu:
>El 5/1/25 a las 21:07, Otto Kekäläinen escribió:
>>> This is an update for my previous MBF announcement here:
>>>
>>> https://lists.debian.org/debian-devel/2024/05/msg00414.html
>>>
>>> I did another test rebuild and found
Hi!
> This is an update for my previous MBF announcement here:
>
> https://lists.debian.org/debian-devel/2024/05/msg00414.html
>
> I did another test rebuild and found 11 new packages failing
> in the not-so-distant future. I also found another package
> for which the fix was lost and the bug had
Hello.
This is an update for my previous MBF announcement here:
https://lists.debian.org/debian-devel/2024/05/msg00414.html
I did another test rebuild and found 11 new packages failing
in the not-so-distant future. I also found another package
for which the fix was lost and the bug had to reope
16 matches
Mail list logo
