Re: [aur-general] Basilisk pkgbuild is facing a trademark violation?

[Doug Newgard via aur-general]

On Mon, 21 May 2018 23:17:39 -0400
Eli Schwartz via aur-general  wrote:

> All this being said:
> 
> [11:07:23 PM]  eschwartz: if you plan to go that
> route, that's fine and someone can have a look over your build
> configuration (which I could do as well if it is was not 5 in the
> morning) and can tell you what's wrong with it. In the interim, until
> permission is granted, you are NOT allowed to keep these packages up
> since you're in violation. You ask permission first, get it granted
> first, THEN are allowed to use it if OK, not in any other order

What these jokers don't seem to get is that there is NO packages involved here.
There is nothing here that violates the license as there is no redistribution
at all. Moot point, move on and whine somewhere else.

Re: [aur-general] pkgrel - Is it correct that some "fixes" aren't "fixes"?

[Doug Newgard via aur-general]

On Fri, 22 Jun 2018 19:33:05 +0200
Ralf Mardorf  wrote:

> Moving a package from AUR to Community or vice versa also doesn't
> change the content. I guess the pkgrel should inform about each change
> done to a package providing the same pkgver.

You're confusing package with PKGBUILD. Changes to the package do require
bumping the pkgrel, changes to the PKGBUILD do not.

Re: [aur-general] Rage-git package exists but pkg web page 404 + seems unmaintained

[Doug Newgard via aur-general]

On Sat, 30 Dec 2017 14:33:41 +0900
Carsten Haitzler <ras...@rasterman.com> wrote:

> On Fri, 29 Dec 2017 23:28:19 -0600 Doug Newgard via aur-general
> <aur-general@archlinux.org> said:
> 
> > A whole lot of orphans with no votes got deleted. When a package is deleted
> > from the AUR, the git repo remains which is what you're seeing.  
> 
> oh - it was a lack of votes?

Lack of votes plus being an orphan and broken. All of which are strong
indicators of lack of interest.

> 
> > As for restoring it, pushing a new commit to the repo would work. It can 
> > also
> > be done over ssh, but you're going to need to fix it up anyway.  
> 
> ok. i assume this is an ok to take over maintenance?
> 

It appears this had no maintenance since I dropped it. You're definitely safe
taking it over.

Re: [aur-general] Rage-git package exists but pkg web page 404 + seems unmaintained

[Doug Newgard via aur-general]

On Sat, 30 Dec 2017 12:40:29 +0900
Carsten Haitzler  wrote:

> https://aur.archlinux.org/packages/rage-git
> 
> Is gone but repo is alive:
>   git clone ssh://a...@aur.archlinux.org/rage-git.git
> 
> Works. As does:
>   git clone https://aur.archlinux.org/rage-git.git
> 
> And I see no removal request on aur-requests:
>   https://lists.archlinux.org/pipermail/aur-requests/
> 
> (downloaded full mbox archive):
>   $ grep rage-git aur-requests.mbox
>   sickrage-git [3]:
>   [3] https://aur.archlinux.org/pkgbase/sickrage-git/
> 
> No rage-git.
> 
> What happened? It's unmaintained because it doesn't build (since July 20 when 
> I
> removed the autotools based build upstream and moved to meson as the build
> system). I put in a comment on the pkg page that the AUR pkg build was broken
> ages ago and offered to take over maintenance in the package comments but got
> no reply and now the package page at least has disappeared.
> 
> How about restoring it? I can also take over maintenance as I have kept a git
> clone of rage-git and moved it to meson locally (have not pushed). I also now
> maintain efl-git and enlightenment-git too (rage-git depends on efl).
> 

A whole lot of orphans with no votes got deleted. When a package is deleted
from the AUR, the git repo remains which is what you're seeing.

As for restoring it, pushing a new commit to the repo would work. It can also
be done over ssh, but you're going to need to fix it up anyway.

Doug (Scimmia)

Re: [aur-general] Special Removal of an Inactive TU: speps

[Doug Newgard via aur-general]

On Thu, 18 Jan 2018 22:05:10 +0100
Thorsten Toepper  wrote:

> Whether the votes happens in the AUR web interface or on a separate
> private mailing list is unimportant for the real process I agree, just
> at the moment it's the AUR webinterface and the second point is simply
> not too well formulated, in it's current form this also includes the
> votes and therefore in case someone participated in a vote both blocks
> are neglected. So the "either" "or" doesn't really work here.
> 

Yes, it is a bit ambiguous. The discussion in #archlinux-tu concluded that the
voting being an the AUR was just happenstance and intent of the section was
that voting not be included in point 2. With many/most of the most active TUs
participating or present for that discussion, I would conclude that the general
understanding of this section was followed in this case and the motions have
passed.


pgpM3bTPDM63B.pgp
Description: OpenPGP digital signature

Re: [aur-general] Please remove gsmartcontrol-svn package from AUR

[Doug Newgard via aur-general]

On Fri, 9 Feb 2018 13:13:37 -0200
Rafael Fontenelle  wrote:

> I don't see it as mandatory, but if I was the maintainer of this
> development package I would do as the developer says and request
> package deletion.
> 

I, on the other hand, wouldn't. The entire point of - packages is to run
the incomplete development code, anyone that's running it should understand
that it's incomplete and potentially unstable.

Re: [aur-general] PKGBUILD(s) Review

[Doug Newgard via aur-general]

On Thu, 22 Feb 2018 22:39:43 +0530
Ankit R Gadiya  wrote:
> >>
> >>install -Dm755 "${srcdir}/${pkgname/-/_}-${pkgver}/plugin/tcomment.vim" 
> >> \
> >>"${pkgdir}/usr/share/vim/vimfiles/plugin/tcomment.vim"
> >>install -Dm755 "${srcdir}/${pkgname/-/_}-${pkgver}/doc/tcomment.txt" \
> >>"${pkgdir}/usr/share/vim/vimfiles/doc/tcomment.txt"
> >>install -Dm755 
> >> "${srcdir}/${pkgname/-/_}-${pkgver}/autoload/tcomment.vim" \
> >>"${pkgdir}/usr/share/vim/vimfiles/autoload/tcomment.vim"  
> > 
> > Same as other PKGBUILD.  
> Added License

Since this one is GPL3, it doesn't need the license. I was referring to the
${srcdir} and -t changes.

Eli already responded about the pkgdesc.


pgprmZmZfv6ZH.pgp
Description: OpenPGP digital signature

Re: [aur-general] PKGBUILD(s) Review

[Doug Newgard via aur-general]

On Thu, 22 Feb 2018 19:45:48 +0530
Ankit R Gadiya  wrote:

> Hi everyone,
> 
> I added two new PKGBUILD(s) today in the AUR, both are plugins for vim.
> Any advice, suggestions or feedback will be greatly appreciated.
> And if anybody would like the *-git versions of these I will be more
> then happy to add them as well.
> 
> 1. ranger-vim: https://aur.archlinux.org/packages/ranger-vim/
> 2. tcomment-vim: https://aur.archlinux.org/packages/tcomment-vim/
> 
> Ranger-vim
> # Maintainer: Ankit R Gadiya 
> 
> pkgname=ranger-vim
> pkgver=2.0
> pkgrel=1
> pkgdesc="Ranger integration for vim"
> license=('MIT')

MIT license is required to be installed in the filesystem, but I don't see that
done below.

> arch=('any')
> url="https://github.com/francoiscabrol/ranger.vim;
> depends=('vim' 'ranger')
> groups=('vim-plugins')
> source=("https://github.com/francoiscabrol/${pkgname/-/.}/archive/${pkgver}.tar.gz;)

You need to rename this file. A file named "2.0.tar.gz" is far too generic if
people are using SRCDEST.

> md5sums=('59f24462eb5c7561756a646585cd9e4c')
> 
> package() {
> install -Dm755 "${srcdir}/${pkgname/-/.}-${pkgver}/plugin/ranger.vim" \
>   "${pkgdir}/usr/share/vim/vimfiles/plugin/ranger.vim"

You can omit the ${srcdir} here if you'd like, functions will always start 
there.
You can also omit the last ranger.vim if you use the -t switch. Both of these 
are
optional.

> }
> 
> tcomment-vim
> # Maintainer: Ankit R Gadiya 
> 
> pkgname=tcomment-vim
> pkgver=3.08.1
> pkgrel=1
> pkgdesc="An extensible & universal comment vim-plugin that also
> handles embedded filetypes"

Is this a wrapping issue or is this really 2 lines?

> license=('GPL3')
> arch=('any')
> url="https://github.com/tomtom/tcomment_vim;
> depends=('vim')
> groups=('vim-plugins')
> source=("https://github.com/tomtom/${pkgname/-/_}/archive/${pkgver}.tar.gz;)

Same as with the other PKGBUILD

> md5sums=('6ea8f4ce78411efba444a0218e111219')
> 
> package() {
> 
>   install -d "${pkgdir}/usr/share/vim/vimfiles/"{doc,plugin,autoload}

This doesn't do anything. The -D switch on the following commands will take 
care of it.

> 
>   install -Dm755 "${srcdir}/${pkgname/-/_}-${pkgver}/plugin/tcomment.vim" 
> \
>   "${pkgdir}/usr/share/vim/vimfiles/plugin/tcomment.vim"
>   install -Dm755 "${srcdir}/${pkgname/-/_}-${pkgver}/doc/tcomment.txt" \
>   "${pkgdir}/usr/share/vim/vimfiles/doc/tcomment.txt"
>   install -Dm755 
> "${srcdir}/${pkgname/-/_}-${pkgver}/autoload/tcomment.vim" \
>   "${pkgdir}/usr/share/vim/vimfiles/autoload/tcomment.vim"

Same as other PKGBUILD.

> }
> 



pgpRZw36HTynP.pgp
Description: OpenPGP digital signature

Re: [aur-general] [PRQ#11055] Deletion Request for dnscrypt-proxy-go | [PRQ#11056] Deletion Request for dnscrypt-proxy-go-git

[Doug Newgard via aur-general]

On Wed, 04 Apr 2018 11:23:34 -0400
Jordan Glover via aur-general  wrote:

> I'm sorry for the harsh words. If those requests were made AFTER update 
> package
> in repo there won't be this conversation. I found situation where killing 
> other people
> efforts to make things work, unacceptable without providing an alternative. 
> Common
> sense should prevail the rules.
> 
> Jordan

Common sense tells me that if we allow people to upload newer packages just
because the repo package is out of date, the AUR will be an even bigger mess
than it already is. Everyone will be uploading packages a few hours after
upstream releases updates, and of course they will just abandon them instead of
having them deleted. The rules are in place for a reason.

Doug

Re: [aur-general] [PRQ#11055] Deletion Request for dnscrypt-proxy-go | [PRQ#11056] Deletion Request for dnscrypt-proxy-go-git

[Doug Newgard via aur-general]

On Wed, 04 Apr 2018 11:54:33 -0400
Jordan Glover via aur-general  wrote:

> On April 4, 2018 5:32 PM, Doug Newgard  wrote:
> 
> > On Wed, 04 Apr 2018 11:23:34 -0400
> > 
> > Jordan Glover via aur-general aur-general@archlinux.org wrote:
> >   
> > > I'm sorry for the harsh words. If those requests were made AFTER update 
> > > package
> > > 
> > > in repo there won't be this conversation. I found situation where killing 
> > > other people
> > > 
> > > efforts to make things work, unacceptable without providing an 
> > > alternative. Common
> > > 
> > > sense should prevail the rules.
> > > 
> > > Jordan  
> > 
> > Common sense tells me that if we allow people to upload newer packages just
> > 
> > because the repo package is out of date, the AUR will be an even bigger mess
> > 
> > than it already is. Everyone will be uploading packages a few hours after
> > 
> > upstream releases updates, and of course they will just abandon them 
> > instead of
> > 
> > having them deleted. The rules are in place for a reason.
> > 
> > Doug  
> 
> Please be specific. We aren't talking about hours and bumping package version.
> Common sense can be used to know when taking action will make people 
> worse-off.
> The package was managed so efficiently that even upstream benefited from it.
> Archlinux maintainer dosen't have to do anything else than copy-paste existing
> PKGBUILD. All work and testing is already done.
> 
> ​Jordan

I have been specific; the rules are in place for a reason, common sense says
that they're necessary. This case is not special.

C the entire PKGBUILD would be a huge mistake. Those sed commands
are...marginal, to be generous.

Re: [aur-general] packaging error in network manager?

[Doug Newgard via aur-general]

On Mon, 19 Mar 2018 15:21:06 +0100
Tom Zander via aur-general  wrote:

> I just updated my machine and rebooted, the network manager failed to get 
> up.
> Checking the journal logs I get message 
> that /usr/bin/NetworkManager can't read the shared library libpsl.so.6
> 
> I only have libpsl.so.5 on my system.
> 
> Did packaging go wrong somewhere?

You're out of date, this was fixed almost 4 hours ago

Re: [aur-general] Questions about some of my packages being adopted in [community]

[Doug Newgard via aur-general]

On Sun, 30 Sep 2018 13:59:28 -0500
Doug Newgard via aur-general  wrote:

> On Sun, 30 Sep 2018 19:51:47 +0100
> Konstantin Gizdov  wrote:
> 
> > Denied resolution?  
> > > ...
> > > I fail to see how you're being "denied" anything.
> > 
> > Call it what you want, I tried to re-open all 3 bugs but was denied with
> > little to no comment/explanation. I wanted to know if python2 is going to
> > be added by Felix or not - instead I was scolded at the bug and here in
> > emails. The other bug is a bug as confirmed - also denied to re-open
> > without explanation/investigation. The third bug was re-opened by Filipe
> > after my initial email - no need to bash me further about it. So all bugs
> > were closed & denied to re-open until I made a fuss about it here. That to
> > me is 'denied'.  
> 
> This entire paragraph is false. You tried to re-open all 3 tickets when only 2
> were closed? On the two that you *did* request re-open, was was never denied.

That should read "one was never denied". Also Filipe never played a part in
anything here other than commenting on the one ticket that was never closed.

> We can access the history in the bug tracker, don't try to pass lies off as
> facts.

Re: [aur-general] Questions about some of my packages being adopted in [community]

[Doug Newgard via aur-general]

On Sun, 30 Sep 2018 19:51:47 +0100
Konstantin Gizdov  wrote:

> Denied resolution?
> > ...
> > I fail to see how you're being "denied" anything.  
> 
> Call it what you want, I tried to re-open all 3 bugs but was denied with
> little to no comment/explanation. I wanted to know if python2 is going to
> be added by Felix or not - instead I was scolded at the bug and here in
> emails. The other bug is a bug as confirmed - also denied to re-open
> without explanation/investigation. The third bug was re-opened by Filipe
> after my initial email - no need to bash me further about it. So all bugs
> were closed & denied to re-open until I made a fuss about it here. That to
> me is 'denied'.

This entire paragraph is false. You tried to re-open all 3 tickets when only 2
were closed? On the two that you *did* request re-open, was was never denied.

We can access the history in the bug tracker, don't try to pass lies off as
facts.

Re: [aur-general] Fwd: FS#60333: namcap exits 0 when errors found (Task closed)

[Doug Newgard via aur-general]

On Mon, 8 Oct 2018 13:23:03 +0700
Tom Hale  wrote:

> I noticed that even when namcap prints out errors, it still exits 0.
> 
> I raised this at:
> https://bugs.archlinux.org/task/60333
> 
> It was closed:
> 
> Reason for closing: Not a bug
> Additional comments about closing: namcap runs fine, so exiting with an 
> error makes no sense
> 
> To me the "reason for closing" is like saying that diff should exit 0 
> when two files are different because diff ran fine.
> 
> If namcap is to be used in any automated packaging tools (or even my 
> dodgy script), then it makes sense to have meaningful exit codes. And 
> possibly an option to also have warnings also exit non-0 for the 
> persnickety amongst us.
> 
> I note that the python source returns 0 and 2, but never 1.
> 
> I'm a newbie here, but I believe my argument has merit, so I raise it 
> here for possible discussion.
> 

namcap's output is informational, nothing more. Taking it as gospel or using it
as any kind of automated checking instead of actually reading the output is not
sane.

Re: [aur-general] TU Application: Daniel Bermond (dbermond)

[Doug Newgard via aur-general]

On Sun, 14 Oct 2018 23:38:54 +0200
Baptiste Jonglez  wrote:

> Hi,
> 
> On 14-10-18, Doug Newgard via aur-general wrote:
> > Decided to take a quick look at your PKGBUILDs, and just a few spot checks
> > makes me wonder. The first one I click on is apache-flex-sdk, I see that you
> > aren't the original submitter, so I look at the git log and see that the 
> > first
> > thing you did when taking over this was to remove pgp checks from the 
> > source.
> > WTF. Look at the PKGBUILD, see a totally useless prepare function, ok, not a
> > big thing. Let's check another one, clicked on flif, see msg2s being used 
> > for
> > no reason and bad conflicts. Click on a couple more, see that those issues
> > aren't mistakes, they're a fundamental misunderstanding.
> > 
> > Maybe my perception was colored by that really bad decision to remove the 
> > pgp
> > checks, and while the PKGBUILDs are mostly fine, there seems to be things 
> > about
> > packaging that you don't understand yet. Is it time to become a TU already? 
> >  
> 
> Well, as always, you could start by not being immediately aggressive
> towards people.

Please read my email again, it was not aggressive in any way. My response to
your candidate would be aggressive, I'm still deciding if I want to actually
send that.

> 
> Judging from the handful of PKGBUILDs I've read, the quality is really
> high overall, they don't even have most of the "classical" small mistakes
> (there is source renaming when needed, etc).  We don't require new TUs to
> do everything perfectly, and nothing is ever perfect anyway.  There's
> always something new to learn.

I'm not talking about expecting perfection, I'm seeing consistent issues that
point to a possible misunderstanding on how packaging is handled. That is a
cause for concern and worth being brought up.

> 
> Regarding the PGP checks, there is no question that they are very useful
> and desirable for packages in our repositories.  I am sure that Daniel
> will make efforts to add PGP checks wherever possible when he moves
> packages to [community].  But for the AUR, the situation is a bit
> different (in my opinion) because I know it throws some people off when
> they don't know that they have to import a PGP key to build the package.
> I tend to include them anyway now, but I would understand that somebody
> would like not to.

The situation in the AUR is no different at all. Downgrading PKGBUILDs to
appease users who don't want to learn anything is is a serious problem and is a
cause for grave concerns.

> 
> Anyway, for the specific case of apache-flex-sdk, look at the comments:
> the signing key simply seemed to have expired.
> 
> Baptiste


pgpjvhAnzG3Ge.pgp
Description: OpenPGP digital signature

Re: [aur-general] TU Application: Daniel Bermond (dbermond)

[Doug Newgard via aur-general]

On Sun, 14 Oct 2018 18:35:53 -0300
Daniel Bermond via aur-general  wrote:

> I usually don't use pgp on my aur packages because people tend to
> complain a lot about building issues. They fail to handle the keys and
> start complaining to the packager, and this is a big stress. When
> dealing with repository packages this is another story, of course. Since
> this was raised as a main issue, I'll be adding the pgp checks back again.
> 
> I know that we should not use msg2 because it's makepkg internal. But it
> helps to diagnose user problems by helping to identify at which stage a
> build error is happening. For sure I can remove it if required to. ;)

You're not helping your case. The pgp issue has well been covered, so I'll skip
that for now.

For msg2, the response that you know you're not supposed to use it but decided
to anyway doesn't inspire confidence. printf or echo would have done the job
just as well, but you used something you knew you weren't supposed to?

To clarify, as I originally said, your PKGBUILDs that I spot checked are
generally good and I think you could make a good TU. You seem to be willing to
work with people, and that's a good sign. There's just some things that make me
wonder if now is the time.

Doug


pgpZqnEYvOlHw.pgp
Description: OpenPGP digital signature

Re: [aur-general] TU Application: Daniel Bermond (dbermond)

[Doug Newgard via aur-general]

Decided to take a quick look at your PKGBUILDs, and just a few spot checks
makes me wonder. The first one I click on is apache-flex-sdk, I see that you
aren't the original submitter, so I look at the git log and see that the first
thing you did when taking over this was to remove pgp checks from the source.
WTF. Look at the PKGBUILD, see a totally useless prepare function, ok, not a
big thing. Let's check another one, clicked on flif, see msg2s being used for
no reason and bad conflicts. Click on a couple more, see that those issues
aren't mistakes, they're a fundamental misunderstanding.

Maybe my perception was colored by that really bad decision to remove the pgp
checks, and while the PKGBUILDs are mostly fine, there seems to be things about
packaging that you don't understand yet. Is it time to become a TU already?


pgplsmnZ8qVUJ.pgp
Description: OpenPGP digital signature

Re: [aur-general] TU Application - Konstantin Gizdov

[Doug Newgard via aur-general]

I must point out this very recent mailing list thread:
https://lists.archlinux.org/pipermail/aur-general/2018-September/034279.html

In this thread, you:

1) whine about someone taking over *your* packages, because you're the one that
knows them and has cared for them and, after all, they're YOURS.

2) whine about how things were handled on the bug tracker, thinking that this
whining is how things get done. It's not.

3) Tell bald faced lies about how things transpired on the bug tracker.

You really think this makes you TU material? Really?



pgp1kq7mkCEqE.pgp
Description: OpenPGP digital signature

Re: [aur-general] Automatic package version

[Doug Newgard via aur-general]

On Fri, 26 Oct 2018 19:26:43 +0300
Shay Gover via aur-general  wrote:

> Hi,
> 
> I have a pakage in AUR that uses an automatic package versioning. I use a
> pkgver() and pkgrel().
> However I just noticed that the package version in AUR is old. I checked
> the functions and everything is OK. Running makepkg gives the correct
> version.
> 
> The package is:
> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=virtualbox-ck-modules
> 
> Ideas?
> 
> Thanks,
> 
> Shay Gover

You didn't update .SRCINFO

Re: [aur-general] Automatic package version

[Doug Newgard via aur-general]

On Fri, 26 Oct 2018 21:33:12 +0300
Shay Gover via aur-general  wrote:

> >
> > Date: Fri, 26 Oct 2018 19:09:36 +0100
> > From: Konstantin Gizdov 
> > To: aur-general@archlinux.org
> > Subject: Re: [aur-general] Automatic package version
> > Message-ID: <8cf660ad-d2cc-d275-7678-cbb32b0d4...@kge.pw>
> > Content-Type: text/plain; charset="utf-8"
> >
> > On 26/10/2018 19:07, Shay Gover via aur-general wrote:  
> > >> Message: 1
> > >> Date: Fri, 26 Oct 2018 18:29:59 +0200
> > >> From: Michael Kogan 
> > >> To: "Discussion about the Arch User Repository (AUR)"
> > >> 
> > >> Subject: Re: [aur-general] Automatic package version
> > >> Message-ID:
> > >> <  
> > >> calsov+bp9ez_v_wfsv5mz9muaringnczxwyyx_1endofkj_...@mail.gmail.com>  
> > >> Content-Type: text/plain; charset="UTF-8"
> > >>
> > >> First thing coming to mind: Did you possibly forget to update the  
> > .SRCINFO  
> > >> file?
> > >>  
> > > Hoe do I update it from the PKGBUILD itself?  
> >
> > I normally have an alias like this:
> >
> > $ which updpkgs
> > updpkgs: aliased to 'updpkgsums && makepkg --printsrcinfo > .SRCINFO'
> >
> That's from outside the PKGBUILD. I already did that when I uploaded the  
> package a month ago. But since then the package was updated. It's not
> automatic versioning if I need to update SRCINFO every time.

If that's what you're looking for, this is simple.

There is no automatic versioning at all.

Re: [aur-general] TU Application - Konstantin Gizdov

[Doug Newgard via aur-general]

On Fri, 26 Oct 2018 17:29:31 +0100
Konstantin Gizdov  wrote:

> On 26/10/2018 15:27, Doug Newgard via aur-general wrote:
> > I must point out this very recent mailing list thread:
> > https://lists.archlinux.org/pipermail/aur-general/2018-September/034279.html
> >
> > In this thread, you:
> >
> > 1) whine about someone taking over *your* packages, because you're the one 
> > that
> > knows them and has cared for them and, after all, they're YOURS.  
> 
> I did no such thing. I opened the thread by thanking Felix for picking
> them up and asked a few questions about the plans for the packages and
> how to pass on what I know, because I was having trouble doing that over
> the bug tracker. What ensued after (the responses) was not my doing. I
> tried to respond to every and all comments respectfully and I think you
> will find a through discussion was had and a lot of details were sorted.
> 
> Part of that was revealing that the ROOT stack was being picked up -
> yes, I care about it as it directly affects my profession and I've given
> thorough reasons why. I **never claimed the packages were mine** - if
> you talk about the usage of the word 'my', it clearly refers to me being
> the maintainer. I said I've put work into them, continue to do so and
> wanted to make sure I can pass that on in full. My TU application is me
> trying to do that.

You did thank Felix, but then went on to make your true intent extremely clear.
You specifically ask why your packages were moved (there doesn't have to be a
reason), and say things like:

"The reason I'm asking is because over the years I've added and been
maintaining some professional software and these packages are part of that
chain. Colleagues in the field have become accustomed to me for packaging
with care and updating with new features."

The aforementioned thanks would appear to be perfunctory, like saying "No
offense, but you're an idiot". 

Reference:
https://lists.archlinux.org/pipermail/aur-general/2018-September/034279.html

> > 2) whine about how things were handled on the bug tracker, thinking that 
> > this
> > whining is how things get done. It's not.  
> 
> Again, I did no such thing. I explained what happened and asked how can
> I do better. I was told I have to stick to the bug tracker. Thus, I said
> why I think this approach is failing in that particular case and gave
> exampes.
> 
> By the way, it was only because of that email that one of the bugs was
> reopened (by Eli) and fixed, otherwise it was ignored. Seems to me my
> email worked fine.

And this attitude right here is a major problem. One ticket was closed because
it was very clearly not a bug. The second one that was closed was closed based
on the information you gave, the reopen request contained different
information. Based on that, I didn't deny the reopen request and decided to
wait until I got home to try it. In the mean time, Eli took a look at the
request and reopened it.

In the middle of all of that, and completely independently and unrelated, you
sent your email to this list, but you still seem to be under the impression
that it was a good thing and actually accomplished something. I can assure you,
it accomplished nothing good.

> 
> > 3) Tell bald faced lies about how things transpired on the bug tracker.  
> I'm sorry, but this is ridiculous. In the many emails I wrote that
> evening, I got confused about one bug being closed, where it wasn't. You
> tried to call me out for lying and my whole point being wrong, but later
> **you yourself sent a follow up email to correct your own statement**. I
> acknowledged my mistake on the spot. Surely, we can agree all of us make
> mistakes. **In no way or form was I telling bald faced lies.**

So you opened 3 tickets. Two were closed and *one* (1) was denied a reopen. Yet
you claim "I tried to re-open all 3 bugs but was denied with little to no
comment/explanation." There is too much disparity here to be a typo or a
mistake.

Reference:
https://lists.archlinux.org/pipermail/aur-general/2018-September/034286.html


pgpcZVOtZcsFn.pgp
Description: OpenPGP digital signature

Re: [aur-general] TU Application - Konstantin Gizdov

[Doug Newgard via aur-general]

On Fri, 26 Oct 2018 18:09:50 +
Maksim Fomin via aur-general  wrote:

> ‐‐‐ Original Message ‐‐‐
> On Friday, October 26, 2018 8:23 PM, Doug Newgard via aur-general 
>  wrote:
> >
> > You did thank Felix, but then went on to make your true intent extremely 
> > clear.
> > You specifically ask why your packages were moved (there doesn't have to be 
> > a
> > reason), and say things like:
> >
> > "The reason I'm asking is because over the years I've added and been
> > maintaining some professional software and these packages are part of that
> > chain. Colleagues in the field have become accustomed to me for packaging
> > with care and updating with new features."
> >
> > The aforementioned thanks would appear to be perfunctory, like saying "No
> > offense, but you're an idiot".
> >
> > Reference:
> > https://lists.archlinux.org/pipermail/aur-general/2018-September/034279.html
> >  
> 
> I see no such attitude. After reading this and previous thread the quote 
> above expresses what happened quite neutrally: AUR package was used by group 
> of people, after moving package to community, some things (important to that 
> group) became broken - presumably because of some changes in community 
> package. There is nothing wrong in telling that one person was maintaining 
> package and his colleagues became accustomed to that package.

Except there was nothing wrong with the packages in Community, nothing had
broken.

Re: [aur-general] Package present in aur-git, but not in the aur

[Doug Newgard via aur-general]

On Sun, 11 Nov 2018 15:37:00 +0100
pianoslum via aur-general  wrote:

> Hi@all,
> 
> I searched whether elster (a program for German tax declaration) was 
> present in the aur (https://aur.archlinux.org/packages/?K=elster) and 
> found out it wasn't. When I finished my own PCKBUILD and tried to upload 
> it, I noticed that there already was a git repo with that name 
> (ssh://a...@aur.archlinux.org/elster.git).
> 
> How can that be?
> 
> While the original script is a meta package only, mine will download and 
> install the latest version of the package via wine.
> 
> Should I ask for deletion or what could I do?
> 
> Original package maintainer is in CC.
> 
> Cheers!

Git repos are not deleted when packages are.

You just clone the repo, make your changes, and push it.

Re: [aur-general] PKGBUILD git remote branch issue

[Doug Newgard via aur-general]

On Wed, 07 Nov 2018 15:16:22 +0100
Ralf Mardorf  wrote:

> "Configure finished, type 'make' to build.
> /usr/src/claws-mail-gtk3-git/PKGBUILD: line 85: --enable-ldap: command
> not found
> ==> ERROR: A failure occurred in build().  
> Aborting..."

That error is a mistake in the PKGBUILD, nothing to do with the checkout.

Re: [aur-general] PKGBUILD git remote branch issue

[Doug Newgard via aur-general]

On Wed, 07 Nov 2018 15:47:59 +0100
Ralf Mardorf  wrote:

> On Wed, 2018-11-07 at 08:40 -0600, Doug Newgard via aur-general wrote:
> > On Wed, 07 Nov 2018 15:16:22 +0100
> > Ralf Mardorf  wrote:
> >   
> > > "Configure finished, type 'make' to build.
> > > /usr/src/claws-mail-gtk3-git/PKGBUILD: line 85: --enable-ldap: command
> > > not found  
> > > ==> ERROR: A failure occurred in build().
> > > Aborting..."  
> > 
> > That error is a mistake in the PKGBUILD, nothing to do with the checkout.  
> 
> The PKGBUILD tries to build an outdated release, that is why it fails.
> When building the latest release, it works with "--enable-ldap".

No, it fails because you have a return before --enable-ldap

Re: [aur-general] RFC: PKGBUILD for nixnote2-git

[Doug Newgard via aur-general]

On Sat, 6 Oct 2018 23:09:57 +0700
Tom Hale  wrote:

> I want avoid the latest commit for greater stability.
> 
> Updated attachment: I've dropped the "-git" from the pkgname as I build 
> from the latest annotated tag.
> 
> On 6/10/18 10:48 pm, Doug Newgard via aur-general wrote:
> > -git PKGBUILDS need to build from the latest commit on master or the default
> > branch, not from a tag. I didn't review the whole thing because the entire
> > concept is invalid.
> 

Which is also invalid, as you're now passing them off as stable releases when
they are not. You'd also have to manually update the AUR every time there's a
release anyway, so it's pointless.

Re: [aur-general] RFC: PKGBUILD for nixnote2-git

[Doug Newgard via aur-general]

On Sat, 6 Oct 2018 22:41:43 +0700
Tom Hale  wrote:

> I took over the disowned package nixnote2-git.
> 
> Attached is my first attempt at a PKGBUILD. I would appreciate 
> constructive feedback.
> 
> Thanks in advance,
> 
> -- 
> Tom Hale

-git PKGBUILDS need to build from the latest commit on master or the default
branch, not from a tag. I didn't review the whole thing because the entire
concept is invalid.

Re: [aur-general] rfc: pkgbuild for prospect releng-tool

[Doug Newgard via aur-general]

On Tue, 5 Mar 2019 23:53:10 -0700
Brett Cornwall via aur-general  wrote:

> On 2019-03-06 01:24, James Knight via aur-general wrote:
> >Hello -- new user to AUR and hoping if anyone is willing to review a
> >PKGBUILD [1] definition for me. I have been reading PKGBUILD [2] and
> >"AUR - Submitting packages" [3] documents, which the latter document
> >suggests to "... submit the PKGBUILD to the AUR mailing list ... for
> >public review before adding it to the AUR".  
> 
> Hello, and welcome!
> 
> Great job doing your research. You've already gone above and beyond with 
> the above.
> 
> 
> >pkgname=releng-tool
> >pkgver=0.1  
> 
> I don't see any releases on the upstream github. Where'd you get this 
> 0.1?
> 
> >pkgrel=1
> >pkgdesc='tool to assist in the release engineering of a project'  
> 
> Capitalize the T!
> 
> >url='https://releng.io/'
> >arch=('any')
> >license=('BSD')  
> 
> I don't see this license in the project. It needs to be in the project, 
> and if it is indeed BSD licensed you need to copy the license to 
> "$pkgdir/usr/share/licenses/$pkgname/" [1]

License is in the repo and is already being installed. Nothing to see here.

> 
> >makedepends=(
> >'python'
> >)  
> 
> You're using python-setuptools, so you'll want to set that in 
> makedepends instead of python.

Also missing git as a makedep. Might want to build in a clean chroot and see
what else you're missing. python shouldn't be in the makedeps, as it should be
in the global deps array, as stated below.

> 
> >source=("$pkgname-$pkgver::git+https://github.com/releng-tool/releng-tool.git#tag=v$pkgver;)
> >  
> 
> I see that you're the maintainer of upstream; Why not create a release 
> on Github and then download the tarball here? Typically, pulling sources 
> via git is for '-git' packages.

git is fine for release packages.

> 
> >sha512sums=('SKIP')  
> 
> Having a tarball release will mean that you can have checksum 
> verification as well.
> 

git does checksumming.

> [...]
> 
> >package() {
> >  depends=('python')  
> 
> The depends() should just go to the top alongside makedepends for this 
> package. You probably saw this in the examples for the python packaging 
> standards, but this is typically used for a 'split package', i.e. using 
> one PKGBUILD to build versions for both python2 and python3. Since 
> you're only building for python 3 depends() should go to the top.
> 
> >  cd "$pkgname-$pkgver"
> >  python setup.py install --root="$pkgdir" --optimize=1  
> 
> Go ahead and add a --skip-build here since you already built earlier.
> 
> [...]
> 
> >  install -dm 755 "$pkgdir/usr/share/bash-completion/completions"
> >  install -m644 scripts/releng-tool-completion 
> >"$pkgdir/usr/share/bash-completion/completions/releng-tool"  
> 
> No need to create the directory beforehand; This can be shortened into:
> 
> install -Dm644 scripts/releng-tool-completion 
> "$pkgdir/usr/share/bash-completion/completions/releng-tool"
> 
> 
> 
> 
> Check out the 'namcap' package in [extra] if you haven't already. It's 
> certainly a fallible tool but it can help with maintenance quality.
> 
> Also, check out the Python packaging guidelines: 
> https://wiki.archlinux.org/index.php/Python_package_guidelines#setuptools
> 
> 
> [1] https://wiki.archlinux.org/index.php/PKGBUILD#license

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 ?

[Doug Newgard via aur-general]

On Tue, 16 Apr 2019 15:19:37 +0200
Lone_Wolf  wrote:

> Hi,
> 
> 
> recently a mesa developer contacted me and asked me to change mesa-git 
> to depend on released llvm/clang instead of llvm/clang trunk.
> 
> He did convince me there's a demand for such a package.
> 
> 
> Currently people wanting to build mesa-git against released versions 
> need to edit the pkgbuild and make a few changes (not documented atm).
> 
> I have been building mesa trunk against llvm trunk since mesa started 
> using llvm and tailored the package to my personal workflow and style.
> 
> Adjusting the mesa-git PKGBUILD to use repo llvm/clang would force me to 
> either change my workflow or maintain a package I don't use in that form.
> 
> I'd probably stop maintaining mesa-git.
> 
> 
> I do feel there's an underlying issue here that concerns us all as 
> stated in the title:
> 
> Are AUR VCS packages that depend on AUR VCS packages from other projects 
> a good idea and who should decide on that?
> 
> 
> Lone_Wolf

Is there any reason it depends specifically on the -git package? Most of the
time, you depend on the release package and those that use the -git version
just build against that, no other changes needed.

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 ?

[Doug Newgard via aur-general]

On Wed, 1 May 2019 01:07:43 +0200
Lone_Wolf  wrote:

> Thanks for speaking freely, scimmia.
> 
> The env var idea has been thrown out of the window.
> 
> 
> 
> Time to summarize and tally .
> 
> Option A. mesa-git depends on llvm trunk and PKGBUILD editing is needed 
> for those that want to build against stable llvm.
> 
> Option B. mesa-git depends on llvm stable and those that want to build 
> against llvm trunk need to edit the PKGBUILD.

You're still not getting it. The diff you gave shows that the only differences
are in the depends and madedepends arrays. If that's the only difference, then
there *IS NO DIFFERENCE*. A dep on "llvm-libs" is satisfied by llvm-libs-git,
so it works in both cases, just as is intended. There is no editing the
PKGBUILD needed by users of either option. That's how "provides" works.

Scimmia

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 ?

[Doug Newgard via aur-general]

On Wed, 1 May 2019 12:38:41 +0200
Lone_Wolf  wrote:

> On 01-05-2019 05:18, Doug Newgard via aur-general wrote:
> > You're still not getting it. The diff you gave shows that the only 
> > differences
> > are in the depends and madedepends arrays. If that's the only difference, 
> > then
> > there *IS NO DIFFERENCE*. A dep on "llvm-libs" is satisfied by 
> > llvm-libs-git,
> > so it works in both cases, just as is intended. There is no editing the
> > PKGBUILD needed by users of either option. That's how "provides" works.
> >
> > Scimmia  
> 
> 
> I know how conflicts/provides/replaces work.
> 
> It seems I failed to make clear that the major problems I see occur at 
> install and runtime, NOT at buildtime.
> 
> Here's another attempt to explain that.
> 
> 
> Hypothetical example
> 
> Assumptions :
> 
> mesa-git depends on llvm and llvm-libs
> 
> AUR only has one mesa-git package
> 
> User builds in clean chroot with devtools
> 
> User wants mesa feature X, finds they need to run mesa-git for that.
> 
> 
> User clones aur mesa-git and builds with extra-x86_64-build
> 
> makepkg sees llvm / llvm-libs dependencies are satisfied by extra/llvm 
> and extra/llvm-libs.
> 
> mesa-git is build against those versions
> 
> user installs mesa-git, pacman sees llvm-libs is needed and finds 
> extra/llvm-libs installed.
> 
> 
> User runs mesa-git, realizes feature X is not working.
> 
> Investigation reveals feature X is not supported by stable llvm, user 
> needs to built mesa-git against llvm-git.
> 
> User builds llvm-git + llvm-libs-git in clean chroot.
> 
> In order to use the llvm-git for mesa-git building they add the packages 
> manually to extra-x86_64-build.
> 
> They now have a mesa-git build against llvm-git and install that.
> 
> pacman sees mesa-git depends on llvm-libs , and that's satisfied by 
> extra/llvm-libs.
> 
> user tries again , mesa-git crashes.
> 
> 
> User asks for help on forum.
> 
> Someone that understands how mesa and llvm interact, suggests they try 
> installing llvm-libs-git .
> 
> User installs that, mesa-git works and feature X also works .
> 
> User is happy, tries to figure out how to avoid similar issues in future.
> 
> 
> Someone points out that the mesa-git crash was caused by pacman being 
> unaware which llvm-libs binary version was needed.
> 
> Simple solution : edit depends in PKGBUILD to have mesa-git depend on 
> llvm-git / llvm-libs-git .

Full stop. Solution is not to edit the PKGBUILD, solution is for the
theoretical user to not be replacing system libraries when they don't have a
clue what they're doing.

You're trying to overcomplicate the system to account for user stupidity. This
is Arch, stop doing that.

Scimmia

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 ?

[Doug Newgard via aur-general]

On Tue, 30 Apr 2019 01:32:58 +0200
Lone_Wolf  wrote:

> Thanks for all replies.
> 
> 
> I've thought about this and think I have found a way that will work for 
> all users.
> 
> 
> My idea is to introduce a new environment variable, mesa_use_llvm .
> 
> It can have the following values :
> 
> 1 > use aur llvm-lw-git and co
> 
> 2 > use aur llvm-git and co
> 
> 3 > use lordheavy unoffical repo llvm-svn and co
> 
> 4 > use [extra] llvm and co
> 
> 
> If mesa_use_llvm is indefined or something else then 1,2,3,4 fallback to 
> value 1.
> 
> In the PKGBUILD I'll use depends+= / makedepends+= to add the correct 
> packages.
> 
> 
> Choosing which llvm to built against is then setting an environment 
> variable.
> 
> Do you guys and girls think this way is a good idea ?
> 
> 
> Lone_Wolf

No, it's not. You're WAY overcomplicating things. The llvm variants you mention
should all "provide" llvm, so you just depend on that and can use whatever you
want.

Scimmia

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 ?

[Doug Newgard via aur-general]

On Tue, 7 May 2019 13:42:05 -0400
Eli Schwartz via aur-general  wrote:

> On 5/3/19 11:41 AM, Doug Newgard via aur-general wrote:
> > On Fri, 3 May 2019 11:32:57 -0400
> > Eli Schwartz via aur-general  wrote:  
> >> Apparently, he *really* thinks that that is a bad idea and an inferior
> >> mesa-git experience.
> >>  
> > 
> > And apparently the mesa developers disagree. Remember how this thread 
> > started.  
> 
> This logic is automatically invalid, no ifs ands or buts.
> 

Your argument is that is makes for an unacceptable mesa experience. The
experience intended by upstream is EXTREMELY valid.

> Upstream developers *by definition* have different priorities from
> downstream users. Furthermore, the world is full of projects run by
> upstreams who have unrealistic and sometimes ridiculous expectations;
> anyone who has packaged a lot of software should know this.
> 
> If the mesa developers disagree, that's fine. But it doesn't actually
> mean anything. What would mean something is their rationale for
> disagreeing. Just like any other upstream software.

So how upstream intends their software to work doesn't mean anything? Try again.

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 ?

[Doug Newgard via aur-general]

On Tue, 7 May 2019 13:42:16 -0400
Eli Schwartz via aur-general  wrote:

> 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.

Which negates the maintainers entire argument.

Re: [aur-general] Kernel version requirement

[Doug Newgard via aur-general]

On Tue, 07 May 2019 15:56:47 -0400
Mark Weiman  wrote:

> Is there a plan to change this to include such a line in the packages?
> 
> Mark

No, because they don't provide the same thing as the linux package.

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 ?

[Doug Newgard via aur-general]

On Fri, 3 May 2019 11:32:57 -0400
Eli Schwartz via aur-general  wrote:

> On 5/3/19 11:25 AM, Bruno Pagani wrote:
> > Yes, and he can solves that by *pinning a comment telling so*. ;)  
> 
> Pinning a comment telling people how to get the default expected User
> Experience in a non-default way, sucks.
> 
> The package maintainer thinks that the average user will dislike the
> resulting default default user experience, will experience crashes, will
> experience missing features, etc. -- and as a result the package
> maintainer has *flatly* refused under any and all circumstances to
> continue maintaining the package that he has, apparently, been
> maintaining to many peoples' satisfaction, for the last four years.
> 
> Apparently, he *really* thinks that that is a bad idea and an inferior
> mesa-git experience.
> 

And apparently the mesa developers disagree. Remember how this thread started.

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 ?

[Doug Newgard via aur-general]

On Fri, 3 May 2019 10:04:39 -0400
Eli Schwartz via aur-general  wrote:

> On 5/1/19 10:53 AM, Doug Newgard via aur-general wrote:
> > On Wed, 1 May 2019 12:38:41 +0200
> > Lone_Wolf  wrote:  
> >> Assumptions :
> >>
> >> mesa-git depends on llvm and llvm-libs
> >>
> >> AUR only has one mesa-git package
> >>
> >> User builds in clean chroot with devtools
> >>
> >> User wants mesa feature X, finds they need to run mesa-git for that.
> >>
> >>
> >> User clones aur mesa-git and builds with extra-x86_64-build
> >>
> >> makepkg sees llvm / llvm-libs dependencies are satisfied by extra/llvm 
> >> and extra/llvm-libs.
> >>
> >> mesa-git is build against those versions
> >>
> >> user installs mesa-git, pacman sees llvm-libs is needed and finds 
> >> extra/llvm-libs installed.
> >>
> >>
> >> User runs mesa-git, realizes feature X is not working.
> >>
> >> Investigation reveals feature X is not supported by stable llvm, user 
> >> needs to built mesa-git against llvm-git.
> >>
> >> User builds llvm-git + llvm-libs-git in clean chroot.
> >>
> >> In order to use the llvm-git for mesa-git building they add the packages 
> >> manually to extra-x86_64-build.
> >>
> >> They now have a mesa-git build against llvm-git and install that.
> >>
> >> pacman sees mesa-git depends on llvm-libs , and that's satisfied by 
> >> extra/llvm-libs.
> >>
> >> user tries again , mesa-git crashes.
> >>
> >>
> >> User asks for help on forum.
> >>
> >> Someone that understands how mesa and llvm interact, suggests they try 
> >> installing llvm-libs-git .
> >>
> >> User installs that, mesa-git works and feature X also works .
> >>
> >> User is happy, tries to figure out how to avoid similar issues in future.
> >>
> >>
> >> Someone points out that the mesa-git crash was caused by pacman being 
> >> unaware which llvm-libs binary version was needed.
> >>
> >> Simple solution : edit depends in PKGBUILD to have mesa-git depend on 
> >> llvm-git / llvm-libs-git .  
> > 
> > Full stop. Solution is not to edit the PKGBUILD, solution is for the
> > theoretical user to not be replacing system libraries when they don't have a
> > clue what they're doing.
> > 
> > You're trying to overcomplicate the system to account for user stupidity. 
> > This
> > is Arch, stop doing that.  
> 
> I'm still not really seeing what the problem here is.
> 
> Lone Wolf's point here, is that mesa-git results in different codegen
> and different features, if the build-time compilation environment is
> llvm-git.
> 
> It's not unreasonable to want the resulting package to have technically
> correct dependency linkages when its compilation environment results in
> *different dependencies*.

No different than an soname bump.

Re: [aur-general] request for action on orphan request

[Doug Newgard via aur-general]

On Fri, 16 Aug 2019 20:15:34 +
Joel Shapiro via aur-general  wrote:

> Hi all, 
> 
> I (jshap[1]) put in a request on `nvidia-docker`[2] for it to be orphaned 2 
> weeks ago and seeing as some reasonable time has gone by I'd like to ask that 
> the request be granted. 
> It is preventing me from being able to delete a dead package[3]. 
> 
> Thanks,
> Joel

Orphan requests have a 2 week waiting period, so you're just now coming up. No
need for this email.

Re: [aur-general] AUR Merge request for kubebox and kubebox-bin

[Doug Newgard via aur-general]

On Fri, 6 Dec 2019 12:47:22 -0500
David Rodriguez via aur-general  wrote:

> Hello,
> 
> I am the maintainer of both kubebox and kubebox-bin. It has been
> brought to my attention that kubebox, since it is not built from
> source, would be more appropriately named "kubebox-bin". I've already
> uploaded the new package and am requesting a merge for comments and
> votes.
> 
> Thank you,
> David Rodriguez

There is a link on the right side of the AUR package page for package requests.
This is how you request merging.

Re: [aur-general] xmrig-amd package deleted?

[Doug Newgard via aur-general]

On Mon, 25 Nov 2019 13:14:36 -0500
Matt Harrison via aur-general  wrote:

> Hi,
> 
> It looks like the xmrig-amd [1] was recently deleted from the AUR. I don't
> currently see any mention anywhere of why or how it was deleted, so I am
> wondering why it was deleted?
> 
> I can re-created it from the archive and maintain it myself, but I wanted
> to check first to not step on anyone's feet if it was deleted for a
> specific reason.
> 
> Thanks,
> Matt Harrison
> 
> [1] https://aur.archlinux.org/packages/xmrig-amd/

https://lists.archlinux.org/pipermail/aur-requests/2019-November/034978.html

Re: [aur-general] review of getax2019 PKGBUILD

[Doug Newgard via aur-general]

On Sun, 23 Feb 2020 13:17:44 +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,
> 

You should not be downloading anything in the prepare function if it can be
avoided. $_pkgver is being added to the downloaded filename, does it not
contain the updates? If this is really necessary, it should all be in the
source array.

Pick a variable style and stick with it. Some have braces, some don't.

Make sure to quote all variables that you don't control and could contain
spaces.

Get rid of the empty build function.

Why call cp 3 times when once would do it?

Don't use tabs for alignment (sha256sums).

aur-requests is a mailing list for automated listing of requests for people to
reply to. You don't send new threads to it directly, and the requests in
question are only deleting package or merging them into other packages, it's
not what you want here. You just need to use the comments.

Re: [aur-general] Anydesk 404 not found

[Doug Newgard via aur-general]

On Sun, 1 Mar 2020 16:36:04 +0330
Amin Vakil  wrote:

> This page gives 404 not found:
> 
> https://aur.archlinux.org/packages/anydesk/
> 
> But this url works:
> 
> https://aur.archlinux.org/anydesk.git
> 
> What am I missing?
> 

Both 404 in a browser.

If you're cloning the second one with git, the repo doesn't get removed when a
package is deleted. That's expected.

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

[Doug Newgard via aur-general]

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.

Re: [aur-general] Reply to your request SGE

[Doug Newgard via aur-general]

On Mon, 12 Oct 2020 20:30:11 -0400
Manhong Dai via aur-general  wrote:

> Thanks a lot for your reply! I commented on the package hoping the new
> maintainer can return the maintainer  to me.
> 
> But I am willing to answer your question.
> 
> A pull request needs a lot of effort to check. The pull request changed a
> lot of files and it is not that easy to see if the change is not malicious.
> That being said, now do you understand that why I would trust a 'trusted
> user' more? After all, 'trusted user' was named so for a reason, right?
> 
> If changing package status to 'out of state ' doesn't send any
> notification, it is SCARY. Not everybody can  check out the aur email list
> everyday and we all work on there packages for free.  Why it is scary? What
> if a malicious user submit a ticket like this and the become the maintainer
> for a package that is not popular but could access sensitive data, like SGE?
> 
> Think about it, the disowning already sends notification, why doesn't the
> warning 'out of state' send the email?
> 
> On another note, maybe the AUR package should be named like github does.
> Adding the user name to the path will save such headache for both you and
> me..
> 
> 
> Best,
> Manhong
> Sent from phone

You didn't read a single word I wrote. Don't bother replying if you can't read.

Re: [aur-general] Reply to your request SGE

[Doug Newgard via aur-general]

On Mon, 12 Oct 2020 19:26:07 -0400
Manhong Dai via aur-general  wrote:

> Hi Freswa,
> 
>   Somebody pointed me to your reply in the list. I didn't even know that
> the request in the AUR request system was sent to this email list, nor I
> know such an email list existed.
> 
>   I agree that you think you already gave enough explanation from your
> point of view. However, please think about it in my shoes, I I didn't even
> know such an email list existed before I sent the last request through the
> AUR website, and I just registered it about an hour ago to appeal. If you
> think I spammed this request system, I am sorry for it. But from my point
> of view, I have been extremely patient and following the ladder to appeal,
> because I didn't get any email or any response on the AUR website, which
> just says one word 'rejected'.
> 
>   I am also a very responsive package maintainer. You can check out my
> other packages, as long as other people submitted a suggestion, I responded
> the second day, and accepted their suggestions.
> 
>   In terms of the package SGE, I just searched my email again but didn't
> find any email saying that the package is marked as out-of-date. It will be
> hard to believe that a package that was submitted just four months ago is
> already marked as out of date. It worked on a cluster of all our Arch Linux
> nodes four months ago, and it is still working on the latest Arch Linux. It
> worked on both new node installation and old node upgrade . I would never
> have thought to check the AUR website to see if I am still a maintainer.
> All I got was the two emails, one saying it was disowned, the other saying
> it was adopted, and they are 19 minutes apart.
> 
>   Now I understand that each AUR package maintainer should join the email
> list and keep watching it. Given this special circumstance, can I get the
> maintainer status for the package SGE back?
> 
> Best,
> Manhong

And the comment left on the AUR page, that you would have gotten a notification
from? They were right, the PKGBUILD was in absolutely terrible shape. Nobody
said it was out of date, just that it very, very badly needed fixing and you
were ignoring it. You would have then gotten notifications on Sept 19th when it
was first requested that it be orphaned, on Oct 6th when a second request the
it be orphaned was filed, and on Oct 10th when it was requested for a 3rd time
that it be orphaned.

Note that none of those notifications require you to be subscribed to any
mailing list. They were sent directly to you.

With the state of the PKGBUILD and no response, removing the maintainer was the
right thing to do, without question.

Re: [aur-general] Reply to your request SGE

[Doug Newgard via aur-general]

On Mon, 12 Oct 2020 20:01:45 -0400
Manhong Dai via aur-general  wrote:

> The comments were sent to me indeed.  However, I didn't receive any email
> notification about the package is marked as out of state.

And what in the world does "out of state" even mean? Of course there's no
notification for it, it's not a thing.

> 
> The comment is just a simple 'bad taste' without any link or other advice.
> The commenter is not a trusted user either and thus I won't simply accept
> the pull request without going through the change one by one to be on the
> safe side. I always compile and test the package during our cluster
> upgrade, which happens once or twice per year. After all, the package works.

Without any link or other advice, but it had a pull request. You're
contradicting yourself here.

You think you can ignore people just because they're not a TU? Think again.

Saying the package works is not a defense. You couldn't even get something as
simple as the pkgver right.

> 
> Now, let me repeat it again, I didn't receive any notification when the
> package was marked as out of state.  I just searched my email again.

And again, "out of state" is not a thing.

> 
> You can see I recently updated my other three packages per other people's
> suggestions. I acted very quickly, if the comment is reasonable and not as
> simple as a 'bad taste'. If other users are not satisfied with my package,
> they can always fork and put a link under my package, instead of 'robbing'.
> 
> Now , all things considered, can I get the maintainer status back?
> 
> 
> Best,
> Manhong
> Sent from phone


And stop top posting.
https://wiki.archlinux.org/index.php/Code_of_conduct#Top_posting

Re: [aur-general] Reply to your request SGE

[Doug Newgard via aur-general]

On Mon, 12 Oct 2020 22:57:52 -0400
Manhong Dai via aur-general  wrote:

> You are right that I don't know what 'out of state' or 'out of date' or
> 'out of whatever' is. All I know is that I suddenly lost the ownership and
> will have to change my cluster maintenance code tomorrow.
> 
> In terms of pkgver or pkgbuild.  Now you said nobody cares about pigver,
> guess who said this sentence below?
> 'You couldn't even get something as simple as the pkgver right'
> 
>   It turned out I can read and actually remember

Then try reading again, as that's not what I said at all. You either have a
serious issue with reading comprehension or you're just making things up now.

And you're STILL violating the rules of just about every mailing list out
there, even after being told twice.

Re: [aur-general] Reply to your request SGE

[Doug Newgard via aur-general]

On Mon, 12 Oct 2020 22:38:02 -0400
Manhong Dai via aur-general  wrote:

> I actually did read your email. You said I cannot get a simple thing such
> as pkgver right.
> 
> Let me explain to you, from your point of view, you certainly want to have
> some rule or guideline to make all the package  has the same standard. That
> is understandable and it is what make Arch Linux popular. I would love to
> be compliant with the rule whenever I have the resource, and I did with all
> other my AUR packages.
> 
> From my point of view, a pkgver is not the point here. I do need to make my
> modified SGE package can be compiled with the latest SSL, GCC, other Linux
> contribution, and can be used to upgrade an old node without losing
> configuration. No matter how bad a pkgver is defined, an Arch Linux with a
> working SGE is away better, right?
> 
> The problem is actually not on my side. Your request system has my email
> address, I sent you a request after the package was adopted, some
> bystanders figured  out I didn't get any reply and sent your reply to me,
> That is when I knew that the request is also in the mail list, and such
> email list exists..
> 
> Because you are attacking my capability, and I believe everybody who can
> read will know your claim is actually baseless, I did ignore your personal
> attack in my previous email.
> 
> Yes, I can say sorry about ignoring hat.
> 
> 
> Best,
> Manhong
> Sent from phone
> 

So you read it and you're STILL top posting in violation of the rules. And
making up something called "out of state" which doesn't exist. And claiming
that you have to be on a mailing list when it's been explained, multiple times,
that you don't. You claim you're reading, now try understanding.

Nobody cares what your point of view is on pkgver. It's obvious to pretty much
anyone that's ever written, or even read, a PKGBUILD.

Re: [aur-general] TU application - raster

[Doug Newgard via aur-general]

On Mon, 24 Aug 2020 14:09:50 -0400
Santiago Torres-Arias via aur-general  wrote:

> On Sun, Aug 23, 2020 at 09:15:34AM +0100, Carsten Haitzler wrote:
> > 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 haven't had a chance to review this application. However, I wanted to
> comment that, on my Archlinux Security capacity, my (admittedly few)
> interactions with the EFL/enlightenment community were incredibly
> nice/responsive.

As someone who had quite a bit of interaction with the community in question,
this is a fair assessment. With few exceptions, they were always ready to
help people debug and took suggestions seriously. Back when Cedric convinced
Raster to switch to Arch, I didn't see this coming, but I'm certainly happy
with this turn of events.

Scimmia



pgp0MOE8WHrTn.pgp
Description: OpenPGP digital signature

Re: [aur-general] Package clonable via git but not on the web interface?

[Doug Newgard via aur-general]

On Mon, 21 Sep 2020 12:14:32 -0400
Ian Denhardt  wrote:

> Hi,
> 
> I recently went looking for a package for [entr][1], didn't find one,
> and so put together a PKGBUILD myself. When I went to submit it I found
> the git repo already exists; if you do:
> 
> git clone ssh://a...@aur.archlinux.org/entr
> 
> You get a non-empty repo that was last updated sometime in 2018, and
> packages version 4.1 of the software. I can't push to the repo since it
> already exists and I am not the maintainer, but there is no
> corresponding package available via the web interface:
> 
> https://aur.archlinux.org/packages/entr
> 
> I am not sure what to make of this. Any insights?
> 
> -Ian
> 
> [1]: http://eradman.com/entrproject/

Yeah, that means that it's been deleted. The underlying git repos don't get
deleted. You can generally just update and push and it'll be back, but you
can't in this case because it was deleted when it was moved to Community.

Scimmia