Re: Project direction with testing changes (branches and patches)
Mathieu Othacehe writes: >> I think trying to change up how branches (staging/core-updates) are >> tested is a good place to start. The concrete change I'm proposing is to >> use an instance of the Guix Data Service plus an instance of the Guix >> Build Coordinator to do the testing and builds, rather than Cuirass on >> ci.guix.gnu.org which is the current approach. >> >> The main advantages of that would be the comparison support from the >> Guix Data Service, and the build performance and reliability that the >> Guix Build Coordinator brings. The main disadvantage is probably the >> lack of an admin like interface similar to that of Cuirass (I think this >> can be remedied in the medium term though). > > We indeed desperately need some more automation. For each new patch > series, it would be great to have the following information: > > * Status of the linter. > * Status of the depending derivations. > * Status of the unit tests (in the tests/ directory). > * Status of the system tests (in the gnu/tests/ directory). > > I would like to stay focused on the existing, well adopted solutions and > build upon them. With Cuirass we already have most of the machinery to > provide those information. I was thinking of using Cuirass for building derivations when testing patches, but I gave up on that approach back in 2019 after trying to use it (I discussed trying to use it here [1]). 1: https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00010.html I was specifically thinking about testing patches when I initially designed both the Guix Data Service and Guix Build Coordinator. For me at least, the focus has been on this direction for the last ~3 years. I realise that Cuirass now has some of the functionality that the Guix Data Service was written to provide, like tracking all packages/derivations in each revision. But from my perspective, Cuirass still lacks key things like being able to compare two revisions and tracking lint warnings. There's also things like testing derivations on different hardware, regularly testing fixed output derivations and automatically retrying failed builds that I think the Guix Build Coordinator is better setup to do compared to Cuirass. But this feedback is why I started this thread. I don't see the same option as was found for improving substitutes by setting up a new substitute server using the Guix Data Service and the Guix Build Coordinator. There's a much stronger need to have one approach as a project for testing changes, and if using the Guix Data Service and Guix Build Coordinator isn't looking like a convincing option at this point, that's better to know now, compared to later when more time and effort has been put in. Thanks, Chris signature.asc Description: PGP signature
Re: Hurd Security vulnerabilities, please upgrade!
Ricardo Wurmus, le mar. 10 août 2021 17:52:34 +0200, a ecrit: > I’m a little unclear on what this means for distributions like Guix. Should > we just update to the latest version from git? Are there specific commits > we should use if it’s not just the latest? Since Sergey's copyright assignment is not complete yet, it's not commited yet, so you have to pick up the patches from the debian repository. Samuel
Re: Hurd Security vulnerabilities, please upgrade!
Hi Samuel, In the past months, Sergey Bugaev has been working on fixing some Hurd security vulnerabilities. This is now fixed in the latest Debian packages, so please upgrade and reboot! Thanks for the fixes and the heads-up! hurd >= 1:0.9.git20210404-9 libc0.3 >= 2.31-13+hurd.1 gnumach-image-1.8-* >= 2:1.8+git20210809-1 I’m a little unclear on what this means for distributions like Guix. Should we just update to the latest version from git? Are there specific commits we should use if it’s not just the latest? Thanks! -- Ricardo
Re: Project direction with testing changes (branches and patches)
Christopher Baines writes: I think using Patchwork or Mumi is viable, it would probably not be great to use both in the long term. The most useful thing for me would be to pick an approach. Patchwork is closer in terms of features I think, since it has an API for patch series and checks. I know mumi gained the ability to generate mbox files for patch series now though. I wouldn’t mind getting rid of Mumi. Surely Patchwork has a way to configure the user interface somewhat? I think the requirements in terms of Mumi would be to have some way of querying for patch series to test, or at least all/recent patch series. I suppose something could just ask for the 1st or latest series each time there's an email to a issue, that might be the simplest approach. There is an /issue//patch-set/ handler to download patch series. IIRC there is a bug somewhere that makes it not work as intended, but I did use it in the past to get a whole bunch of patches and apply them with ‘git am’. Then there's the bits you describe about showing relevant information about whatever tests take place. I guess Mumi would need an API or some way to find out about that information, and then display it. Maybe that could happen in the form of emails with machine+human readable data that Mumi could interpret. I don’t know what this means. What exactly is needed here? Unfortunately I don't know much about the Mumi internals. Ricardo, are you able to comment on the feasibility and whether this direction would make sense? I think it’s feasible to add a few more things to Mumi to make the existing features work better. But I should also emphasize that I’m in no way attached to Mumi. If we have something better I’d be happy to retire it. Mumi has served us well; we don’t need to extend its use beyond what is reasonable. -- Ricardo
