Who maintains scribus? archweb declares I am the maintainer but I don't know why. I managed to get a working update using the following diff, should I do the build?

I pushed the update to [extra] so that libpng/tiff rebuilds can use latest version. Rémy.

On 01/30/2012 10:22 PM, Allan McRae wrote:

On 31/01/12 04:43, Ionut Biru wrote:

...

On 01/18/2012 09:33 PM, Ionut Biru wrote:

...

On 01/18/2012 09:17 PM, Ionut Biru wrote:

...

Hi,

i cannot speak about libtiff but libpng 1.5 rebuild is going to be difficult. All previous warnings are now fatal and a lot of patching is involved.

I managed to get all patches from gentoo here (thanks gentoo devs!):

http://pkgbuild.com/~ioni/libpng-1.5 http://pkgbuild.com/~ioni/libpng-1.5.tar.gz

Patches also can be found in fedora rawhide and openbsd.

The rebuild is done as usually in staging and at first you won't be able to build any packages until their dependencies are built first.

note for all packages, pay attention to configure log to see if png is really detected and not just blindly rebuild a package.

I'm going to move the packages into testing now. Don't forget to fully update your system before reporting bugs on our tracker.

It will stay in testing for couples of weeks (maxim 2) until is moved our in extra.

Happy testing.

Looks like some packages have dependency issues:

(11/53) upgrading djvulibre [######################] 100% gtk-update-icon-cache: error while loading shared libraries: libpng14.so.14: cannot open shared object file: No such file or directory error: command failed to execute correctly

(14/53) upgrading evince [######################] 100% gtk-update-icon-cache: error while loading shared libraries: libpng14.so.14: cannot open shared object file: No such file or directory error: command failed to execute correctly

(16/53) upgrading firefox [######################] 100% gtk-update-icon-cache: error while loading shared libraries: libpng14.so.14: cannot open shared object file: No such file or directory error: command failed to execute correctly

(18/53) upgrading gdk-pixbuf2 [######################] 100% g_module_open() failed for /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: libpng14.so.14: cannot open shared object file: No such file or directory

Allan

seems like i need to add a versioned dependendy to install gdk-pibxbuf2 before everything else. -- Ionuț

Here are couples of instructions about dealing with broken packages. As usually, fully update your system before reporting bugs and don't forget about enabling community-testing along with multilib-testing(if necessary) What to do when one of your favorite application returns: libpng14.so.14: cannot open shared object file: No such file or directory do $ LD_DEBUG=files yourapp > yourapp.log 2>&1 $ grep libpng14.so.14 yourapp.log $ pacman -Qo /path/to/soname/that/links/to/libpng14.so.14 If is not from the repo, rebuild it yourself, otherwise, report it on our tracker. -- Ionuț

On 01/02/12 08:29, Pierre Schmitz wrote:

Am 30.01.2012 21:20, schrieb Ionut Biru:

...

On 01/30/2012 10:22 PM, Allan McRae wrote:

...

On 31/01/12 04:43, Ionut Biru wrote: (18/53) upgrading gdk-pixbuf2 [######################] 100% g_module_open() failed for /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: libpng14.so.14: cannot open shared object file: No such file or directory

Allan

seems like i need to add a versioned dependendy to install gdk-pibxbuf2 before everything else.

So pacman does not install the packages according to their dependency tree if there are no versioned deps? Sounds like a pacman bug to me. I'd rather have that one fixed then having versioned deps all over the place that cause more problems than they attempt to solve.

Nope...

pacman -Qo /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so is owned by librsvg 2.34.2-3

pacman -Si librsvg ... Depends On : gdk-pixbuf2>=2.24.1-3 pango libcroco

So librsvg depends on gdk-pixbug2 but the install script of gdk-pixbuf2 requirs librsvg... This can not be solved until we have transaction hook support in pacman. Allan

On Thu, Feb 2, 2012 at 3:06 PM, Eric Bélanger wrote:

On Mon, Jan 30, 2012 at 1:43 PM, Ionut Biru wrote:

...

On 01/18/2012 09:33 PM, Ionut Biru wrote:

...

On 01/18/2012 09:17 PM, Ionut Biru wrote:

...

Hi,

i cannot speak about libtiff but libpng 1.5 rebuild is going to be difficult. All previous warnings are now fatal and a lot of patching is involved.

I managed to get all patches from gentoo here (thanks gentoo devs!):

http://pkgbuild.com/~ioni/libpng-1.5 http://pkgbuild.com/~ioni/libpng-1.5.tar.gz

Patches also can be found in fedora rawhide and openbsd.

The rebuild is done as usually in staging and at first you won't be able to build any packages until their dependencies are built first.

note for all packages, pay attention to configure log to see if png is really detected and not just blindly rebuild a package.

I'm going to move the packages into testing now. Don't forget to fully update your system before reporting bugs on our tracker.

It will stay in testing for couples of weeks (maxim 2) until is moved our in extra.

Happy testing.

-- Ionuț

FYI, there is a problem with the rebuilt directfb in community-testing, at least qingy doesn't work with it. I'm still trying to figure what's the problem. I tried the newer releases but whether it's in the same 1.4 branch or the newer 1.5 branch, it doesn't work. We'll need to wait until it's fix to move the rebuild out of testing.

directfb is fixed now. Building with --enable-debug did the trick (don't ask me why).