Am Thu, 01 Mar 2012 21:46:41 +0200 schrieb Ionut Biru :

Most GTK2 GTK3 ports are hard to be supported in AUR since most of the time it depends on what packages a user has installed on his system and may be picked different because almost 99% of our users do not compile in clean chroots.

Why is it hard to support a pure GTK3 port and a pure GTK2 port of a package in AUR? Just create one package indicator-messages with a ./configure and one package indicator-messages-gtk2 with a ./configure --with-gtk=2. That's so simple. There's really no reason to having indicator-messages (the GTK3 port) as a dependency for indicator-messages-gtk2 (the GTK2 port). In fact a user expects to just having the GTK2 port being installed if he installs the -gtk2 packge. In this case he explained that both ports share some files, and that there are people who want to have installed both ports at the same time. This is either no problem. There are two ways of doing this: Create one package indicator-messages-base which contains the shared files, one package indicator-messages-gtk2 and one package indicator-messages-gtk3. Or: Create one package indicator-messages which contains both the GTK2 and the GTK 3 port if there are really people who want to have both at the same time, one package indicator-messages-gtk2 and one package indicator-messages-gtk3. Pretty easy and gives very clean, officially supported PKGBUILDs which can easily be installed with makepkg as well as the AUR wrappers. And what does this have to do with a compilation in a clean chroot? Nothing. It's just bad packaging.

Having support for that is hard because AUR needs to understand split packages and return them using json interface

I don't recall AUR having support for those and that's why he needs to add workarounds.

No, he doesn't need to add such workarounds. As long as AUR doesn't support split packages PKGBUILDs just can be written as single packges. Adding such dirty workarounds to AUR packages is even bad packaging. Where's the problem to just create either one single PKGBUILD which builds and installs every feature (subpackage) or to create several single PKGBUILDs for each subpackage? I don't see any problems. And this was clean and good packaging which is absolutely and officially supported by AUR and the AUR wrappers. And such packages can flawlessly be installed. His packages with those dirty workarounds just can't be installed. It's definitely not possible to install indicator-messages with yaourt. In fact I would recommend to patch AUR, so that it detects and declines PKGBUILDs with such workarounds, if AUR won't be patched to support split packages. Heiko

Am Thu, 1 Mar 2012 16:27:45 -0500 schrieb Dave Reisner :

Feel free to provide such PKGBUILDs and actually prove that this can be done rather than soapboxing about something that he isn't doing. It's just that simple.

I guess you are kidding, aren't you? 1. I'm not soapboxing. 2. I'm not interested in maintaining these packages. I just wanted to quickly try them which is not possible, since they can't be installed with yaourt. Try it and you will see. 3. Look at my PKGBUILDs in AUR, particularly linux-fbcondecor (https://aur.archlinux.org/packages.php?ID=50924). With this package I have changed the linux split package from ABS into a single package which can easily be installed by yaourt. And, yes, this was extremely easy to do. And then look at his packages I mentioned, and tell me what's the problem with writing them as clean single packages. I guess, I don't need to explain to you how to read and correctly write PKGBUILDs. 4. AUR is meant for providing PKGBUILDs for other users, so that they don't need to do the same work again (writing the PKGBUILDs). Since e.g. indicator-messages can't be installed by other users - at least not with yaourt, like I said, try it - I indeed had to rewrite this PKGBUILD and all its dependency hell, which György has also written as split packages, to be able to install this package. And that's not what AUR is meant for. If he wants to maintain packages then he should do it in a way that they apply to the official policies. And split packages are officially NOT supported by AUR, not even with this dirty workaround, which is fact, well known and often discussed, so I don't have to prove this. So his packages don't apply to the official policies. And since when are two different depends arrays necessary or even make sense in one PKGBUILD? Not to mention that he told me that he hasn't time to maintain those PKGBUILDs if they were written cleanly. He told me that he had to orphan those packages otherwise. So how shall he have time for being a TU? And if fixing a package means orphaning it for him what shall I expect from him if he will be a TU? Will he really fix PKGBUILDs or just orphan and/or move them to AUR if they contain a bug? Keep in mind, TU means Trusted User, a user whom every other Arch Linux user can and has to trust. This implies that one needs to be sure that the TU is able to write qualitative good PKGBUILDs, because a Linux distro is expected to provide stable, and well packaged packages. What will he do on AUR or [community] if he has a lot more rights? I know, just some questions. Probably I do him wrong with some of these questions. But the bad packaging quality is fact and doesn't need to be proven. A closer look at the mentioned packages and a try to install them with an AUR wrapper is evidence enough. Heiko

Am Fri, 2 Mar 2012 09:51:41 +1100 schrieb Gaetan Bisson :

[2012-03-01 23:35:16 +0100] Heiko Baums:

...

I guess you are kidding, aren't you?

Nobody cares what you guess.

Just quit posing for an expert on everything already.

Are you sure that your attitude is the right one? I just pointed out that and explained why his packages are in a bad quality in a way that they can't be installed. And just gave my concerns about making him a trusted user. And, yes, I contacted him before in the AUR comments for those packages and already explained it to him. If you don't care about that then this is a real pity. And that comes from a dev who should know about packaging standards, policies and packaging quality. Just shaking my head about such an arrogance, ignorance and such an attitude. Heiko

Am Fri, 02 Mar 2012 00:27:39 +0100 schrieb Balló György :

I understand Heiko's opinion and now I replaced these hackish split packages by individual packages even if it's requires more maintenance time on updates. So now users should able to install all of my packages with AUR helpers, however I don't use these tools at all. I hope that AUR once will have better support for split packages.

Thanks, looks a lot better now. But there's still an issue. Your makedepends should all be depends since they are runtime, not only buildtime dependencies. And libindicate doesn't build, but I'll file a comment to AUR for this. On the first glance I'm not sure if this is a downstream or an upstream issue. Still remains the issue with indicator-messages-gtk2 having indicator-messages as a dependency. Here you should comply with the naming conventions. Build two or three different packages like I explained. -gtk2 implies that this is only the GTK2 port. Heiko

Am Fri, 02 Mar 2012 22:01:59 +1000 schrieb Allan McRae :

I see what was done there... makedepends in split packages probably need to become depends when built as individual packages.

@György: Let that be a lesson in being careful when making reactionary changes to packages. Don't worry... it is a surprisingly common occurrence when people first become a TU and start getting bug reports. There are always annoying and persistent users that think they are right,

If I'm so annoying and I'm so wrong then explain why his packages are so good and I'm so wrong, but this time try it with facts. Explain to me e.g. - I know I already asked that Stéphane - why it is such a good packaging quality to have two totally different depends arrays in one PKGBUILD of which one is also prefixed with a "true &&". Where in the Arch Packaging Standards is this written down? In which PKGBUILD proto can this be found? Since when it is a good packaging quality to upload packages which can't be installed? Just explain it factually to me. And don't tell me anything about "not officially supported". Neither the helpers nor the split packages are "officially supported". This is not an argument in this case.

so you are better of not making reactionary changes to packages. It is important to learn when a change does not need implemented, and this change was probably not needed when no TU had posted about having issues with the split packages.

This change was neither reactionary nor unneeded, just because it was not possible to install this package. So this change was needed. So don't mix up the facts. In the repos like [community] split packages are supported and are no problem. And in the repos there's no need for such dirty workarounds. In AUR it is totally different. And that is just a fact, even if you don't want to hear that. Heiko

On 02/03/12 23:40, Allan McRae wrote:

On 02/03/12 23:16, Heiko Baums wrote:

...

Am Fri, 02 Mar 2012 22:01:59 +1000 schrieb Allan McRae :

...

I see what was done there... makedepends in split packages probably need to become depends when built as individual packages.

@György: Let that be a lesson in being careful when making reactionary changes to packages. Don't worry... it is a surprisingly common occurrence when people first become a TU and start getting bug reports. There are always annoying and persistent users that think they are right,

If I'm so annoying and I'm so wrong then explain why his packages are so good and I'm so wrong, but this time try it with facts.

Fact. I never said you were annoying or wrong in that sentence. Someone is a bit sensitive... probably because he is annoying and wrong.

...

Explain to me e.g. - I know I already asked that Stéphane - why it is such a good packaging quality to have two totally different depends arrays in one PKGBUILD of which one is also prefixed with a "true &&".

That fixed the issues you were complaining about with AUR helpers unable to find dependencies. So hang on... this was a complete solution to having a split package in the AUR while still being able to use an AUR helper. So what was your problem again? Apart from ignorance...

I'll put my hand up and say I am partially wrong here. This broke AUR helpers that blindly source the PKGBUILD in order to get the dependency list. I.e. broken AUR helpers became further broken... The AUR helper I use worked because it very sensibly does not do that and ends up with the same (working) dependency list as was displayed on the AUR. In conclusion... a good hack that did not work in shitty AUR helpers.

...

Where in the Arch Packaging Standards is this written down? In which PKGBUILD proto can this be found.

Where is it written that you can't do that? PKGBUILDs are bash. Any valid bash is a valid PKGBUILD. Show me an PKGBUILD proto that shows specifying different dependencies for i686 and x86_64? Given there is none, should all packages doing this be removed? Note that also screws AUR helpers.

...

Since when it is a good packaging quality to upload packages which can't be installed?

They can be installed. Or do you mean can not be installed by an AUR helper? In which case you are still wrong due to the extra dependency line.

...

Just explain it factually to me. And don't tell me anything about "not officially supported". Neither the helpers nor the split packages are "officially supported". This is not an argument in this case.

It is a valid PKGBUILD that provided split packages with a modified dependency line to fix AUR helper issues.

...

...

so you are better of not making reactionary changes to packages. It is important to learn when a change does not need implemented, and this change was probably not needed when no TU had posted about having issues with the split packages.

This change was neither reactionary nor unneeded, just because it was not possible to install this package. So this change was needed. So don't mix up the facts.

Absolute shit... the package installed just fine.

...

In the repos like [community] split packages are supported and are no problem. And in the repos there's no need for such dirty workarounds. In AUR it is totally different. And that is just a fact, even if you don't want to hear that.

I agree that in the AUR it is totally different to the repos. You have to use workarounds in the AUR. So everything said in that paragraph is true.

Allan

Xyne wrote:

Allan McRae wrote:

...

...

Since when it is a good packaging quality to upload packages which can't be installed?

They can be installed. Or do you mean can not be installed by an AUR helper? In which case you are still wrong due to the extra dependency line.

I think this point should be stressed. Yaourt and other AUR helpers do not determine the validity of a PKGBUILD. If you can download the tarball from the AUR and build the package with makepkg, then the PKGBUILD is *valid* as far as the AUR is concerned.

Having said that, I disagree that the criteria for a *good* PKGBUILD is only that it build. PKGBUILDs should try to conform to certain patterns and not exploit the fact that they are written in Bash (unless absolutely necessary, and even then only reluctantly). All metapackaging tools would have been much easier to write if PKGBUILDs were perfectly parsable without arbitrary code execution. The choice of Bash was myopic and lazy in my opinion, and something that should be reversed as far as possible, not glorified.

Hmmm, I should have finished reading all of the threads before replying. This would have been more appropriate elsewhere. Sorry.

Am Fri, 02 Mar 2012 23:40:55 +1000 schrieb Allan McRae :

Where is it written that you can't do that? PKGBUILDs are bash. Any valid bash is a valid PKGBUILD.

So, what if I would build a package which contains an .install file with an `rm -Rf /` in its post_install() function and upload it to AUR? That's a totally valid package, totally valid bash, which can easily be uploaded to AUR and flawlessly installed with makepkg and every AUR helper. Is it a qualitative good package? So, it's obvious that a valid bash is not the only quality criterion. Heiko

[2012-03-02 00:13:33 +0100] Heiko Baums:

Are you sure that your attitude is the right one?

Yes.

And that comes from a dev who should know about packaging standards, policies and packaging quality.

Such as quoting variables that may contain whitespace? -- Gaetan

[2012-03-02 01:44:02 +0100] Heiko Baums:

Not me.

Like I said, nobody cares.

But you know what you want to say?

If you have problems reading between the lines, try growing up. -- Gaetan

On 03/02/2012 08:17 AM, Heiko Baums wrote:

Am Fri, 2 Mar 2012 11:59:56 +1100 schrieb Gaetan Bisson :

...

Like I said, nobody cares.

Oh, you are nobody? Interesting.

...

If you have problems reading between the lines, try growing up.

Between the lines are spaces otherwise there would be other lines. I'd say, the one who needs to grow up is you, so that you can get rid of your childish and bad attitude.

Heiko

Seriously Heiko, you got some issues. Maybe some kind of disorder like Asperger[1]. You should look for a doctor if you can't sort this out by yourself. No joke, seek some help and stop bullying Arch devs/TUs. [1] https://en.wikipedia.org/wiki/Asperger_syndrome

Am Fri, 02 Mar 2012 07:11:21 -0500 schrieb Stéphane Gaudreault :

STOP.

Heiko, you had the chance to express you opinion about this application (and you did it in a totally inappropiate way).

I didn't do it in a inappropriate way. I did it in a factual way and explained why I am concerned and what was going wrong. I even said that I probably do him wrong with some of my questions. Nevertheless it's fact that this package couldn't be built. You can't argue it away. It was some other people who thought to need to offend me in an inappropriate way. So they get an adequate answer.

REPEAT: Please stop such nonconstructive messages.

Sorry, but my concerns aren't nonconstructive. But as the question, so the answer. Stop offending me, discuss in a factual way with me and you will get factual answers from me. If I'm so wrong with my concerns then explain it to me. I only got answers like "grow up", "AUR helpers are not officially supported" even if split packages are not supported, neither officially nor unofficially, by AUR, "Wow, I never seen somebody who maintains so many packages" etc. Quantity is not the same as quality, btw. Give factual reasons why his packages are so good and I'm so wrong, and everything is good. Otherwise think if he is really that good and trustworthy resp. that his knowledge is already good enough. E.g. explain to me why a package needs to have two completely different depends arrays one also with a "true &&" before. For me this looks like bad packaging, sorry. Btw., I didn't want to say that he personally is not trustworthy. But I'm not sure if he has sufficient knowledge, yet. Heiko

Am Fri, 02 Mar 2012 10:22:46 -0300 schrieb Angel Velásquez :

Heiko,

I've always had several discussions with you, now Gaetan, and many people seems to have disagree with your opinion.

If they disagree with my opinion, they can happily explain why. I explained my concerns. But I only got answers like "grow up", "not officially supported", etc., not to mention the offences, particularly those of Gaetan. I don't say that I'm always right. And having concerns does not mean that a person about whom I have concerns is really that bad. But it means that one should have a closer look at him before he is fully trusted. But what I have read in the answers looked rather like an unreflecting hype. And I also know that there are people who every now and then do agree with me. Just the people who disagree are usually the loudest. And once a TU even told me personally face to face that my comments are usually worth reading. I don't remember it literally. I also discovered several times, that I was offended here on the mailing lists by a lot of people. But I still gave my arguments. And lo and behold after a while the discussion got factual and it turned out in the end that I wasn't so wrong and that I wasn't the only one with this opinion. So you indeed should sometimes think about my comments. I really don't write so many times, at least I don't give so many times my concerns. But if I give them, then there's usually a reason for that. Of course, I can be wrong. But then explain it and don't tell me anything about I should grow up and it was inappropriately or the like. That's the point.

A personal advice is when so much people are saying that you're wrong at least try to think about it and try to put on the otherside of the line.

Why? I mean, of course, I think about it, but only if I get some reasonable arguments. On the other hand the fact that so many people are saying that I'm wrong doesn't necessarily mean that I'm this wrong. That can mean that those people are just the loudest and that those people probably haven't thought about my arguments or even haven't read them completely. Like I said before, I'm certainly not always right, but sometimes.

Gyorgy have good skills, and you personally are nothing to say that he doesn't have it,

Because I tried to install one of his packages, looked at those PKGBUILDs, found several issues, and written comments about those problems in the AUR. This was, btw., shortly before he has written his TU application. So I didn't check his AUR packages because of his TU application. And from those PKGBUILDs which indeed looked pretty weird I had my concerns that he is probably not the right one for being a TU. That was not meant personally, that was just because of what I saw.

are you a TU? Dev? were you a Fellow, I don't remember on those sides, so please, stop complaining,

Where am I complaining? I gave my concerns about someone who has written a TU application. And I said that either split package support should be added to AUR or that split packages shouldn't be uploaded to AUR. How is that complaining? And, no, I'm neither a TU or a dev, yet. Does this mean that I mustn't say my opinion? I don't think so. And that doesn't mean that I don't have any knowledge.

start contributing,

I already do this. 21 packages in AUR, a not too short part of the code in /etc/rc.sysinit, a few lines - only a very few, I admit that - of code in the vanilla kernel. Is this not contributing?

if you can't do this, then you will be remembered always like the noising user who like to break our balls.

No, only people who either don't read my arguments completely, have prejudices against me or just dislike me for whatever reason will remember me as a noising user. Other people probably know that I'm not just noising. Like I said in another e-mail: As the question, so the answer. Heiko

On Thursday 01 Mar 2012 23:35:16 Heiko Baums wrote:

4. AUR is meant for providing PKGBUILDs for other users, so that they don't need to do the same work again (writing the PKGBUILDs). Since e.g. indicator-messages can't be installed by other users - at least not with yaourt

Sounds like you should file a bug against yaourt.

And split packages are officially NOT supported by AUR, not even with this dirty workaround, which is fact, well known and often discussed, so I don't have to prove this. So his packages don't apply to the official policies.

I didn't think that anything about the AUR was officially supported. Pete.

On 02/03/12 09:37, Heiko Baums wrote:

I just see a PKGBUILD which doesn't apply to the official policies.

You keep saying "official policies"... Where is this official policy document that says do not use the split PKGBUILD hack to upload packages to the AUR? Yes, the AUR does not support split packages. But there is nothing actually wrong about using "true && pkgname=()" to provide one. It is still a perfectly valid PKGBUILD. Not being supported by AUR helpers is never a benchmark of a valid PKGBUILD... Allan

On 02/03/12 08:35, Heiko Baums wrote:

If he wants to maintain packages then he should do it in a way that they apply to the official policies. And split packages are officially NOT supported by AUR, not even with this dirty workaround, which is fact, well known and often discussed, so I don't have to prove this. So his packages don't apply to the official policies.

You do realize who first came up with the workaround for adding split packages to the AUR... Because from memory it was figured out in the TU IRC channel. Allan

On Fri 02 Mar 2012 00:49 +0100, Heiko Baums wrote:

Am Fri, 02 Mar 2012 09:21:33 +1000 schrieb Allan McRae :

...

You do realize who first came up with the workaround for adding split packages to the AUR... Because from memory it was figured out in the TU IRC channel.

I don't know, because I'm not in the IRC channels. But if I recall correctly this workaround was also discussed in the forums and/or the mailing lists. This was at a time when it was still discussed if AUR shall support split packages or not.

The package splittest which was meant to test this workaround and to give a sample PKGBUILD was uploaded to AUR by Harvie, a normal user. And if I recall correctly it was him who first came up with it. But I can be wrong.

The problem is if you add a subpackage of a split package into a depends array as György did it just can't be installed, because AUR don't know anything about those subpackages, because it doesn't support split packages. And thus the AUR wrappers can't find them. So it's not possible to install those packages.

First of all I'll deplore you for hijacking György's TU Application thread to rant about your own qualms. You should be ashamed. You should apologise. You are wrong. Secondly. If a PKGBUILD can be built with makepkg then it IS a valid PKGBUILD. No matter what you say. If an AUR helper cannot process it, then there is a problem with the AUR helper, not the AUR and not the PKGBUILD. Third. The AUR is not meant to help you build source packages. It hosts them, and parses the tarballs only for convenience. You are supposed to install it by your own means. If your means are buggy, that's your problem. Finally, yes, there are problems with Arch source packages but you're missing the solution by lightyears. These things have been discussed on the list, the forums, and the bugtracker. You would be keen to do a little research and perhaps propose solutions (patches?) rather than wasting precious oxygen. Cheers.

On Sat 03 Mar 2012 01:15 +0100, Heiko Baums wrote:

Am Fri, 2 Mar 2012 17:16:16 -0500 schrieb Loui Chang :

...

First of all I'll deplore you for hijacking György's TU Application thread to rant about your own qualms. You should be ashamed. You should apologise. You are wrong.

I'm not wrong, I didn't hijack anything, and I didn't rant. I gave my concerns about György's TU application and explained them. Afterwards I just answered some not so nice reactions and kept giving my arguments. So nothing to be ashamed, nothing to apologise. And, no, I'm not wrong. Just because you say so?

Yes. Because I say so. Because everyone else says so. Because you are one of those imbeciles that don't stop to listen and simply talk over everyone so that you can only hear yourself shouting.

Like I already said, give some factual and reasonable arguments. You, too, didn't give even one.

...

Secondly. If a PKGBUILD can be built with makepkg then it IS a valid PKGBUILD. No matter what you say. If an AUR helper cannot process it, then there is a problem with the AUR helper, not the AUR and not the PKGBUILD.

Also wrong. If a PKGBUILD has no syntax errors does not mean that it is valid resp. good. See my example of the package with the `rm -Rf /` in its post_install(). This package is totally valid, because it's totally valid bash without any syntax errors. This package can perfectly uploaded to AUR, is fully supported by AUR and every AUR helper, and can flawlessly be installed. Is it a good package, just because it is valid and has no syntax errors? Just think about that and think about the meaning of quality, quality assurance (QA) and good packaging.

Obviously you don't know the meaning of the word 'valid'. For instance: I could write a program in C with gotos. It could be perfectly valid, since goto is a valid instruction, but it might not be pretty, or good practice, or recommended. If I put a 'rm -Rf /' command in a script I damned well meant to put it there. It's a valid command. The script does not magically become invalid because you don't like what it's doing. If it runs, it's valid. (permissions errors aside)

The AUR helpers - all of them - support everything what AUR supports. AUR does NOT support split packages. Otherwise such a hackish workaround wouldn't be needed. So there's no problem with the AUR helpers. Would this be a problem with an AUR helper I would have filed a bug report for this.

...

Third. The AUR is not meant to help you build source packages. It hosts them, and parses the tarballs only for convenience. You are supposed to install it by your own means. If your means are buggy, that's your problem.

Wrong again. AUR is meant to provide PKGBUILDs so that other people can use and install them without rewriting them by themselves. They don't parse them only for my convenience, they parse the PKGBUILDs to assure that the PKGBUILDs are valid and most likely working.

Lemme see... Do you have any experience writing or otherwise hacking on an AUR helper, or for that matter the AUR itself? Otherwise how on earth are you able to declare the intents of its developers? Anyways, no the AUR was not meant to do your work for you - at least while it was on my watch.

...

Finally, yes, there are problems with Arch source packages but you're missing the solution by lightyears. These things have been discussed on the list, the forums, and the bugtracker. You would be keen to do a little research and perhaps propose solutions (patches?) rather than wasting precious oxygen.

I know these discussions, and I know the results of these discussions. You seem to have forgotten them. And, yes, the result of the discussion about implementing support for split packages into AUR, which was requested by a lot of people, btw., was that it does not going to be supported, because nobody wanted to write the patches. Maybe you have missed this discussion.

The issue has been hinted at by Xyne in the previous thread. Your problem is that your skull is too thick for that notion to seep deep enough to reach that pistachio nut you call a brain. Thanks for playing.

Hi, thanks for the question.

I looked at your AUR packages and saw that you are maintaining the unity desktop. I never used this desktop environment, but as a curiosity is it something you want to eventually bring into [community] ?

I worked a lot on making Unity and indicators usable on Arch Linux, but I don't want to add any of these packages[1] into [community], because Ubuntu heavily patched gtk2, gtk3[2], metacity and compiz, and it's impossible to build and/or use some packages with the upstream, unmodified packages. They patched a lot of other packages also for better integration into the panel and the launcher. So if GNOME developers accept some must have patches, then I could imagine to add these packages, but until it does not happen, it's better to keep them in a separated repo. (However I'm not sure that Ubuntu sent all required patches to upstream yet.) [1] Nearly all packages in ubuntu-unity and apps-unity directories on https://github.com/City-busz/Arch-Linux-Repository [2] E.g.: https://bugzilla.gnome.org/show_bug.cgi?id=658563 -- György Balló

On Sat, Mar 3, 2012 at 3:15 PM, Rashif Ray Rahman wrote:

Is there a separate repo? Do you intend to start one otherwise? I would really like to see unity accessible for Arch users.

https://wiki.archlinux.org/index.php/Unity ?

On 4 March 2012 00:12, Ionut Biru wrote:

Unity is only a Canonical project, not a project that can be used by anyone.

It's just about accessibility, so as to not deprive anyone and allow no-one to say "there is no foo in Arch" :D But I guess if it's that much PITA then it should be forgotten about. -- GPG/PGP ID: C0711BF1

Hi György, I think you would be an awesome addition to the TU team. Your Unity packages are very good (and saved me a lot of work from repackaging everything :D). Since you mentioned the patched Xorg server and compiz, I'd just like to point out that the patched Xorg patches are no longer needed after Xorg 1.12.0 is released. Unity uses utouch, which uses Xinput 2.2 that Canonical backported to Xorg 1.11.4. The next version of Xorg will have it built in. I agree that my repo is pretty risky; one little error in the packaging, and then nothing works (especially with compiz) :). Good luck! Xiao-long Chen

Date: Sat, 3 Mar 2012 17:13:11 +0100 From: ballogyor@gmail.com To: aur-general@archlinux.org Subject: Re: [aur-general] TU Application - György Balló

...

Is there a separate repo? Do you intend to start one otherwise? I would really like to see unity accessible for Arch users.

Unity 2D is available in my [ayatana] repo[1] along with indicators. To provide x86_64 packages, I'll need a build server.

Unity is a more difficult task, because it depends on a forked compiz 0.9, and I unable get it working with the upstream xorg-server. Chenxiaolong[2] works also on making Unity available for Arch Linux. His packages are mostly based on mine, but he maintain much more patched packages (including xorg-server, glib, even if not all patches are really needed), which makes his repo more risky.

[1] http://ayatana.info/ [2] https://github.com/chenxiaolong/Unity-for-Arch

-- György Balló