Hi,
some packages (e.g. cups), after installation, insert their service into
the runlevel, others (e.g. apache2) do not. How is this accomplished in
the %post sections of .spec files?
-
To unsubscribe, e-mail: [EMAIL
On Oct 17 2007 13:09, Marcus Rueckert wrote:
On 2007-10-17 12:56:51 +0200, Holger Macht wrote:
What would result in
char *prop = (char*)laptop_panel.num_levels;
const char *prop = laptop_panel.num_levels;
should fix it too no?
Yes. And if it is supposed to be writable, use char prop[].
On Oct 14 2007 21:12, Andreas Gruenbacher wrote:
On Sunday 14 October 2007 12:55, Pascal Bleser wrote:
Andreas Gruenbacher wrote:
Why not fix this rpm defect instead? This limitation really doesn't make
sense.
You have a patch to discuss with Jeff ? :)
No, but didn't Jan say he'd
Hi,
I noticed that some -lang packages contain noarch data and hence should
be produced as such, to reduce number of packages in the rpm metadata,
as well as the space on DVD. For example:
-rw-r--r-- 1 455 5200 597700 Sep 23 01:07
/lnk/103/i586/mc-lang-4.6.1-140.i586.rpm
-rw-r--r-- 1 455
On Oct 9 2007 03:22, Paul Elliott wrote:
What other flaws can you find?
Run rpmlint.
%define name skylendar
%define version 1.7.0
Don't do this. It's horribly redundant.
Name: %{name}
Version: %{version}
Just put it in here, and %name/%version is implicitly defined.
Pcakman pkgs also
Trying to build some kmp removes module-init-tools from the buildsys,
but which is BuildRequired:. I suppose lbulid does not properly expand
macros, since BuildRequires: module-init-tools comes from
/etc/rpm/macros.kernel-source that is inside the buildsys, and probably
not installed yet.
On Oct 5 2007 15:31, Andreas Gruenbacher wrote:
On Friday 05 October 2007 03:07:55 pm Jan Engelhardt wrote:
Trying to build some kmp removes module-init-tools from the buildsys,
but which is BuildRequired:. I suppose lbulid does not properly expand
macros, since BuildRequires: module-init
Hi,
I notice, for example,
-rw-r--r-- 1 455 5200 66727 Sep 22 00:02 libelf0-devel-0.8.9-17.i586.rpm
while I agree with the new naming scheme (libelf0), I do not for -devel
packages that cannot reasonably be installed alongside each other.
Think of libelf0-devel and libelf1-devel which both
On Oct 4 2007 17:25, Stephan Kulow wrote:
I notice, for example,
-rw-r--r-- 1 455 5200 66727 Sep 22 00:02 libelf0-devel-0.8.9-17.i586.rpm
while I agree with the new naming scheme (libelf0), I do not for -devel
packages that cannot reasonably be installed alongside each other.
Think of
On Oct 4 2007 17:44, Stephan Kulow wrote:
libelf-devel conflicts with libelf0-devel. Where is your point?
Ah ok, I did not see libelf-devel since I was looking for
lib*[0-9]-devel*.rpm. Ok, I try again, with a better package example.
But not all packages follow the curl scheme, e.g.
On Oct 2 2007 21:38, Jan Engelhardt wrote:
Hi,
with lbuild-10.3, the following oddity happens:
keeping kernel-bigsmp-2.6.22.9-ccj54
keeping kernel-default-2.6.22.9-ccj54
installing kernel-regular-2.6.22.9-ccj54
[...]
keeping kernel-xen-2.6.22.9-ccj54
keeping kernel-xenpae-2.6.22.9-ccj54
On Oct 2 2007 11:16, Ludwig Nussel wrote:
Where might I find that svn^W hg^W git repository of lbuild, to track
changes?
I'm currently experimenting which system is most convenient so the
repository is on my harddisk only atm :) I didn't bother to research
whether there are ways to host
Hi,
with lbuild-10.3, the following oddity happens:
keeping kernel-bigsmp-2.6.22.9-ccj54
keeping kernel-default-2.6.22.9-ccj54
installing kernel-regular-2.6.22.9-ccj54
[...]
keeping kernel-xen-2.6.22.9-ccj54
keeping kernel-xenpae-2.6.22.9-ccj54
[...]
Hi,
has someone from Novell already created a
/usr/lib/lbuild/configs/sl10.3.conf/factory.conf configuration and would
like to share it?
thanks,
j
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
On Sep 10 2007 17:09, Stephan Kulow wrote:
* Bugs that won't be fixed for 10.3 can be moved to 11.0 in bugzilla now. I
suggest to take that option for every bug you're not planning to do an
online update later (should be a minority of the current bugs).
No future 10.4?
Jan
--
On Sep 10 2007 17:59, Ladislav Michnovič wrote:
2007/9/10, Jan Engelhardt [EMAIL PROTECTED]:
On Sep 10 2007 17:09, Stephan Kulow wrote:
* Bugs that won't be fixed for 10.3 can be moved to 11.0 in bugzilla now. I
suggest to take that option for every bug you're not planning to do
On Sep 10 2007 18:14, Reinhard Max wrote:
On Mon, 10 Sep 2007 at 18:09, Jan Engelhardt wrote:
Meh, can't let 6.4 be the only .4.
Don't forget about 4.4 and 4.4.1.
And look at FreeBSD or OpenBSD, they even go up to .9.
_That's_ good conversion of numbers. SUSE just wastes them
like it can't
On Sep 2 2007 00:18, Pascal Bleser wrote:
On Sep 1 2007 16:22, Paul Elliott wrote:
Name: peless
Summary:Tabbed text browser
Version:1.156
Release:19%{?dist}
License:GPL
Group: Productivity/Text/Utilities
Source0:
On Sep 1 2007 21:18, Cristian Rodriguez wrote:
Paul Elliott escribió:
---cut here with a chainsaw
# norootforbuild
%define _prefix /opt/gnome
uh ho. GNOME has moved to /usr
And KDE has not. I really question the weirdo move (but only for the
.so files)
On Aug 30 2007 18:32, Philipp Thomas wrote:
* Jan Engelhardt ([EMAIL PROTECTED]) [20070823 09:36]:
Bwäh. printf(%llu, (unsigned long long)var); is much more readable
and does not provide any surprises.
It isn't more readable and it certainly doesn't provide surprises as stdint.h
On Aug 30 2007 17:42, Marcus Meissner wrote:
On Thu, Aug 30, 2007 at 05:40:54PM +0200, Marcus Rueckert wrote:
On 2007-08-30 12:31:28 +0200, [EMAIL PROTECTED] wrote:
http://en.wikipedia.org/wiki/Prelinking
http://www.gentoo.org/doc/en/prelink-howto.xml
On Aug 23 2007 09:26, Andreas Jaeger wrote:
I suggest to use:
#include inttypes.h
int
main (void)
{
int64_t var;
printf ( PRIi64, var);
...
}
The PRT* macros from inttypes.h and the standard integer types from
stdint.h will do the magic for you,
Bwäh. printf(%llu, (unsigned long
On Aug 21 2007 16:27, JP Rosevear wrote:
3) Separation of soname number from library name
We could always put the dash in for more consistency ie libz-1 instead
of libz1 so when the library name ends in a number its libwhatever2-7
and its easier for humans to parse (probably).
dbus-1-1.0.0-7.
On Aug 13 2007 12:58, James Oakley wrote:
I ended up writing my own script to build kernel spec files from templates,
which I have attached.
Well I do have my own, and I'd like to get rid of them, because as soon
as someone from Novell changes lines so that my regexes do not match
anymore,
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
25 matches
Mail list logo
