August 2015 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] OBS tests fail after building package
by auxsvr 16 Aug '15

16 Aug '15

Hello, I'm trying to build a package[1] that fixes several problems with google-earth. It builds fine and works locally, but the OBS performs some tests after the package is built, which fail. Since it depends on google-earth, which cannot be installed in the OBS as far as I know, is there a way to prevent these tests from running? -------- [1] https://build.opensuse.org/package/show/home:auxsvr/google-earth-fix -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 8

[opensuse-packaging] Factory -> Leap packages status monitor
by Marguerite Su 13 Aug '15

13 Aug '15

Hi, Inspired by the thread with @tiwai in M17N list, I created this: https://forum.suse.org.cn/leap.html This shows packages that are in Factory but not in Leap. The webpage generates from a ruby script from me and refreshes every 6 hours (a cron job) So packagers please help yourselves, just take a look and see if your packages are left behind. Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

10 14

[opensuse-packaging] unexpected RPATH set for x86_64
by Marguerite Su 13 Aug '15

13 Aug '15

Hi, Today I encountered this issue: https://build.opensuse.org/build/home:MargueriteSu:branches:X11:Cinnamon:Fa… there're two unexpected RPATH: -Wl,-rpath -Wl,/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 while they don't appear on i586. someone points out that it may be from pkgconfig files of the dependencies. https://bugzilla.opensuse.org/show_bug.cgi?id=902421 But I installed all the BuildRequires and ran "grep -r 'rpath' /usr/lib64/pkgconfig", it returned nothing. Anyone knows why? Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 2

Re: [opensuse-packaging] Introduce golang-packaging
by Jordi Massaguer Pla 10 Aug '15

10 Aug '15

On 07/26/2015 11:02 AM, marguerite wrote: > Hi Jordi, > > Yesterday I finished replacing go-* packages in openSUSE:Factory to > golang-* alternatives, except two packages: go-blackfriday and > go-go-md2man, which are from Docker's devel project. > > Do you want me to touch those two packages? Docker won't need to > change, but those two packages will reside in devel:languages:go from > now on with different names. > > And it seems your team want to update docker with go packages under > old names for 13.2. That is fine actually. New/old packages are > compatible. > > Marguerite Hi Marguerite, we actually submitted the packages you wrote as for the 13.2 update (more info at: https://bugzilla.novell.com/show_bug.cgi?id=938156) Thus, please go on removing the old names for factory. Please also do so in openSUSE:42 . thanks jordi > > 发自我的 iPhone > > 在 2015年7月23日，02:46，Jordi Massaguer Pla <jmassaguerpla(a)suse.de > <mailto:jmassaguerpla@suse.de>> 写道： > >> >> >> On 07/13/2015 05:14 PM, Marguerite Su wrote: >>> Hi, friends, >> >> Hi Marguerite Su, >> >> I am Jordi from the Docker Team and I am working on the docker >> packaging, which requires some go packages. >> >> First of all, sorry for not having answered your email. I've been >> very busy and hadn't look into it. You've done a great job and I am >> sure you've put a lot time and effort. kudos to you!!! >> >> All this looks very cool and I've noticed you had submit at least 20 >> packages to devel:languages:go project, using your golang-packaging tool. >> >> For packaging docker we were already using some old go packages which >> have already been submitted to openSUSE:Factory openSUSE:42 and >> released for SLE12. I have to look into the details on the >> implications of using your approach will have on the already released >> packages and on the submitted ones. >> >> Anyway, I just wanted to let you know you have not been "unnoticed". >> >> >> >> >> >> >> >>> Last month I saw some posts in this list complaining that our >>> devel:languages:go is not packager friendly, eg, we don't have >>> "golang(google.golang.org/cloud/compute/metadata <http://google.golang.org/cloud/compute/metadata>)" style >>> BuildRequires, and package names are not intuitive (not following >>> golang's importpath so when an error about importpath occurs, packager >>> don't know which package provides it) >>> >>> So I coded. >>> >>> https://github.com/marguerite/golang-packaging >>> devel:languages:go/golang-packaging >>> >>> This is inspired by the logic behind the nodejs-packaging packge in >>> devel:languages:nodejs. nodejs-packaging is developed by Fedora/RedHat >>> package maintainers, using the brand-new system RPM 4.9 provides: >>> >>> http://www.rpm.org/wiki/PackagerDocs/DependencyGenerator >>> >>> Basically it has two parts: >>> >>> * matching rule >>> * scripts to generate Provides/Requires >>> >>> When a RPM is being built, if file will install to the dir that >>> mentioned by the regex matching rule, the self-maintained scripts will >>> be called and the generated Provides/Requires will be attached along >>> with the regular Provides/Requires. >>> >>> So I wrote two scripts: >>> >>> 1. golang.prov will extract importpath from specfile: >>> >>> "%define importpath xxx" > "%goprep xxx" > URL: xxx >>> >>> and all the sub-directories in >>> /home/abuild/rpmbuild/BUILD/gocloud-%{version}(this is detected by >>> "Source" tag), that is because both"google.golang.org/cloud <http://google.golang.org/cloud>" and >>> "google.golang.org/cloud/compute/metadata <http://google.golang.org/cloud/compute/metadata>" are valid importpaths in >>> golang. >>> >>> 2. golang.req will extract such lines from all *.go files (except for >>> those .go files inside examples/test directory and *_test.go files, >>> because examples/tests are useless in production environment, with the >>> imports inside them): >>> >>> * import "xxx" >>> * import { >>> xxx >>> "xxx" >>> } >>> * import xx "xxx" >>> >>> these lines can actually be treated as golang's "include" or >>> build/runtime Requires. and generate such golang() Requires. >>> >>> So if you're a golang packager, now you can just "BuildRequires: >>> golang-packaging" and let my scripts to handle Provides/Requires for >>> you automatically. with this, you can also "BuildRequires: >>> golang(xxx)" for packages built with golang-packaging. >>> >>> Additional information: >>> >>> 1. If there're unneeded importpath in examples/tests, just leave them >>> there, my package will skip them. If such importpath resides in main >>> .go source codes, "%go_strip_builddep xx" in %prep step can help you >>> strip them manually. >>> >>> 2. there's one shortcoming, the same as the one for nodejs-packaging: >>> The build "success" status for a package doesn't mean the package can >>> be installed without any problem. Because there might be non-fulfilled >>> Requires for the package, remember to check it again using page like >>> this: >>> >>> https://build.opensuse.org/package/binary/devel:languages:go/golang-org-x-t… >>> >>> As to package renames: >>> >>> I just follow the Fedora style: golang + importpath like string, eg: >>> golang-github-golang-glog refers togithub.com/golang/glog <http://github.com/golang/glog>. basically >>> importpath with ".org/.net/.com" will be okay with my package. You can >>> refer to the golang-* packages I recently send to devel:languages:go >>> as examples. >>> >>> Welcome to help golang package renaming and contribute to my package :-) >>> >>> Marguerite >>

1 1

Re: [opensuse-packaging] Introduce golang-packaging
by Jordi Massaguer Pla 10 Aug '15

10 Aug '15

Hi, I just got back from vacations. Let me talk with my colleagues and I'll get back to you. thanks again for your work on packaging go On 07/26/2015 11:02 AM, marguerite wrote: > Hi Jordi, > > Yesterday I finished replacing go-* packages in openSUSE:Factory to > golang-* alternatives, except two packages: go-blackfriday and > go-go-md2man, which are from Docker's devel project. > > Do you want me to touch those two packages? Docker won't need to > change, but those two packages will reside in devel:languages:go from > now on with different names. > > And it seems your team want to update docker with go packages under > old names for 13.2. That is fine actually. New/old packages are > compatible. > > Marguerite > > 发自我的 iPhone > > 在 2015年7月23日，02:46，Jordi Massaguer Pla <jmassaguerpla(a)suse.de > <mailto:jmassaguerpla@suse.de>> 写道： > >> >> >> On 07/13/2015 05:14 PM, Marguerite Su wrote: >>> Hi, friends, >> >> Hi Marguerite Su, >> >> I am Jordi from the Docker Team and I am working on the docker >> packaging, which requires some go packages. >> >> First of all, sorry for not having answered your email. I've been >> very busy and hadn't look into it. You've done a great job and I am >> sure you've put a lot time and effort. kudos to you!!! >> >> All this looks very cool and I've noticed you had submit at least 20 >> packages to devel:languages:go project, using your golang-packaging tool. >> >> For packaging docker we were already using some old go packages which >> have already been submitted to openSUSE:Factory openSUSE:42 and >> released for SLE12. I have to look into the details on the >> implications of using your approach will have on the already released >> packages and on the submitted ones. >> >> Anyway, I just wanted to let you know you have not been "unnoticed". >> >> >> >> >> >> >> >>> Last month I saw some posts in this list complaining that our >>> devel:languages:go is not packager friendly, eg, we don't have >>> "golang(google.golang.org/cloud/compute/metadata <http://google.golang.org/cloud/compute/metadata>)" style >>> BuildRequires, and package names are not intuitive (not following >>> golang's importpath so when an error about importpath occurs, packager >>> don't know which package provides it) >>> >>> So I coded. >>> >>> https://github.com/marguerite/golang-packaging >>> devel:languages:go/golang-packaging >>> >>> This is inspired by the logic behind the nodejs-packaging packge in >>> devel:languages:nodejs. nodejs-packaging is developed by Fedora/RedHat >>> package maintainers, using the brand-new system RPM 4.9 provides: >>> >>> http://www.rpm.org/wiki/PackagerDocs/DependencyGenerator >>> >>> Basically it has two parts: >>> >>> * matching rule >>> * scripts to generate Provides/Requires >>> >>> When a RPM is being built, if file will install to the dir that >>> mentioned by the regex matching rule, the self-maintained scripts will >>> be called and the generated Provides/Requires will be attached along >>> with the regular Provides/Requires. >>> >>> So I wrote two scripts: >>> >>> 1. golang.prov will extract importpath from specfile: >>> >>> "%define importpath xxx" > "%goprep xxx" > URL: xxx >>> >>> and all the sub-directories in >>> /home/abuild/rpmbuild/BUILD/gocloud-%{version}(this is detected by >>> "Source" tag), that is because both"google.golang.org/cloud <http://google.golang.org/cloud>" and >>> "google.golang.org/cloud/compute/metadata <http://google.golang.org/cloud/compute/metadata>" are valid importpaths in >>> golang. >>> >>> 2. golang.req will extract such lines from all *.go files (except for >>> those .go files inside examples/test directory and *_test.go files, >>> because examples/tests are useless in production environment, with the >>> imports inside them): >>> >>> * import "xxx" >>> * import { >>> xxx >>> "xxx" >>> } >>> * import xx "xxx" >>> >>> these lines can actually be treated as golang's "include" or >>> build/runtime Requires. and generate such golang() Requires. >>> >>> So if you're a golang packager, now you can just "BuildRequires: >>> golang-packaging" and let my scripts to handle Provides/Requires for >>> you automatically. with this, you can also "BuildRequires: >>> golang(xxx)" for packages built with golang-packaging. >>> >>> Additional information: >>> >>> 1. If there're unneeded importpath in examples/tests, just leave them >>> there, my package will skip them. If such importpath resides in main >>> .go source codes, "%go_strip_builddep xx" in %prep step can help you >>> strip them manually. >>> >>> 2. there's one shortcoming, the same as the one for nodejs-packaging: >>> The build "success" status for a package doesn't mean the package can >>> be installed without any problem. Because there might be non-fulfilled >>> Requires for the package, remember to check it again using page like >>> this: >>> >>> https://build.opensuse.org/package/binary/devel:languages:go/golang-org-x-t… >>> >>> As to package renames: >>> >>> I just follow the Fedora style: golang + importpath like string, eg: >>> golang-github-golang-glog refers togithub.com/golang/glog <http://github.com/golang/glog>. basically >>> importpath with ".org/.net/.com" will be okay with my package. You can >>> refer to the golang-* packages I recently send to devel:languages:go >>> as examples. >>> >>> Welcome to help golang package renaming and contribute to my package :-) >>> >>> Marguerite >>

1 0

Fwd: Re: [opensuse-packaging] OBS tests fail after building package
by Benjamin Denisart 08 Aug '15

08 Aug '15

On 08/07/2015 03:49 PM, auxsvr wrote: > Hello, > > I'm trying to build a package[1] that fixes several problems with > google-earth. It builds fine and works locally, but the OBS performs > some tests after the package is built, which fail. Since it depends on > google-earth, which cannot be installed in the OBS as far as I know, is > there a way to prevent these tests from running? > > -------- > [1] https://build.opensuse.org/package/show/home:auxsvr/google-earth-fix You should integrate your changes directly in the google-earth package. -- 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] postfix.rpm does not install sysconfig files
by Olaf Hering 06 Aug '15

06 Aug '15

After a fresh TW install I compared /etc/sysconfig/postfix with an old installation. Most of the settings are just missing, like POSTFIX_UPDATE_MAPS= After poking around I found the value in /var/adm/fillup-templates/sysconfig.postfix, but not in /etc. And even after 'rpm -e postfix;rm /etc/sysconfig/postfix;zypper in postfix' the file is not installed. I wonder if that part of postfix.spec:%post is really correct: ... %if 0%{?suse_version} > 1210 %service_add_post %{name}.service %set_permissions %{_sbindir}/postqueue %set_permissions %{_sbindir}/postdrop %set_permissions %{_sysconfdir}/%{name}/sasl_passwd %set_permissions %{_sbindir}/sendmail %verifyscript %verify_permissions -e %{_sbindir}/postqueue %verify_permissions -e %{_sbindir}/postdrop %verify_permissions -e %{_sysconfdir}/%{name}/sasl_passwd %verify_permissions -e %{_sbindir}/sendmail %{fillup_only -y postfix} %else %{fillup_and_insserv -y postfix} %endif %{fillup_only -an mail} /sbin/ldconfig ... It seems %verifyscript creates a new section named 'verify scriptlet (using /bin/sh)', which is not executed. Olaf -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 11

[opensuse-packaging] openSUSE Leap erlang
by Matwey V. Kornilov 06 Aug '15

06 Aug '15

Dear colleagues I've just found that there is no erlang in openSUSE:42 and submitted one from Factory: https://build.opensuse.org/request/show/320821 However, it is worth to discuss to have dedicated devel project for Leap (devel:languages:erlang:Leap) in order to have there "more stable" erlang. I mean 17.5.x is still maintained after 18.x release, so sometimes we have a choice. Second. If 18.0.2 lands to Leap, we need to provide maintenance updates. Should we stick on 18.0.x or 18.x? As far as I understand that there should not be compatibility issues between erlang X.Y and X.(Y+1). -- 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

1 0

[opensuse-packaging] filezilla: Mismatch between the program and library build versions detected
by Michael Ströder 04 Aug '15

04 Aug '15

HI! When starting filezilla (see package details below) on openSUSE 20150728 (Tumbleweed) (x86_64) it fails with this message: ---------------------------- snip ---------------------------- Fatal Error: Mismatch between the program and library build versions detected. The library used 3.0 (wchar_t,compiler with C++ ABI 1009,STL containers,compatible with 2.8), and your program used 3.0 (wchar_t,compiler with C++ ABI 1008,STL containers,compatible with 2.8). ---------------------------- snip ---------------------------- Any clue what's causing this and how to work around this? Ciao, Michael. Information for package filezilla: ---------------------------------- Repository: openSUSE-20150311-0 Name: filezilla Version: 3.11.0.2-1.3 Arch: x86_64 Vendor: openSUSE Installed: Yes Status: up-to-date Installed Size: 5.2 MiB Summary: A GUI FTP and SFTP Client Description: FileZilla is a modern and powerful FTP client for Windows and Linux. FileZilla development focuses on high usability while also supporting as many useful features as possible. FileZilla is "Open Source" under the GPL license. Some of the main features are: * Continuing interrupted up-/downloads * Managing different FTP sites * Modifiable Commands * Keep-Alive-System * Timeout detection * Firewall support * SOCKS4/5 and HTTP 1.1 proxy support * SSL support (secure connections) * SFTP support * Upload/Download queue * Drag&Drop support

3 3

[opensuse-packaging] How to avoid more undefined symbols?
by SF Markus Elfring 03 Aug '15

03 Aug '15

Hello, I came along two issues recently where symbols from C++ class libraries which were provided by specific software package versions did not fit together temporarily. Combinations: * libmodman1 / libproxy1 https://bugzilla.opensuse.org/show_bug.cgi?id=937157#c5 * yast2-core / libyui6 https://bugzilla.suse.com/show_bug.cgi?id=937665#c2 How are the chances that such name mangling changes because of application binary interface adjustments will trigger appropriate updates automatically? Do dependency descriptions need any more fine-tuning for corresponding RPM specifications? Regards, Markus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 6