Re: Hackathon: fix build errors on the "master" branch.
Hi Chris, On Tue, Apr 30 2024, Christopher Baines wrote: > I get 1290 as 4.3% of 3 Thanks for that! I do not understand the underlying math but read the other number with some skepticism. Kind regards Felix
Re: Hackathon: fix build errors on the "master" branch.
Efraim Flashner writes: > On Mon, Apr 29, 2024 at 04:52:29PM +0200, Ricardo Wurmus wrote: >> Hi Guix, >> >> for the past weeks the "master" branch has been in pretty poor state >> according to ci.guix.gnu.org. It keeps hovering at around 56% progress, >> which is a far cry from the 80+% we used to have in the old days. >> >> A lot of packages are in fact broken. Many more are marked as broken >> due to a bug affecting ci.guix.gnu.org. >> >> It would be a good idea to do a little spring cleaning and go through >> the dashboard for the master branch and work on fixing builds that are >> currently broken on x86_64-linux. (Other architectures are in worse >> state, but fixing x86_64-linux may be something we can actually >> accomplish.) >> >> What do you think? > > Using the QA¹ page we can see another data point of how the different > architectures are doing. Also, assuming there are 30,000 packages, the > 4.3% difference on bayfront between x86_64 and i686 would be 129 > packages. Given how easy it is to build for i686 on x86_64 I'd suggest > also going through some of the i686 packages which don't build and > checking if there's a build failure that can be patched or if it's a > case of the software not supporting 32-bit architectures. > > ¹ https://qa.guix.gnu.org/branch/master I get 1290 as 4.3% of 3, and that matches up better with the 1551 results I see here for things that are available from bordeaux, but not from ci: https://data.guix.gnu.org/revision/ddf3759645ba76ef532658a257ae74fe0b1788b5/package-derivation-outputs?search_query=_available_from=2_not_available_from=1_consistency=any=x86_64-linux=none=no-additional-fields_path=_results=_results=on You can also ask the data service about failing builds, although it only knows about bordeaux builds: https://data.guix.gnu.org/revision/ddf3759645ba76ef532658a257ae74fe0b1788b5/package-derivations?search_query==x86_64-linux=none_builds=_builds=_status=failing=builds_name=_results=_results=on signature.asc Description: PGP signature
Re: Hackathon: fix build errors on the "master" branch.
On Mon, Apr 29, 2024 at 04:52:29PM +0200, Ricardo Wurmus wrote: > Hi Guix, > > for the past weeks the "master" branch has been in pretty poor state > according to ci.guix.gnu.org. It keeps hovering at around 56% progress, > which is a far cry from the 80+% we used to have in the old days. > > A lot of packages are in fact broken. Many more are marked as broken > due to a bug affecting ci.guix.gnu.org. > > It would be a good idea to do a little spring cleaning and go through > the dashboard for the master branch and work on fixing builds that are > currently broken on x86_64-linux. (Other architectures are in worse > state, but fixing x86_64-linux may be something we can actually > accomplish.) > > What do you think? Using the QA¹ page we can see another data point of how the different architectures are doing. Also, assuming there are 30,000 packages, the 4.3% difference on bayfront between x86_64 and i686 would be 129 packages. Given how easy it is to build for i686 on x86_64 I'd suggest also going through some of the i686 packages which don't build and checking if there's a build failure that can be patched or if it's a case of the software not supporting 32-bit architectures. ¹ https://qa.guix.gnu.org/branch/master -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Hackathon: fix build errors on the "master" branch.
Hi Guix, for the past weeks the "master" branch has been in pretty poor state according to ci.guix.gnu.org. It keeps hovering at around 56% progress, which is a far cry from the 80+% we used to have in the old days. A lot of packages are in fact broken. Many more are marked as broken due to a bug affecting ci.guix.gnu.org. It would be a good idea to do a little spring cleaning and go through the dashboard for the master branch and work on fixing builds that are currently broken on x86_64-linux. (Other architectures are in worse state, but fixing x86_64-linux may be something we can actually accomplish.) What do you think? -- Ricardo
