August 2017 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Update on patches upstream policy
by Kristýna Streitová 09 Aug '17

09 Aug '17

Hello, I've just adjusted "Upstream policy" section [1] in our "openSUSE:Packaging Patches guidelines" on openSUSE Wiki in order to explain our current patch policy better. The previous version of the paragraph only mentioned that patches should be sent upstream first when OBS package maintainer requires it. However, the truth is that all patches that can be interesting to upstream must *always* be sent to them. I hope that now the paragraph is clearer regarding this topic. If you are not familiar with this policy, please take your time and read this article. Also, if you maintain any package, please check whether it contains any patches that should be sent upstream. It's never too late to do it :) Thank you! Best regards, Kristyna Streitova [1] https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Upstream_poli…

4 3

Re: [opensuse-packaging] New repo-checker to be deployed on August 14th
by Jimmy Berry 06 Aug '17

06 Aug '17

On Saturday, August 5, 2017 8:46:56 AM CDT Sebastian wrote: > Hi, > > Is there a possibility to run this bot / these checks locally or on > other projects? I think this would be very useful. Currently it is > necessary to (re-submit to the devel project and then to)[1] re-submit > to Factory to see if the cryptic error messages are gone. > > Sebastian > > [1]: When someone is not a maintainer. This first usually takes some weeks. > Running the tool on devel projects to provide early feedback is something I have considered, but would likely require a bit of work to make it work and not be annoying. Devel projects can see a lot of change while reworking things that is not as clear to see the final state as SRs grouped together in a single staging. Additionally, it likely makes sense to filter checks for packages not submitted to Factory within a devel project, but perhaps also have a way to enable them. Alternatively, all of this could also be run manually if the tool was capable of such operation. It likely is not too far from this, but would require a bit of logic tweaking to properly overlay the devel repository on top of the target project to be checked. The previous checker had quite a bit of logic for trying to figure out which repositories in a devel project were built against the target project (ex Factory). I believe it can be done more simply or at worse-case manually indicated. The overall workflow is a bit unclear since there is no staging process for devel projects. As such the rpms from a home:* project problem would need to be analyzed which could provide false negatives or even positives depending on what else is built in that project. Sometimes packages from different devel projects are submitted together to form a valid update which would of course be seen as broken in devel projects. Checking individual devel packages overlayed on Factory seems the most straight forward, but of course that only works if no other packages in the devel project are needed as dependencies. Overall, it is a bit mirky how exactly to make this work in devel projects. Either a project level check or request workflow both have sticky areas. Given the staging-bot I introduced ensures packages are staged quickly it should not take too long for them to finish building and the repo-checker to provide feedback (especially for non-ring packages). The underlying tools can be run manually, but setting up the appropriate environment is not entirely trivial (entire copy of Factory and devel project rpms is required). If interested the primary tools are: - installcheck from libsolv-tools - findfileconflicts [1] And of course the repo_checker.py itself [2] along with repo_checker.pl [3] that prepares the data to be consumed by the installcheck. If you would really just like to see what the tool would spit out for a specific devel project you can manually tweak the code as I have done during testing. [not on a device that I can easily produce a proper diff] Use a submit request from Factory just to make the wheels turn. Change line 104 to set the group to your devel project. group = 'some:devel:project' Comment out 111 (ie status = api.project_status(group, True)) through 121. Be sure your devel project uses 'standard' as repo (or change the references with a conditional based on project). Run with --dry to ensure it does not try to post a comment. ./repo_checker --dry --debug id 514741 Hopefully, I remembered the rough gist. [1] https://github.com/openSUSE/osc-plugin-factory/blob/master/ findfileconflicts [2] https://github.com/openSUSE/osc-plugin-factory/blob/master/repo_checker.py [3] https://github.com/openSUSE/osc-plugin-factory/blob/master/repo_checker.pl -- Jimmy -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

Re: [opensuse-packaging] New repo-checker to be deployed on August 14th
by Sebastian 05 Aug '17

05 Aug '17

On 08/05/2017 03:46 PM, Sebastian wrote: > Hi, > > Is there a possibility to run this bot / these checks locally or on > other projects? I think this would be very useful. Currently it is > necessary to (re-submit to the devel project and then to)[1] re-submit > to Factory to see if the cryptic error messages are gone. > > Sebastian > > [1]: When someone is not a maintainer. This first usually takes some weeks. > > > On 08/05/2017 12:34 AM, Jimmy Berry wrote: >> packagers, >> >> A complete rewrite of the tool that runs as factory-repo-checker on OBS is >> scheduled for deployment on August 14th as the new user repo-checker. This new >> tool fixes a number of major shortcomings and bugs with the previous tool that >> result in errors detected that were previously not detected. As such simple >> version updates may be rejected until these issues are resolved. >> >> Both to provide a grace period and tooling improvement going forward the tool >> will now regularly post comments on packages with issues in their corresponding >> devel project. The 112 comments went out Wednesday on a variety of packages. >> >> Issues with any ring package will block an entire letter stagings just as a >> failing builds have previously. Due to the issues with the previous tool a >> number of problems currently exist with ring packages. In order to roll out the >> tool I started to fix the problems, but ended up finding too many so a whitelist >> will be used and relaxed as issues are fixed. See the Factory config [1] >> repo_checker-package-whitelist{,-x86_64,-i586} lines to see which packages are >> whitelisted and work to resolve those problems. The complete list of problems >> can be found in the repo_checker file [2]. If you help fix ring problems it >> is appreciated if you link to the requests in the tracking issue [3] so the >> whitelist can be relaxed as they are accepted. >> >> Overall, the new tool is significantly simpler in terms of lines of code, code >> complexity, and workflow complexity. Also faster! See the initial rewrite pull >> request for more details [4]. >> >> Summary of changes/features: >> >> - all architectures are checked (currently i586, x86_64) instead of just x86_64 >> - requests are checked in staging groups instead of devel projects >> - no more review spam during intermediary stages >> - properly handle ghc-* requests >> - cycle check based on entire group which properly catches problems >> - no longer a requires the latest version from devel >> - expect reviews not to be accepted until the entire group is built and passes >> - summary comments on staging projects to notify submitters of problems >> - new user repo-checker on requests >> - comments on packages in devel projects based on current Factory:standard >> >> The new repo-checker is currently soft-enabled for Factory in that it will be >> checking all requests, but only commenting when it sees a problem and having no >> effect on reviews. On August 14th all new requests will require approval from >> the new repo-checker user on OBS. >> >> An example of problems detected during the soft-enablement that the old repo >> checker passed over can be seen currently on Staging:B [5]. >> >> For a summary of planned improvements to the tool see the issues on github [5]. >> Report issues there using the title prefix 'repo_checker: '. >> >> Enjoy! >> >> [1] https://build.opensuse.org/package/view_file/openSUSE:Factory:Staging/dashb… >> [2] https://build.opensuse.org/package/view_file/openSUSE:Factory:Staging/dashb… >> [3] https://github.com/openSUSE/osc-plugin-factory/issues/1012 >> [4] https://github.com/openSUSE/osc-plugin-factory/pull/964 >> [5] https://build.opensuse.org/project/show/openSUSE:Factory:Staging:B >> [6] https://github.com/openSUSE/osc-plugin-factory/issues?&q=is%3Aissue%20is%3A… >> -- python programming - mail server - photo - video - https://sebix.at cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers

1 0

[opensuse-packaging] Massive problem with automatic formatting of spec file
by Johannes Weberhofer 05 Aug '17

05 Aug '17

Hi! I didn't care much on the discussions about the problems with the automatic formatting of spec-files up to today. In all projects maintained by me the spec-cleaner is regulary used and am very glad it helps me creating a consistent and easy to read format within my files. BUT today I tried to fix a problem which came up trying to build first PHP7 pear packages. I branched the php7 development project and changed a SINGLE LINE in the file and adopted the changes file. Submitting back to the devel:languages:php/php7 project, I now get a diff of 960 lines (see https://build.opensuse.org/request/show/514670 ). I think in general the changes make sense, but no one can review that! I can hardly find the change in the diff (its lines 204-205). To collaborate, this situation has to be improved. Have a nice weekend! -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] What paremeters to add to .config to allow kernel build with a reiser4 patch [reiser4-for-4.11.0.patch.?
by doiggl＠velocitynet.com.au 05 Aug '17

05 Aug '17

Hello. What paremeters to add to .config to allow kernel build with a reiser4 patch [reiser4-for-4.11.0.patch ]? - make oldconfig seems to remove them. Add in: CONFIG_REISER4_DEBUG=n CONFIG_REISER4_FS=m # Am I missing any parameters ? Thanks for your expertise. --Glenn urls :spec https://build.opensuse.org/package/view_file/home:doiggl/kernel-vanilla/ker… :reiser4 parameters allow patch to enable patch. https://build.opensuse.org/package/view_file/home:doiggl/kernel-vanilla/zre… reiser4 patch [reiser4-for-4.11.0.patch.gz 2017-06-03 625.9 kB] https://sourceforge.net/projects/reiser4/files/reiser4-for-linux-4.x/reiser… :build log. https://build.opensuse.org/build/home:doiggl/openSUSE_13.1/i586/kernel-vani… :build log content [ 74s] # configuration written to .config [ 74s] # [ 74s] make[1]: Leaving directory `/home/abuild/rpmbuild/BUILD/kernel-vanilla-4.12.4/linux-4.12/linux-obj' [ 74s] make: Leaving directory `/home/abuild/rpmbuild/BUILD/kernel-vanilla-4.12.4/linux-4.12' [ 74s] + echo '#run: /home/abuild/rpmbuild/SOURCES/check-for-config-changes .config.orig .config' [ 74s] #run: /home/abuild/rpmbuild/SOURCES/check-for-config-changes .config.orig .config [ 74s] + /home/abuild/rpmbuild/SOURCES/check-for-config-changes .config.orig .config [ 74s] [ 74s] Changes after running `make oldconfig': [ 74s] -# CONFIG_FRAME_POINTER_UNWINDER is not set [ 74s] -# CONFIG_GUESS_UNWINDER is not set [ 74s] +# CONFIG_REISER4_DEBUG is not set [ 74s] -# CONFIG_SUSE_KERNEL_SUPPORTED is not set [ 74s] -CONFIG_CRASHER=m [ 74s] -CONFIG_HAVE_MOD_ARCH_SPECIFIC=y [ 74s] -CONFIG_NF_CONNTRACK_SLP=m [ 74s] -CONFIG_ORC_UNWINDER=y [ 74s] -CONFIG_REISER4_DEBUG=n [ 74s] -CONFIG_REISER4_DEBUG=n [ 74s] -CONFIG_REISER4_FS=m [ 74s] -CONFIG_SUSE_KERNEL=y [ 74s] -CONFIG_UNWIND_INFO=y [ 74s] [ 74s] error: Bad exit status from /var/tmp/rpm-tmp.OzqHE8 (%prep) [ 74s] [ 74s] [ 74s] RPM build errors: [ 74s] Bad exit status from /var/tmp/rpm-tmp.OzqHE8 (%prep) [ 74s] [ 74s] cloud135 failed "build kernel-vanilla.spec" at Sat Aug 5 08:57:33 UTC 2017. [ 74s] [ 74s] ### VM INTERACTION START ### [ 79s] [ 50.623286] reboot: Power down [ 91s] ### VM INTERACTION END ### [ 91s] [ 91s] cloud135 failed "build kernel-vanilla.spec" at Sat Aug 5 08:57:51 UTC 2017. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] New repo-checker to be deployed on August 14th
by Jimmy Berry 04 Aug '17

04 Aug '17

packagers, A complete rewrite of the tool that runs as factory-repo-checker on OBS is scheduled for deployment on August 14th as the new user repo-checker. This new tool fixes a number of major shortcomings and bugs with the previous tool that result in errors detected that were previously not detected. As such simple version updates may be rejected until these issues are resolved. Both to provide a grace period and tooling improvement going forward the tool will now regularly post comments on packages with issues in their corresponding devel project. The 112 comments went out Wednesday on a variety of packages. Issues with any ring package will block an entire letter stagings just as a failing builds have previously. Due to the issues with the previous tool a number of problems currently exist with ring packages. In order to roll out the tool I started to fix the problems, but ended up finding too many so a whitelist will be used and relaxed as issues are fixed. See the Factory config [1] repo_checker-package-whitelist{,-x86_64,-i586} lines to see which packages are whitelisted and work to resolve those problems. The complete list of problems can be found in the repo_checker file [2]. If you help fix ring problems it is appreciated if you link to the requests in the tracking issue [3] so the whitelist can be relaxed as they are accepted. Overall, the new tool is significantly simpler in terms of lines of code, code complexity, and workflow complexity. Also faster! See the initial rewrite pull request for more details [4]. Summary of changes/features: - all architectures are checked (currently i586, x86_64) instead of just x86_64 - requests are checked in staging groups instead of devel projects - no more review spam during intermediary stages - properly handle ghc-* requests - cycle check based on entire group which properly catches problems - no longer a requires the latest version from devel - expect reviews not to be accepted until the entire group is built and passes - summary comments on staging projects to notify submitters of problems - new user repo-checker on requests - comments on packages in devel projects based on current Factory:standard The new repo-checker is currently soft-enabled for Factory in that it will be checking all requests, but only commenting when it sees a problem and having no effect on reviews. On August 14th all new requests will require approval from the new repo-checker user on OBS. An example of problems detected during the soft-enablement that the old repo checker passed over can be seen currently on Staging:B [5]. For a summary of planned improvements to the tool see the issues on github [5]. Report issues there using the title prefix 'repo_checker: '. Enjoy! [1] https://build.opensuse.org/package/view_file/openSUSE:Factory:Staging/dashb… [2] https://build.opensuse.org/package/view_file/openSUSE:Factory:Staging/dashb… [3] https://github.com/openSUSE/osc-plugin-factory/issues/1012 [4] https://github.com/openSUSE/osc-plugin-factory/pull/964 [5] https://build.opensuse.org/project/show/openSUSE:Factory:Staging:B [6] https://github.com/openSUSE/osc-plugin-factory/issues?&q=is%3Aissue%20is%3A… -- Jimmy -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] How to control repositories enabled for obs build?
by John Paul Adrian Glaubitz 03 Aug '17

03 Aug '17

Hi! I am currently working on updating the Microsoft Azure SDK for Python for SLE12SP2. All of these Python packages use setuptools upstream which causes some problems on SLE12SP2 because they use a feature not present in the old version of setuptools in SLE12P2, namely the "~=" operator which is used to denote compatible versions in Python. To resolve this problem, I simply patched the setup.py to replace "~=" with ">" and made sure the proper version dependencies are noted in the spec file. This worked all fine and without problems until I worked on a package (python-azure-sdk) that I branched from the devel:languages:python project. Although the package uses the aforementioned operator in setup.py, the package still builds fine in a SLE12SP2 environment without the necessary patch. After digging some time, I noticed that the chroot for the package branched from devel:languages:python was using a current version of setuptools, namely version 36.2.2 while my other packages were using the setuptools version present in SLE12SP2 which is 1.10.x. So, I have obviously the problem that OBS is enabling the devel:languages:python repository for the build which it shouldn't. Is there a way to tell OBS which repositories it's allowed to use during build and which not? Or do I have to branch the package into a specific project to avoid the inclusion of these particular repositories? Thanks, Adrian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

6 10

[opensuse-packaging] Fwd: New comment in package security:forensics/python-plaso by repo-checker
by Greg Freemyer 03 Aug '17

03 Aug '17

The below is complaining I have a package that requires an out-of-date version of python-construct. The trouble is the requirement is real. Do I have any options? fyi: In security:forensics I have the older package available. Thanks Greg ---------- Forwarded message ---------- From: Repo Checker <jberry+repo-checker(a)suse.de> Date: Wed, Aug 2, 2017 at 10:55 PM Subject: New comment in package security:forensics/python-plaso by repo-checker To: Greg Freemyer <Greg.Freemyer(a)gmail.com> Visit https://build.opensuse.org/package/show/security:forensics/python-plaso Repo Checker wrote in package security:forensics/python-plaso: The version of this package in openSUSE:Factory has installation issues and may not be installable: can't install python-plaso-1.5.1-1.1.noarch: nothing provides python-construct = 2.5.2 needed by python-plaso-1.5.1-1.1.noarch (we have python2-construct-2.8.11-2.1.noarch) can't install python-plaso-1.5.1-1.1.noarch: nothing provides python-construct = 2.5.2 needed by python-plaso-1.5.1-1.1.noarch (we have python2-construct-2.8.11-2.1.noarch) -- Configure notifications at https://build.opensuse.org/user/notifications openSUSE Build Service (https://build.opensuse.org/) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] d:l:p and %{!?license: %global license %doc}
by Bruno Friedmann 02 Aug '17

02 Aug '17

I found the macro really useful, allow to write cleaner spec files, and especially in the rewrite portage of python package to singlespec. Now the trouble we have in d:l:p is that all SLE12 and less important 42.1,SLE11 failed due to unpackaged directory /usr/share/license Perhaps we can extend the project repository to include those directory ? While it is not THAT important it will help to minimize the build failure number (also why running a build that we know it will fail?) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1