-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Trying to add signatures to my (yast2) RPM repository for 10.1.
http://en.opensuse.org/Secure_Installation_Sources
A couple of unclear things in there I'd like to poke on.
=========
"When YaST detects an installation source it checks if the file
"products" is there, and then checks if it is signed with a known key.
If it is not signed at all or with an unknown key, or if the key is on
the media, but not trusted (yet), the user will be asked what to do."
"The key is usually also on the installation media as
/gpg-pubkey-9c800aca-40d8063e.asc"
What it doesn't say clearly is where/how YaST2 will try to fetch the
armored/exported key in order to propose importing it.
I assume it uses whatever is defined in "content" using the "KEY" tag
(see below). Correct ?
=========
"The "content" file is signed in the same manner as the "products" file,
so there is a "content.key" (usually, but not necessarily the same as
"products.key")."
Those "content.key"/"products.key" files are not mentioned anywhere else.
Are those copies of the ASCII-armored, exported GPG key ?
=========
"META keys are added for all files in the directory named in the key
DESCRDIR"
So in "content" I should have something like:
...
DESCRDIR setup/descr
KEY SHA1 33ad20fe228350dc4e0f0cd7967460c31266af36 gpg-pubkey-guru.asc
META SHA1 4baafd9998ea4e20245f82e507c6db6b723f4597 packages
META SHA1 965ba5faeea815d41ba308ffd193b78505b26c1c directory.yast
META SHA1 4565f769ae573f89dddbf2eef1357b59a88ad1df packages.DU
META SHA1 c53400cdb9e16ac0d9add587585fc77c86f132c5 packages.en
Correct ?
=========
"Before YaST uses any file from DESCRDIR it will look up the entry in
"content". This entry is currently a SHA1 checksum followed by the
package name. This may change to a SHA256 checksum."
A "package" name ? I suppose what is meant here is "file" name. Is it ?
=========
"The next step in the chain is the file "packages" in DESCRDIR.
If you are familiar with its syntax you will see that we added a new tag
there, too, right after the "Pgk:" tag. Here is an example of the first
two lines of the entry for the default kernel:
=Pkg: kernel-default 2.6.16 13 i586
=Cks: SHA1 8c8eb2b605e1d626c22bea8dd0c3b05885432b16
Again we have a SHA1 checksum."
Maybe it should be mentioned that one must use create_package_descr from
10.1 or Factory (I only checked the one from autoyast2-2.13.59.tar.bz2)
What about older versions ?
If I use create_package_descr from 10.1/Factory, that adds those =Cks:
tags into the "packages" file, can I also use it to generate "packages"
for, say, 10.0/9.3/9.2/9.1 ?
Or will YaST2 on 10.0 and older bark, saying that it does not know
anything about the "=Cks:" tag ?
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\ <pascal.bleser(a)skynet.be> <guru(a)unixtech.be>
_\_v The more things change, the more they stay insane.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFEdcqur3NMWliFcXcRAipAAJ9zpDlujVLHfvUyGqzVevt23Y3fUgCfcBvf
/6CbxUT9RXz8ZjXc+Kor0/Q=
=nzgd
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have compailed MusE for SuSE 10.1. Compile works fine but at start i
become the follow error message:
Unabel to find ladspa_descriptor() function in plugin library file
"/usr/lib/ladspa/sine.so":/usr/lub/sine.so: undefined symbol:
ladspa_descriptor.
I think OK a problem with ladspa. I load the
ladspa-1.12.20050216-7.src.rpm and tried to recompile it. ladspa has
libselinux as BuildRequire, there is no libselinux in 10.1?
Then i removed libselinux as BuildRequire.
Now the compile breaks with
c++ -O2 -g -m32 -march=i586 -mtune=i686 -fmessage-length=0
- -D_FORTIFY_SOURCE=2 - fPIC -I. -o plugins/sine.o -c plugins/sine.cpp
plugins/sine.cpp: In constructor
‘StartupShutdownHandler::StartupShutdownHandler ()’:
plugins/sine.cpp:266: error: ‘instantiateSineOscillator’ was not
declared in this scope
plugins/sine.cpp:268: error: ‘connectPortToSineOscillator’ was not
declared in this scope
plugins/sine.cpp:270: error: ‘activateSineOscillator’ was not declared
in this scope
plugins/sine.cpp:278: error: ‘cleanupSineOscillator’ was not declared
in this scope
plugins/sine.cpp:291: error: ‘runSineOscillator_FreqAudio_AmpAudio’ was
not declared in this scope
plugins/sine.cpp:303: error: ‘runSineOscillator_FreqAudio_AmpCtrl’ was
not declared in this scope
plugins/sine.cpp:315: error: ‘runSineOscillator_FreqCtrl_AmpAudio’ was
not declared in this scope
plugins/sine.cpp:327: error: ‘runSineOscillator_FreqCtrl_AmpCtrl’ was
not declared in this scope
Anyone an idea Why i can't rebuild it?
Oliver Bengs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFEeyTNj/glEAdJRAMRAgs7AJ9pqXGn4rIwoGMVl4uyperjYh4SzwCggO8Q
FSL9JPMu+c7YBMyX+7Ze++0=
=DmFP
-----END PGP SIGNATURE-----
Hi,
I am new to SUSE. My system is OpenSUSE 10.1 The YaST tool only shows the
j2sdk packages from SUN, but none from IBM. Can I download the rpm from the
IBM website and install it with YaST? Just wondering what is the best way to
install 3rd party rpms like this in OpenSUSE.
Doug
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
hi
i would like to know if the makefile can have an impact on the specfile?
i create a specfile step by step
BuildRoot: %{_tmppath}/%{name}-%{version}
%description
spca5xx video for linux (v4l) driver, providing
support for webcams and digital cameras based on the spca5xx range of chips
manufactured by SunPlus Sonix Z-star Vimicro Conexant Etoms Transvision
Mars-Semi Pixart.
%prep
%setup
%build
make
build --rpms /opt/dvd_suse
return
/bin/chgrp -Rhf root .
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.56470
+ umask 022
+ cd /usr/src/packages/BUILD
+ /bin/rm -rf /var/tmp/spca5xx-20060501
++ dirname /var/tmp/spca5xx-20060501
+ /bin/mkdir -p /var/tmp
+ /bin/mkdir /var/tmp/spca5xx-20060501
+ cd spca5xx-20060501
+ make
Building SPCA5XX driver for 2.5/2.6 kernel.
Remember: you must have read/write access to your kernel source tree.
make -C /lib/modules/`uname -r`/build
SUBDIRS=/usr/src/packages/BUILD/spca5xx-20060501 CC=cc modules
make: *** /lib/modules/2.6.16.13-4-default/build: No such file or directory.
Stop.
make: *** [default] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.56470 (%build)
not sure but with this message, the build don't seem to take the right
folder....
thanks
We are working on patch naming for SUSE Package Conventions
(http://forgeftp.novell.com//library/SUSE%20Package%20Conventions/spc.html)
This is proposal and comments from community are welcome.
Reasons/ motivations: why we need this:
-------------------------------------------------------
- backup maintainers
- team working on bug fixing -> unified way of patching
- tracking changes in patch, tracking mainstream patches
1. Patch Name
-----------------------
1.1 Suffix
------------
We need to choose unified suffix for patch name. Commonly used suffixes
are: "patch, diff, dif"
Suffix "Patch" and "Diff" are most commonly used. There is no rational
reason why one "Patch" or "Diff" should NOT be used. "Diff" suffix is
associated with shared mime info
Proposal:
- use "patch" suffix, do not rename old patches. Do not use
"dif" suffix any more.
1.2 Naming
---------------
Name of package should be very intuitive and should tell maintainer what
this patch actually fix. Name of patch should consist of: Name, Number,
Mnemonic hint
1.2.1 Name
---------------
There is two way for choose patch name, use package name, or use source
name. There are packages with more than one source in package.
Proposal:
- use name of source which patch is apply to. Patch should not
fix files from different source.
- if is not possible use name of source, use name of package
instead.
1.2.2 Number
------------------
Number as version of source or package is heavily used in patch name.
This could confuse new maintainer because it suggest that patch is
version dependent. If this package is not version dependent and package
is updated to new version, all patch had to be updated. In SUSE, there
are many packages which contains patch, which are not sent to upstream,
because they fix SUSE specific problems.
Proposal:
- use no number at all for patch which are not meant to be send
in upstream (SUSE specific, temporary distribution dependent fix ....)
- use number for patch which are only for this version of
package (source), this patch should be sent to upstream. This number
should be changed when updating to new version if we still expect this
patch to be accepted by upstream. If no, number should be removed from
this patch.
1.2.3 Mnemonic hint
---------------------------
Mnemonic hint should tell (together with changelog) what this patch fix.
There are only common hints how to do useful hints.
Proposal:
- use '-' for separate section in name and '_' for separating words
e.g.: gcc-really_useful.patch
enlightenment-gcc-error.patch
lftp-compat-mode.patch
graphviz-fix_swig_template.patch
- if fixed problem could not be easily hinted by short name,
you can use bugzilla number, or security bug reference ID (like CVE,
PMASA). We could consider creating table of commonly used hints.
e.g.: CVE-2005-3353.patch
PMASA-2005-6.patch
php-5.1.2-phpbug-36208.patch
- there are patch which fix problem which is caused by another
part of system ( broken library, autobuild....). Patch name should
reflex this. We propose to use buildfix/temporaryfix/runfix for such
patch. This patch should be removed as soon as possible (probably when
updating to new version)
buildfix - if this package could be builded, this patch
could be safely removed.
runfix - if this package could be runed without this
patch, this patch could be safely removed.
temporaryfix - all other temporary fix.
2. Changelog
------------------
All changes in package (adding/removing patch, changing spec file ...)
should be mentioned in changelog. From name of patch changelog and
comments in patch should be clear what change was made.
Proposal:
- mention add or remove patch in changelog
e.g. [ ...]
- added patch -gcc-error.patch
- use number of bug from bugzilla., Name of bugzilla should be
used if it is not obvious
e.g. fixed gcc error [#32423]
fixed gcc error, openoffice [#3224324]
- use reference to security ID in changelog
e.g. - fixed completely broken SplTempFileObject [php#37257]
- if fix is more complicated, additional info in header of patch
file should be present!
- additional info in patch should be present also in patch which
will be presented in package for long time (program is not developed any
longer...)
3. Patch in specfile
-------------------------
Main problem with patch in specfile is numbering. When patches are added
they have increasing number. Php example:
Patch1: php5-config.patch
Patch2: php5-phpize.patch
Patch3: php5-apache_sapi_install.patch
Patch4: php5-php-config.patch
Patch5: php-%{version}-include_path.patch
[ ... snip, there are about 51 patches]
When patch is removed, there are hole in specfile, which could look
ugly. But renumbering is time consuming. There is possible to use unused
number, but adding position in spec file should be preserved. Example
Patch1: php5-config.patch
Patch3: php5-apache_sapi_install.patch
Patch4: php5-php-config.patch
Patch5: php-%{version}-include_path.patch
Patch2: php5-new.patch
When patch is commented in spec file and not deleted, there should be
comment, explaining this.
e.g.
# FIXME: This patch should be backported.
#%patch2
# Uncomment this patch, if automake fails.
#%patch3
Comment should be also used, if patch is used differently than normal.
e.g. (blender)
Patch1: po.patch
Patch2: blender-home-to-datadir.patch
# patch is applied only on x86-64
Patch5: Scons.patch
[...]
4. Common advise
-------------------------
- when fixing package, try to keep style convention set by author of
this package (if it is still any)
e.g. some one write bugzilla number as "#234345", [#33453453],
(#2342342)
- do not overwrite changelogs
- preserve time stamps of file you do not modify.
--
Pavel Nemec
package-maintainer
http://en.opensuse.org/Czech_Packagers_Team
---------------------------------------------------------------------
SuSE CR, s.r.o. e-mail: pnemec(a)suse.cz
Drahobejlova 27 tel:+420 2 9654 2373
190 00 Praha 9 fax:+420 2 9654 2374
Ceska republika http://www.suse.cz
> Hi,
>
> On Monday, May 22, 2006 at 01:44:39, Marc Collin wrote:
>
>> i begin to create rpm for suse
>>
>> configure: error: IMWheel depends on the X11 libraries!
>>
>> i don't understand why it don't get the X11 librairies, i copied all the
>> dvd in /opt/dvd_suse
>
> You are probably missing BuildRequires to xorg-x11-libs and
> xorg-x11-devel
>
> Henne
>
ya know that compile
i read this tutorial
http://www-128.ibm.com/developerworks/library/l-rpm1/
i get: build --rpms /opt/dvd_suse
error: Installed (but unpackaged) file(s) found:
/usr/X11/bin/imwheel
/usr/local/man/man1/imwheel.1.gz
i tried to add in the spec file:
%config(noreplace) /etc/imwheelrc
/usr/X11R6/bin/imwheel
%attr(0755, root, root) %{prefix}/bin/imwheel
%{prefix}/man/man1/imwheel.1x.bz2
but i get
RPM build errors:
File not found: /var/tmp/imwheel-1.0.0pre12-build/etc/imwheelrc
File not found: /var/tmp/imwheel-1.0.0pre12-build/usr/X11R6/bin/imwheel
linux64:/usr/src/packages/SOURCES/imwheel # build --rpms /opt/dvd_suse
logging output to /var/tmp/build-root/.build.log...
----
www.laboiteaprog.com
hi
i begin to create rpm for suse
i installed build
i don't find a good tutorial about specfile
in my spec file i have:
%define prefix /usr/X11
...
...
%prep
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT
%setup
%build
./configure
make all
%install
mkdir -p $RPM_BUILD_ROOT%{prefix}/bin $RPM_BUILD_ROOT%{prefix}/man/man1
$RPM_BUILD_ROOT%{prefix}/etc
/usr/bin/install -c -d -o root -g root -m 0755 $RPM_BUILD_ROOT%{prefix}/bin
/usr/bin/install -c -o root -g root -m 0755 imwheel
$RPM_BUILD_ROOT%{prefix}/bin/imwheel
/usr/bin/install -c -d -o root -g root -m 0755
$RPM_BUILD_ROOT%{prefix}/man/man1
/usr/bin/install -c -o root -g root -m 0644 imwheel.1
$RPM_BUILD_ROOT%{prefix}/man/man1/imwheel.1x
%{bz2} -9 $RPM_BUILD_ROOT%{prefix}/man/man1/imwheel.1x
/usr/bin/install -c -d -o root -g root -m 0755 $RPM_BUILD_ROOT/%{cfg}
/usr/bin/install -c -o root -g root -m 0644 imwheelrc
$RPM_BUILD_ROOT/%{cfg}/imwheelrc
when i do: /usr/src/packages/SOURCES/imwheel # build --rpms /opt/dvd_suse/
i get:
hecking where the pid file goes... /tmp
checking if we suid imwheel at install... no
checking if we use the included getopts... no
checking if we build mdetect... no
checking if we build mdump... no
checking if we build extras... no
checking for gpm-1.19.3/gpm.c... no
checking if we build gpm-imwheel... no
checking for X... no
checking for XCreateWindow in -lX11... no
configure: error: IMWheel depends on the X11 libraries!
linux64:/usr/src/packages/SOURCES/imwheel # error: Bad exit status
from /var/tmp/rpm-tmp.84858 (%build)
i don't understand why it don't get the X11 librairies, i copied all the dvd
in /opt/dvd_suse
if i use only the source
./configure
make all
work without problem
thank
--
www.laboiteaprog.com
Hallo.
After four years after GNOME2/GTK2 release, the last "killer"
application - gnucash, will be finally ported to GNOME2. So we are ready
to drop GNOME1 from SuSE Linux.
There is a proposal of the dropping plan:
Phase 1 (August 2003):
Drop everything not needed for gnucash 1, rename foo2 to foo, if
applicable.
Status: Done
Phase 2 (May 2006):
Drop everything except core GNOME1.
Status: Done
Packages for dropping: bonobo control-center gconf gnome-print
gnome-spell gnome-vfs gtkhtml oaf
Affected packages: none
Phase 3 (May 2006):
Think about robust naming scheme of packages, where can coexist in more
major versions without confusion and often renaming.
See below for discussion summary.
Phase 4 (near future):
Drop core GNOME1.
Status: Little work needed
Packages for dropping: libglade libxml orbit gnome-libs
Affected packages:
loki_setup, loki_update (installer) Proposed solution:
http://www.icculus.org/loki_setup/
frontline (frontend for autotrace) Proposed solution: drop
coriander (IEEE-1394 Digital Camera Controller) Proposed solution:
Replace, drop or port
soundtracker (sound tracker) Proposed solution: Replace, drop or port
bombermaze (game) Proposed solution: Replace or drop
gdk-pixbuf (image library) Proposed solution: do not package GNOME1
extension
perl-Gtk-Perl (perl bindings) Proposed solution: do not package GNOME1
bindings
unixODBC-gui-gtk Proposed solution: do not package GNOME1 interface
and popular third party ogle (DVD player)
Phase 5 (sometimes in future):
Drop GTK1.
Status: A lot of work needed
Packages for dropping: gtk, glib, gdk-pixbuf, gtk-engines imlib
Affected packages: ami gal gau xmms-jack evms-gui pcsx surf xmms xzgv
xmms-gnome2 winetools flac-xmms fvwm2 gqcam smpeg-gtv swami bidwatcher
loki_uninstall powertweak-gtk python-xmms wmakerconf Xdialog manedit
perl-Xmms WindowMaker-applets sylpheed-claws amarok-xmms ardour gbuffy
gentoo squaroid gtkzip nicolatter glchess kanji-lookup pcpmon
perl-Gtk-Perl alsaplayer TeX-Guy unison procmeter usbview xdelta xmorph
sipset xlogmastergoom2k4 xmms-plugins xarchon and popular third party
mplayer
Proposed solution: Use gtk1-compat-devel (and extend it to cover more),
drop, port, turn different frontend instead of GTK1, if available.
Naming schemas:
Desired properties:
- only rename if absolutely not avoidable
- use same name as upstream if possible
- we can only have one package with an identical name
Possible naming schemes:
1) mainline stable without number, old branches with number.
Advantage:
- use same name as upstream if possible for the head version
Problems:
- BuildRequires must not use package name but some feature virtual
- The moment, when devel branch becomes stable, needs ugly renames
- Will cause undefined RPM dependencies
Result: Probably not acceptable
2) keep old branch as is and add suffix for new one
Advantage:
- simple
Problems:
- having branch number for half of packages is irritating.
- additional rename is also not comfortable
Result: Confusing use of branch numbers
3) keep old branch as is and add suffix for new one. Rename back, when
old branch is dropped (It's the actually used approach.)
Advantage:
- simple
Problem:
- having branch number for half of packages is irritating.
- many package renames
Result: Current solution, ugly, partially confusing use of branch
numbers
4) all branches with numbers deduced from, say .pc files names (maybe
with dots and trailing zeroes removed).
Advantage:
- never rename package which does not change API
Problems:
- packages has names different from upstream
- most packages will have untrivial name and version, e. g.
gnome-vfs-2.0-2.12.3 (resp. gnome-vfs2-2.12.3) and also
gtkmm24-2.8.2.
Result: Needs to think twice before using this scheme.
5) ???
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
---------------------------------------------------------------------
SuSE CR, s. r. o. e-mail: sbrabec(a)suse.cz
Drahobejlova 27 tel: +420 296 542 382
190 00 Praha 9 fax: +420 296 542 374
Czech Republic http://www.suse.cz/
Hi,
are there any generic packaging "style" guidelines for SUSE Linux packages?
More precisely, I have the following questions:
- Is %buildroot preferred over $RPM_BUILD_ROOT?
I'm asking because I see more and more packages switching from
$RPM_BUILD_ROOT to %buildroot, but this macro is an implementation detail
according to Red Hat's rpm-list:
http://www.redhat.com/archives/rpm-list/2002-July/msg00121.html
The environment variable is the documented thing. The same is the case with
%optflags vs. $RPM_OPT_FLAGS IIRC.
- Is %configure preferred over ./configure? IIRC until recently, no package
in the distro used it and everything worked well without it.
I'm asking that because %configure IMHO sucks terribly. It sets questionable
values for --libexecdir, --localstatedir and --sharedstatedir for packages
whose prefix is /usr, requires even more macros to be redefined for packages
whose prefix is not /usr (/opt/kde3, /opt/gnome and /usr/X11R6 come to mind)
and always sets --libdir to %{_prefix}/%{_lib} although it must remain
%{_prefix}/lib for some packages.
So what's the exact benefit of %configure? It makes some autoconf calls
shorter by adding the right options and others longer by adding wrong ones,
which have to be corrected manually, so we end up adding options manually in
either case.
- %optflags / $RPM_OPT_FLAGS again:
Are they "nice to have" things or is not using them a bug that should be
reported?
- run-time and -devel packages
Is there a general rule for splitting or not splitting library packages into
run-time and -devel subpackages? Is this decided according to the size of a
library, the number of header files, other criteria?
I'm asking that because IMHO always splitting them is an interesting
approach even for tiny packages as it allows third party people to package
another version of the same library that has a different SONAME without
having to worry about conflicts. The -devel packages would still be clashing
in most of such cases, but the run-time packages can be installed in
parallel.
Andreas Hanke
--
Mobile Internet - E-Mail und Internet immer und �berall!
GMX zum Mitnehmen: http://www.gmx.net/de/go/pocketweb
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've downloaded the 10.1 tree to compile my Packman packages for 10.1. The
problem is there are really strange errors with y2pmbuild. It's a problem with
the old packagemanager and rpm package alternatives.
BuildRequires: kdebase3-devel
unresolvable dependencies:
*** Conflicts ***
Name: avahi-compat-mDNSResponder
Edition: 0.6.5-27
Referers: kdelibs3-3.5.1-47 requires libdns_sd.so()(64bit), kdelibs3-3.5.1-47
requires libdns_sd.so()(64bit)
Conflicts-With: mDNSResponder-lib-107.5-8 conflicts with
avahi-compat-mDNSResponder, mDNSResponder-lib-107.5-8 conflicts with
avahi-compat-mDNSResponder, avahi-compat-mDNSResponder-0.6.5-27 conflicts with
mDNSResponder-lib, avahi-compat-mDNSResponder-0.6.5-27 conflicts with
mDNSResponder-lib
Remove-To-Solve-Conflict: kdebase3-devel, kdelibs3-devel, mDNSResponder-devel,
mDNSResponder-lib
mDNSResponder-lib and avahi-compat-mDNSResponder provide libdns_sd.so, so you
need as BuildRequires
BuildRequires: mDNSResponder-lib kdebase3-devel
-- andreas
- --
http://www.cynapses.org/ - cybernetic synapses
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFEZe2Qf94+j/M+P8YRAqJMAJ0dOA7pmA+k+gorpfNEl+tLkkPIAwCfSVLd
KeUzSPKUAYL/SA/3n1LSS+Y=
=8iQy
-----END PGP SIGNATURE-----