On Mon, Nov 21, 2016 at 06:21:47PM +0100, Marius Bakke wrote: > Sweet. Perhaps it should be grafted on master first, then merge it and > ungraft on core-updates? Either approach will cause conflicts if there > are further updates to libtiff before next core-updates merge, so not > sure which is better.
I'm sure there will be patches for 4.0.7. I'll handle master -> core-updates merge conflicts when I commit those patches to master. > Another approach could be to have special "ungraft" branches for each of > these widely used high-severity libraries, that are continously merged > once Hydra has built it all. > > Not sure how many days it takes to build ~1600 packages for all > supported archs, probably better to merge "ungrafts" to staging. It would be nice to remove the grafts soon, but it's over the 1200 rebuild limit for staging: http://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html But, I'll put it on staging if there is a consensus. I guess that staging will end up requiring more than 1200 rebuilds anyways, since there could be multiple changes with that much impact, but affecting different parts of the package graph.
signature.asc
Description: PGP signature
