January 2014 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] rpmlint-mini
by Matwey V. Kornilov 18 Mar '14

18 Mar '14

Hi Dirk and all, Some time in the past, I've integrated my rpmlint check (ErlangCheck.py) to openSUSE's checks. It is in Factory's rpmlint for a long time. Now, I would like to continue and make my check available as option to maintainers in OBS. The dependencies to ErlangCheck.py are python-pybeam, python-construct and python-six. All of them are in Factory for a long time. I need to modify rpmlint-mini to pack parts of python-pybeam, python-construct in order to make ErlangCheck.py working in OBS workers. I see that rpmlint-mini.spec is full of magic. What is the preferred way to pick python modules from %python_sitelib? Should I add another deps.txt and yet another loop...? I can make this is hundred different ways but it is better to ask prior. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp:0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 3

[opensuse-packaging] krb5 dependency in Base:System
by Stephan Kulow 12 Mar '14

12 Mar '14

Hi, It's currently impossible to submit packages from Base:System due to repo-checker blocking submissions as base packages suddenly require krb5. This is due to a change in libtirpc, that creates a huge cycle. As I'm protecting Factory from having that cycle too, I block such updates. Unfortunately the check hits other packages in the cycle too, so this means: unless this change is reverted, it won't be possible to submit base packages. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

14 48

[opensuse-packaging] Adding a new package which depends on others
by Guillaume Gardet 05 Feb '14

05 Feb '14

Hi, I would like to add a new package (pocl) which depends on non-standard packages : * hwloc-devel which is in Factory and developped at devel:libraries:c_c++ * ocl-icd-devel which is in Education * opencl-headers which is in Education * uthash which is in devel:libraries:c_c++ I think devel:libraries:c_c++ or devel:tools projects may be fine for pocl package. Is there anything better? What would be the best way to integrate all of thoses deps? Not sure about the right RPM Group: 'Productivity/Other' or 'System/Libraries'? Guillaume -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 3

[opensuse-packaging] apache2-mod_authnz_external depending on Apache version
by vetter＠physik.uni-wuerzburg.de 04 Feb '14

04 Feb '14

Hi, this is probably answered before, but I didn't find anything in the archives and Packaging Guidelines. apache2-mod_authnz_external comes upstream in different versions for different apache versions: 3.3.x is for Apache 2.3/2.4 3.2.x is for Apache 2.2 Currently in https://build.opensuse.org/project/show/Apache:Modules we have version 3.2.6, working and compiling only for apache 2.2. So it does not build for newer distros, i.e. openSUSE 13.1 and newer. I branched and updated my branch to 3.3.2. It builds for the openSUSE 13.1 and newer and for most Apache_* targets. What is the best way to bring 3.2.6 for older distros and 3.3.2 for newer distros to the Repositories? I thought about including version number in the package name. That would probably mean to also change name of the existing package? Is there is a way to build different versions depending on either distribution/repository or even better depending on apache version? TIA. -- Mit freundlichen Gruessen, Andreas Vetter -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 3

[opensuse-packaging] debuginfo
by Wolfgang Rosenauer 03 Feb '14

03 Feb '14

Hi, some years ago I understood some of the stuff but apparently forgot almost everything again. I'm hunting an issue that the Firefox debugsymbols (the google-breakpad ones) which are created in the build step do not match the binaries ending up in the package. This means that crashreports sent to Mozilla cannot be decoded and are useless. Nothing changed in the packages and the way all that is handled and it worked in the past (I cannot exactly tell when it stopped working). For verifying which step of the build could be culprit I've disabled the debuginfo flag in OBS and rebuilt the package. Afterwards the breakpad symbols did match again. I've also verified that stripping the binaries via command strip does not change the ID and therefore stripping itself is not hurting the procedure. Therefore I'm pretty sure something in RPMs find-debuginfo.sh is doing something which changes the breakpad ID. I cannot tell what it is but it wasn't an issue in the past. So the following question: - what does find-debuginfo.sh do which changes the breakpad ID And as a sidequestion out of curiousity: - what is expected when the debuginfo flag is removed from OBS? Do binaries still contain debugsymbols? (apparently no) Do shared libs still contain debugsymbols? (apparently yes) Is that expected? I need to find a solution since the breakpad symbols are actually more useful for me since users don't have to do anything special (using gdb) to report crashes. But the "distro" way is to have the debuginfo packages usable with gdb. If both cannot be achieved at the same time, I'm not sure what to do. Thanks, Wolfgang -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 3

[opensuse-packaging] Can a package be updated as a newer version has been released.
by doiggl＠velocitynet.com.au 31 Jan '14

31 Jan '14

Hello Can a package be updated[1] as a newer version has been released[2] I tried the newer version and it works[3] Thanks Glenn [1]https://build.opensuse.org/package/show/system:packagemanager/smart [2] https://launchpad.net/smart/+milestone/1.4.1 https://launchpad.net/smart/trunk/1.4.1/+download/smart-1.4.1.tar.bz2 [3]https://build.opensuse.org/package/show/home:doiggl:branches:system:packa… -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 4

[opensuse-packaging] NOTE: auto-cleanup of ~:branches: projects is active now!
by Adrian Schröter 30 Jan '14

30 Jan '14

To reduce the build load of our build.opensuse.org instance we did activate the new auto-cleanup mechanism of OBS now. This means, by default all default branch projects (home:<ACCOUNT>:branches:...) get an attribute to self-destruct after a given time (currently 60 days). No panic, this is less grave as you may think now, because: * The deletion will happen via a request. If you decline that one the project will stay. * Delete requests will not created if there are still running requests involving this project. * there is the "osc undelete" command to bring the project sources back * You can Opt-Out by removing the OBS:AutoCleanup attribute This will free hopefully lots of build power and make us more responsive again :) thank you adrian -- Adrian Schroeter email: adrian(a)suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 4

[opensuse-packaging] exfat-nofuse in factory or at least consolidated in filesystem
by Bruno Friedmann 30 Jan '14

30 Jan '14

For the shake, it would be wonderful to synchronize the different offer we have on obs about exfat. For example have the best of dkms alternative available here https://build.opensuse.org/package/show/home:aevseev/exfat-nofuse-dkms or native https://build.opensuse.org/package/show/home:Akoellh:Kernelmodules/exfat-no… and the fuse exfat-utils https://build.opensuse.org/package/show/home:seife:testing/exfat-utils https://build.opensuse.org/package/view_file/home:seife:testing/fuse-exfat Would be nice to have all effort submitted to filesystems repository and then pushed to factory. Also the different packagers could work together offering a perfect need for our end-users community I know that could submit them to filesystems devel repo, but I would prefer to see a (small) debate on the pro & cons by people who knows what they are doing ;-) Truly yours. -- Bruno Friedmann openSUSE Member 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

3 5

[opensuse-packaging] Modified files? What does it mean?
by Ilya Chernykh 29 Jan '14

29 Jan '14

rpm build checks I receive the following message: [ 1168s] /usr/bin/chkstat modified files that are not properly handled! [ 1168s] this will break rpm -V, ask ro for details. What does it mean? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] Fwd: Replace setuid bit to cap_net_raw capability
by Andrei Dziahel 29 Jan '14

29 Jan '14

Hello list, I'm Ubuntu fugitive and frequent user of mtr utility (https://build.opensuse.org/package/show/network:utilities/mtr) In ubuntu mtr could be run by restricted user, but not in OpenSUSE, complaining with "unable to get raw sockets" message. By adding cap_net_raw capability to /usr/sbin/mtr with > sudo /sbin/setcap cap_net_raw+ep /usr/sbin/mtr (found in libcap-progs package) and then fixing permissions by removing suid bit and making all users run it with > sudo chmod -s+rx /usr/sbin/mtr I've managed to successfully run mtr as unprivileged user. I'm almost sure that capabilities cannot be transferred across rpm which means I should add libcap-progs as a runtime dependency, and update permissions/add capability during package installation. Am I right? Thanks in advance. -- Regards, Andrei Dziahel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 2

[opensuse-packaging] -DCMAKE_INSTALL_PREFIX does not work
by Ilya Chernykh 29 Jan '14

29 Jan '14

This problem exists in nearly every package based on cmake. When I am trying to build a cmake application for KDE3 (where it should be in /opt/kde3 prefix), it gets installed in /usr. I already abandoned several packages and in other ones I manually patched the makefiles. Is there a general way, or CMAKE is just a buggy crap? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 5

[opensuse-packaging] What's the problem with this package (autotools bug?)
by Ilya Chernykh 28 Jan '14

28 Jan '14

When building this package: https://build.opensuse.org/package/show/KDE:KDE3/yast2-control-center-qt3 I encounter an error message: [ 57s] configure.ac:18: error: AC_INIT should be called with package and version arguments [ 57s] /usr/share/aclocal-1.13/init.m4:23: AM_INIT_AUTOMAKE is expanded from... This happens only in Factory. Where's the problem? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 4

[opensuse-packaging] Question: Where do I get perl-Email-MIME-Modifier >= 1.442 rpm [which repo] ?
by doiggl＠velocitynet.com.au 25 Jan '14

25 Jan '14

Hello. I have packaged up the bugzilla package but have trouble installing it. Problem: nothing provides perl-Email-MIME-Modifier >= 1.442 needed by bugzilla-4.4.1-30.1.noarch Question: Where do I get perl-Email-MIME-Modifier >= 1.442 rpm ? Thanks Glenn So far I have done: # zypper ar http://ftp5.gwdg.de/pub/opensuse/repositories/home:/doiggl/openSUSE_13.1/ mypackages # zypper in bugzilla Loading repository data... Reading installed packages... Resolving package dependencies... Problem: nothing provides perl-Email-MIME-Modifier >= 1.442 needed by bugzilla-4.4.1-30.1.noarch Solution 1: do not install bugzilla-4.4.1-30.1.noarch Solution 2: break bugzilla-4.4.1-30.1.noarch by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/c] (c): other details: bugzilla-4.4.1-30.1.noarch.rpm 24-Jan-2014 10:43 5.4K http://ftp5.gwdg.de/pub/opensuse/repositories/home:/doiggl/openSUSE_13.1/no… Log details ########### # zypper ar http://ftp5.gwdg.de/pub/opensuse/repositories/home:/doiggl/openSUSE_13.1/ mypackages Adding repository 'mypackages' ........................[done] Repository 'mypackages' successfully added Enabled: Yes Autorefresh: No GPG check: Yes URI: http://ftp5.gwdg.de/pub/opensuse/repositories/home:/doiggl/openSUSE_13.1/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] Proper version scheme for packages from git, hg, svn, ...
by Sascha Peilicke 24 Jan '14

24 Jan '14

Hi guys, I'd like to gather some input on versioning schemes used for packaging SCM snapshots. Why do we care at all? Ignoring the source pkg and the changes file for the moment, the package version is meant to tell the user exactly which state of the software was provided to him. When you package an upstream tarball, you implicitly provide information about what was released and when. And the package build is reproducable, it won't change how often you download the tarball referenced in Source:. Thus it's enough to just have sth. like this in your spec file: Version: 1.2.3 So if you have to package a (random) SCM snapshot, you want to make sure that it's obvious which commit you picked, so that others can confirm and eventually repeat the build. Here's a small list of flavors that I've come across or used myself. Please not that I replaced the stable (upstream) version with X, since that's not the part I'm interested here. Also, the word "git" can be replaced by whatever SCM at hand: 1) X+git 2) X_20041122git 3) X+git20111213 4) X.a258.g003e7e3 5) X+git.1363873583.8dfab15 Albeit you can discuss the format differences, 2) and 3) are much better than 1) since they at least broadly state when the SCM snapshot was taken. 4) Does a better job by providing the commit number/hash but breaks RPM upgradeability. Random commit hashes aren't upgradeable right? So the best version is indeed number 5), where the first number is the commit date and the second one is the commit hash. The date assures upgradability, because it increments always linearly and the commit hash provides for reproducability. You can of course argue about dots vs, any other separating paragraph. Also, instead of "+git", you may prefer sth. different (along as it won't break RPM's version comparison mechanism). TL;DR ===== My recommendation would be to (at least loosely) follow pattern 5) versioning if you ever have to package from SCMs. While devel projects are rather free to do whatever they prefer, I'd say it's appropriate for Factory submissions. Bonus ===== There is absolutely no reason to do this manually. Use the tar_scm source service (in disabled or local_only mode !!!) if you want to fully automate this. Here are some examples: Cloud:OpenStack:Master / openstack-utils devel:languages:go / go-assert -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

21 132

[opensuse-packaging] fix needed for: directories not owned by a package:
by doiggl＠velocitynet.com.au 23 Jan '14

23 Jan '14

Hello What is the spec fix for the following: spec file: https://build.opensuse.org/package/view_file/home:doiggl/bugzilla/bugzilla.… -- Glenn [ 79s] ... running 02-check-gcc-output [ 79s] ... testing for serious compiler warnings [ 79s] (using /usr/lib/build/checks-data/check_gcc_output) [ 79s] (using //.build.log) [ 79s] ... running 03-check-binary-kernel-log [ 79s] ... running 04-check-filelist [ 79s] ... checking filelist [ 79s] bugzilla-contrib-4.2.7-50.1.noarch.rpm: directories not owned by a package: [ 79s] - /usr/share/bugzilla/contrib [ 79s] bugzilla-doc-4.2.7-50.1.noarch.rpm: directories not owned by a package: [ 79s] - /usr/share/bugzilla/docs [ 79s] - /usr/share/bugzilla/docs/en [ 79s] bugzilla-4.2.7-50.1.noarch.rpm: directories not owned by a package: [ 79s] - /etc/httpd [ 79s] - /etc/httpd/conf.d [ 79s] - /usr/share/bugzilla/contrib [ 79s] bugzilla-doc-build-4.2.7-50.1.noarch.rpm: directories not owned by a package: [ 79s] - /usr/share/bugzilla/docs [ 79s] - /usr/share/bugzilla/docs/en [ 85s] [ 73.664374] SysRq : Power Off [ 85s] [ 73.772356] reboot: Power down -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 4

[opensuse-packaging] missing lvm2-devel package
by Henrik Kuhn 20 Jan '14

20 Jan '14

Hi, I wonder why there is no officaly released openSUSE 'lvm2-devel' package available? During the packaging of the lvm2 package the header files lvm2cmd.h, lvm2app.h including the pkgconfig lvm2app.pc are explicitly deleted. Why just do not package these separately? Here is my proposal: Index: lvm2.changes =================================================================== --- lvm2.changes (revision 2) +++ lvm2.changes (revision 3) @@ -1,4 +1,10 @@ ------------------------------------------------------------------- +Sat Jan 18 21:19:31 UTC 2014 - henrik.kuhn(a)origenis.de + +- added a lvm2-devel package definition +- added %config macro before /etc/lvm/lvm.conf + +------------------------------------------------------------------- Mon Jan 6 07:43:59 UTC 2014 - dmzhang(a)suse.com - add csm_convert to lvm2-clvm package(bnc#854076) Index: lvm2.spec =================================================================== --- lvm2.spec (revision 2) +++ lvm2.spec (revision 3) @@ -189,9 +189,9 @@ rm $RPM_BUILD_ROOT/etc/lvm/cache/.cache #remove lvm-devel parts -rm -f $RPM_BUILD_ROOT/usr/include/lvm2cmd.h -rm -f $RPM_BUILD_ROOT/usr/include/lvm2app.h -rm -f $RPM_BUILD_ROOT%{_libdir}/pkgconfig/lvm2app.pc +#rm -f $RPM_BUILD_ROOT/usr/include/lvm2cmd.h +#rm -f $RPM_BUILD_ROOT/usr/include/lvm2app.h +#rm -f $RPM_BUILD_ROOT%{_libdir}/pkgconfig/lvm2app.pc #remove device-mapper man page rm -f $RPM_BUILD_ROOT/%{_mandir}/man8/dm* #remove device-mapper systemd events @@ -408,4 +408,25 @@ /usr/lib/ocf/resource.d/lvm2/cmirrord %{_mandir}/man8/cmirrord.8.gz + + +%package devel +Version: 2.02.98 +Release: 0 +Requires: lvm2 = %{version} +Summary: Development files for LVM2 +Group: Development/Libraries/C and C++ + + +%description devel +This package provides development files for the LVM2 Logical Volume Manager. + + +%files devel +%defattr(-,root,root) +/usr/include/lvm2cmd.h +/usr/include/lvm2app.h +%_libdir/pkgconfig/lvm2app.pc + + %changelog Regards, Henrik -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Help with build cycle
by Robert Schweikert 18 Jan '14

18 Jan '14

Hi, Could use some help with the following problem: Getting buildconfig from server and store to /work/rjschwei/obs/filesystems/s3fs/.osc/_buildconfig-openSUSE_13.1-x86_64 buildinfo is broken... it says: unresolvable: have choice for libss.so.2()(64bit) needed by krb5-mini: libcom_err2 libcom_err2-mini, have choice for libcom_err.so.2()(64bit) needed by krb5-mini: libcom_err2 libcom_err2-mini This occurs for filesystems:s3fs, which I am trying to update to 1.74 Help is as always appreciated. Thanks, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei(a)suse.com rschweik(a)ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 6

[opensuse-packaging] Re: RPM in openSUSE 13.1
by Bernhard Voelker 18 Jan '14

18 Jan '14

[forwarding to opensuse-packaging ML] On 01/15/2014 11:50 PM, Marco Cimmino Gibellini wrote: > Hi, > my name is Marco Cimmino and I am the main UI developer for Skype for Linux. > > I am writing to you to ask a question about an odd behaviour of rpm/package manager installed on openSUSE 13.1. > Our main problem is to add a dependency in our Skype rpm package that depends on a 32-bit libraries, regardless the > running openSUSE is either 32-bit or 64-bit. > This is easily achievable on Fedora 20 specifying in the RPM Requires field something like this: > Requires: alsa-plugins-pulseaudio(x86-32) > > As also stated in this document: > http://www.rpm.org/wiki/PackagerDocs/ArchDependencies > > However the same thing does not work on openSUSE 13.1, if I do not mention the architecture then it will pull the same > as the operating system, if I mention it then it fails to install it with unmet dependencies error. > Since rpm version is exactly the same as Fedora 20, v4.11.1, I wonder why this difference and if there is any workaround. > > I hope you can give me more insight, thank you. > > best > Marco Cimmino > ----- > Linux UI team, Skype > UI developer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

15 36

[opensuse-packaging] Using "~" in package version?
by Andrey Borzenkov 13 Jan '14

13 Jan '14

Is using something like 2.02~beta1 acceptable? Brief check suggests that RPM does support it and sorts this before 2.02, but may be there are guidelines for it? Since which openSUSE release is it supported BTW? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 4

[opensuse-packaging] Build for x86_64 platform on x86?
by Andrey Borzenkov 13 Jan '14

13 Jan '14

GRUB2 for legacy BIOS builds two EFI runtime emulation modules - 32 and 64 bits. They are used when booting OS X. As I noticed, those modules are missing in grub2 for i586 because it cannot build 64 bit module. Is it possible at all? Which packages would be need during build? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 5

Re: [opensuse-packaging] Re: Proper version scheme for packages from git, hg, svn, ...
by Jan Engelhardt 11 Jan '14

11 Jan '14

On Saturday 2014-01-11 09:29, Matwey V. Kornilov wrote: >Ok. And what version scheme should I follow? If you have not already made up your mind as to what you want (or "need"), then I would say go with the guidelines. They are there to guide. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Best practices for a library with backends?
by Martin Vidner 09 Jan '14

09 Jan '14

Hi, I am getting involved with https://github.com/libyui , the UI library powering YaST. The basic design is a core library, libyui, which provides the API but has no actual UI. One of the 3 backends, libyui-{ncurses,gtk,qt}, is needed. I am looking for examples of best practices of versioning the shared libraries and setting up the dependencies among the parts of the framework. Current problems of libyui in this area: - not being careful about the so-versioning. That is a solved problem for a single(!) library, see https://github.com/openSUSE/libzypp/blob/a01b41c7dfe42a1fae9d9431fbad61997f… - the user-facing ABI of libyui and the backend-facing ABI are not well separated. Is there any project which has figured this out? - expressing the dependency "the core lib needs at least one backend with a matching ABI" is done via the yui_backend symbol but that breaks bootstrapping the build (See Fedora 19 on https://build.opensuse.org/project/monitor/devel:libraries:libyui ) Can you point me to any projects that handle this situation (common api + backends), however well? -- Martin Vidner, Cloud & Systems Management Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu

2 1

[opensuse-packaging] Stack protector isues?
by Ilya Chernykh 09 Jan '14

09 Jan '14

What causes this package to fail for 32-bit but build for 64-bit in Factory? https://build.opensuse.org/package/show/KDE:KDE3/kdelibs3 I receive the following error message: [ 666s] /usr/lib/libc_nonshared.a(stack_chk_fail_local.oS): In function `__stack_chk_fail_local': [ 666s] /home/abuild/rpmbuild/BUILD/glibc-2.18.90/debug/stack_chk_fail_local.c:45: undefined reference to `__stack_chk_fail' [ 666s] collect2: error: ld returned 1 exit status [ 666s] Error creating ./kdeprint/management/libkdeinit_kaddprinterwizard.la. Exit status 1. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 12

[opensuse-packaging] openocd looks for home
by Matwey V. Kornilov 07 Jan '14

07 Jan '14

Hi, We have different forks of openocd package. Even I have my own with CMSIS support. But we don't have devel project for it. openocd is open on-chip debugger. It is a tool to communicate with embedded ARM-based hardware, to upload microcode and to provide interface for gdb for online debugging. I think, It is necessary to have openocd in Factory, but in any case we need devel project. I have not found appropriate project. Any ideas? Who will take care? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] Unite package 'R-base' with 'R-base-devel'
by guenter 04 Jan '14

04 Jan '14

Please transfer the files from R-base-devel in the package R-base. Why?: When you have installed R and use it, it's _most likely_ that you need an additional R-package. If you then invoke e.g. 'install.packages("maps")' you will get an error which essentially says "R.h not found" (R-packages are built from source for install). But this takes a while to find out what the problem is (google for '"R.h" fatal error opensuse'). R-base-devel is small (400K after installation; R-base has 48,6M); the additional disk space is worth the convenience of a normal R user, I feel. It avoids a lot of frustration. Or make R-base-devel a dependency for R-base. Happy New Year! guenter -- openSuse 12.3; R-base[-devel] 2.15.2-2.4.1.x86_64 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0