Hi Niels,
Am Sun, Jan 05, 2025 at 12:40:54PM +0100 schrieb Niels Thykier:
> The "I'll do the job until the second someone else shows up" sounds close to
> RFA (Request For Adoption).
>
> Maybe we can do with a variant like OFA (Open For Adoption), which does not
> have the "lingering ownership" t
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.
Hi,
> Gioele Barabucci:
> We need different levels of responsibility:
>
> * Nobody cares ⇒ orphan package
> * I care a bit, but I don't have time to handle all the responsibilities
> that a maintainership entail, but try to contact me anyway, I may reply
> ⇒ MISSING LEVEL discussed here
> * I care
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
Hi!
On Sun, 2025-01-05 at 19:37:44 +0100, Santiago Vila wrote:
> El 5/1/25 a las 19:15, Guillem Jover escribió:
> > I think this indicates a problem in the upstream autotools support,
> > and it might be better to try to fix that instead of adding what seems
> > like a workaround that might end up
El 5/1/25 a las 19:15, Guillem Jover escribió:
I think this indicates a problem in the upstream autotools support,
and it might be better to try to fix that instead of adding what seems
like a workaround that might end up causing problems too due to the
(silenced) version mismatch.
I already di
Hi!
On Sun, 2025-01-05 at 17:44:33 +0100, Santiago Vila wrote:
> I've just uploaded gettext 0.23.1-0.1 for experimental.
Ah, great, thanks!
> In most cases, the failure is like this:
>
> make[3]: Entering directory '/<>/po'
> *** error: gettext infrastructure mismatch: using a Makefile.in.in fr
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
Greetings.
I've just uploaded gettext 0.23.1-0.1 for experimental.
[ This is preliminary, don't worry for the changelog, there will be a
proper one in unstable. Also please don't close any bugs yet, I want
to close them in unstable ].
There is a list of upstream changes here:
https://savannah.
On 2025-01-05 08:07, Drew Parsons wrote:
On 2025-01-05 08:39, Alastair McKinstry wrote:
Hi,
I am thinking about re-instating mpi-testsuite, last in the archive in
2018.
Any thoughts?
Alastair
I'd say it's a good idea. mpi4py has sort of been serving in the role
of a test suite,
but it
Niels Thykier:
Marc Haber:
On Sat, 21 Dec 2024 22:23:19 +0100, Gioele Barabucci
wrote:
This branch of the discussion started by pointing out the fact that some
maintainers _do_ in fact orphan their packages to remove the "feeling of
being responsible", and then go on maintaining these packages
Marc Haber:
On Sat, 21 Dec 2024 22:23:19 +0100, Gioele Barabucci
wrote:
This branch of the discussion started by pointing out the fact that some
maintainers _do_ in fact orphan their packages to remove the "feeling of
being responsible", and then go on maintaining these packages.
Its a way to
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: python-advanced-alchemy
Version : 0.26.2
Upstream Contact: Litestar Developers
* URL : https://github.com/litestar-org/advanced-alchemy
* License
* Theodore Ts'o:
> On Thu, Dec 26, 2024 at 01:19:34PM -0500, Michael Stone wrote:
>> Further reading: look at the auto_da_alloc option in ext4. Note that it says
>> that doing the rename without the sync is wrong, but there's now a heuristic
>> in ext4 that tries to insert an implicit sync when th
20 matches
Mail list logo
