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
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
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
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
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
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
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
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