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)
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
Hi Marguerite,
it seems like it's time to review your requests, it's only been 2 months
:-/ While the submits look mostly fine to me, I wonder whether the lua
dependencies should go into devel:languages:lua following the package
style / naming there and be linked instead into server:messaging?
From glimpsing at d:l:lua, it's in a really sorry state and needs a lot
of love. I don't know if you'd be interested in working on that, thus
I'm opening this up to the wider community.
--
Sascha Peilicke
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)
Hi all,
I'm not sure this is the right mailing list but here I go.
After a long search on howto making packeges and a lot of try and more
error I was hoping you all could help.
For a development project I have to run ccbuild, it makes dynamic
makefiles. But I can't find any package to install it. I don't like
building and running from source. It prevents from keeping track of what
is installed.
That said I have a spec-file for ccbuild that looks okay. But it needs
bobcat (Brokken's Own Base Classes And Templates). And that's where the
big problem is. I can't seem to get a spec-file to build it. I always
get an error on the directory or the files in use.
So I was hoping you could help me making a package for ccbuild and/or
bobcat. I even think that there will be dev how would like to see them
in openSUSE.
Best regarts
Daniël Huisman
bobcat: http://bobcat.sourceforge.net/ made my Frans Brokken the same
one as icmake
ccbuild http://www.logfish.net/pr/ccbuild/ spec-file at
https://build.opensuse.org/package/view_file/home:Drunken/ccbuild/ccbuild.s…
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
I'm asking Wolfgang directly instead of only a list because of firefox-esr
changelog, and http://lists.opensuse.org/ doesn't indicate a good place for
Mozilla questions spanning different OS releases.
IIUC, 24 is scheduled to take over esr soon. I don't want anything newer than
22 installed as default Firefox anywhere around here. Its UI has been dumbed
down too much. I'd rather 17 for normal use as long as it's viable, with
SeaMonkey and Konq for things requiring latest features and/or security
updates. Maybe others have similar feelings and would like access to a
17-latest rpm in 13.1 now that beta1 has been announced.
12.3 has latest, 17.0.9, available in mozilla/openSUSE_12.3 repo.
13.1 has 6 month old 17.0.4 available in
mozilla:/experimentalopenSUSE_Factory repo.
1-Is old version for 13.1 oversight?
2-Can 12.3's rpm be installed in 13.1 without need to backlevel deps/libs?
3-Why isn't esr available in a standard Factory/13.1 repo instead of
"experimental"?
Why does BS have a lot of what looks like the same thing under two different
names? e.g.
mozilla/
mozilla:/
Other than different names and different subdirs, what's the distinction
between those with and without ":"?
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Dear all,
there seems to be a setup issue for antRun that makes the scala builds fail,
as antRun could not be found.
By creating a symlink by hand from "/usr/share/ant/bin/antRun" to
"/usr/bin/antRun" could possibly fix it, but I didn't get it to work.
I tried the following in build section of the spec:
# Create symlink to fix antRun setup bug
mkdir -p %{buildroot}/usr/share/ant/bin/
cd %{buildroot}/usr/share/ant/bin/
ln -s ../../../bin/antRun
as suggested, but this didn't work.
Any idea, how to get this working again? Sorry for crossposting, but this
seems a better place to ask.
project : devel:languages:scala
package: scala
Thanks, Denny
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
I maintain libprelude and it is now failing in factory. I assume a
new gcc compiler went in recently. (It still builds fine in the 13.1
branch.)
A local build log has these lines which I think are the critical ones:
=============================
[ 191s] Making all in lua
[ 191s] make[3]: Entering directory
`/home/abuild/rpmbuild/BUILD/libprelude-1.0.1/bindings/lua'
[ 191s] /usr/bin/swig -c++ -I../../bindings
-I../../bindings/c++/include -I../../src/include
-I../../src/libprelude-error -lua -o PreludeEasy.cxx libpreludecpp.i
[ 191s] SWIG:1: Warning 125: Use of the include path to find the
input file is deprecated and will not work with ccache. Please include
the path when specifying the input file.
[ 191s] ../../bindings/c++/include/prelude-error.hxx:48: Warning 503:
Can't wrap 'operator const char*' unless renamed to a valid
identifier.
[ 191s] ../../bindings/c++/include/prelude-error.hxx:49: Warning 503:
Can't wrap 'operator const std::string' unless renamed to a valid
identifier.
[ 191s] /bin/sh ../../libtool --tag=CXX --mode=compile g++
-DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../src/include
-I../../src/include -I../../src/libprelude-error
-I../../bindings/c++/include -I../../libmissing -I../../libmissing
-fomit-frame-pointer -fmessage-length=0 -grecord-gcc-switches -O2
-Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -g -c -o PreludeEasy.lo PreludeEasy.cxx
[ 191s] libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I../..
-I../../src/include -I../../src/include -I../../src/libprelude-error
-I../../bindings/c++/include -I../../libmissing -I../../libmissing
-fomit-frame-pointer -fmessage-length=0 -grecord-gcc-switches -O2
-Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -g -c PreludeEasy.cxx -fPIC -DPIC -o
.libs/PreludeEasy.o
[ 192s] PreludeEasy.cxx: In function 'int _wrap_IDMEFValue_Clone(lua_State*)':
[ 192s] PreludeEasy.cxx:7154:9: warning: unused variable 'ret'
[-Wunused-variable]
[ 192s] int ret;
[ 192s] ^
[ 192s] PreludeEasy.cxx: In function 'int _wrap_IDMEFPath_Get(lua_State*)':
[ 192s] PreludeEasy.cxx:7376:9: warning: unused variable 'ret'
[-Wunused-variable]
[ 192s] int ret;
[ 192s] ^
[ 192s] PreludeEasy.cxx: In function 'int _wrap_IDMEF_Get(lua_State*)':
[ 192s] PreludeEasy.cxx:10519:9: warning: unused variable 'ret'
[-Wunused-variable]
[ 192s] int ret;
[ 192s] ^
[ 192s] PreludeEasy.cxx: In function 'void
luaopen_PreludeEasy_user(lua_State*)':
[ 192s] PreludeEasy.cxx:11337:53: warning: comparison between signed
and unsigned integer expressions [-Wsign-compare]
[ 192s] if ( idx >= ((sizeof(argv) / sizeof(char *)) - 1) )
[ 192s] ^
[ 192s] PreludeEasy.cxx: In function 'int
SWIG_Lua_namespace_register(lua_State*, swig_lua_namespace*)':
[ 192s] PreludeEasy.cxx:1278:1: warning: control reaches end of
non-void function [-Wreturn-type]
[ 192s] }
[ 192s] ^
[ 192s] PreludeEasy.cxx: In function 'int
SWIG_Lua_add_namespace_details(lua_State*, swig_lua_namespace*)':
[ 192s] PreludeEasy.cxx:1248:1: warning: control reaches end of
non-void function [-Wreturn-type]
[ 192s] }
[ 192s] ^
==================
The last 2 warnings are causing the build to fail (or so I believe).
So you can see the compile is in the directory bindings/lua and the
file PreludeEasy.cxx is being compiled.
My confusion is when I go look in the source file at lines 1248 and 1278 I have:
1248: SWIGINTERN void SWIG_Lua_class_register(lua_State*
L,swig_lua_class* clss)
1278: lua_rawset(L,-3); /* metatable into registry */
Neither of those look like they correspond to the warnings. Further
if I search the source tree for SWIG_Lua_namespace_register or
SWIG_Lua_add_namespace_details I don't find either one.
Can someone help me try to track down how to patch this.
fyi: I looked upstream and this hasn't yet been reported. I thought I
wold try to provide a patch with my bug report, but I may have to just
submit a bug report and wait for a patch from upstream.
Thanks
Greg
--
Greg Freemyer
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
We branched the sources of factory into openSUSE:13.1 and from now
on I will cherry pick openSUSE:Factory submit requests to copy into
13.1
To ease my work there, it would be great if you document your
expectations and the bugs you fixed.
E.g. I agreed to take GNOME 3.10, but that does not mean every update
of a package that has GNOME in the group tag is automatically going
into 13.1.
The accept message of your submit request will tell you if I copied
to 13.1 or not.
Greetings, Stephan
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi, packagers,
I need help from texlive packagers with texlive-cjk-latex-extras in M17N.
Personally I don't know how to package for texlive...and I didn't find
tutorial on Portal:Packaging.
It's now in a fail status for 13.1 and Factory.
I read its URL tag in specfile, upstream now has a different source
name "cjk-*" for it and released a lot of versions (the latest
happened in late 2012)
So just fix the package doesn't work, we need to update it.
I think such an important update should be done by experts instead of
a person who know nothing about it...
Greetings
Marguerite
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
I noticed some packages in M17N were dropped from Factory.
But the links are still there, so they're all in a "broken" status.
How can I remove the links and make them build inside M17N?
Greetings
Marguerite
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org