August 2015 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] release-notes-openSUSE requires google-opensans-fonts
by Felix Miata 23 Apr '17

23 Apr '17

TW $SUBJECT can't be right, but trying to zypper rm opensans wants to remove releasenotes. :-( -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 8

[opensuse-packaging] The purpose of Copyrights in specfile?
by Marguerite Su 31 Aug '15

31 Aug '15

Hi, This is not a right/wrong question, but why we keep copyright of companies/persons in a specfile? Is there really anyone who will steal that? Or, eg: 1. I wrote my copyright in a specfile, after 70 years, there's little chance that my original code still in it. why should I still own that file? just for the naming? but common names like gcc.spec exist everywhere. 2. After I ran spec-cleaner manually or OBS ran obs-service-format_spec_file automatically, for a very simple specfile, it is most likely that the whole file got "rewritten" by the program, the only exception might be the reserved words like "%prep" or "make". isn't the author of the specfile automatically changed to one of the obs-service-format_spec/spec-cleaner/the specfile template/the rpm project authors? And: If I wrote the copyright, then in some cases the specfile will get included in commercial products like SLE. If one day I said I do not authorize SUSE to use my specfile, what will they do? remove the package completely? or just rewrite the specfile? If they rewrite the specfile, should I say, oh they copyed my work. because there's little chance that they know whether I wrote the specfile from scratch or I generated it from our specfile template. If I own the specfile, the skeleton will also be owned. but how can a person write a specfile without following the specfile guideline? And how could the skeleton be owned by others? they're initialized by RPM project authors... Thanks for answering my wonders Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 13

[opensuse-packaging] Temporary hold on accepting devel:language:python requests
by Todd Rme 31 Aug '15

31 Aug '15

Short version: please do not accept any submit requests or make any other changes to devel:languages:python until the following package has built at least once: python-jupyter_ipywidgets Long version: For the last 16 days I have been trying to get all of the core Jupyter packages in devel:languages:python and devel:languages:python3. Jupyter is a renaming and modularization of the enormously popular IPython project. This has been very slow going, because they split the packages into many parts, and these parts have a lot of dependencies (including quite a few new ones). These dependencies include many common python packages. That means that, in OBS, if any of these dependencies is changed in any way (or any of its dependencies are changeda, and so on), then everything is rebuilt from scratch. And unfortunately these new packages seem to be given a very low priority for building, which means it takes a long time before OBS actually gets around to building them. This means it is a process of: get a package in, wait 2 days for it to build, get another package in, wait 2 days for it to build, and so on for weeks. I have one more package to go: python-jupyter. Once it is in, the process is complete. For the last 4 days I have been waiting for the python-jupyter_notebook package to build. It had one dependency left before it was going to build, and then an submit request python-Cython was accepted. Since this is a dependency of all of the jupyter-related packages, everything will need to rebuild now. That may very well mean another 2 days wait for me. Until all of its dependencies have built at least once, I can't properly package python-jupyter. It will outright refuse to build. Of the two dependencies that have not built yet, python-jupyter_ipywidgets package is the most "leaf" one. That means that once it has built once, all of the other dependencies have as well. So if everyone could refrain from making any changes of any kind to devel:languages:python until that package has been built at least once, I would greatly appreciate it. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 4

[opensuse-packaging] golang-packaging failure
by Matwey V. Kornilov 26 Aug '15

26 Aug '15

Hi, The following package does not provides golang(github.com/bmizerany/pat) as it did before: https://build.opensuse.org/package/show/devel:languages:go/golang-github-bm… Something is probably broken with golang-packaging. -- 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] [ACTION REQUIRED] Make sure your packages get in openSUSE Leap
by Richard Brown 25 Aug '15

25 Aug '15

Hi all, Here's a reminder that for openSUSE Leap, unlike previous openSUSE versions, package maintainers need to actively submit their packages to the distribution if they want to be sure their package ends up in the final release. This is because openSUSE Leap can include packages from one of 3 origins 1) SUSE:SLE-12:GA and SUSE:SLE-12:Update - aka The SLE Sources 2) openSUSE:Factory 3) Leap Devel Projects - new devel projects for the purpose of containing stable versions of packages for Leap which are newer than SLE but older than Tumbleweed (Currently non of these exist, but they are expected to be needed in the future) As a Package Maintainer for openSUSE it is *your responsibility* to decide which version of your software makes sense for the stable distribution we are creating with leap. More thoughts on this can be found on the opensuse-factory thread on the topic: http://lists.opensuse.org/opensuse-factory/2015-07/msg00796.html The steps required are luckily quite simple Step 1) Decide which of the 3 locations above you want to pull your existing package from. Step 2) Submit it to the openSUSE:42 Project (Full Documentation Here: https://en.opensuse.org/openSUSE:How_to_contribute_to_Leap ) Step 3) That should be it, make sure the package gets in and do the usual awesome job you do maintaining the package - Thank you ;) Please can everyone also do their best to spread the word around to anyone and everyone who maintains packages in openSUSE who may not be reading this list. Many Thanks, Richard -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

17 36

[opensuse-packaging] Jupyter released -- new name for IPython project
by Todd Rme 21 Aug '15

21 Aug '15

Warning, long post ahead. Unfortunately this is a complicated issue, and I don't think our current policies will serve us well here. IPython is a rich python shell and python browser interface that has gained a lot of popularity, especially amongst scientific users. Python 2 and Python 3 versions have been supported in openSUSE:Factory and openSUSE releases for a long time. Over the past year or so, the project has been modularizing. The python-specific bits have been split out, the individual components have been spun off into individual projects that can be built, installed, and released independently. The last key missing piece, IPython 4.0, was released 2 days ago. With this, it is not possible to have a fully working jupyter installation. I am currently in the process of getting everything working for openSUSE, but due to a large number of new dependencies, updated dependency version requirements, and package interdependencies, it is going to take some time. I ask everyone else please hold off on trying to package them, it really requires a coordinated approach and I have a specific packaging system in mind: In order to keep things consistent, I want to name jupyter-specific components with the naming convention "python-jupyter_<name>" and "python3-jupyter_<name>", where "<name>" is the package name (unless the package name is already "jupyter_<something>", in which case it uses "python-<name>"/"python3-<name>"). This is not exactly in line with the current Python packaging, but because Jupyter has so many components, I think it would be a nightmare if they weren't named in a consistent manner, and unfortunately the upstream naming is far from consistent. This naming convention normally only applies to package that are useless outside of jupyter. I would like this naming convention to be formally included in the python packaging guidelines, because there is already dozens of kernels for jupyter, and dozens of additional add-ons, and more of both are coming constantly. We are going to end up with a huge mess if we don't get things nailed down correctly up-front. Initially, I will get a minimum set of jupyter packages running and submitted to openSUSE:Factory, as defined by the "jupyter" package (I use "python-" here, but "python3-" versions will be submitted in parallel): * python-ipython_genutils - Generic utilities copied from IPython. Upstream name: ipython_genutils * python-traitlets - A configuration system. Part of the jupyter project but usable elsewhere. Upstream name: traitlets * python-jupyter_core - The core of jupyter. All jupyter components rely on this. Useless to users on its own. Upstream name: jupyter_core * python-jupyter_client - Libraries used by jupyter clients and kernels. Useless to users on its own. Upstream name: jupyter_client * python-jupyter_ipython - IPython components. This was the "ipython" package, but, most useful stuff has been moved out of it. Now useless to users on its own. Upstream name: ipython. * python-jupyter_ipykernel - the IPython kernel for jupyter. Again, useless on its own. Upstream name: ipykernel. * python-jupyter_nbformat - API for working with the jupyter browser interface. Useless on its own. Upstream name: nbformat, but there is also a "jupyter_ nbformat" project, owned by the same group, but with no files. * python-jupyter_nbconvert - Convert jupyter browser interfaces to other formats. This is useful for users, but requires everything listed above. Upstream name: nbconvert, but there is also a "jupyter_ nbconvert" project, owned by the same group, but with no files. * python-jupyter_notebook - the jupyter browser interface. This is useful for users, but requires everything listed above. Upstream name: notebook, but there is also a "jupyter_notebook" project, owned by the same group, but with no files. * python-jupyter_console - the jupyter console interface. This is useful for users, but requires everything listed above except the notebook stuff. Upstream name: jupyter_console. * python-jupyter_qtconsole - the stand-alone qt console. This is useful for users, but requires everything listed above except the notebook stuff. Upstream name: qtconsole, but there is also a "jupyter_qtconsole" project, owned by the same group, but with no files. At this point I hope you are starting to see how naming consistency is an issue. * python-jupyter - upstream metapackage for setting up in a basic, working jupyter system. This package will provide and obsolete the existing "IPython" package, since it is the package that provides equivalent functionality. Upstream name: jupyter Once this is working, I will then get additional packages that provide existing ipython functionality working. With these in Factory we should be in a similar state to where we are now with IPython 3.x: * python-jupyter_ipywidgets - Interactive widgets for the notebook. Upstream name: ipywidgets * python-jupyter_ipyparallel - Parallel processing for jupyer. Upstream name: ipyparallel Once these are done, and a naming conventional is in the wiki, we can open things up and let people start submitting what they find useful. There are currently dozens of additional jupyter-related packages in pypi and many more coming. As for package homes, I think the best solution would be this: Generic components live in devel:languages:python / devel:languages:python3. That is the language these components are written in. Packages provided by the jupyter project should be in openSUSE:Factory, but third-party add-ons should be looked at on a case-by-case basis. Kernels for other languages should live in the home project of those languages, and be linked in devel:languages:python / devel:languages:python3. If those languages are in openSUSE:Factory, their kernel should be as well once it has a stable release. Language-specific add-ons should live on the home project of that language, and do not need to be linked anywhere else but optionally can be. Does this approach seem reasonable to everyone? Comments, criticisms, suggestions? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 10

[opensuse-packaging] Package for sale - Guake
by Bjørn Lie 21 Aug '15

21 Aug '15

X11:terminals/guake is for sale. If anyone wants to step up and take over maintenance of it feel free to request it in the devel-project. The package itself is fairly low in terms of effort needed, but as I no longer use guake myself, and hence neglect it a bit, new hands are preferd. I declined forward of guake to Leap (openSUSE 42) sr#324982, a new maintainer can reopen that of course. So if you are a Guake user who wants to see Guake in Leap, now is your time to shine. //Bjørn - Zaitor -- 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] Patch review needed.
by jcsl 20 Aug '15

20 Aug '15

Hi. I'd like to add a patch to LXPanel for it to make a systemwide themes search. I don't know neither C nor GTK so I'm not sure about the quality and possible bugs in the patch. I did my best but... https://build.opensuse.org/package/view_file/home:jcsl:test/lxpanel/lxpanel… Thanks in advance. Greetings. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 2

[opensuse-packaging] Introduce golang-packaging
by Marguerite Su 17 Aug '15

17 Aug '15

Hi, friends, Last month I saw some posts in this list complaining that our devel:languages:go is not packager friendly, eg, we don't have "golang(google.golang.org/cloud/compute/metadata)" style BuildRequires, and package names are not intuitive (not following golang's importpath so when an error about importpath occurs, packager don't know which package provides it) So I coded. https://github.com/marguerite/golang-packaging devel:languages:go/golang-packaging This is inspired by the logic behind the nodejs-packaging packge in devel:languages:nodejs. nodejs-packaging is developed by Fedora/RedHat package maintainers, using the brand-new system RPM 4.9 provides: http://www.rpm.org/wiki/PackagerDocs/DependencyGenerator Basically it has two parts: * matching rule * scripts to generate Provides/Requires When a RPM is being built, if file will install to the dir that mentioned by the regex matching rule, the self-maintained scripts will be called and the generated Provides/Requires will be attached along with the regular Provides/Requires. So I wrote two scripts: 1. golang.prov will extract importpath from specfile: "%define importpath xxx" > "%goprep xxx" > URL: xxx and all the sub-directories in /home/abuild/rpmbuild/BUILD/gocloud-%{version}(this is detected by "Source" tag), that is because both "google.golang.org/cloud" and "google.golang.org/cloud/compute/metadata" are valid importpaths in golang. 2. golang.req will extract such lines from all *.go files (except for those .go files inside examples/test directory and *_test.go files, because examples/tests are useless in production environment, with the imports inside them): * import "xxx" * import { xxx "xxx" } * import xx "xxx" these lines can actually be treated as golang's "include" or build/runtime Requires. and generate such golang() Requires. So if you're a golang packager, now you can just "BuildRequires: golang-packaging" and let my scripts to handle Provides/Requires for you automatically. with this, you can also "BuildRequires: golang(xxx)" for packages built with golang-packaging. Additional information: 1. If there're unneeded importpath in examples/tests, just leave them there, my package will skip them. If such importpath resides in main .go source codes, "%go_strip_builddep xx" in %prep step can help you strip them manually. 2. there's one shortcoming, the same as the one for nodejs-packaging: The build "success" status for a package doesn't mean the package can be installed without any problem. Because there might be non-fulfilled Requires for the package, remember to check it again using page like this: https://build.opensuse.org/package/binary/devel:languages:go/golang-org-x-t… As to package renames: I just follow the Fedora style: golang + importpath like string, eg: golang-github-golang-glog refers to github.com/golang/glog. basically importpath with ".org/.net/.com" will be okay with my package. You can refer to the golang-* packages I recently send to devel:languages:go as examples. Welcome to help golang package renaming and contribute to my package :-) Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 7

[opensuse-packaging] derived packages, e.g. openldap2-client
by Michael Ströder 17 Aug '15

17 Aug '15

HI! Could someone enlighten me why some packages are derived from others? Example: https://build.opensuse.org/package/show/network:ldap/openldap2 This already generates several different RPMs. Derived from openldap2: https://build.opensuse.org/package/show/network:ldap/openldap2-client Both packages almost use the same .spec files and generate several RPMs. Why does openldap2 not simply generate additional client RPMs? Even the OpenLDAP server uses the client libs anyway. Ciao, Michael.

2 3

[opensuse-packaging] OBS tests fail after building package
by auxsvr 16 Aug '15

16 Aug '15

Hello, I'm trying to build a package[1] that fixes several problems with google-earth. It builds fine and works locally, but the OBS performs some tests after the package is built, which fail. Since it depends on google-earth, which cannot be installed in the OBS as far as I know, is there a way to prevent these tests from running? -------- [1] https://build.opensuse.org/package/show/home:auxsvr/google-earth-fix -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 8

[opensuse-packaging] Factory -> Leap packages status monitor
by Marguerite Su 13 Aug '15

13 Aug '15

Hi, Inspired by the thread with @tiwai in M17N list, I created this: https://forum.suse.org.cn/leap.html This shows packages that are in Factory but not in Leap. The webpage generates from a ruby script from me and refreshes every 6 hours (a cron job) So packagers please help yourselves, just take a look and see if your packages are left behind. Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

10 14

[opensuse-packaging] unexpected RPATH set for x86_64
by Marguerite Su 13 Aug '15

13 Aug '15

Hi, Today I encountered this issue: https://build.opensuse.org/build/home:MargueriteSu:branches:X11:Cinnamon:Fa… there're two unexpected RPATH: -Wl,-rpath -Wl,/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 while they don't appear on i586. someone points out that it may be from pkgconfig files of the dependencies. https://bugzilla.opensuse.org/show_bug.cgi?id=902421 But I installed all the BuildRequires and ran "grep -r 'rpath' /usr/lib64/pkgconfig", it returned nothing. Anyone knows why? Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 2

Re: [opensuse-packaging] Introduce golang-packaging
by Jordi Massaguer Pla 10 Aug '15

10 Aug '15

On 07/26/2015 11:02 AM, marguerite wrote: > Hi Jordi, > > Yesterday I finished replacing go-* packages in openSUSE:Factory to > golang-* alternatives, except two packages: go-blackfriday and > go-go-md2man, which are from Docker's devel project. > > Do you want me to touch those two packages? Docker won't need to > change, but those two packages will reside in devel:languages:go from > now on with different names. > > And it seems your team want to update docker with go packages under > old names for 13.2. That is fine actually. New/old packages are > compatible. > > Marguerite Hi Marguerite, we actually submitted the packages you wrote as for the 13.2 update (more info at: https://bugzilla.novell.com/show_bug.cgi?id=938156) Thus, please go on removing the old names for factory. Please also do so in openSUSE:42 . thanks jordi > > 发自我的 iPhone > > 在 2015年7月23日，02:46，Jordi Massaguer Pla <jmassaguerpla(a)suse.de > <mailto:jmassaguerpla@suse.de>> 写道： > >> >> >> On 07/13/2015 05:14 PM, Marguerite Su wrote: >>> Hi, friends, >> >> Hi Marguerite Su, >> >> I am Jordi from the Docker Team and I am working on the docker >> packaging, which requires some go packages. >> >> First of all, sorry for not having answered your email. I've been >> very busy and hadn't look into it. You've done a great job and I am >> sure you've put a lot time and effort. kudos to you!!! >> >> All this looks very cool and I've noticed you had submit at least 20 >> packages to devel:languages:go project, using your golang-packaging tool. >> >> For packaging docker we were already using some old go packages which >> have already been submitted to openSUSE:Factory openSUSE:42 and >> released for SLE12. I have to look into the details on the >> implications of using your approach will have on the already released >> packages and on the submitted ones. >> >> Anyway, I just wanted to let you know you have not been "unnoticed". >> >> >> >> >> >> >> >>> Last month I saw some posts in this list complaining that our >>> devel:languages:go is not packager friendly, eg, we don't have >>> "golang(google.golang.org/cloud/compute/metadata <http://google.golang.org/cloud/compute/metadata>)" style >>> BuildRequires, and package names are not intuitive (not following >>> golang's importpath so when an error about importpath occurs, packager >>> don't know which package provides it) >>> >>> So I coded. >>> >>> https://github.com/marguerite/golang-packaging >>> devel:languages:go/golang-packaging >>> >>> This is inspired by the logic behind the nodejs-packaging packge in >>> devel:languages:nodejs. nodejs-packaging is developed by Fedora/RedHat >>> package maintainers, using the brand-new system RPM 4.9 provides: >>> >>> http://www.rpm.org/wiki/PackagerDocs/DependencyGenerator >>> >>> Basically it has two parts: >>> >>> * matching rule >>> * scripts to generate Provides/Requires >>> >>> When a RPM is being built, if file will install to the dir that >>> mentioned by the regex matching rule, the self-maintained scripts will >>> be called and the generated Provides/Requires will be attached along >>> with the regular Provides/Requires. >>> >>> So I wrote two scripts: >>> >>> 1. golang.prov will extract importpath from specfile: >>> >>> "%define importpath xxx" > "%goprep xxx" > URL: xxx >>> >>> and all the sub-directories in >>> /home/abuild/rpmbuild/BUILD/gocloud-%{version}(this is detected by >>> "Source" tag), that is because both"google.golang.org/cloud <http://google.golang.org/cloud>" and >>> "google.golang.org/cloud/compute/metadata <http://google.golang.org/cloud/compute/metadata>" are valid importpaths in >>> golang. >>> >>> 2. golang.req will extract such lines from all *.go files (except for >>> those .go files inside examples/test directory and *_test.go files, >>> because examples/tests are useless in production environment, with the >>> imports inside them): >>> >>> * import "xxx" >>> * import { >>> xxx >>> "xxx" >>> } >>> * import xx "xxx" >>> >>> these lines can actually be treated as golang's "include" or >>> build/runtime Requires. and generate such golang() Requires. >>> >>> So if you're a golang packager, now you can just "BuildRequires: >>> golang-packaging" and let my scripts to handle Provides/Requires for >>> you automatically. with this, you can also "BuildRequires: >>> golang(xxx)" for packages built with golang-packaging. >>> >>> Additional information: >>> >>> 1. If there're unneeded importpath in examples/tests, just leave them >>> there, my package will skip them. If such importpath resides in main >>> .go source codes, "%go_strip_builddep xx" in %prep step can help you >>> strip them manually. >>> >>> 2. there's one shortcoming, the same as the one for nodejs-packaging: >>> The build "success" status for a package doesn't mean the package can >>> be installed without any problem. Because there might be non-fulfilled >>> Requires for the package, remember to check it again using page like >>> this: >>> >>> https://build.opensuse.org/package/binary/devel:languages:go/golang-org-x-t… >>> >>> As to package renames: >>> >>> I just follow the Fedora style: golang + importpath like string, eg: >>> golang-github-golang-glog refers togithub.com/golang/glog <http://github.com/golang/glog>. basically >>> importpath with ".org/.net/.com" will be okay with my package. You can >>> refer to the golang-* packages I recently send to devel:languages:go >>> as examples. >>> >>> Welcome to help golang package renaming and contribute to my package :-) >>> >>> Marguerite >>

1 1

Re: [opensuse-packaging] Introduce golang-packaging
by Jordi Massaguer Pla 10 Aug '15

10 Aug '15

Hi, I just got back from vacations. Let me talk with my colleagues and I'll get back to you. thanks again for your work on packaging go On 07/26/2015 11:02 AM, marguerite wrote: > Hi Jordi, > > Yesterday I finished replacing go-* packages in openSUSE:Factory to > golang-* alternatives, except two packages: go-blackfriday and > go-go-md2man, which are from Docker's devel project. > > Do you want me to touch those two packages? Docker won't need to > change, but those two packages will reside in devel:languages:go from > now on with different names. > > And it seems your team want to update docker with go packages under > old names for 13.2. That is fine actually. New/old packages are > compatible. > > Marguerite > > 发自我的 iPhone > > 在 2015年7月23日，02:46，Jordi Massaguer Pla <jmassaguerpla(a)suse.de > <mailto:jmassaguerpla@suse.de>> 写道： > >> >> >> On 07/13/2015 05:14 PM, Marguerite Su wrote: >>> Hi, friends, >> >> Hi Marguerite Su, >> >> I am Jordi from the Docker Team and I am working on the docker >> packaging, which requires some go packages. >> >> First of all, sorry for not having answered your email. I've been >> very busy and hadn't look into it. You've done a great job and I am >> sure you've put a lot time and effort. kudos to you!!! >> >> All this looks very cool and I've noticed you had submit at least 20 >> packages to devel:languages:go project, using your golang-packaging tool. >> >> For packaging docker we were already using some old go packages which >> have already been submitted to openSUSE:Factory openSUSE:42 and >> released for SLE12. I have to look into the details on the >> implications of using your approach will have on the already released >> packages and on the submitted ones. >> >> Anyway, I just wanted to let you know you have not been "unnoticed". >> >> >> >> >> >> >> >>> Last month I saw some posts in this list complaining that our >>> devel:languages:go is not packager friendly, eg, we don't have >>> "golang(google.golang.org/cloud/compute/metadata <http://google.golang.org/cloud/compute/metadata>)" style >>> BuildRequires, and package names are not intuitive (not following >>> golang's importpath so when an error about importpath occurs, packager >>> don't know which package provides it) >>> >>> So I coded. >>> >>> https://github.com/marguerite/golang-packaging >>> devel:languages:go/golang-packaging >>> >>> This is inspired by the logic behind the nodejs-packaging packge in >>> devel:languages:nodejs. nodejs-packaging is developed by Fedora/RedHat >>> package maintainers, using the brand-new system RPM 4.9 provides: >>> >>> http://www.rpm.org/wiki/PackagerDocs/DependencyGenerator >>> >>> Basically it has two parts: >>> >>> * matching rule >>> * scripts to generate Provides/Requires >>> >>> When a RPM is being built, if file will install to the dir that >>> mentioned by the regex matching rule, the self-maintained scripts will >>> be called and the generated Provides/Requires will be attached along >>> with the regular Provides/Requires. >>> >>> So I wrote two scripts: >>> >>> 1. golang.prov will extract importpath from specfile: >>> >>> "%define importpath xxx" > "%goprep xxx" > URL: xxx >>> >>> and all the sub-directories in >>> /home/abuild/rpmbuild/BUILD/gocloud-%{version}(this is detected by >>> "Source" tag), that is because both"google.golang.org/cloud <http://google.golang.org/cloud>" and >>> "google.golang.org/cloud/compute/metadata <http://google.golang.org/cloud/compute/metadata>" are valid importpaths in >>> golang. >>> >>> 2. golang.req will extract such lines from all *.go files (except for >>> those .go files inside examples/test directory and *_test.go files, >>> because examples/tests are useless in production environment, with the >>> imports inside them): >>> >>> * import "xxx" >>> * import { >>> xxx >>> "xxx" >>> } >>> * import xx "xxx" >>> >>> these lines can actually be treated as golang's "include" or >>> build/runtime Requires. and generate such golang() Requires. >>> >>> So if you're a golang packager, now you can just "BuildRequires: >>> golang-packaging" and let my scripts to handle Provides/Requires for >>> you automatically. with this, you can also "BuildRequires: >>> golang(xxx)" for packages built with golang-packaging. >>> >>> Additional information: >>> >>> 1. If there're unneeded importpath in examples/tests, just leave them >>> there, my package will skip them. If such importpath resides in main >>> .go source codes, "%go_strip_builddep xx" in %prep step can help you >>> strip them manually. >>> >>> 2. there's one shortcoming, the same as the one for nodejs-packaging: >>> The build "success" status for a package doesn't mean the package can >>> be installed without any problem. Because there might be non-fulfilled >>> Requires for the package, remember to check it again using page like >>> this: >>> >>> https://build.opensuse.org/package/binary/devel:languages:go/golang-org-x-t… >>> >>> As to package renames: >>> >>> I just follow the Fedora style: golang + importpath like string, eg: >>> golang-github-golang-glog refers togithub.com/golang/glog <http://github.com/golang/glog>. basically >>> importpath with ".org/.net/.com" will be okay with my package. You can >>> refer to the golang-* packages I recently send to devel:languages:go >>> as examples. >>> >>> Welcome to help golang package renaming and contribute to my package :-) >>> >>> Marguerite >>

1 0

Fwd: Re: [opensuse-packaging] OBS tests fail after building package
by Benjamin Denisart 08 Aug '15

08 Aug '15

On 08/07/2015 03:49 PM, auxsvr wrote: > Hello, > > I'm trying to build a package[1] that fixes several problems with > google-earth. It builds fine and works locally, but the OBS performs > some tests after the package is built, which fail. Since it depends on > google-earth, which cannot be installed in the OBS as far as I know, is > there a way to prevent these tests from running? > > -------- > [1] https://build.opensuse.org/package/show/home:auxsvr/google-earth-fix You should integrate your changes directly in the google-earth package. -- 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] postfix.rpm does not install sysconfig files
by Olaf Hering 06 Aug '15

06 Aug '15

After a fresh TW install I compared /etc/sysconfig/postfix with an old installation. Most of the settings are just missing, like POSTFIX_UPDATE_MAPS= After poking around I found the value in /var/adm/fillup-templates/sysconfig.postfix, but not in /etc. And even after 'rpm -e postfix;rm /etc/sysconfig/postfix;zypper in postfix' the file is not installed. I wonder if that part of postfix.spec:%post is really correct: ... %if 0%{?suse_version} > 1210 %service_add_post %{name}.service %set_permissions %{_sbindir}/postqueue %set_permissions %{_sbindir}/postdrop %set_permissions %{_sysconfdir}/%{name}/sasl_passwd %set_permissions %{_sbindir}/sendmail %verifyscript %verify_permissions -e %{_sbindir}/postqueue %verify_permissions -e %{_sbindir}/postdrop %verify_permissions -e %{_sysconfdir}/%{name}/sasl_passwd %verify_permissions -e %{_sbindir}/sendmail %{fillup_only -y postfix} %else %{fillup_and_insserv -y postfix} %endif %{fillup_only -an mail} /sbin/ldconfig ... It seems %verifyscript creates a new section named 'verify scriptlet (using /bin/sh)', which is not executed. Olaf -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 11

[opensuse-packaging] openSUSE Leap erlang
by Matwey V. Kornilov 06 Aug '15

06 Aug '15

Dear colleagues I've just found that there is no erlang in openSUSE:42 and submitted one from Factory: https://build.opensuse.org/request/show/320821 However, it is worth to discuss to have dedicated devel project for Leap (devel:languages:erlang:Leap) in order to have there "more stable" erlang. I mean 17.5.x is still maintained after 18.x release, so sometimes we have a choice. Second. If 18.0.2 lands to Leap, we need to provide maintenance updates. Should we stick on 18.0.x or 18.x? As far as I understand that there should not be compatibility issues between erlang X.Y and X.(Y+1). -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2207@jabber.ru -- 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] filezilla: Mismatch between the program and library build versions detected
by Michael Ströder 04 Aug '15

04 Aug '15

HI! When starting filezilla (see package details below) on openSUSE 20150728 (Tumbleweed) (x86_64) it fails with this message: ---------------------------- snip ---------------------------- Fatal Error: Mismatch between the program and library build versions detected. The library used 3.0 (wchar_t,compiler with C++ ABI 1009,STL containers,compatible with 2.8), and your program used 3.0 (wchar_t,compiler with C++ ABI 1008,STL containers,compatible with 2.8). ---------------------------- snip ---------------------------- Any clue what's causing this and how to work around this? Ciao, Michael. Information for package filezilla: ---------------------------------- Repository: openSUSE-20150311-0 Name: filezilla Version: 3.11.0.2-1.3 Arch: x86_64 Vendor: openSUSE Installed: Yes Status: up-to-date Installed Size: 5.2 MiB Summary: A GUI FTP and SFTP Client Description: FileZilla is a modern and powerful FTP client for Windows and Linux. FileZilla development focuses on high usability while also supporting as many useful features as possible. FileZilla is "Open Source" under the GPL license. Some of the main features are: * Continuing interrupted up-/downloads * Managing different FTP sites * Modifiable Commands * Keep-Alive-System * Timeout detection * Firewall support * SOCKS4/5 and HTTP 1.1 proxy support * SSL support (secure connections) * SFTP support * Upload/Download queue * Drag&Drop support

3 3

[opensuse-packaging] How to avoid more undefined symbols?
by SF Markus Elfring 03 Aug '15

03 Aug '15

Hello, I came along two issues recently where symbols from C++ class libraries which were provided by specific software package versions did not fit together temporarily. Combinations: * libmodman1 / libproxy1 https://bugzilla.opensuse.org/show_bug.cgi?id=937157#c5 * yast2-core / libyui6 https://bugzilla.suse.com/show_bug.cgi?id=937665#c2 How are the chances that such name mangling changes because of application binary interface adjustments will trigger appropriate updates automatically? Do dependency descriptions need any more fine-tuning for corresponding RPM specifications? Regards, Markus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 6

[opensuse-packaging] devel-file-in-non-devel-package for golang packaging
by Matwey V. Kornilov 02 Aug '15

02 Aug '15

Hello, I see lots of [ 151s] golang-github-influxdb-influxdb.x86_64: E: devel-file-in-non-devel-package (Badness: 50) /usr/lib64/go/contrib/pkg/linux_amd64/github.com/influxdb/influxdb/cmd/influxd/restore.a I know that It can be disabled per package, but It would be great to handle golang in rpmlint in order to simplify packaging. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 1

[opensuse-packaging] Force specific Lua version as build requirement
by Green Basilisk 02 Aug '15

02 Aug '15

Hello, how do I force a specific Lua version as build requirement independently of the used openSUSE version? In Tumbleweed, 13.2, etc. the Lua package contains version 5.2. In Factory the Lua package provides version 5.3. However, the programm I want to package needs version 5.2. Using ------ BuildRequires: lua BuildRequires: lua-devel ------ works for Tumbleweed, 13.2, etc. but not for Factory. In contrast ------ BuildRequires: lua52 BuildRequires: lua52-devel ------ works only with Factory because these package are not available in the other openSUSE versions. I first tried to distinguish between Factory and Tumbleweed but that seems to be impossible. Is that correct? I also tried to query the Lua version but since subshell expansions don't work in OBS for BuildRequires (see https://en.opensuse.org/openSUSE:Specfile_guidelines#OBS_Caveat) I was not successful. My solution is now to use lua52 and lua52-devel as build requirements and to include the repository devel:languages:lua to Tumbleweed, 13.2, etc. to have packages with that name. This seems to work (see https://build.opensuse.org/package/show/home:greenbasilisk:branches:graphic…) but I don't know if that is an appropriate solution. Heinz -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 10

[opensuse-packaging] npm packaging in devel:languages:nodejs (split or integrate?)
by Marguerite Su 02 Aug '15

02 Aug '15

Hi, all, As you may noticed, npm has been splitted from nodejs main package since openSUSE 13.2. If I remembered correctly, the reason of the split given was: to get the latest updated npm. But now it has been proved that the split is a total failure. It not only increased the possibility of a broken npm in openSUSE:Factory but also increased the difficulty to maintain npm. And it can not even guarantee a latest updated npm at all. Let me explain the situation now: 0. If npm is built from the nodejs package, we only need to maintain one package. If npm is splitted as it is now, we have to maintain about 40 packages and their dependencies, it is about 100+ packages as I counted. 1. nodejs-packaging is not a tool good for aggegation. eg: if you just build one package, you can check its dependencies found by nodejs-packaging through the OBS website; but if you're going to build 100 of such packages, it's very very time-consuming for you to do that one by one. And there's no way to have all the dependencies and sub-dependencies at one time, the only similar tool existed is "npm shrinkwrap", but it requires the latest npm installed first, or it can only give the all-in-one dependecy map of the old installed npm. 2. And even this tool has conflicts with nodejs-packaging. "npm install npm" will always installs a npm. But actually nodejs's dependency checking is not as strict as nodejs-packaging. so even if you update the packages based on "npm shrinkwrap" (I don't want to mention the funny stuff like you want to update npm you have to have an updated npm installed first), nodejs-packaging will still triggers a lot of conflicts. Many of them are actually not resolveable at all, eg: package A needs 0.8 version of package C, but package B needs 1.2 version of package C, package A and B are both dependencies for npm. what should be done now? As a maintainer you have to read the git commit logs of package C to see what happened between 0.8 and 1.2, to see if it is safe to bump/downgrade version for A or B. If you're lucky enough, it can be done no matter how painful it is. But if you're not so lucky, you have to provide both 0.8 and 1.2 version, that comes update-alternatives (which is questionable because in this case 0.8 and 1.2 will be installed both, what if a file from 0.8 is used with other files from 1.2? is it safe? no one knows). 3. nodejs-packaging's check result is not shown to you unless you submit all packages to openSUSE:Factory. This means npm will be always broken in devel:languages:nodejs because no one knows which package is a dependency for npm and remember not to touch it! So if you accept a single request to update a package, it is very likely that the whole npm chain breaks. Even if the results are shown to you now, you can't be sure factory maintainers accepts your requests at the same time. That means npm in Factory is very likely to break. And as we introduced staging projects, a single request accepts much faster than 100+ requests. 4. Actually the person who proposed the split never maintain npm after 2 or 3 submits. And 100+ packages really need lots of manpower. If I want to update npm today, I can finish the work a month later if I do nothing but to update nodejs-* packages once I login to OBS. While npm will see 2 or 3 releases during that time, that means we will be always late. So here's what I want to do: 1. everything stops now, all npm dependencies will be removed from Factory (writing Obsoletes will be a lot of work, see you in a month), and npm builds from nodejs main package from now on. 2. someone steps in to maintain the packages with a program. Because it's not doable for a human being as I told above. Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 3