Hello all,
For use in libreoffice, chromium and others I've created macro that
should allow you to limit jobs based on some constraints you can set
later on in the spec to avoid OOM crashes.
The usage is pretty straight forward (Once it is accepted in
Tumbleweed):
===
BuildRequires: memory-constraints
%build
# require 2GB mem per thread
%limit_build -m 2000
make %{?_smp_mflags}
====
Here the _smp_mflags vaule for 8GB machine would be 4 while default is
number of cores (lets say 16)...
Both macros %jobs and %_smp_mflags are overriden as such the
integration should be really painless if you need to do something like
this.
Tom
Hi,
recently there have been a few updates of package to use %license for
the license files. And this seems triggering the build failures for
SLE12.
How would we cure this? Fiddling with some prjconf stuff?
thanks,
Takashi
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
There are still a large number of packages in openSUSE:Factory that
are python2-only. Some have not been touched upstream in years. We
probably should start thinking about what to do with them.
I think we should break python2-only packages into four categories:
* Those that have python3 support that just hasn't been integrated
should be updated.
* Those that upstream has indicated has python3 support in the
near-term roadmap should be kept as-is for now (or updated to the
latest version).
* Those that are python2-only and have not seen upstream activity
since 2016 should be dropped from openSUSE:Factory and dropped from
devel:languages:python after a two-week warning period.
* All others, including backports packages, should be moved to a new
subproject, devel:languages:python:legacy since they won't need many
updates or rebuilds. This project should be built but not published.
What does everyone think of this plan?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi all,
seems like something change in the vim packaging since the last
submission of vagrant to Factory, because I got errors from the
repo-checker:
<pre>
found conflict of vagrant-vim-2.0.2-7.3.noarch with
vim-8.0.1568-4.1.x86_64:
- /usr/share/vim/current [mode mismatch: d755 root:root, l777
root:root -> vim80]
</pre>
Seems to boil down to this line in vagrant's spec file:
%{!?vim_data_dir:%global vim_data_dir /usr/share/vim/current/}
/usr/share/vim/current is a link to /usr/share/vim/vim80 in Factory,
so I could hardcode that path for Factory and leave it like it is on
all other build targets. But I would rather like to avoid that and use
the officially recommended way to do that, if there is one.
Any ideas?
vim-plugins uses this, is this recommended?
%define vimplugin_dir %{_datadir}/vim/site
https://build.opensuse.org/package/view_file/openSUSE:Leap:15.0/vim-plugins…
Kind Regards,
Johannes
On Tue, May 22, 2018 at 2:46 AM, Joachim Wagner
<jwagner(a)computing.dcu.ie> wrote:
>> [...] last update 2009, last update 2014... Nothing is
>> so bugfree to not varrant even one bugfix release :).
>
> In well tested/aged software, remaining bugs only show when new, unexpected
> input arrives or the environment changes. 9 years without a bug report is
> possible for applications with a narrow use case and a small user base.
>
> Joachim
devel:languages:python:singlespec-staging has most of the packages
that need to be converted. In fact most of them have already been
automatically converted, they just need to be checked since the
automatic conversion isn't perfect.
But that assumes the package supports python 3 to begin with. There
are lots of packages that don't support python 3 and almost certainly
never will because they haven't been touched upstream in years. Those
are what my current proposal focuses on.
devel:languages:python:misc has packages that are not in or submitted
to openSUSE:factory. Many of those are in pretty good shape, often
just needing and update and a license macro in the files. Others,
however, haven't been updated in years.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On Tue, May 22, 2018 at 3:21 AM, Joachim Wagner
<jwagner(a)computing.dcu.ie> wrote:
>> * Those that are python2-only and have not seen upstream activity
>> since 2016 should be dropped [...]
>> [...] after a two-week warning period.
>
> Where can we see a list of all affected packages, including packages that
> depend on an affected package? Similarly to Larry for VirtualBox, users with
> good python knowledge might step forward to volunteer converting their
> favourite package to python 3.
>
> Joachim
devel:languages:python:singlespec-staging has most of the packages
that need to be converted. In fact most of them have already been
automatically converted, they just need to be checked since the
automatic conversion isn't perfect.
But that assumes the package supports python 3 to begin with. There
are lots of packages that don't support python 3 and almost certainly
never will because they haven't been touched upstream in years. Those
are what my current proposal focuses on.
devel:languages:python:misc has packages that are not in or submitted
to openSUSE:factory. Many of those are in pretty good shape, often
just needing and update and a license macro in the files. Others,
however, haven't been updated in years.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
On Tue, May 22, 2018 at 11:26 AM, Matěj Cepl <mcepl(a)cepl.eu> wrote:
> On 2018-05-21, 14:31 GMT, Todd Rme wrote:
>> * Those that are python2-only and have not seen upstream
>> activity since 2016 should be dropped from openSUSE:Factory
>> and dropped from devel:languages:python after a two-week
>> warning period.
>>
>> What does everyone think of this plan?
>
> I agree, but I would suggest to be even more aggressive on less
> used packages (measured by the number of updates and not being
> required).
>
> Best,
>
> Matěj
That would be fine, but if we went that route there would need to be a
project for python packages that aren't in factory and that is
published so people could use it. That could involve simply enabling
publishing on devel: languages:python:misc. I'm that case I would
probably move all the unmaintained packages in dlp:misc to dlp:legacy
first.
--
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 just got submission auto rejected because of failure to verify sources:
> Visit https://build.opensuse.org/request/show/611168
>
> State of request 611168 was changed by factory-auto:
> review -> declined
>
> Comment:
> Output of check script:
> Source validator failed. Try "osc service localrun source_validator"
>
> gpg: key 3EB073EC: no valid user IDs
> gpg: Signature made Sat May 19 01:31:20 2018 CEST using ? key ID 3EB073EC
> gpg: Can't check signature: Invalid public key algorithm
> (E) signature Mesa/mesa-18.1.0.tar.xz.sig does not validate
It fails with "Invalid public key algorithm". The algorithm in this case is
number 22, which is EdDSA. It should be supported since gpg 2.1.0.
We have 2.0.24 in Leap 42.3 and 2.2.7 in Factory. Which one is used by the
factory-auto checker?
Thanks,
Michal Srb
I would like to play with PostgREST software
postgrest.org
and https://github.com/PostgREST/postgrest
But I'm completely n00bs in term of ghc-* packaging or build.
So yes I can fire search engine and like a bee try flower one by one, but
perhaps around we have a smart soul that can drive me by giving an ordered
list of howto, todo.
Thanks.
--
Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch
Bareos Partner, openSUSE Member, fsfe supporter
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