Created attachment 1249012 [details] cause error in make Description of problem: The build of snappy-java goes successfuly true even if the make ends in error. I guess it's not what should happen. Version-Release number of selected component (if applicable): snappy-java-1.1.2.4-3 How reproducible: Make the make command fail, for example by adding a syntax error to src/main/java/org/xerial/snappy/SnappyNative.cpp. Steps to Reproduce: build snappy-java with attached patch Actual results: build succeed Expected results: build fails Additional info: https://kojipkgs.fedoraproject.org//work/tasks/8026/17708026/build.log
i try to found the syntax error in src/main/java/org/xerial/snappy/SnappyNative.cpp but in our source archive is not available. (contets of SnappyNative.cpp) #include <string> #include <cstring> #include <snappy.h> #include "SnappyNative.h" where you download/found this?
I'm not saying there is a syntax error in the sources. I'm saying that if there is an error one the build should fail. I made the error on purpose to illustrate the behavior.
(In reply to Tomas Repik from comment #2) > I'm not saying there is a syntax error in the sources. I'm saying that if > there is an error one the build should fail. > > I made the error on purpose to illustrate the behavior. Default build tool for this project is sbt (= 0.13.8), and a lot of sbt plugins, not available in our repositories. So we use maven. I/we do MANY CAUTION during the build process to AVOID problem with COMPILATION. For me this bug is not valid
Latest scratch build Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=17709474
This _is_ a bug, Gil. If for example, for whatever reason, g++ refuses to build the only *.cpp file in future -- nobody will notice (koji build succeeds, so what?). That's like you've done '%mvn_build || true' to hide the errors.. This would be a bit similar bug 1420790 .. it survived one stable release broken. If you claim this is not a bug in snappy-java, please switch against appropriate component, it would be really helpful! If you have not enough time to fix yourself, can you please guide us towards correct solution? What we need is: to ensure that when the compilation fails, also the whole koji build fails so we can observe FTBFS as soon as possible.
(In reply to Pavel Raiskup from comment #5) > This _is_ a bug, Gil. If for example, for whatever reason, g++ refuses to > build the only *.cpp file in future -- nobody will notice I admit that if you do the build, you will notice most probably, but for example Fedora release engineers might spin build during mass rebuild and broken package could get into repository. Feel free to assign this bug to me or Tomáš, because we plan to have this fixed, but yeah - help would be appreciated.
(In reply to Pavel Raiskup from comment #5) > This _is_ a bug, Gil. If for example, for whatever reason, g++ refuses to > build the only *.cpp file in future -- nobody will notice (koji build > succeeds, so what?). That's like you've done '%mvn_build || true' to hide > the errors.. This would be a bit similar bug 1420790 .. it survived one > stable release broken. This is only an your opinion and not involved me and the package > If you claim this is not a bug in snappy-java, please switch against > appropriate component, it would be really helpful! I dont care > If you have not enough time to fix yourself, can you please guide us > towards correct solution? What we need is: to ensure that when the > compilation fails, also the whole koji build fails so we can observe FTBFS > as soon as possible. No solution. The only one is take care of the build process
(In reply to Pavel Raiskup from comment #6) > (In reply to Pavel Raiskup from comment #5) > > This _is_ a bug, Gil. If for example, for whatever reason, g++ refuses to > > build the only *.cpp file in future -- nobody will notice > > I admit that if you do the build, you will notice most probably, but > for example Fedora release engineers might spin build during mass rebuild > and broken package could get into repository. If something in the build process gone wrong. we can notice its. This library is used in many projects as build or test deps, using Koschei. > Feel free to assign this bug to me or Tomáš, because we plan to have this > fixed, but yeah - help would be appreciated. I will close this bug for the last time.
> No solution. The only one is take care of the build process Which means manual review of all of this? If yes then -1: https://koji.fedoraproject.org/koji/packageinfo?packageID=13533 > If something in the build process gone wrong. we can notice its. This > library is used in many projects as build or test deps, using Koschei. -1. Without doubts, Koschei is too late for such build failures. Please don't bother other package maintainers with FTBFS in package you maintain. > I will close this bug for the last time. Uh, OK :(. Thanks anyway for being responsive and sorry for me being that unyielding. I'm reopening again and assigning to myself, I hope I'll have a time to have a look soon ... I'll propose a fix or close CANTFIX. Still any hint is appreciated.
Created attachment 1249060 [details] Proposed fix. Gil, can you please have a quick look? The patch is in private branch private-praiskup-rhbz-1421088. I can merge && build this in F26.
i can apply the patch now
Thanks!
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=17722119