Progress on Unity under Arch Linux!

qiuwei · 2013-03-03 08:47:35

@chenxiaolong

I'm not sure whether you can host your build server on Amazon EC2 or http://www.cloudbees.com/, anyway if you want a stable dedicated server, I will definitely donate to it:)

Last edited by qiuwei (2013-03-03 08:47:51)

qiuwei · 2013-03-03 09:02:34

@chenxiaolong

qt4-ubuntu is not in your test repo. I couldn't find it in the building log of jenkins either.

EDIT:
Also libindicate-qt in the test repo is not updated, it still depends on qt instead of qt4.

EDIT2:
In Unity-for-Arch-Extra, everpad is missing. And the dependency of it python2-shiboken is neither in aur nor in the git repo.

I guess we need some validation script to check whether all of the packages in the git repo are also in dropbox.

EDIT3:
OK, I realized that python2-shiboken is provided by python-shiboken. Then python-shiboken should depend on qt4. I will create pull request on github.

Last edited by qiuwei (2013-03-03 11:26:42)

tydell · 2013-03-03 10:12:55

chenxiaolong wrote:

I've just started a rebuild for compiz-ubuntu for the new protobuf update. If you look within the next ~50 minutes, you can see it compile http://cxl.epac.to:8091/job/UFA-2.0-Bui … 12/console

Thanks for quick response. Now unity works good with new protobuf package.

steeeve · 2013-03-03 14:08:09

hi
yesterday i installed unity from the source. i set the launcher to autohide, but it wont reveal when i move the mouse to the left edge. i tried to change the sensitivity, it didn't help
i'm using the bumblebee with the latest drivers. i tried to disable the nvidia-driver cause i read that there where problems, but it didn't help.

any suggestions what i'm doing wrong?

ludwig · 2013-03-03 15:01:27

steeeve wrote:

hi
yesterday i installed unity from the source. i set the launcher to autohide, but it wont reveal when i move the mouse to the left edge. i tried to change the sensitivity, it didn't help
i'm using the bumblebee with the latest drivers. i tried to disable the nvidia-driver cause i read that there where problems, but it didn't help.
any suggestions what i'm doing wrong?

Have you set up "reveal location" in the "Behaviour" tab of the "Appearance" to the "left side"?
It's "top left corner" by default.

steeeve · 2013-03-03 15:48:44

ludwig wrote:

steeeve wrote:
hi
yesterday i installed unity from the source. i set the launcher to autohide, but it wont reveal when i move the mouse to the left edge. i tried to change the sensitivity, it didn't help
i'm using the bumblebee with the latest drivers. i tried to disable the nvidia-driver cause i read that there where problems, but it didn't help.
any suggestions what i'm doing wrong?
Have you set up "reveal location" in the "Behaviour" tab of the "Appearance" to the "left side"?
It's "top left corner" by default.

i tried both, nothing works

oi_wtf · 2013-03-03 17:34:05

well, sounds like you didn't install xorg-server-ubuntu,
the launcher revelation depends on some things patched into X by ubuntu...

chenxiaolong · 2013-03-03 18:33:37

qiuwei wrote:

@chenxiaolong
I'm not sure whether you can host your build server on Amazon EC2 or http://www.cloudbees.com/, anyway if you want a stable dedicated server, I will definitely donate to it:)

Thanks for the offer! I really appreciate it, but that's not something I can do right now. I'm 17 years old, so I can't even sign up because I don't have a credit card I'll definitely consider it in the future though.

chenxiaolong · 2013-03-03 18:41:34

qiuwei wrote:

@chenxiaolong
qt4-ubuntu is not in your test repo. I couldn't find it in the building log of jenkins either.

This isn't a bug. I have to add packages manually to Jenkins. For big packages, like qt4-ubuntu, I want to make sure that it compiles fine before I add it, so I don't waste time waiting for a broken package to build

qiuwei wrote:

EDIT:
Also libindicate-qt in the test repo is not updated, it still depends on qt instead of qt4.

This is due to the commits in my qt4 branch being older than HEAD in the master branch. This is due to the way git works and I don't think there's a way to fix it.

qiuwei wrote:

EDIT2:
In Unity-for-Arch-Extra, everpad is missing. And the dependency of it python2-shiboken is neither in aur nor in the git repo.

I haven't added everpad because the python-pyside and python-shiboken packages depend on Qt. I'll add them later today.

qiuwei wrote:

I guess we need some validation script to check whether all of the packages in the git repo are also in dropbox.

https://github.com/chenxiaolong/jenkins … sh-repo.py The build system will make sure that all built packages are published (or else the Jenkins UFA-3.0-Publish-Repo job will be marked as failed). As long as I all the git packages to Jenkins, they will always be published to the repo.

EDIT: libindicate-qt is building: http://cxl.epac.to:8091/job/UFA-2.0-Bui … ate-qt/27/

Last edited by chenxiaolong (2013-03-03 18:44:24)

qiuwei · 2013-03-03 19:04:14

Thanks for the reply. That's awesome!
And I found out that using dropbox as a repo is a wise choice, it's so fast! I can get 4 MB/s easily, much faster than all other official repos.

chenxiaolong · 2013-03-03 19:11:38

qiuwei wrote:

Thanks for the reply. That's awesome!
And I found out that using dropbox as a repo is a wise choice, it's so fast! I can get 4 MB/s easily, much faster than all other official repos.

4 MB/s ?? I wish my internet is that fast

I'm adding the everpad packages now:

Last edited by chenxiaolong (2013-03-04 06:05:52)

steeeve · 2013-03-03 20:25:11

oi_wtf wrote:

well, sounds like you didn't install xorg-server-ubuntu,
the launcher revelation depends on some things patched into X by ubuntu...

that was the mistake
thanks

qiuwei · 2013-03-04 08:32:58

@chenxiaolong

Everpad is now in the test repo, but there is something wrong with it.
I got

Traceback (most recent call last):
  File "/usr/bin/everpad", line 9, in <module>
    load_entry_point('everpad==2.5dev', 'gui_scripts', 'everpad')()
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 343, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2307, in load_entry_point
    return ep.load()
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2013, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "/usr/lib/python2.7/site-packages/everpad/pad/indicator.py", line 8, in <module>
    from everpad.pad.editor import Editor
  File "/usr/lib/python2.7/site-packages/everpad/pad/editor/__init__.py", line 6, in <module>
    from everpad.interface.editor import Ui_Editor
  File "/usr/lib/python2.7/site-packages/everpad/interface/editor.py", line 125, in <module>
    from PySide import QtWebKit
ImportError: cannot import name QtWebKit

Since I noticed that

/usr/lib/python2.7/site-packages/PySide/QtWebKit.so

is not presented.

I think we should also include qtwebkit as dependency of python-pyside.

EDIT:
I wanted to try it out, however your dashboard shows that it takes 1 hour and 41 minutes to compile!

Last edited by qiuwei (2013-03-04 08:37:19)

divansantana · 2013-03-04 11:26:24

I know I must be doing something wrong...
I still have "qt-ubuntu and qt4 are in conflict (qt)". using unity.xe-xe.org repo.

pacman wants to remove one or the other.

Any ideas?

oi_wtf · 2013-03-04 11:55:15

well, i think pekmop just hasn't updated his repo yet.

qiuwei · 2013-03-04 15:30:25

divansantana wrote:

I know I must be doing something wrong...
I still have "qt-ubuntu and qt4 are in conflict (qt)". using unity.xe-xe.org repo.
pacman wants to remove one or the other.
Any ideas?

The reason is that archlinux now includes qt5 also in extra. So they need to rename all of qt stuff to qt4 as they did for python.

The solution is to either wait or to compile qt4-ubuntu by yourself( I guess chenxiaolong would also include qt4-ubuntu in his test repo quite soon).
The compiling process takes around 1 hour on my laptop with i5 cpu equipped.

chenxiaolong · 2013-03-04 17:05:54

qiuwei wrote:

@chenxiaolong

Everpad is now in the test repo, but there is something wrong with it.
I got

Traceback (most recent call last):
  File "/usr/bin/everpad", line 9, in <module>
    load_entry_point('everpad==2.5dev', 'gui_scripts', 'everpad')()
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 343, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2307, in load_entry_point
    return ep.load()
  File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2013, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "/usr/lib/python2.7/site-packages/everpad/pad/indicator.py", line 8, in <module>
    from everpad.pad.editor import Editor
  File "/usr/lib/python2.7/site-packages/everpad/pad/editor/__init__.py", line 6, in <module>
    from everpad.interface.editor import Ui_Editor
  File "/usr/lib/python2.7/site-packages/everpad/interface/editor.py", line 125, in <module>
    from PySide import QtWebKit
ImportError: cannot import name QtWebKit

Since I noticed that

/usr/lib/python2.7/site-packages/PySide/QtWebKit.so

is not presented.

I think we should also include qtwebkit as dependency of python-pyside.

EDIT:
I wanted to try it out, however your dashboard shows that it takes 1 hour and 41 minutes to compile!

Thanks! I've added qtwebkit to the dependencies. python-pyside and qt4-ubuntu are compiling now. This is going to take forever...

http://cxl.epac.to:8091/job/UFAE-2.0-Bu … /3/console
http://cxl.epac.to:8091/job/UFA-2.0-Bui … /1/console

EDIT: Holy crap, Qt runs a huge g++ command http://i.imgur.com/KbS4Sod.png

EDIT2: That took forever... Well, at least my server builds faster than launchpad.net

Last edited by chenxiaolong (2013-03-05 00:35:20)

qiuwei · 2013-03-04 20:46:50

Something a little off topic.

Canonical now announced their new plan about the x server, it's not wayland but mir!
And they are returning to Qt/QML which they dropped not long ago.

I don't know whether it would be harder or easier for Unity-for-arch in the future, but there would be definitely a lot of work!
I hope it's going to be a real revolution for Linux desktop this time!

chenxiaolong · 2013-03-05 00:31:18

qiuwei wrote:

Something a little off topic.
Canonical now announced their new plan about the x server, it's not wayland but mir!
And they are returning to Qt/QML which they dropped not long ago.
I don't know whether it would be harder or easier for Unity-for-arch in the future, but there would be definitely a lot of work!
I hope it's going to be a real revolution for Linux desktop this time!

No more X! No more Compiz! Yay I don't really care if the Wayland or Mir wins in the end, as long as X goes away.

Anyway...I will be packaging the new UnityNext and Mir stuff as soon as it comes out. mir-bzr and mesa-mir are already available in the Unity-for-Arch git repo. And if there's a Linux desktop revolution, I'll make sure Arch users aren't left out

EDIT: Looks like mir is pretty useless right now. Their demo is a black screen, even in Ubuntu.

Last edited by chenxiaolong (2013-03-05 01:37:44)

didaho · 2013-03-05 13:58:22

Hi! Anyone using Java Swing based apps on Arch+Unity?

I use Netbeans regularly and its completely broken under unity, it seems as if all windows take into account the missing menu height even if the window doesn't have a menu. I tried other swing based apps and they are all completely messed up.

I'm using Oracles Java 7 btw.

Any tips? I already tried to disable the menuproxy before launching the app but it stays the same....

thanks!

oi_wtf · 2013-03-05 14:16:21

Same here, also tried disabling the globalmenu...
i'm using jdk7-openjdk 7.u13_2.3.7-2 , I wanted to try downgrading that package next to see,
if it's something related to java or if it's related to unity/compiz...

edit: downgraded down till 7.u9_2.3.3-1, no change... must be something related to some UFA-package,
but I've not installed all updates from 2013-03-04, I'll try that next...

Last edited by oi_wtf (2013-03-05 14:36:34)

oi_wtf · 2013-03-06 05:18:17

[RANT]

chenxiaolong wrote:

No more X! No more Compiz! Yay I don't really care if the Wayland or Mir wins in the end, as long as X goes away.

It's right, X is quite old and most of it doesn't fit modern needs.
But I don't like the way Canonical goes with Mir...
Why start a completely new project instead of contributing to existing projects?
They just said, "Wayland doesn't fit our needs" instead of contributing to it so it'll become something that fits.
Which wouldn't have been that hard, if they'd actually talked to wayland devs.
Why split everything up instead of cooperating and create something really awesome together?

That's the one thing that irritates me about Linux generally: Too much splitting up. (distros, init, DE/WM, etc.)
Well, it's nice to have many flavors available, so one can choose whatever fits ones needs,
but it would be nice if there was more cooperation.
For example, almost every distro has got it's own package-manager, which all do more or less the same thing.
So why reinvent the wheel a dozen times?
Wouldn't one, or maybe two managers, combining the know-how of all that package-managers out there,
of much better quality and efficiency than those many independent ones out there?
Or if at least the devs of the different managers would exchange knowlege about common problems or provide compatible api's?
It's not that there would be any (financial) damage by exchanging "secrets" or supporting the same api's, like there might be for M$ if they'd would spit out their secrets.

Same goes in my opinion for distros, init-systems, DEs and wMs, display servers, etc...
Well, concerning distros, it is, as I said, nice to have many, but nevertheless I think less is more here, too,
since more people would pull in the same direction, won't confuse newcomers
and make it more attractive to everyone, since it'd be a lot more consistent.
And they could do flavors like there's Kubuntu and Xubuntu to provide different sets of software.

But that'll probably remain a dream of mine...
[/RANT]

that said, i'll go to bed now...
been up the whole night drinking beer
and reading about X, Wayland and Mir (oooh, it rhymes O.o)

Last edited by oi_wtf (2013-03-06 05:28:53)

chenxiaolong · 2013-03-06 06:08:30

oi_wtf wrote:

[RANT]
chenxiaolong wrote:
No more X! No more Compiz! Yay I don't really care if the Wayland or Mir wins in the end, as long as X goes away.
It's right, X is quite old and most of it doesn't fit modern needs.
But I don't like the way Canonical goes with Mir...
Why start a completely new project instead of contributing to existing projects?
They just said, "Wayland doesn't fit our needs" instead of contributing to it so it'll become something that fits.
Which wouldn't have been that hard, if they'd actually talked to wayland devs.
Why split everything up instead of cooperating and create something really awesome together?

I was pretty happy with Mir until later yesterday. I was watching the conversation on #wayland in IRC between the Mir and Wayland developers. Basically, everything Canonical said is wrong with Wayland is false. They said that their input had problems? That was false. They said that they want proprietary drivers to work? Wayland can do that. They want existing Android drivers to work? Wayland can support that.

In some cases, I don't think the Mir developers even understand Wayland completely. During the UDS session on Mir today, one of the developers basically avoided the question on the reasons against using Wayland. He was not able to give a single technical reason (despite saying that he studied Wayland and Weston "carefully"). I mean, the fact that Wayland can support everything that Mir can (without changing existing code) shows how the protocol is very well thought out.

oi_wtf wrote:

That's the one thing that irritates me about Linux generally: Too much splitting up. (distros, init, DE/WM, etc.)
Well, it's nice to have many flavors available, so one can choose whatever fits ones needs,
but it would be nice if there was more cooperation.
For example, almost every distro has got it's own package-manager, which all do more or less the same thing.
So why reinvent the wheel a dozen times?
Wouldn't one, or maybe two managers, combining the know-how of all that package-managers out there,
of much better quality and efficiency than those many independent ones out there?
Or if at least the devs of the different managers would exchange knowlege about common problems or provide compatible api's?
It's not that there would be any (financial) damage by exchanging "secrets" or supporting the same api's, like there might be for M$ if they'd would spit out their secrets.

I agree. I really hope we don't get into a situation where it's like:

sudo systemctl stop Mir.service
sudo rmmod nvidia-mir
sudo modprobe nvidia-wayland
sudo systemctl start Wayland-Compositor.service

If anything, Wayland and Mir should at least share the same drivers.
As for the package managers, I know exactly what you mean (especially after packaging so many things). Like, in Arch, it's "make DESTDIR="${pkgdir} install". In Fedora, it's switched around: "make install DESTDIR=$RPM_BUILD_ROOT". In openSUSE, it's "%make_install" or "%makeinstall". And don't even get me started on the different package names between distros. Or distro-incompatible scripts: is it /etc/default, /etc/conf.d, or /etc/sysconfig, or is it /var/lib/adm?

I don't know if you've read the blog by the PackageKit developer. In order to work with every single package manager, he had to workaround almost every single API. I remember reading that he only uses 3% of yum's API in Fedora. He had to reimplement the rest.

oi_wtf wrote:

Same goes in my opinion for distros, init-systems, DEs and wMs, display servers, etc...
Well, concerning distros, it is, as I said, nice to have many, but nevertheless I think less is more here, too,
since more people would pull in the same direction, won't confuse newcomers
and make it more attractive to everyone, since it'd be a lot more consistent.
And they could do flavors like there's Kubuntu and Xubuntu to provide different sets of software.

Right. Arch and Ubuntu have different goals (customization vs user friendliness), but that doesn't mean they have to use completely different tools.

oi_wtf wrote:

But that'll probably remain a dream of mine...
[/RANT]
that said, i'll go to bed now...
been up the whole night drinking beer
and reading about X, Wayland and Mir (oooh, it rhymes O.o)

Same here Since Mir means peace in some languages, someone wrote on the Phoronix forums: "may Mir die in Mir"

EDIT: Oh yeah, I just remembered. During the UDS, someone asked how Mir was going to work in a virtual machine. None of the devs knew how to reply. They clearly have no idea what's ahead of them.

EDIT2: A crazy, impossible, ridiculous, insert-word-here theory of mine: What if they knew that Wayland is better, that they couldn't design a quality display server. Maybe...just maybe they announce Mir, so that the Wayland developers would implement the features they want, and then they switch to Wayland.

Last edited by chenxiaolong (2013-03-06 06:59:43)

Kopkins · 2013-03-06 15:43:05

Ubuntu Wiki wrote:

Why Not Wayland / Weston?
An obvious clarification first: Wayland is a protocol definition that defines how a client application should talk to a compositor component. It touches areas like surface creation/destruction, graphics buffer allocation/management, input event handling and a rough prototype for the integration of shell components. However, our evaluation of the protocol definition revealed that the Wayland protocol does not meet our requirements. First, we are aiming for a more extensible input event handling that takes future developments like 3D input devices (e.g. Leap Motion) into account. Please note though that Wayland's input event handling does not suffer from the security issues introduced by X's input event handling semantics (thanks to Daniel Stone and Kristian Høgsberg for pointing this out). With respect to mobile use-cases, we think that the handling of input methods should be reflected in the display server protocol, too. As another example, we consider the shell integration parts of the protocol as privileged and we'd rather avoid having any sort of shell behavior defined in the client facing protocol.
However, we still think that Wayland's attempt at standardizing the communication between clients and the display server component is very sensible and useful, but due to our different requirements we decided to go for the following architecture w.r.t. to protocol-integration:
A protocol-agnostic inner core that is extremely well-defined, well-tested and portable.
An outer-shell together with a frontend-firewall that allow us to port our display server to arbitrary graphics stacks and bind it to multiple protocols.
In summary, we have not chosen Wayland/Weston as our basis for delivering a next-generation user experience as it does not fulfill our requirements completely. More to this, with our protocol- and platform-agnostic approach, we can make sure that we reach our goal of a consistent and beautiful user experience across platforms and device form factors. However, Wayland support could be added either by providing a Wayland-specific frontend implementation for our display server or by providing a client-side implementation of libwayland that ultimately talks to Mir.

That was more vague than I would have liked/expected from a wiki.

chenxiaolong · 2013-03-06 16:30:24

I, sure as hell, will not be porting this if/when it is released: http://www.phoronix.com/scan.php?page=n … px=MTMxOTc I will never support DRM in any form or fashion.

What does Canonical think they are doing?

Arch Linux

#1651 2013-03-03 08:47:35

Re: Progress on Unity under Arch Linux!

#1652 2013-03-03 09:02:34

Re: Progress on Unity under Arch Linux!

#1653 2013-03-03 10:12:55

Re: Progress on Unity under Arch Linux!

#1654 2013-03-03 14:08:09

Re: Progress on Unity under Arch Linux!

#1655 2013-03-03 15:01:27

Re: Progress on Unity under Arch Linux!

#1656 2013-03-03 15:48:44

Re: Progress on Unity under Arch Linux!

#1657 2013-03-03 17:34:05

Re: Progress on Unity under Arch Linux!

#1658 2013-03-03 18:33:37

Re: Progress on Unity under Arch Linux!

#1659 2013-03-03 18:41:34

Re: Progress on Unity under Arch Linux!

#1660 2013-03-03 19:04:14

Re: Progress on Unity under Arch Linux!

#1661 2013-03-03 19:11:38

Re: Progress on Unity under Arch Linux!

#1662 2013-03-03 20:25:11

Re: Progress on Unity under Arch Linux!

#1663 2013-03-04 08:32:58

Re: Progress on Unity under Arch Linux!

#1664 2013-03-04 11:26:24

Re: Progress on Unity under Arch Linux!

#1665 2013-03-04 11:55:15

Re: Progress on Unity under Arch Linux!

#1666 2013-03-04 15:30:25

Re: Progress on Unity under Arch Linux!

#1667 2013-03-04 17:05:54

Re: Progress on Unity under Arch Linux!

#1668 2013-03-04 20:46:50

Re: Progress on Unity under Arch Linux!

#1669 2013-03-05 00:31:18

Re: Progress on Unity under Arch Linux!

#1670 2013-03-05 13:58:22

Re: Progress on Unity under Arch Linux!

#1671 2013-03-05 14:16:21

Re: Progress on Unity under Arch Linux!

#1672 2013-03-06 05:18:17

Re: Progress on Unity under Arch Linux!

#1673 2013-03-06 06:08:30

Re: Progress on Unity under Arch Linux!

#1674 2013-03-06 15:43:05

Re: Progress on Unity under Arch Linux!

#1675 2013-03-06 16:30:24

Re: Progress on Unity under Arch Linux!

Board footer