Hi,
the kernel-*.spec files contain a lot of hardcoded strings, such as
2.6.22.1 for what's currently cooking. This causes a major pain when
trying to bump the version by oneself. All occurrences need to be
replaced by more-or-less blunt scripts (simple perl -pe 's///'), since
the .in files are not available. If these could please be added to the
kernel-source pack, that would greatly simplify work.
Moreover, I think that strings, where possible, should be replaced by
rpm tags. For example this obvious one:
Provides: kernel = 2.6.22.1-%source_rel
(and other places)
this can easily be replaced by %version-%source_rel. The other major
thing being
Name: kernel-default
(and other places of course)
which could be replaced - since the macro is already there - by
Name: kernel-%build_flavor
thanks,
Jan
--
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi!
I would like to mention it explicitly even though I expect
everyone to figure it out:
Factory is no longer 10.3. So you have to remember to submit
a package into both 10.3 and Factory/STABLE if you do an update
for 10.3
We will wait with changing Factory a bit though to not put
too much traffic on the mirrors.
Greetings, Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi, everyone,
I just installed osc on openSUSE 10.3; the first run asked me for my
username/password, so I gave it what I use for the openSUSE wiki and
bugzilla.novell.com.
However, it doesn't want to authenticate :( I turned on http_debug in
the config file. Attached is what osc prints.
Does anyone know what may be wrong?
[I just built my first package with the build service's web interface
--- it's *really* nice!]
Thanks in advance,
Federico
Hi,
I wanted to update my openSUSE 10.3 RC1's Xorg to the newest stable
version which is 7.3 currently. So I added:
http://download.opensuse.org/repositories/xorg73/openSUSE_10.3/
repository using YaST and maked update of Xorg. Then I compared Xorg
-version output:
linux-5wri:~ # Xorg -version
X Window System Version 7.2.0
Release Date: Sat Sep 15 00:09:03 UTC 2007
X Protocol Version 11, Revision 0, Release 7.2
Build Operating System: openSUSE SUSE LINUX
Current Operating System: Linux linux-5wri 2.6.22.5-23-default #1 SMP
2007/09/18 05:23:45 UTC i686
Build Date: 15 September 2007
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
linux-5wri:~ # Xorg -version
X Window System Version 7.2.0
Release Date: Fri Sep 21 14:49:55 UTC 2007
X Protocol Version 11, Revision 0, Release 7.2
Build Operating System: openSUSE SUSE LINUX
Current Operating System: Linux linux-5wri 2.6.22.5-23-default #1 SMP
2007/09/18 05:23:45 UTC i686
Build Date: 21 September 2007
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
So update was succesfully, but so called "xorg73" seems to be 7.2
really, not 7.3. Could someone check this repository and make it
contain 7.3 version of Xorg, please?
--
Rafał Miłecki
Hello,
creating the symlink to licenses in the licenses package is curently
done by including a small script in each spec file, like:
for FILE in COPYING copyright.txt ; do
MD5SUM=$(md5sum $FILE | sed 's/ .*//')
if test -f /usr/share/doc/licenses/md5/$MD5SUM ; then
ln -sf /usr/share/doc/licenses/md5/$MD5SUM $FILE
fi
done
This is error-prone (see bug 306681) and adds lots of duplicated code to
the spec files.
Please add a small script to the licenses package or create a rpm macro
that creates the symlink. If the rpm macro could also drop in a
"Requires: licenses", it would be even better.
The specfile should then contain commands like (replacing the example
above):
%symlink_license COPYING
%symlink_license copyright.txt
Oh, and please do this ASAP, before more package(r)s include the script
in the spec file ;-)
Regards,
Christian Boltz
--
31.8.-3.9.2007: Weinfest und Jubiläum 1225 Jahre Insheim
Pig Slip, Hifi-Delity, Human Fact, Frank Petersen und die Söhne Insheims
spielen bei der Landjugend.
Mehr Infos: www.Landjugend-Insheim.de
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
The upcoming transition to GCC 4.3 will cause some common problems
in C and C++ source to become compile-time errors. You investigate
if your Factory package is affected by looking at the
home:dirkmueller:playground:gcc43 project which is currently rebuilding
(most of) Factory with GCC 4.3.
Common problems include:
1) Missing includes. The include dependencies of the standard library
headers were cleaned up a lot and a lot less unneeded dependencies
are pulled in. This results in errors like
Geometry.cpp: In member function 'const Magick::Geometry& Magick::Geometry::operator=(const std::string&)':
Geometry.cpp:191: error: 'strcpy' was not declared in this scope
make[3]: *** [Geometry.lo] Error 1
which hints at that you should include <cstring>, the C++ standard
include name of the C string.h header. The rule of thumb is to look
in which C header the missing function is in and then include the
C++ variant which has a 'c' prepended and the '.h' stripped off.
This is 90% of all errors we currently see with C++ programs.
2) There are extra warnings with GCC 4.3 and you use -Werror. You simply
need to fix them.
3) More picky preprocessor:
main.cpp:182:7: error: extra tokens at end of #endif directive
the preprocessor diagnoses
#endif foo
use #endif /* foo */ instead.
4) C99 inline semantics changes. If you use 'extern inline foo(....' in
headers and build with either -std=c99 or -std=gnu99 then you will
probably face linker errors complaining about duplicate symbols.
If you want to fix this in a way that is compatible with GCC 4.3 and
previous versions use something like the following:
extern inline
#ifdef __GNU_STDC_INLINE__
__attribute__((__gnu_inline__))
#endif
foo(....
which will preserve the previous semantics. If you do not care about
compatibility with older GCC and want to use C99 semantics simply
remove the 'extern' qualifier on inline functions defined in headers.
5) If you see something like
/usr/include/zypp/Bit.h:86: error: declaration of 'typedef struct zypp::bit::MaxBits<_IntT> zypp::bit::Range<_IntT, _begin, _size>::MaxBits'
/usr/include/zypp/Bit.h:52: error: changes meaning of 'MaxBits' from 'struct zypp::bit::MaxBits<_IntT>'
you did something like
template <class T>
struct Foo : public FooBar<T> {
typedef Foo::FooBar<T> FooBar;
...
this is invalid C++. Use a different typedef-name here:
typedef Foo::FooBar<T> FooBar_t;
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
I get an error I haven't seen before when creating a repo, can someone
please advice?
290/532 - i586/php5-pcntl-5.2.4-11.i586.rpmerror: rpmts_HdrFromFdno:
headerRead failed: region trailer: BAD, tag 0 type 0 offset 0 count 0
('E', 'r', 'r', 'o', 'r', ' ', 'o', 'p', 'e', 'n', 'i', 'n', 'g', ' ',
'p', 'a', 'c', 'k', 'a', 'g', 'e') - i586/php5-debuginfo-5.2.4-7.i586.rpm
Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
That was the problem. With this macro it works fine!
Thank you,
Andras
>>> Ruediger Oertel <ro(a)suse.de> 09/17/07 11:22 PM >>>
On Mon, 17 Sep 2007, Marcus Rueckert wrote:
>
> hi,
>
> just curious: what distro are you running on?
the problem is the missing lang_package macro:
# Template for lang sub-package.
%lang_package(n:) \
%package %{-n:-n %{-n*}-}lang \
Summary: Languages for package %{name} \
Group: System/Localization \
Provides: %{-n:%{-n*}}%{!-n:%{name}}-lang-all = %{version} \
Requires: %{name} = %{version} \
%description %{-n:-n %{-n*}-}lang \
Provides translations to the package %{name}
you can probably just put it to the end of the file /usr/lib/rpm/suse_macros
--
with kind regards (mit freundlichem Grinsen),
Ruediger Oertel (ro@novell.com,ro@suse.de,bugfinder@t-online.de)
----------------------------------------------------------------------
Linux Fatou 2.6.22.5-16-default #1 SMP 2007/09/11 14:25:31 UTC x86_64
Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
On Fri, 2007-09-14 at 14:38 +0200, Dirk Mueller wrote:
> if the latter description for requires-on-release is not understandable, then
> file a bugreport and suggest a description that you can understand.
What's the right product/component to file this in Bugzilla?
Federico
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org