That'sĬpp-hocon, luminance-hdr, openshadinglanguage, and usd. The rest were not submitted for a rebuild, for some reason. Now, and gqrx which seems to be broken by the codec2 update. The boost update, and luxcorerender and shiny, which I'm rebuilding Those are all done now except blender, which was already FTBFS before The ones marked with *** couldn't be built because a dependencyįailed, but should have been resubmitted after the dep was fixed. The ones marked ** depend on one of the ones that failed, so are blocked. (some have now been fixed, some need a FTBFS bug filed). The ones marked with a single * were submitted but failed to build The packages that didn't get rebuilt are: I'll check to see if that happened to other packages. > cpp-hocon and usd, so I'm not sure why rebuilds weren't issued for > The process to find them is a reqoquery using -whatrequires > It’s probably worth looking into the process for finding and rebuilding dependent packages to see why these were not rebuilt, as there must be many other packages that also should have been rebuilt but were not. Packages to use, there's no need to rebuild them. The API and ABI of those shared libraries are using the new versions.įor standalone applications that don't provide any libraries for other That would ensure that any boost types in Packages which require boost-devel and also provide %/lib*.soįiles (or a -devel package). I suppose we could add to the set of rebuilds by doing a repoquery for > rebuilt anyway by a mass rebuild after the boost update, but the mass > only depend on boost headers from boost-devel (although often they get
#Luxcorerender standalone update
> When we update boost in rawhide we never rebuild the packages that > Boost releases, but this doesn't happen often in practice. > libs and cairomm libs will encounter some incompatibility between the > In some cases it's possible that another package that depends on boost > dependency on the version of boost that the rest of the distro uses. > Strictly speaking, they don't need to be rebuilt. > Others (cairomm/cairomm1.16) presumably used only header-only parts of Boost, and were silently continuing to use the old Boost. Another (usd) should be in the same boat once some unrelated problems causing FTBFS are resolved.
#Luxcorerender standalone manual
> Some (luminance-hdr, cpp-hocon) had automated FTI bugs filed these were fixed by a manual rebuild on my part. > It looks like none of the packages I maintain or co-maintain that depend on boost-devel were rebuilt before the side tag was merged.
> On Tue, at 18:23, Benjamin Beasley wrote:
0 kommentar(er)
