[Ebuild] FVWM CVS

Message

swimmer · Post by **swimmer** » Sun May 11, 2008 3:46 pm

Hello i92guboj

I removed the directory from the layman repos and synced devnull with layman and after that I got this error:

>>> Emerging (1 of 1) x11-wm/fvwm-9999 to /
 * fvwm-2.5.26-patchset.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...                                                                                                                                [ ok ]
>>> Creating Manifest for /usr/portage/local/layman/devnull/x11-wm/fvwm
 * checking ebuild checksums ;-) ...                                                                                                                                                           [ ok ]
 * checking auxfile checksums ;-) ...                                                                                                                                                          [ ok ]
 * checking miscfile checksums ;-) ...                                                                                                                                                         [ ok ]
 * checking fvwm-2.5.26-patchset.tar.bz2 ;-) ...                                                                                                                                               [ ok ]
>>> cfg-update-1.8.2-r1: Checksum index is up-to-date ...
>>> Unpacking source...
 * Fetching CVS module fvwm into /usr/portage/distfiles/cvs-src ...
 * Running  cvs -q -f -z1 -d ":pserver:anonymous:guest@cvs.fvwm.org:/home/cvs/fvwm" login
Logging in to :pserver:anonymous@cvs.fvwm.org:2401/home/cvs/fvwm
 * Running  cvs -q -f -z1 -d ":pserver:anonymous@cvs.fvwm.org:/home/cvs/fvwm" update -dP fvwm
 * Copying fvwm from /usr/portage/distfiles/cvs-src ...
 * CVS module fvwm is now in /var/tmp/portage/x11-wm/fvwm-9999/work
>>> Unpacking fvwm-2.5.26-patchset.tar.bz2 to /var/tmp/portage/x11-wm/fvwm-9999/work
 * Applying VerticalSeparatorMargins.patch ...                                                                                                                                                 [ ok ]
 * Applying various patches (bugfixes/updates) ...
 * Done with patching

 * Cannot find $EPATCH_SOURCE!  Value for $EPATCH_SOURCE is:
 * 
 *   /usr/portage/local/layman/devnull/x11-wm/fvwm/files/fvwm-translucent-menus.patch
 *   ( fvwm-translucent-menus.patch )

 * 
 * ERROR: x11-wm/fvwm-9999 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_unpack
 *             environment, line 3210:  Called epatch 'src_unpack'
 *             environment, line 1831:  Called die
 * The specific snippet of code:
 *                   die "Cannot find \$EPATCH_SOURCE!";
 *  The die message:
 *   Cannot find $EPATCH_SOURCE!

The file does not exist (anymore) ... is it still needed?

Apart from that big thanks that you took the time to update ebuild and patches!!!!

Saludos
swimmer

Post by **i92guboj** » Sun May 11, 2008 3:54 pm

Thanks, Stefan.

I just made another commit. See if that fixes the problem.

The patch is still needed if you want transparencies in the menu. I did not notice that because I disable it via an use flag. Test it and report back if it fails.

ExecutorElassus · Post by **ExecutorElassus** » Sun May 11, 2008 3:58 pm

The missing translucency patch appears to have been fixed by the latest commit. IT worked for me, at least.

Now, since I just found this version, I'm going to go see what it actually provides; my fvwm is badly out of date.

Thanks,

EE

Post by **i92guboj** » Sun May 11, 2008 4:09 pm

ExecutorElassus wrote:The missing translucency patch appears to have been fixed by the latest commit. IT worked for me, at least.

Now, since I just found this version, I'm going to go see what it actually provides; my fvwm is badly out of date.

Thanks,

EE

Besides some bugfixes, this new version includes the VerticalMargins patch, I forgot to tell you how it works on my other post. It's documented in the man page and html files, but on a quick note here, it's just as easy as to add a line like this to your config:

Code: Select all

MenuStyle * VerticalMargins 3 3

It receives two integer arguments, which will be the margin in pixels on the top and bottom of the menu. If the values are incorrect, or they are not exactly two arguments, then both values are set to 0, which is the same that you would get if you don't use this option (and it's also the same that fvwm has always done, so the default behavior hasn't changed).

Besides that, if you are using a very old fvwm you will find that support for svg graphics has been added, and the 64 bits support has improved greatly. More info on changes can be found in the NEWS file, the Changelog file and the fvwm web site:

http://fvwm.org/news/

swimmer · Post by **swimmer** » Sun May 11, 2008 4:55 pm

Jesus

it works all now - thanks for the good work!!!

Saludos

ExecutorElassus · Post by **ExecutorElassus** » Sun May 11, 2008 5:42 pm

Sorry, I should have said "my fvwm config is badly out of date;" I was running the latest out of portage before I upgraded. Right now I just have stock window decorations (though all translucent). I guess I need to get off my lazy ass and do some work to make my theme a bit more |337.

But nevermind. I'll work on that myself. Thanks for this patchset.

EE

Post by **i92guboj** » Sun May 11, 2008 5:50 pm

ExecutorElassus wrote:Sorry, I should have said "my fvwm config is badly out of date;" I was running the latest out of portage before I upgraded. Right now I just have stock window decorations (though all translucent). I guess I need to get off my lazy ass and do some work to make my theme a bit more |337.

But nevermind. I'll work on that myself. Thanks for this patchset.

EE

Cool. Remember to check the news and changelog, you might find some tips there about what needs to be changed.

Also, as I said, I am now working with David Shakaryan to get the ebuilds in portage into shape. A ebuild for 2.5.25 has been already submitted. Another for 2.5.26 has been created, reworked from the ground, and much cleaner and smarter than the previous one. That one has not been submitted to portage as far as I know, but for those that preffer to use a non-cvs ebuild, you can get the ebuild for 2.5.26 this way:

Code: Select all

svn co http://overlays.gentoo.org/svn/dev/omp/

ExecutorElassus · Post by **ExecutorElassus** » Thu May 22, 2008 8:44 pm

Hmm... now (devnull rev. 122) it seems to be looking for "fvwm-live.desktop," when what's in the files/ directory is just "fvwm.desktop." I changed it, rebuilt the manifest with 'ebuild fvwm-9999.ebuild digest,' and I'm now compiling it. I'll let you know if it breaks. Should I just be using the regular portage ebuilds at this point, or is the overlay further ahead?

Thanks again. This whole subversion thing is great.

EE

Post by **i92guboj** » Thu May 22, 2008 9:19 pm

ExecutorElassus wrote:Hmm... now (devnull rev. 122) it seems to be looking for "fvwm-live.desktop," when what's in the files/ directory is just "fvwm.desktop." I changed it, rebuilt the manifest with 'ebuild fvwm-9999.ebuild digest,' and I'm now compiling it. I'll let you know if it breaks. Should I just be using the regular portage ebuilds at this point, or is the overlay further ahead?

Thanks again. This whole subversion thing is great.

EE

The ebuild has suffered a rebuild from the ground. Little from the original fvwm is remaining, this is true for both, the portage and the devnull versions. So, some breakage like this is to be expected. I am willing to hear and solve all the issues if any. However, I am looking at the ebuild right now and that piece seems to be ok.

I suggest to wipe the x11-wm/fvwm dir from the devnull overlay, and resync with "layman -S". If the problem persists, complain here again.

About which ebuild to use... Well, it's up to you. The devnull ebuild also can apply a set of custom patches. That's the main difference with the 2.5.26 ebuild in portage. So, if you don't use these patches there's no point in using the cvs ebuild, but it will not hurt either, it's basically the same code and the same ebuild except for the cvs bits.

I am now maintaining the portage ebuild, so, for now, you can be sure that the ebuilds in portage will be as up to date as they can be. There's always a slight chance that the cvs ebuild can break from one to another day, that should never happen with the portage ebuilds... But, in fvwm those breakages are rare, because the fvwm cvs branch itself is often as stable (sometimes even more) than the numbered releases.

So, the choice is up to you.

Cheers.

swimmer · Post by **swimmer** » Sat Jan 10, 2009 5:15 pm

Jesus, the fvwm-ebuild in the devnull overlay is suffering a dependancy from virtual/xft too :-/

Can you fix this or isn't it in your hands anymore?

Saludos

Post by **i92guboj** » Sat Jan 10, 2009 9:12 pm

swimmer wrote:Jesus, the fvwm-ebuild in the devnull overlay is suffering a dependancy from virtual/xft too :-/

Can you fix this or isn't it in your hands anymore?

Saludos

I don't really know. I haven't updated fvwm since devnull migrated to hg from cvs. I just tried and it doesn't work. However I've reported it and it should be fixed soon (either by me if I gain access or by whomever wants to maintain it from now on).

Thanks for spotting and reporting the bug and regards

swimmer · Post by **swimmer** » Sun Jan 11, 2009 12:10 am

Thanks again for your efforts!

And congratulations with your promotion

Best regards
swimmer

ocin · Post by **ocin** » Sun Jan 11, 2009 1:12 am

Fixed :)

swimmer · Post by **swimmer** » Sun Jan 11, 2009 1:18 am

Ok - then many thanks both of you!

Dominique_71 · Post by **Dominique_71** » Sun Jan 11, 2009 7:48 pm

I can see that the keyword is still wrong. Live cvs ebuilds must use the missing keyword "".

The missing keyword is mean for untested ebuild. That is the case of all the live ebuilds because you just cannot test such an ebuild and for cause: the source code can change at anytime.

The missing keyword give another advantage than just to inform about the status of the ebuild. An user can choose to use the stable version of a package with "arch", the unstable with "~arch" and the live version with "**".

ExecutorElassus · Post by **ExecutorElassus** » Tue Feb 24, 2009 6:26 pm

Whoops. Same problem with digest verification I ran into with my last post: the manfiest wants "fvwm-live.desktop," but the file is "fvwm.desktop." Rebuilding the digest fixes it.

Thanks for the ebuildis, guys.

EE

ocin · Post by **ocin** » Tue Feb 24, 2009 8:36 pm

We dont use KEYWORDS="", we use package.mask instead, see here.
Btw: The Manifest says fvwm.desktop, so no problem there.

Or are you not talking about the ebuilds in devnull overlay? I'm confused now.
Which overlay is used? Please explain i92guboj! (btw you still have access to devnull)

ExecutorElassus · Post by **ExecutorElassus** » Tue Feb 24, 2009 8:42 pm

Um, aren't we all using the devnull overlay? Anyway, that's the one I'm talking about: it's looking for fvwm-live.desktop, which requires renaming a file and rebuilding the digest.

Thanks!

EE

Post by **i92guboj** » Tue Feb 24, 2009 9:03 pm

ExecutorElassus wrote:Um, aren't we all using the devnull overlay? Anyway, that's the one I'm talking about: it's looking for fvwm-live.desktop, which requires renaming a file and rebuilding the digest.

Thanks!

EE

I don't know what your sources are, but the live ebuild I maintain has nothing like that in the Manifest. No one has reported that, and I sync the overlay once in a while just in case someone else changed something. Furthermore, you can see yourself:

Code: Select all

# layman -s devnull
* Running command "cd "/var/portage/local/layman/devnull" && /usr/bin/hg pull -u "http://hg.core.ws/devnull""...
pulling from http://hg.core.ws/devnull
searching for changes
no changes found
* 
* Success:
* ------
* 
* Successfully synchronized overlay "devnull".
# cd /var/portage/local/layman/devnull/x11-wm/fvwm/
# grep -r live *
fvwm-9999.ebuild:       ewarn "This is a live CVS ebuild, it is unstable by nature, and is"
# grep desktop Manifest 
AUX fvwm.desktop 5638 RMD160 d7a4100749ad03778f52361167cf4f8204b0ed83 SHA1 63484485b7746dbb00779d8debafbdae5a5c7c03 SHA256 d52d00dd9911d63f129229d4220727da083a468bb765c200b8ae9bcbb278f294

Maybe you need to do some cleaning. Delete and re-add the overlay, and try again.

EDIT: Fixed code.

ocin · Post by **ocin** » Wed Feb 25, 2009 12:37 pm

I have noticed that the desktop file is in files/ but does not get installed at all.
This is fixed now.

Dominique_71 · Post by **Dominique_71** » Sun Mar 08, 2009 11:09 am

ocin wrote:We dont use KEYWORDS="", we use package.mask instead, see here.

I am talking about the fvwm live ebuild. To use package.mask instaed of KEYWORDS="" is breaking gentoo policy. The theory is here: devmanual: keywording.

No keyword
If a package has no keyword for a given arch, it means it is not known whether the package will work, or that insufficient testing has occurred for ~arch.

The last statement is what you get with a live ebuild: a package that have insufficient testing for ~arch.
It is another and confusing statement at the same url:

The package.mask file can be used to 'hard mask' individual or groups of ebuilds. This should be used for testing ebuilds or beta releases of software, and may also be used if a package has serious compatibility problems. Packages which are not hard masked must not have a dependency upon hard masked packages.

fvwm-themes and fvwm-crystal are depending on fvwm and are not hard masked.
In practice, portage is using KEYWORDS="" for live ebuilds. We can see this as example with sci-electronics/ng-spice-rework

Code: Select all

$ cat ng-spice-rework-18.ebuild |grep -i keyword
KEYWORDS="~amd64 ~ppc ~sparc ~x86"
$ cat ng-spice-rework-9999.ebuild |grep -i keyword
KEYWORDS=""

So, I don't understand why this ebuild is using another policy than the ebuilds in portage, especially when portage's policy give more freedom to the user and have a better systematic.

By using package.mask, the user must use package.mask. By using KEYWORDS="", the user must use package.keywords and still have the possibility to use package.mask (as example when the package is sloted and have live ebuilds for 2 slots (ardour, museseq,... - pro-audio overlay))

Post by **i92guboj** » Sun Mar 08, 2009 9:48 pm

Not that it matters, but I also agree that this ebuild (and the rest of ebuilds in devnull by that matter) should abide by this police. People installing devnull might just want to use one or two ebuilds while wanting to keep the rest of the system in official ~arch. Right now this is only possible by masking the whole overlay which is a nonsense.

This is one of the reasons why a person just fish an ebuild and put it in a local overlay instead of using layman to pick the whole overlay.

Post by **i92guboj** » Tue Mar 10, 2009 10:44 pm

Hi again

I just wanted to let you know that I have made a slight update, nothing critical. From the changelog:

Code: Select all

* fvwm-9999 (10 March 2009)

        10 March 2009; Jesús Guerrero <i92guboj@terra.es> 
        Removed libxml2 dep, with USE=doc we depend on libxslt
        Added xlock use flag, xlockmore is required if enabled,
                and if disabled then we remove the fvwm-menu-xlock stuff

Just a bit of cleaning and slight corrections in the dependencies.

Post by **i92guboj** » Thu Mar 19, 2009 10:31 pm

There has been some movement in the fvwm cvs lately, mostly related to the perl stuff and that. It seems that at some point someone changed the menu stuff related to xlock so the Gentoo patch for xlock is no longer needed. I removed if (actually commented it) from the ebuild. It's now in the mercurial repo for devnull. I haven't still removed the patch becase I have never used that feature, just in case.

So, if someone around is using this xlock thingie and want to check, now it's time to do so, before I remove if definitely.

Dominique_71 · Post by **Dominique_71** » Fri Jul 13, 2012 8:27 pm

I found updated patches here: fvwm+ 2.6.5-3 on arch linux.

It is for fvwm-2.6.5 (not yet in portage. I made an ebuild by just renaming the 2.6.3 portage ebuild and modifying the following section:

Code: Select all

src_prepare() {
	if ! use vanilla; then
		epatch "${FILESDIR}/01-TranslucentMenus.patch"
		epatch "${FILESDIR}/02-ColourBorders.patch"
		epatch "${FILESDIR}/03-ResizeOutlineThin.patch"
		epatch "${FILESDIR}/04-Conditionals.patch"
		epatch "${FILESDIR}/05-FlatSeparators.patch"
		epatch "${FILESDIR}/06-BorderUnderTitle.patch"
		epatch "${FILESDIR}/07-InactiveFont.patch"
		epatch "${FILESDIR}/08-FluxRoundedCorners.patch"
		epatch "${FILESDIR}/09-TopBorder.patch"
		epatch "${FILESDIR}/10-ButtonWidth.patch"
		epatch "${FILESDIR}/11-MultiBorder.patch"
		epatch "${FILESDIR}/12-FvwmButtonsTips.patch"
		epatch "${FILESDIR}/13-FvwmIconMan.patch"
		epatch "${FILESDIR}/14-Hover.patch"
		epatch "${FILESDIR}/15-FirstItemUnderPointer.patch"
		epatch "${FILESDIR}/16-ThinGeometryProxy.patch"
	fi
}

You will need the patches. Just decompress the archive and put the files into $FILESDIR.