-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
what will be the Gnome and KDE path in openSUSE 10.2?
Bye,
-- 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
iD8DBQFE8wMlf94+j/M+P8YRAnH4AKCUITnaSxeCyFQLLzmnLcSHuxMgEwCcDqk0
MtgbCS2WdDguDrYPd6sTGw0=
=KUH4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
I've been thinking a little..
What's the differencies between building packages with y2pmbuild and build?
I'd like the best of the worlds.. I'd like to build several
architectures in one run (build), but I'd also like to have the packages
signed and dumped to the repositary I'm building.
One problem is that it appears as the rpm's doesn't get signed.. I have
to dig into that a bit more, I'm setting some traps in the y2pmbuild
script to see if I can find something out..
I guess a script running 'y2pmbuild-10.1' and then 'linux32 y2pmbuild'
would do the trick, but I'd like to know which exit codes y2pmbuild
generates for failure and success.
--
Anders Norrbring
Norrbring Consulting
I just set up y2pmsh to use y2pmbuild, and immideately ran into
problems. It's probably me, but I don't really see the problem.
The package I'm trying to build, builds great with both 'build' and
'rpmbuild', but with y2pmbuild I get this;
+ echo 'I call /usr/sbin/Check...'
I call /usr/sbin/Check...
+ /usr/sbin/Check
/etc/profile: line 236: /etc/nntpserver: Permission denied
/usr/sbin/Check: line 4: /etc/sysconfig/security: Permission denied
error: Bad exit status from /var/tmp/rpm-tmp.64478 (%install)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.64478 (%install)
And it exists.. Isn't it a bit strange that it works with 'build'?
When the build root is set up, these are shown right before it starts
the build itself:
ldconfig ...
compiler:x:1000:100::/home/compiler:/bin/bash
adjusting permissions
/etc/profile: line 236: /etc/nntpserver: Permission denied
/etc/profile.d/lang.sh: line 33: /etc/sysconfig/language: Permission denied
/etc/profile.d/profile.sh: line 13: /etc/sysconfig/windowmanager:
Permission denied
/etc/profile.d/profile.sh: line 13: /etc/sysconfig/suseconfig:
Permission denied
/etc/profile.d/profile.sh: line 13: /etc/sysconfig/mail: Permission denied
/etc/profile.d/profile.sh: line 13: /etc/sysconfig/proxy: Permission denied
drwxr-xr-x+ 8 compiler users 4096 Sep 28 17:03 /home/compiler
/etc/profile: line 236: /etc/nntpserver: Permission denied
/etc/profile.d/lang.sh: line 33: /etc/sysconfig/language: Permission denied
/etc/profile.d/profile.sh: line 13: /etc/sysconfig/windowmanager:
Permission denied
/etc/profile.d/profile.sh: line 13: /etc/sysconfig/suseconfig:
Permission denied
/etc/profile.d/profile.sh: line 13: /etc/sysconfig/mail: Permission denied
/etc/profile.d/profile.sh: line 13: /etc/sysconfig/proxy: Permission denied
drwxr-xr-x+ 8 compiler users 4096 Sep 28 17:03 /home/compiler
Memory limit set to 2707522KB
sync ...
Any ideas and/or hints, please? I can't find much documentation on this,
so I can't say that I *know* my config is alright...
--
Anders Norrbring
Norrbring Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Michael Matz wrote:
> Hi,
>
> On Mon, 4 Sep 2006, Stanislav Brabec wrote:
>
> > Create a new daemon, running by default: triggerd
>
> In one dist meeting I suggested doing this with e.g. cron or even at. I'm
> not very fond of yet another system daemon, so we should go through great
> pain to integrate it with whatever other default-running daemons we have.
> Or integrate crond into triggerd, whatever.
Cron is too slow. Some packages fails to work correctly, if proper
caches are not updated.
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.cz
Lihovarská 1060/12 tel: +420 284 028 966
190 00 Praha 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz/
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
On 2006-09-25 16:39:17 +0200, Michael Matz wrote:
> On Mon, 4 Sep 2006, Stanislav Brabec wrote:
>
> > Create a new daemon, running by default: triggerd
>
> In one dist meeting I suggested doing this with e.g. cron or even at. I'm
> not very fond of yet another system daemon, so we should go through great
> pain to integrate it with whatever other default-running daemons we have.
> Or integrate crond into triggerd, whatever.
>
> I completely agree with having something like this, though.
>
> > Specified path can be file, directory or recursive directory search.
> > There will be a special flag (file), which will block/postpone the
> > script calling.
>
> Yes, that's the important feature of this idea. Being able to "merge"
> several quickly succeeding requests for work and doing the work only once.
> That's what SuSEconfig was designed for (in part), and needs to be
> retained.
how about incorportating something like that:
http://incron.aiken.cz/
"1. About
This program is the "inotify cron" system. It consist of a daemon and a
table manipulator. You can use it a similar way as the regular cron. The
difference is that the inotify cron handles filesystem events rather
than time periods."
so we wouldnt need to write our own triggerd but could use incron
instead.
this might also be a good example why ubuntu wants to incorporate
cron/at like functionality into their event based init "upstart".
darix
--
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
glibc 2.5 CVS has been tested for a long time in our beta tree, the
final release is now planned for the 29th and therefore we've moved it
to factory on friday.
The switch from 2.4 to 2.5 was rather easy (compared with the switch
From=202.3 to 2.4), so only a few packages needed fixing (I only saw
some using splice as function).
FYI, I'm appending the NEWS file for glibc 2.5 so that you get a high
level overview. Besides this, a lot of bug fixes and optimizations
have been done.
Version 2.5
* For Linux, the sorting of addresses returned by getaddrinfo now also
handles rules 3 and 7 from RFC 3484. Implemented by Ulrich Drepper.
* Allow system admin to configure getaddrinfo with the /etc/gai.conf file.
Implemented by Ulrich Drepper.
* New Linux interfaces: splice, tee, sync_file_range, vmsplice.
* New iconv module for MIK. Contributed by Alexander Shopov.
* For sites with broken group and/or passwd database, the auto-propagate
option of nscd can prevent creating ID lookup entries from the results
of a name lookup and vice versa. This usually is no problem but some
site might have problems with default behavior.
Implemented by Ulrich Drepper.
* Iterating over entire database in NIS can be slow. With the
SETENT_BATCH_READ option in /etc/default/nss a system admin can decide
to trade time for memory. The entire database will be read at once.
Implemented by Ulrich Drepper.
* The interfaces introduced in RFC 3542 have been implemented by
Ulrich Drepper.
* Support for the new ELF hash table format was added by Ulrich Drepper.
* Support for priority inheritance mutexes added by Jakub Jelinek and
Ulrich Drepper.
* Support for priority protected mutexes added by Jakub Jelinek.
Andreas
--
Andreas Jaeger, aj(a)suse.de, http://www.suse.de/~aj/
SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Hello,
Sorry for cross posting. I am not sure which list this issue belongs on.
I am getting this error when trying to use the nethack-vultureseye RPM.
FATAL: Actual size of gametiles.bin does not match the expected size!
Are you sure you are using the gametiles.bin that was built together with
this executable?
So I am having problems trying to package vultureseye and vulturesclaw.
During the building of the to programs they both use/create
./gamedate/graphics/gametiles.bin
They use the same source to build both. The only difference in the
GNUmakefile is this code path
ifeq ($(BUILD), nethack)
BUILDDIR := build_n
CFLAGS += -DVULTURESEYE
else
BUILDDIR := build_s
CFLAGS += -DVULTURESCLAW
endif
The problem is that gametiles.bin is being replaced during the RPM build.
Making the program with make in the orignal source or using the src RPM
creates two seperate and distinct gametiles.bin. But building locally or
in the SUSE build service using...
osc build SUSE_Linux_10.1 i586 nethack-vultures.spec
Here is what I see in the log.
...
Leaving directory `/usr/src/packages/BUILD/vultures-2.1.0/nethack/util'
...
Entering directory `/usr/src/packages/BUILD/vultures-2.1.0/vultures'
...
tiletrans: Wrote 1567 tiles to ./gamedata/graphics/gametiles.bin
267 of 433 objects have unique tiles: 61.7% done
381 of 382 monsters have unique tiles: 99.7% done
...
and
...
Leaving directory `/usr/src/packages/BUILD/vultures-2.1.0/slashem/util
...
Entering directory `/usr/src/packages/BUILD/vultures-2.1.0/vultures'
...
tiletrans: Wrote 1567 tiles to ./gamedata/graphics/gametiles.bin
269 of 537 objects have unique tiles: 50.1% done
401 of 612 monsters have unique tiles: 65.5% done
...
Here is what I see in the log
Entering directory `/usr/src/packages/BUILD/vultures-2.1.0/nethack
cd ./config/
...
cd ../graphics
cp *.png gametiles.bin
/var/tmp/nethack-vultures-2.1.0-0-root-root/usr/games/vultureseye/graphics
...
Entering directory `/usr/src/packages/BUILD/vultures-2.1.0/slashem'
cp *.png gametiles.bin
/var/tmp/nethack-vultures-2.1.0-0-root-root/usr/games/vulturesclaw/graphics
...
I am not sure what to do. When I try to add debut echo statements I
create SIGSEGFAULT or some such error.
Could anyone give me some ideas on trouble shooting this type of
--
Boyd Gerber <gerberb(a)zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I posted the following to the vultures list and then received this reply.
I understand what they are saying, but I am not sure how best to deal with
it and packaging. I know this is not just a build service problem so I
thought this list would be the best place. I have done rpm's before but I
have never had this kind of issue. I am hoping to get some assistance
from all the great people on this list. I also want to say thanks in
advance for any and all assistance.
- ----------------------------------Forwarded-Message-------------------------
On Wednesday 20 September Karen Pease wrote.
>On Wednesday 20 September 2006 01:55 am, Boyd Lynn Gerber wrote:
> Hello,
>
> Here are a few more patches...
>
> Before these paches. The vultureseye/vultureseye of the new rpm package,
> doesn't work due to permission problems and a fatal error on
> gametiles.bin.
>
> ===========================================================================
>===== # vultureseye
> ERROR: could not open log file vultures_log.txt for appending: Permission
> denied [/usr/games/vultureseye/vultureseye]: Warning: cannot write
> scoreboard file record Warning: cannot write scoreboard file record
> ERROR: could not open log file vultures_log.txt for appending: Permission
> denied [/usr/games/vultureseye/vultureseye]: Program initialization has
> failed. Program initialization has failed.
> ERROR: could not open log file vultures_log.txt for appending: Permission
> denied [/usr/games/vultureseye/vultureseye]: Report error to "wizard".
> Report error to "wizard".
> ERROR: could not open log file vultures_log.txt for appending: Permission
> denied [/usr/games/vultureseye/vultureseye]: FATAL: Actual size of
> gametiles.bin does not match the expected size! Are you sure you are using
> the gametiles.bin that was built together with this executable?
>
> FATAL: Actual size of gametiles.bin does not match the expected size!
> Are you sure you are using the gametiles.bin that was built together with
> this executable?
> ===========================================================================
>=====
>
> now I get
>
> ===========================================================================
>===== Program initialization has failed.
> Report error to "wizard".
> FATAL: Actual size of gametiles.bin does not match the expected size!
> Are you sure you are using the gametiles.bin that was built together with
> this executable?
> ===========================================================================
>=====
>
> Here is the differences of this file with the make home and rpm.
>
> gerberb@blg:~> l /usr/games/vultureseye/graphics/gametiles.bin
> -rw-r--r-- 1 root root 7855730 2006-09-19 14:17
> /usr/games/vultureseye/graphics/gametiles.bin
> gerberb@blg:~> l ~/vultures/vultureseyedir/graphics/gametiles.bin
> -rw-r--r-- 1 gerberb users 7681513 2006-09-15 18:59
> /home/gerberb/vultures/vultureseyedir/graphics/gametiles.bin
>
> I am not sure what I need to do to fix this.
This has been a nightmare with the Fedora packages. Basically, we now have
two *different* gametiles.bin files, but they're both built in the same
directory. If you call your two make commands, then copy them to your
staging dir, you're only going to be using one version of gametiles.bin.
You need to back up the gametiles.bin file between builds.
However...
On Fedora, at least, there's a bug. If you do a fresh install, things work
out okay. But if you upgrade, for some reason, it duplicates one of the
gametiles.bin files. I don't know if this will exist in SUSE. I haven't
been trying to fix it, I'm too busy. It works from a fresh install, so
there's the workaround.
- Karen
- ----------------------------------Forwarded-Message-------------------------
- --
Boyd Gerber <gerberb(a)zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/
iD8DBQFFEVy0VtBjDid73eYRAuZMAJ9QaSE33nj4bc5kJnRmaXo2MlgyegCfUhXz
qdT8H1z++9QZpHQIY0ahjKY=
=3ebv
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Re: SuSE 10.1 x86-64
I notice the 32-bit package of gtk2 engines includes cleanice. The
64-bit package is missing it, though the documentation is there. Does
anyone know if this was an oversight? Or is it because something in the
engine source won't compile 64-bit?
--
Ed Hurst
------------
Applied Bible - http://ed.asisaid.com/bible/index.html
Plain & Simple Computer Help - http://ed.asisaid.com/
Mission, Method & Means blog - http://ed.asisaid.com/blog/
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
* Joe Shaw <joeshaw(a)novell.com> [Sep 05. 2006 18:08]:
> Hi,
>
> On Mon, 2006-09-04 at 13:04 +0200, Stanislav Brabec wrote:
> > Create a new daemon, running by default: triggerd
>
> Adding a daemon I think is a really bad idea. We have an overabundance
> of daemons as it is. I think that a packaging daemon (rcd, zmd) is a
> generally bad idea, and that's a lot more full-featured than something
> which just runs scripts. (And I was one of its designers. Whoops.)
A management daemon, supporting role based access (separation of duty),
is highly desirable for enterprises.
Looking at package management, solving dependencies is a resource
intensive task. One can gain speed by constructing a proper in-memory
representation of the dependency graph. However, this might take
longer than the actual run of the dependency solver.
A deamon, which keeps the graph representation in memory, is one
possible approach to make package management fast.
Klaus
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org