Michel Salim wrote:

On 20/08/07, Stanislav Brabec wrote:

...

Michel Salim wrote:

...

I'm currently working on packaging a GNOME application that installs OMF files, and thus requires scrollkeeper to be run on post-install / post-uninstall.

I am getting segfaults, however, which turns out to be because /var/lib/scrollkeeper was not present! i.e. the scrollkeeper database was never initialized.

This is probably a bug with scrollkeeper (shouldn't it initialize its database post-install, and own /var/lib/scrollkeeper?), but should I handle this differently, i.e. run a test before running scrollkeeper-update?

AFAIK, in new SuSE versions scrollkeeper is only a build time dependence and you don't need to call anything in %post/%postun. In old SuSE versions SuSEconfig was updating the database if a flag file in /var/lib was created in %post/%postun.

The segfault you experience is most probably: https://bugzilla.novell.com/show_bug.cgi?id=258576

It is -- I used exactly the same workaround. Any reason why scrollkeeper is not patched to just own and create /var/lib/scrollkeeper?

Not creating /var/lib/scrollkeeper was a bug, which is now fixed. Why to add new user account and another dangerous sgid application? These data were updated by root after the (un)installation and should never be changed by users.

...

You should not call scrollkeeper in %install phase. But it is not so easy as it should be: https://bugzilla.novell.com/show_bug.cgi?id=237140

It was in %postinstall. Should I take it off from there too?

Yes. In new SuSE versions, it is not used any more.

If --disable-scrollkeeper is passed to %configure, actually, I might not even need a BR on it.

I guess that --disable-scrollkeeper should disable only indexing in /var/lib, but I am not sure. See gnome-doc-utils for more.

Doesn't yelp require scrollkeeper, though? How do us poor GNOME users get our documentation indexed? :)

I guess that no. I don't understand this stuff, but I guess, that yelp uses index created by scrollkeeper-preinstall during compilation. http://mail.gnome.org/archives/gnome-doc-devel-list/2006-July/msg00014.html -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@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@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Michel Salim píše v Po 20. 08. 2007 v 11:57 -0400:

On 20/08/07, Stanislav Brabec wrote:

...

Michel Salim wrote:

...

On 20/08/07, Stanislav Brabec wrote:

...

Michel Salim wrote:

...

I'm currently working on packaging a GNOME application that installs OMF files, and thus requires scrollkeeper to be run on post-install / post-uninstall.

I am getting segfaults, however, which turns out to be because /var/lib/scrollkeeper was not present! i.e. the scrollkeeper database was never initialized.

This is probably a bug with scrollkeeper (shouldn't it initialize its database post-install, and own /var/lib/scrollkeeper?), but should I handle this differently, i.e. run a test before running scrollkeeper-update?

AFAIK, in new SuSE versions scrollkeeper is only a build time dependence and you don't need to call anything in %post/%postun. In old SuSE versions SuSEconfig was updating the database if a flag file in /var/lib was created in %post/%postun.

The segfault you experience is most probably: https://bugzilla.novell.com/show_bug.cgi?id=258576

It is -- I used exactly the same workaround. Any reason why scrollkeeper is not patched to just own and create /var/lib/scrollkeeper?

Not creating /var/lib/scrollkeeper was a bug, which is now fixed.

Why to add new user account and another dangerous sgid application? These data were updated by root after the (un)installation and should never be changed by users.

Hm. the %post-un and %post scriplets are run as root anyway, so there is no need for a new sgid application, right?

Sorry. I was thinking you are proposing new UID owning /var/lib/scrollkeeper. There was another problem during build you have another problem: It (incorrectly) tried to create and access /var/lib/scrollkeeper during %install, but it fails, because build process has no permission there. And the bug caused segfault: https://bugzilla.novell.com/show_bug.cgi?id=230786 If scrollkeeper was used as root, it was working correctly.

Since we're at it, how about update-mime-database? Also not needed?

It's needed if you install anything to /usr/share/mime/packages. You must not install anything to /usr/share/mime except packages directory. %post if test -x usr/bin/update-mime-database ; then usr/bin/update-mime-database usr/share/mime >/dev/null fi %postun if test -x usr/bin/update-mime-database ; then usr/bin/update-mime-database usr/share/mime >/dev/null fi Maybe even better would be calling it in %postrans and and conditionally in %postun in case of package removal, but it is not yet tested and will require hack for <= 10.2: https://bugzilla.novell.com/show_bug.cgi?id=235361 -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@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@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Michel Salim wrote:

On 20/08/07, Stanislav Brabec wrote:

...

...

...

Why to add new user account and another dangerous sgid application? These data were updated by root after the (un)installation and should never be changed by users.

Hm. the %post-un and %post scriplets are run as root anyway, so there is no need for a new sgid application, right?

Sorry. I was thinking you are proposing new UID owning /var/lib/scrollkeeper.

There was another problem during build you have another problem: It (incorrectly) tried to create and access /var/lib/scrollkeeper during %install, but it fails, because build process has no permission there. And the bug caused segfault: https://bugzilla.novell.com/show_bug.cgi?id=230786

If scrollkeeper was used as root, it was working correctly.

Thing is, scrollkeeper _was_ used as root during RPM post-install phase, right? In any case, the problem is the version shipping in 10.2+updates does /not/ initialize /var/lib/scrollkeeper unless scrollkeeper-rebuilddb is run.

In past, scrollkeeper was used by root in SuSEconfig (and triggered by RPM postinstall), so /var/lib/scrollkeeper was existing in the build root and this segfault was hidden. Now scrollkeeper is only a development package and nobody calls scrollkeeper-rebuilddb, so /var/lib/scrollkeeper does not exist. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@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@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On 21/08/07, Leo Eraly wrote:

On Tue, 2007-08-21 at 11:16 +0200, Stanislav Brabec wrote:

...

Michel Salim wrote:

...

On 20/08/07, Stanislav Brabec wrote:

...

...

...

Why to add new user account and another dangerous sgid application? These data were updated by root after the (un)installation and should never be changed by users.

Hm. the %post-un and %post scriplets are run as root anyway, so there is no need for a new sgid application, right?

Sorry. I was thinking you are proposing new UID owning /var/lib/scrollkeeper.

There was another problem during build you have another problem: It (incorrectly) tried to create and access /var/lib/scrollkeeper during %install, but it fails, because build process has no permission there. And the bug caused segfault: https://bugzilla.novell.com/show_bug.cgi?id=230786

If scrollkeeper was used as root, it was working correctly.

Thing is, scrollkeeper _was_ used as root during RPM post-install phase, right? In any case, the problem is the version shipping in 10.2+updates does /not/ initialize /var/lib/scrollkeeper unless scrollkeeper-rebuilddb is run.

In past, scrollkeeper was used by root in SuSEconfig (and triggered by RPM postinstall), so /var/lib/scrollkeeper was existing in the build root and this segfault was hidden.

Now scrollkeeper is only a development package and nobody calls scrollkeeper-rebuilddb, so /var/lib/scrollkeeper does not exist.

I'm having the same problem (when packaging rubrica2) for openSUSE 10.2 when calling scrollkeeper in the %post section

Will there be a fix included in the scollkeeper package? Otherwise different solutions/workarounds will show up on various places...(both good and bad solutions)

From what I understand, we're not supposed to call scrollkeeper at all -- scrollkeeper should never be in the Require, Require(post) or Require(postun) anymore.

Regards, -- Michel --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org