openSUSE Packaging April 2013

packaging@lists.opensuse.org

57 participants
30 discussions

by Matwey V. Kornilov

Hi, In CrossToolchain:avr, I see avr-gcc-* and cross-avr-gcc. What is the difference? What is correct naming? (I suppose the last one). What guidelines/rules should I follow to create CrossToolchain subproject for yet unsupported arch? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 1 month

Packaging Guideline enforcement

by Dominique Leuenberger a.k.a DimStar

Dear Factory contributors and packagers, As openSUSE 12.2 is frozen and Factory is 'open to go wild' again, I would like to announce that the packaging guidelines have some extensions (not really new) that will be stricter enforced than they used to be. Currently a common rule to be 'ignored' or packagers are not aware is around the topics of: - .Changes entries - Patches First, the .changes entry (rpm changelog) surves two purposes: - News for the user - History tracking of packaging changes (often referenced in bugs to verify if a user has the latest packaging bugfixeS). A simple "Update to version x.y.z" is, as before, not accepted. There should be some buzz around the update for the user; some major reasons to the upgrade should be listed Changes on the package itself should be mentioned in a way that any other contributor to the same package can follow traces of why something is the way it is. Commonly, Added (build)dependencies are interesting to be seen, special hacks to make something work in a particular way [..]: Always consider that package maintenance is a distributed task and various contributors need to be able to step up at will. Patches: The rules about patches are listed at http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines . Most prominent is likely the mentioning of the patches life cycle, which forces you to mention additions and removals of patches in the changelog. As history shows, this can be helpful if a patch got removed, and later a regression is reported; finding out when a patch was removed can be crucial in reconstructing feature sets (including contacting the contributor that dropped it.. which is easily extracted from the .changes if listed) The main appeal is to the devel project maintainers / reviewers, to keep out for those rules, to live according to them, as it is frustrating for everybody if a package needs to be declined by the Factory Review team: - The dev prj maintainer is the one getting the 'decline' (as it was usually a forwarded request), which often leaves the 'fixing' to the devel project maintainers, where the 'originator' of the fix would have been willing to actually do that... And the Factory Review team also prefers to see complying submissions to having to reject SRs... reject is not fun for anybody! Looking forward to many more SRs to accept! Dominique / DimStar -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 2 months

Package looking for volunteers: CodeAnalyst

by Cristian Morales Vega

As per https://bugzilla.novell.com/show_bug.cgi?id=793541 it seems CodeAnalyst needs a new maintainer. Any volunteer? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 3 months

package looking for maintainer: the AT daemon

by Cristian Rodríguez

Hi: I will no longer maintain fix or otherwise care about the "at" daemon, starting now because I would rather devout my time testing and improving systemd.timer(5) So it is now up for grabs. that's all ;) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 5 months

Howto protect files from removing after uninstall of a rpm?

by Meike Stone

Hello, I try to build a RPM. All is working fine. But I need that after uninstall of the rpm two files always should be left on disk. If the package is updated, file should be replaced with the file from new rpm and replaced renamed as .rpmsave. Is there a way to do this in the spec file? Thanks Meike -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 7 months

glibmm and sigc static packages

by Sankar P

Hi, I am trying to build a static binary of https://github.com/i-rinat/fragview I patched the cmake file as: +SET (CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static") to build a static binary. Now during the make phase, I get the following errors: /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lglibmm-2.4 /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lsigc-2.0 I got the above error for "-lm" too which went away after installing the libc-devel-static rpm. However I could not find either a glibmm-devel-static rpm or a sigc-devel-static rpm. Now what is the easiest way to get the static rpm of these packages so as to get the static binary generated ? Which buildservice packages should I fork and tweak ? I do not have much experience in building and so wanted to ask here before proceeding, to know if I am going in the right path. I need a static binary as I want to run this tool in some old SLE boxes where the latest GTK, glibmm packages are not available, and so I cannot compile the fragview tool from the source in those machines. On a side note, The earlier RPM search under software.opensuse.org/search will list the rpms (instead of the projects) and it was easier to find if there were any rpms in home projects etc. in just one page. Now, the search interface is kind of complex, and makes us click a lot more. Does anyone else apart from me, feel that this can be reported as an usability issue ? Thanks. Sankar -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 7 months

Failed to lookup host/port: "127.0.0.1:0": Name or service not known

by Martin Vidner

Hi, I am getting a build failure for rubygem-ruby-dbus.rpm(1). The package contains a test suite where a new dbus-daemon is started listening on localhost. This fails with Failed to lookup host/port: "127.0.0.1:0": Name or service not known It runs fine in local builds and in Travis(2). 1) https://build.opensuse.org/package/show?package=rubygem-ruby-dbus&project=d… 2) https://travis-ci.org/mvidner/ruby-dbus Does anyone have an idea what the problem is? -- Martin Vidner, Cloud & Systems Management Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu

7 years, 7 months

devel:lanugages:erlang proposal

by Matwey V. Kornilov

We are getting a lots of packages inside the devel:languages:erlang. We should think to change project structure to avoid massive rebuild of packages at erlang updates. My suggestion is to follow devel:langages:python approach: maintaince project for erlang is devel:languages:erlang:Factory, and packages inside devel:languages:erlang are built against erlang from the *distribution* repository (or from openSUSE:Factory for factory). Since we can not just broke the things, the following roadmap is proposed: 1) move devel:languages:erlang/erlang to devel:languages:erlang:Factory/erlang and make a link from devel:languages:erlang:Factory/erlang to devel:languages:erlang/erlang. Change devel project for openSUSE:Factory/erlang to devel:languages:erlang:Factory. 2) disable devel:languages:erlang/erlang for Factory and upcoming openSUSE 13.1 in order to make erlang packages use erlang from the distribution. then disable for 13.2, 13.3, etc. At this step for openSUSE >= 13.1 packages from the project will use erlang from distribution, and the packages for openSUSE < 13.1 will use erlang from devel:languages:erlang, as they do now. 3) when all versions up to 12.3 will be discontinued, drop disabled devel:languages:erlang/erlang finally. -- With best regards, Matwey V. Kornilov http://0x2207.blogspot.com 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

7 years, 7 months

Correctly splitting xinetd configuration file that has %config(noreplace).

by Michal Srb

Hi, There are two VNC related packages: * xorg-x11-Xvnc, contains: - Xvnc binary (Xserver working as VNC server), since 12.3 based on tigervnc * tightvnc, contains: - VNC client (tightvnc) - bunch of scripts to configure and start Xvnc comfortably - vnc_inetd_httpd (http server to deliver Java based VNC client) - /etc/xinetd.d/vnc file containing vnc and vnchttp services tightvnc depends on xorg-x11-Xvnc and usually they are installed together. The /etc/xinetd.d/vnc contains definition of vnc{1,2,3} services that start Xvnc from xorg-x11-Xvnc package and vnchttpd{1,2,3} services that start vnc_inetd_httpd from tightvnc package. Now, to fix a bug that prevents Xvnc from working correctly in 12.3, we need to add additional option (-SecurityTypes None) to the xinetd configuration file. But it doesn't feel correct to add tigervnc specific option to file in tightvnc package. The best solution would be to split the xinetd configuration file into two and put each to appropriate package. I have that prepared and I verified that YaST is still able to switch both vnc and vnchttp services on and off correctly. Problem is that the /etc/xinetd.d/vnc is %config(noreplace) and if someone modified it, he will end up with two files - the original with all services and the new one with half of them. Xinetd refuses to start when it finds duplicate services. Could you suggest some safe way to split the configuration file? Or is it better to keep it in one package? Michal -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 7 months

Creating of systemd service files instead of init scripts for new packages

by Andreas Jaeger

Since we moved to systemd completely, I suggest that newly added files will contain service files - and not init scripts anymore. So, please only add service files to new packages and if you change your init file, consider using a service file and dropping the init file, Andreas -- Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 years, 7 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging April 2013