December 2013 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] d:l:p : drop-in replacement for python-gmp
by denisart benjamin2 11 Dec '13

11 Dec '13

Hello everyone, I wan't to add a package in d:l:p, python-gmp2 which is maintained, and provides more functions like support for MPFR but a drop-in replacement for python-gmp as it provides same libraries name/function. My idea is to upload package and remove python-gmp. Doesit would pose problem to someone ? Regards. Benjamin -- 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] How to use package from another repo from build?
by Andrey Borzenkov 11 Dec '13

11 Dec '13

Let's say I want to test whether change in one package A will fix build pf package B. I branch both packages: osc branch devel1 A osc branch devel2 B hack A and commit. How can I now build B in home:me:branches:devel2 against package home:me:branches:devel1/A *and* the remaining of original repos, normally used by B? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 2

[opensuse-packaging] Packages failing to link
by Michael Matz 10 Dec '13

10 Dec '13

Hello, the last binutils update broke linking of executables in some packages. E.g. php5. The symptom looks like this: $ gcc -o conftest conftest.c -lc-client -lssl -lpam /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64/libc-client.so: undefined reference to `pam_start' So an application linking against some libx (c-client above) needing symbols of liby (libpam above), where libx itself isn't linked against liby. I.e. it's expected that all users of libx need to link against liby themself. This situation _is_ normally okay. Except that the recent binutils (in connection with link with --as-needed which is the default in our build-system) update broke it when those symbols are only provided in a versioned variant (like the pam symbols from libpam.so). There's a work-around, namely explicitely linking against liby when producing libx. Otherwise you'll have to wait for an updated and fixed binutils. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 5

[opensuse-packaging] Ghost (the blogging platform) for openSUSE
by Sascha Manns 09 Dec '13

09 Dec '13

Hello list, actually i'm working on a package which provides Ghost (https://ghost.org/) for openSUSE. My workspace is there: https://ghost.org/ Maybe anyone want's to have a look on this? Specially the init-files aren't my strengh. I'm enjoying your feedback... -- Sincerly yours Sascha Manns (bdvb) openSUSE Packager / Membership team http://saigkill.homelinux.net -- 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: Request 209576: Review wanted
by Stephan Kulow 07 Dec '13

07 Dec '13

Hi, I'm in the process of replacing Hermes mails by built in OBS notifications and to avoid any surprises on your side: here is an example mail in case you want to prepare your mail filters - or have other wishes on their headers (or content). I basically tried to mimic what bugzilla adds in the mail headers. It will be possible to disable notifications in OBS, but we're not sure yet how and when it will be ready. So I will roll this out very slowly :) Greetings, Stephan

4 6

[opensuse-packaging] Base:System/apport upstream update
by Bruno Friedmann 07 Dec '13

07 Dec '13

apport has an upstream update. (from 0.114 to 2.12.7) Lot's of changes there, and I will not be able to maintain it any longer. If you have some python packaging skill and are interested to maintain it, it's the perfect time to stand up :-) Thanks for your attention. -- 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

2 1

[opensuse-packaging] request to unlock x11vnc package
by Gábor Nyers 02 Dec '13

02 Dec '13

Hi, I've noticed that the x11vnc package is locked in 13.1 on all architectures and ports. https://build.opensuse.org/package/show/openSUSE:13.1/x11vnc Is it possible to unlock and publish it? Thanks, Gábor -- 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] noarch (sub-)package with ELF files in it
by Andrey Borzenkov 01 Dec '13

01 Dec '13

Background. Currently grub2 is split between grub2 containing user level utilities (should probably be really called grub2-tools or similar) and subpackages for each platform that contain boot-time files (kernel and modules). The actual bootloader binary for each platform is built at run time from those files. From currently running OS PoV those modules are simply opaque data. They are *never* executed on current OS and grub tools that use them to build executable image work identically on every platform. I.e. you can use grub2-mkimage to built usable grub executable (core.img) for SPARC, PPC64 or ARM while being on i386 system as long as files for these platforms are present. Built grub executable will be exactly identical independently of host OS architecture used to create it. Currently all grub2 subpackages are arch-dependent. This already means we have two absolutely identical packages - grub2-i386-pc for i386 and x86_64 (grub2 run-time on legacy BIOS is always 32 bit). As long as this was the only overlap this could be ignored. But now upstream added native support for Xen PV guests (a.k.a. pvgrub2). grub2 core.img must match guest architecture; which would mean that we'd need two *identical* subpackages for each i386 and x86_64 and possibly for other archs (ARM?) So I'm looking at making those subpackages noarch. That would reduce build time (could skip building some of them) and space (omitting identical packages). In principle from pure RPM PoV it works without problems. But our build tools get confused. The problems I hit so far. 1. rpmlint complaints about arch-independent-package-contains-binary-or-object. 2. (special case) rpmlint complaints about suse-filelist-forbidden-noarch due to /usr/lib64/efi/grub.efi - our signed EFI bootloader. Providing rpmlintrc unfortunately does not help for x86_64 case - when package is signed it is apparently being run through rpmlint as extra step *after* being built and fails because rpmlintrc is ignored. For 2 it probably makes sense to split binary in separate subpackage anyway. But for 1? So is it possible to do it? Would it be OK according to policies? Clean way to do it? You can see current work in home:arvidjaar:grub2-next:noarch/grub2 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1