[opensuse-gnome] Using scrollkeeper: /var/lib/scrollkeeper missing?
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? Thanks, -- Michel -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
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 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 -- 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-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
On 20/08/07, Stanislav Brabec <sbrabec@suse.cz> 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?
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? If --disable-scrollkeeper is passed to %configure, actually, I might not even need a BR on it. Doesn't yelp require scrollkeeper, though? How do us poor GNOME users get our documentation indexed? :) Many thanks, -- Michel -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
Michel Salim wrote:
On 20/08/07, Stanislav Brabec <sbrabec@suse.cz> 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-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
On 20/08/07, Stanislav Brabec <sbrabec@suse.cz> wrote:
Michel Salim wrote:
On 20/08/07, Stanislav Brabec <sbrabec@suse.cz> 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?
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.
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
Ah OK. simpler to maintain the spec that way anyway. It's actually a modification of Jan's drivel package, so I'm waiting to hear from him before uploading it. Since we're at it, how about update-mime-database? Also not needed? Thanks, -- Michel -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
Michel Salim píše v Po 20. 08. 2007 v 11:57 -0400:
On 20/08/07, Stanislav Brabec <sbrabec@suse.cz> wrote:
Michel Salim wrote:
On 20/08/07, Stanislav Brabec <sbrabec@suse.cz> 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-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
On 20/08/07, Stanislav Brabec <sbrabec@suse.cz> 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.
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
Got it, thanks. Those are already in the original spec. Package is up at openSUSE:Community (drivel-2.0.3-3.1). If anyone wants to get it working for versions lower than 10.2, or for Factory, feel free to dive in. Regards, -- Michel -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
Michel Salim wrote:
On 20/08/07, Stanislav Brabec <sbrabec@suse.cz> 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-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
On Mon, 2007-08-20 at 03:45 -0400, 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?
Probably not, we should probably just fix the package to create the dir, although the long term opensuse and upstream direction has been to kill this package with extreme prejuidice. -JP -- JP Rosevear <jpr@novell.com> Novell, Inc. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
participants (3)
-
JP Rosevear -
Michel Salim -
Stanislav Brabec