I've updated libwebkit in the testing repo to a recent nightly snapshot.
It requires new libsoup that also adds cookie support. This introduced a .so name bump.


I've already updated midori. Maybe there are more rebuilds required.
Please check all packages that (opt)depend on libwebkit.


-Andy

On Thu, Mar 5, 2009 at 6:06 AM, Andreas Radke <a.radke@arcor.de> wrote:
> I've updated libwebkit in the testing repo to a recent nightly snapshot. It
> requires new libsoup that also adds cookie support. This introduced a .so
> name bump.
>
> I've already updated midori. Maybe there are more rebuilds required. Please
> check all packages that (opt)depend on libwebkit.
>
> -Andy
>

The other packages that (opt)depend on libwebkit are gimp and gimp
devel. I'll rebuild them if necessary. There's also
community/lib/perl-gtk2-webkit but that'll need to wait for libwebkit
to hit extra.

On Thu, Mar 5, 2009 at 1:52 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
> On Thu, Mar 5, 2009 at 6:06 AM, Andreas Radke <a.radke@arcor.de> wrote:
>> I've updated libwebkit in the testing repo to a recent nightly snapshot. It
>> requires new libsoup that also adds cookie support. This introduced a .so
>> name bump.
>>
>> I've already updated midori. Maybe there are more rebuilds required. Please
>> check all packages that (opt)depend on libwebkit.
>>
>> -Andy
>>
>
> The other packages that (opt)depend on libwebkit are gimp and gimp
> devel. I'll rebuild them if necessary. There's also
> community/lib/perl-gtk2-webkit but that'll need to wait for libwebkit
> to hit extra.
>

Gimp and gimp-devel needs to be rebuilt but a simple rebuild doesn't
fix the plugin. The plugin crashes with the following error message on
the terminal:

GLib-ERROR **: The thread system is not yet initialized.
aborting...

I haven't looked into it any further. The plugin is only used to use
the gimp help browser but a regular web browser can also be used to
view the help files so it's not critical.

BTW, I've noticed that you are using the svn source version in the
pkgrel so we have pkgrel=0.41443 which looks quite weird. Why don't
you just use the version as stated in configure.ac for the package,
i.e. 1.1.1-1? It seems to be sufficient IMO. If you really want to
also have the svn version there, put it in the pkgver: 1.1.1.41443-1.
The pkgrel is supposed to be used for the PKGBUILD version, not the
package's source version.

On Thu, Mar 5, 2009 at 2:32 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
> BTW, I've noticed that you are using the svn source version in the
> pkgrel so we have pkgrel=0.41443 *which looks quite weird. Why don't
> you just use the version as stated in configure.ac for the package,
> i.e. 1.1.1-1? It seems to be sufficient IMO. If you really want to
> also have the svn version there, put it in the pkgver: 1.1.1.41443-1.
> The pkgrel is supposed to be used for the PKGBUILD version, not the
> package's source version.

Agreed. Additionally, we never fully "agreed" on this whole decimal
pkgrel thing, and I, for one, find it annoying to see
"foobar-1.2.3.4-1.3.7" - it's a major wtf moment. Not only should the
pkgrel reflect _our_ version, not upstream's version, but we should
try to stick to integers to avoid confusion, and it's not like we're
going to run out of integers any time soon