All, I was following the "[TW] nextcloud desktop client uninstallable" thread and that brought up the question of how are these build failures being identified and handled in the rolling-release process and how are they slipping through? I ask because I'm not that familiar with the Tumbleweed QA process and am only familiar with how Arch does it. With Arch, there are two sets of repos: (1) "testing" - where new upstream packages and build system changes are introduced. Any build type failures are identified here and package remain in testing until the issue are resolved (along with any packages that depend on them) (2) the normal repos - when package hit here, all build and dependency issues have been resolved and the only corner cases that arise are the stray user hardware/software combinations, etc... I suspect openSUSE has a similar setup for Tumbleweed, but in the case of nextcloud client and Calibre the FORTIFY_SOURCE=3 somehow seems to have gotten by. Now this is just "growing pains" no different to handling build with jumps in gcc or glibc versions -- there are going to be issues to fix. My curiosity is where/how are these "growing pains" issues caught in the Tumbleweed process? -- David C. Rankin, J.D.,P.E.