Hello,
is there a simple way to force the GCC version used to build a package?
openSUSE Leap 42.2 for example
uses GCC 4.8 as default compiler, but also provides packages for GCC
5.3. Simply using BuildRequires gcc5
pulls gcc5 in but still uses gcc48 to build the package (especially in
Build Service).
So is there maybe some Buid Service or spec file switch (bcond) to
select the used GCC version?
Best greetings
Matthias Fehring
P.S. Not sure if it is a problem with my browser settings, but when I
try to search lists.opensuse.org, it is not possible
for me to limit the results to a specific list. Even if I set one, I get
results from all lists, what makes searching almost
impossible, because most results are commit messages.
--
Das Gesetz hat zum Schneckengang verdorben, was Adlerflug geworden wäre.
(Friedrich Schiller - Die Räuber)
www.buschmann23.de
GPG-Key: 0x614C3258
GPG Fingerprint: D786 DDF8 4CA9 00BC CDE0 9A5F CCC5 125D 6E87 D4FC
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
I have just implemented some changes for the various factory targets
of devel:languages:python. Most importantly, the
openSUSE_Factory_ARM, openSUSE_Factory_PowerPC, and
openSUSE_Factory_zSystems build targets have been rolled into the
openSUSE_Tumbleweed build target. They are now architectures of
openSUSE_Tumbleweed rather than stand-alone repositories. The
existing repositories are still there. Assuming there are no problems
they will be disabled on in 2 days (Sunday, April 2) and will be
deleted in one week (Friday, April 7 2017).
Second, the opensuse_factory_staging build target has already been
deleted. It was purely a testing repository, so nobody should have
been using it to begin with.
Thank you,
Todd
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
I am a bit unclear about the rules for when build packages are pushed
to repositories. I have been told that it only occurs for a given
build target when all architectures for that target have finished
building. However, when I look at download.opensuse.org, it seems
packages are getting pushed from one architecture while another is
still building according to build.opensuse.org.
So I was hoping to get a better understanding of how OSC decides
whether to publish a package. It is important because it has an
impact on how we structure our build targets.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi, I've been running around in circles trying to fix
multimedia:libs/libdbus-c++'s gcc7 build errors, in home:plater. I fixed
one which was a type conversion error but I'm struggling with this:
In file included from ../../include/dbus-c++/server.h:34:0,
from ../../include/dbus-c++/dbus.h:33,
from propsgs-server.h:4,
from propsgs-server.cpp:1:
../../include/dbus-c++/dispatcher.h: In static member function 'static
void DBus::Threading<Mx, Cv>::init()':
../../include/dbus-c++/dispatcher.h:262:5: error: no matching function
for call to '_init_threading(DBus::Mutex* (&)(), void (&)(DBus::Mutex*),
void (&)(DBus::Mutex*), void (&)(DBus::Mutex*), DBus::CondVar* (&)(),
void (&)(DBus::CondVar*), void (&)(DBus::CondVar*, DBus::Mutex*), bool
(&)(DBus::CondVar*, DBus::Mutex*, int), void (&)(DBus::CondVar*), void
(&)(DBus::CondVar*))'
);
^
../../include/dbus-c++/dispatcher.h:247:13: note: candidate: void
DBus::_init_threading()
void DXXAPI _init_threading();
^~~~~~~~~~~~~~~
../../include/dbus-c++/dispatcher.h:247:13: note: candidate expects 0
arguments, 10 provided
../../include/dbus-c++/dispatcher.h:249:13: note: candidate: void
DBus::_init_threading(DBus::MutexNewFn, DBus::MutexFreeFn,
DBus::MutexLockFn, DBus::MutexUnlockFn, DBus::CondVarNewFn,
DBus::CondVarFreeFn, DBus::CondVarWaitFn, DBus::CondVarWaitTimeoutFn,
DBus::CondVarWakeOneFn, DBus::CondVarWakeAllFn) <near match>
void DXXAPI _init_threading(
^~~~~~~~~~~~~~~
propsgs-server.cpp doesn't even call DBus::_init_threading() and
although searching brings nothing up, if this isn't a gcc7 bug.
These problems only occur in tests and examples so I can disable them
but I would really like to understand this build error.
Thanks
Dave P
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Dear All,
I'm trying to build and package openbabel. It needs the "RUNPATH" tag to run correctly or the "obabel" command will not find the plugin directories. Openbabel uses CMAKE and on OBS
"-DCMAKE_SKIP_RPATH=ON" is set automatically by the %cmake marco. I can use "-DCMAKE_C_FLAGS="-Wl,-rpath={%_libdir}" and "-DCMAKE_CXX_FLAGS=-Wl,-rpath={%_libdir}" to force passing the flags to gcc and
build with RUNPATH on my local computer directly (without using "osc build "). However it gcc will just ignore the "-Wl,-rpath" flag when I use "osc build" or the online building service and no
RUNPATH information is written to the binary and .so files.
Does any one know why gcc behaves differently like this (invoke directly vs via OBS) and how to insert the "RUNPATH" information into the final .rpm files?
Thanks and best wishes,
Xing
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hallo Frank,
Am Montag, 27. März 2017, 14:47:37 CEST schrieb Frank Schreiner:
> On Sonntag, 26. März 2017 10:48:52 CEST you wrote:
> > Am Sonntag, 26. März 2017, 10:17:28 CEST schrieb Adrian Schröter:
> > > On Sonntag, 26. März 2017, 09:56:06 CEST wrote Axel Braun:
> > > > Morning all,
> > > >
> > > > does anyone know of an OBS Service to pull sources from bitbucket?
> > > > I had a look at
> > > > http://openbuildservice.org/help/manuals/obs-reference-guide/
> > > > cha.obs.source_service.html
> > > > but there is nothing listed - overview of available sources would be
> > > > great!
> > >
> > > It is not supported yet, but it should not be too hard to add.
> > >
> > > Just have a look at the tar/obs_scm service. But please look in this
> > > repo
> > >
> > > here atm:
> > > https://github.com/M0ses/obs-service-tar_scm/
> >
> > Thanks Adrian, that helped a lot!
> > Bitbucket talks hg, so that helps as well
> >
> > First test was half way successful, I could clone the source tree, but the
> > service was looking for a 'hgreview':
> > ...
> > Command failed(255): "*** failed to import extension hgreview: No module
> > named hgreview\nhg: parse error at 0: syntax error in revset '*** failed
> > to
> > import extension hgreview: No module named hgreview\n327'\n"
> > Aborting: service call failed: /usr/lib/obs/service/tar_scm --scm hg
> > --url
> > https://bitbucket.org/jonaswolz/yajhfc --filename yajhfc --extension
> > tar.bz
> > -- outdir
> > /home/docb/buildservice/home:DocB/yajhfc/tmpFeOoUT.tar_scm.service ....
> >
> > So is OBS Service expecting a module hgreview, or does the service need to
> > import this (python) module?
>
> No, as far as I can see obs-service-tar_scm is only expecting a working "hg"
> command installed. We are not using any hg related python libs.
>
> The following hg calls are executed by tar_scm
>
> ['hg', 'update', self.revision],
> ['hg', 'clone', self.url, self.clone_dir]
> ['hg', 'pull'], cwd=self.clone_dir,
> ['hg', 'id', '-n'], self.clone_dir)[1]
> ['hg', 'log', ...]
>
> for more information have a look into
>
> /usr/lib/obs/service/TarSCM/scm/hg.py
>
> For me, it looks like a broken installation of hg tools, as all of the above
> commands worked well on our appliance.
mercurial is installed and working. I can clone a git repositry from
bitbucket, no problem
when I run hg clone manually:
hg clone https://bitbucket.org/jonaswolz/yajhfc
*** failed to import extension hgreview: No module named hgreview
So, for whatever reason my installation asks for this hgreview (funny enough,
I had packed this some time ago myself)
https://build.opensuse.org/package/show/devel:tools:scm/hgreview
As this is now fixed, the service file works as well :-)
Now I need to find out how to get the version number (0.6.1) into the filename -
currently it seems to set the revision (327)
Cheers
Axel
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
don't think it is a good idea to have several packages owning 'same'
directory, isn't it ?
ovhpc-01:/usr/lib/tmpfiles.d # rpm -q --whatprovides $(pwd)
dmraid-1.0.0.rc16-34.3.x86_64
clamav-0.99.2-25.1.x86_64
amavisd-new-2.8.1-11.1.x86_64
screen-4.0.4-21.2.x86_64
lvm2-2.02.120-72.8.x86_64
dirmngr-1.1.1-10.1.x86_64
systemd-228-135.1.x86_64
which one is the correct one ?
and how to fix build error:
[ 26s] xyzserver-1.67-0.x86_64.rpm: directories not owned by a package:
[ 26s] - /usr/lib/tmpfiles.d
without using...
%dir %{_prefix}/lib/tmpfiles.d
...and producing a further package providing same DIR.
Cheers
--
Christian
------------------------------------------------------------
https://join.worldcommunitygrid.org?recruiterId=177038
------------------------------------------------------------
http://www.sc24.de - Sportbekleidung
------------------------------------------------------------
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello,
Have you a link to the source code which builds the iso[1] cd and links in
the oss and non-oss parts to the build.
It has links to
/non-oss/
/oss/
Questions:
- which files establish the links used in the built iso for /oss/ and
/non-oss/?
- Have you a link to a build log of a sucessful iso build ?
Thanks
--Glenn
[1]
e.g
release for:
http://ftp.gwdg.de/pub/opensuse/distribution/leap/42.2/iso/openSUSE-Leap-42…
it has links for oss and non-oss in iso
# other
https://en.opensuse.org/Portal:Factory
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi guys,
I just stumbled upon the python-python-axolotl package in d:l:p today.
I linkpac'd it and it built, but was not enough to fulfill a
dependency (gajim-plugin-gajim-omemo needs the axolotl stuff). I
checked the spec and found a mismatch:
devel:languages:python/python-python-axolotl
The package is called python-python-axolotl
The spec is called python-python-axolotl.spec
In the spec, the name of the package is python-python_axolotl (note
the "_" instead of the "-" ).
Is there any reason for that?
I changed my copy to have the same name in the spec as the package,
and it builds and it works. (I also updated it to 0.1.39, but that's
just a side note).
If desired, I can sr it to d:l:p.
But maybe there should be an additional "Obsoletes
python-python_axolotl" in there, to make sure the transition smooth.
Johannes