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
[short summary]
During the creation of Leap, I've tried to sr postgresql94-plr to Leap.
It was refused, at that time postgresql94 wasn't yet properly submitted to factory, casue 94 version was directly coming from SLE.
postgresql93-plr was submitted to Leap and accepted.
Now dust has settle.
Actually here the situation :
On Leap you can choose between postgresql 9.3 and 9.4 version.
Unfortunately for user of 9.4 they can benefit the postgresql94-plr due to the refused sr.
I would like to create a Maintenance ticket to push postgresql94-plr to Leap.
It's a non sense to tell users to broke their system by using the -devel projet.
I know how to do that for existing package, but for a non existing one.
Someone has an example of how to do this ?
Thanks.
--
Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch
openSUSE Member & Board, 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
Hello,
In my institute we are selecting the operating system and Leap 42.1 is a
strong candidate.
In the selection process we are deeply analyzing the packaging and package
management aspects. Currently we use openSUSE 11.1 and some custom GUI
packaging and installation tools based on RPM.
With the new OS we would like to follow the packaging good practices of
the distribution.
We have already tried building packages for the python projects, using the
python setup.py bdist_rpm (based on distutils), but we also wanted to
give a try to the "openSUSE:Packaging guidelines [1].
We mostly use Python and C++ projects, hosted on sourceforge/github or our
local repositories. We do want to implement Continuous Delivery, so
automatic packaging and deployment to the testing environment is crucial
for us.
Initially we do not foresee to publish our packages to the distribution,
but maybe in the future we would like to do that for some of our projects.
In your portal we have found several recommendation to use the OBS [2].
But our understanding is that OBS is just for the packages aimed to be
public. We have not found information on how to build locally packages
apart of a link to the Fedora How to create RPM packages [3]. There is
also a possibility to setup our private OBS system, but maybe it is too
complicated solution for what we need right now.
Could you provide us a guide on how to do packaging in the most compatible
with the openSUSE standards way.
Thanks a lot for your help!
Zibi
[1] https://en.opensuse.org/openSUSE:Packaging_guidelines
[2] https://en.opensuse.org/Portal:Build_Service/Documentation
[3] http://fedoraproject.org/wiki/How_to_create_an_RPM_package
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
I wrote two external Provides/Requires resolver scripts for nodejs packaging.
Usually such scripts should take what RPM pass through it, that is,
filelist of buildroot.
But:
1. I ran the script locally by passing exactly the same filelist
through, it ran fine.
2. I let the script run on OBS, it gave different result, indicating
that a nested "each" loop is not completely looped (correct: loop
14000 times; wrong: loop 19 times)
3. I modified the code, to find the filelist myself. the result is correct.
So the problem is due to what RPM pass through.
But, eg, the self found list:
/home/abuild/rpmbuild/BUILDROOT/...../gulp/package.json
the passed through list:
/home/abuild....package.json\n
the result was wrong even after I stripped '\n'.
so I wonder if there're any limits on resources in RPM dependency
resolving? like CPU usage...
Marguerite
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello,
I have tried the following queries out on package information
which is available on my openSUSE Tumbleweed system at the moment.
elfring@Sonne:~> show_names() {
> XY=$(zypper --terse search --match-words --provides "$1") && echo "$XY" | tail --lines +$(($(echo "$XY" | grep --line-number --regexp=--+ | cut --delimiter : --fields 1) + 1)) | cut --delimiter \| --fields 2
> }
elfring@Sonne:~> show_names abi
abi-compliance-checker
gimp
llvm-clang
nodejs
php5
python-base
python3-base
ruby2.1
ruby2.2
vdr
elfring@Sonne:~> show_names api | wc -l
87
Does such a display indicate further possibilities for the specification
of details around the usage of application binary interfaces
and application programming interfaces?
How do you think to improve any product descriptions which are provided
(by RPM files for example) in different degree?
Would it make sense to clarify a kind of certification mark duty
for more software components?
Regards,
Markus
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi, in hugin the internal dependency generator is off so it doesn't
provide any appdata.xml or .desktop files. How do I define
__find_provides to include both desktop-file.prov and appdata.prov?
Thanks
Dave Plater
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On 01/23/2016 03:54 PM, Matthias Mailänder wrote:
> Hi,
>
> I suggest we make tickets in the bug tracker for this. This will depend on a
> lot of sub-tasks. See also
> https://build.opensuse.org/project/show/home:Mailaender:branches:Java:packa…
> with maven-bootstrap in particular.
>
> best regards
>
> Matthias Mailänder
https://bugzilla.opensuse.org/show_bug.cgi?id=963323
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On 01/23/2016 03:54 PM, Matthias Mailänder wrote:
> Hi,
>
> I suggest we make tickets in the bug tracker for this. This will depend on a
> lot of sub-tasks. See also
> https://build.opensuse.org/project/show/home:Mailaender:branches:Java:packa…
> with maven-bootstrap in particular.
>
> best regards
>
> Matthias Mailänder
Looks like a good idea.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
I have stumbled over a small problem regarding versioned directories.
Currently, it is expected a versioned library uses a pattern like /usr/lib/
libfoo-1_2_3/bar.so. Although this allows multiple packages, it is contrary to
what some upstreams use for versioning, e.g. /usr/lib/libfoo/1.2.3/bar.so.
From an RPM perspective, both are ok, as directories can be owned by multiple
packages. rpmlint throws an "W: shlib-policy-nonversioned-dir" warning, which
is IMHO wrong.
Kind regards,
Stefan
--
Stefan Brüns / Bergstraße 21 / 52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019
work: +49 2405 49936-424
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org