problem with patchset

Other things FVWM Patches
1

I have a problem with patching. I use gentoo:

>>> Emerging (1 of 1) x11-wm/fvwm-2.5.26-r1
 * fvwm-2.5.26.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...                   [ ok ]
 * checking ebuild checksums ;-) ...                                     [ ok ]
 * checking auxfile checksums ;-) ...                                    [ ok ]
 * checking miscfile checksums ;-) ...                                   [ ok ]
>>> Unpacking source...
>>> Unpacking fvwm-2.5.26.tar.bz2 to /var/tmp/portage/x11-wm/fvwm-2.5.26-r1/work
 * Applying 01-fvwm-translucent-menus.patch ...                           [ ok ]
 * Applying 02-fvwm-menu-xlock-xlockmore-compat.diff ...                  [ ok ]
 * Applying 03-ColourBorders.patch ...

 * Failed Patch: 03-ColourBorders.patch !
 *  ( /usr/overlays/layman/123/x11-wm/fvwm/files/03-ColourBorders.patch )
 * 
 * Include in your bugreport the contents of:
 * 
 *   /var/tmp/portage/x11-wm/fvwm-2.5.26-r1/temp/03-ColourBorders.patch-12569.out

 * 
 * ERROR: x11-wm/fvwm-2.5.26-r1 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_unpack
 *             environment, line 2414:  Called epatch '/usr/overlays/layman/123/x11-wm/fvwm/files/03-ColourBorders.patch'
 *             environment, line 1210:  Called die
 * The specific snippet of code:
 *                   die "Failed Patch: ${patchname}!";
 *  The die message:
 *   Failed Patch: 03-ColourBorders.patch!
 * 
 * If you need support, post the topmost build error, and the call stack if relevant.
 * A complete build log is located at '/var/tmp/portage/x11-wm/fvwm-2.5.26-r1/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/x11-wm/fvwm-2.5.26-r1/temp/environment'.
 * This ebuild is from an overlay: '/usr/overlays/layman/123/'
 * 

>>> Failed to emerge x11-wm/fvwm-2.5.26-r1, Log file:

>>>  '/var/tmp/portage/x11-wm/fvwm-2.5.26-r1/temp/build.log'

 * Messages for package x11-wm/fvwm-2.5.26-r1:

 * Failed Patch: 03-ColourBorders.patch !
 *  ( /usr/overlays/layman/123/x11-wm/fvwm/files/03-ColourBorders.patch )
 * 
 * Include in your bugreport the contents of:
 * 
 *   /var/tmp/portage/x11-wm/fvwm-2.5.26-r1/temp/03-ColourBorders.patch-12569.out
 * 
 * ERROR: x11-wm/fvwm-2.5.26-r1 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_unpack
 *             environment, line 2414:  Called epatch '/usr/overlays/layman/123/x11-wm/fvwm/files/03-ColourBorders.patch'
 *             environment, line 1210:  Called die
 * The specific snippet of code:
 *                   die "Failed Patch: ${patchname}!";
 *  The die message:
 *   Failed Patch: 03-ColourBorders.patch!
 * 
 * If you need support, post the topmost build error, and the call stack if relevant.
 * A complete build log is located at '/var/tmp/portage/x11-wm/fvwm-2.5.26-r1/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/x11-wm/fvwm-2.5.26-r1/temp/environment'.
 * This ebuild is from an overlay: '/usr/overlays/layman/123/'
 *

Ebuild fvwm-2.5.26-r1.ebuild:

inherit eutils flag-o-matic

DESCRIPTION="An extremely powerful ICCCM-compliant multiple virtual desktop window manager"
HOMEPAGE="http://www.fvwm.org/"
SRC_URI="ftp://ftp.fvwm.org/pub/fvwm/version-2/${P}.tar.bz2"

LICENSE="GPL-2 FVWM"
SLOT="0"
KEYWORDS="~alpha ~amd64 ~ia64 ~ppc ~ppc64 ~sparc ~x86 ~x86-fbsd"
IUSE="bidi debug doc gtk gtk2-perl imlib netpbm nls perl png readline rplay stroke svg tk truetype vanilla xinerama"

COMMON_DEPEND="
	dev-libs/libxml2
	sys-libs/zlib
	x11-libs/libICE
	x11-libs/libSM
	x11-libs/libX11
	x11-libs/libXau
	x11-libs/libxcb
	x11-libs/libXcursor
	x11-libs/libXdmcp
	x11-libs/libXext
	x11-libs/libXfixes
	x11-libs/libXpm
	x11-libs/libXrandr
	x11-libs/libXrender
	bidi? ( dev-libs/fribidi )
	gtk? (
		=x11-libs/gtk+-1.2*
		imlib? ( media-libs/imlib )
	)
	png? ( media-libs/libpng )
	readline? (
		sys-libs/ncurses
		sys-libs/readline
	)
	stroke? ( dev-libs/libstroke )
	svg? ( gnome-base/librsvg )
	truetype? (
		media-libs/fontconfig
		virtual/xft
	)
	xinerama? (
		x11-proto/xineramaproto
		x11-libs/libXinerama
	)"

RDEPEND="${COMMON_DEPEND}
	dev-lang/perl
	gtk2-perl? ( dev-perl/gtk2-perl )
	perl? ( tk? (
			dev-lang/tk
			dev-perl/perl-tk
			>=dev-perl/X11-Protocol-0.56
		)
	)
	rplay? ( media-sound/rplay )
	userland_GNU? ( sys-apps/debianutils )
	!x86-fbsd? ( netpbm? ( media-libs/netpbm ) )"

DEPEND="${COMMON_DEPEND}
	dev-util/pkgconfig
	doc? ( dev-libs/libxslt )
	x11-proto/xextproto
	x11-proto/xproto"

src_unpack() {
	unpack ${A}

	if ! use vanilla; then
		cd "${S}"

		epatch "${FILESDIR}/01-fvwm-translucent-menus.patch"
		epatch "${FILESDIR}/02-fvwm-menu-xlock-xlockmore-compat.diff"
		epatch "${FILESDIR}/03-ColourBorders.patch"
		epatch "${FILESDIR}/04-ResizeOutlineThin.patch"
		epatch "${FILESDIR}/05-Conditionals.patch"
		epatch "${FILESDIR}/06-FlatSeparators.patch"
		epatch "${FILESDIR}/07-BorderUnderTitle.patch"
		epatch "${FILESDIR}/08-InactiveFont.patch"
		epatch "${FILESDIR}/09-FluxRoundedCorners.patch"
		epatch "${FILESDIR}/10-TopBorder.patch"
		epatch "${FILESDIR}/11-ButtonWidth.patch"
		epatch "${FILESDIR}/12-MultiBorder.patch"
		epatch "${FILESDIR}/13-FvwmButtonsTips.patch"
		epatch "${FILESDIR}/14-FvwmIconMan.patch"
		epatch "${FILESDIR}/15-Hover.patch"
		epatch "${FILESDIR}/16-FirstItemUnderPointer.patch"
		epatch "${FILESDIR}/17-TextOffset.patch"
		epatch "${FILESDIR}/18-ThinGeometryProxy.patch"

	fi
}

src_compile() {
	local myconf="--libexecdir=/usr/lib --with-imagepath=/usr/include/X11/bitmaps:/usr/include/X11/pixmaps:/usr/share/icons/fvwm --enable-package-subdirs --without-gnome"

	# Non-upstream email where bugs should be sent; used in fvwm-bug.
	export FVWM_BUGADDR="desktop-wm@gentoo.org"

	# Recommended by upstream.
	append-flags -fno-strict-aliasing

	# Signed chars are required.
	use ppc && append-flags -fsigned-char

	if use gtk; then
		if ! use imlib; then
			einfo "ATTN: You can safely ignore any imlib related configure errors."
			myconf="${myconf} --with-imlib-prefix=${T}"
		fi
	else
		myconf="${myconf} --disable-gtk"
	fi

	use readline && myconf="${myconf} --without-termcap-library"

	econf ${myconf} \
		$(use_enable bidi) \
		$(use_enable debug debug-msgs) \
		$(use_enable debug command-log) \
		$(use_enable doc htmldoc) \
		$(use_enable nls) \
		$(use_enable nls iconv) \
		$(use_enable perl perllib) \
		$(use_with png png-library) \
		$(use_with readline readline-library) \
		$(use_with rplay rplay-library) \
		$(use_with stroke stroke-library) \
		$(use_enable svg rsvg) \
		$(use_enable truetype xft) \
		$(use_enable xinerama) \
		|| die "econf failed"

	emake || die "emake failed"
}

src_install() {
	emake DESTDIR="${D}" install || die "emake install failed"

	# These are always removed, because gentoo doesn't have anymore
	# a dev-perl/gtk-perl package, so, these modules are pointless.
	rm -f "${D}/usr/share/fvwm/perllib/FVWM/Module/Gtk.pm"
	find "${D}" -name '*FvwmGtkDebug*' -exec rm -f '{}' \; 2>/dev/null

	if use perl; then
		if ! use tk; then
			rm -f "${D}/usr/share/fvwm/perllib/FVWM/Module/Tk.pm"
			if ! use gtk2-perl; then # no tk and no gtk2 bindings
				rm -f "${D}/usr/share/fvwm/perllib/FVWM/Module/Toolkit.pm"
				find "${D}/usr/share/fvwm/perllib" -depth -type d -exec rmdir '{}' \; 2>/dev/null
			fi
		fi

		# Now, the Gtk2.pm file, it will require dev-perl/gtk2-perl
		# so it implies gtk2 as well. That's why we need another use flag.
		if ! use gtk2-perl; then
			rm -f "${D}/usr/share/fvwm/perllib/FVWM/Module/Gtk2.pm"
		fi
	else
		# Completely wipe it if ! use perl
		rm -rf "${D}/usr/bin/fvwm-perllib" \
			"${D}/usr/share/man/man1/fvwm-perllib.1"
	fi

	# Utility for testing FVWM behaviour by creating a simple window with
	# configurable hints.
	if use debug; then
		dobin "${S}/tests/hints/hints_test"
		newdoc "${S}/tests/hints/README" README.hints
	fi

	# Remove fvwm-convert-2.6 as it does not contain any code.
	rm -f "${D}/usr/bin/fvwm-convert-2.6" \
		"${D}/usr/share/man/man1/fvwm-convert-2.6.1"

	echo "/usr/bin/fvwm" > "${D}/etc/X11/Sessions/${PN}"

	dodoc AUTHORS ChangeLog NEWS README \
		docs/{ANNOUNCE,BUGS,COMMANDS,CONVENTIONS} \
		docs/{DEVELOPERS,error_codes,FAQ,TODO,fvwm.lsm}

	# README file for translucent menus patch.
	use vanilla || dodoc "${FILESDIR}/README.translucency"
}

USE Flags: gtk nls perl png readline truetype xinerama.

Patches from fvwm.tuxfamily.org/pub/wiki/portage/files/
Sources from ftp://ftp.fvwm.org/pub/fvwm/version-2/f … 26.tar.bz2
Instructions fvwm.tuxfamily.org/wiki/un_ebuil … our_gentoo

Can help me?

2

So at what point were you going to include the output of this file? This is more useful than uploading an entire ebuild! We’re not a pasting service here – please use a pastebin next time. Google for one.

The patch that’s failing looks like it might be one I wrote. I have zero interest in making that patch play nicely with all the others, so if it is an integration issue, I won’t help you, but I won’t know for sure until I see the contents of that file.

– Thomas Adam

3

pastebin.com/m35e058a1

4

Good – absolutely nothing to do with the code I wrote. This is some other integration error.

– Thomas Adam

5

I diffed it against mine, and seems that it’s the mod I made. I only made trivial changes to it, Thomas, but as you said, it’s not your patch on its original form. I am not sure either if I will continue maintaining all this stuff when it breaks again unless it’s trivial to fix. In any case the patches work against .26 and against current cvs. There’s no doubt about that. So, I must assume that either their packaging or their ebuild break something.

From your log

|diff -U3 -r /var/portage/distfiles/cvs-src/fvwm/fvwm/borders.c fvwm/borders.c

It seems like it’s looking into $PORTDIR/distfiles/cvs-src, which is a nonsense. I can’t see a sense on this all so you are either posting the wrong ebuild (it’s not a cvs ebuild) or mixing the things because your log .out file is about a cvs ebuild and not about a numbered release one. The ebuild you posted doesn’t even inherit the cvs stuff so there’s nothing else to look at. I can’t comment on the correctness of the rest of the ebuild right now, I don’t have the time. But I advise you to try using fvwm-9999 from the devnull overlay instead.

Also, maybe a better place to continue further this discussion could be this thread in the Gentoo forum, since it’s really not an fvwm issue.

forums.gentoo.org/viewtopic-t-46 … t-150.html

That assuming that you use the devnull overlay. As I said, I can’t tell you about other ebuilds/patchsets that there might be around.

6

All thanks for the help. Has replaced /var/portage/distfiles/cvs-src/fvwm/fvwm/borders.c on fvwm/borders.c in 03-ColourBorders.patch and fvwm has builded.

There was a main point: how to use multiborder path? Can put a code of a config for borders and conners textures?


http://img27.picoodle.com/img/img27/3/8/13/f_windowm_5ba97cf.png

7

In the time where I used to enjoy playing with fvwm I played a bit with these things. You might be interested in taking a look into my old configs, for example, this one contains lots of decorations that use the multiborder patch.

jesgue.homelinux.org/fvwm-files/ … un.tar.bz2

There’s a whole directory full of decorations. I don’t remember how the patch work, but you should be able to figure out by taking a look. Feel free to reuse all those decorations if you like them.

8

Thank you. Very useful examples. I found the opportunity to pouring texture to borders:

BorderStyle Active   TiledPixmap brushed_metal/border_active.png
BorderStyle Inactive TiledPixmap brushed_metal/border_inactive.xpm
BorderStyle -- HiddenHandles NoInset Raised

Is it possible for the border every single texture?


Is it possible that all the selected elements of the windows were individual picture textures?

9

I don’t understand the question very well.

I am not sure if I was using all the potential for those patches on my configs, I guess that the simplest thing is to dive into the patch itself, and find the relevant options. I can’t do that now because today I am really really busy, and I have to leave now to drive for a few hours. If you can’t figure out the syntax by looking at the patches (the home page for the patches seems to be dead) I can try to help you, but not today.

10

Sorry for my english. Can be so it will be more clear:

Each piece - individual picture.

Help please when awake are free.

11

You’re now asking a question completely outside of your original one of getting the patches compiled.

You can’t with any of the patches apply images to the corners of the window, but with my Mulitcolor border patch you can assign a colorset to the handles as well as the borders – and in theory it should be possible to do what you want with a gradient colorset. I will leave you to understand what one is and how it’s used.

I don’t like throw-away comments like this which slant demands placed upon the people here who do actually answer the questions put here. It goes without saying that people will reply as/when/if they can, so don’t state it. We’re volunteers, not your own personal workhorse.

– Thomas Adam

12

That that I want it is possible to make in decorations (title). Whether It is possible to place decorations from all four parties of a window?

I am assured that you have understood incorrectly me. I do not write on english - I use the translator. In the original this phrase only the request - a politeness element.

13

8 pixmaps (4+4). Besides that, I’ve seen complete decos based on this patch which used pixmaps on the corners. You can only decorate the border, not add additional shapes that goes off the window though. So, yes, you can with the MultiBorder patch. By looking at the borderc.c part of the patch it’s evident that’s drawing 8 parts of the border (N, NE, E, SE, S, SW, W, NW).

vpupken, I can’t test it, but as for what I perceive from the patch (which could perfectly be wrong) the syntax should be something in the lines of:

Multiborder pix1.xpm pix2.xpm ... pix8.xpm

In the same order that I said above, from N clickwise to NW.

I think that this can also be used as a MenuStyle.

14

Does not work. I’m try something like:

MultiBorderDecor pix1.xpm pix2.xpm ... pix8.xpm
or
MultiBorder pix1.xpm pix2.xpm ... pix8.xpm

And there is documentation on this feature?

15

No. That’s one of the causes why this patch hasn’t made its way into the official branch, I guess.

16

It’s more fundamental than that – the entire decor code is in a state of flux anyway.

– Thomas Adam