Pantheon Shell on Archlinux

Pylm · 2014-07-15 15:48:29

any ... progress?

quequotion · 2014-07-24 06:57:02

Pylm wrote:

any ... progress?

Keep an eye on launchpad; there's a lot of activity going on.

I think the elementary OS devs intend to hold back official releases until they have a stable, fully integrated product. That's going to be difficult to achieve so long as their upstream is Canonical.

I'm working on a suite of pantheon-bzr packages (tenatively "pantheon-bzr-qq" based on aur-alucryd/pantheon, Unity for Arch, and some of my own packages) to run Pantheon the bleeding-edge best in can be on arch. Compromises have to be made: Canonical is upstream for some things, like indicators, and these things are only becoming more dependent on their patched packages and more integrated into their Unity DE.

The elementary OS devs face almost equal difficulty in maintaining stability and compatibility against the whims of Mark Shuttleworth or taking drastic measures to remove all dependence on Ubuntu. Neither task will be easy, but the latter will certainly be more profitable in the long run. I think we could be of great help by fully porting Pantheon to arch. Another reason I'm putting together a new, bleeding-edge, suite is to make it easy for myself (and hopefully others) to do rapid test building on the development tip.

orschiro · 2014-07-24 09:19:38

I think we could be of great help by fully porting Pantheon to arch

Fully agree! Are there any simple tasks (not programming intensive) that can support you?

pgoetz · 2014-07-24 19:51:52

quequotion wrote:

The elementary OS devs face almost equal difficulty in maintaining stability and compatibility against the whims of Mark Shuttleworth or taking drastic measures to remove all dependence on Ubuntu. Neither task will be easy, but the latter will certainly be more profitable in the long run.

It's not clear why the elementary OS devs aren't seeing this. A lot of people (myself included) got sucked up in the Ubuntu feel good only to realize that "hey, this is actually a private company making what they believe to be commercially advantageous decisions". The first screw up was the upstart vs. systemd thing. That's now fixed, but Ubuntu users will have to deal with legacy Upstart crap for a long time to come, even though it's now officially obsolete. I recently once again got bit by some weird Upstart initialization problems that were hard to track down. The second screw up was the Unity vs. gnome 3 schism, although I can see this one, because the gnome devs appear to be hard to work with. The deal killer was Mir vs. Wayland. Going forward, this is going to be a huge problem for many multi-desktop installations. I have users who use KDE, gnome 3, cinnamon, and Unity. How am I supposed to manage systems where most of the UI's are running on Wayland and exactly 1 is running on Unity? Answer: I'm going to drop Unity.

But what's going to happen to Pantheon when Ubuntu starts making library changes to accommodate Mir and Mutter only runs on Wayland?

Unfortunately I think all the tasks for converting Pantheon to run on Arch are very programming intensive. If people are interested in working on this, what is the best way to proceed? Continuing this discussion on a 2-year old forum thread doesn't seem like the best approach. Maybe we should use the Pantheon wiki page? An official fork of the Pantheon bzr repository, maybe switched to git or mercurial, which are more commonly used these days?

olantwin · 2014-07-24 23:04:51

pgoetz wrote:

quequotion wrote:
The elementary OS devs face almost equal difficulty in maintaining stability and compatibility against the whims of Mark Shuttleworth or taking drastic measures to remove all dependence on Ubuntu. Neither task will be easy, but the latter will certainly be more profitable in the long run.
Unfortunately I think all the tasks for converting Pantheon to run on Arch are very programming intensive. If people are interested in working on this, what is the best way to proceed? Continuing this discussion on a 2-year old forum thread doesn't seem like the best approach. Maybe we should use the Pantheon wiki page? An official fork of the Pantheon bzr repository, maybe switched to git or mercurial, which are more commonly used these days?

I would be interested in helping.

Forking should be a last resort, if upstream don't want to support anything but Ubuntu.
Since they are already starting to package for debian, they hopefully are not opposed to an Arch port.

I'd prefer git, but I'm fine with learning bzr as well.

Edit: Maybe longterm it would be possible to have a working "rolling" version of Pantheon and a "LTS" version for official eOS releases. (rolling in this case: staying up to date with gnome/gtk stable.)

Last edited by olantwin (2014-07-25 06:51:22)

orschiro · 2014-07-25 04:35:31

Since they are already starting to package for debian, they hopefully are not opposed to an Arch port.

Did someone already have contact with the elementary devs about creating an "official" Arch port? If they fully support and agree to a port, then the next step could indeed be setting up a Github repository.

Maybe @Alucryd wants to take the lead on this?

Last edited by orschiro (2014-07-25 04:38:05)

quequotion · 2014-07-25 06:53:33

orschiro wrote:

Are there any simple tasks (not programming intensive) that can support you?

Hard to say; there's not really a to-do list and I think that's the first thing that needs to be worked out: find out, down to specific bits of code, what's left to be done to make Pantheon work without any Canonical-patched packages. Luckily the individual components of Pantheon run on just about anything as they are; just a few things are broken or not functioning without Canonical code.

The biggest headache is what to do about the Canonical-developed packages. I really like indicators; but if they aren't taken out of Canonical's hands soon they're going to end up unusable outside of Unity.

pgoetz wrote:

It's not clear why the elementary OS devs aren't seeing this.

Perhaps they are. There's talk of rebasing to Debian.

"hey, this is actually a private company making what they believe to be commercially advantageous decisions"

It's not going to surprise me when it starts shipping on locked-firmware devices with a private software channel; making money from free software other people made.

What's going to happen to Pantheon when Ubuntu starts making library changes to accommodate Mir and Mutter only runs on Wayland?

In a just universe, Mir would wither and die taking Unity with it. Hopefully we'll have an independent Pantheon before this happens.

Maybe we should use the Pantheon wiki page? An official fork of the Pantheon bzr repository, maybe switched to git or mercurial, which are more commonly used these days?

We need to get involved directly with the elementary OS devs and we should probably make some updates to the Wiki page.

I'd rather not fork Pantheon. I see porting pantheon to Arch (and Debian) as part of a larger objective: making Pantheon platform-independent. The fact that people are already using it in Arch, Debian, and even Gentoo proves it can be done. I also think it would be good for the elementary OS project to be less dependent on a particular base.

olantwin wrote:

Since they are already starting to package for debian, they hopefully are not opposed to an Arch port.

Opposition doesn't seem to be a problem and I don't think they're especially loyal to Ubuntu either. They probably got into it for the same reasons pgotez and I did; maybe they can get out of it for the same reasons we did as well. Their webpage has some wonderful statements about community contributions and open-source development but not one word about Ubuntu, not one.

I'd prefer git, but I'm fine with learning bzr as well.

bzr won't be hard to figure out if you already use other VCSs; for better or worse it's less intricate than git.

Are there any reasons for developing in bzr other than working with Ubuntu; were the elementary OS devs hoping to make an official Ubuntu port?

orschiro wrote:

Did someone already have contact with the elementary devs about creating an "official" Arch port?

It's too bad they don't have a forum. There is #elementary-dev on freenode.

Last edited by quequotion (2014-07-25 06:55:10)

Varg · 2014-07-25 08:09:25

quequotion wrote:

orschiro wrote:
Did someone already have contact with the elementary devs about creating an "official" Arch port?
It's too bad they don't have a forum. There is #elementary-dev on freenode.

The Elententary OS Google+ page seems the best bet to contact the devs. They are pretty active on that page.
The Pantheon shell ported to Arch with continuous updates for all the latest packages would be so, so sweet. To bad I don't have the skills to help out with that.

orschiro · 2014-07-25 08:25:45

@Varg

Great idea. I created a post here for everyone to join the discussion.

Shnatsel · 2014-07-25 10:57:32

orschiro wrote:

Great idea. I created a post here for everyone to join the discussion.

I got pinged from that post and here I am. Hello everyone!

I'm the guy who's packaging Pantheon for Debian. I was also responsible for all aspects of the "OS" in elementary OS during the Luna cycle (packaging, integration, ISO building, etc) and I'm still around for Freya.

quequotion wrote:

Luckily the individual components of Pantheon run on just about anything as they are; just a few things are broken or not functioning without Canonical code.

A number of packages optionally depend on libunity because it provides an API to talk to the dock that supersedes DockManager API. The API was originally developed for Docky, but then Docky lead dev was hired to work on Unity and the Launcher API ended up in libunity. It does depend on Canonical-ish libdee and libdbusmenu-gtk3, but those packages are already in Debian and I had no problem getting libunity in Debian either (sketchy copyright information aside). So these packages should not be a problem, and if they are, you can always switch dock integration off for now and go ahead. The only Ubuntu-specific thing we have is Wingpanel with its Ayatana indicators.

olantwin wrote:

Unfortunately I think all the tasks for converting Pantheon to run on Arch are very programming intensive.

Nope. I'm packaging it for Debian now and I didn't need any programming knowledge whatsoever, only packaging. I did poke upstream devs to fix something up once or twice, but that's it. So I can spend my programming time to implement fun things like http://www.youtube.com/watch?v=WLhTmnifAro instead

quequotion wrote:

Compromises have to be made: Canonical is upstream for some things, like indicators, and these things are only becoming more dependent on their patched packages and more integrated into their Unity DE.

Oh God, indicators! There are several problems with them. Even leaving the merits of the API aside, they have never been maintainable outside of Ubuntu because of ever-changing interfaces and now they're being redone again, this time in Qt and with a convergence-oriented design. For Jupiter and Luna using Canonical's indicators was not only the path of least resistance but also pretty much the only option we had. Now, with Ubuntu dropping Unity7-era indicators, we're forced to abandon ship.

Just to be clear, we're not talking about application indicators here. AppIndicators were obsoleted the moment Ubuntu grew a dock, in 6 months after their debut. We're talking system indicators here - things like volume control and shutdown button and network menu and all that stuff. Ubuntu's indicators have a lot of C code with a significant complexity; NetworkManager indicator for one is very complex, Sound indicator has to use some obscure backchannel to PulseAudio because (of course) it does not expose volume control via a sane API, Shutdown indicator deals with PolicyKit and that's security-critical code...

(Fun fact: Canonical has decent API for application indicators, but the API for writing system indicators is so terrible that at some point even Canonical just gave up and implemented a number of system indicators via AppIndicator API. And then they created a hack called "libido" to be able to insert more or less arbitrary widgets in Gtk.Menu to work around their own intentional limitation. *slow clapping ensues*)

So here's the situation: We need some kind of system indicators, we don't really care about the API at this point. We cannot maintain the Unity7 indicators on our own, we just don't have enough C experts (and it's just about the least fun thing to do in C, so even if we had the C experts they'd get bored and leave in a couple of months). We probably cannot use the Unity8 indicators either because they have a design vastly different from ours and besides, that'd mean getting into endless patching of indicators just to make them look sorta okay and mostly work yet again (yeah, we've been doing that all along, it was just terrible in Luna, less terrible in Freya now). We cannot afford to write the indicators from scratch and then maintain them because we simply do not have the resources to do that. And I have to admit I haven't looked in a while, but I'm not aware of any other options we could use. LXDE had some of those but now it's transitioning to Qt too, so no luck there. GNOME Shell indicators are mostly JavaScript, and we're not buying any of it (not to mention that decoupling them from GNOME Shell would take an enormous amount of patching). XFCE is still lagging on GTK3 transition... I'm not sure what's their situation wrt system indicators. I gotta do some proper digging on the topic after Luna release, but so far the situation looks bleak. Any suggestions regarding the indicators are welcome.

orschiro wrote:

Did someone already have contact with the elementary devs about creating an "official" Arch port? If they fully support and agree to a port, then the next step could indeed be setting up a Github repository.

I'm not sure what you mean by an official port here; if it's an elementary OS spin based on Arch, I reckon this would not be all that useful - shipping a pre-configured and already integrated OS image is not what Arch is all about, right? (I haven't used it much so please correct me if I'm wrong).
And as for making Pantheon available as a DE option in Arch, it would only be official if it makes its way into main Arch repos and that's out of elementary team's hands. I'd be glad to assist in packaging and get you in touch with relevant developers should you need any code changes, but this ultimately requires somebody who's familair with Arch and uses Arch with Pantheon on a regular basis to step up and maintain the packages in Arch repos.

olantwin wrote:

Since they are already starting to package for debian, they hopefully are not opposed to an Arch port.

Opposed? I'd welcome it! I'd really like to see it happen!
As I said, I'd be glad to assist in packaging and get you in touch with relevant developers should you need any code changes. My contact info can be found at https://launchpad.net/~shnatsel should you need any help.

quequotion wrote:

There's talk of rebasing to Debian.

This remains to be seen. It mostly depends on how much of a second-class citizen Wayland is going to be on Ubuntu. We're pretty obviously tied into Wayland because we use GNOME libs and Canonical doesn't care about officially supporting GTK on Mir, and I'm not even mentioning things like Mutter.

I have to note that at least during the 12.04 days, when I was most active in elementary, Ubuntu has been the most wonderful upstream, responsive and helpful. Mentioning a bug in IRC and saying "it's blocking us in elemenetary" always got it fixed in a couple of days even if it was open for a year prior to that. The ISO build system developer took his time and explained how to use it to me in great detail. Developer of Apport crash reporter made it distro-independent on my request and helped us deploy it, and we were the first ever non-Ubuntu distro to use it. We couldn't have wished for a better upstream.

I don't know what the situation is now, but I do know we finally got the ball rolling on pushing our GTK extensions back into GTK upstream and all around have a symbiosis with GTK devs now.

quequotion wrote:

were the elementary OS devs hoping to make an official Ubuntu port?

As a guy who's been involved in Xubuntu and Ubuntu Studio, I'm sure that would be completely pointless. Small teams are really struggling with Ubuntu's large-scale dev processes and frozen schedules.

quequotion wrote:

Are there any reasons for developing in bzr other than working with Ubuntu

Much lower entry barrier than in Git. But the primary reason is Launchpad; things like GitHub and the like are simply ineffective for elementary.

Speaking of dev platforms, we're currently looking for something like https://slack.com/ but open-source or at least self-hosted. IRC is ineffective and Slack's paid plans are prohibitively expensive. I'm seriously considering shaking the rust off my Erlang-fu and writing a custom group chat Any suggestions are welcome.

PS: I'm not going to check this thread very often so if you want to talk to me here, ping me on G+ or wherever. Thanks.

Alucryd · 2014-07-25 14:12:04

Shnatsel wrote:

A number of packages optionally depend on libunity because it provides an API to talk to the dock that supersedes DockManager API. The API was originally developed for Docky, but then Docky lead dev was hired to work on Unity and the Launcher API ended up in libunity. It does depend on Canonical-ish libdee and libdbusmenu-gtk3, but those packages are already in Debian and I had no problem getting libunity in Debian either (sketchy copyright information aside). So these packages should not be a problem, and if they are, you can always switch dock integration off for now and go ahead. The only Ubuntu-specific thing we have is Wingpanel with its Ayatana indicators.

The Pantheon packages are already Unity-free, I have disabled libunity support in each package that has it. The only things that depend on canonical code right now are indeed wingpanel, and the Ubuntu Online Accounts system. While wingpanel needs patched gtk3 which is out of the question, I have already packaged all parts necessary to run UOA (hope I didn't miss anything), now I just need to figure out why it doesn't work . Also, some software needs to be rebuilt (I'm thinking empathy for example) to add libaccounts support.

Shnatsel wrote:

olantwin wrote:
Unfortunately I think all the tasks for converting Pantheon to run on Arch are very programming intensive.
Nope. I'm packaging it for Debian now and I didn't need any programming knowledge whatsoever, only packaging. I did poke upstream devs to fix something up once or twice, but that's it. So I can spend my programming time to implement fun things like http://www.youtube.com/watch?v=WLhTmnifAro instead

No programming indeed, only shell

Shnatsel wrote:

Oh God, indicators!

Nice to see this reaction is universal

Shnatsel wrote:

orschiro wrote:
Did someone already have contact with the elementary devs about creating an "official" Arch port? If they fully support and agree to a port, then the next step could indeed be setting up a Github repository.
I'm not sure what you mean by an official port here; if it's an elementary OS spin based on Arch, I reckon this would not be all that useful - shipping a pre-configured and already integrated OS image is not what Arch is all about, right? (I haven't used it much so please correct me if I'm wrong).
And as for making Pantheon available as a DE option in Arch, it would only be official if it makes its way into main Arch repos and that's out of elementary team's hands. I'd be glad to assist in packaging and get you in touch with relevant developers should you need any code changes, but this ultimately requires somebody who's familair with Arch and uses Arch with Pantheon on a regular basis to step up and maintain the packages in Arch repos.

We don't need another spin-off (just look at the current Manjaro drama disaster), people just need to type "sudo pacman -S pantheon pantheon-extras". Regarding packages in the official repos, some parts are already in there, and there will be no problem pushing more of them. The only thing I need is for them to be stable releases that work as a whole. Next candidates are pantheon-files and scratch-text-editor, but the current releases do not work with the current release of granite. Also, gala still has no stable release, so it's not possible to include it right now.

Shnatsel wrote:

olantwin wrote:
Since they are already starting to package for debian, they hopefully are not opposed to an Arch port.
Opposed? I'd welcome it! I'd really like to see it happen!
As I said, I'd be glad to assist in packaging and get you in touch with relevant developers should you need any code changes. My contact info can be found at https://launchpad.net/~shnatsel should you need any help.

Thanks for the offer. Raphael Isemann (teemperor) has already helped me regarding the pantheon greeter and recently got me invited to the slack team so that I could contact devs directly. It's nice to know you are willing to help.

Now regarding the current status: packaging is mostly done, apart from minor adjustments and getting some parts to work, there is not much more to do. My nightly repo already provides all of the latest and I have had no problem on my Pantheon for Arch VM for a while (although it is now wingpanel-less). And with daily build reports I can fix packages ever so quickly.

Current TODO:
- Find a (temporary?) solution/replacement for wingpanel.
- Find out why Ubuntu Online Accounts do not work. AFAICT the service runs, but empathy (rebuilt with UOA support) does not seem to pick it up. Also geary might get UOA support in the near future (https://bugs.launchpad.net/ubuntu/+sour … ug/1299255) would be nice if it's ready by then. Installing the switchboard online accounts plugin from my repo should pull all UOA parts.
- Check current compatibility between the greeter and granite. Not every stable piece of software currently works with stable granite, the best course of action atm is to use nightly bzr packages, however, last time I checked the greeter did not support granite-bzr.

Shnatsel · 2014-07-25 15:33:21

In fact we don't use UOA, we are going to use a fork of the same thing written by Intel. Technically UOA didn't originate in Ubuntu, it all started in MeeGo and then Ubuntu forked it and then Intel took it back... long story.
And we're not 100% successful in making it work in elementary OS either. Contact tintou on Slack for more info.

Updated stable release of Pantheon Files is coming soonish. We just have to figure out building it with public instead of private libraries first.

Scratch doesn't seem to be far behind either: https://launchpad.net/scratch/+milestone/freya-beta1

As for the greeter, you'd better ask teemperor, I'm not up to speed on that one.

Alucryd wrote:

The Pantheon packages are already Unity-free, I have disabled libunity support in each package that has it.

Aww. You're missing out on dock integration then, but it's only really essential for Birdie, so count it a wishlist item. libunity doesn't actually need Unity, and the server-side Launcher API is provided by e.g. Plank.

By the way, are you shipping Plank with or without elementary patches? Plank upstream doesn't want it to be a ready-to-use dock and we obviously do, so we have to carry a number of patches.

olantwin · 2014-07-25 15:47:26

Shnatsel wrote:

In fact we don't use UOA, we are going to use a fork of the same thing written by Intel. Technically UOA didn't originate in Ubuntu, it all started in MeeGo and then Ubuntu forked it and then Intel took it back... long story.
And we're not 100% successful in making it work in elementary OS either.

Out of curiosity: Have you ever considered using gnome-online-accounts? If so, what led you to decide against it and for UOA?

Shnatsel · 2014-07-25 15:58:10

olantwin wrote:

Out of curiosity: Have you ever considered using gnome-online-accounts? If so, what led you to decide against it and for UOA?

GOA is not extensible by design. Provider names (e.g. "facebook") are hardcoded. We can't provide such an API to developers writing for elementary OS and keep a straight face. We also have better use for resources than maintaining hardcoded values. We also believe that making something deliberately not extensible hinders innovation, both in-house and third-party. This is the sole reason Switchboard exists, in fact - it's just an extensible clone of GNOME Control Center.

More background on the GNOME Online Accounts extensibility issue:
http://debarshiray.wordpress.com/2012/1 … way-it-is/
http://jewelfox.dreamwidth.org/2012/11/ … roken.html

olantwin · 2014-07-25 16:00:30

Shnatsel wrote:

olantwin wrote:
Out of curiosity: Have you ever considered using gnome-online-accounts? If so, what led you to decide against it and for UOA?
GOA is not extensible by design. Provider names (e.g. "facebook") are hardcoded. We can't provide such an API to developers writing for elementary OS and keep a straight face. We also have better use for resources than maintaining hardcoded values. We also believe that making something deliberately not extensible hinders innovation, both in-house and third-party. This is the sole reason Switchboard exists, in fact - it's just an extensible clone of GNOME Control Center.
More background on the GNOME Online Accounts extensibility issue:
http://debarshiray.wordpress.com/2012/1 … way-it-is/
http://jewelfox.dreamwidth.org/2012/11/ … roken.html

Thank you. That is a very good reason indeed.

Last edited by olantwin (2014-07-25 16:00:51)

quequotion · 2014-07-25 16:40:26

Shnatsel wrote:

The API was originally developed for Docky, but then Docky lead dev was hired to work on Unity and the Launcher API ended up in libunity.

I'd love to see this repackaged as "libdock". At the moment, this and dee (libdee) are the only dependencies not available in the Arch repository.

It does depend on Canonical-ish libdee and libdbusmenu-gtk3, but those packages are already in Debian and I had no problem getting libunity in Debian either (sketchy copyright information aside).

The only danger is the possibility that Canonical may decides to do something new and completely incompatible with these libraries in the future.

I didn't need any programming knowledge whatsoever, only packaging. I did poke upstream devs to fix something up once or twice, but that's it.

In fact, one can pretty well install pantheon on Arch from Alucryd's PKGBUILDS; we just need to polish a few things off and get them into the Arch (community? extra?) repository (if their dependencies can also be accepted into the repository).

Oh God, indicators!

I feel your pain.

(Fun fact: Canonical has decent API for application indicators, but the API for writing system indicators is so terrible that at some point even Canonical just gave up and implemented a number of system indicators via AppIndicator API. And then they created a hack called "libido" to be able to insert more or less arbitrary widgets in Gtk.Menu to work around their own intentional limitation. *slow clapping ensues*)

Why do they do this?

So here's the situation: We need some kind of system indicators, we don't really care about the API at this point. We cannot maintain the Unity7 indicators on our own, we just don't have enough C experts (and it's just about the least fun thing to do in C, so even if we had the C experts they'd get bored and leave in a couple of months).

We're going to have to fork them; we're going to have to fork the entire API. On the bright side, doing so would provide an opportunity to make platform-independent system indicators and solve this problem for all the other DEs at the same time. For now, I suggest we go back to the Unity 7 indicators, fork them, and remake them in Pantheon's image.

To-do:
Re-write the system indicator API to be easier to use.
Alternatives: Merge the system indicator API with the application indicator API; Create a new system indicator API from the application indicator API; Scrap the system-indicator API and make libido hacked application indicators instead.
Re-write the system indicators in an easier language, like Vala.
Replace ubuntu-specific functionality with standards-compliant functionality; particularly all the nonsense in indicator-session.

This ultimately requires somebody who's familair with Arch and uses Arch with Pantheon on a regular basis to step up and maintain the packages in Arch repos.

I nominate Alucryd!

It mostly depends on how much of a second-class citizen Wayland is going to be on Ubuntu. We're pretty obviously tied into Wayland because we use GNOME libs and Canonical doesn't care about officially supporting GTK on Mir, and I'm not even mentioning things like Mutter.

I'm still holding out hope that Mir will implode, but massively unpopular and broken software never stopped Canonical from going through with it's plans before.

I have to note that at least during the 12.04 days, when I was most active in elementary, Ubuntu has been the most wonderful upstream, responsive and helpful. Mentioning a bug in IRC and saying "it's blocking us in elemenetary" always got it fixed in a couple of days even if it was open for a year prior to that. The ISO build system developer took his time and explained how to use it to me in great detail. Developer of Apport crash reporter made it distro-independent on my request and helped us deploy it, and we were the first ever non-Ubuntu distro to use it. We couldn't have wished for a better upstream.

There was a time when I felt the same way about Canonical and the Ubuntu community. I wasn't developing software, but it seems like there was a time when people would actually help each other in Ubuntu. However, lately, good help is in short supply.

Shnatsel · 2014-07-25 18:32:09

Alucryd, there is indeed something wonky about the greeter, it blows up for me with an error about PopOver not being found if I nuke the pre-generated makefile in cmake/ and pull in newer CMake modules. Let's file a bug report or something.
UPD8: Probably won't apply to you, I'm getting errors since I've dropped in newer CMake modules and didn't update CMakeLists.txt. Currently investigating that at https://code.launchpad.net/~elementary- … rge/228366

quequotion, regarding the bugs you've linked:
https://bugs.launchpad.net/ubuntu/+sour … bug/390508 is the reason we've built a custom notification system in Freya. It addresses most if not all of the annoying limitations of notify-osd (like "one message at a time" BS) and uses all available metadata; for example, depending on the urgency it will use different animations so that they attract attention proportionally to the importance. Critical notifications also invade fullscreen windows, so "You have 5% battery remaining" will show even if you watch a fullscreen movie (well, it should, but I haven't actually tested that. File a bug if that's not the case!).

And missing features are just the tip of the iceberg that notify-osd is. What if I told you that once a while it leaks a huge amount of memory (up to ~150Mb per call, presumably in image handling), and to work that around it monitors its memory usage and kills itself every time it crosses a certain threshold? IT DOES. It literally suicides to work around memory leaks. This code has been in production for at least 3 years. It still is. And it probably will be like that for a while.
Prooflink: https://bazaar.launchpad.net/~notify-os … ack.c#L781

And JFYI https://bugs.launchpad.net/ubuntu/+sour … bug/592842 is not fixable by design without hideous security-threatening hacks, so don't expect anything to improve here at least until Unity8 (Mir might include a special backchannel to fix this, but I doubt that).

quequotion wrote:

The only danger is the possibility that Canonical may decides to do something new and completely incompatible with these libraries in the future.

That's what ABI revisions are for!
Also, we can always fork off the Launcher API at the first sign of trouble.

Last edited by Shnatsel (2014-07-25 19:29:48)

Alucryd · 2014-07-25 22:47:38

Shnatsel wrote:

In fact we don't use UOA, we are going to use a fork of the same thing written by Intel. Technically UOA didn't originate in Ubuntu, it all started in MeeGo and then Ubuntu forked it and then Intel took it back... long story.
And we're not 100% successful in making it work in elementary OS either. Contact tintou on Slack for more info.

Got it, thx for the pointer.

Shnatsel wrote:

Updated stable release of Pantheon Files is coming soonish. We just have to figure out building it with public instead of private libraries first.
Scratch doesn't seem to be far behind either: https://launchpad.net/scratch/+milestone/freya-beta1

Nice.

Shnatsel wrote:

Alucryd wrote:
The Pantheon packages are already Unity-free, I have disabled libunity support in each package that has it.
Aww. You're missing out on dock integration then, but it's only really essential for Birdie, so count it a wishlist item. libunity doesn't actually need Unity, and the server-side Launcher API is provided by e.g. Plank.

I had it enabled for a while without issues, if it's really necessary I can add it back. libunity doesn't need any crazy ubuntu patched dep so it's fine.

Shnatsel wrote:

By the way, are you shipping Plank with or without elementary patches? Plank upstream doesn't want it to be a ready-to-use dock and we obviously do, so we have to carry a number of patches.

I maintain vanilla plank in [community], that's the one I'm using atm. I will create a pantheon-dock package for this then.

I'll probably get back to working on all this some time next week.

Alucryd · 2014-07-25 22:55:23

I knew I had forgotten sth. There's also the issue of the GCC plugs in switchboard. The problem with this is that upstream gnome-control-center is now one big static binary, Ubuntu reverted the relevant commit to still have libgnome-control-center available. Doing the same to our gnome-control-center isn't possible, the best I can do is build a separate libgnome-control-center (that's what I'm doing atm) but even then I'm not sure jgc or heftig will be happy about it. If not, I think I'll just ship the lib in the gcc plug package. That said, switchboard currently crashes when I attempt to load any gcc plug and I still need to investigate why.

Shnatsel · 2014-07-26 07:31:56

Getting GNOME Control Center plugs into Switchboard is also a long painful story. We've fixed a crash and then another crash just recently. If you need any help, contact tintou or tom95, they're the guys most familiar with that stuff.

woomia · 2014-07-26 18:15:55

When I open Pantheon Terminal I get this:

bash: PROMPT_COMMAND: line 0: syntax error near unexpected token `;'
bash: PROMPT_COMMAND: line 0: `dbus-send --type=method_call --session --dest=net.launchpad.pantheon-terminal /net/launchpad/pantheon_terminal org.pantheon.terminal.ProcessFinished string:$PANTHEON_TERMINAL_ID string:"$(history 1 | cut -c 8-)"; ; printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"'

Note: it doesn't happen in the standard xterm and seems harmless but irritating.

Last edited by woomia (2014-07-27 14:16:58)

esquiso · 2014-07-27 14:49:30

Why is the switchboard-bzr package suddenly pulling so many dependencies?

resolving dependencies...
looking for inter-conflicts...

Packages (32):

Name                         Old Version  New Version   Net Change  Download Size

extra/cdparanoia                          10.2-5        0.19 MiB                 
extra/celt                                0.11.3-2      0.15 MiB                 
extra/cheese                              3.12.2-1      3.16 MiB                 
extra/chromaprint                         1.1-1         0.09 MiB                 
extra/clutter-gst                         2.0.12-1      0.42 MiB                 
extra/fftw                                3.3.4-1       5.50 MiB                 
extra/fluidsynth                          1.1.6-3       0.54 MiB         0.18 MiB
extra/gnome-video-effects                 0.4.1-1       0.17 MiB                 
extra/gst-plugins-bad                     1.2.4-1       6.49 MiB                 
extra/gst-plugins-base                    1.2.4-1       0.50 MiB                 
extra/gst-plugins-base-libs               1.2.4-1       10.72 MiB                
extra/gst-plugins-good                    1.2.4-1       7.79 MiB                 
extra/gstreamer                           1.2.4-1       13.14 MiB                
extra/libavc1394                          0.5.4-2       0.11 MiB                 
extra/libdv                               1.0.0-6       0.23 MiB                 
extra/libdvdnav                           4.2.1-1       0.21 MiB                 
extra/libdvdread                          4.9.9-1       0.24 MiB                 
extra/libgme                              0.6.0-3       0.31 MiB         0.12 MiB
extra/libiec61883                         1.2.0-4       0.15 MiB                 
extra/libmms                              0.6.4-1       0.08 MiB                 
extra/libofa                              0.9.3-5       0.19 MiB                 
extra/libraw1394                          2.1.0-2       0.19 MiB                 
extra/libshout                            1:2.3.1-2     0.11 MiB                 
extra/libsrtp                             15.1c9bd90-3  0.29 MiB                 
extra/libvisual                           0.4.0-5       0.47 MiB         0.12 MiB
extra/mjpegtools                          2.1.0-1       2.20 MiB                 
extra/neon                                0.30.0-1      0.75 MiB                 
extra/soundtouch                          1.8.0-1       0.26 MiB                 
extra/spandsp                             0.0.6pre21-2  1.56 MiB                 
extra/taglib                              1.9.1-1       1.57 MiB                 
extra/wildmidi                            0.3.6-1       0.14 MiB                 
pantheon/switchboard-bzr     r458-1       r462-1        0.00 MiB         0.04 MiB

Total Download Size:    0.46 MiB
Total Installed Size:   58.06 MiB
Net Upgrade Size:       57.91 MiB

dilyn · 2014-07-28 06:37:28

woomia wrote:

When I open Pantheon Terminal I get this:

bash: PROMPT_COMMAND: line 0: syntax error near unexpected token `;'
bash: PROMPT_COMMAND: line 0: `dbus-send --type=method_call --session --dest=net.launchpad.pantheon-terminal /net/launchpad/pantheon_terminal org.pantheon.terminal.ProcessFinished string:$PANTHEON_TERMINAL_ID string:"$(history 1 | cut -c 8-)"; ; printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"'

Note: it doesn't happen in the standard xterm and seems harmless but irritating.

I'm having the same issue. I can't figure out what is doing it.

Shnatsel · 2014-07-28 09:45:38

woomia wrote:

When I open Pantheon Terminal I get this:

bash: PROMPT_COMMAND: line 0: syntax error near unexpected token `;'
bash: PROMPT_COMMAND: line 0: `dbus-send --type=method_call --session --dest=net.launchpad.pantheon-terminal /net/launchpad/pantheon_terminal org.pantheon.terminal.ProcessFinished string:$PANTHEON_TERMINAL_ID string:"$(history 1 | cut -c 8-)"; ; printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"'

Note: it doesn't happen in the standard xterm and seems harmless but irritating.

Oh that's interesting. This is caused by pantheon-terminal injecting a custom callback in $PROMPT_COMMAND - this is how process completion notifications work. The command is terminated with ";" to allow easy appending of other stuff to it. However, whatever adds the following command starting with printf assumes that whatever comes before it doesn't end with a ";", and adds another one, about which BASH complains.

I'm not sure how to approach this. It seems that the printf stuff is added after the terminal callback is injected, so whatever adds it should either be smarter and not add a second ";" or be dumber and never add the ";".

Last edited by Shnatsel (2014-07-28 09:46:08)

quequotion · 2014-07-28 15:06:16

woomia wrote:

printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"'

This string, printf and all, is stored in the variable PROMPT_COMMAND in Arch; and maybe not in other distros like Debian or Ubuntu.

Would the injection work if appended to the end of $PROMPT_COMMAND instead?

Arch Linux

#326 2014-07-15 15:48:29

Re: Pantheon Shell on Archlinux

#327 2014-07-24 06:57:02

Re: Pantheon Shell on Archlinux

#328 2014-07-24 09:19:38

Re: Pantheon Shell on Archlinux

#329 2014-07-24 19:51:52

Re: Pantheon Shell on Archlinux

#330 2014-07-24 23:04:51

Re: Pantheon Shell on Archlinux

#331 2014-07-25 04:35:31

Re: Pantheon Shell on Archlinux

#332 2014-07-25 06:53:33

Re: Pantheon Shell on Archlinux

#333 2014-07-25 08:09:25

Re: Pantheon Shell on Archlinux

#334 2014-07-25 08:25:45

Re: Pantheon Shell on Archlinux

#335 2014-07-25 10:57:32

Re: Pantheon Shell on Archlinux

#336 2014-07-25 14:12:04

Re: Pantheon Shell on Archlinux

#337 2014-07-25 15:33:21

Re: Pantheon Shell on Archlinux

#338 2014-07-25 15:47:26

Re: Pantheon Shell on Archlinux

#339 2014-07-25 15:58:10

Re: Pantheon Shell on Archlinux

#340 2014-07-25 16:00:30

Re: Pantheon Shell on Archlinux

#341 2014-07-25 16:40:26

Re: Pantheon Shell on Archlinux

#342 2014-07-25 18:32:09

Re: Pantheon Shell on Archlinux

#343 2014-07-25 22:47:38

Re: Pantheon Shell on Archlinux

#344 2014-07-25 22:55:23

Re: Pantheon Shell on Archlinux

#345 2014-07-26 07:31:56

Re: Pantheon Shell on Archlinux

#346 2014-07-26 18:15:55

Re: Pantheon Shell on Archlinux

#347 2014-07-27 14:49:30

Re: Pantheon Shell on Archlinux

#348 2014-07-28 06:37:28

Re: Pantheon Shell on Archlinux

#349 2014-07-28 09:45:38

Re: Pantheon Shell on Archlinux

#350 2014-07-28 15:06:16

Re: Pantheon Shell on Archlinux

Board footer