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
Is anyone working on (or thinking of working on) making our build
process reproducible?
https://reproducible-builds.org/
It seems Debian and Fedora are already part of the project, and the
advantages are quite compelling, not just from a security perspective,
but also due to the potential savings in storage and network
consumption:
https://hackweek.suse.com/13/projects/131
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi dear rpm'ers!
Since always, having an upgrade in Mapserver ( mapserver.org ) can be a real pain when
the syntax of the mapfile change creating breakage in serving your map.
Making the changes take always a maximum of time. And sometimes you could have an old
project that will be retired in two months, when you want to start a new one on the newer
version right now ;-)
Wouldn't be a dream to have both the newer and old (still bugfix and security release)
available at the same time ? Read below, this become near a reality.
Last week, during TOSprint in Paris organized by osgeo, I've been enough lucky to spend
my time with upstream mapserver. And the request of being able to have all the supported
version would be a nice to have from upstream point of view. I've took the challenge ;-)
Here's the news.
Starting with the bad ones, mapscript part is lacking maintainers, and/or fundings.
It should be considered already deprecated, and in a near future if there's no changes
it could be move to /dev/null. If you use it, especially in a professional context I would
like to invite you to take contact with mapserver.
Due to this lack of maintenance, mapscript modules (java,perl,php,python) are not able
to have a versionned lib. As such there's no way to have 2 mapscript installed from
differents versions.
The good news, actually I've been able to build mapserver6 (6.4.3) and mapserver7 (7.0.1)
packages which works smoothly here.
https://build.opensuse.org/package/show/home:bruno_friedmann:branches:Appli…https://build.opensuse.org/package/show/home:bruno_friedmann:branches:Appli…
Before sending them to Application:Geo I would propose a period of review to the above
project. Getting your feedback there: use this mailing list or obs comment/bug link is important.
I'm not 100% satisfied by the java mascript naming libjavamapscript I would prefer to move it
to java-mapscript like the others module, but rpmlint on certain plateform like 13.2 just tag it with
10000 badness :-(
If you have a better idea for implementation, don't hesitate to speaking, or best, branch and sr ;-)
Thanks for your attention.
--
Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch
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
Really? What's special about Carlito that libreoffice cannot function without it? How is having Cantarell, DejaVu, Droid, Liberation, Noto, Stix, Oxygen and Roboto so deficient that yet another Google font package is required in order for libreoffice not to "break"?
# zypper in libreoffice-calc
...
Resolving package dependencies...
The following 44 NEW packages are going to be installed:
...google-carlito-fonts...
Continue? [y/n/? shows all options] (y): n
# zypper al google-carlito-fonts
Specified lock has been successfully added.
# zypper in libreoffice-calc
...
Problem: libreoffice-calc-5.0.4.2-4.1.x86_64 requires libreoffice = 5.0.4.2, but this requirement cannot be provided
uninstallable providers: libreoffice-5.0.4.2-4.1.x86_64[Update]
Solution 1: remove lock to allow installation of google-carlito-fonts-1.1.03.beta1-3.2.noarch[OSS]
Solution 2: do not install libreoffice-calc-5.0.4.2-4.1.x86_64
Solution 3: break libreoffice-calc-5.0.4.2-4.1.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/c] (c): 3
...
The following 13 NEW packages are going to be installed...
30 packages cannot install because yet another Google font is indispensible. :-(
--
"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
(x-posting to -factory and -packaging to inform users / -buildservice
to find solutions. Please reply to the appropriate list based on the
content of your reply, not to all!)
Hi hackers and packagers,
Since this morning, a lot of packages show status 'unresolvable
- nothing provides libldap-2.4.so.2()(64bit) needed by libcurl4'
The issue will settle itself, but it will take quite a moment
(actually, until the next snapshot will be ready).
How did this happen:
====================
openldap2 was changed in the packaging layout; so far there were 2 spec
files (openldap2 and openldap2-client). the -client part was the one
building the libraries (like libldap-2_4-2). The maintainers re-
organized this package and simplified it, now building everything from
openldap2.spec directly. This resulted in openldap2-client being
removed from openSUSE:Factory.
so, why does this impact openSUSE:Factory/snapshot ?
====================================================
The /snapshot repository copies binaries from packages in /standard. As
the package 'openldap2-client' no longer exists in /standard, all
binaries, also from /snapshot, have been removed.
What can you do *NOW* to build your project / package
=====================================================
* Not that much I'm afraid. You can try to build against
openSUSE:Factory/standard (but that will give you many more rebuilds
than you want and increase the load on OBS, thus slowing down the final
solution for everybody)
* You can wait for /standard to finish its build, pass on to openQA and
get a new /snapshot published.
A possible alternative solution:
================================
@Adrian / Buildservice team: can we possibly inject the binaries from
openldap2-client in the backend directly for /snapshot, until the next
one is published? This could give users at least a working repo back.
Other ideas are welcome of course too. In the long
Best regards,
Dominique
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi. I created a package
https://build.opensuse.org/package/show/home:rwman/progress
Currently it does not build for opensuse 42.1 with the error:
[ 33s] Package ncurses was not found in the pkg-config search path.
[ 33s] Perhaps you should add the directory containing `ncurses.pc'
[ 33s] to the PKG_CONFIG_PATH environment variable
[ 33s] No package 'ncurses' found
How can i fix it? And why it is building fine for opensuse 13.2?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
Some of you may have seen this on Google Plus, so:
Short version:
The way to package Node.js modules for openSUSE ( I say "for
openSUSE", _may_ not for self-use/happy-hacking, read below) will
change from,
"every module is a package" to "every logically reasonable bundle is a package"
or "every simple application is a package", with the help of the "npkg" tool
written by me here: https://github.com/marguerite/nodejs-packaging
This will greatly reduce the amount of nodejs packages that need maintaining.
Long version: (with "why" complaints and a simple howto)
http://marguerite.su/introducing-the-brand-new-nodejs-packaging/
Impacts:
Tumbleweed or any released product will _not_ get impacted, because
there're no nodejs module packages in them at all :-) :-(
This will affect those who package nodejs modules in their own home
(devel:languages:nodejs will be cared by myself, sadly no one steps in
for co-maintenance for almost 2 years), by providing an alternative
way.
The new tool is 99.99% compatible with the old Fedora one because I
rewrote all existing functions. So most of you can just ignore the
changes in toolkit (although something might change still).
But if, if you're interested in the bundle method, and are tired of
maintaining hundreds of packages, you can give it a try. I have strong
evidence that the new tool can reduce the packages to maintain from
400+ to less than 10. Keep focus on things you really need, why not?
Changes need for discussion:
1. The wiki needs to be updated to reflect the change in toolkit (the
old way and the new way). This will get done by myself because I live
long enough to know both methods well.
2, The nodejs naming scheme needs to be discussed.
In the past we used "nodejs-xxx" as package names. Now I myself prefer
to name bundles just as their upstream names(the old packages will
proceed with the "nodejs-" prefix).eg: jshint, jslint, coffee-script,
gulp...because in the new way, nodejs packages will be fully
functional applications, no difference with "firefox", "chromium"...
Shortcomings:
1. SLE_11_SP3 is currently not supported. I started the ruby 1.8 porting anyway.
2. Licenses may bother you.
Because it's a bundle. it contains lots of .tgz sources from different
nodejs upstreams.
npkg will create a file like "gulp.license" to gather all licenses
inside the bundle for you. But it's like this:
"BSD and MIT and ISC and Apache-2.0 and BSD-3-Clause and Apache 2.0 and Apache"
not fully compatible with openSUSE's license strings. In such case,
you may need to download the built RPM, "unrpm" it, and use shell
tools like "grep" to confirm eg
Is "BSD" "BSD-3-Clause"?
And one thing I still concern is the compatibility of the licenses. eg: Can
MIT and ISC coexist together?
3. There might be bugs that have not found by me yet. And as I'm a
newbie to ruby programming...I didn't write stuff like exceptions...so
it might be a little hard for you to debug (but you have my words that
I'll fix it ASAP if get told)
4. This tool will _not_ build native node modules (ones with .gyp
files) for you. You need to build it yourself for now :-(
Well, the old one has no such feature as well. So it might be easy to
live with it.
I may scan the source and give you some hints if there're .gyp files
existing. Later I'll add such a feature to automatically build native
modules.
Test Coverage:
I have tested it for almost a month, with 5 beta versions.
I tested it with azure module:
1377:delayed-stream
1378:mime
1379:async
1380:validator
1381:mime
1382:node-uuid
1383:extend
I think most of you will not meet such complex package...so I'd say my
tool is usable for the public now.
Glad for your feedback!
Marguerite
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi. Is there any way to know if a "BuildRequires" in my spec file was
not used in build process?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org