October 2019 - openSUSE Build Service - openSUSE Mailing Lists

[opensuse-buildservice] Different build engines for different packages at the same project
by Julio Gonzalez 08 Oct '19

08 Oct '19

Current situation: https://build.opensuse.org/project/show/systemsmanagement:Uyuni:Master:Ubun… * salt contains both a normal salt.spec file (to build RPMs), and a debian.tar and salt.dsc (to build Deb packages) [1] * spacecmd contains only a spacecmd.spec file, adapted to use debbuild, so it can produce both RPM and DEB packages [1] I added <path project="Ubuntu:debbuild" repository="Ubuntu_16.04"/> to the meta config, but of course that's now using debbuild for both packages. Checking https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.prjconfig.… I don't see how to do what I need: using .dsc if it's there, otherwise trying to build the spec with debbuild. Is it possible? Any ideas? [1] Reason of this is that such packages are maintained on a common place (systemsmanagement:Uyuni:Master) for a lot of different OS, so we basically banch the packages to each set of client tools. -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

2 1

[opensuse-buildservice] Possible mistake with OSC
by William Brown 08 Oct '19

08 Oct '19

Hi there, I was recently trying to submit a package update to the internal SUSE:SLE-15-SP2:GA repo. Because the package had been deleted I was required to re-branch it, but in the process I forgot to use my internal alias (iosc) which meant that I accidentally updated to build.opensuse.org. https://build.opensuse.org/projects/SUSE:SLE-15-SP2:GA/pulse Now this caused me to have a bit of an anxious moment - had I just leaked all of SUSE's internal SLE-15-SP2 into the public internet? I'd like to know if: A) I have just massively leaked content B) This mirror is an intentional part of the build.opensuse.org system Following on from that, it leads me to an observation, which is that osc is really hard to get right from a psychology perspective. It's *easy* to make mistakes or accidentally leak content like this. In this case because I already had a branch from internal osc, when I re-checked it out the change in behaviour (a lack of consistency in design terms) caused me to believe I was still working internally when I was not. A simple suggestion is that with osc, if you have *multiple* connections in .config/osc/oscrc, and the current action doesn't "know" which to use, instead of assuming the default, prompt the user to provide the connection details or select which one. IE: # osc branch thing otherthingy > Which instance would you like to do this in? 1) https://build.opensuse.org 2) https://internal.obs.instance [default: 1] # Second, the presence of the SUSE:SLE-15-SP2:GA if intentional, is also surprising behaviour - because it meant that a command on the internal instance also works on the external instance - there is no feedback or constraint that could stop this. This poses a risk because without the osc switching as listed above, it could be very easy for someone to have submitted an MR/SR that would leak vendor or private content to the public instance. As a result to prevent this another suggestion is that if this *is* a public mirror of the content, then it should have a different name. This way it becomes impossible to accidentally submit the MR/SR to the public mirror because the project does not exist. (This is a constraint in design terms). Thanks, -- Sincerely, William — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

2 1

[opensuse-buildservice] Correct way to remove packages and have the delete "flow on"
by William Brown 08 Oct '19

08 Oct '19

There are a number of deprecated and unsupported packages in network:ldap related to the old 389 console. These need to be removed. What's the right way to delete these so the "delete" flows down into tumbleweed? Thanks, — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

2 2

[opensuse-buildservice] Possible mistake with OSC
by William Brown 07 Oct '19

07 Oct '19

Hi there, I was recently trying to submit a package update to the internal SUSE:SLE-15-SP2:GA repo. Because the package had been deleted I was required to re-branch it, but in the process I forgot to use my internal alias (iosc) which meant that I accidentally updated to build.opensuse.org. https://build.opensuse.org/projects/SUSE:SLE-15-SP2:GA/pulse Now this caused me to have a bit of an anxious moment - had I just leaked all of SUSE's internal SLE-15-SP2 into the public internet? I'd like to know if: A) I have just massively leaked content B) This mirror is an intentional part of the build.opensuse.org system Following on from that, it leads me to an observation, which is that osc is really hard to get right from a psychology perspective. It's *easy* to make mistakes or accidentally leak content like this. In this case because I already had a branch from internal osc, when I re-checked it out the change in behaviour (a lack of consistency in design terms) caused me to believe I was still working internally when I was not. A simple suggestion is that with osc, if you have *multiple* connections in .config/osc/oscrc, and the current action doesn't "know" which to use, instead of assuming the default, prompt the user to provide the connection details or select which one. IE: # osc branch thing otherthingy > Which instance would you like to do this in? 1) https://build.opensuse.org 2) https://internal.obs.instance [default: 1] # Second, the presence of the SUSE:SLE-15-SP2:GA if intentional, is also surprising behaviour - because it meant that a command on the internal instance also works on the external instance - there is no feedback or constraint that could stop this. This poses a risk because without the osc switching as listed above, it could be very easy for someone to have submitted an MR/SR that would leak vendor or private content to the public instance. As a result to prevent this another suggestion is that if this *is* a public mirror of the content, then it should have a different name. This way it becomes impossible to accidentally submit the MR/SR to the public mirror because the project does not exist. (This is a constraint in design terms). Thanks, -- Sincerely, William -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

1 0

[opensuse-buildservice] Kickstart to AutoYast
by Dominig ar Foll (Intel Open Source) 02 Oct '19

02 Oct '19

Hello, as part of porting the project StartlingX to OpenSUSE, I have to convert many kickstart files into autoyast. Would someone know about a translator/converter, even semi manual which could ease progressing that tedious task ? Regards. -- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

2 1

[opensuse-buildservice] CentOS8: No python3?
by Julio Gonzalez 02 Oct '19

02 Oct '19

I am trying to fix the issue at https://build.opensuse.org/package/show/openSUSE:Tools/obs-service-tar_scm not building for CentOS_8 with https://build.opensuse.org/request/show/734384 Problem is that "python3" is not available. As far as I can tell from https://developers.redhat.com/blog/2019/05/07/what-no-python-in-red-hat-ent… and the tests I am making myself at a CentOS8 VM, neither python2 or python3 are part of the baseOS repository, but part of the AppStream repository. Is AppStream repo missing at OBS? PS: obs-service-tar_scm does not have RHEL8 enabled yet, but I guess it will have the same issue. -- Julio González Gil Release Engineer, SUSE Manager and Uyuni jgonzalez(a)suse.com

5 11

[opensuse-buildservice] undefined reference to boost::python::
by opensuse.lietuviu.kalba 01 Oct '19

01 Oct '19

Hi, Do to some unknown "meta change" on 2019 September 19, builds for tumbleweed fails with various "undefined reference to `boost::python::" errors: undefined reference to `boost::python::detail::dict_base::dict_base()' undefined reference to `boost::python::detail::list_base::list_base()' undefined reference to `boost::python::throw_error_already_set()' libboost_python-py3-1_71_0-1.71.0-2.1, libboost_python-py3-1_71_0-devel-1.71.0-2.1, libboost_python3-devel-1.71.0-1.1 are installed. Seems to be related to updating boost-defaults (1.69.0 -> 1.71.0) in Tumbleweed snapshot 20190918. Build for openSUSE Leap success. Can someone please help to fix builds for Tumbleweed? See more information in: https://build.opensuse.org/packages/calamares/job_history/home:embar-:calam… https://build.opensuse.org/package/live_build_log/home:embar-:calamares/cal… -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

1 1

[opensuse-buildservice] service error: DEBUG:root:Cleaning: /var/cache/obs/trDXZ8kSZ2as/out/tmp_kh0857x
by Andreas Schwab 01 Oct '19

01 Oct '19

What does that mean when an obs_scm service fails with this error? Andreas. -- Andreas Schwab, SUSE Labs, schwab(a)suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org

2 1