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
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
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
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
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
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
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
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
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
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