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