lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] PATCH: Fix build with gcc11 in C++20 mode


From: Vadim Zeitlin
Subject: Re: [lmi] PATCH: Fix build with gcc11 in C++20 mode
Date: Sat, 23 Oct 2021 14:52:30 +0200

On Fri, 22 Oct 2021 18:39:57 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 10/22/21 4:55 PM, Vadim Zeitlin wrote:
GC> > On Fri, 22 Oct 2021 14:44:18 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
GC> [...]
GC> > GC> I think it's advantageous to continue running CI builds under
GC> > GC> 'unstable', for the reason you gave. Then the question becomes what
GC> > GC> debian release to use in two cases:
GC> > GC>   (1) for production...why not move to 'bookworm'?
GC> > 
GC> >  The only reason I see is that right now we don't need it and stable is,
GC> > well, stable.
GC> 
GC> To me at least, choosing between 'stable' and 'testing' seems to be a
GC> big strategic decision, whereas adhering to 'testing' as it evolves
GC> seems to be a comparatively minor, tactical matter. If we decide now
GC> to keep 'bullseye' for production now that it's 'stable', then changing
GC> back to 'testing' later will be a major undertaking, as it will require
GC> a new chroot.

 OK, let's not do anything about it then. I just wanted to ask if we wanted
to use the time window when stable and testing were identical anyhow to
switch back to the former, but I'm perfectly fine with staying with the
latter too.

GC> I'm guessing that someday we'll want a newer version of some package
GC> and will therefore want 'testing'.

 This certainly looks plausible.


GC> > GC>   (2) for non-unstable CI builds...shouldn't we use the same
GC> > GC>       answer as for (1)? In particular, if we use 'bookworm' for
GC> > GC>       production, why would we want anything older for CI?
GC> > 
GC> >  We wouldn't. But we would almost certainly want to run CI in both 
Bookworm
GC> > and Sid environments, to give us an advance warning of the problems that
GC> > are going to appear in the former, wouldn't we?
GC> 
GC> Yes, that sounds ideal.

 OK, I've added this to my short-term TODO list. One CI-related thing I'd
like to do first is to start using ccache for lmi builds: it's pretty
wasteful to keep rebuilding the same files even if they don't change and it
means the CI builds take a rather long time. I've already started
experimenting with this, but, somehow, ccache doesn't seem to used there
(even though the cache is explicitly preserved and restored between the
runs), so I have to debug it further. This is also a bit wasteful, as I'd
rather spend time on something more useful, but I think I'll save more time
by making ccache work first, i.e. before adding more CI builds, just
because the wait for the results of these builds will be much shorter.

 Any ccache-related changes shouldn't affect anything except for the
CI-specific files, so this is purely informative and doesn't require any
action on your part.

 Regards,
VZ

Attachment: pgpbYfPmpSGvi.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]