Once Xfce4.8 is available from your favorite repo this entire thread will be irrelevant but if you, like me, simply couldn't wait then this is for you. *Note*You should most likely remove everything Xfce4 that is currently on your system or I would expect some conflicts. The .debs created with checkinstall are by no means the equivalent of proper Debian packages. In fact the names and packages will be different. There for it would also be advisable to remove these same .debs prior to installing the proper Debian packages once available.

Although I used checkinstall it certainly isn't required. If you prefer not to use checkinstall simply edit the build script to use make install instead of checkinstall --options and skip the echo '' > description-pak bit. Otherwise everything's the same.

Create a little checkinstall build script to save some typing. Just copy paste using your own email address.

XfburnIf you've built Xfce4.8 you don't want to install Xfburn from Debian repos since that pulls in several pieces of Xfce4.6.You can build libraries from http://www.libburnia-project.org/ but those already available in Debian work fine.

Indeed there are some new things. Since release Thunar 1.1.0, Thunar has had support for network flesystems through gvfs. This is huge (for some anyway). Read what Jannis Pohlmann has to say about it. Another blog mentions remote filesystem supportBelow is a brief summary of the response from Jannis

most of these features are available only because of the folks at GNOME. I may not agree with all design decisions made in GIO and especially not in GVfs but overall the APIs are pretty good. ThunarVFS definitely is more lightweight than GIO/GVfs. It has file:// and trash:// hard-coded in very efficient ways and the API is more to the point as well.There’s also no D-Bus or DeviceKit-disks/gnome-disk-utility involved which makes it somewhat faster and requires less dependencies. But leightweightness is not everything of course. GIO is more flexible, extensible and is used indirectly because of GTK+ anyway, so it’s fair to say that it has a brighter future than ThunarVFS (which is being deprecated at the moment).

All of the core components have been ported to GIO however not all of the plugins and goodies have.

Some of the notable fixes/changes gleaned directly from source of core components:

libxfce4ui - has hotkey support to popup Xfdesktop menu

Xfce4-appfinder is a complete rewrite- now launch items with startup notification- Port the libxfce4menu code to garcon.- Port to libxfce4ui and gio.- New in this version is the possibility to pass a specific menu file directly to xfce4-appfinder-- xfce4-appfinder /etc/xdg/menus/gnomecc.menu

xfdesktop- Port xfdesktop to GIO and drop the dependency on thunar-vfs.- Drop dependency on libxfcegui4 and use libxfce4ui- HIDDEN CUSTOMISATIONS - Check the README for xfdesktop version 4.5 for further details. Briefly:--If you're using the icon view, and would like to change how the text looks, you have three things you can change: the opacity (transparency) of the rounded text background, the color of the rounded text background, and the color of the text itself. This is done in ~/.gtkrc-2.0 (preferrably ~/.gtkrc.mine)

xfce4-session- Do not try "unix-session" authorization with PolicyKit as this seems to be either broken or not implemented in PolicyKit (bug #6817). This fixes suspend/hibernate in xfce4-session-logout.

I am not able to build thunar-volman before building the xfce-apps.libgudev-1.0-dev seems to be a dependency for thunar-volman.

I got confused and mixed the order of building.I didn't get a useful error message.I added && between the commands in the `build` script, which was of help (configure failed, i got the error message and could figure it out). That might be an idea.

trying to overwrite '/usr/share/icons/hicolor/icon-theme.cache', which is also in package libxfcegui4 4.7.0-1

I tried different variations to install it (removed exo, removed libxfcegui....), but that error keeps coming up for several packages. No google results for me.(trying it with `dpkg -i --force-overwrite`, according to the man-page. We will see... seems to have worked great.htop says 110Mb and it seems very snappy )

"I am not fine with it, so there is nothing for me to do but stand aside." M.D.

trying to overwrite '/usr/share/icons/hicolor/icon-theme.cache', which is also in package libxfcegui4 4.7.0-1

I tried different variations to install it (removed exo, removed libxfcegui....), but that error keeps coming up for several packages. No google results for me.(trying it with `dpkg -i --force-overwrite`, according to the man-page. We will see... seems to have worked great.

Yeah - that was unavoidable and why we set --force-overwrite in /etc/checkinstallrc

You are right about /etc/checkinstallrc.At least a prof that i did copy and paste without much reading. So: good guide

I don't know why the editing of checkinstallrc didn't work for me: i guess INSTALL=0 should have taken care of autoinstalling the resulting deb, which didn't work neither (Some kind of pebkac...).At least i now know that my solution was correct (bit of sweaty hands for me).

Thanks again.

"I am not fine with it, so there is nothing for me to do but stand aside." M.D.

There also might be some unofficial Debian repository, but I guess Debian Xfce Group mailinglist would be good place to ask (:

This also may be useful:

We only keep the debian/ directory of xfce packages in subversion. Our packages which use CDBS use its simple-patchsys when patches to upstream are needed. Otherwise we tend to use dpatch though upstream has an excellent record of accepting sane patches.

It is necessary to create a ../tarballs directory with the .orig.gz tarballs, which are all downloadable at once as follows:cd scripts./get-source.pl [desktop|goodies]

Note that every option accepted by dpkg-buildpackage is accepted by svn-buildpackage too. (In the former example: -rfakeroot -us -uc).

For more detailed instructions, see our HOWTOs.

If you want to rebuild Xfce entirely you can use the pbuilder script available in scripts/pbuilder/pdebuild-sources.sh though you probably want to change the MIRROR= line in pdebuild.conf to point to a local apt-proxy first. The script creates a sid chroot, then builds everything in this chroot, using previously built packages to satisfy dependencies. The script takes an argument, which can be:desktop (build every desktop package)goodies (build every goodies package, you should build desktop packages first)clean (clean every package built)The script resumes itself where it was interrupted. If you want to only rebuild a package, just remove the xfce/build/<packagename> file and restart ./pdebuild-sources.sh

You can also build only one package in pbuilder using the following syntax: ./pdebuild-source.sh [desktop|goodies] [package]

Actually, I'm working on it, but probably there won't be builds for i386 architecture* (it's about resources, compilation and my time). All of work was made by Debian Xfce team, I just put those things together. Also, there (at least today) won't be any goodies, only "main" Xfce (as in here: http://archive.xfce.org/xfce/4.8pre3/src). I'll provide repository link later on.

* - although there will be source repository, so you will be able to rebuild it by yourself.

BTW I have these from Experimental - not sure if that's really required...:libglib2.0-0 (2.27.5-1) ...libglib2.0-bin (2.27.5-1) ...libglib2.0-dev (2.27.5-1)

Well, I compiled it as stated in the first post of this topic, and while I was anxious to see what the next Xfce will be, I think there is no need for rush, pre3 is already out, and final release in a week or two. By that time I hope someone will take care of the packaging.

I mean, I can put debs I have compiled (i386) somewhere on fileshare but I don't think it's the right way to do these things.

Branimir wrote:Well, I compiled it as stated in the first post of this topic, and while I was anxious to see what the next Xfce will be, I think there is no need for rush, pre3 is already out, and final release in a week or two. By that time I hope someone will take care of the packaging.

I believe packaging is already done by Debian Xfce team (I'm using their debianization and almost all of the packages are in the latest version) so they are waiting for final release to push it into official Debian repositories.

Branimir wrote:I mean, I can put debs I have compiled (i386) somewhere on fileshare but I don't think it's the right way to do these things.

If it's an checkinstall made packages, you shouldn't -- they might break someone else's OS. I make packages, as I mentioned earlier, using debianization made by Debian Xfce team and I'm building them properly, which means I'm using pbuilder for this task. I don't want to wait for release and I'm making packages myself cause I want to switch to Xfce and, obviously, I want to use latest release (:

Hadret wrote:If it's an checkinstall made packages, you shouldn't -- they might break someone else's OS. I make packages, as I mentioned earlier, using debianization made by Debian Xfce team and I'm building them properly, which means I'm using pbuilder for this task. I don't want to wait for release and I'm making packages myself cause I want to switch to Xfce and, obviously, I want to use latest release (:

Yes those are checkinstall made packages as described in the first post.

If someone is really eager to try it ASAP, I recommend compiling it by yourself, as noted in the topic, I'm not by all means a linux guru or a programming expert, I just followed the instructions step by step. After all it's just for testing purposes and to give it look at what has 4.8 become and how it works/looks like.

Btw I welcome the comeback of custom menu. Though xfce4-panel has transparency now with Xfwm compositing enabled, I think I'll still use tint2 instead.

The good things:- After Xfce 4.8 release and when Debian Xfce team will pull packages to the Debian official repositories, there should be smooth upgrade;- No need to build anything by yourself;- Proper packages made by Debian Xfce team and built with pbuilder in chroot environment;