Re: [aur-general] Submit updated package build to the AUR - hey

[Eli Schwartz via aur-general]

On 12/13/20 6:30 PM, Shyamin Ayesh via aur-general wrote:

Hi,

I'm new to this mailing list and don't know if I'm submitting the question
to the right one. Please forgive me if I'm doing something wrong.

I tried to submit new AUR package for the HTTP load testing tool called hey
written in golang and it got failed to "git push" because of the origin
repository is not empty. It seems like there is already a repository with
past work and I can't submit new package because of that reason. When I try
to navigate to the package page I can't find the package.

Repository: https://aur.archlinux.org/cgit/aur.git/?h=hey
Package: https://aur.archlinux.org/pkgbase/hey/ ( 404 - not found )


You're in luck -- it was deleted from the AUR due to being added to the 
official repos! https://www.archlinux.org/packages/community/x86_64/hey/


Or, well, I guess you're not in luck if you really wanted that learning 
experience of maintaining a package. In that case, feel free to find 
more cool software to maintain instead. ;)


...

Note that deleted packages in the AUR retain their git backing history 
even when delisted, for historical tracking purposes.


--
Eli Schwartz
Bug Wrangler and Trusted User



OpenPGP_signature
Description: OpenPGP digital signature

Re: [aur-general] Fwd: Change committer name

[Eli Schwartz via aur-general]

On 11/24/20 12:58 PM, Cyrusmg wrote:
> Hi,
> 
> could any Trusted User please change committer name for the latest commit I 
> have pushed for "eobcanka" package to "Cyrusmg " just like
> I have in previous commits ? I have used my corporate identity and that's 
> not good.
> ""
> 
> It should be possible as per "Modify committer or author identity" in 
> https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines
> (https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines)

Should be fixed now.

-- 
Eli Schwartz
Bug Wrangler and Trusted User


OpenPGP_signature
Description: OpenPGP digital signature

Re: [aur-general] TU removal: Evgeniy 'arcanis' Alekseev

[Eli Schwartz via aur-general]

On 11/8/20 12:48 PM, Morten Linderud via aur-general wrote:
> Yo,
> 
> I would like to start the discussion period for a Trusted User removal of
> Evgeniy Alekseev, also known as 'arcanis' on the grounds of 'Special Removal 
> of
> an Inactive TU' [1]. 
> 
> Evgeniy's last action on archweb was '2019-12-25 20:41', and the last vote 
> they
> participated in was the removal of shiv 13 montsh ago. I have also attempted
> sending them an email two times the past 5 months, along with Alad having sent
> them an email. There has been no replies.

Last commit to svn-community, 2019-06-30
Last AUR package update, 2018-12-16

Huh, I don't actually see any messages from him on any mailing list
except one during Alad's TU application.

> The voting procedure will commence after seven days of discussion
> period, in which Evgeniy can state his case.

7 days is the discussion period for a normal removal vote; the
discussion period for one triggered by inactivity is 3 days.

Other than that, this seems quite reasonable.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] This Saturday I was deprived the maintainer status of AUR package SGE without reason

[Eli Schwartz via aur-general]

On 10/12/20 4:40 PM, Manhong Dai via aur-general wrote:
> Dear AUR administrator,
> 
>   Can you please change me back to the maintainer of the AUR package SGE?
> 
>   This saturday I got two emails. One is user "freswa" disowned this
> package, and then 19 minutes later, another email said this package was
> adopted. When I got the two emails, it was already too late to adopt the
> package back. I did submit a request at the AUR web interface later, but
> the request was denied without any explanation.
> 
>   I am an SGE administrator for University of Michigan, and I have been
> maintaining the legacy SGE C code for many years to make it work with the
> latest library changes and the newer version of GCC. I published my code
> modification to AUR to help other Arch Linux user, and also help myself to
> maintain our own SGE cluster, which runs on both CentOS and Arch Linux.
> 
>   I really don't know why I was deprived of the maintainer status because I
> am a very responsive AUR maintainer. For example, I received some good
> suggestions about my other packages, I did accept those suggestions and
> modified my packages accordingly.
> 
>   The serious issue is I didn't receive any notification about the package
> sge before the two email notifications. It is quite scary for me, and
> should be scary for all AUR package maintainers.

Did you check your spam mailbox?

https://lists.archlinux.org/pipermail/aur-requests/2020-October/045427.html
https://lists.archlinux.org/pipermail/aur-requests/2020-October/045522.html
https://lists.archlinux.org/pipermail/aur-requests/2020-October/045529.html

>   Is there anything I can do to get the maintainer status back?
> 
> Best,
> Manhong
> 


-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Lost user/pass on AUR site

[Eli Schwartz via aur-general]

On 9/16/20 9:52 AM, Fábio Emilio Costa via aur-general wrote:
> Lost my password and user on AUR site. It was recommended to get help
> here... Anything I need to provide? I think I used this email to
> create it.

There is indeed an AUR account with this email. Did you try the "forgot
password" link on the login page? https://aur.archlinux.org/passreset/

You should be able to do account recovery via email on your own.

Since you do not have an SSH key *or* a PGP key associated with your
account, we will be unable to verify your credentials using those as an
emergency falback.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application - raster

[Eli Schwartz via aur-general]

On 9/7/20 6:59 AM, Eli Schwartz wrote:
> On 8/23/20 9:47 AM, Eli Schwartz wrote:
>> On 8/23/20 4:42 AM, Carsten Haitzler wrote:
>>> On Sun, 23 Aug 2020 09:15:34 +0100 Carsten Haitzler  
>>> said:
>>>
>>> Forgot to pgp sign... this reply is.
>>>
 Hi Everyone.

 I'm Carsten - or Raster.

 Sponsors: eschwartz and shibumi agreed to +1 me

 I'm upstream founder of enlightenment, EFL, terminology and a few other
 things. I work at Arm in Cambridge, UK (and live here). I've been involved 
 in
 OSS and releasing software since like 1995/96 or so for Linux (And other
 Unixen at the time). I've worked on several distributions - RedHat, Debian
 (made custom variant, not upstream) and Tizen. I pretty much eat, breathe 
 and
 sleep C, and of course that comes with the requisite "I can drive a shell
 script off a cliff gracefully" developer skill-set. Linux is my OS. I don't
 dual boot. All my machines are Linux machines without booting into anything
 else and that's been the way for me for me since I got my first PC in 1996
 after I had to give up on the Amiga. This PC then ran just Linux and 
 nothing
 else (never saw a DOS or Windows install). In fact all but 2 of my machines
 are Arch Linux (Rockpro64 dev board (debian SID) and my Ampere Emag aarch64
 workstation (Ubuntu), my pinephone has Manjaro for now which is 
 kind-of-close
 to Arch...).

 I already maintain the AUR packages for efl-git, enlightenment-git, 
 rage-git,
 efl-git-asan, enlightenment-git-asan and have for a long while now (also
 co-maintain terminology-git). You can see that I'm responsive to issues 
 people
 bring up and fix them pretty fast. I have done some edits to the arch wiki 
 as
 well over time.

 I will admit - I haven't really touched the Arch forums... I'm really an
 IRC/Email person, but I am on #archlinux, #archlinux-offtopic (and
 #archlinux-arm) most of the time.

 I've been using arch as my primary/only distro now for maybe about 4-5 
 years.
 I like its simplicity and "don't patch/modify things from upstream unless
 absolutely needed" policy (as an upstream I smile warmly at this 
 direction).
 It's very developer friendly... and that's who I am. I also run ALARM on my
 Rapsberry Pis.

 I do spend most of my effort on the upstream work on these E related 
 projects
 as those are what I write, release, add features to and fix bugs in.

 I'm about as googlable as it gets:

 ras...@rasterman.com
 http://www.rasterman.com

 I know that there are a lot of packages to maintain for a very small 
 number of
 people, so I'm happy to help out.

 I'd be best at taking over or being co-maintainer of:

 * efl
 * enlightenment
 * terminology

 Other packages I can add to community:

 * rage (https://aur.archlinux.org/packages/rage - i maintain rage-git 
 already)
 * evisum (https://www.enlightenment.org/news/2020-06-07-evisum-05-release)

 And in future any others that I think are past the bar of "worth including 
 in
 Arch community rather than AUR" over time (there are ones brewing or 
 lurking
 like EDI https://www.enlightenment.org/about-edi, Ephoto
 https://www.enlightenment.org/about-ephoto, Enventor
 https://www.enlightenment.org/about-enventor)

 I'd also be happy to help maintain packages I know I depend on and work 
 with
 that might be a bit niche like:

 * packagekit
 * ddcutil

 And in general just help attack anything that I know enough about to be a 
 bit
 better than a bowl of dried up custard at that is in my general sphere of
 knowledge/use.

 My PGP key hash: 04F7A0E31E08D3E08D39AFEBD147F94364295E8C
 http://keys.gnupg.net/pks/lookup?op=get=0xD147F94364295E8C

 Looking forward to pitching in and making Arch better :)
>>
>> I approve this TU application. Looking forward to seeing you on the team
>> soon. :)
> 
> The discussion period is over, time to vote!
> 
> https://aur.archlinux.org/tu/?id=123

Congrats to our newest TU! Voting results:

YesNoAbstainTotal   Participation
45 0 4  49  85.96%


Please review the checklist of things to do here:
https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_for_new_Trusted_Users

I've updated your AUR profile to grant you Trusted User permissions.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Deletion of sxiv-cdown-git

[Eli Schwartz via aur-general]

On 9/13/20 6:44 AM, Chris Down wrote:
> Hi there,
> 
> It seems this morning sxiv-cdown-git was deleted. It exists as a (small)
> fork from sxiv with features geared towards using it as a photo manager
> which Bert has indicated are different from his goals in mainline, not
> merely a set of config options or whatever. I assume Eli deleted it
> because he thought it's a one-person package, but it has multiple users.
> 
> I assume it was removed on this basis due to the name:
> 
>> Make sure the package you want to upload is useful. Will anyone else
>> want to use this package? Is it extremely specialized? If more than a
>> few people would find this package useful, it is appropriate for
>> submission.
> 
> ...but it is acutually used by a number of people (I know, because I
> have others in my photography group who use it).
> 
> Eli, on that basis, would you kindly consider restoring it? I'm happy to
> rename it sxiv-photomanager-git, or whatever else.

I deleted it at the same time as a couple of other sxiv derivative
PKGBUILDs. It is possible I was hasty in the process.

> I'm also a bit concerned about the predecent set for other packages
> which happen to bear my name, if that's the criteria for removal. For
> example, I have `systemd-cdown-git`, which is what I use when people
> report systemd problems to me and I write and ask them to try out some
> patches, so it's definitely used by more than a few people, albeit
> sporadically. Sure, I could just send PKGBUILDs and .install files
> around, but this seems reasonable to have on the AUR since it means I
> can just tell them the package to install, and things Just Work(tm). 
> That strategy has been very successful in the past. If the naming is
> part of the rationale for removal, any suggestion for that one?

In principle this is something I'm not comfortable saying "I, Eli,
refuse to allow this".

In practice, there are two general issues with "foo-${username}" packages:

- invariably they tend to to be low quality and not really interesting
  to multiple people [1]
- their method of advertising (a username) might not obviously convey
  why they are sufficiently useful

I'd like to specifically focus on the first of these issues. sxiv is
suckless.org software with the well-known building pattern of "each user
is supposed to provide their own config.h in order to perform
user-specific configuration". I feel like we probably don't need lots of
forked versions for this. These projects also have various patches which
it seems like every user picks and chooses between in order to obtain a
very specific respin of the software. Which they then name with their
name. "'s customizations for XXX"

This is *really common* for suckless.org software, as far as I can tell.
It's confusing, and gives the impression every suckless.org forked
package is just there to bundle one user's personal config.h to taste.

... I realize at this time we do also currently have 20 different forks
of dwm in the AUR. Which ones are actually used by people other than the
uploader? Well, at least a couple of them tell people why this fork is
useful. "dwm-keycodes" "dwm-hidpi"
What do the other ones do, even?

Perhaps there should be a general discussion about how to handle the
proliferation of suckless.org software forks, and what constitutes
uniqueness.

In the meantime, it seems like I may have made a mistake in deleting
your sxiv derivation. Renaming it to sxiv-photomanager-git sounds like a
good way to avoid future confusion, at least. :) Either way, consider me
to have withdrawn my objection to your package; you may feel free to
re-upload it.

...

On the topic of systemd-cdown-git, as an upstream systemd member
providing this as a method of helping people test your patches, I
suppose I better understand both the package and its use of your
username. But maybe you could make a note of that in the pkgdesc, e.g.

+="(cdown's integration testing branch)"

And maybe a pinned comment going into detail about why users should
consider using it. More knowledge never *hurts*.


[1] https://github.com/muennich/sxiv/compare/master...BachoSeven:master
https://lists.archlinux.org/pipermail/aur-requests/2020-September/044316.html

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application - raster

[Eli Schwartz via aur-general]

On 8/23/20 9:47 AM, Eli Schwartz wrote:
> On 8/23/20 4:42 AM, Carsten Haitzler wrote:
>> On Sun, 23 Aug 2020 09:15:34 +0100 Carsten Haitzler  
>> said:
>>
>> Forgot to pgp sign... this reply is.
>>
>>> Hi Everyone.
>>>
>>> I'm Carsten - or Raster.
>>>
>>> Sponsors: eschwartz and shibumi agreed to +1 me
>>>
>>> I'm upstream founder of enlightenment, EFL, terminology and a few other
>>> things. I work at Arm in Cambridge, UK (and live here). I've been involved 
>>> in
>>> OSS and releasing software since like 1995/96 or so for Linux (And other
>>> Unixen at the time). I've worked on several distributions - RedHat, Debian
>>> (made custom variant, not upstream) and Tizen. I pretty much eat, breathe 
>>> and
>>> sleep C, and of course that comes with the requisite "I can drive a shell
>>> script off a cliff gracefully" developer skill-set. Linux is my OS. I don't
>>> dual boot. All my machines are Linux machines without booting into anything
>>> else and that's been the way for me for me since I got my first PC in 1996
>>> after I had to give up on the Amiga. This PC then ran just Linux and nothing
>>> else (never saw a DOS or Windows install). In fact all but 2 of my machines
>>> are Arch Linux (Rockpro64 dev board (debian SID) and my Ampere Emag aarch64
>>> workstation (Ubuntu), my pinephone has Manjaro for now which is 
>>> kind-of-close
>>> to Arch...).
>>>
>>> I already maintain the AUR packages for efl-git, enlightenment-git, 
>>> rage-git,
>>> efl-git-asan, enlightenment-git-asan and have for a long while now (also
>>> co-maintain terminology-git). You can see that I'm responsive to issues 
>>> people
>>> bring up and fix them pretty fast. I have done some edits to the arch wiki 
>>> as
>>> well over time.
>>>
>>> I will admit - I haven't really touched the Arch forums... I'm really an
>>> IRC/Email person, but I am on #archlinux, #archlinux-offtopic (and
>>> #archlinux-arm) most of the time.
>>>
>>> I've been using arch as my primary/only distro now for maybe about 4-5 
>>> years.
>>> I like its simplicity and "don't patch/modify things from upstream unless
>>> absolutely needed" policy (as an upstream I smile warmly at this direction).
>>> It's very developer friendly... and that's who I am. I also run ALARM on my
>>> Rapsberry Pis.
>>>
>>> I do spend most of my effort on the upstream work on these E related 
>>> projects
>>> as those are what I write, release, add features to and fix bugs in.
>>>
>>> I'm about as googlable as it gets:
>>>
>>> ras...@rasterman.com
>>> http://www.rasterman.com
>>>
>>> I know that there are a lot of packages to maintain for a very small number 
>>> of
>>> people, so I'm happy to help out.
>>>
>>> I'd be best at taking over or being co-maintainer of:
>>>
>>> * efl
>>> * enlightenment
>>> * terminology
>>>
>>> Other packages I can add to community:
>>>
>>> * rage (https://aur.archlinux.org/packages/rage - i maintain rage-git 
>>> already)
>>> * evisum (https://www.enlightenment.org/news/2020-06-07-evisum-05-release)
>>>
>>> And in future any others that I think are past the bar of "worth including 
>>> in
>>> Arch community rather than AUR" over time (there are ones brewing or lurking
>>> like EDI https://www.enlightenment.org/about-edi, Ephoto
>>> https://www.enlightenment.org/about-ephoto, Enventor
>>> https://www.enlightenment.org/about-enventor)
>>>
>>> I'd also be happy to help maintain packages I know I depend on and work with
>>> that might be a bit niche like:
>>>
>>> * packagekit
>>> * ddcutil
>>>
>>> And in general just help attack anything that I know enough about to be a 
>>> bit
>>> better than a bowl of dried up custard at that is in my general sphere of
>>> knowledge/use.
>>>
>>> My PGP key hash: 04F7A0E31E08D3E08D39AFEBD147F94364295E8C
>>> http://keys.gnupg.net/pks/lookup?op=get=0xD147F94364295E8C
>>>
>>> Looking forward to pitching in and making Arch better :)
> 
> I approve this TU application. Looking forward to seeing you on the team
> soon. :)

The discussion period is over, time to vote!

https://aur.archlinux.org/tu/?id=123


-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] PKGBUILD with side-effects outside of build-dir

[Eli Schwartz via aur-general]

On 9/5/20 7:30 PM, Knut Ahlers wrote:
> Hey there,
> 
> Today I received a comment [1] on one of the packages I'm maintaining
> asking for a change which I'm really not sure about:
> 
> Basically the requested change is to have the build use an external
> environment variable (if set) which allows the packager to use an
> directory outside of the current build directory (the directory
> `makepkg` was executed in) for build assets.
> 
> This would on the one hand allow packagers to reuse crates already
> built and not to build every dependency again within the build process
> of the package itself.

The correct way to do something like this within one package is the way
it is done for ccache, i.e. a mechanism by which the compiler can check
to see if the current command line would result in identical output to
some previously cached compiler output, and simply reuse that.
C/C++-based projects can frequently benefit from this during rebuilds.

The correct way to do this for content originally built by some totally
unrelated package is not at all. This is what depends=() is for, and
static/shared libraries. It's not a makepkg problem if
rust-the-programming-language is *deliberately* slow as molasses.

(There is no reason why something like ccache should not *still* work in
this case, even though it's ill language design compared to
system-installable rlibs. However, the point remains that there should
be dedicated interfaces to this such as how ccache currently works via
makepkg.conf, not "set this random environment variable before running
makepkg to cause it to sidestep using $srcdir".)

> On the other hand this would introduce
> side-effects to the package building process and also the system of
> the packager. For builds within isolated environments like Docker
> containers this would basically not change anything.
> 
> My personal opinion is strongly biased against allowing side effects
> outside of the build-dir itself and against letting
> (developer-)environment-settings, of the systems which execute the
> build, interfere with the package build. In my opinion the build
> should stay in a way neither is allowed or at least prevented as far
> as possible.

I agree with you that this should not be done. Again: setting random
environment variables before running makepkg is not and should not be
supported in any way for changing how makepkg works or tearing $srcdir
out from under it.

Furthermore, the side effects seem to be worse than just ugliness: I
googled "CARGO_TARGET_DIR shared" and the top two results (other than
the manual page for CARGO_TARGET_DIR which is a false positive; it
didn't mention sharing them) were unfixed bug reports. e.g.

https://github.com/rust-lang/cargo/issues/7740

In fact, every single result on the first page, if it had anything to do
with the search query, at least warned that you might not want to this
since it works on some projects and breaks others due to rust not
knowing the difference between different crates or binaries with the
same name. Half of them mentioned sccache (ccache alternative) as the
superior option. sccache marks its rust support as experimental, but
that seems to mean it doesn't always successfully cache results, not
that it returns the wrong information.

> As I did not find advice / consent on this in the Wiki or AUR-General
> I'd like to have some opinions of other package maintainers on this:
> How would you like to have package builds behave?
> 
> Act as isolated as possible, not reacting to outside influences (like
> env-vars) though this will never be fully achieved without some
> wrapper wiping all env-vars from the outside…
> 
> OR
> 
> Allow interference of outside influences and allow modifications
> outside the build directory (for example store the build artefacts
> outside the build-dir and package them from there)…
> 
> Cheers,
>   Knut
> 
> [1] https://aur.archlinux.org/packages/dust/#comment-764039
> 


-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Removing py2 (make-)dependency vs. keeping py2 features ?

[Eli Schwartz via aur-general]

On 8/27/20 11:11 AM, Michael Kogan wrote:
> I had the same issue with the `medit` package. It's an editor with some
> nice features, in particular, an integrated bash terminal. I have been
> pointed to the fact that pygtk is deprecated some months ago, but removing
> pygtk as dependency leads to the bash terminal functionality vanishing. I
> decided to keep the dependency for now, but I am open for opinions!

That's a bit of a different case though. If major core features depend
on the python2 dependency, it makes sense to keep them.

It's more of a question with pycharm, because the only thing you gain in
pycharm is... the ability to edit/manipulate python2 code using it.

With medit, everyone would lose out on the integrated terminal. This
seems like a clear case to continue shipping it.

With pycharm, only people developing on legacy python2 codebases lose
out. Hence why it's a question.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application - raster

[Eli Schwartz via aur-general]

On 8/23/20 4:42 AM, Carsten Haitzler wrote:
> On Sun, 23 Aug 2020 09:15:34 +0100 Carsten Haitzler  
> said:
> 
> Forgot to pgp sign... this reply is.
> 
>> Hi Everyone.
>>
>> I'm Carsten - or Raster.
>>
>> Sponsors: eschwartz and shibumi agreed to +1 me
>>
>> I'm upstream founder of enlightenment, EFL, terminology and a few other
>> things. I work at Arm in Cambridge, UK (and live here). I've been involved in
>> OSS and releasing software since like 1995/96 or so for Linux (And other
>> Unixen at the time). I've worked on several distributions - RedHat, Debian
>> (made custom variant, not upstream) and Tizen. I pretty much eat, breathe and
>> sleep C, and of course that comes with the requisite "I can drive a shell
>> script off a cliff gracefully" developer skill-set. Linux is my OS. I don't
>> dual boot. All my machines are Linux machines without booting into anything
>> else and that's been the way for me for me since I got my first PC in 1996
>> after I had to give up on the Amiga. This PC then ran just Linux and nothing
>> else (never saw a DOS or Windows install). In fact all but 2 of my machines
>> are Arch Linux (Rockpro64 dev board (debian SID) and my Ampere Emag aarch64
>> workstation (Ubuntu), my pinephone has Manjaro for now which is kind-of-close
>> to Arch...).
>>
>> I already maintain the AUR packages for efl-git, enlightenment-git, rage-git,
>> efl-git-asan, enlightenment-git-asan and have for a long while now (also
>> co-maintain terminology-git). You can see that I'm responsive to issues 
>> people
>> bring up and fix them pretty fast. I have done some edits to the arch wiki as
>> well over time.
>>
>> I will admit - I haven't really touched the Arch forums... I'm really an
>> IRC/Email person, but I am on #archlinux, #archlinux-offtopic (and
>> #archlinux-arm) most of the time.
>>
>> I've been using arch as my primary/only distro now for maybe about 4-5 years.
>> I like its simplicity and "don't patch/modify things from upstream unless
>> absolutely needed" policy (as an upstream I smile warmly at this direction).
>> It's very developer friendly... and that's who I am. I also run ALARM on my
>> Rapsberry Pis.
>>
>> I do spend most of my effort on the upstream work on these E related projects
>> as those are what I write, release, add features to and fix bugs in.
>>
>> I'm about as googlable as it gets:
>>
>> ras...@rasterman.com
>> http://www.rasterman.com
>>
>> I know that there are a lot of packages to maintain for a very small number 
>> of
>> people, so I'm happy to help out.
>>
>> I'd be best at taking over or being co-maintainer of:
>>
>> * efl
>> * enlightenment
>> * terminology
>>
>> Other packages I can add to community:
>>
>> * rage (https://aur.archlinux.org/packages/rage - i maintain rage-git 
>> already)
>> * evisum (https://www.enlightenment.org/news/2020-06-07-evisum-05-release)
>>
>> And in future any others that I think are past the bar of "worth including in
>> Arch community rather than AUR" over time (there are ones brewing or lurking
>> like EDI https://www.enlightenment.org/about-edi, Ephoto
>> https://www.enlightenment.org/about-ephoto, Enventor
>> https://www.enlightenment.org/about-enventor)
>>
>> I'd also be happy to help maintain packages I know I depend on and work with
>> that might be a bit niche like:
>>
>> * packagekit
>> * ddcutil
>>
>> And in general just help attack anything that I know enough about to be a bit
>> better than a bowl of dried up custard at that is in my general sphere of
>> knowledge/use.
>>
>> My PGP key hash: 04F7A0E31E08D3E08D39AFEBD147F94364295E8C
>> http://keys.gnupg.net/pks/lookup?op=get=0xD147F94364295E8C
>>
>> Looking forward to pitching in and making Arch better :)

I approve this TU application. Looking forward to seeing you on the team
soon. :)

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Packaging ruby gems

[Eli Schwartz via aur-general]

On 8/9/20 4:59 PM, Anatoly Bashmakov via aur-general wrote:
> Hello.
> 
> I need feedback on packaging ruby gems.
> 
> First, I don't think packaging every gem of the latest version makes a
> lot of sense. For development there are rvm/rbenv/etc that solve this
> problem. The only gems need to package (I think) are gems that are
> required by end-user applications. But such applications may require
> gems not of the latest versions. So, there are several options here.
> 
> 1) Bundle dependencies in the application itself. I don't like this
> approach at all, since the package begins providing a lot of unnecessary
> gems.  Example: ruby-gollum-lib [1].

This package is in severe violation of PKGBUILD standards. It's bad
enough when mysteriously complicated software only works with giant
ruby-bundler envs installed in /opt. But under no circumstances should
it be installing its own dependencies into /usr/lib/ruby/gems

> 2) Package dependency gems only of versions required by the application.
> For example, gollum-lib gem requires loofah ~2.3 (which means >= 2.3 and
> < 2.4). The latest version of loofah is 2.6.0. So naming package
> ruby-loofah of version 2.3.1 for gollum-lib may entails rightly flagging
> it as out of date.

Indeed, non-slotted packages might be needed by other software expecting
up-to-date versions, so this is strictly inferior to option 3.

> 3) Packaging versioned gems. In previous example the package will be
> called ruby-loofah-2_3 (or something) and add "provides" in PKGBUILD. It
> is not forbidden by package guidelines (but not encouraged either) as
> far as I remember.

This is a suitable workaround if the package cannot be updated to use
the latest version. But try to see if upstream can update their code to
be compatible with the latest versions of their dependencies...

> 4) Not package ruby gems at all.
> 
> I don't like neither of these options, but I think packaging versioned
> gems is lesser evil.
> 
> What are your thoughts?
> 
> [1]: https://aur.archlinux.org/packages/ruby-gollum-lib/
> 


-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Help for AUR guides

[Eli Schwartz via aur-general]

On 8/3/20 12:27 AM, Budi via aur-general wrote:
> May one submitted to AUR not binary but a bash script or function (a
> quite fundamental, necessasry utility wrapper) instead ?

As per the submission guidelines:
https://wiki.archlinux.org/index.php/AUR_submission_guidelines

"Make sure the package you want to upload is useful. Will anyone else
want to use this package? Is it extremely specialized? If more than a
few people would find this package useful, it is appropriate for
submission."

Assuming that is the case, there's no reason to consider it problematic
merely because it is a script and not written in C. :)

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] [arch-dev-public] AUR migration

[Eli Schwartz via aur-general]

On 7/24/20 3:24 PM, Giancarlo Razzolini via arch-dev-public wrote:
> Em julho 23, 2020 17:09 Giancarlo Razzolini via aur-general escreveu:
>> Hi All,
>>
>> In continuing with the improvements being done to our infrastructure,
>> we're
>> planning to migrate the AUR to another machine. This means that,
>> during the migration,
>> there *will* be downtime of the whole AUR.
>>
>> I expect the migration to take around two hours and happen either
>> tomorrow (Friday)
>> or on Saturday, depending on availability.
>>
>> Regards,
>> Giancarlo Razzolini
>>
> 
> The migration is almost done. Since we are moving to a new machine, it will
> have new host keys. They are:

This seems like it could be a reasonable situation for posting to
https://www.archlinux.org/news/ so that people seeing the keys change
understands why and that it's okay. Not everyone follows a-d-p or
aur-general.

Thoughts?

> 
>    Ed25519: SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4
>    ECDSA: SHA256:5s5cIyReIfNNVGRFdDbe3hdYiI5OelHGpw2rOUud3Q8
>    RSA: SHA256:uTa/0PndEgPZTf76e1DFqXKJEXKsn7m9ivhLQtzGOCI
> 
> They are also be available on the home page when logged out.
> 
> Regards,
> Giancarlo Razzolini
(I'm never logged out, so I never see them.)

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] know what dependencies in PKGBUILD

[Eli Schwartz via aur-general]

On 7/23/20 4:50 PM, Knut Ahlers wrote:
> IMO you should add them as omitting packages required to run the
> program will cause issues for people. Packages should request
> everything they need to run.

Isn't that exactly what I said?

> As an example: All AUR packages I'm using on my machines are built on
> a CI system in containers. All of them do have a clean environment -
> of course containing devel packages. My machines do not have devel
> packages installed as long as they are not used for development as
> they don't require them. So an AUR package built through the CI system
> installed on a machine without devel packages will miss some of its
> dependencies and will be broken.
> 
> Also I know of repos maintained by TUs containing AUR packages: For
> them the same applies and while in a worst-case szenario I can patch
> the build before building it users relying on those AUR repos listed
> in the Wiki will get broken packages.

Never mind CI systems or TU repos. The official repos operate on exactly
this rule already. All official repo packages are intended to be
installed on systems with "base" installed but not "base-devel".

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] know what dependencies in PKGBUILD

[Eli Schwartz via aur-general]

On 7/23/20 4:07 PM, alad via aur-general wrote:
> 
> On 23/07/2020 15:45, Eli Schwartz via aur-general wrote:
>> On 7/23/20 9:17 AM, alad via aur-general wrote:
>>> Am 23/07/2020 um 15:10 schrieb Budi via aur-general:
>>>> h\How to know what dependencies only need to put  (surely not all)
>>> I proceed as follows:
>>>
>>> 1. ignore anything in base-devel
>> base-devel is for makedepends only, base is for depends.
> So? base-devel contains programs that can be used during runtime, like
> gawk.
Or 'which', or 'sudo'.

If they are used during runtime, you can't exactly leave them out of
depends=() on the rationale that people who installed base-devel to
build packages, won't have errors running it.

Unless I've misunderstood what you're suggesting here?

(gawk is covered by the base metapackage, though. So that is okay to
omit, but not because of -devel.)

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] know what dependencies in PKGBUILD

[Eli Schwartz via aur-general]

On 7/23/20 9:17 AM, alad via aur-general wrote:
> Am 23/07/2020 um 15:10 schrieb Budi via aur-general:
>> h\How to know what dependencies only need to put  (surely not all)
> 
> I proceed as follows:
> 
> 1. ignore anything in base-devel

base-devel is for makedepends only, base is for depends.

> 2. include libraries listed in ldd, if the package includes a compiled
> executable

This is wrong. If myprog links *only* to libfoo.so, and internally
libfoo.so links to libbar.so, ldd will show both libfoo.so and libbar.so

Instead use readelf -d and look for lines containing "NEEDED". Or use
lddtree (from the pax-utils package) to get a tree-based view of a
program's dependencies.

ldd is completely inaccurate and misleading for this purpose.

> 3. include external commands if they are required (and not already in
> base-devel)
> 
> The second point is not mandated (you can depend on a package fulfilling
> the needed library depends, transitively), though helpful when listing
> rebuilds. Otherwise, see the packaging guidelines on the wiki.
> 
> (inb4 10 pages of discussion after a 1-sentence question)


-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Upgrade will install package from testing without having testing enabled, it breaks a dependency of a package from AUR

[Eli Schwartz via aur-general]

On 6/30/20 2:27 PM, marnout wrote:
> Hi every body,
> I got a similar error :

This is not the same error.

> sudo pacman -Suy
> :: Synchronisation des bases de données de paquets…
>  core est à jour
>  extra est à jour
>  community est à jour
> :: Début de la mise à jour complète du système…
> résolution des dépendances…
> recherche des conflits entre paquets…
> :: xorg-fonts-alias-100dpi et xorg-fonts-alias sont en conflit.
> Supprimer xorg-fonts-alias ? [o/N]

You selected the default No option here.

> erreur : un conflit de paquets impossible à résoudre a été détecté
> erreur : la préparation de la transaction a échoué (conflit de dépendances)
> :: xorg-fonts-alias-100dpi et xorg-fonts-alias sont en conflit
> 
> In English it says something like :
> error: conflicting packages detected unresolvable
> error: could not prepare transaction (dependency conflict)
> :: xorg-fonts-alias-100dpi and xorg-fonts-alias are in conflict

You didn't translate the whole thing. For future notice, if you want to
describe the output in English you should use

sudo LC_ALL=C pacman -Syu

This will print *everything* in English.

> On my system :
> pacman -Qs xorg-fonts
> local/xorg-font-util 1.3.2-2 (xorg-fonts xorg)
>     X.Org font utilities
> local/xorg-fonts-100dpi 1.0.3-6 (xorg)
>     X.org 100dpi fonts
> local/xorg-fonts-alias 1.0.3-3
>     X.org font alias files
> local/xorg-fonts-encodings 1.0.5-2 (xorg-fonts xorg)
>     X.org font encoding files
> 
> So xorg-fonts-alias-100dpi is not installed.

pacman -Syu tried to install it as a brand-new dependency of
xorg-fonts-100dpi, but in order to do that you need to remove
xorg-fonts-alias.

When pacman prompted you to remove xorg-fonts-alias, you said "no".

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Upgrade will install package from testing without having testing enabled, it breaks a dependency of a package from AUR

[Eli Schwartz via aur-general]

On 6/30/20 2:10 AM, Ralf Mardorf wrote:
> Hi,
> 
> when upgrading with 'pacman -Syu' I get 'Packages (3) firefox-78.0-1
> xorg-fonts-alias-misc-1.0.3-4  xorg-fonts-misc-1.0.3-9', but extra
> provides xorg-fonts-misc 1.0.3-8,
> https://www.archlinux.org/packages/extra/any/xorg-fonts-misc/ ,
> xorg-fonts-misc 1.0.3-9 is from testing,
> https://www.archlinux.org/packages/testing/any/xorg-fonts-misc/ .
> 
> Testing is _not_ testing repo enabled:
> 
> [rocketmouse@archlinux ~]$ grep testing /etc/pacman.conf
> # The testing repositories are disabled by default. To enable, uncomment the
> #[testing]
> #[community-testing]
> #[multilib-testing]
> [rocketmouse@archlinux ~]$
> 
> The upgrade results in
> 
> "error: failed to commit transaction (conflicting files)
> xorg-fonts-alias-misc: /usr/share/fonts/misc/fonts.alias exists in
> filesystem (owned by xorg-fonts-alias) Errors occurred, no packages
> were upgraded."
> 
> Manual intervention is needed, 'pacman -Rdd xorg-fonts-alias'.
> 
> The problem is that this is the cause for
> 'error: missing 'xorg-fonts-alias' dependency for 'white_dune''
> 
> https://aur.archlinux.org/packages/white_dune/
> 
> and I wonder if a comment to fix the dependencies is appropriated,
> since actually the issue is caused by a package that should be in
> testing, but gets installed without testing enabled.

Why "should" it be in testing? pacman -Si reports that it is only in
extra...

www.archlinux.org is not updating properly to reflect the true state of
the repos. That's a completely different bug that has nothing to do with
this one package.

Your AUR package needs to adapt to perfectly normal changes in
https://git.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/xorg-fonts-alias=dcd3d0ba7d39ff30e26ef55441f760d6408224fd

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Account suspension?

[Eli Schwartz via aur-general]

On 6/27/20 8:39 AM, Tom Hale wrote:
> Hi Eli,
> 
> On 27/4/20 10:20 pm, Eli Schwartz via aur-general wrote:
>> I'd be amenable to re-enabling your account with a warning to be more
>> careful next time. However, I would appreciate it if you were to
>> acknowledge the importance of reading recent comments, but especially
>> pinned comments, when you have something to discuss about a package.
>> It's possible someone else has noticed the same thing you did, and
>> provided a solution. Or, in this case, it's possible there was a very
>> important notice, and reading it could prevent a great deal of confusion
>> or non-optimal interactions. ;)
> 
> Duly noted on reading recent and especially pinned comments to save time
> and frustration.
> 
> Would you mind doing the deed and re-enabling my account "Ataraxy"?
> 
> Thanks in advance,

Thank you.

Your account is now re-enabled.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Search-URL in PKGBUILD

[Eli Schwartz via aur-general]

On 6/3/20 8:26 AM, Ralf Mardorf wrote:
> On Wed, 3 Jun 2020 08:11:32 -0400, Eli Schwartz via aur-general wrote:
>> On 6/3/20 8:06 AM, Ralf Mardorf wrote:
>>> https://aur.archlinux.org/packages/perl-cpanel-json-xs/#comment-749091
>>>
>> What is a "search-URL"?
> 
> I don't know the correct term.
> 
> source=('http://search.cpan.org/CPAN/authors/id/R/RU/RURBAN/Cpanel-JSON-XS-4.19.tar.gz')
> ^^
> ^^

So a "search-URL" is a perl concept. That's something I did not know,
because I'm not a perl person.

To translate this into concepts that don't depend on an understanding of
perl...

This package downloads source code from the search.cpan.org website.

> It seemingly should redirect, but I get a HTTP 403 forbidden. I always
> need to edit this and other packages with such URLs.
> 
> source=("https://cpan.metacpan.org/authors/id/R/RU/RURBAN/Cpanel-JSON-XS-${pkgver}.tar.gz;)

... and apparently at least you are getting 403 forbidden errors. Which
is interesting, because at least I'm getting 301 "moved permanently"
redirects, to the cpan.metacpan.org website.

My conclusion is:

a) speak to the operators of this website and find out why you're being
   "forbidden"
b) a PKGBUILD should use the second url, because "moved permanently"
   means people should not be using the old, legacy site; also, it saves
   a tiny bit of bandwidth and performs fewer network connections to use
   the authoritative site directly instead of first querying another
   site and being told "no really, you should be looking there instead"


As for the package, the AUR maintainer updated it to use the
cpan.metacpan.org website, and threw in an https for free.

(Note that both search.cpan.org and cpan.metacpan.org support both
http:// and https:// and, for me, are accessible over either one.)

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Search-URL in PKGBUILD

[Eli Schwartz via aur-general]

On 6/3/20 8:06 AM, Ralf Mardorf wrote:
> Hi,
> 
> I'm using the default DLAGENTS settings in makepkg.conf [1], curl is
> from the core repo and up to date [2].
> 
> Search-URLs never do work on my machine, see
> 
> https://aur.archlinux.org/packages/perl-cpanel-json-xs/#comment-749091
> 
> What is the recommended solution to solve this issue?
What is a "search-URL"?

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Create user

[Eli Schwartz via aur-general]

On 5/21/20 10:29 PM, karx via aur-general wrote:
> Hey,
> 
> An application I'm thinking about packaging for AUR requires its own user
> to run. Is it ok to be/How would I go about creating a "user" that will be
> created on the installer's system when they install the package?

Use sysusers.d(5) to install a description of the user you need. systemd
comes with a pacman hook to create users based on sysusers.d dropins
(and for non-systemd distros using e.g. OpenRC, there are
reimplementations like opensysusers, because this is generally portable
and beneficial to use).

You can usually specify the "-" placeholder instead of a reserved,
hardocded uid, and have one automatically assigned. This is preferable
whenever possible.

You can check the output of

$ pkgfile -vr '/usr/lib/sysusers.d/.*\.conf'

to see which packages in the repositories use sysusers.d files, and see
how they are using it for inspiration. (Or see which packages on your
system provide files in /usr/lib/sysusers.d/)

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] When to use optdepends

[Eli Schwartz via aur-general]

On 5/14/20 1:53 PM, Markus Schaaf wrote:
> Am 12.05.20 um 17:53 schrieb Eli Schwartz via aur-general:
> 
>> I'd generally expect an optdepends for something which the program
>> has a built-in ability to use simply by installing the optdepends.
> 
> I'm sorry, but since you came up with the (IMO too clever by half)
> suggestion to add optdepends, I expected a somewhat more elaborate
> answer, considering the details of *that* package. The problem I have
> is this:
> 
> The package defines a couple of custom commands for compiling (la)tex
> to PDF and whatnot. (This is IMO a negligibility, because the main
> purpose of that editor plugin is to provide tools for *editing* latex
> files, not command suggestions for whatever task the author came up
> with.) One such command sequence is:
> 
> rubber [...] --pdf "$filename"
> gvfs-open "$shortname.pdf"
> 
> Now, rubber is like make, but for latex. And it's of the same
> complexity. Please have a glance at the man page. What it does and
> what programs it calls depends largely on the input (and
> configuration). Like make it may potentially call a lot of different
> programs. Even before considering which of these to include in
> optdepends, I would need to know them. I don't use rubber, and by
> cursory look I haven't found that information. The rubber package
> itself does not optdepend on anything. Like the make package. Am I
> supposed to find out? As the maintainer of an editor plugin? You could
> depend on texlive, but texlive doesn't contain everything. One surely
> needs more to compile something other than latex Hello-world.
> 
> This was the first line. The second is even better. gvfs-open calls
> the preferred PDF-viewer. Should I decide which? Or suggest all I can
> find?
> 
> Don't get me wrong. I'm not opposed to your suggestion to include some
> helpful optdepends. It's just not *that* easy. Arch is not Debian. I
> haven't looked, but Debian probably has a virtual package for
> PDF-viewer and a list of candidates. Ubuntu has flavours where someone
> decided which of these candidates it is. Even if Arch had flavours, an
> AUR package would not.
> 
> This was only the first command. There are more. :-)

I'm no expert on the plugin, I haven't used it and I don't do latex...
but the name of the plugin implies it's intended to be used for a
specific type of command. If it's just a... general command runner? with
a couple of default commands that aren't particularly suited to
universal use, then maybe I've misunderstood and it doesn't really merit
an optdepends.

I assumed it would be something like e.g. a hardcoded menu entry to run
some standard and usually-useful command that most people using it would
want to run, with maybe the ability to customize it for exotic needs.
Since it's apparently a lot more nebulous than that, I guess I was
wrong. Anything that needs to have its command be configured before you
can reasonably expect to use it, seems like the user would need to also
figure out their own set of dependent software too. There's no out of
the box experience.

OK then -- I retract my suggestion.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application; freswa

[Eli Schwartz via aur-general]

On 5/6/20 5:19 PM, Frederik Schwan via aur-general wrote:
> Hi everyone, my name is Frederik aka freswa and I'm applying to
> become a Trusted User with svenstaro's and grazzolini's sponsorship.
> 
> I started using Linux around 2004 with some live images of Ubuntu. In
> 2010, Debian became my main OS. Only a year later I switched to Arch
> after I screwed up Debian/sid while hunting for the latest kernel.
>
> I'm interested in DevOps topics, mail server, C, Rust, Go and newer
> JVM languages such as Kotlin.
> 
> Thanks to svenstaro I've been a bug wrangler since February. You
> mostly hear from me when I assign bugs to the wrong people from time
> to time :P
> 
> OS contributions:
> - working on the dovecot-xaps code, providing native Mail.app
>   Apple Push for iOS devices
> - maintaining and writing PKGBUILDs for the AUR
> - bug reporting and fixing for several projects
> 
> My AUR packages got reviewed recently by eschwartz, svenstaro and
> alad - thanks :)

Just for the record -- I did not review your AUR packages, you may have
intended to ask me to do so but this never happened. Perhaps you drafted
this email and forgot to remove my name before sending it?

You did provide a very useful kernel backports patch for my zfs-dkms
package, which was much appreciated.

> If I become a TU, I'd like to focus on the bug tracker until we have
> a better solution. I'd also like to help out bug fixing when
> maintainers are busy, away or on vacation.

I don't know what this means... once there is a "better solution for our
bugtracker" you intend to not focus on it? :p

Becoming a TU might give more opportunities to commit fixes to packages,
but it's unrelated to triage and analysis, at least, which I'd say are
the things which need the most love.

So there's plenty to do there either way. :D
(Speaking from personal experience, being a TU has made me less
productive on the bugtracker.)

> I'm aware though that some of these packages do not meet the criteria
> of 10 votes yet. I'll reevaluate whether they meet this criteria from
> time to time.
> 
> I'd also like to go on helping Eli with maintenance of
> zfs-dkms and zfs-utils in the AUR.

Patches and suggestions are definitely welcome. :D

Though I doubt zfs is suitable in any way for inclusion in community,
despite indeed having enough votes.

> In case JetBrains is okay with us packaging their IDE's, I'd also
> maintain them. But so far all requests I found resulted in a negative
> response from JB.

I'm given to understand packaging our current packages for
pycharm/intellij community edition gives their current maintainers
enough agonizing headaches. It seems like the kind of thing one would
want to avoid getting involved in. :D

I don't think we should be packaging their custom JRE, anyway, as that
should remain an AUR kind of thing (and we don't optdepends on AUR
packages either). This probably makes it more complicated to support
their stuff, especially for things which aren't open source?

tl;dr do you believe this is practical to focus on? Do you think they
are likely to provide a way for us to package it which fits our
packaging guidelines?

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] When to use optdepends (was: AUR package q -- newbie)

[Eli Schwartz via aur-general]

On 5/12/20 9:55 AM, Markus Schaaf wrote:
>> It's not really clear to me when to optdepend.
> 
> Comments welcome. My idea is to use optdepends for things the user may
> want, but it's not obvious how to make them work, like a glue-library
> the application needs to use another facility, e.g. gpgme to use gpg, or
> ghostscript to produce PDF.

I'd generally expect an optdepends for something which the program has a
 built-in ability to use simply by installing the optdepends.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] AUR package q -- newbie

[Eli Schwartz via aur-general]

On 5/12/20 3:04 AM, Markus Schaaf wrote:
> If you look at the plugin's settings, there are a couple of commands
> defined. One of which you are trying to use. The plugin's installation
> doesn't depend on any of the programs that are setup by default for
> these commands, because you may want to change them. Or not use all of
> them. I wouldn't want to install R, for instance, just because the
> plugin has commands to render *.rnw files. It's your responsibility to
> install and setup everything, so the commands you use do what you want.
> If you want to use the default rubber command, you need to install at
> least 'rubber' and 'texlive-core'. The plugin does no magic. It just
> calls a command. You may test the very same command in a terminal.

On the other hand, this *would* seem like a good situation in which to
use optdepends.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] AUR package q -- newbie

[Eli Schwartz via aur-general]

On 5/11/20 10:09 AM, Raj Kombiyil via aur-general wrote:
> Dear all,
> Greetings!
> Just finished my maiden install of arch-linux on my laptop, with my share
> of headache. But things are running alright now, I guess. It's kind of
> difficult to find packages in one place -- e.g.; I could install gedit
> easily (via pacman), but couldn't find the LaTeX plugin. Searching, I see
> it is in AUR:
> https://aur.archlinux.org/packages/gedit-latex
> I see that in the comments section, there's some issue. The package is
> updated in 2017 last. I know all these will be voluntary work and maybe
> people don't need this plugin much. For me, I could compile LaTeX source on
> the fly, using gedit with this plugin. What should I do to install this
> package?

One advantage of the AUR is that many people have shared their work in
the AUR. One disadvantage is that since they are still, at the end of
the day, unsupported, they might become abandoned by their previous user
and stop working.

You have a couple of options.

- You can try commenting on the package, asking the maintainer to fix
  it.

- You can ask here or in the package requests subforum for some kind
  individual to update it for you, which often (but not always) works:
  https://bbs.archlinux.org/viewforum.php?id=38

- You can try to do it yourself, and ask for guidance (again, here or on
  the forums) which has the additional advantage of letting you learn
  something new, which can be exciting to some, and useful the next time
  you need a package.

I'm personally willing to provide guidance and help walk people through
the process of writing their first PKGBUILD, but I don't just do it for
people. However, don't worry, there are definitely other people who are
willing to do it for you, so you can certainly ask and there's a good
chance one of them will see your request and respond. (I have a gut
impression this happens more often on the forums, FWIW.)


To provide a head start, I'll point out that from a quick look at the
latest version of this plugin (
https://gitlab.gnome.org/GNOME/gedit-latex ) it appears to have been
switched from autotools to meson, which might simplify the build process
a bit but does require some changes.

> I was hoping just to install and move on with my work. I am into science
> computing and don't have the knowledge base to make this work/make packages
> etc. I read good things about Arch, so I picked it. Apologies, I am
> thankful for the great work all the developers/volunteers do, but at this
> moment I just would like something that works.
> Thank you for your time and any help would be greatly appreciated.

We appreciate your thanks. :)

I hope you find a quick resolution, see above.

Please note that writing a package can be fairly simple and easy to pick
up. In case you end up deciding you'd like to try this out, I would
encourage taking a quick look at the following resources to start with:

https://wiki.archlinux.org/index.php/Creating_packages

and https://wiki.archlinux.org/index.php/Classroom#Previous_classes (I
am a big fan of the class titled "The Beginner's Guide to Arch Linux
Package Management" :p)

And of course, you are free to ask any questions, we will be more than
happy to answer.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] intel-opencl-sdk updated to 2020, probably poorly

[Eli Schwartz via aur-general]

On 5/5/20 1:46 PM, Nick Black via aur-general wrote:
> Late last night, I put together an update to intel-opencl-sdk,
> updating it from the 2017 edition to 2020. This was by far the
> most difficult PKGBUILD I've ever done, and I suspect it is less
> than optimal in one or more ways.
> 
> If anyone feels competent to take a look at the packaging or
> (more importantly IMHO) the installed result, please do so.
> 
>   https://aur.archlinux.org/packages/intel-opencl-sdk/
> 
> I intend to get to intel-opencl-runtime, helpfully flagged as
> out-of-date last week, today or tomorrow.


Don't write to "${pkgdir}" in your build() function.

Instead, instruct the software to install to

"${srcdir}/temp_install"

and then in package() you may 'mv' this to "${pkgdir}".

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Account suspension?

[Eli Schwartz via aur-general]

On 4/27/20 10:49 AM, Tom Hale wrote:
> Heya all,
> 
> When logging in as "Ataraxy" at:
> https://aur.archlinux.org/login
> 
> The site says: "Account suspended"
> 
> Can somebody tell me why my account is suspended, and if in error,
> reactivate?

Your account details shows you have a deleted comment at
https://aur.archlinux.org/packages/libc++/

In violation of the pinned comments, it asks for the tests to be
disabled by default.

Note that due to a lengthy prior history of abuse by various users,
including repeated requests for exactly what you asked -- and which was
answered both patiently by the maintainer and somewhat less patiently by
two different Trusted Users -- as well as some upsetting insults and
abuse directed at the maintainer (which you did not do)...

... the libc++ package was already declared a zero-tolerance zone for
people who failed to respect the pinned comments. In the context of
discussion about whether the package *should* use the check() or
validpgpkeys=() features, we've tended towards very strict enforcement,
and you have been caught up in that.

Although you were *not* rude or nasty about it, you still participated
in the issue of "many people keep on bugging the maintainer to make a
change, completely ignoring that the maintainer has said no". The
consequence of this was that, per the warning on that page, your account
was suspended.

...

Note: I am the TU who triggered this suspension. I don't recall whether
or not I reached out to you about it -- if I forgot to do so, you have
my apologies.

I'd be amenable to re-enabling your account with a warning to be more
careful next time. However, I would appreciate it if you were to
acknowledge the importance of reading recent comments, but especially
pinned comments, when you have something to discuss about a package.
It's possible someone else has noticed the same thing you did, and
provided a solution. Or, in this case, it's possible there was a very
important notice, and reading it could prevent a great deal of confusion
or non-optimal interactions. ;)

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] User deletion request

[Eli Schwartz via aur-general]

On 3/31/20 3:14 PM, Giusy via aur-general wrote:
> I've been banned from AUR, but I keep getting notification of package I
> maintained on my email and that's annoying.
> 
> Please delete my user. Thanks.

What's your AUR username? Also, why were you suspended? Do you have
anything you want to say in support of getting your account unlocked?

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Proposal: Mark packages that require significant computational power to build

[Eli Schwartz via aur-general]

On 4/3/20 3:24 PM, Nick Shvelidze wrote:
> Hello everyone, as you know, some packages on AUR take many minutes to
> build on all but very powerful machines. I think it would be helpful to
> have an optional bit of metadata that will mark these packages, or possibly
> even a general thing that will describe approximately how intensive the
> package is to build.
> 
> Writing this as freecad-git melts my laptop.

A pinned comment could do this today. Most users of such software I
think know that they are heavyweight software, to be honest.

Either way, this is not going to be an official PKGBUILD variable as
defined by makepkg and stored in the .SRCINFO, because it is out of
scope for makepkg.

I guess it could be discussed as a potential feature for e.g. a checkbox
in the AUR web interface. There's a slightly similar feature request at
https://bugs.archlinux.org/task/56602 asking for a checkbox for "this is
a VCS package".

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] What is pkgrel and why/how should I use it?

[Eli Schwartz via aur-general]

On 3/3/20 6:28 PM, karx via aur-general wrote:
> On Tue, Mar 3, 2020, 5:23 PM Doug Newgard via aur-general <
> aur-general@archlinux.org> wrote:
> 
>> On Tue, 3 Mar 2020 13:29:30 -0600
>> karx via aur-general  wrote:
>>
>>> Hi Georg, thank you for your reply.
>>> If I am understanding correctly, pkgrel is for changes to the
>>> PKGBUILD, and pkgver is for changes to the actual sources. Is this
>>> correct?
>>>
>>> Yash
>>>
>>> On 3/3/20, Georg  wrote:
 Hi Yash,
 and welcome to archlinux.
 pkgrel is the internal revision of the package, e.g. the packaging
 version. This allows improvements on the package without bumping the
 software release version and is often used for binary rebuild to adapt
 to changed dependencies etc.
 Georg

>>
>> Kind of. pkgrel is for changes to the built package, there's plenty of
>> changes
>> you can make to the PKGBUILD that don't change the actual package; those
>> don't
>> require a pkgrel change.
>>
> 
> Like what?

Whitespace or quoting changes. Switching from "mkdir -p foo && cp foo
bar/baz" to "install -Dm644 foo bar/baz". Changing the CMake generator
between GNU Makefiles and Ninja.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] What is pkgrel and why/how should I use it?

[Eli Schwartz via aur-general]

On 3/3/20 3:50 PM, Alexander Fasching wrote:
> On Tue, 2020-03-03 at 15:36 -0500, Eli Schwartz via aur-general wrote:
>> On 3/3/20 2:09 PM, karx via aur-general wrote:
>>> Hello all, sorry if this is not in the appropriate mailing list. I
>>> am
>>> developing an AUR package, and it says that pkgrel is a required
>>> field.
>>> Right now, I simply leave it at 1, but I want to know how I should
>>> really
>>> use it and what its purpose is.
>>>
>>> Thanks, Yash
>>
>> This mailing list is fine for any discussion about developing AUR
>> packages, including questions about the PKGBUILD format.
>>
>> But I am curious -- have you read the wiki documentation at
>> https://wiki.archlinux.org/index.php/PKGBUILD#pkgrel and if
>> so, is there
>> anything that was still unclear to you after reading it?
>>
> 
> I have a question about pkgrel and git commits in the AUR. Should I
> update pkgrel every time I make a commit and don't change pkgver?
> I use aurpublish to manage my packages and I have some commits that
> don't change pkgrel because I don't publish these commits.
> 
> I don't see a problem doing it this way because people who build from
> intermediate commits should know what they are doing, but I don't know
> if there are any guidelines on it. If pkgrel should be updated, then
> maybe the aurpublish hooks should enforce this.

The pkgver and pkgrel together (and epoch, if it exists), together form,
let's call it the "fullpkgver". For example, pacman is 5.2.1-4 and zlib
is 1:1.2.11-4

Every time the built package changes, whether that is due to building
different code, or having different packaging metadata (new
dependencies, etc.) the fullpkgver *must* change.

If the change is due to a new version of the code being built, then the
pkgver= field changes (and pkgrel is reset).

If the change is due to the PKGBUILD enabling different options, or
adding new dependencies, or similar, then the pkgver naturally cannot
change, so instead we increment the packaging-specific version suffix,
i.e. the pkgrel. Ultimately, the package can still be uniquely
identified via its fullpkgver and shows up as a new (upgradeable) package.

If all you did was modify the formatting or something, then obviously
this does not qualify for a pkgrel bump.

I think, though, that you are asking about changes which *do* modify the
package, but which were never publicly pushed (and were used for local
testing, I suppose). I don't see anything particularly wrong with only
incrementing the pkgrel once in this case, though personally I tend to
use git commit --amend and then push one new commit in such cases.

Since users never end up with a changed package but without an updated
pkgrel, it never affects them and does not matter. Think of it like a
transitional state between two tags, or a patch series merged using the
"git merge --no-ff" option.

So I would not worry about updating the pkgrel in such cases. (I guess
if you really want to, you could?)

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] What is pkgrel and why/how should I use it?

[Eli Schwartz via aur-general]

On 3/3/20 2:09 PM, karx via aur-general wrote:
> Hello all, sorry if this is not in the appropriate mailing list. I am
> developing an AUR package, and it says that pkgrel is a required field.
> Right now, I simply leave it at 1, but I want to know how I should really
> use it and what its purpose is.
> 
> Thanks, Yash

This mailing list is fine for any discussion about developing AUR
packages, including questions about the PKGBUILD format.

But I am curious -- have you read the wiki documentation at
https://wiki.archlinux.org/index.php/PKGBUILD#pkgrel and if so, is there
anything that was still unclear to you after reading it?

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Anydesk 404 not found

[Eli Schwartz via aur-general]

On 3/1/20 12:56 PM, Frederick Zhang via aur-general wrote:
> Sorry please ignore my last comment since apparently it was replaced by
> anydesk-debian [1].
> 
> [1] 
> https://lists.archlinux.org/pipermail/aur-requests/2020-February/037952.html
This... doesn't even make much sense at all. What is the point of having
so many packages for the same thing?

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Question about AUR submission guidelines rule #1

[Eli Schwartz via aur-general]

On 2/27/20 10:36 AM, Lone_Wolf wrote:
>    - packages that *remove *features.
> 
> example : mesa-noglvnd[2] disables glvnd support but is otherwise the
> same as extra/mesa of the same upstream version .
> 
> Maybe change the wording to clarify this ?

It has the feature of avoiding glvnd for people who dislike glvnd?

>    - VCS packages building trunk master or specific branches
> 
> example : gcc-git [3]
> 
> The PKGBUILD is very similar to repo version, but it does build trunk
> master.
> 
> Are they considered to have 'patches' or should they be mentioned
> specifically ?

Well, those certainly do have patches, and the suffix -git indicates
what form those patches take, I suppose. The wording could possibly be
tweaked to make this clearer, but I would consider it already covered.

>    - VCS packages building a specific commit or revision
> 
> (Sorry, can't find an example atm.)
> 
> Usually these are considered 'stable' versions. Are they seen as
> packages having patches or should they have their own rule ?
> 
> Suppose we have  2 packages of this type :
> 
> A builds a commit that matches exactly with latest released version, B
> builds some commit without a tag or label..
> 
> In my opinion A violates rule#1, but I'm unsure about B.
> 
> How do we make the difference clear ?

Packages that build from an arbitrary commit are no different from
packages that build from a stable tag -- they must have a really good
excuse for why the official repository version is insufficient.

>    - Older versions of repo packages
> 
> There are plenty of older versions of repo packages in AUR . Just search
> for gcc or llvm.
> 
> I don't see anything in the exception that applies to these packages.

This is the only thing which I believe contains true ambiguity in the
current guidelines.

The counterpoint is that we do package things like qt4, gtk2, python2,
ruby2.6, gcc8, llvm7, electron{2,4,5,6} as dependencies for other
software, in the official repos.

On the other hand, we generally do not want such packages anyway. Unless
they are dependencies for some other package and thus needed. So I
really do not want to imply carte blanche to upload old versions of
random packages to the AUR either.

One solution would be to leave it as uncovered, thereby reserving the
right to delete them at any time, with the unspoken acknowledgement that
we, the TUs, will not actually delete such AUR packages unless we would
likewise delete them from the official repositories for the same reasons.

> Lone_Wolf
> 
> 
> [1] https://wiki.archlinux.org/index.php/AUR_submission_guidelines
> 
> [2] https://aur.archlinux.org/packages/mesa-noglvnd
> 
> [3] https://aur.archlinux.org/packages/gcc-git/


-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Spring cleaning (moving orphaned packages from [community] to AUR)

[Eli Schwartz via aur-general]

On 2/25/20 10:22 AM, Alexander F Rødseth via aur-general wrote:
> Hello,
> 
> It's time for the semi-yearly package cleanup of [community] packages, as
> is tradition.
> 
> I have gathered a list of "unneeded orphans" in [community] (packages that
> currently has no maintainer, and no other package depends on them) from the
> excellent list on our web page.
> 
> TUs and Devs, please adopt, if you're interested:

This should be on arch-dev-public since there's no requirement for Devs
to be subscribed to the AUR mailing list and it's about official
repository affairs, not AUR affairs...

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] CVEs Listing issue

[Eli Schwartz via aur-general]

On 2/24/20 1:12 AM, Vijay Kumar Kamannavar via aur-general wrote:
> Hello Team,
> 
> https://security.archlinux.org/issues/all is not listing all CVES.

When you posted this message to the aur-dev mailing list, I suggested
you post instead to the arch-general mailing list.

This is not the arch-general mailing list, it is the aur-general mailing
list.

*arch*, not *aur*.

arch-gene...@archlinux.org


-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] review of getax2019 PKGBUILD

[Eli Schwartz via aur-general]

On 2/23/20 1:11 PM, Yoan Blanc via aur-general wrote:
> Le dim. 23 févr. 2020 à 15:36, Bert Peters via aur-general <
> aur-general@archlinux.org> a écrit :
> 
>> On Sun, 2020-02-23 at 13:17 +0100, Yoan Blanc via aur-general wrote:
>>> Hi folks,
>>>
>>> I've built my first PKGBUILD based on Brunio Renié's vaudtax,
>>> https://aur.archlinux.org/packages/vaudtax/
>>>
>>> https://gitlab.com/greut/getax
>>>
>>> Do you think I could propose it as is to aur-request? Do you see
>>> anything
>>> that could be improved?
>>>
>>> Cheers,
>>>
>>
>> Some things that stand out:
>> - You prepare shouldn't ever download things; you should use the
>> sources array for that.
>> - The build function isn't mandatory and can be left out if unused.
>> - The included `getax` script checks for java somehow, which is a
>> direct dependency. If this script comes from somewhere else, include
>> it in the sources array. Otherwise, just assume that your dependencies
>> are actualy isntalled.
>> - You should consistently quote $srcdir and $pkgdir since they may
>> contain spaces.
>> - Not sure if there is a rule about it, but a package description in
>> French seems odd to me.
>> - You depend on a specific java package rather than a specific java
>> version, or just java-environment. Why?
>> - Take a look at the java packaging guidelines in [1], it has more
>> general tips wrt to packaging java apps.
>>
> 
> 
> Wow, thanks a lot. I've managed to:
> - use source for all the files
> - simplify the shell script by assuming all the dependencies are installed
> - translate the description :)
> - and more.
> 
> Although, it only works with Java 8... so it has to stick to jre8-openjdk.

You should use "java-runtime=8" as the dependency since that is provided
by jre8-openjdk but may also be provided by oracle java from the AUR.

On the changes you have made:

for f in $(ls config\|* lib\|* model\|*); do

Don't do this:
http://mywiki.wooledge.org/BashPitfalls#for_f_in_.24.28ls_.2A.mp3.29

config\|* lib\|* model\|*

This is already a list of filenames, there is no need to run them
through a subshell and the ls program just to break on strange corner
cases, and eventually get the glob expansion right back anyway.

You're still using unquoted:

cd $(dirname $(dirname $(realpath $0)))

Also, license=('custom') -- where is the license text? See
https://wiki.archlinux.org/index.php/PKGBUILD#license

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] review of getax2019 PKGBUILD

[Eli Schwartz via aur-general]

On 2/23/20 7:17 AM, Yoan Blanc via aur-general wrote:
> Hi folks,
> 
> I've built my first PKGBUILD based on Brunio Renié's vaudtax,
> https://aur.archlinux.org/packages/vaudtax/
> 
> https://gitlab.com/greut/getax
> 
> Do you think I could propose it as is to aur-request? Do you see anything
> that could be improved?

Added to what others have pointed out...

for v in $(seq 1 2); do
varname=_update_1_0$v
for f in ${!varname}; do

You could just use:

for f in _update_1_0{1,2}

Your file https://gitlab.com/greut/getax/-/blob/master/getax contains
bash-specific &>, but a /bin/sh shebang. You can easily use /bin/sh
compatible syntax:

type java &> /dev/null

becomes

type java > /dev/null 2>&1

...

but you should not be using "type" at all, just use command -v >/dev/null

You also don't need to check if [ "$?" -ne "0" ] ; then

Instead, just check

if ! command -v java >/dev/null; then

later you use:

which zenity

The "which" program is not guaranteed to be installed, stick to one
builtin method (command -v is preferred, type has reliable results if
you stick to #!/bin/bash).

(Of course this is mostly moot if your package depends on java-runtime
anyway.)

cd $(dirname $(dirname $(realpath $0)))

Each $() should be quoted, just like a variable, to avoid unexpected
whitespace in paths. Since you're not hardcoding the same directory you
installed to, but building it using dirname/realpath, you should not be
assuming *anything* about the path.

pkgver=2019
_pkgver=1.02

This is confusing and the latter should maybe be "_minor_version" or
something that makes it clear why they are so different.


-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Review of clickhouse-static PKGBUILD

[Eli Schwartz via aur-general]

On 2/10/20 5:02 AM, Felixoid via aur-general wrote:
> Hello, dear TUs and Arch developers.
> 
> I'd like to ask relative the package clickhouse-static[1]. The
> officially supported way to build ClickHouse binaries is static
> linking[2]. And my question: is it possible that the package with the
> current building structure (getting contribs like submodules in
> upstream, static linking etc.) would theoretically come to [community]
> repository?

"upstream recommends using vendored static linking" is not an acceptable
reason to violate the packaging guidelines.

The program *must* build using the system versions of the 46
dependencies listed in the -static package, and the pkgname must be
"clickhouse", not "clickhouse-static", in order to be moved to
community; this is part of the "quality of life" care which defines a
Trusted User's job.

Among other things, this ensures that the openssl and libcurl versions
used are the latest versions which are tracked on the security tracker
and patched with security backports if needed -- something which is
understandably important for anything that is communicating over the
network.

Also, libxml2 from 2 years ago, which is a bit ouch because xml is not
exactly the least-exploited data format ever.

Even linux distributions which build statically by default, will expect
that the program link to the system's lib*.a static library packages
rather than build a custom one.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Issue python PKGBUILD

[Eli Schwartz via aur-general]

On 2/7/20 4:36 PM, Iyán Méndez Veiga wrote:
> Now I would like to get rid of the package contains reference to $srcdir 
> warnings. Any ideas?
> 
> They are all .so files, and using strings I find there are always mentions to 
> .pyx and .cxx files using the full path.

cmake embeds full paths into binaries.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Issue python PKGBUILD

[Eli Schwartz via aur-general]

On 2/6/20 6:10 PM, Iyán Méndez Veiga wrote:
> Hi,
> 
> After a new release of a python module, I'm facing an issue to update the 
> PKGBUILD. I get a permission error in the package() section:
> 
> Traceback (most recent call last):
>   File "setup.py", line 52, in 
> setup(
>   File "/usr/lib/python3.8/site-packages/skbuild/setuptools_wrap.py", line 
> 639, in setup
> _copy_file(data_file, dest_data_file, hide_listing)
>   File "/usr/lib/python3.8/site-packages/skbuild/setuptools_wrap.py", line 
> 828, in _copy_file
> copyfile(src_file, dest_file)
>   File "/usr/lib/python3.8/shutil.py", line 259, in copyfile
> with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
> PermissionError: [Errno 13] Permission denied: '_skbuild/linux-x86_64-3.8/
> cmake-install/src/third-party/headers/muparserx/.git/objects/pack/pack-
> bcece967ee9ec3297e6c8709d2c6d670ad7e3af2.idx'
> 
> However, if I execute python setup.py install --root="test-install" --
> optimize=1 --skip-build manually I cannot replicate the error.
> 
> Is there any difference between when makepkg executes that command and when I 
> do it myself?

Well, makepkg runs under fakeroot.

But forget about that. Why is setup.py install attempting to install the
.git/ directory of a git repository?

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] AUR problem: 403 for white_dune package

[Eli Schwartz via aur-general]

On 1/24/20 4:17 AM, J. Scheurich wrote:
> 
> Hi
>>> $ git clone ssh://a...@aur.archlinux.org/white_dune.git
>>> Cloning into 'white_dune'...
>>> a...@aur.archlinux.org: Permission denied (publickey).
>>> fatal: Could not read from remote repository.
>> Is your key added to the ssh-agent?
> $ cat ~/.ssh/config
>  Host aur.archlinux.org
>  User aur
>  PreferredAuthentications publickey
>  IdentityFile ~/.ssh/aur
>  AddKeysToAgent yes
> ...
> $ git push
> a...@aur.archlinux.org: Permission denied (publickey).
> fatal: Could not read from remote repository.
> 
> Please make sure you have the correct access rights
> $
> 
> Is this .ssh/config enough for ssh-agent ?

Are you sure your pubkey is added to your AUR profile?

What is the full output of the command:

ssh -v a...@aur.archlinux.org

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] AUR problem: 403 for white_dune package

[Eli Schwartz via aur-general]

On 1/23/20 11:10 PM, J.Scheurich wrote:
> Hi,
> 
> 
> When i try
> 
> $ git remote add white_dune ssh://a...@aur.archlinux.org/pkgbase.git
> $ git push
> fatal: unable to access 'https://aur.archlinux.org/white_dune.git/': The
> requested URL returned error: 403

the "white_dune" remote you just added is not the one you are pushing
to. git push by default pushes to the same remote you used "git clone" on.

You can try:
- re-cloning using ssh from the start
- "git remote set-url origin ssh://..." to update the default
  remote's url for pushing
- use "git push white_dune master" to push to the alternative remote

Also: why are you adding a remote with the literal value "pkgbase"?

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] EQ And Community Kindness

[Eli Schwartz via aur-general]

On 1/15/20 5:35 PM, Eli Schwartz wrote:
> On 1/15/20 4:17 PM, michael Bostwick via aur-general wrote:
>> Hi,
>> This is my first time writing the mailing list, to be honest I would
>> have preferred anther way of bringing this up, but *I didn't see an easy
>> way to bring my concern to someone who's empowered to fix this strong
>> comment or make it better.* I was looking into a package to solve a complex
>> programming task when I encountered a rather jarring pinned comment . (
>> https://aur.archlinux.org/packages/libc%2B%2B/#pinned-678768 )
> 
> [...]
> 
>> I really hope no one was banned by the writer of this comment, and I really
>> hope as trusted users in the future you guys would *be a little more kind*
>> to members of the aur community.  Many linux users may be familiar with
>> Linus Torvalds writings on his mistakes with EQ, I hope no one in aur has
>> to experience that.
>>
>> For those trusted AUR members that have been kind I say *thank you for your
>> hard work*, and for those that mean well but are harsh please keep in mind
>> when you see a package the first thing you see in the pinned comment (and
>> alot of context that is missed), and that speaks loudly to your impressions
>> of aur.
> 
> While there were indeed some good reasons to potentially ban certain
> participants on that AUR package, it seems like maybe there's some
> confusion here about who it was meant for.
> 
> I'd consider it reasonable to clarify it by e.g. adding a preamble:
> 
> "Hey people, sorry for the interruption if you're just an average AUR
> user doing their thing. But if you're one of the handful of people
> causing an utter ruckus here recently, I'm afraid we'll need to have a
> PSA. The rest of you can return to your regularly scheduled usage of the
> AUR."
> 
> The original comment was somewhat context-sensitive with regard to the
> actual content it addressed, which was indeed atrocious and deserved to
> be described as atrocious.

FWIW: I've updated that comment for clarity and tweaked wording, which I
hope now makes it a lot clearer what it is a response to (I ended up
making a couple more change than I had initially). Feedback is welcome.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Being an asshole to package maintainers is a bannable offense, and that's okay (Was: EQ And Community Kindness)

[Eli Schwartz via aur-general]

On 1/15/20 6:07 PM, Brett Cornwall wrote:
>> If you had moderator privileges on the AUR and could see the contents of
>> the deleted comments -- of which there are many -- I suspect you'd
>> rapidly understand why people are at the end of their tether.
> 
> 
> The only directly mean comment I see is one from 2018-09-30 where
> someone elegantly wrote:
> 
>> Stop beeing arrogant , and help, if not shut up! Sometimes
>> talk toa human is a lot better way of learning !
> 
> All the other comments seem to be the typical fare for those that expect
> Arch to support AUR helpers/make the experience "easier". Perhaps I
> missed some.

That one definitely hit a low point, yes, but there were a couple nearly
as bad, including (as I mentioned) the one calling the maintainer stupid
because the gpg key wasn't added to the PKGBUILD and needed to be
manually downloaded, claiming that the package was "added to manjaro"
because otherwise it's too hard to install.

> It appears that the pinned comment in question was indeed added after a
> small uptick in the undesirable comments. I have doubts as to whether it
> has actually stopped any sort of behavior - adding one more comment atop
> a pile doesn't seem effective to me, and comments have since occurred
> despite the new pin.
> 
> I'm not discounting the probable possibility that the maintainers
> received some nasty emails, but the deleted comments I can see are tame
> (if tiring to look through). The Arch Linux community has issues with
> interacting like human beings; however, I find the pinned comment in
> question to be tame (if colorful).
> 
>>> Many linux users may be familiar with
>>> Linus Torvalds writings on his mistakes with EQ, I hope no one in aur
>>> has
>>> to experience that.
>>
>> I'm not even sure I recognize the abbreviation "EQ", but given it's some
>> sort of Linus Torvalds reference I'm fairly positive no one has been
>> personally attacked or called names on that AUR page.
> 
> I came across https://en.wikipedia.org/wiki/Emotional_intelligence

That seems like a very complicated way to hide the words "lacking
empathy" behind vague scientific terms. Also either I suck at google, or
google sucks at me. :( Not only did I not recognize the term, I also
couldn't even resolve the abbreviation to the term.

>> Some people who were behaving very impolitely indeed, were given an
>> ultimatum that their behavior was not an acceptable way to treat people,
>> but more on that later.
>>
>> Hmm, I wonder: does that make me the champion of community kindness,
>> here? Is my attempt to enforce that, now being met with objections from
>> you, who would like to defend the right of users to be as offensive as
>> they want without having to suffer the consequences of being banned for
>> their behavior?
> 
> While I think that your pinned comment is acceptable, I'm not sure that
> deriding a user from trying to help the community is. I see where this
> is going, and it'd be good to just stop it now before it becomes another
> drama train.

I don't think this is actually the case, to be honest. It's just a
potential interpretation, if you look at things the wrong way and miss
context. Much like the AUR comment.

How do you distinguish between "user raises concern about TU sensitivity
to users and offers a role model from an unfortunately controversy-laden
source", and "user defends repeat abusers from justified banning through
the use of Linus Torvalds/Code of Conduct controversy comparison to
paint authority figures in a bad light"?

How do you distinguish between "moderator threatens harsh punishment for
people who break the rules after being warned", and "moderator threatens
to ban people for disagreeing with him"?

Perhaps we could all agree both that this thread was not intended in
malice to abet troublemakers, and that the AUR comment was not intended
in malice against users.

>> I have been kind... to the AUR package maintainer. This is more
>> important than being kind to users, because the package maintainer is
>> the one who does the work, and therefore we would like him to continue
>> doing the work rather than being chased away by ungrateful users heaping
>> abuse upon him because he wrote a PKGBUILD for software that takes a
>> while to compile, and users apparently hate maintainers that don't offer
>> instant gratification.

[...]

> Everyone in the world is in a consumption role at some point or another,
> including package maintainers. It's up to everyone to be civil - it's
> not "us" vs "them": For every one comment/email received from a
> bothersome user, ten/twenty other users are following rules and going
> about their day. It's like retail work: Lots of assholes abound in the
> public sphere, but not everyone's an asshole so don't treat them like one.

Right, I'm not saying it should be "us" vs. "them", merely that in a
case where the package maintainer and some consumers have already ended
up at odds, I think it's generally useful to side with the 

Re: [aur-general] EQ And Community Kindness

[Eli Schwartz via aur-general]

On 1/15/20 4:17 PM, michael Bostwick via aur-general wrote:
> Hi,
> This is my first time writing the mailing list, to be honest I would
> have preferred anther way of bringing this up, but *I didn't see an easy
> way to bring my concern to someone who's empowered to fix this strong
> comment or make it better.* I was looking into a package to solve a complex
> programming task when I encountered a rather jarring pinned comment . (
> https://aur.archlinux.org/packages/libc%2B%2B/#pinned-678768 )

[...]

> I really hope no one was banned by the writer of this comment, and I really
> hope as trusted users in the future you guys would *be a little more kind*
> to members of the aur community.  Many linux users may be familiar with
> Linus Torvalds writings on his mistakes with EQ, I hope no one in aur has
> to experience that.
> 
> For those trusted AUR members that have been kind I say *thank you for your
> hard work*, and for those that mean well but are harsh please keep in mind
> when you see a package the first thing you see in the pinned comment (and
> alot of context that is missed), and that speaks loudly to your impressions
> of aur.

While there were indeed some good reasons to potentially ban certain
participants on that AUR package, it seems like maybe there's some
confusion here about who it was meant for.

I'd consider it reasonable to clarify it by e.g. adding a preamble:

"Hey people, sorry for the interruption if you're just an average AUR
user doing their thing. But if you're one of the handful of people
causing an utter ruckus here recently, I'm afraid we'll need to have a
PSA. The rest of you can return to your regularly scheduled usage of the
AUR."

The original comment was somewhat context-sensitive with regard to the
actual content it addressed, which was indeed atrocious and deserved to
be described as atrocious.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

[aur-general] Being an asshole to package maintainers is a bannable offense, and that's okay (Was: EQ And Community Kindness)

[Eli Schwartz via aur-general]

On 1/15/20 4:17 PM, michael Bostwick via aur-general wrote:
> Hi,
> This is my first time writing the mailing list, to be honest I would
> have preferred anther way of bringing this up, but *I didn't see an easy
> way to bring my concern to someone who's empowered to fix this strong
> comment or make it better.* I was looking into a package to solve a complex
> programming task when I encountered a rather jarring pinned comment . (
> https://aur.archlinux.org/packages/libc%2B%2B/#pinned-678768 )
> 
> "
> Hi people, this is your regular reminder to SHUT UP about validpgpkeys
> checks and complaints about the fact that test suites exist.
> 
> This package is doing the correct thing, and there has been a great deal of
> pointless moaning and whining about it, but there is also multiple pinned
> comments explaining why every one of those complaints is not only null and
> void, but retroactively ridiculous.
> 
> The banhammer is ready and waiting in case you *still* want to ignore all
> this on top of the Trusted User warning."
> 
> I really hope no one was banned by the writer of this comment,and I really
> hope as trusted users in the future you guys would *be a little more kind*
> to members of the aur community.

The package in question has suffered to a very surprising degree from
tremendous quantities of abuse heaped upon the maintainer.

Since that pinned comment was added, users have stopped being mean to
the maintainer. As a result, no one has needed to be banned.

If you had moderator privileges on the AUR and could see the contents of
the deleted comments -- of which there are many -- I suspect you'd
rapidly understand why people are at the end of their tether.

> Many linux users may be familiar with
> Linus Torvalds writings on his mistakes with EQ, I hope no one in aur has
> to experience that.

I'm not even sure I recognize the abbreviation "EQ", but given it's some
sort of Linus Torvalds reference I'm fairly positive no one has been
personally attacked or called names on that AUR page.

Some people who were behaving very impolitely indeed, were given an
ultimatum that their behavior was not an acceptable way to treat people,
but more on that later.

Hmm, I wonder: does that make me the champion of community kindness,
here? Is my attempt to enforce that, now being met with objections from
you, who would like to defend the right of users to be as offensive as
they want without having to suffer the consequences of being banned for
their behavior?

> For those trusted AUR members that have been kind I say *thank you for your
> hard work*, and for those that mean well but are harsh please keep in mind
> when you see a package the first thing you see in the pinned comment (and
> alot of context that is missed), and that speaks loudly to your impressions
> of aur.
I have been kind... to the AUR package maintainer. This is more
important than being kind to users, because the package maintainer is
the one who does the work, and therefore we would like him to continue
doing the work rather than being chased away by ungrateful users heaping
abuse upon him because he wrote a PKGBUILD for software that takes a
while to compile, and users apparently hate maintainers that don't offer
instant gratification.

Futhermore: the so-called "unkindness" you speak of is simply a warning
stating that users are not permitted to complain about two very specific
things which are simultaneously correct to do *and* which the package
maintainer has very patiently explained the purpose of and the makepkg
options to disable them if the user optionally chooses that they don't
wish these things to happen.

Despite these very patient, thoughtful pinned comments by the package
maintainer, we would periodically have like ten comments in a row
discussing those two things, by people who did not read the pinned
comments and were upset that the package "doesn't work", calling the
maintainer stupid, demanding a binary repository for the package, or
simply derailing the comments with some discussion about their needing
to delete gpg.conf in order for the /usr/bin/gpg command to work.

Most people will not even see this warning, because they simply download
the PKGBUILD with an AUR helper and neither see existing comments nor
post their own.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] AUR Comment for white_dune

[Eli Schwartz via aur-general]

On 12/27/19 9:26 AM, J. Scheurich wrote:
> $ git remote set-url origin a...@aur.archlinux.org:white_dune.git
> $ git pull white_dune master
> ssh: Could not resolve hostname 2a01: Name or service not known
> fatal: Could not read from remote repository.
> 
> Please make sure you have the correct access rights
> and the repository exists.

Why did you set the remote url for "origin", then try to pull from
"white_dune"?

What is the "white_dune" remote?

Consider deleting your clone, re-cloning, and redoing your changes. It
might help you avoid confusing configurations.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] AUR Comment for white_dune

[Eli Schwartz via aur-general]

On 12/27/19 3:46 AM, J. Scheurich wrote:
> Hi,
> 
> I dont understand the following:
> 
> # Maintainer: J Scheurich 
> pkgname=white_dune
> pkgver=1.654
> pkgrel=1
> epoch=
> pkgdesc="white_dune X3D/VRML97 tool"
> arch=()
> url="ftp://ftp.ourproject.org/pub/wdune/$pkgname-$pkgver.tar.bz2;
> ...
> $ pkgname=white_dune
> $ pkgver=1.654
> $ wget "ftp://ftp.ourproject.org/pub/wdune/$pkgname-$pkgver.tar.bz2;
> --2019-12-27 09:36:02--
> ftp://ftp.ourproject.org/pub/wdune/white_dune-1.654.tar.bz2
>    => 'white_dune-1.654.tar.bz2'
> Resolving ftp.ourproject.org (ftp.ourproject.org)... 80.81.122.49
> Connecting to ftp.ourproject.org
> (ftp.ourproject.org)|80.81.122.49|:21... connected.
> Logging in as anonymous ... Logged in!
> ==> SYST ... done.    ==> PWD ... done.
> ==> TYPE I ... done.  ==> CWD (1) /pub/wdune ... done.
> ==> SIZE white_dune-1.654.tar.bz2 ... 24429987
> ==> PASV ... done.    ==> RETR white_dune-1.654.tar.bz2 ... done.
> Length: 24429987 (23M) (unauthoritative)
> 
> white_dune-1.654.ta 100%[===>]  23.30M 1.35MB/s    in 15s
> 
> 2019-12-27 09:36:19 (1.58 MB/s) - 'white_dune-1.654.tar.bz2' saved
> [24429987]
> 
> $ rm white_dune-1.654.tar.bz2
> $ updpkgsums
> ==> Retrieving sources...
> ==> ERROR: white_dune-1.654.tar.bz2 was not found in the build directory
> and is not a URL.
> ==> ERROR: Failed to generate new checksum
> 
> The URL exists, but updpkgsums refuses to read it...

Because "url" shows the homepage of the software, and has nothing to do
with the "source" to be downloaded.

I have no idea what you are trying to do here. What modifications have
you made to
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=white_dune ?

Have you fixed your ssh issue yet?

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] AUR Comment for white_dune

[Eli Schwartz via aur-general]

On 12/26/19 11:34 PM, J. Scheurich wrote:
> Hi,
>> Your remote URL looks wrong. You want to be using the username `aur`, not
>> `mufti`, and the format is not like the one used on the web interface.
>> I.e.
>>
>> git remote set-url origin a...@aur.archlinux.org:white_dune.git
>>
>> To change to the correct format so you can pull/push to and from the
>> repo.
> $ git push
> a...@aur.archlinux.org: Permission denied (publickey).
> fatal: Could not read from remote repository.
> 
> Please make sure you have the correct access rights
> and the repository exists.
> 
> How do i set the $HOME/.ssh/id_rsa.pub to AUR ?

Are you able to successfully run this command:

ssh -T a...@aur.archlinux.org

If not, you will need to fix your ssh setup until this works.

After that the AUR website will list a section for "Git Clone URL". If
you're the maintainer, it will mention an ssh url in addition to the
usual "https://... (read-only)".

Use that url.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Dropping official gitlab packages

[Eli Schwartz via aur-general]

On 12/25/19 5:31 PM, Sven-Hendrik Haase via aur-general wrote:
> On Wed, 25 Dec 2019 at 23:30, Karol Babioch via aur-general <
> aur-general@archlinux.org> wrote:
> 
>> Hi,
>>
>> Am 25.12.19 um 23:18 schrieb Anatol Pomozov via aur-general:
>>> I remember discussions about using gitlab to manage our (future) git
>>> repos. If we want to go this route then we need to keep gitlab in our
>>> repos.
>>
>> So is the recommendation for anyone currently using the packaged version
>> to migrate to the Docker image?
>>
>> Maybe this can be communicated accordingly, when no other maintainer can
>> be found.
>>
>> Best regards,
>> Karol Babioch
>>
>>
> We don't really have any system for communication for things like that in
> place except for this mailing list. What other mechanism do you imagine?

I'd argue arch-dev-public moreso than aur-general...

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Transition from split package to unsplit package

[Eli Schwartz via aur-general]

On 11/27/19 9:31 AM, Georg wrote:
> Hi list,
> 
> with the deprecation of Python2 ahead lots of packages currently built
> as split packages for py2/py3 will have to transition to non-split
> packages building only the py3 version, but this is not the only
> scenario when this could be needed.
> What is the correct workflow for this? It might depend on whether the
> pkgbase is the py2 vs py3 package vs another name (all cases exist).

I'm not sure I understand the question.

A PKGBUILD with a split package_*() and multiple pkgnames is just a way
to build multiple packages from one PKGBUILD. The resulting packages
aren't inherently tied together, and in fact, pacman -S doesn't even
know that they came from the same PKGBUILD. (Although libalpm does
record the original pkgbase, pacman doesn't use this information IIRC.)

You might need a transition if one resulting package takes over the
conceptual purpose of multiple packages from a previous revision. For
example:

https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/pygobject2=4cce72ee56cea6dcdb314a0a6c3066148390aaed

The legacy pygobject 2.x bindings were in a split package,
python-pygobject2 python2-pygobject2 and pygobject2-devel with common
files. But python-pygobject2 was totally broken, so we removed the
python3 support. It's a simple "remove the split package, no
replacements, no transitions, no nothing, it is just gone".

And then there was only python2-pygobject2 and pygobject2-devel. Since
only one package needed those development headers, the two split
packages could be combined into one. This does need a "transition",
simply because the old version of pygobject2-devel has *conflicting
files* with the new version of python2-pygobject2.

The transition was very simple, and it is the same transition if we
provided a package called "compton" and it died upstream and was
replaced by a new package called "picom". The transition has *nothing*
to do with the PKGBUILD that it came from, only the fact that one
package deprecates another.

- picom PKGBUILD:

provides=(compton)
conflicts=(compton)
replaces=(compton)

- pygobject2 PKGBUILD:

provides=("pygobject2-devel=$pkgver-$pkgrel")
conflicts=('pygobject2-devel')
replaces=('pygobject2-devel<=2.28.7-3')

Now, python2-pygobject2 is the only package, and to ensure that no one
is permitted to have the pygobject2-devel package, python2-pygobject2
will provide it (ensuring dependencies on the legacy pygobject2-devel
package are still met), conflict it (to force pacman to uninstall
pygobject2-devel while upgrading), and replace it (to make pacman
install python2-pygobject2 if you only had pygobject2-devel installed).

...

All these things apply regardless of whether the package was built from
one PKGBUILD or two PKGBUILDs.

...

For python2 packages which are dropped from the repos, pacman only knows
that the package is gone, and if you want to get it, you'll need to
install it from the AUR. AUR maintainers may take inspiration for
writing a new PKGBUILD, based on previous revisions of the one in the
official repos, but that is all.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Updating AUR versions server side

[Eli Schwartz via aur-general]

On 11/3/19 12:39 PM, Alberto Salvia Novella via aur-general wrote:
> What if regular, non development, AUR packages were tested server side
> for new versions?
> 
> Won't that make more sense than the maintainer having to run pkgver()
> manually from time to time?

We shall not evaluate user-uploaded shellscripts on the AUR server. Most
AUR helpers provide a --devel option to download packages with a
pkgver() function and check them for updates.

Non-development AUR packages are not permitted to change their version
just by running makepkg and having the pkgver() update it, since this
implies that the non-development AUR package uses VCS sources that are
not pinned to a specific commit or tag.

Please report such package violations for deletion or other corrective
measures.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] [PRQ#16499] Deletion Request for aur-git

[Eli Schwartz via aur-general]

On 10/30/19 4:38 PM, Alberto Salvia Novella via aur-general wrote:
> AUR:
>> Alad deleted aur-git:
>>
>> Why are you submitting this again after agreeing that a name change is
>> in order?
> 
> That was the original package which was there before the discussion, and
> only one day has passed.
> 
> I haven't had time that fast for thinking a new name and requesting a
> change, which I was planning to do this very week.

There's no grace period for a package which has been determined to be in
violation of our admittedly spur of the moment rules. Grace periods
exist only for the specific category of packages requests for orphaning
a package, since the current maintainer (usually) deserves the right to
justify their continued maintenance. And even that, we can resolve early.

I don't understand why, once we've decided such a name is too confusing,
we should put the rule on hold while you take the time to think of a new
name.

> I suggest that you make standard in Arch waiting a couple of days for
> feedback before making unilateral decisions.

We may make unilateral decisions whenever we want, subject only to
internal review by fellow team members. Unilateral decisions aren't a
bad thing and don't need to be cast in a negative light.

We held a meeting and a bunch of team members decided to carry out this
action with no active "no" votes -- no other feedback is needed, and
regular users don't get a vote. There is no point in waiting.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] aur client

[Eli Schwartz via aur-general]

On 10/29/19 1:22 PM, Giancarlo Razzolini wrote:
> Em outubro 29, 2019 14:09 Eli Schwartz via aur-general escreveu:
>>
>> Correction: there is "a blacklist", but it's only used to prevent
>> namespace conflicts for users who attempt to upload packages named the
>> same pkgname as a package in the binary repos.
>>
>> It is correct to say we have never attempted to blacklist names which
>> "shouldn't be allowed to exist as packages because $person dislikes the
>> name".
>>
>> "aur" isn't inherently a bad name, I could conceive of it being the name
>> for a package which installs the aur.archlinux.org software, though
>> "aurweb" would be an even better name. ;)
>>
> 
> Indeed, a there are two blacklists, one that blacklists repo packages, so
> they are not uploaded to the AUR. That one is updated automatically.
> 
> There's a second blacklist, but that one has no way to update, other than
> through the DB, hence my confusion.

Hence my confusion too... I did not realize we had another table.

> I think we should probably start adding a few packages to that list.

Makes sense, we have the functionality so we might as well use it. The
question is what criteria to use. :/

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] aur client

[Eli Schwartz via aur-general]

On 10/29/19 4:07 PM, Alberto Salvia Novella via aur-general wrote:
> Lukas Fleischer:
>> Another one is that we'd prefer you to not use a name that sounds very
>> official for a very unofficial project.
> That sounds reasonable in theory, but in practice it does nothing. The
> software does its work nicely, 

Hold on to those value judgments. Everyone likes to think their work
works nicely, but saying so isn't an intellectually meritorious argument
when discussing whether to make a rule or grant someone an exception to
a rule.

> and there's no official alternative that
> does such thing.

Well, there  is aurpublish, available in [community]. I think this is as
close to "official" for uploading packages to the AUR, as we're likely
to get.

(Disclaimer: I wrote aurpublish and think it is pretty nifty as far as
that goes.)

There shall never be an "official" way to download packages from the
AUR, however, other than "follow the clone or tarball links from the
webpage".

See point #2:
https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#Rules_for_Packages_Entering_the_[community]_Repo

> Plus being in the AUR implicitly suggests it's unofficial.

So I'm free to upload a package called "official-aur-helper", then?

> So it doesn't matter
> , it's
> just for the political correctness.

Saying the rules -- even brand new rules created in response to your
project -- "doesn't matter, it's just for political correctness" is not
a great way to convince anyone of things, IMO.

Your link talks about, essentially, "the perfect is the enemy of the
good enough". For example, a direct quote:

"Would these things be nice to have? Sure. Would they be great to have?
Sure. Would they be cool to have? You bet. But do they really matter?
Nope. And that’s why we left them out."

This is... not related to political correctness, and I would agree it's
not really worth implementing a blacklist just to deal with this, but
since we have a blacklist anyway, we can get the "cool to have" feature
of avoiding confusion with a pkgname="aur".

Your own link actually says we should block this package if it can be
trivially done without effort!

> I could name it "aup", but really,
> what's the deal? I simply thought that typing "aur get" would be more
> meaningful to the end user, but whatever.

What if the user tries typing 'aur sync', which is provided by the
'aurutils' package? Now we have two implementations of "aur", and they
don't correctly conflicts=() each other! At least one of them has its
own unique brand, though.
(It even has a logo:
https://github.com/AladW/aurutils/blob/master/06Nitori1.png)

> Another alternative is that you name what criteria such program shall
> meet to be considered official. And see if we can get to a common ground.

Now I'm genuinely confused. Are you asking for criteria for the sake of
getting your AUR helper to achieve the status of "official"?

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] aur client

[Eli Schwartz via aur-general]

On 10/29/19 1:06 PM, Giancarlo Razzolini via aur-general wrote:
> Em outubro 29, 2019 12:55 Loui Chang escreveu:
>>
>> Please rename your project to avoid confusion. I'm surprised that the
>> name
>> wasn't already blacklisted. I would hope some TU does add 'aur' to the
>> blacklist
>> of package names.
>>
> 
> There is no "blacklist". Having said that, I don't think that name is
> good at all.

Correction: there is "a blacklist", but it's only used to prevent
namespace conflicts for users who attempt to upload packages named the
same pkgname as a package in the binary repos.

It is correct to say we have never attempted to blacklist names which
"shouldn't be allowed to exist as packages because $person dislikes the
name".

"aur" isn't inherently a bad name, I could conceive of it being the name
for a package which installs the aur.archlinux.org software, though
"aurweb" would be an even better name. ;)

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] aur client

[Eli Schwartz via aur-general]

On 10/28/19 9:49 PM, Alberto Salvia Novella wrote:

What is with your email headers, and the waves of duplicated email I
just got.

To: Arch Linux - Announcements ,
 Arch Linux - General ,
 Arch Linux - Projects ,
 Arch Linux - AUR Development ,
 Arch Linux - AUR General 

Do you have a good reason for unsuccessfully trying to get past the
password filter on the arch-announce mailing list, which is only
permitted to be posted to by the www.archlinux.org server software
sending out notifications for the front-page news?

Do you have a good reason for trying to announce your AUR helper on the
arch-projects mailing list, which is self-described as:

"Development discussion, patches and pull requests for the Arch Linux
projects: dbscripts, devtools, mkinitcpio, namcap, netctl, archweb,
pyalpm. Please begin the email subject with the name of a project in
square brackets (e.g. [devtools]). If no project matches, use [projects]."

(Your email was, however, rejected from that list because the subject
header did not contain a tag for one of the official
https://git.archlinux.org projects.)

> Since publishing to the AUR is something that all packagers do quite
> frequently, I have developed a software that reduces the related
> operations to the bare minimum, making publishing to the AUR instant.
> 
> Basically it's a SMED 
> system. 

"Since packagers quite frequently package things, we need a way to help
people package things as utterly fast as possible, without wasting any
time at all."

This "SMED" thing seems to suggest that the most important thing for the
consumer industry is fast labor to produce (cookie-cutter?) products
more efficiently. Fine...

Why is this relevant to the AUR, which is a creative labor in which
uploads require a social contract of responsibility, that responsibility
being "I believe I have to the best of my abilities tried to avoid
uploading actual literal " as well as "the package
actually successfully builds on my machine"?

(Ideally the package successfully builds and runs in a makechrootpkg
clean-build container.)

Automation of boring trivia is not necessarily a bad thing, but it comes
across as rather funny (funny as in "weird, not funny as in "haha") when
your rationale brings positive reinforcement from a promotional video
about quantity over quality.

> The software is called "aur
> " itself, and you can check
> its manual out by in the terminal entering:

You're really shooting for the most impressive namespace here, I see. :)

I have looked at your AUR package, and it seems to also use another AUR
package you uploaded -- "silently-git", whose purpose is to run commands
and delete their stdout/stderr unless the command returns a fatal exit
code, in which case it only deletes stdout.

(Note it also uses badly escaped messages and eval, resulting in
incorrect commit messages for things that contain, say, quotes.)

This is utterly wrong, since makepkg can emit information on stderr at
loglevel "warning" (bold yellow "==> WARNING:" followed by some warning)
while also exiting with a successful return code, and users should make
sure that the warning does not denote something bad (sometimes it does).
More generally, I have certainly seen packages whose build systems
returned successfully -- and packaged nothing, or just packaged an
incomplete portion of the software -- due to incorrectly masking return
values of commands in their Makefile.

Especially if this is geared to people maintaining/uploading packages, I
have a hard time seeing this as anything other than a very bad goal to
begin with.

> curl --silent https://gitlab.com/es20490446e/aur/raw/master/assets/aur.1
>> aur.1; man ./aur.1; rm aur.1
> 
> As long as constructive, suggestions are very welcome. When replying
> please include my email address in the recipients list.

No, this is not how mailing lists work. You are posting here to start a
discussion, it's expected you subscribe to the discussion rather than
ask people to manually add your email address to Cc: (and then re-add it
every time it gets dropped by another poster). You are automatically
going to miss at least some responses (you have missed 100% of the
single response before mine). Please re-enable mail delivery for this
mailing list if you expect to have a discussion on it.

This is also not how feedback works. You don't get to say no one is
allowed to talk to you unless they agree with you, so let's not have
another of your mailing list threads where you claim everyone who
disagrees with you is being "not constructive" and therefore their
comments are "not welcome".

No one here is interested in a repetition of

https://lists.archlinux.org/pipermail/arch-general/2019-October/046991.html
https://lists.archlinux.org/pipermail/arch-general/2019-October/046999.html

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital 

Re: [aur-general] Doubt conflict array & request check PKGBUILDS

[Eli Schwartz via aur-general]

On 10/23/19 3:22 PM, Iyán Méndez Veiga wrote:
> Reading again your message I am still not quite sure you are right. It should 
> be possible to install both adwaita-qt and adwaita-qt4 at the same time so 
> both qt5 and qt4 apps use the theme.
> 
> Besides, adwaita-qt4 installs adwaita.so in /usr/lib/qt4/... while adwaita-qt 
> is in /usr/lib/qt/...
> 
> If you think you are right, then wiki should also be fixed:
> https://wiki.archlinux.org/index.php/
> Uniform_look_for_Qt_and_GTK_applications#Adwaita

No, you're entirely correct. My apologies. I guess I forgot that qt5
uses an unversioned install path whereas qt4 uses a versioned one -- on
the other hand, in self defense, qt4 doesn't exist in the official repos
anymore, so why should I concern myself with it or remember what it does? :D

(I am still kicking myself either way, don't worry.)

...

That being so, I think it would be fine to name it either adwaita-qt or
adwaita-qt5, but I still don't quite see the purpose in conflicting
against an alternative package name that should not exist. adwaita-qt4
can be its own unrelated package, I suppose.


-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Doubt conflict array & request check PKGBUILDS

[Eli Schwartz via aur-general]

On 10/16/19 4:22 PM, Iyán Méndez Veiga wrote:
> Hi,
> 
> I recently adopted two packages from AUR: adwaita-qt and adwaita-qt4. Today 
> @morealaz (who is maintaining adwaita-qt-git) asked me to edit some of the 
> arrays in the PKGBUILD (please read comments in the AUR website) and after 
> reading the wiki I did a commit with those little changes.
> 
> I am not sure if they are correct and he argues that I should a conflict 
> array. 
> Can someone have a look at these two (three) PKGBUILDS and tell me if I 
> should 
> change something and why?

Each version of adwaita-qt will install a single file IIRC, that file
being /usr/lib/qt/plugins/styles/adwaita.so

Thus, logically, one cannot install both the Qt4 and Qt5 versions
simultaneously, because the packages will error out with a conflicting
files message.

The solution is simple, and in accordance with long-standing package
policy, adwaita-qt is the "main" package, and all other packages must
provide/conflict against it. For more details, see:
https://wiki.archlinux.org/index.php/PKGBUILD#conflicts

The adwaita-qt5 name is different, since it is what this package used to
be called, and if anyone depends on "adwaita-qt5" which does not exist,
this package must provide that dependency.

(Some people might argue that the package should be called adwaita-qt5
anyway. It would match the naming for other qt5-* packages then.)

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application: kpcyrd

[Eli Schwartz via aur-general]

On 10/11/19 4:27 PM, Levente Polyak via aur-general wrote:
> On 9/20/19 10:09 PM, kpcyrd wrote:
>> Hello,
>>
>> My name is kpcyrd and I'm applying to become a Trusted User with anthraxx', 
>> sangys and jelles sponsorship.
>>
> 
> The voting period is over and we have a result:
> 
> Yes: 39
> No: 4
> Abstain: 6
> Participation: 87.50% (meets the quorum)
> 
> I'm happily hereby announcing: Welcome to the team! :)
> 
> 
> Please read and proceed with:
> https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_for_new_Trusted_Users.

Welcome! I've updated your bugtracker account to grant you Trusted User
status for the Community Packages project, and made you a member of our
internal Keyring project.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application: kpcyrd

[Eli Schwartz via aur-general]

On 10/7/19 10:59 AM, Levente Polyak via aur-general wrote:
> On 10/4/19 9:29 PM, Santiago Torres-Arias via aur-general wrote:
>> Hi,
>>
>> It's been 15 days (and a couple of hours as I'm aware) since, so the
>> vote starts now:
>>
>> https://aur.archlinux.org/tu/?id=119
>>
> 
> 
> Reminder, only 4 days left (aur vote notifications seem to be broken
> right now).

Nah, notifications only get sent once every 12 hours, and only for votes
that are ending in the next 48 hours.

It seems a bit overkill to send notifications every 12 hours for the
majority of the voting period (3 days in, 4 left to go?)

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] package-base PKGBUILD with different architecture list for packages inside

[Eli Schwartz via aur-general]

On 10/5/19 7:48 AM, Attila Greguss via aur-general wrote:
> Hello,
> 
> I have a PKGBUILD Here
> 
> 
> Is there a way to enable the commented out package in the PKGBUILD without
> said package blocking the installation of the other packages on the
> architecture it does not support?
> I'm OK with splitting it out, but I thought I ask first if because I don't
> know the capabilities of PKGBUILD/makepkg.
> 
> Some (not necessary) context:
> Package is for dotnet, and the source archive includes dotnet-host,
> dotnet-runtime, aspnet-runtime, dotnet-sdk for x86_64 and armv7h. For
> aarch64 it does NOT contain aspnet-runtime files, but all the rest.

Yes, and it is also repackaging someone else's prebuilt binaries instead
of building from source (and the source code is available). Is there a
reason the package name does not include the word "bin" in it?

Also generally why not just build from source, exactly like the
unversioned package in [community]?

> I tried to specify the architecture list for aspnet-runtime in the
> PKGBUILD, but if someone tries to install any of the other packages on
> aarch64 it will fail. (see commented out part in file)

Well, no it won't fail. What will fail is trying to build it in the
first place, since adding a split package whose list of arches is
smaller than the global arch=() list is a broken concept. The first
thing makepkg will do is check if all packages contain valid metadata,
and on aarch64 it will refuse to even try to build anything at all,
because it can tell it won't work.

Building from source would fix this, since I assume the source code
supports aarch64?

...

I would like to know how this was ever a problem. Did you not try to
build the package for aarch64 before uploading it?

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application: Jonas Witschel (diabonas)

[Eli Schwartz via aur-general]

On 9/26/19 1:49 PM, Bruno Pagani via aur-general wrote:
> Vote is now over too, and the results are in:
> 
> Yes: 42
> No: 1
> Abstain: 8
> 
> So, with a participation of 91.07% that meets the quorum, I can now say
> “Welcome in the team!”.
> 
> You can now proceed with
> https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_for_new_Trusted_Users.

Congratulations, and welcome! :)

I've granted your bugtracker account the necessary permissions in the
"Community Packages" and internal "Keyring" project, and there is now a
Keyring ticket open for your key: https://bugs.archlinux.org/task/63926
(I have added you to the notifications for this ticket.)

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Why keeping OpenRC related packages on AUR?

[Eli Schwartz via aur-general]

On 9/16/19 12:38 PM, fredbezies via aur-general wrote:
> Indeed! I just remember some manjaro related packages to be deleted
> because they were using manjaro dependencies in some ways.

Well, if the package in question can only be run on Manjaro (or only
makes sense to run on manjaro), then that is probably an issue. On the
other hand, we encourage users of derivative distributions to contribute
to the AUR as long as their contributions are also able to be used on
Arch Linux.

For example, https://aur.archlinux.org/packages/?K=manjaro

These are mostly themes, but nothing says they cannot be used on Arch
Linux too.

And many AUR maintainers add archlinuxarm support for their packages (in
fact, I do this for pacman-git myself) -- as long as it *also* compiles
for x86_64, this is fine.

Some parabola users historically maintained e.g. linux-libre -- this is
fine too, Arch users can run this kernel if they want, it's a valid
kernel...

> Some projects are directly based on these technologies, providing
> their own repository. I thought it was simpler to use directly ISO
> from these projects.

But maybe someone wants to use those technologies with Arch. :)

>> What matters is that you built up your system from Arch Linux, and any
>> deviations from the official Arch Linux repositories are achieved by
>> your own labor, which you understand. (Do not try to use this as an
>> excuse to get support for Manjaro, Artix, or Parabola, you will get banned.)
> 
> I won't ask any support for any of these distributions, even if I'm
> using one of them on my old laptop.
> 
> I'm a 10 years long Archlinux user, who had known Archlinux 0.7x
> ISO... Good old /etc/rc.conf times... Or not!

Then you are entitled to Arch Linux support for those Arch systems,
regardless of which AUR packages you install on them (even the ones
which bring back /etc/rc.conf). ;)

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Why keeping OpenRC related packages on AUR?

[Eli Schwartz via aur-general]

On 9/16/19 10:38 AM, fredbezies via aur-general wrote:
> Hello.
> 
> Note: posting in the right mailing list now. Oops!
> 
> I hope it is the right place to discuss about this issue. I noticed
> there is a lot of OpenRC related packages on AUR. I don't want to
> start a flamewar, I just want to know what is going on with these
> PKGBUILDs.
> 
> A quick search gave me 42 answers - some not related to this init
> system - 95% of them last updated between 2015 and 2018.
> 
> https://aur.archlinux.org/packages/?O=0=openrc

openrc-git and openrc-arch-services-git are, in fact, git packages, so
it doesn't matter if they haven't been updated since 2015.
openrc-sysvinit is hardly receiving daily updates, so likewise it's
entirely reasonable to be an old package.

Is it flagged out of date? No? I think we call that "stable software
that works". :)

Only two of the openrc-related packages are flagged out of date for any
significant time. Feel free to request something be done about
strongswan-nosystemd and docker-openrc-scripts-git.

> Is there any interest of keeping these PKGBUILDs? There is an official
> Archlinux + OpenRC init system called Artix, providing a migration
> guide from Arch or Manjaro.

One of the core archlinux developers is the maintainer of openrc and
openrc-sysvinit (and openrc-git). One assumes this is not against the rules.
https://www.archlinux.org/people/developers/#andrew

As for "interest", the AUR is not in the business of determining whether
there is "interest" in a package. Our submission guidelines state that
packages must be useful enough that other users *may* be interested in
it, a criterion that is graded on good faith. Well, openrc is obviously
useful enough for other distributions to base themselves on it, so it is
clearly not software that is specific to one person that cannot be
feasibly expected to be used by others.

> It is also listed in
> https://wiki.archlinux.org/index.php/Arch-based_distributions#Active
> 
> "Artix Linux *2016, previously Arch-OpenRC"
> 
> https://artixlinux.org/
> https://wiki.artixlinux.org/Main/Migration

Artix Linux may be based on Arch with openrc, but Manjaro Linux is based
on Arch with systemd. Does that mean that it is forbidden for Arch users
to use systemd, because it is also used by a derivative? No, that would
be an extremely foolish idea.

No one cares if another distribution uses something. We only care if
Arch Linux could potentially use it. If so, it is useful.

Arch Linux is a distribution that people make into what they want it to
be. This stuff is definitely useful to at least some people. We will not
play politics and tell people that they're not allowed to publicly
experiment with different init systems -- we will simply refrain from
pushing that into [core], and expect them to make a good-faith effort in
the forums to alert people regarding their unique configurations.

> By the way, it is written in the wiki that : "Warning: Arch Linux only
> has official support for systemd. When using OpenRC, please mention so
> in support requests."
> 
> Source: https://wiki.archlinux.org/index.php/OpenRC
> 
> Is there any explanations for keeping them?
> 
> Thanks for your answers.

So, the wiki explicitly clarifies that one is permitted to use openrc
and if you do use openrc you are still eligible to receive help in the
official support forums (as long as you let people know you are using it).

The context of this is that if you install Arch Linux according to the
Arch Way, then you are running Arch Linux... even if you later go ahead
and install a custom kernel, or systemd-git. It is really no different
if you go ahead and install linux-libre, openrc, and whatever other
special interests packages you want to replace core system components.
What matters is that you built up your system from Arch Linux, and any
deviations from the official Arch Linux repositories are achieved by
your own labor, which you understand. (Do not try to use this as an
excuse to get support for Manjaro, Artix, or Parabola, you will get banned.)

I am therefore unsure why you think we need an "explanation" for keeping
them, as though it is some sort of dirty secret and we need to air the
laundry and demand explanations from the "guilty parties" via some form
of mob-with-pitchfork mentality.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application: Jonas Witschel (diabonas)

[Eli Schwartz via aur-general]

On 9/5/19 11:23 AM, Jonas Witschel wrote:
> Hi all,
> 
> my name is Jonas Witschel (online nick "diabonas" on the
> AUR/GitHub/GitLab/...) and I am applying as an Arch Linux Trusted User
> under the sponsorship of Bruno Pagani and Alad Wenter.
> 
> A few words about myself: I am a math PhD student and long-time Linux
> user. I switched to Arch Linux around 2016 because I like the idea of a
> rolling release distribution that stays close to upstream, which is
> especially beneficial when doing software development. I got more
> actively involved in contributing to Arch when the previous AUR
> maintainer of the tpm2-software stack (tpm2-tss, tpm2-abrmd and
> tpm2-tools) orphaned these packages, so I took over maintenance until
> they were adopted to [community].
> 
> I am interested in many security-related thing such as Secure Boot,
> Trusted Platform Modules (TPMs), disk encryption, PGP, ... As such, I am
> a member of the tpm2-software organisation and a maintainer of tpm2-totp
> [1]. Recently I have been working on getting Web Key Directory support
> into pacman for fetching PGP keys independently of the key server
> network [2,3]. A repository of all my AUR packages can be found on
> Gitlab [4].

I notice you use my aurpublish routine, so this automatically gets a +1
from me. :D

Also, your attempts to get WKD into pacman are awesome. I love to see
prospective TUs who take an interest in improving the packaging
toolchain! <3

> If I were accepted as a trusted user, I would take over maintenance of
> the tpm2-software stack from my sponsor Bruno Pagani. This makes sense
> since I am an upstream member of tpm2-software anyway and had been
> maintaining these packages until they were adopted to [community].
> Another long-time goal as a trusted user would be getting out of the box
> Secure Boot support for the Arch Linux installation images [5,6].
> 
> Packages I would like to adopt from the AUR to [community] for starters are:
> 
> - The rest of the tpm2-software stack: tpm2-tss-engine and tpm2-totp
> (when they have reached the 1% usage from pkgstats/10 votes on the AUR
> threshold), tpm2-pkcs11-git (as soon as it gets a release).
> - clevis and tang (and their dependencies jose, luksmeta)
> - sbupdate-git (I need to speak to upstream about making a release first)
> - paperkey
> - cryptomator
> - deheader
> - texworks
> - pdftk-java (an exact Java reimplementation of the very popular
> pdftk/pdftk-bin, which is hard to package since it relies on an outdated
> version of GCC)
> 
> I am looking forward to working with you and welcome any questions and
> comments!
> 
> Cheers,
> Jonas
> 
> [1] https://github.com/tpm2-software/tpm2-totp
> [2] https://bugs.archlinux.org/task/63171
> [3] https://lists.archlinux.org/pipermail/pacman-dev/2019-July/023493.html
> [4] https://gitlab.com/diabonas/aur-packages
> [5] https://bugs.archlinux.org/task/53864
> [6]
> https://lists.archlinux.org/pipermail/arch-releng/2019-January/003891.html
> 


-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] New package: disklow

[Eli Schwartz via aur-general]

On 9/2/19 6:50 AM, Khorne via aur-general wrote:

> Few style things:
> - remove unused directives
> - packages always provide themselves

Or as I prefer to describe it:

Packages cannot logically provide themselves, they already *are* themselves.

> More importantly it seems to me that you switched url and source
> around. The source array is used to define where to find (and
> potentially download) the sources. The url array is just a general
> hint, for example to an upstream project page.
> 
> As it stands, the pkgbuild assumes the sources to be in cwd as a
> file. If that's intentional, carry on.

The url points to a valid prebuilt *.pkg.tar.xz, so that's not really a
"source" either.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] New package: disklow

[Eli Schwartz via aur-general]

On 9/2/19 7:31 AM, Holger Jahn wrote:
> Hi Daniel,
> 
> Thanks for your review.
> 
>> You'll need to install the PerlArtistic license.
> 
> What exactly do you mean by "install the license"? Put a copy of it into
> the package?

core/licenses provides /usr/share/licenses/common/PerlArtistic/license.txt

If you were actually in need of installing the license, then you would
do so in accordance with
https://wiki.archlinux.org/index.php/PKGBUILD#license


>> This may be a small tool, but you're not really supposed to host the
>> source code in the AUR. It should be hosted elsewhere and downloaded.
> 
> The payload code is one Perl script with 1400+ lines.
> 
> For brevity's sake I am trying to keep it in one package, but if the
> community rules dictate to split it into PKGBUILD & source, then so be it.

The AUR graciously provides hosting for build recipes (PKGBUILD) and
additional files needed for packaging (desktop files, those tiny
shellscript wrappers which the java ecosystem is accursed with, kernel
.config files, systemd units if upstream doesn't provide them, etc).

The AUR does not provide source code hosting, on the grounds that other
places like Github, Gitlab, git.sr.ht, amd so on are doing it better.
Moreover, source code hosting is a resource burden on the provider,
which in our case we do not have either a business or community
rationale for accepting. (Again: we provide hosting for build recipes,
because build recipes are something specific to Arch).

We actually have a rudimentary enforcement method in the form of an
upload validation script that will reject packages containing files
which are "too big" and therefore seem like they cross the line from
packaging files to source code.

...

More generally, why would you upload your project in a way that is
targeted exclusively for Arch users? What if users of a different distro
wanted to use your software?

And, regardless of where you host it, why would you upload it as a
tarball checked into git? git already has excellent deduplication
algorithms and the ability to diff versions of a file, but it is geared
to text and is kind of terrible at handling often-changing binary files
like a gzipped tarball. Over time, a repo containing tarballs will
balloon in size.

>> MD5 is old (and, some would argue, busted). Prefer SHA1, or better,
>> SHA256.
> 
> I wrote a little build script in order to wrap everything into the
> package itself. The script uses
> 
> makepkg -g >> PKGBUILD
> 
> which produces the md5sums array. How do I get it to use something else
> than md5sum? Simply roll my own by using sha256sum?

makepkg -g will generate new checksums for a PKGBUILD, using all the
current checksum algorithms listed in the PKGBUILD, or, if there are
none, using the INTEGRITY_CHECK setting in makepkg.conf

The INTEGRITY_CHECK defaults to md5.

...

Aside: using makepkg -g >> PKGBUILD will lead to repeatedly appending
checksum lines, which you will need to edit in order to remove old
versions. The updpkgsums script from pacman-contrib will use makepkg -g
in order to update checksums in-place.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Deletion request for ipython

[Eli Schwartz via aur-general]

On 8/29/19 5:35 AM, asm0dey via aur-general wrote:
> 2. Comments are absolutely random, but… I just think that when there
> are no important changes in repository, just version bumps then no
> comment can make sense. Of course I'm absolutely ready to rewrite
> history to make them just normal boring comments.

So relay that relevant information.

git commit -m 'upstream release'

(https://www.archlinux.org/packages/community/any/aurpublish/ will even
cleverly insert this exact commit message for you, if it detects a
pkgver bump.)

Instead of using commit messages which relay the message "I consider
both myself and my packages to be a laughingstock, useful only for
providing demented humor by way of insulting my own intelligence".

...

Do you even realize that site is *satire*?

...

Your claim that there is "just version bumps" is factually incorrect:

https://aur.archlinux.org/cgit/aur.git/commit/PKGBUILD?h=ipython-7=42c1ff5d25a9ddc034154b5651483076658b6ec5


-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU membership application

[Eli Schwartz via aur-general]

On 8/18/19 12:26 AM, Santiago Torres-Arias wrote:
>>> - This appears to me it's a -bin package
>>
>> Why? It looks like some sort of standard js-based source package on the
>> NPM registry.
>>
> 
> well, judging from the lack of build() I'd assume so. I'm not too
> familiar with npm, but if t is running build commands (as you concede
> down in the email it may be happening) then that probably should happen
> inside of build()?

That's what I do for rapydscript-ng. If you try to npm install in
build() and then npm install --prefix="$pkgdir/usr" in package(), I'm
pretty sure it will just build a second copy all over again, during the
package() step.

Repeat after me: "curse you, npm".

It is very, very, very difficult to provide meaningful criticism of an
npm PKGBUILD. There aren't a lot of options when it comes to packaging
this language.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU membership application

[Eli Schwartz via aur-general]

On 8/17/19 10:51 PM, Santiago Torres-Arias via aur-general wrote:
> On Fri, Aug 16, 2019 at 03:19:56PM -0400, Jean Lucas via aur-general wrote:
>> Hi all,
>>
>> Thank you for your time, and thank you to all who help make Arch a great OS!
> 
> Always happy to help! :)
> 
> It's customary to review PKGBUILDS for new applicants.  This is somewhat
> of a quick/cursory review over 3 random packages as I've been in
> conferences for the whole week.

I haven't looked at Jean's packages myself, but I'm not sure some of
these things you point to are actually problems.


> 
> == Overall ==
> 
> - It appears you need quote strings way more everywhere, from deps, to 
> licenses
>   to variables

Quote strings are only necessary for variable expansions which could
potentially undergo word splitting. For declaring an array (deps,
licenses) it's completely unnecessary as you know when writing the
PKGBUILD if there are spaces (and most makepkg fields don't permit
spaces anyway).

Admittedly I think single-quoting array keys looks prettier. That's a
personal opinion though.

> - Consider that base-devel is assumed to exist for makedepends and (iirc).

This is not great if it is in makedepends, but honestly we still haven't
fully fixed the official repos for this.

> == Beaker ==
> 
> - This depends array has to be wrong
> - This makedepends array too. you should make sure things aren't depending on
>   py2 anymore

What's necessarily wrong with this? I don't like py2 either, but just
because something uses it doesn't mean it has no reason to. What
specifically made you think it isn't needed?

What is wrong with the dependencies that it "must" be wrong? From a
cursory inspection it seems to be some sort of electron thingy, which
would hopefully use community/electron but life isn't perfect.

Depending on glibc and gcc-libs is a bikeshed topic that TUs/Devs don't
agree on. The rest of the dependencies could plausibly be linked to by
whichever version of prebuilt electron is being downloaded by the build
system.

> - I'm also a little confused, did you take over the namespace of another
>   project called beaker? Why not just call this beaker browser?
> 
> == Oxy ==
> 
> - I think you should document why you're cherry-picking that commit rather 
> than
>   using a tag. Admittedly this is probably upstream's fault, but still, better
>   to be clear.

Upstream is amazing and doesn't use git tag. The cherry-picked commit
has the commit message "Call it a version". This is obvious enough
causes that I don't actually feel bad about the lack of comments. :)

> - Again, I think your depends are either too verbose or wrong.  

There's exactly one depends, which is gcc-libs. Again, a bikeshed topic.
I will loudly proclaim my own belief in not depending on gcc-libs or
anything else in *base*, but I won't tell anyone they are *wrong* for
doing so themselves.

(Obviously makedepends on base-devel is still against the packaging
guidelines.)

> == stf ==
> 
> - This appears to me it's a -bin package

Why? It looks like some sort of standard js-based source package on the
NPM registry.

> - npm -i -g --prefix seems like a good way to overwrite a bunch of system 
> files
>   and/or cause a bunch of file conflicts

npm install -g --prefix="$pkgdir" is actually how you are supposed to
install npm stuff -- it "globally" installs it to the packaging
directory so that pacman will install it to /usr, so it should never
conflict with anything. This seems fine to me.

(I have personal issues with npm as a technology, and prefer to npm
install into $srcdir then use cp because it feels at least mildly
cleaner -- see my rapydscript-ng package -- but stf doesn't seem any
less valid and some official packages do the same thing he does).


> - I think you can use $pkgname more often, namely when resolving the url and
>   resolving the tgz file

I've seen it both ways extremely often. I think some people actually
insist on hardcoding $pkgname everywhere, because they want to preserve
the possibility of users forking the PKGBUILD, modifying the pkgname,
and still have everything work without having to fix up all pkgname
references.

> - I'm curious to know where you got those depends arays, they seem to be a
>   little off... do you really need python, graphicksmagic and protobuf to
>   basically extract a tarball?

Not to extract a tarball. This is npm. It's not just extracting a
tarball, it is also probably downloading half the internet during build,
and maybe compiling G-d-knows-what after the unauthenticated download.
Because npm. And npm sucks. But the package itself seems fine, and I'd
need to actually look in depth at the build in order to decide if those
makedepends raise a red flag.

> - I'm also not sure why *everything* is just blindly put on /usr

It's not? npm install (like make install except that npm is obviously
terrible because javascript desktop programming) is responsible when
given --prefix="$pkgdir/usr" to place "everything" in the 

Re: [aur-general] TU membership application

[Eli Schwartz via aur-general]

On 8/17/19 2:49 PM, Jean Lucas via aur-general wrote:
> That said, I think its a bit unfair to say that I went off and found
> another sponsor without batting an eye - asking Alexander and Sergej
> seemed appropriate as they'd both adopted one of my packages, I had
> worked with you to resolve some of my issues, I've gone over all of my
> packages with a fine-toothed comb many times now, and got more help as
> needed. I didn't suppose that having you decline sponsorship should
> deter me from eventually applying until getting your approval. I
> regret that we didn't have better communication, though.

I don't see anyone implying you aren't allowed to apply until the person
who declined to sponsor you says it is okay.

All that anyone is saying is that you're supposed to provide fair
disclosure of the fact that it happened.


On 8/17/19 6:59 PM, Jean Lucas via aur-general wrote:
> On Sat, 2019-08-17 at 21:58 +0200, Robin Broda wrote:
>> On 8/17/19 8:49 PM, Jean Lucas wrote:
>>> In totality, I asked 4 TUs - Alexander, Sergej, Alad, and you.
>>
>> Why did you not make this clear in your application?
> 
> Since there is no formal guideline for writing an application AFAICT, I
> thought it sufficient to include the names of those who agreed to
> sponsor me.
> 
>>
>> I'm sure you've read the wiki article on Trusted Users[1] -
>>> *Note*: Should the TU you contact decline to sponsor your
>>> application,
>>> you should make this fact known if you seek sponsorship from
>>> another TU.
>>
>> Have you at least told xyproto & sergej that you have approached alad
>> and me,
>> and the reason for me declining sponsorship?
> 
> I have not. I contacted Alexander before you something like 2 months
> ago, and your formal refusal for sponsorship came in about 2 weeks
> later. Admittedly, I forgot to mention that you'd declined my
> sponsorship to both of them.

Hmm, did you contact him about sponsorship, specifically? You say that
he offered to sponsor you "after a few chat sessions", and that your
first contact with him (about him adopting your package) was before your
first contact with Robin. If you only contacted him about sponsorship
after Robin declined, I'm not even sure why it is relevant if you
contacted Alexander about unrelated things. If you were in discussion
with Alexander about sponsorship before you asked Robin, I could at
least understand how such forgetfulness happened.


On 8/17/19 8:46 PM, Jean Lucas via aur-general wrote:
> For the record, it says "Should the TU you contact decline to sponsor
> your application, you should make this fact known if you seek
> sponsorship from another TU." - that should be reworded to something
> similar to what you said instead, given the recent amendment to the TU
> bylaws of needing two sponsors instead of one.
>
> Either way, I had forgotten about that part, so I failed to bring it
> up with the TUs I was in contact with. My apologies. In hindsight, it
> would've been a pragmatic idea.

I... really don't see what is confusing or ambiguous about the wiki? My
reading of the wiki does not say that you must acknowledge it to the
whole world on this mailing list (it may or may not be a good idea to do
so) but you sure had better acknowledge this to the TUs who you later
approach for sponsorship. At least in that much, the wiki is very, very
clear.

I think it's more than pragmatic. It's required. It's a matter of trust:
you want the community to trust you and put you in a position where a
great many Arch users trust you by default, and part of that is that if
someone had objections in the past to your being on the team, then you
should at least let your sponsors know the position you are in, which
you are asking them to stake their reputation on. They will want to have
the opportunity to evaluate and hopefully decide that those reasons no
longer apply (or they disagree with the other prospective sponsor's
reasoning, which is also okay, because we are allowed to have
differences of opinion).

Frankly, even if it wasn't an official rule of the application process,
I would still consider it to be common courtesy.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] kodi-devel-bin

[Eli Schwartz via aur-general]

On 8/17/19 5:30 AM, Ike Devolder wrote:
> On 12/08/2019 20:18, Eli Schwartz wrote:
>> @Ike,
>>
>> I'm curious what made you choose to call it "kodi-bin" instead of what
>> seems to me like the more descriptive and accurate "kodi-x11". Perhaps
>> it might make sense to change the pkgname?
> 
> kodi-bin was chosen to have kodi-x11 as the default, if all "bin"
> packages provide kodi-bin and kodi depends on "kodi-bin", by default
> there would be kodi-gdbm installed, which most people can't actually
> use. So by having kodi-bin as an actual package which holds kodi-x11
> that is still most used, users of kodi-wayland or kodi-gdbm can install
> those alongside or alone to suit there needs.

You mean, that they would be interactively requested to press "1", "2",
or "3" -- and if they simply press enter without even reading the
console, then they would get gbm. I guess your concern is that pacman
doesn't have a mechanism for choosing which is the default provider when
the user doesn't pay attention to pacman? But I don't see why we should
care about such users.

On the other hand, it seems like the current mechanism means that kodi's
X11 executable will always be installed, and users won't even know that
they have the option to install a wayland version. So in order to make
it work only on X11 without requiring the user to pay attention to what
they are installing, you made it... broken on not-X11?

Given the precise nature of the tradeoffs, I recommend renaming the
package to kodi-x11 so that users at least have a way to know why their
package doesn't actually work because they dared to use wayland, then
depending directly on kodi-x11 and not some provides. Then add
kodi-wayland and kodi-gbm as optdepends so they know what to install
instead if they need it.

Alternatively, fix the Kodi page on the Arch Wiki to recommend
installing the actual package "kodi-x11"/"kodi-gbm"/"kodi-wayland"
instead of "kodi", which will *also* work fine, pull in kodi as a
dependency and satisfy the kodi-bin dependency provider without
requiring any sort of interactive prompt, and which is frankly a lot
more intuitive. This would seem to solve the best of every world,
without creating trick package names and unworking installs for people
who just installed "kodi" and now have no idea why kodi "doesn't support
wayland".

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU membership application

[Eli Schwartz via aur-general]

On 8/16/19 3:19 PM, Jean Lucas via aur-general wrote:
> Hi all,
> 
> My name is Jean Lucas, and I'm sending this email to submit my candidacy
> for Trusted User member. As per the latest TU bylaws, I'm being
> sponsored by both Alexander Rødseth and Sergej Pupykin.
> 
> I've been an Arch Linux user since around a little before I registered
> my AUR account (January 2015, username "flacks" [1]), and I've recently
> had a few of my packages adopted into [community], namely "cage",
> "coturn", and "swaybg".
> 
> I'm currently a computer science student with a particular interest in
> software engineering ranging from low-level (with a few contributions to
> projects like coreboot and postmarketOS) all the way up to web
> development (my current focus), and as such, would love to help maintain
> Arch's [community] repo in an official capacity to be part of the team
> that gives Arch users a robust, high-quality Linux software experience;
> as well as to help maintain, manage, and watch over the operation of the
> AUR and it's vast sea of software packaging recipes.
> 
> If I were accepted to become a TU, I'd like to adopt and move the
> following packages (all having over 10 votes in the AUR) from the AUR
> into [community]:
> 
> anydesk, downgrade, exercism, flutter, godot, itch, mattermost-desktop,
> nvm, reaper, spotify, teamviewer, thermald, unity-editor, and unityhub,
> for starters!

In the case of Spotify specifically, the AUR maintainer is already a TU,
and had you asked him before being eager to move it to community he'd
have probably told you that you're not the first or even the second (or
third? I lose track) person to propose moving it.
I think someone may have also suggested it in a TU application before...

Either way you should definitely ask the maintainer if it is okay to
move it to community. If that maintainer is a TU, and they haven't moved
it to community on their own, there is probably a reason.

downgrade:

I'm quite hesitant to have "downgrade" in the repos, it seems to be an
immense antipattern --  not quite as bad as an AUR helper in[community],
but nearly. Also isn't even well written as it does a ton of parsing
HTML files and pacman.conf in sed, instead of using either pacman-conf
or an HTML parser. I really wish that people who wrote complex
integrations around pacman/makepkg would follow pacman development -- in
fact, many of the current crop of AUR helpers do exactly that, which is
why I would even dare use some of them.

If we *were* going to add a program to pander to the desire to have
partially updated systems, I would prefer to create a new tool from scratch.

Also "downgrade" indexing archive.archlinux.org (with sed or anything
else) is problematic due to the fact that we no longer store many
versions of packages but upload them to archive.org and delete them from
our own server (and use rewrite rules to let users download the files,
but that doesn't help to build an HTML index). So I'm decidedly unsure
how useful it's supposed to be even at fulfilling its desired goal.

> Additionally, I would express my willingness to help co-maintain
> "firejail" (already in [community]), as its a project I have a higher
> interest in and contribute to occasionally; as well as to help get
> "ghidra" in good enough shape to propose moving it into [community],
> since I've had lots of fun building it [2], its a phenomenal piece of
> open-source software, and it'd be nice to have it officially supported
> by the Arch community (it also has a nice number of votes in the AUR)!
> 
> Thank you for your time, and thank you to all who help make Arch a great OS!
> 
> 
> Best regards,
> 
> Jean Lucas
> 
> 
> [1] https://aur.archlinux.org/account/flacks
> [2] https://aur.archlinux.org/cgit/aur.git/log/?h=ghidra-git
> 


-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Custom arch repository

[Eli Schwartz via aur-general]

On 8/16/19 11:42 AM, pavel.finkelsht...@gmail.com wrote:
> Hi everyone,
> 
> So I have the repo built (BTW, Travis CI is able to upload files to
> pages by itself) here: 
> https://github.com/asm0dey/arch-kodi-devel-builder/tree/gh-pages/x86_64
> 
> It's built with `repo-add` command and looks correct to me. Next
> question to everybody: how will pacman detect database without
> directory listing?

$ curl -s
https://asm0dey.github.io/arch-kodi-devel-builder/x86_64/repo.db |
bsdtar -tf -
kodi-bin-devel-18.4rc1pre20-1/
kodi-bin-devel-18.4rc1pre20-1/desc
kodi-dev-devel-18.4rc1pre20-1/
kodi-dev-devel-18.4rc1pre20-1/desc
kodi-devel-18.4rc1pre20-1/
kodi-devel-18.4rc1pre20-1/desc
kodi-eventclients-devel-18.4rc1pre20-1/
kodi-eventclients-devel-18.4rc1pre20-1/desc
kodi-gbm-devel-18.4rc1pre20-1/
kodi-gbm-devel-18.4rc1pre20-1/desc
kodi-tools-texturepacker-devel-18.4rc1pre20-1/
kodi-tools-texturepacker-devel-18.4rc1pre20-1/desc
kodi-wayland-devel-18.4rc1pre20-1/
kodi-wayland-devel-18.4rc1pre20-1/desc

So the pacman.conf setting would be:

[repo]
Server = https://asm0dey.github.io/arch-kodi-devel-builder/$arch

I advise using a more descriptive name for the repository instead of
"repo.db".

Aside for that, pacman only cares about being told the name of the .db,
and then it downloads that directly (by concatenating the Server
directive, a "/", the repository name, and ".db"), getting all other
information by using a database parser, not via regular expressions on
an HTML file.

As I said on Wednesday:

> If you want an HTML index, you can generate your own or rely on
> webserver software to do so automatically, but it would be entirely for
> the interactive viewing pleasure of the user.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Custom arch repository

[Eli Schwartz via aur-general]

On 8/14/19 10:01 AM, asm0dey via aur-general wrote:
> Hi everyone,
> 
> I'm looking for any description on how arch linux repository should be
> organized.
> I've found way to publish built packages to github pages, but it's
> absolutely not enough to just put them somewhere. It looks like
> repository should have some predefined structure, maybe index files and
> so on. Any ideas on where I can find them?

https://wiki.archlinux.org/index.php/Unofficial_user_repositories

> If you want to create your own custom repository, follow pacman/Tips
and tricks#Custom local repository.

https://wiki.archlinux.org/index.php/Pacman/Tips_and_tricks#Custom_local_repository
describes how to generate the repository, with the note that the only
requirements are for one or more *.pkg.tar* files in the same directory
as a *.db file which contains the database itself.

If you want an HTML index, you can generate your own or rely on
webserver software to do so automatically, but it would be entirely for
the interactive viewing pleasure of the user.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] kodi-devel-bin

[Eli Schwartz via aur-general]

On 8/12/19 2:48 PM, Paul Finkelshteyn wrote:
> Of course my comment in there! Here it is:
> https://aur.archlinux.org/packages/kodi-devel-bin#comment-703544

Ugh, I'm sorry and I completely apologize. I totally misread that
comment and may have only registered the first half.

Maybe you could provide a bit more explanation, highlight what I said
here about kodi-devel-bin vs kodi-bin-devel? Then we can wait for the
maintainer to respond (it's only been three days, so he might not have
noticed yet), and play it by ear from there.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] AUR package with prebuilt packages

[Eli Schwartz via aur-general]

On 8/12/19 2:33 PM, Paul Finkelshteyn wrote:
> On Mon, 12 Aug 2019 14:23:51 -0400
> Eli Schwartz via aur-general  wrote:
>> I think you can probably use github pages for this. Github already
>> allows release assets, and there are definitely people putting release
>> assets in github pages, so I don't think this is against the terms of
>> service, and github pages lets you provide a simple html index and
>> file structure however you like.
>>
>> Just make sure to rebuild and force overwrite the gh-pages branch
>> rather than appending new commits, to make sure the size doesn't get
>> too big due to bloaty binary blobs in git history.
>>
> 
> Sounds awful cause it will bloat repo size to insane sizes (built
> packages are tens of MB) and it's devel version so it may obtain
> updates several times a week…
> 
> OK it looks like there is no sane way to do what I want so maybe I
> should just leave it as repo-for-myself.

That's exactly why I said you should force-overwrite the gh-pages branch
-- that way the total size of the repository is only the size of master
(the history of a shellscript and dockerfile) + the tens of MB for the
latest packages on gh-pages and *only* the latest packages.

git branch -D gh-pages
git checkout --orphan gh-pages
git reset HEAD -- .
git add *.pkg.tar.xz
git commit -m "nuke gh-pages and restart branch from scratch with new
packages"
git push -f origin gh-pages

git clone will never be too big. Your existing clone might grow quite
big, but git gc --auto should prune the dangling blobs in the background
after a while.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] AUR package with prebuilt packages

[Eli Schwartz via aur-general]

On 8/12/19 2:12 PM, Paul Finkelshteyn wrote:
> On Mon, 12 Aug 2019 14:03:55 -0400
> Eli Schwartz via aur-general  wrote:
> 
>>> Hi folks,
>>>
>>> As kodi-devel-bin take almost forever to build I've created github
>>> https://github.com/asm0dey/arch-kodi-devel-builder/ with pre-built
>>> packages.
>>>
>>> Now I want to create AUR packages which will be able to install
>>> these binary packages.  
>>
>> No.
> 
> Basically it's why I'm writing here

And thank you for asking first! :)

>>> As you can see I have some knowledge on how to maintain packages:
>>> https://aur.archlinux.org/packages/?SeB=m=asm0dey but in this
>>> concrete situation I have no any idea on how to create packages. Of
>>> course I can't just use these packages in source field because they
>>> have their own dependencies. Also I think I can't just install them
>>> inside build or package phase…
>>>
>>> So question is: is there any recommended way to do what I want?  
>>
>> If you replace the word "recommended" with the word "allowed", then
>> the answer is "you are allowed to advertise your repository on
>> https://wiki.archlinux.org/index.php/Unofficial_user_repositories and
>> on the package details for the AUR package".
>>
>> In fact, you're actually encouraged to do so. That's why we have the
>> wiki listing in the first place. :)
>>
> 
> But truth is I don't have repository (cause repository should have some
> predefined layout and so on). And I'm not sure if it's possible to
> create something repository-like on github. And I currently I have no
> idea on where should I have to host repository for it to be more or
> less reliable.

I think you can probably use github pages for this. Github already
allows release assets, and there are definitely people putting release
assets in github pages, so I don't think this is against the terms of
service, and github pages lets you provide a simple html index and file
structure however you like.

Just make sure to rebuild and force overwrite the gh-pages branch rather
than appending new commits, to make sure the size doesn't get too big
due to bloaty binary blobs in git history.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] kodi-devel-bin

[Eli Schwartz via aur-general]

On 8/10/19 8:04 AM, Luca Weiss via aur-general wrote:
> Hi Pasha,
> 
>> It looks like to me that all kodi-devel packages are named wrong. For
>> example kodi-devel-bin isn't binary package.
> 
> It looks like kodi-devel-bin is a subpackage of kodi-devel which contains 
> kodi-x11 and kodi-xrandr, just like the kodi-bin package on [community] which 
> is also a subpackage of kodi. So in this case, it's not a package with 
> prebuilt binaries but just a conincidence that the package suffix is the same 
> as 
> what is being used for marking packages with prebuilt binaries.

Incorrect.

kodi-devel-bin is the -devel version of community/kodi-bin, which means
that it should be named kodi-bin-devel.

It's no different from taking, say, systemd & systemd-libs, and turning
it into systemd-git and systemd-git-libs, which is also wrong... or
would be, except that systemd-git is better maintained. :)

...

This is aside for the fact that I find the name of the community package
"kodi-bin" to be strange, since it seems to be the x11 analogue to
"kodi-wayland".

@Ike,

I'm curious what made you choose to call it "kodi-bin" instead of what
seems to me like the more descriptive and accurate "kodi-x11". Perhaps
it might make sense to change the pkgname?

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] kodi-devel-bin

[Eli Schwartz via aur-general]

On 8/10/19 4:42 AM, Paul M. Finkelshteyn via aur-general wrote:
> Hi folks,
> 
> It looks like to me that all kodi-devel packages are named wrong. For
> example kodi-devel-bin isn't binary package.
> 
> Is there some way to force renaming it?

Yes, the first step is to talk to the maintainer of the package. Have
you left a comment on the AUR package details asking politely if they
think it is a good idea to rename it, or did you first come to the
mailing list asking if it can be "forced"?

...

Nope, no comment on the package details.

Please discuss this with the package maintainer, and hopefully it can be
resolved amicably. :)

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] AUR package with prebuilt packages

[Eli Schwartz via aur-general]

> Hi folks,
> 
> As kodi-devel-bin take almost forever to build I've created github
> https://github.com/asm0dey/arch-kodi-devel-builder/ with pre-built
> packages.
> 
> Now I want to create AUR packages which will be able to install these
> binary packages.

No.

> As you can see I have some knowledge on how to maintain packages:
> https://aur.archlinux.org/packages/?SeB=m=asm0dey but in this
> concrete situation I have no any idea on how to create packages. Of
> course I can't just use these packages in source field because they
> have their own dependencies. Also I think I can't just install them
> inside build or package phase…
> 
> So question is: is there any recommended way to do what I want?

If you replace the word "recommended" with the word "allowed", then the
answer is "you are allowed to advertise your repository on
https://wiki.archlinux.org/index.php/Unofficial_user_repositories and on
the package details for the AUR package".

In fact, you're actually encouraged to do so. That's why we have the
wiki listing in the first place. :)

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Fwd: Replacing package

[Eli Schwartz via aur-general]

On 8/5/19 6:02 PM, Rhys Perry via aur-general wrote:
> I have a package (i3-gaps-rounded) and would like to rename it to
> i3-gaps-rounded-git in order to comply with standards. What would I have to
> add to the PKGBUILD of each packages in order to force people who have
> installed i3-gaps-rounded to move to i3-gaps-rounded-git?

Renaming the package is not sufficient to comply with the standards
anyway. Why does it clone a git repository in prepare() instead of using
the source=() array? Why does it then play strange games with git
archive, gzip and tar just to copy the source code from one directory to
another?

Why does it use "pkgver=latest"?

Some of these are grounds for removing the package from the AUR. Please
read the entirety of
https://wiki.archlinux.org/index.php/VCS_package_guidelines and fix the
package entirely. If it is meant to download development versions, from
git master, then it *also* needs to be renamed, yes.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Fwd: Replacing package

[Eli Schwartz via aur-general]

On 8/5/19 6:19 PM, Chris Billington via aur-general wrote:
> On Mon, Aug 5, 2019 at 6:02 PM Rhys Perry via aur-general <
> aur-general@archlinux.org> wrote:
> 
>> I have a package (i3-gaps-rounded) and would like to rename it to
>> i3-gaps-rounded-git in order to comply with standards. What would I have to
>> add to the PKGBUILD of each packages in order to force people who have
>> installed i3-gaps-rounded to move to i3-gaps-rounded-git?

> provides=(i3-wm i3-gaps-rounded)
> replaces=(i3-gaps-rounded)

While it is technically true that the "replaces" metadata would "force
people who had one, to install the other", the proper answer is "do not
force people to do that if they were expecting a stable version,
replaces are for when software is renamed".

The other answer is "the AUR is not a sync repository and therefore does
not support replaces, it is possible there are AUR helpers which
implement it though" (or they would, if the RPC interface actually
supported that sort of search).




-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Advise on updating/uploading binary package

[Eli Schwartz via aur-general]

On 7/18/19 8:28 AM, Oon-Ee Ng via aur-general wrote:

I've been using cin-git for a while (which draws on cinelerra-gg project).
For those who are unfamiliar, there's the 'original' (old and out-of-date)
cinelerra, and a newer cinelerra-heroine, and the most popular one is
cinelerra-gg.

The 'cin-bin' PKGBUILD on AUR points to the original website, and is
practically useless in an up-to-date Arch system. For convenience (and
because recently some problems have been happening with cin-git), I want to
upload a binary verison of cinelerra-gg. As cin-bin is currently quite
useless (and IMO the -gg project is the real heir of the cinelerra
heritage), is there any reason I shouldn't adopt it and update it to point
to cinelerra-gg binary package?


In general, that would be fine. Since every other package points to this 
upstream, it would be more coherent and generally serve the user better.


In this specific case, I'm not sure I understand the purpose though. It 
is presumably repackaging this upstream binary: 
https://www.cinelerra-gg.org/arch-package/


But, uh, they already provide a pacman repository, so why not just use 
that directly. What is the *point* of downloading a *.pkg.tar.xz, 
un-tar'ing it, and using a PKGBUILD to re-tar it into another *.pkg.tar.xz?


Also side note: why are these packages called "cin" instead of 
"cinelerra"? Seems weird. And now we have currently five packages in the 
AUR matching the search term "cinelerra":


- cin
- cin-bin
- cinelerra-cv

(these all point to out of date links on cinelerra-cv.org, which is a 
redirect to cinelerra-gg.org)


- cin-git

(points to cinelerra-gg.org)

- cinelerra-heroine

...

Apparently cinelerra-cv was the "official" (or as official as it gets) 
package for Arch Linux, since David Runge dropped it to the AUR on 
2018-12-30 with the commit message:


"Moving cinelerra-cv to the AUR, after announcing it upstream and 
getting into contact with cinelerra-gg as a potential replacement (in 
the future)."


I'm unclear on exactly what that means given -cv is a redirect to -gg, 
the "cin" package's pkgdesc helpfully mentions the unhelpful git clone 
url which is some "goodguy" person's namespace on git.cinelerra-cv.org 
and cin-git claims it is "goodguy's version" -- I assume the -gg is for 
"goodguy".


"The 'cin-bin' PKGBUILD on AUR points to the original website" -- does 
that mean it points to the website before a rename of the project? If 
so, then this is the most clear-cut case I could possibly imagine for a 
package that is "out of date" by pointing to a deprecated domain for the 
*exact same project*.
Or do you mean that cinelerra-cv was the development by a different 
group, in which case that is some very confusing references -- plus if 
they turned their site into a redirect for the other project, it seems 
obvious they passed on the torch.


(Is there a third site that has pre-"goodguy" development that isn't 
referenced by *any* packages in the AUR? Then since nothing discusses or 
links to it, let's not bother discussing it either. :D)


Either way, there's entirely too many packages at the moment and two of 
them are probably duplicates. I'd suggest the "cinelerra" prefix either 
way, it seems cleaner and cinelerra-cv dates back to *at least* Arch 
Linux's initial import of PKGBUILDs into subversion, back in 2009...


--
Eli Schwartz
Bug Wrangler and Trusted User

Re: [aur-general] Trouble receiving email to reset password

[Eli Schwartz via aur-general]

On 7/17/19 3:16 PM, Etienne Wan via aur-general wrote:

It worked this time. Thanks.


Great!


I am as surprised as you that my previous account did not exist anymore.
I cannot remember when I created it, but I did not have much activity on it.

How long ago is long ago? Before the 2015 migration to AUR 4.0?

--
Eli Schwartz
Bug Wrangler and Trusted User

Re: [aur-general] Trouble receiving email to reset password

[Eli Schwartz via aur-general]

On 7/17/19 9:32 AM, Etienne Wan via aur-general wrote:

Hello,

I had an account with the username etiennewan for some months now. I
tried to login today but was not able to, so tried to send a reset email
to the email address the account was registered with, but I did not
receive anything.


I don't see an existing AUR user by that username or email address. When 
did you create it?



I signed up a new account today with the same username
(and it was accepted) and this email address, but I did not receive any
email to set my password. Can you help me on this ?

Thank you in advance,


This does not make any sense. If you created an account with the same 
name, that means the account did not used to exist.


...

Note that the mysql database did run pretty low on disk space today, so 
writes were failing. If I assume that the account never existed, then 
it's possible you tried creating it today, and it seemed to work from 
the website but never registered in the backend. Since the disk space 
issue is now resolved, can you try signing up again?


--
Eli Schwartz
Bug Wrangler and Trusted User

Re: [aur-general] Packages that include other project code

[Eli Schwartz via aur-general]

On 7/15/19 10:57 AM, Brett Cornwall via aur-general wrote:

I'd like a sanity check!

Waybar has a dependency on a C++ logging library called spdlog. This 
project depends on fmt and by default uses an included copy. I've raised 
a ticket about removing this but it doesn't look like the developer is 
interested [2].


In this case, I feel it expedient to patch out the logic to use the 
bundled headers [2] and outright remove the directories [3]. Am I 
correct in this conclusion or is this too far-reaching?


[1] https://github.com/gabime/spdlog/issues/1146
[2] 
https://git.archlinux.org/svntogit/community.git/tree/spdlog/trunk/rm_bundled_fmt.patch 

[3] 
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/spdlog#n50 


Upstream has an option to build using the system spdlog, which is 
perfectly reasonable. We should use that configure-time option.


There's no reason to also use downstream patches which can get out of 
date, just to remove source code that isn't used. Debian does this all 
the time, and it's one of the reasons it's so hard to understand 
anything at all about how Debian packages are constructed. Their 
rationale for doing so is, I think, that it offends their morality to 
know that the build system is at all capable of using vendored code.


--
Eli Schwartz
Bug Wrangler and Trusted User

Re: [aur-general] The AUR package "svp" is suspicious

[Eli Schwartz via aur-general]

On 6/29/19 5:18 PM, Hirela via aur-general wrote:
> TL;DR: The AUR package "svp" (https://aur.archlinux.org/packages/svp/) might 
> be injecting suspicious binary patches.
> 
> Here are the relevant lines from the PKGBUILD version 4.3.0.165:
> 
>     pkgver=4.3.0.165
>     
> source=("https://gist.githubusercontent.com/phiresky/1e2cbd30bed4e5978771af232d11afd1/raw/svp4-$pkgver.tbz2;)
>     # I am rehosting the binaries
>     # taken from
>     # http://www.svp-team.com/files/svp4-linux-64.tbz2
>     # at https://gist.github.com/phiresky/1e2cbd30bed4e5978771af232d11afd1
>     # so they are correctly versioned and old versions still exist
>     
> sha256sums=('00a025ce7c06660bafbad8cf5d889e9a6f09a9c9c9585dbee2415a8bf0256f53')
> 
> First of all, I do not agree with him rehosting binary software and would 
> much prefer this PKGBUILD to just download the latest version of 
> svp4-linux-64.tbz2 straight from the official source. Since this is 
> proprietary freeware, the maintainer might not have a license to redistribute 
> binaries, and even if he did, the advantage of "correctly versioned" does not 
> match up to the disadvantage of having to trust the maintainer to not tamper 
> with his rehosted versions. Loose versions are acceptable for all the *-git 
> packages, so it should be acceptable for SVP.

Note that makepkg has a builtin mechanism for correctly versioning the
sources. From man PKGBUILD(5):

```
It is also possible to change the name of the downloaded file, which is
helpful with weird URLs and for handling multiple source files with the
same name. The syntax is: source=('filename::url').
```

The correct way to write a PKGBUILD for this software, then, is to
download from the svp website, but rename the download to contain the
version number. When updating the pkgver, the file will get redownloaded
from the same location under a new name, and therefore not run into bad
cache/checksum issues.

> I decided to get the binaries from the official source to verify whether his 
> rehosted packages weren't tampered with. The package version of the PKGBUILD 
> (4.3.0.165) matches up with the latest version of SVP according to the 
> official website (https://www.svp-team.com/wiki/Main_Page). I tried 
> downloading the SVP binary from the official source and compare the hashes:
> 
>     $ curl https://www.svp-team.com/files/svp4-linux-64.tbz2 > 
> svp4-linux-64.tbz2
>     $ sha256sum svp4-linux-64.tbz2
> 070411ab60d429e03632fa80bb3ded7d5b2c60c2f5b85dff136f65eb83da3bdb  
> svp4-linux-64.tbz2
> 
> This hash does not match up with the hash claimed by the PKGBUILD for his 
> rehosted version, which suggests that the rehosted package is not identical 
> to the official one. I don't know whether this is due to incompetence or 
> malice, but it is worrisome, as it may be possible that the maintainer has 
> injected his own patches into the rehosted versions.
> 


-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Copyrighted source on https://aur.archlinux.org/

[Eli Schwartz via aur-general]

On 6/25/19 1:20 PM, Jones, Philip via aur-general wrote:
> 3) I am in contact with the US .gov site to get them to take down the
> original tarball which is obviously the definitive action but that
> will then leave you with a dangling link. If it is as popular as
> indicate that may not be an issue 

OK -- from our end, we would then recommend that the person who uploaded
the AUR package will use a local://libccmio-2.6.1.tar.gz link and users
who wish to install libccmio will have to (legally) acquire it from the
copyright holders somehow.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Copyrighted source on https://aur.archlinux.org/

[Eli Schwartz via aur-general]

On 6/25/19 12:09 PM, Daniel Berjón Díez via aur-general wrote:
> Hi Santiago, all,
> 
> I'm very new to Arch and I don't know if the package I'm going to put
> forward as an example violates itself any AUR rule, but for instance
> 'ufsd-pro-dkms' [1] depends on a file that is not freely distributable, and
> the PKGBUILD has a file:// URL, so the user has to procure the file herself
> to build it; maybe this solution is more reasonable than deleting the
> package altogether, so that users that do want to install it don't have to
> create their own PKGBUILD needlessly.
> 
> Cheers,
> Daniel
> 
> [1]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=ufsd-pro-dkms

The package you just linked is actually a perfect example of our
official policy. :)

Packages with source code that is not publicly available are supposed to
be described using just the filename, and typically come with
instructions to obtain the file manually and save it to the same
directory as the PKGBUILD.

That being said, ufsd-pro-dkms and other packages like it should really
be using "local://" not "file://", as the former is special cased in
makepkg as "you need to obtain this yourself", while the latter is a
type of link that /usr/bin/curl understands and will try to download
from the local filesystem.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Copyrighted source on https://aur.archlinux.org/

[Eli Schwartz via aur-general]

On 6/25/19 10:53 AM, Jones, Philip via aur-general wrote:
> Jerome
> 
> I appreciate that the package
> (https://aur.archlinux.org/packages/libccmio/) is not hosted on the
> site but if you Google " libccmio-2.6.1.tar.gz" it is the top hit.

This sounds like an SEO problem, have you tried contacting Google to
discuss why your brand is being diluted by links to some unofficial
website? I'm afraid we don't have any power over this, though.

Note that the Google SEO ranking is an unrelated matter -- it does not
have an impact on the legality of the use of the package.

If the package is hosting copyright-infringing content, then the package
is illegal to distribute, regardless of its SEO ranking.

If the package is *not* hosting copyright-infringing content, then the
package is completely legal to distribute, again regardless of its SEO
ranking.

> The source has a copyright that states  “The unauthorized use,
> distribution, or duplication of this program is prohibited.”

And indeed, we do not use, distribute, or duplicate the libccmio
program. We do, however, host a tutorial (in script form) that teaches
people how they can, on their own, acquire and use the program.

As far as I am aware, this tutorial is legal.

One potential concern is the link itself: is the
https://portal.nersc.gov/ website illegally redistributing this source
code? If so, have you tried talking to them about it?

> I don’t want to enter into a legal argument if the link is
> distribution or not, all I ask is that the listing be removed as a
> matter of courtesy. The material is clearly not designed to be
> publicly distributed.

There is no legal argument if the link is distribution -- it may be
advocacy (or "contributory copyright infringement"), but distribution is
a whole 'nother kettle of fish. :/ But as far as I can tell, it all
boils down to whether that link is legally distributing the product. It
is plainly distributing it in some manner...

If I look at the google search links following the AUR search result, I
see many search results all pointing to the OpenFOAM developer resources
and source code repositories. For example,
https://github.com/OpenFOAM/ThirdParty-6#miscellaneous

Since the libccmio source code linked in the AUR build tutorial/script
is also used all over by the OpenFOAM project, it seems that it is being
publicly distributed for the sake of many people. Is this infringement
as well? Have you discussed this with them?

The AUR package is only used by the AUR build tutorial/script for
OpenFOAM, so my guess is that this primarily impacts OpenFOAM users --
one of whom has converted existing OpenFOAM documentation into
AUR-compatible documentation.

The OpenFOAM documentation exists irrespective of the existence of this
AUR package, and if the latter is removed, the former will graduate to
being the top Google search result anyway, so it is probably worth
looking into that either way (and fixing the root of the problem, which
is the distribution by https://portal.nersc.gov/ which may or may not
have the right to do so).

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] How to name llvm trunk packages tailored to work with mesa trunk ?

[Eli Schwartz via aur-general]

On 5/8/19 8:41 AM, Lone_Wolf wrote:
> Hi,
> 
> 
> llvm-git (and it's predecessor llvm-svn) is intended to provide a full
> implementation of the llvm/clang compiler suite. It's a huge package
> that takes a lot of time and processor capacity to build.
> 
> While mesa needs llvm, it only needs a subset.
> 
> examples :
> 
> llvm-git builds with ocaml support, but mesa doesn't use ocaml at all.

llvm-minimal-git, perhaps? If it is just building the core.

> llvm-git builds for lots of processor architectures not supported by
> archlinux. RISC-V is one of them.

Why does llvm-git build for RISC-V at all? Who is using it?

> I've been looking into this and tried 2 (bad) naming schemes already.
> 
> The current scheme goes like this :
> 
> lone_wolf-llvm-git , lone_wolf-compiler-rt-git, lone_wolf-clang-git and
> lone_wolf-lib32-llvm-git
> 
> 
> llvm-mesa-git seems to vague, while llvm-trunk-for-mesa-trunk-git feels
> clumsy and long.
> 
> Please help me to find  a good name for these packages.
> 
> Lone_Wolf


-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Kernel version requirement

[Eli Schwartz via aur-general]

On 5/7/19 3:25 PM, Julien Nicoulaud via aur-general wrote:
> Hi,
> 
> In the oomd package , I put a
> linux>=4.20 dependency requirement since it requires the new resource
> pressure metrics  introduced in
> linux 4.20.
> 
> But as another user pointed out, some of the alternatives kernel packages
> declare provides=("linux=${pkgver}"), but several of the most popular do
> not (linux-lts, linux-dzen, linux-hardened).

Those packages are incorrect as they do not provide /boot/vmlinuz-linux
or /lib/modules/${version}-ARCH/, and are specifically designed to be
co-installable with the actual core/linux package. Their provides=()
will therefore cause errors for users who have installed out-of-tree
modules targeting a different kernel package.

linux-libre tries to get around this by also providing LINUX-ABI_VERSION
but AFAIK it is the only package to do so.

> What we would be correct way to handle this ? Should I just drop the
> version requirement (since having a kernel>=4.20 does not imply you are
> running this one anyway) ? Or should these packages be improved ?

Consider java (sorry!) for inspiration here. One can have java-runtime
as a dependency if an application can use any version of java, but if
you need a specific version of java, depend on e.g. java-runtime=11.
This does not guarantee the user will use this version, but it does
guarantee that they have it installed and provides pacman hints so that
users know why the software does not work on other versions.

This works because there is a standard for all java packages to
provides=(java-runtime=$majorver)

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

[Eli Schwartz via aur-general]

On 5/3/19 1:09 PM, Bruno Pagani wrote:
> They came for mesa-git, did not took care about which dependency were
> pulled. They update mesa-git, but don’t think of llvm-git because they
> were never informed this is especially relevant for mesa-git.

If they break their system by installing packages from git, and not
updating them, then that is entirely on their head.

> Other case : user already has llvm-git for whatever reason, but like you
> said don’t update it (they forgot about it, don’t care…). They install
> mesa-git from AUR, llvm-git dependency is already satisfied. But at that
> point, their llvm-git could even be older than repo llvm (granted, at
> this stage they would have other issues). So depending on llvm-git in
> mesa-git does not achieve a lot.

Like I said? What I said is that they *will* update it.

If they don't update it but do install mesa-git, and then don't update
that either, then as you even point out, they have other issues. And
what I will point out, is that they are not the intended users of the
AUR. Responsible people who use the AUR as intended, are the intended
users of the AUR.

So yes, depending on llvm-git does achieve a lot. It achieves a state of
being, whereby competent users who read the instructions, know what is
on their system, and act responsibly, build some package against current
development versions of llvm, tracking code that is far ahead of
[extra]/llvm.


-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

[Eli Schwartz via aur-general]

On 5/7/19 1:13 PM, Giancarlo Razzolini via aur-general wrote:
> This thread went way beyond what it should have gone. This is the AUR
> we're talking about.
> I'm not saying we should accept any crap on the AUR, but, I'm talking
> from my own experience here,
> we don't always anticipate what will be useful or not to people.

In fact, the AUR is sort of by definition a place for people to
experiment with software.

> I have several packages I've put on the AUR that, even though I've
> followed the guidelines, I didn't
> expect them to be of any use to other people. And yet, they did. On the
> other hand, I have uploaded
> packages that I expected to be of use, and they turned out to not be
> that useful.
> 
> Unless we have a way to enforce the guidelines properly, I say that we
> should not bikeshed this much
> over AUR submissions. We have a lot of crap on AUR, yes. We have a lot
> of submissions that are useful to
> only one person, yes. We have packages that are not even for the
> architecture we support, yes. So, let's
> not dabble over a package that's not even the worse we have on the AUR
> *right now*.

Yeah, I think it is pretty disheartening that someone who has capably
packaged software for years is receiving so much flak over how he does
it, when everyone agrees that it's definitely useful to a whole bunch of
random ordinary users.

Because apparently ideological purity in the AUR. Even though no one can
actually suggest a better way of doing it that answers the
thought-provoking usability concerns which have been raised.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature