Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
+++ Russ Allbery [2012-10-08 12:32 -0700]: > Bob Friesenhahn writes: > > > Does simple replacement of config.guess and config.sub constitute a > > useful "port" to this previously unencountered target? > > Believe it or not, yes, frequently it does. > Note that this is specifically in the context of Debian, which means that > all of these platforms are Linux and they're all using glibc. Indeed. In more than 90% of cases this is all that was required, assuming the package cross-built at all (currently everything is cross-built as there is no actual arm64 hardware anywhere). yes, a proper autoreconf is better for lots of reasons but it doesn't really make any difference for our purposes. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Global autoconf cache
+++ Thomas Petazzoni [2012-11-19 15:49 +0100]: > In Buildroot [1], we had support to use an autoconf cache to speed up > the build. This autoconf cache was shared amongst packages, with the > idea that once a package has verified that such or such system feature > was available or not, it would be written in the cache, and subsequent > packages to be built would not have to do those tests again. > > Unfortunately, we ran into several corner cases where some packages > were using the same autoconf variable name for tests that were mostly > the same, but not exactly, leading to the autoconf cache having a nasty > effect on the build of certain packages, if other packages built before > had "poisoned" the cache with somewhat invalid values. Is this the same cache as that specified by CONFIG_SITE? Debian uses this mechanism to supply config variables unavailable when cross-compiling. Almost all the results are wrapped in if [ "$PACKAGE" = "foo" -o "$PACKAGE_NAME" = "foo" ]; to avoid exactly this poisoning/difference between packages issue. But nearly all the time it is not necessary, and means supplying the same variable in many, many places. If you had any data on which variable/packages were problematic, that would help us streamline this system. I noticed whilst looking into this that autoconf can read this from a default location without setting SITE_CONFIG. I would like to expand this to read the file only when cross-compiling, and to read it from a HOST-arch specific location. Thereby generalising the currently debian-specific mechanism. Is that something that would be of interest upstream - or is there a way to achieve this already (because the file is just a script so maybe it could determine the BUILD and HOST arches itself then read the appropriate thing if needed). Are the variables for configured BUILD and HOST arch available at the time this script is read in? I suppose I should just try this. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
+++ Thomas Petazzoni [2013-05-15 16:30 +0200]: > Hello, > > On Tue, 14 May 2013 23:53:44 -0400, Mike Frysinger wrote: > > > yes, Gentoo fixed this for every package in our tree like 9 years ago > > (we added a common function like 11 years ago that ebuilds could call > > manually, but we found that didn't scale). when you run a standard > > autoconf script, we automatically search for files named "config.sub" > > and "config.guess" and replace them with the up-to-date host copy. > > no checking or anything :). in hindsight, that seems like a bad > > idea, but in practice, i think we have yet to find a package that > > this doesn't actually work. > > FWIW, we do the same thing in Buildroot (a tool that builds embedded > Linux systems from source, through cross-compilation). Never had any > problem doing so. Same story in OpenEmbedded. Given the widespread positive experience with this process, at least in Linux distros, can those who think that defaulting to using 'current' versions is a bad idea produce any examples of genuine problems large enough to counter the fairly major issue of updating hundreds of these files for new architectures. Perhaps there are non-linux arches where lots of things would break? There have been some theoretical or obscure issues brought up so far in this thread, and some history, but I haven't seen much that looks like a good enough reason not to default to use current unless configured not to (which anyone shipping a 'special' config.sub/guess can use. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
+++ Eric Blake [2013-05-20 09:11 -0600]: > On 05/20/2013 09:01 AM, Paul Wise wrote: > > On Mon, 2013-05-20 at 08:37 -0600, Eric Blake wrote: > > > >> I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB > >> environment variable, rather than baking in a PATH search. This topic > >> has come up in the past, where I made the same request back then. > > > > The patch does both and both are needed AFAICT. > > I disagree. Env-var override should be sufficient, without needing any > PATH probing. The problem with this in the context of distro buildds was explained in this sub-part of the thread from Oct last year: http://article.gmane.org/gmane.comp.sysutils.autoconf.general/14756 ENV VARS are carefully filtered out of buildd environments in order to get clean builds. We really want a mechanism where the distro default build just looks in the right (system) place, unless you ask for something different. Now it probably is possible to get this ENV VAR set in buildd environments, but what if the cmake, maven, ant, scons and $everybody else also insist on the same mechanism for default builds to work properly? That's a lot of ENV VARS - it doesn't scale well. And if someone does a local build outside the buildd environment now they have to remember to set these variables too, otherwise suddenly stuff that built on the buildds doesn't build for them. ENV VARS are very useful for all sorts of things, but they are problematic for distro build defaults, so there is a good reason for the path walk. Now we could patch autoconf in Debian (and other distros patch it too) to deal with this, but the whole point of this excercise is to fix this upstream so that over time the problem will just fade into history. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: cross-compilation and proprietary pkg-config replacements (pcre-config, pcap-config, etc)
+++ John Spencer [2014-08-15 23:49 +0200]: > Hello! > > I'm currently in the process of adding cross-compilation support to > a linux distribution, but I'm running into a lot of nasty issues. > > The #1 offender are proprietary pkg-config replacements, and there are many. > They break cross-compilation by returning non-sysrooted include and > library directories from the host, like -I/usr/include or -L/lib. > > I'm glad to say that autoconf itself is one of the few components > that properly handle cross-compilation. > > It seems it's "en vogue" for libs to ship their own broken > replacement rather than supplying a portable pkgconfig file... > the list is big, but these here are the most often used ones: > pcap-config, pcre-config, freetype-config, apr-1-config, > glib-config, gtk-config, ncursesw5-config, libmikmod-config, etc. It's not really "en vogue", it's historic: many of the things that have their own *-config scripts are sufficiently old that they pre-date pkg-config so are not doing this just to be annoying. At the time they didn't have much choice. > since it's unlikely to get any of those fixed in the next decade (or > even convinced to ship .pc files instead of their NIH'd pkg-config > replacement), I don't see why this should be too hard. We've (Debian) already persuaded a couple of projects to just use pkg-config instead of whatever homegrown stuff they had, or at least do that as well. It's the right way to make crossing and multiarch work right (as you are aware), and I'd hope that most upstreams could be persuaded of that. But there is a load of work involved in fixing things up and checking you didn't break all their reverse dependencies so it will take some time. > my idea was to add support for them into autoconf itself: > > Offer a m4 macro for each of them (or a generic "external config" > macro), which then calls these config tools and prefixes the > returned include and library paths with the sysroot path (passed to > configure via --with-sysroot=). > so packagers depending on these libraries would use the provided macros > rather than hardcoding their own test. Interesting idea. Is that easier than just adding a pkg-config file to each project? If you do this do remember that we want it to work on multiarch systems too, where sysroot is not used (equivalent to sysroot=/) > Does this sound viable and acceptable for inclusion ? > Or is there another workaround that i missed ? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: autocon and sub-packages
+++ Ralf Corsepius [2015-09-04 17:38 +0200]: > On 09/04/2015 02:26 PM, Sébastien Hinderer wrote: > > >Eric Blake (2015/09/04 06:07 -0600): > >>On 09/03/2015 08:09 AM, Sébastien Hinderer wrote: > >>>Dear all, > >>> > >>>I am one of the maintainers of Coccinelle[1], a tool written in the > >>>Objective Caml[2] language. > >>> > >>>The tool is distributed with the libraries it depends on (they are > >>>provided as bundles). > > >Camllanguage and its libraries are not as widespread as gettext and > >libtool. So the idea of the bundles is tomake life of end-users simpler, > >but of course it also makes thelifeofdevelopers and maintainers a bit > >harder. > > Well, what I can tell you with my Fedora on is that in Fedora we > discourage bundling, because it in a nutshell raises a lot problems > in maintenance, both for system-integrators (read: distros) and > upstreams. Right. Debian requires software not to use embedded libraries (unless they are genuinely exclusive to the package) if at all possible. Bundling libraries is bad for security (the bundled versions don't get updated when an issue is found in the system version), it wastes memory (unless versions are identical) and space, and conversely using system libs encourages proper upstreaming (over random forking and hackery), and API stabilty/management. It's acceptable to leave such libs in the source if that's how upstream ships it, but not to use them in the build. They are sometimes removed from the source too in the packaging process. Packaging (and build-systems like autotools) provides the same functionality from the user/developer POV, of having all the build-dependencies easily available at build-time. Distro-people believe this is superior to every upstream trying to do it with their own random-version, maybe-forked embedded copy :-) Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Hierarchical autoconf project with cross-compiled subproject
+++ panic [2016-01-26 20:45 +]: > How to correctly handle a cross-compiled subproject in autoconf/-tools? Well, the short version is that you are working against the design and making your life difficult. Having a project which is then either all compiled or all cross-compiled is what everything expects, so even with the co-dependencies I'd still think that it was easier to package the parts independently of the target architecture in the normal way, then build the pieces for the arches required. However it is possible to cross-builds parts of a project (e.g gcc bootstrap) so I expect what you want to do can be arranged. I have never actually tried to do what you are aiming for. > /After this long introduction, finally to the yet unsolved problem/: > When `make install-strip' is run, `make' runs recursively through the > directories and calls > /bin/mkdir -p '/the/install/dir' > STRIPPROG='strip' /bin/bash /to/project/build-aux/install-sh -c -s \ >thebinary '/the/install/dir' > > This fails for the subproject, because to strip a cross-compiled ELF > file, `$host-strip' (here: avr-strip) would be needed instead of normal > `strip'. One way is to make sure that $host-strip works both natively and cross. (i.e you have a link for amd64-strip or arm64-strip or whatever the non-avr arch is.). Then just calling $host-strip (e.g. by setting STRIPPROG) works in both cases. I don't know if there is a more autotoolsy way of dealing with this. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: How to update config.guess?
On 2016-08-01 17:58 -0400, Jeffrey Walton wrote: > I'm trying to build a package from its release tarball. config.guess > appears to be misidentifying the platform, so I'd like to update it to > the latest version. > > How do I update config.guess? On distros a reasonably current version is normally available in the filesystem. On Debian-based systems they are in: /usr/share/misc/config.guess /usr/share/misc/config.sub (the package autotools-dev needs to be installed). If building packages there are standard/recommended ways of updating during the build, documented on https://wiki.debian.org/Autoreconf It's also a good idea to prod upstream to update to recent versions to save others this hassle. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Reautoconfing
On 2020-12-20 17:46 +0100, Bruno Haible wrote: > This patch is already in Gnulib since 2020-12-09. But when people > run 'autoreconf' on an existing released tarball, they are effectively > combining an older Gnulib with a newest Autoconf. > > Why do people do that? The point of tarballs is that you can run > './configure' right away. Because on balance, over the long term, it works better. This page explains why debian now does this by default: https://wiki.debian.org/Autoreconf We realise that it was/is not the autotools design, but that design only works well when the auto* bits get updated reasonably often. If they just get left (because the last relase was a decade ago) or copied over into releases but never actually updated for years and years (which often happens in practice) they can (and in my experience often do) get badly out of sync with the surrounding world. Testing that things build with the tools now, as opposed to the tools available when the tarball was generated, demonstrates that the software can still be built from source. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Reautoconfing
On 2020-12-20 13:37 -0800, Paul Eggert wrote: > On 12/20/20 12:25 PM, Wookey wrote: > > We realise that it was/is not the autotools design, but that design > > only works well when the auto* bits get updated reasonably often. > > Yes, the design assumes that Autoconf etc. are maintained well, which > (except for Zack's efforts) has not been the case for a while. This part of > the GNU ecosystem needs more help, as the rare volunteers are spread way too > thin. Just to clarify here: I was talking about software projects that _use_ autotools being very infrequently updated, not autotools itself. Even if autotools was being updated assiduously that doesn't change a tarball last released 10 years ago, still being built in a modern distro. Nor projects that do new releases but don't reautoconf themselves and just cargo cult the autofoo they had working from last time, which I have also seen way too much of. I realise that my comment could in fact be read either way - apologies for lack of clarity. No criticism was implied of the people keeping autotools itself going. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: On time64 and Large File Support
new triplets for the 'LFS and 64_bit timet' ABI(s) then we should agree on them and use them. If distros are happy to migrate to these ABIs within the existing arm-linux-gnueabihf and i386-linux-gnu (or i686-linux-gnu) then we should do that. If half the distros migrate within the existing triplet and the rest use a new one, that sounds like a recipie for much confusion. I could write more, but I'll swot up a bit first :-) Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: On time64 and Large File Support
On 2022-11-12 04:28 +, Sam James wrote: > > > > On 12 Nov 2022, at 04:20, Wookey wrote: > > > > Distros need to co-ordinate on this. If there are going to be new > > triplets for the 'LFS and 64_bit timet' ABI(s) then we should agree on > > them and use them. If distros are happy to migrate to these ABIs > > within the existing arm-linux-gnueabihf and i386-linux-gnu (or > > i686-linux-gnu) then we should do that. > > > > If half the distros migrate within the existing triplet and the rest use > > a new one, that sounds like a recipie for much confusion. > > > > 100%. And also on sharing patches and known problems > and experience with the migration. All of it! OK. It seems that the time is right to have this conversation. So we should agree on a place to do it. We have used the linaro cross-distro list in the past as it is intended for this sort of cross-cutting discussions. I can't think of a better place? https://lists.linaro.org/mailman3/lists/cross-distro.lists.linaro.org/ Some of the right people are probably already there, but we should encourage others with relevant expertise to join. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: How can Autoconf help with the transition to stricter compilation defaults?
On 2022-11-10 19:08 +0100, Florian Weimer wrote: > * Zack Weinberg via Gcc: > > > It’s come to my attention (via https://lwn.net/Articles/913505/ and > > https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and > > Clang both plan to disable several “legacy” C language features by > > default in a near-future release (GCC 14, Clang 16) (see the Fedora > > wiki link for a list). > based on a limited attempt to get this fixed about three years > ago, I expect that many of the problematic packages have not had their > configure scripts regenerated using autoconf for a decade or more. This > means that as an autoconf maintainer, you unfortunately won't be able to > help us much. We changed the default in debian to re-autoconf on build a few years ago precisely so that changes in the tools (particularly new arch support) were picked up even by code that was not being re-released or released without autofoo updates. This has worked remarkably well. So changes in the tools will get used, at least in that context, which includes a fairly hefty pile of crufty old code. I have no feeling for how many packages are actually affected by this. Is there a quick way to test? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: On time64 and Large File Support
On 2022-11-12 11:15 -0800, Paul Eggert wrote: > On 2022-11-12 10:50, Bruno Haible wrote: > > I'm saying > > "tiny" because we are still 15 years away, and new releases of the (not > > many) affected packages are likely to come in the next 1-2 years. > > Not so "tiny", I'm afraid. My department is still running a server with > libraries and executables that are over 17 years old. Nobody disagrees with the idea that 2038 fixes are now fairly urgent if we want to avoid real-world stuff breaking in 15 years time. That has been increasingly clear for the last few years. But the point here is that we need a bit of co-ordination and a plan, particularly for binary distros. This isn't a minor change that should just happen to people because there was an autoconf upgrade. Or at least I don't think it is. My assumption is that if you just turned it on in random packages as they were uploaded, there would be very serious (unacceptably bad) breakage - we need to co-ordinate sets of matching-ABI packages to upgrade together, and the worry is that the matching set is 'most of the distro'. Now, I'm not yet sure if just having autoconf 2.72 will actually break things. AIUI, these changes only apply where LFS (-D_FILE_OFFSET_BITS=64) is turned on, so in Debian at least, where that is not the default on 32bit arches, maybe this is OK. But probably quite a lot of packages already enable LFS so they are suddenly going to get a new ABI if they expose timet anywhere? https://codesearch.debian.net/search?q=AC_SYS_LARGEFILE&perpkg=1 shows 163 pages of hits, and a quick peruse suggsts that AC_SYS_LARGEFILE is used by a lot of packages (as you might expect - this transition has been going on for many years). And just having that macro in configure.(in|ac) will turn 64-bit timet on if you autoreconf with 2.72. Right? We can't embark on that until we decide whether this transition will be done within the existing arch/triplet or with a new one. I agree we should decide that pronto. And I think that 'we' is bigger than just Debian. If new autoconf (and gnulib) just turns this on within the existing arch/triplet then we, the distro, can't use those new versions unless we back out those changes, or until we decide that we are going to attempt this ABI transition within the existing arch/triplet. I'm OK with this being done either way (complicated transition within arch/triplet, or whole-world rebuild with new arch/triplet) once the size of the problem (and thus the amount of work) is reasonably understood and there is some consensus amongst distros. TTBOMK we need some more research before we can make that choice (although I realise some others are further down this road than I am, and yes I did plan to get to this point about a year ago, so apologies for slowness). Hence my suggestion of a full discussion on the cross-distro list. It is overdue. However my limited understanding as of right now says that autoconf 2.72 tying 64bit time_t to use of AC_SYS_LARGEFILE means that 2.72 can't be used in debian yet. So I currently favour not tying them together in this release. People have been using AC_SYS_LARGEFILE without 64bit time_t for many years now so it's not yet clear to me why that cannot continue. And even if it is a good idea to complete both transitions in the same upheaval we can't just have everyone who enabled LFS sometime in the last 20 years suddenly being forced into the time_t change (can we?). Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: On time64 and Large File Support
On 2023-03-02 13:24 +, Daniel P. Berrangé wrote: > On Thu, Mar 02, 2023 at 01:17:33PM +0100, Bruno Haible wrote: > > Richard W.M. Jones wrote: > > > Another way to look at this is that it's a bug in gnutls and we should > > > fix it only in this package > > > > It's by far not just this one package. An 'fgrep -rl time_t /usr/include' > > search shows a number of libraries that use time_t in their API: > > alsa, boost, libstdc++, glib-2.0, gtk+-3.0, libpng, nettle, openssl, > > readline, libuuid, wxwidgets, X11, libxcb > > - and that's just the few that I happen to have installed. > > > > If a distro takes a package-by-package approach: > > - Some of these packages use Gnulib, and are thus causing trouble now or > > will soon. > > - The other packages (and there are a number of them!) will either > > require a manual switch to _TIME_BITS=64 or blow up in 2038. There are lots. I'm nearly 6000 packages into a 10,325 *-dev package analysis in debian and have so far found 218 packages where enabling _TIME_BITS=64 changes the ABI. (and 39 where enabling LFS changes the ABI - implying that they are not being built with it now). 1068 didn't change, (and 3713 don't actually contain a lib or headers - like 2000 golang* packages, and 895 need further analysis - many because the libs and headers are not in the same package). So there could be around 500 packages affected. (It was about 130 in Ubuntu main) Gnulib automatically changing the ABI for packages that use it is deeply unhelpful and is going to cause significant breakage and hassle. I'd better start checking how many libraries in debian have had their ABI incompatibly-changed already. Just because most users are on 64-bit systems is no excuse for randomly breaking the 32-bit ones. We do need to make this transition in 32-bit world, but it also needs to be done in an orderly fashion like any other ABI-breaking transition - with SONAME changes and ordered uploads (or decide it's too big, not do that, and start a new triplet/architecture). Neither of these involves randomly changing the ABI on some libraries just because they updated their gnulib. I gave a FOSDEM talk on the state of play about a month ago on this general issue in case anyone cares:https://fosdem.org/2023/schedule/event/fixing_2038/ > Those 32-bit binaries being targeted are going to be exclusively > using 32-bit time_t. IOW, doing a mass rebuild of the distro with > _TIME_BITS=64 will break compatibility with the very apps that > motivate the continued existance of i686 as a build target. Right. > Essentially i686 with 64-bit time_t needs to be considered > an entirely new build target. Either distros want to support > to this new target as a whole, or they want to stick with > the old target. Which is essentially x32, that has existed for some years (but has had little adoption). Debian builds it as an unoffical (i.e 'best effort') port. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: On time64 and Large File Support
On 2023-03-02 21:50 -0800, Paul Eggert wrote: > On 3/2/23 19:30, Wookey wrote: > > Gnulib automatically changing the ABI for packages that use it > > (and have LFS already enabled) is deeply unhelpful... > This change to Gnulib was reverted in December[1] and that propagated into > bleeding-edge GnuTLS last month[2]. So if I understand things correctly the > next GnuTLS release will go back to the old way of doing things, OK. gnulib doesn't seem to have releases as such (last release v0.1 9 years ago), and is normally used embedded in the upstream source like autotools (right?). What is a good test for whether a package/upstream is affected by this 'gnulib might have turned 64-bit time' issue? Is there an embedded gnulib version one can check, or does one have to look at dates of the m4/year2038.m4 and m4/largefile.m4 files in the source? I've not properly analysed this yet but presumably the problem arises if you have m4/largefile.m4 and m4/year2038.m4 from between 2012-07-02 and 2022-12-25. https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=history;f=m4/largefile.m4;hb=b9bf95fd0a6ab666b484b1e224321664f051f7fa https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=history;f=m4/year2038.m4;h=2e4427e6fac10550c99748abebf31b61e6afda2b;hb=b9bf95fd0a6ab666b484b1e224321664f051f7fa https://git.savannah.gnu.org/cgit/gnulib.git/log/m4/largefile.m4?h=stable-202301 > which will tempt the 32-bit time_t rearguard to fall back into > "Let's not worry about 2038" mode. Up to a point. I think enough people are taking notice now that those who care will be getting at least the core of this transition done this year. (Althought there will always be ancient bits of unmaintained software that don't get fixed until it actually breaks in 2038). > However this is just one package. We'll likely see similar issues with other > packages, independently of whether they use Gnulib, and independently of > whether the built packages are not supposed to be used after the year 2038. Yep. I noticed tar changing in debian (which may not involve any changing external interfaces so is hopefully OK, but I'm not sure the maintainers really understood what they should be checking before flicking the switch) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026204 This will be the normal case (upstream see a test failure and just enable the thing that makes the test work without necessarily understanding that they are/might-be part of a chain of ABI changes). > So this incident is a warning siren for the 32-bit time_t community. It's no > time to relax. > > [1]: > https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=7c7c8a519f3892f6f5b30a1c6b22796ab314a45c > [2]: > https://gitlab.com/gnutls/gnutls/-/commit/9622d7201e1d73d217c18802e1d435ba3404adb3 I made this wiki page for Debian's transition (which still needs a proper community discussion to agree a plan - I'm currently trying to collect the info needed for that discussion to be productive): https://wiki.debian.org/ReleaseGoals/64bit-time I will update it with this gnulib info once I understand it properly. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
