PacUI removed from AUR

It is not so nice that they didn’t reply. I still hope @eschwartz finds the time to reply, because the package was quite popular with AUR users. It couldn’t have been all Manjaro users, because Manjaro users would have got the package from Manjaro repos. The package pacli is still there in AUR.

@tix https://wiki.manjaro.org/index.php?title=Forum_Rules#Respect_Other_Distributions_and_Operating_Systems

1 Like

@eugen-b
I think you need to clarify your point to have a reasonable discussion here.
I’m Arch user, so your pointer to the forum rules bashing other distros is obviously not valid. As to an unproductive slander or not respecting devs, I don’t see you point here either. I actually think the pacui is very useful package and do support and respect @excalibur1234 efforts. Pacli is relatively outdated package (comparing to actively maintained pacui), last changed from 09/2017, it’s not exactly the replacement if you tried to hint that. Arch and other Arch based distros have no built-in access to Manjaro repos, so pacui release would not be readily searchable nor available for them (in a consistent way as other packages). Likewise Manaro users now have no access to pacui-git AUR version that is obviously a bad thing for testing new features or bugs for the package thus makes the dev and testers/early adopters work more difficult. I obviously don’t have to remind you that core strength of Manjaro is ease of use, so suggesting manual installation on regular basis / cases may sound… well, not particularly sound :wink:

1 Like

Pacui is in Manjaro repos, yes. But not pacui-git. That’s why I suggested MUR. However, if it’s okay for you to release straight to Manjaro repos, I see no problems for Manjaro (only!) users. As to all others Arch based distros that have access to AUR, it basically means blocking pacui from widespread use for no justified reason, against the spirit of open source community and common sense.

If @excalibur1234 want push also git version in our repository no problem : provide a pkgbuild and ping us when rebuild is needed :wink:

personally, i use the manual installation method, which requires a manual install of all dependencies for a properly working pacui. this is the fastest way to do development for me.

we can think about pacui-git in the manjaro repositories - no problem.
i just created the PKGBUILD file from the old PKGBUILD_AUR-git file here:
https://github.com/excalibur1234/pacui/blob/master/PKGBUILD-git
@Ste74, can you use this PKGBUILD? i have added your name as maintainer in order to honor your efforts.

i agree that the removal from the AUR is a bad thing for arch and arch-based distributions. experienced and motivated users might continue to use pacui, but the majority of users of those distributions is probably lost.

if any of those distributions want to include pacui (or pacui-git) in their repositories as well, they can either take the PKGBUILD* files available on github and modify them according to their needs or they can contact me and we can create a PKGBUILD file for their distribution together.

as arch linux users, you can either try to create your own AUR package of pacui (and hope it is not found quickly and removed) or bend to the will of those policing forces, who have just kicked out pacui. if you are able to contact them, feel free to argue with them (but not on my behalf).
i feel i have done everything i can. i am (and will be) willing to discuss specific technical matters. if there is a (potential) situation, in which the existing code is harmful, i will change it. however, nobody has described such a situation to me (and ideally explained what pacui’s code is doing and why it can be harmful).

1 Like

Yep… If -git version can help you to release in community to trace the issues why not…
maintainer is only a word… Your work is the real effort :wink:

At the moment i m in holiday at Mallorca but when come back to home i will push it ( aprox after 13/8)

1 Like

please take all the time you need - no rush needed. pacui is not a priority.

i just returned from holiday. enjoy all the quality human time you can get!

I’ve split this thread as it has moved from what should be development-related discussion to discussion about how the AUR is managed.


Just because it has been removed from the AUR does not mean it can’t be fixed and re-added.

Fix it. Improve it. Re-add it.

1 Like

Sad news but if you look at as a security risk then it was a correct decision no-corfirm should never be used under any circumstances, nor any of the other points.
That undermines al the bashing Arch got previously as not being a secure distro, is also against the arch guidelines come on fix the dam thing don’t be stupid in your thinking nothing has taken place that is directed at you or anybody else AUR is the “Arch users repository” its not the “manjaro users repository”.

If a package does not meet their guidelines they have every right to delete with no warning or explanation.
Its not only you this has happened to but others AUR was compromised Arch users do not want that to happen again.
Just take @jonathon advice fix it re-add it.

Out of curiosity, which of the AUR guidelines does this package not meet?

Well you do not need me to answer that if you do then you should not be using AUR should you.
Or read the guidelines. Years ago packages had to be approved, unless you were a trusted user, before they were submitted you also had to be a Arch user. That rule was relaxed and should be re introduced after more than one attack of on AUR so now every package is being checked not just this one get over it.

My security and other Real Arch users is a bigger priority than Manjaro users pkgs that don’t meet the standard.

“Manjaro is not Arch Linux” Arch Linux is for Arch Linux users Arch Linux states the criteria of what is Arch its simple enough installed the Arch way.

Manjaro is not installed the Arch way, nor is any spin they are not installed the Arch way.
Manjaro also has its own repros packages are modified has its own tools Manjaro is Manjaro not even a child more like a cousin
Nothing to do with me take it up with Jason or Alan they are nice and will explain it to you.

Because the yes/no dialogs are so much fun for the end user.
Which is where I have issues, I understand there is a security issue but being asked if i want to to edit the pkgbuild each time is damned annoying because I am a end user not a developer.
And then I get asked to I want to continue to install the package, well no I want to construct a giant robot to save the galaxy from an evil alien horde from another dimension… of course i want to install it!
Oy vey

4 Likes

Well that is the foolish answer that is expected of you is it not.
You would be the 1st slating Arch and the AUR down if you got mallware or a virus on your beloved computor/Laptop, It would of course not be your own fault it would then be the develloper of the helper, Manjaro/Arch to blame for your actions because you are a user that shows no responsibility for you own actions, go back to Mint where you belong you keep saying Mint is idiot proof after all.

i am repeating myself, but here it is again for you:
we are talking about the following line (and a couple of very similar lines) of code here:

yay -Syu

updates your system, including all packages from the AUR, which have a modified PKGBUILD file.

yay -Syu --devel --needed --noconfirm

is only executed if the previous command finishes without errors. then, all AUR development packages are reinstalled without user confirmation.

if a PKGBUILD file was modified (possibly in a bad way), you can check it with the first command. only if the PKGBUILD file was not modified, it is installed without user confirmation.

please describe ANY situation, in which the --noconfirm flag (as part of the 2 commands above) can harm an arch linux system.

you (and Alad Wenter and Eli Schwartz) argue that the use of --noconfirm is actually a security vulnerability.
as stated above, please describe ANY situation, in which the --noconfirm flag (as part of the 2 commands above) can harm an arch linux system.
as the --noconfirm flag is used in pacui, i do not see ANY security risk.
what is there to fix?


here is what pacman’s man page says about the --noconfirm flag:

 --noconfirm
    Bypass any and all “Are you sure?” messages. 
    It’s not a good idea to do this unless you want to run pacman from a script.

pacui is a bash script and unless i misunderstand all the manuals i have read, i know what i am doing.
but i fully acknowledge that new users are discouraged from using the --noconfirm flag.


i have (again) mentioned my arguments for the use of the --noconfirm flag within pacui.
please read the rest of this topic before you start a discussion about “the other points”. then, i do not have to repeat myself (again).


the only AUR guidelines (some linked on this page) i have found are available here:
https://wiki.archlinux.org/index.php/Arch_User_Repository
https://wiki.archlinux.org/index.php/Arch_packaging_standards
https://wiki.archlinux.org/index.php/Creating_packages
none of these guidelines prohibits the use of the --noconfirm flag.
please link the “guidelines” you are talking about.

3 Likes

If the AUR package has been updated (e.g. after adoption) to include malicious content. devel packages aren’t included in a yay -Syu so won’t be checked as part of that step.

Just because it’s on your system already doesn’t mean an updated PKGBUILD file can be implicitly trusted.

I know the majority of people do implicitly trust updated PKGBUILDs but strictly speaking they should check every change.

@dalto pointed out the flaw in my logic.

And you answered like a elitist, tisk tisk.
I always think of the end user and how things can effect them, I always thought of PacUI to be a rather nice bridge between command line and something that a new user could approach.
And yes the yes no dialogs are some of the most annoying things about arch and the AUR because they interrupt the flow of installation, I want to install a application not have to take a pop quiz.
I would not be complaining if the dialogs were not so oblivious.
Its so much like Vistas UAC with its cancel/allow dialogs, good for security yes (as the UAC was actually one of the good ideas Microsoft implemented) but being prompted all the time is damned annoying.
Password prompts are one thing, yes/no dialogs… ugh

3 Likes

You if you have a package foo-git. I thought ‘yay -Syu’ wouldn’t update because the pkgbuild hasn’t changed(even though the source has). But if you did get a new pkgbuild, won’t it rebuild foo-git regardless of whether the source has changed?

If we are talking about a pkgbuild that hasn’t changed that we have used in the past to install from that has always pulled the latest version of code from a certain repository, the risk seems pretty much the same as the first time you did the original install. What is the situation that you would choose not to install that?

1 Like

You both didn’t understand the matter. The rationale for --noconfirm was explained at least twice.
And you both are wrong about it. You are wrong about it on a very primitive level - it’s annoying for you to be asked if you really want to build the package. @mandog didn’t understand that --noconfirm get’s applied for packages which PKGBUILD didn’t change.

1 Like

Call me a elitist its water off a ducks back. If elitist is caring for your distro of choice that is fine by me users that don’t give a monkey about the distro that feeds them and the damage they can cause if a package is compromised, that is not thinking of the end user that is compromising the end user in this case Arch users. What Manjaro does with it own packages is Manjaro business. what Manjaro tries to do with AUR packages is Arch user business.
If Manjaro users do not comply then its tough shyte the package will be removed the trusted users are thinking of Arch end users the same applies to Arch users in fact a Arch user would more than likely get banned, It is their user repro not Manjaro so you guys either suck it or use your own.

Forum kindly sponsored by