Progress on Unity under Arch Linux!

qiuwei · 2012-11-13 19:37:27

chenxiaolong wrote:

I have an off topic question about fonts under Arch: do you set your locale to Chinese? I've been running into this issue lately in both Arch and Fedora: https://ask.fedoraproject.org/question/ … ese-locale which makes it very hard to read the terminal output. Do you have this issue?
Thanks!

I'm not using Chinese locale, but are you using standard fontconfig? I have quite a lot of problems with it(Also with fontconfig-ubuntu since the latest update of fontconfig). So I turned to fontconfig-infinality, it provides very good font effect out of box.

chenxiaolong · 2012-11-14 21:55:17

qiuwei wrote:

chenxiaolong wrote:
I have an off topic question about fonts under Arch: do you set your locale to Chinese? I've been running into this issue lately in both Arch and Fedora: https://ask.fedoraproject.org/question/ … ese-locale which makes it very hard to read the terminal output. Do you have this issue?
Thanks!
I'm not using Chinese locale, but are you using standard fontconfig? I have quite a lot of problems with it(Also with fontconfig-ubuntu since the latest update of fontconfig). So I turned to fontconfig-infinality, it provides very good font effect out of box.

Thanks a lot! My fonts are all fine now.

I still can't seem to find out what causes the (0,0) bug. You're packages work fine, but the chroot builds I do every day are still broken

shiznix · 2012-11-14 23:12:17

chenxiaolong wrote:

I still can't seem to find out what causes the (0,0) bug. You're packages work fine, but the chroot builds I do every day are still broken

I've managed to track the bug down a little using qiuwei's compiz package.
The bug can be found in libcompiz_core.so.0.9.8.4, replace only this file with that found in qiuwei's compiz and window placement works correctly.

chenxiaolong · 2012-11-15 00:21:31

shiznix wrote:

chenxiaolong wrote:
I still can't seem to find out what causes the (0,0) bug. You're packages work fine, but the chroot builds I do every day are still broken
I've managed to track the bug down a little using qiuwei's compiz package.
The bug can be found in libcompiz_core.so.0.9.8.4, replace only this file with that found in qiuwei's compiz and window placement works correctly.

That's really helpful

ldd shows that the compiz_core library depends on the following libraries:

╔═(chenxiaolong@cxl-4270cto)═════════════════(Wed, 14 Nov 2012 18:38:29 -0500)═╗
╠════(/stuff/chenxiaolong/chroots/unity/root/.../compiz-ubuntu/pkg/usr/lib)════╣
╚═⇒  $ ldd /stuff/chenxiaolong/chroots/unity/root/home/builder/Unity-for-Arch/compiz-ubuntu/pkg/usr/lib/libcompiz_core.so.0.9.8.4 
	linux-vdso.so.1 (0x00007fffbedff000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0x00007fa4b6a0e000)
	libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00007fa4b6804000)
	libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00007fa4b6600000)
	libXext.so.6 => /usr/lib/libXext.so.6 (0x00007fa4b63ed000)
	libICE.so.6 => /usr/lib/libICE.so.6 (0x00007fa4b61d1000)
	libSM.so.6 => /usr/lib/libSM.so.6 (0x00007fa4b5fc8000)
	libglibmm-2.4.so.1 => /usr/lib/libglibmm-2.4.so.1 (0x00007fa4b5d5b000)
	libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0x00007fa4b5b55000)
	libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007fa4b585e000)
	libstartup-notification-1.so.0 => /usr/lib/libstartup-notification-1.so.0 (0x00007fa4b5655000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007fa4b535b000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fa4b513e000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fa4b4f3a000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fa4b4c37000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fa4b4a21000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007fa4b467a000)
	libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fa4b445b000)
	libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007fa4b424f000)
	libuuid.so.1 => /usr/lib/libuuid.so.1 (0x00007fa4b404a000)
	libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007fa4b3dfc000)
	libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007fa4b3bf7000)
	librt.so.1 => /usr/lib/librt.so.1 (0x00007fa4b39ef000)
	libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007fa4b3791000)
	libxcb-util.so.1 => /usr/lib/libxcb-util.so.1 (0x00007fa4b358b000)
	libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0x00007fa4b3389000)
	/usr/lib/ld-linux-x86-64.so.2 (0x00007fa4b7008000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fa4b3184000)
	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fa4b2f7e000)
	libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007fa4b2d7c000)
	libffi.so.6 => /usr/lib/libffi.so.6 (0x00007fa4b2b74000)

EDIT: Based on oi_wtf's pacman.log, only three of libcompiz_core's dependencies were updated: glibmm, glib2, and glibc. It is extremely unlikely that glibc (mother of all libraries ) is broken, so that leaves glibmm and glib2.

Last edited by chenxiaolong (2012-11-15 00:26:54)

shiznix · 2012-11-15 22:46:32

chenxiaolong wrote:

shiznix wrote:
chenxiaolong wrote:
I still can't seem to find out what causes the (0,0) bug. You're packages work fine, but the chroot builds I do every day are still broken
I've managed to track the bug down a little using qiuwei's compiz package.
The bug can be found in libcompiz_core.so.0.9.8.4, replace only this file with that found in qiuwei's compiz and window placement works correctly.
That's really helpful
EDIT: Based on oi_wtf's pacman.log, only three of libcompiz_core's dependencies were updated: glibmm, glib2, and glibc. It is extremely unlikely that glibc (mother of all libraries ) is broken, so that leaves glibmm and glib2.

Tried different glibmm versions with no effect, the bug is still present.
Glib2 I'm not convinced is the culprit as I've had this window placement bug through many versions of glib2 and is a package we maintain in our respective repositories.

Feeling that it is not any of the dynamic libraries shown with 'ldd' but something more internal to the creation of libcompiz_core.so
Boost is grabbing my attention at the moment, it's used everywhere in the library and more specifically on window creation and geometry.
But trying a downgrade of boost to 1.4* on Gentoo means a downgrade of glibc from 2.16 to 2.15 as boost-1.4 is known to not work with glibc-2.16.

I tried uninstalling boost and building compiz to try and get compiz to puke out a minimum boost version needed, but it doesn't seem to even check for boost's existence and just fails violently to build

qiuwei · 2012-11-15 22:59:21

shiznix wrote:

chenxiaolong wrote:
shiznix wrote:
I've managed to track the bug down a little using qiuwei's compiz package.
The bug can be found in libcompiz_core.so.0.9.8.4, replace only this file with that found in qiuwei's compiz and window placement works correctly.
That's really helpful
EDIT: Based on oi_wtf's pacman.log, only three of libcompiz_core's dependencies were updated: glibmm, glib2, and glibc. It is extremely unlikely that glibc (mother of all libraries ) is broken, so that leaves glibmm and glib2.
Tried different glibmm versions with no effect, the bug is still present.
Glib2 I'm not convinced is the culprit as I've had this window placement bug through many versions of glib2 and is a package we maintain in our respective repositories.
Feeling that it is not any of the dynamic libraries shown with 'ldd' but something more internal to the creation of libcompiz_core.so
Boost is grabbing my attention at the moment, it's used everywhere in the library and more specifically on window creation and geometry.
But trying a downgrade of boost to 1.4* on Gentoo means a downgrade of glibc from 2.16 to 2.15 as boost-1.4 is known to not work with glibc-2.16.
I tried uninstalling boost and building compiz to try and get compiz to puke out a minimum boost version needed, but it doesn't seem to even check for boost's existence and just fails violently to build

I don't think it would be related to boost because it's a very general C++ library.

chenxiaolong · 2012-11-16 00:31:15

shiznix wrote:

chenxiaolong wrote:
shiznix wrote:
I've managed to track the bug down a little using qiuwei's compiz package.
The bug can be found in libcompiz_core.so.0.9.8.4, replace only this file with that found in qiuwei's compiz and window placement works correctly.
That's really helpful
EDIT: Based on oi_wtf's pacman.log, only three of libcompiz_core's dependencies were updated: glibmm, glib2, and glibc. It is extremely unlikely that glibc (mother of all libraries ) is broken, so that leaves glibmm and glib2.
Tried different glibmm versions with no effect, the bug is still present.
Glib2 I'm not convinced is the culprit as I've had this window placement bug through many versions of glib2 and is a package we maintain in our respective repositories.
Feeling that it is not any of the dynamic libraries shown with 'ldd' but something more internal to the creation of libcompiz_core.so
Boost is grabbing my attention at the moment, it's used everywhere in the library and more specifically on window creation and geometry.
But trying a downgrade of boost to 1.4* on Gentoo means a downgrade of glibc from 2.16 to 2.15 as boost-1.4 is known to not work with glibc-2.16.
I tried uninstalling boost and building compiz to try and get compiz to puke out a minimum boost version needed, but it doesn't seem to even check for boost's existence and just fails violently to build

I tried rebuilding compiz under Fedora and I've hit the window placement issue. Looking at the logs, boost was never updated between the two builds and the original build was compiled with boost 1.50. So, I'm not sure that boost is the cause of the issue.

I've noticed that cairo was updated between the old and new builds on my system in both Arch and Fedora. I'm going to try downgrading that.

EDIT: Nope, not cairo

EDIT2: Packages updated in both Arch and Fedora: cairo, cmake, coreutils, and util-linux. This is confusing as heck...

Last edited by chenxiaolong (2012-11-16 01:25:07)

oi_wtf · 2012-11-16 18:15:45

gnome-menus2 landed in community
https://www.archlinux.org/packages/comm … me-menus2/

Last edited by oi_wtf (2012-11-16 18:17:42)

chenxiaolong · 2012-11-16 21:09:12

oi_wtf wrote:

gnome-menus2 landed in community
https://www.archlinux.org/packages/comm … me-menus2/

Thanks! Deleted from repo.

shiznix · 2012-11-17 00:08:43

chenxiaolong wrote:

I tried rebuilding compiz under Fedora and I've hit the window placement issue. Looking at the logs, boost was never updated between the two builds and the original build was compiled with boost 1.50. So, I'm not sure that boost is the cause of the issue.
I've noticed that cairo was updated between the old and new builds on my system in both Arch and Fedora. I'm going to try downgrading that.
EDIT: Nope, not cairo
EDIT2: Packages updated in both Arch and Fedora: cairo, cmake, coreutils, and util-linux. This is confusing as heck...

OK, turns out it's nothing to do with dependencies but what we do with the binary once it's compiled.

FEATURES="nostrip" USE="debug" CFLAGS="${CFLAGS} -ggdb" emerge compiz

This creates a perfectly working compiz!
Glitchy dash artifacts gone, desktop starts quicker and most importantly window placement is fixed.

Haven't been able to distill it down yet, but enabling '-ggdb' with '-O0' for CFLAGS and not stripping binaries looks to be the magic.
I'll test throughout today and try to come up with an equivalent for Arch but you may be able to do something quicker on your side being more familiar

chenxiaolong · 2012-11-17 01:09:42

shiznix wrote:

chenxiaolong wrote:
I tried rebuilding compiz under Fedora and I've hit the window placement issue. Looking at the logs, boost was never updated between the two builds and the original build was compiled with boost 1.50. So, I'm not sure that boost is the cause of the issue.
I've noticed that cairo was updated between the old and new builds on my system in both Arch and Fedora. I'm going to try downgrading that.
EDIT: Nope, not cairo
EDIT2: Packages updated in both Arch and Fedora: cairo, cmake, coreutils, and util-linux. This is confusing as heck...
OK, turns out it's nothing to do with dependencies but what we do with the binary once it's compiled.
FEATURES="nostrip" USE="debug" CFLAGS="${CFLAGS} -ggdb" emerge compiz
This creates a perfectly working compiz!
Glitchy dash artifacts gone, desktop starts quicker and most importantly window placement is fixed.
Haven't been able to distill it down yet, but enabling '-ggdb' with '-O0' for CFLAGS and not stripping binaries looks to be the magic.
I'll test throughout today and try to come up with an equivalent for Arch but you may be able to do something quicker on your side being more familiar

Wow, that's great! I'll try disabling optimization only and if that doesn't work, I'll add the other two options.

This is one of the things that only Gentoo users can solve Thanks a lot for the solution!

EDIT: I'm trying to build with options=('!strip') and C{XX,}FLAGS="**cflags without -O2 and _FORTIFY_SOURCE** -ggdb"

This causes the compiler to segfault: http://paste.ubuntu.com/1364320/. I've never seen this before.

EDIT2: I tried compiling with CFLAGS set only to "-O0 -ggdb" instead of appending it to the defaults CFLAGS. Unfornately, the (0,0) bug is still not fixed

Last edited by chenxiaolong (2012-11-17 06:51:18)

shiznix · 2012-11-17 08:03:22

chenxiaolong wrote:

Wow, that's great! I'll try disabling optimization only and if that doesn't work, I'll add the other two options.
This is one of the things that only Gentoo users can solve Thanks a lot for the solution!
EDIT: I'm trying to build with options=('!strip') and C{XX,}FLAGS="**cflags without -O2 and _FORTIFY_SOURCE** -ggdb"
This causes the compiler to segfault: http://paste.ubuntu.com/1364320/. I've never seen this before.
EDIT2: I tried compiling with CFLAGS set only to "-O0 -ggdb" instead of appending it to the defaults CFLAGS. Unfornately, the (0,0) bug is still not fixed

Turned out it was actually the USE="debug" part of the commandline that was crucial, not the CFLAGS or stripping.
Long story short, if compiz is built with the cmake flag "-DNDEBUG" it will cause the window placement bug.

Big thanks to all working on this, think we got it finally.
Hoping now that you can reproduce at your end chenxiaolong.
If it wasn't for you guys getting the same bug and being able to provide a working binary I would have floundered.

Always great to see fellow Linux people rise above their respective distros to reach common goals

oi_wtf · 2012-11-18 00:54:39

chenxiaolong wrote:

This causes the compiler to segfault: http://paste.ubuntu.com/1364320/. I've never seen this before.

O.O me neither...

shiznix wrote:

Long story short, if compiz is built with the cmake flag "-DNDEBUG" it will cause the window placement bug.

Just now started a build without that flag. Lets see if it works...

shiznix wrote:

Always great to see fellow Linux people rise above their respective distros to reach common goals

big +1 to that

Last edited by oi_wtf (2012-11-18 01:27:46)

chenxiaolong · 2012-11-18 01:09:33

shiznix wrote:

chenxiaolong wrote:
Wow, that's great! I'll try disabling optimization only and if that doesn't work, I'll add the other two options.
This is one of the things that only Gentoo users can solve Thanks a lot for the solution!
EDIT: I'm trying to build with options=('!strip') and C{XX,}FLAGS="**cflags without -O2 and _FORTIFY_SOURCE** -ggdb"
This causes the compiler to segfault: http://paste.ubuntu.com/1364320/. I've never seen this before.
EDIT2: I tried compiling with CFLAGS set only to "-O0 -ggdb" instead of appending it to the defaults CFLAGS. Unfornately, the (0,0) bug is still not fixed
Turned out it was actually the USE="debug" part of the commandline that was crucial, not the CFLAGS or stripping.
Long story short, if compiz is built with the cmake flag "-DNDEBUG" it will cause the window placement bug.

Robert Xu discovered that building with the CMake Debug target is enough to make Compiz work properly: https://github.com/chenxiaolong/Unity-f … t-10481151 I think we can officially call this fixed thanks to you!

shiznix wrote:

Big thanks to all working on this, think we got it finally.
Hoping now that you can reproduce at your end chenxiaolong.
If it wasn't for you guys getting the same bug and being able to provide a working binary I would have floundered.
Always great to see fellow Linux people rise above their respective distros to reach common goals

Couldn't have said that better

oi_wtf · 2012-11-18 01:27:53

THAT'S IT! Build worked and neither weird render bug nor (0,0) placing bug!
my PKGBUILD: https://dl.dropbox.com/u/76078202/PKGBUILD

I wouldn't use the Debug target since it'll turn off optimizations,
which is clearly not neccessary... it built fine for me with -O3...

Last edited by oi_wtf (2012-11-18 01:34:43)

chenxiaolong · 2012-11-18 01:36:01

The new libunity-webapps update should allow the HUD to work with the webapps.

quiro91 · 2012-11-19 00:15:05

after xf86-video-intel and intel-dri updates, I can't start X again. Maybe a update to xorg-server is required?

chenxiaolong · 2012-11-19 03:34:51

quiro91 wrote:

after xf86-video-intel and intel-dri updates, I can't start X again. Maybe a update to xorg-server is required?

I've updated the xorg-server-ubuntu with the latest Arch patches. Would you mind testing it? I'm not at my computer right now.

quiro91 · 2012-11-19 08:43:54

Everything works as expected, thanks! But... Now I have a new issue, when I open google-chrome:
http://i.imgur.com/liqot.png

chenxiaolong wrote:

quiro91 wrote:
after xf86-video-intel and intel-dri updates, I can't start X again. Maybe a update to xorg-server is required?
I've updated the xorg-server-ubuntu with the latest Arch patches. Would you mind testing it? I'm not at my computer right now.

edmael · 2012-11-19 14:16:27

Hi, just a quick question: what's the best way to install Unity on Arch?
I have currently an installation of Arch+Gnome (x86_64), should I add the repository and install everything from it or should I compile it using the instruction in the first post?

qiuwei · 2012-11-19 17:02:49

edmael wrote:

Hi, just a quick question: what's the best way to install Unity on Arch?
I have currently an installation of Arch+Gnome (x86_64), should I add the repository and install everything from it or should I compile it using the instruction in the first post?

It should be equivalent. But the repo hasn't been updated for days so it still has the window placement bug, you will need to compile it if you want a working system immediately.

edmael · 2012-11-19 17:36:55

qiuwei wrote:

edmael wrote:
Hi, just a quick question: what's the best way to install Unity on Arch?
I have currently an installation of Arch+Gnome (x86_64), should I add the repository and install everything from it or should I compile it using the instruction in the first post?
It should be equivalent. But the repo hasn't been updated for days so it still has the window placement bug, you will need to compile it if you want a working system immediately.

Thanks, I'll try!

kladd · 2012-11-19 17:40:48

After the latest round of updates I clean compiled/installed from the git repo. I'm currently getting a seg fault from gtk-window-decorator. Anyone else experiencing this? Or have suggestions?

gdb output:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000414f97 in meta_calc_button_size ()

Last edited by kladd (2012-11-19 18:36:20)

qiuwei · 2012-11-19 19:29:01

kladd wrote:

After the latest round of updates I clean compiled/installed from the git repo. I'm currently getting a seg fault from gtk-window-decorator. Anyone else experiencing this? Or have suggestions?
gdb output:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000414f97 in meta_calc_button_size ()

It's related to metacity. I've encountered this problem before. Normally a rebuild of metacity should fix the problem.
Are you using metacity-ubuntu from the git repo or standard metacity?

kladd · 2012-11-19 20:23:54

qiuwei wrote:

kladd wrote:
After the latest round of updates I clean compiled/installed from the git repo. I'm currently getting a seg fault from gtk-window-decorator. Anyone else experiencing this? Or have suggestions?
gdb output:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000414f97 in meta_calc_button_size ()
It's related to metacity. I've encountered this problem before. Normally a rebuild of metacity should fix the problem.
Are you using metacity-ubuntu from the git repo or standard metacity?

metacity-ubuntu from the repo at the moment. After a rebuild I'm still getting the seg fault.

EDIT:

Okay, problem solved. Compiled compiz-ubuntu and metacity-ubuntu since they're interdependent and installed both at the same time. Then I rebuilt compiz-ubuntu and installed it. Now gtk-window-decorator works fine. Thanks for the rebuilding tip.

Last edited by kladd (2012-11-19 22:56:57)

Arch Linux

#1376 2012-11-13 19:37:27

Re: Progress on Unity under Arch Linux!

#1377 2012-11-14 21:55:17

Re: Progress on Unity under Arch Linux!

#1378 2012-11-14 23:12:17

Re: Progress on Unity under Arch Linux!

#1379 2012-11-15 00:21:31

Re: Progress on Unity under Arch Linux!

#1380 2012-11-15 22:46:32

Re: Progress on Unity under Arch Linux!

#1381 2012-11-15 22:59:21

Re: Progress on Unity under Arch Linux!

#1382 2012-11-16 00:31:15

Re: Progress on Unity under Arch Linux!

#1383 2012-11-16 18:15:45

Re: Progress on Unity under Arch Linux!

#1384 2012-11-16 21:09:12

Re: Progress on Unity under Arch Linux!

#1385 2012-11-17 00:08:43

Re: Progress on Unity under Arch Linux!

#1386 2012-11-17 01:09:42

Re: Progress on Unity under Arch Linux!

#1387 2012-11-17 08:03:22

Re: Progress on Unity under Arch Linux!

#1388 2012-11-18 00:54:39

Re: Progress on Unity under Arch Linux!

#1389 2012-11-18 01:09:33

Re: Progress on Unity under Arch Linux!

#1390 2012-11-18 01:27:53

Re: Progress on Unity under Arch Linux!

#1391 2012-11-18 01:36:01

Re: Progress on Unity under Arch Linux!

#1392 2012-11-19 00:15:05

Re: Progress on Unity under Arch Linux!

#1393 2012-11-19 03:34:51

Re: Progress on Unity under Arch Linux!

#1394 2012-11-19 08:43:54

Re: Progress on Unity under Arch Linux!

#1395 2012-11-19 14:16:27

Re: Progress on Unity under Arch Linux!

#1396 2012-11-19 17:02:49

Re: Progress on Unity under Arch Linux!

#1397 2012-11-19 17:36:55

Re: Progress on Unity under Arch Linux!

#1398 2012-11-19 17:40:48

Re: Progress on Unity under Arch Linux!

#1399 2012-11-19 19:29:01

Re: Progress on Unity under Arch Linux!

#1400 2012-11-19 20:23:54

Re: Progress on Unity under Arch Linux!

Board footer