Re: [aur-general] TU application for Eli Schwartz

[Levente Polyak via aur-general]

On 12/13/2017 01:57 PM, Eli Schwartz via aur-general wrote:
> Hello, all. :)
> 
> My name is Eli Schwartz, better known as eschwartz on the forums[1],
> AUR[2], bugtracker[3], wiki[4] general mailing lists, IRC, and generally
> everywhere I can stick my nose in. With the aid of Bartłomiej
> Piotrowski, I am applying today to become a TU.
> 

Nice to hear you finally surrender resisting, unfortunately it wasn't me
who finally convinced you :p

Running xxarhtna surprisingly lead to some minor things... expected void
here ;)

calibre-installer:
- nothing i would call common to enable and start units or timers on install

fanficfare:
- there is an update for 2.20.0

kindletool:
kindletool-git:
- its GPL3 license, GPL points to GPL2

git-extras:
git-extras-git:
- can't hurt to list some dependencies it uses like gawk etc, makes it
  work better on install in minimal environments like baremetal
  containers. at least i would :P

kindleunpack:
- GPLv3 is not a valid common license, should be GPL3
- package() could get a --skip-build

PS: i *really* hate variables in url= just annoyance -.-*
PPS: good luck

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Packaging all CRAN packages for R

[Levente Polyak via aur-general]

On May 26, 2018 6:04:48 PM GMT+02:00, Alex Branham via aur-general 
 wrote:
>already 130ish R packages on the AUR. I named them r-cran-* rather than
>r-* because 1) it's clearer where the packages are coming from and 2)
>it's a pain to search for r-*
>


Please stop naming packages including where they come from, they should only 
contain its name and language, not the source. We never want cpan for perl, 
pypi for python or whatever. Also it. Doesn't quite make sense to search for 
r2-* at all, either way, please definitively leave cran out of packages names.

Cheers

Re: [aur-general] Moving xss-lock to community

[Levente Polyak via aur-general]

On January 18, 2018 7:26:33 PM GMT+01:00, Pierre Neidhardt via aur-general 
 wrote:
>
>The 100%-cpu issue should be fixed upstream on master (and thus also in
>the -git package).
>I've mentioned this on the wiki:
>

Why not simply backporting it via a patch file then?

Cheers,
Levente 

Re: [aur-general] TU application: Ivy Foster

[Levente Polyak via aur-general]

On February 2, 2018 12:40:57 AM GMT+01:00, Ivy Foster  wrote:
>
>For cgo, since upstream pulled in the patches I submitted, LDFLAGS are
>properly picked up and we have full relro.
>
>libbulletml was a bit tougher. I wound up throwing out Debian's
>patches to upstream's Makefile and just rewriting the Makefile from
>scratch. Hopefully either Debian or the dev will be interested in
>accepting the new Makefile; until word comes back, it's [in the AUR
>git repo][1]. This also grants full relro.
>


Awesome, thanks for upstreaming the problems :)

Re: [aur-general] TU application: Ivy Foster

[Levente Polyak via aur-general]

Hey, good luck and such

Just noticed there are packages that don't properly LDFLAGS resulting in
binaries without full RELRO.
Its good to always checksec the binaries once creating or adopting a new
package and see if everything was setup properly to respect hardening
and other flags like generic archs.
namcap will have such feature soonish

Everything else i had on my list was already mentioned by Eli.

libbulletml:
- whats up with LDFLAGS from makepkg.conf? like -znow?
  if there are options that don't work its better to remove them
  from makepkg.conf LDFLAGS but always use the variable

cgo-git:
- does not respect LDFLAGS leading to a binary without full relro

cheers,
Levente

Re: [aur-general] TU application: Ivy Foster

[Levente Polyak via aur-general]

On January 30, 2018 11:37:42 PM GMT+01:00, Ivy Foster  wrote:
>I'll have some time free tomorrow to get you a proper answer and/or
>fix; for now, I'm just letting you know I got your email!


Hey, any news from respecting LDFLAGS and if needed just purge parts of it? 
I'm specially interested in seeing full relro.

Cheers,
Levente 

Re: [aur-general] Dropping python-colorlog and python2-colorlog

[Levente Polyak via aur-general]

On February 18, 2018 7:27:05 PM GMT+01:00, Pierre Neidhardt via aur-general 
 wrote:
>
>python-colorlog and python2-colorlog just got flagged out-of-date, is
>anyone looking forward to maintaining it in [community]?
>
>Otherwise I'll put it back on the AUR.


Don't quite understand, you just moved them into the repository like 2 month 
ago. Can you explain further why not just bumping it? Any issues? 

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

[Levente Polyak via aur-general]

Naming scheme for vim plug-ins is always the other way around, vim-something 
not something-vim. 
Always prefix them with vim. 

Cheers
Levente

Re: [aur-general] intellij-idea-community-edition

[Levente Polyak via aur-general]

On 8/10/18 8:20 AM, Simon Legner via aur-general wrote:
> Hi Arch!
> 
> (I'm not sure whether I'm posting to the correct mailing list.)
> I'm a happy user of IntelliJ IDEA. Unfortunately, the community
> package intellij-idea-community-edition is out-of-date most of the
> time. As of writing, it has been updated at 2018-07-10 and flagged
> again on 2018-07-12. In the meanwhile, the versions 2018.1.6, 2018.2,
> 2018.2.1 have been released.
> Since I found updates to be smooth, updating the community package
> should be easy as well. Could any TU step in as (co)maintainer of this
> package to bring updates closer to the time?
> 
> Thank you!
> Simon
> 

Hi,

I've spoken to Lukas and am now co-maintaining the package. Together I
believe we will achieve faster update cycles.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] [tu-bylaws][PATCH] extend tu addition discussion period to 14 days

[Levente Polyak via aur-general]

The discussion period is over,
lets give the reviewers and applicants some more time :]

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


cheers,
Levente



signature.asc
Description: OpenPGP digital signature

[aur-general] [tu-bylaws][PATCH] extend tu addition discussion period to 7 days

[Levente Polyak via aur-general]

Just adding this signed mail to authenticate i indeed proposed this
change :)

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

[aur-general] [tu-bylaws][PATCH] extend tu addition discussion period to 7 days

[Levente Polyak via aur-general]

From: anthraxx 

Signed-off-by: Levente Polyak 
---

The discussion period for the addition of a new TU is too short.
After having some chats on this topic with multiple TUs it seemed like
a general consensus to extended the dicussion period to 14 days, hence
this proposal.

5 days are rarely enough to discuss all details with the applicant
taking into account that f.e. lots of packages need to be reviewed. Once
feedback was given to the applicant there shall be enough time to work
through it, potentially research, apply and/or discuss things out of the
feedback.

Given the fact that many people, including the applicant, may be
in the middle of a work week (or otherwise busy), having only 5 days
to do one or multiple feedback loops is unrealistic and too much
pressure. Considering the fact that it is an essential part for a TU
to be able to decide on the vote as well as for the applicant to
have enough time and the possibility to respond properly to the input
an adjusted discussion period of 14 days shall be appropriate.
---
 tu-bylaws.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tu-bylaws.txt b/tu-bylaws.txt
index 27e4804..d32e06c 100644
--- a/tu-bylaws.txt
+++ b/tu-bylaws.txt
@@ -104,10 +104,10 @@ In order to become a TU, one must first find a sponsoring 
TU,
 and arrange privately with them to announce their candidacy on the
 https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general] mailing
 list.  Following the announcement, standard voting procedure commences with a
-discussion period of 5 days, a quorum of 66%, and a voting period of 7 days.
+discussion period of 14 days, a quorum of 66%, and a voting period of 7 days.
 
 
-SVP( addition_of_TU, 5, 0.66, 7 );
+SVP( addition_of_TU, 14, 0.66, 7 );
 
 
 If a candidate is rejected by SVP, they may not reapply to become a Trusted
-- 
2.18.0

[aur-general] [tu-bylaws][PATCH] extend tu addition discussion period to 14 days

[Levente Polyak via aur-general]

I quite definitively should not send patches when being incredibly
tired, of cause the subject should be "14 days" matching what the body
actually describes and changes.

I'm sorry >.>
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Build packages without Arch on pkgbuild.com

[Levente Polyak via aur-general]

On April 7, 2018 8:23:08 AM GMT+02:00, Pierre Neidhardt via aur-general 
 wrote:
>
>To perform the complete operation on soyuz, we need to forward the
>gpg-socket (and the SSH socket if different) to soyuz, which defeats
>the PGP
>/ Web of Trust security model: for a person with root access to soyuz,
>the private key is only one passphrase away.
>
>Thoughts?
>

Yes, truly defeats it. I explicitly do not recommend forwarding it to the build 
server.
For not doing that, you will most likely need to download the final artifacts 
for signing. If I recall correctly we had a discussion on that topic with 
Bluewind, jelle and grazzolini and someone wanted to rephrase the section with 
better recommendations.

Cheers,
Levente

Re: [aur-general] Build packages without Arch on pkgbuild.com

[Levente Polyak via aur-general]

On 04/08/2018 05:51 PM, Eli Schwartz via aur-general wrote:
> On 04/08/2018 07:49 AM, Florian Pritz via aur-general wrote:
>> On 08.04.2018 05:01, Eli Schwartz via aur-general wrote:
>>> If you're really afraid of someone running as either your user, or some
>>> user with the power to hijack your SSH session, while you're trying to
>>> sign something, then they could just switch out your built files anyway.
>>> There's literally no solution there, except to build everything on your
>>> machine and not use soyuz at all. "clave" won't help either, because
>>> it's got the same fundamental problem of not actually being your trusted
>>> machine from beginning to end.
>>
>> Yes, the built files may not be trustworthy if an attacker is present,
>> but the potential scope of this is limited to our package files.
>>
>> The problem with agent forwarding is that people generally configure
>> their agent to cache passwords so they don't have to unlock their keys
>> all the time. With that in mind, an attacker can just request that the
>> agent signs something after the package has been signed and there won't
>> be any dialog popping up. That includes trust signatures on the
>> attacker's key or just messages to prove that they are someone else.
>>
>> Also people might have more than one key in their agent. If you have gpg
>> and ssh keys in there, the attacker can just connect to other machines
>> by using your forwarded agent's ssh key. Also, again there probably
>> won't be a prompt since the password is usually cached.
> 
> Right, like I said/implied the problem was ill-defined. It's a
> configuration issue, not a conceptual problem with gpg forwarding being
> fundamentally a violation of PGP trust.
> 

With the correct configuration, sure. But even then it still allows one
to sign whatever the hack they want, (mail)texts requesting something
like ssh key change or whatever like any arbitrary file one could
imagine and grab the signature on the remote.
It could even be made semi-stealthed to ask twice for a side-artifact
and if not taking a careful notice about the lack of "wrong password"
messages or whatever, most people will just enter the passphrase again
and assume they mistyped.

Not saying doing "harm" to a package that later gets locally signed and
uploaded to the repo can't do more devastating havoc and gain access to
the packagers key if installed on that very same machine... but people
should also be aware it can aid to trivially get any text signed that
makes f.e. some non-legitimate claims or requests look legitimate.

Security and implications of threat models is always (additionally to
hard facts) a personal thing of consideration what is acceptable and
what not. People should always be made fully aware of the implications
of acting in certain ways with their (distro) signing/shell keys.

Speaking purely for me, my personal decision is to never build on remote
machines and especially never sign anything on them. At the end, our
reproducible builds efforts will (soon) help to detect such
backdoored/altered packages uploaded to our tier-1 mirrors but it will
not detect maliciously signed text messages or off-repo signed and
exfiltrated packages that can later be used for a targeted MitM or
malicious mirrors.

So yes, if you ask me I still totally don't recommend to remote sign on
a shared environment no matter how its configured... but if you feel the
urge to do, then do it as good as possible.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

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

[Levente Polyak via aur-general]

On 03/19/2018 03:21 PM, 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?
> 


make sure you have also updated to networkmanager 1.10.6-2 and did a
full system upgrade.

cheers
Levente

Re: [aur-general] TU Application - Robin Broda

[Levente Polyak via aur-general]

On 03/02/2018 08:09 PM, Robin Broda via aur-general wrote:
> On 03/02/2018 06:17 PM, Levente Polyak via aur-general wrote:
>> find some notes related to your packages:
>>
>> [...]
>>
> Thanks for the feedback!
> 
> Regards,
> Rob
> 

You're welcome.


BTW: How are you tracking upstream updated so you can bump your packages
 before someone flags them?

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU Application - Robin Broda

[Levente Polyak via aur-general]

On 03/05/2018 05:20 PM, Robin Broda via aur-general wrote:
> On 03/05/2018 05:11 PM, Levente Polyak via aur-general wrote:
> 
>> On 03/02/2018 08:09 PM, Robin Broda via aur-general wrote:
>>> On 03/02/2018 06:17 PM, Levente Polyak via aur-general wrote:
>>>> find some notes related to your packages:
>>>>
>>>> [...]
>>>>
>>> Thanks for the feedback!
>>>
>>> Regards,
>>> Rob
>>>
>> You're welcome.
>>
>>
>> BTW: How are you tracking upstream updated so you can bump your packages
>>  before someone flags them?
>>
>> cheers,
>> Levente
>>
> The ones i've submitted the patches to notified me via email on
> merge/activity (GitHub default),
> and my current non-vcs packages don't update very frequently - so beyond
> occasionally checking
> upstream, i'm not doing anything special yet.
> 
> Regards,
> Rob
> 


Hey Rob,

ah I see... thanks for the fast handling of my feedback :P

I would recommend taking a look at a way to track upstreams for release
tarballs/tags beyond that...

there is a big amount of tools to achieve this (trying not to turn this
thread into an advertisement-repy-war so not mentioning any).

For projects hosted on git i find it handy to have some of them
observing 'git ls-remote --tags https://someurl.foo/project.git'.


I recommand having something in place to track maintained packages.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU Application - Robin Broda

[Levente Polyak via aur-general]

On 03/02/2018 05:16 PM, Robin Broda via aur-general wrote:
> Hello,
> 
> I'm Robin 'coderobe' Broda, born in '99, and I'm writing to become a
> Trusted User.


Hi Robin,

good luck. You can already start helping with reproducible build stuff,
feel free to ask for advice in #archlinux-reproducible we have toolchain
to be extended and bugs filed against upstream.

find some notes related to your packages:

streem + streem-git
- They don't honor existing CFLAGS and LDFLAGS (later at all).
  For now, you can fix both with a small sed command but i recommend
  bringing this issue upstream as a easy PR.
  Always checking for respect of those flags is important.
- If you touch the Makefile anyway maybe a install target with
  respecting PREFIX and DESTDIR would make sense.

indicator-sysmonitor
- 80.patch is not a unique file name per se, this is important for
  shared srcdir setups. a prefix using the $pkgname should be better.
- /usr/bin/indicator-sysmonitor invokes stuff and imports py files
  provided in usr/lib. This can result in untracked file creations
  if the application is run as root. cache files should be created
  before packaging, but this should also be possible solved upstream
  for the make install call
- sysmonitor-budgie-git and sysmonitor-appindicator-git should
  also provide their own non-git variants to possibly satisfy
  sysmonitor-budgie or sysmonitor-appindicator instead of the
  general shared indicator-sysmonitor provides.
- just style, but in package() instead of pkgdesc="${pkgdesc}
  you can also simply use pkgdesc+="

glava
- seems to work/build just fine with non-git glfw-x11, is the -git
  required?
- LDFLAGS is not properly handled in Makefile leading to non -znow
  (and other flags) linking. should be temporarily fixed in PKGBUILD
  and possibly a patch submited upstream.

daemontools-encore
- quite weird Makefile with their conf-cc and print-cc.sh calls,
  anyway does not respect CFLAGS and LDFLAGS at all. should be fixed.
  This Makefile made me giggle :D

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Go package dependencies

[Levente Polyak via aur-general]

On 02/28/2018 02:23 AM, Adam Levy via aur-general wrote:
> Hi there,
> 
> I am co-maintaining a few AUR packages written in Golang and I just ran
> namcap on my built package. I got the following output on a few of my
> golang packages:
> 
> $ namcap influxdb-1.4.3-1-x86_64.pkg.tar.xz
> influxdb E: Dependency glibc detected and not included (libraries
> ['usr/lib/libpthread.so.0', 'usr/lib/libc.so.6'] needed in files
> ['usr/bin/influx_inspect', 'usr/bin/influx_stress', 'usr/bin/influx',
> 'usr/bin/influx_tsm', 'usr/bin/influxd'])
> 
> However 'glibc' is in the base group, and I thought that it wasn't
> necessary to declare dependencies from the base group since it should
> always be installed on a fresh OS install. Am I wrong about this point?
> Should I be including 'glibc' as a dependency in this package? Should I be
> including 'bash' as a dependency in packages with scripts that use bash?
> 
> Thank you!
> Adam Levy (alaskanarcher)
> 

Actually there is no strict rule that base must be installed, its just a
strong recommendation. While most systems would be quite useless without
having glibc, its still a first level dependencies that a package uses
and therefor should be declared explicitly and not implicitly.
Opinions vary, but if you ask me its cleaner to explicitly state first
level dependencies, no matter from where they may be implicitly
available (so yes, personally i add both, glibc and bash if required).

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

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

[Levente Polyak via aur-general]

On 10/15/18 12:27 AM, Baptiste Jonglez wrote:
> On 15-10-18, Levente Polyak via aur-general wrote:
>> On 10/14/18 11:35 PM, 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.
>>>
>>
>> So let me summarize what you are saying, correct me if im wrong:
>>
>> You fully know whats all the gizzle with gpg. Instead of acting like a
>> trustable user who follows best practice and spreads good advice and
>> helps teaching people about how all this works properly you prefere to
>> pull the lazy card because its what? big stress? Serious?
>> I don't even find words to describe how untrustworthy this is to the
>> community to prefer to remove GPG signatures instead of educating users?
> 
> What a warm way to welcome people.  A bit of fact-checking doesn't hurt:
> 
> $ pkgver=4.16.1
> $ wget 
> "https://www.apache.org/dist/flex/${pkgver}/binaries/apache-flex-sdk-${pkgver}-bin.tar.gz"{,.asc}
> $ gpg --verify apache-flex-sdk-4.16.1-bin.tar.gz.asc 
> gpg: assuming signed data in 'apache-flex-sdk-4.16.1-bin.tar.gz'
> gpg: Signature made mer. 15 nov. 2017 09:44:37 CET
> gpg:using RSA key 44998F3E242727E94C4BADEB6B0A7EC905061FC8
> gpg: Can't check signature: No public key
> 
> $ gpg --search-keys 44998F3E242727E94C4BADEB6B0A7EC905061FC8
> gpg: data source: http://192.146.137.99:11371
> (1)  Piotr Zarzycki (CODE SIGNING KEY) 
>4096 bit RSA key 6B0A7EC905061FC8, created: 2017-06-17 (revoked)
> Keys 1-1 of 1 for "44998F3E242727E94C4BADEB6B0A7EC905061FC8".  Enter 
> number(s), N)ext, or Q)uit > 
> 
> 
> Baptiste
> 

Fact checkin what? I didn't respond to a specific case, I responded to a
general statement:

"I usually don't use pgp on my aur packages because people tend to
complain a lot about building issues."

And that statement applies to parts of your comment as well... no I
frankly don't understand that someone would not like to because its
stress. We then better add base-devel to makedepends as well, right?



signature.asc
Description: OpenPGP digital signature

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

[Levente Polyak via aur-general]

On 10/14/18 11:41 PM, Konstantin Gizdov wrote:
> Sure, I can share the load. I've built tensorflow+cuda from scratch a
> couple of times and completely understand the struggle. :)
> 

Reminder to always bottom-post on Arch mailinglists ;)



signature.asc
Description: OpenPGP digital signature

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

[Levente Polyak via aur-general]

Hey Konstantin,


On 10/14/18 11:41 PM, Konstantin Gizdov wrote:
>>>   o llvm50
>>>   o llvm50-libs
>>>   o clang50

Didn't dig into it myself as its easier to ask, could you maybe
elaborate why we would need those 50 versioned variants? Normally we try
to keep the number of versioned variants to the very minimum and only
throw them in as a last resort because of mayor incompatibilities :)

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

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

[Levente Polyak via aur-general]

Hi Daniel,

On 10/14/18 9:49 PM, Daniel Bermond via aur-general wrote:
> I have a project of my own called screencast[4], which is a command line 
> interface to record a X11 desktop using FFmpeg, having support for offline 
> recording, live streaming and the capability of adding some effects. It's 
> written in pure POSIX/portable shellscript.


Just took some seconds of reading screencast and i noticed the following
that you may want to fix as i didn't spot in a 10sec lookup what would
mitigate the following:

https://github.com/dbermond/screencast/blob/HEAD/src/settings_general.sh#L31

You are using /tmp here, you should replace processing with a safe user
owned directory aquired by `mktemp`.

The reason:

Its vulnerable to symlink attacks, you can delete arbitrary user owned
files via:
https://github.com/dbermond/screencast/blob/HEAD/src/system.sh#L31

Or steal secret data like ssh or gnipg secret keys by moving it outside
of a user-only accessable folder via a `mv` gadget:

https://github.com/dbermond/screencast/blob/HEAD/src/system.sh#L40

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

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

[Levente Polyak via aur-general]

On 10/14/18 11:35 PM, 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.
> 

So let me summarize what you are saying, correct me if im wrong:

You fully know whats all the gizzle with gpg. Instead of acting like a
trustable user who follows best practice and spreads good advice and
helps teaching people about how all this works properly you prefere to
pull the lazy card because its what? big stress? Serious?
I don't even find words to describe how untrustworthy this is to the
community to prefer to remove GPG signatures instead of educating users?

PS: Did you hear of pinned comments?

WOW I'm speechless at best.



signature.asc
Description: OpenPGP digital signature

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

[Levente Polyak via aur-general]

Hey Konstantin,

I'm wondering which tool you use to keep track of upstream
releases? is it urlwatch or such?


cheers,
Levente



signature.asc
Description: OpenPGP digital signature

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

[Levente Polyak via aur-general]

Hey Daniel,

out of curiosity, what is you tool of choice to keep track of upstream
releases? something like urlwatch?


cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU Membership Application

[Levente Polyak via aur-general]

Hi Brett


On 10/25/18 8:22 PM, David Runge wrote:
> 
> P.S.: As you've just created a new pgp key pair for your address, please
> make sure to upload the pubkey to the keyservers!
> 

can you please fix this and make your gpg key available somewhere?



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU Membership Application

[Levente Polyak via aur-general]

On 10/25/18 4:26 PM, Brett Cornwall via aur-general wrote:
> I am being sponsored by dvzrv.
> 
> I've been working in the AUR since 2014 as 'Ainola'.

Hi Brett,

some small questions and hints first:

It looks like several packages have different issues preventing to build
in clean chrooted environments properly. Did you take a look at the
devtools package and building packages in clean chroots so far?

What software/tool do you using to track all the new ustream releases?

You still seem to use `mksrcinfo` for generating SRCINFO files, it was
deprecated in favor of native `makepkg --printsrcinfo` you may want to
use that in the future.

I have noticed that mostly all git packages lack sufficient
provides/conflicts on the basic non-git name schema and/or makedepends
on git itself, would be nice to keep in mind

Also i notices there are multiple packages that store a tarball in the
AUR source repo that contain things like icons, please don't miss-use
the AUR as a storage for tarball artifacts.

some findings after reading your PKGBUILDS, can you please take a look
and process the following feedback:

ags
- upstream Makefile doesn't seem to respect CPPFLAGS try to either get a
  patch upstream or if that fails extend CFLAGS with CPPFLAGS in
  the PKGBUILD.

creeper-world
- upstream source/url provides a https endpoint
- you can't reference the PKGBUILD like in prepare(), try building in a
  clean chroot via extra-x86_64-build
- don't think pkgdesc should ever end with a dot

creeper-world2
- upstream source/url provides a https endpoint
- don't think pkgdesc should ever end with a dot
- unzip to prepare the env is more of a prepare() candidate

creeper-world3
- upstream source/url provides a https endpoint
- you can't reference the PKGBUILD like in prepare(), try building in a
  clean chroot via extra-x86_64-build
- not a big fan of fiddling with PKGEXT even if its "just the AUR" but
  well

csound-blue
- please don't use the AUR to store a tar.gz as a source
- provides/conflicts on itself doesn't do anything useful
- is there a reason for not stripping?
- this looks like a -bin package as you are re-distributing pre-compiled
  files, why not just build from source instead? :)

gam
- don't think pkgdesc should ever end with a dot
- there is some unused client_secrets.patch sitting around in the source
  repo
- python2-oauth2client dependency is missing
- this package create cluttering files across the filesystem if you run
  gam as root, it will have untracked pyc files in /usr/share/gam/
  you need to compile them if no distutils is provided

gnome-xcf-thumbnailer
- prepare() shall never package into $pkgdir

gtk-theme-adwaita-tweaks
- don't think pkgdesc should ever end with a dot

gtk-theme-adwaita-tweaks-git
- lack of provides/conflicts
- should pull via git+https://
- don't think pkgdesc should ever end with a dot
- git makedepends is missing
- the dark variant isn't published as "Adwaita Tweaks Dark" i don't
  think this works compared to the non git variant, it should honor
  the assets-dark folders and mimic what the release tarballs provide

gtk-theme-minwaita
- don't think pkgdesc should ever end with a dot

hib-dlagent
- none-url.patch is not a very unique name for a remote soruce, it could
  potentially clash, prepend with $pkgname can help

imv-git
- lack of provides imv

i3lock-media-keys
- don't think pkgdesc should ever end with a dot

interception-ctrl2esc-git
- don't think pkgdesc should ever end with a dot
- git makedepends is missing
- provides/conflicts not proper
- is there a reason to have interception- prefix? imo ctrl2esc-git would
  be the better naming here plus provides/conflicts on ctrl2esc
- you should use CMAKE_INSTALL_PREFIX=/usr and DESTDIR for $pkgdir

invada-studio-plugins-lv2
- don't think pkgdesc should ever end with a dot

lazy-ips-git
- don't think pkgdesc should ever end with a dot
- git makedepends is missing
- you can't reference the PKGBUILD like in prepare(), try building in a
  clean chroot via extra-x86_64-build
- lack of provides/conflicts

linkchecker
- don't think pkgdesc should ever end with a dot

minecraft-technic-launcher
- don't think pkgdesc should ever end with a dot

nexuiz
- don't think pkgdesc should ever end with a dot
- upstream source/url both provides a https endpoint
- not a big fan of fiddling with PKGEXT even if its "just the AUR" but
  well
- extracting and patching should be done in prepare()
- please don't use the AUR to store a tar.gz as a source, there is also
  an orphan bin-links.tar.gz file additionally to the used
  nex-icons.tar.gz checked into the AUR

pam_encfs
- doesn't respect neither CFLAGS, CPPFLAGS, LDFLAGS please make sure
  this is always applied for c/cpp

pd-extended
- non unique filename that only contains the $pkgname, must always be
  unique including the pkgver so avoid clashes
- doesn't respect neither CFLAGS, CPPFLAGS, LDFLAGS please make sure
  this is always applied for c/cpp
- orphan file makefile.am.patch in the 

Re: [aur-general] TU application: Maxim Baz

[Levente Polyak via aur-general]

Hi Maxim,

some feedback to your packages that others did not yet bring up (so
pelase go through jelle's as well, i did not include them again):

But before we start, can't resist mumbling a small 'meh' for all this
non build content hosted in the AUR. meh.


browserpass:
- just a nitpick, but entry point is always $srcdir so if there is no
  reason to do so, its just line-noise when calling 'cd' on each step.

chromium-vaapi:
- just the same tiny nitpick about cd-ing into $srcdir

chromium-vaapi-bin:
- this should also provide chromium-vaapi

grub-btrfs:
- conflicts on a git variant doesn't belong here. always the
  other way around
- sources must be unique when f.e. stored in a global place,
  always prefix artifacts like v$pkgver.tar.gz with
  $pkgname-$pkgver.tar.gz::
- no need to distribute GPL3 license, they are common and therefore
  nothing put storage waste.

i3ipc-python:
- don't provide yourself, doesn't do anything
- conflicts on a git variant doesn't belong here. always the
  other way around
- same tiny nitpick about cd-ing into $srcdir
- upstream has tests, why not call whem via checkdepends and py.test?

kak-lsp:
- someone should push a non git go-langserver so this packages doesn't
  need to recommend an optdepends on a git package
- same tiny nitpick about cd-ing into $srcdir

lscolors-git
- should pull over TLS via git+https://
- should have proper provides/conflicts
- still not a fan of those verbose docs in .install

rmtrash
- ok at least im sure this .install classifies as not mandatory
  for a package to work, right? :P
- just the same tiny nitpick about cd-ing into $srcdir
- this is bash, it should have arch=(any)

wire-desktop
- conflicts on a -bin variant doesn't belong here. always the
  other way around
- this source prefix is literally useless it should be unique
  like  $pkgname-$pkgver.tar.gz::
- same tiny nitpick about cd-ing into $srcdir
- patching should be done in prepare()
- ending pkgdesc with a dot is meh
- hunspell-en optdepends does not exist

wire-desktop-beta:
- conflicts is total bogus, should only have 'wire-desktop' as
  does provides
- this source prefix is literally useless it should be unique
  like  $pkgname-$pkgver.tar.gz::
- same tiny nitpick about cd-ing into $srcdir
- patching should be done in prepare()
- ending pkgdesc with a dot is meh
- hunspell-en optdepends does not exist

wire-desktop-git:
- makedepends on git is missing
- should pull via git+https over TLS
- conflicts is bogus, should only have 'wire-desktop' as
  does provides
- same tiny nitpick about cd-ing into $srcdir
- hunspell-en optdepends does not exist

yubikey-touch-detector:
- should be build via go-pie


cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] On TU application, TU participation and community/ package quality

[Levente Polyak via aur-general]

On 11/12/18 12:54 AM, Baptiste Jonglez wrote:
> On 11-11-18, Santiago Torres-Arias via aur-general wrote:
>> On TU applications, TU participation and package quality:
>> =
>>
>> Many Trusted Users have brought up their concerns regarding the lack
>> of proper vetting of packages put forward by new TU's, the small
>> participation of TUs in their duties* and the declining quality of
>> packages in the community/ repository. As a consequence, we've decided
>> to bring forward proposals to tackle the following issues:

Thanks sangy that I could offload to you kick-starting this discussion :)

Nothing here is finger pointing even if you may find yourself matching
an example in any way. We are facing different symptoms and that's the
root why many TUs brought up concerns.
It's not easy to find hard facts for all this, even I can't deliver
those in all my following examples but denying there is something we can
or should improve just ignores why we have this discussion today.

> 
> Before diving in on the proposed solutions, let's make sure we all agree
> on whether there is a problem and what is the problem exactly:
> 
>> ## Issues
>>
>> * Existing Trusted Users are not followed closely in their actions
> 
> Well, that's why it's called *Trusted* Users, right?  Most of the issues
> you mention are actually issues about trust.
> 
> I've made some packaging mistakes in the past, and there was always
> somebody to yell at me.  I wasn't happy at the time and maybe I didn't
> react appropriately, but most of the time the "yeller" was right, and I
> learned from these mistakes so as not to repeat them.
> 
> If we want to increase the level of trust in terms of packaging quality, I
> like the suggestion of a "probation" period in which new TUs have all
> their changes reviewed by their sponsor and/or another TU.
> 
> This seems much more productive and reasonable than a "council of trusted
> Trusted Users" that either acts as a gatekeeper or assesses the
> "performance" of their fellow TUs, whatever that means...

Sure, if we can call out sponsors for lack of proper guidance and
commitment. Sometimes I have the feeling some sponsors don't do anything
besides putting their name into an applications and creating a ticket on
success.
I know of some sponsors that just didn't take the time to review any
packages (they personally admitted so) and therefor IMO didn't really
mentor the applicant. We should take sponsoring more seriously.

I feel a bit sad and like people offload the burden fully on others like
me when I notice very obvious things as VCS packages that for example
lack any provides/conflicts (or similar) which is already very well
documented in our packaging related wiki pages.

Not saying nobody does, but sponsoring should quite frankly be far more
then just to agree and like that an applicant wants to become a TU.
Redirecting to another possible sponsor doesn't mean you reject an
applicant either and that's easy to make clear! To volunteer being a
sponsor should mean to _potentially_ spend lots of time and patience in
order to be a mentor that an applicant deserves.

> of 
>> * New applications are not carefully reviewed, and a several TUs seem to
>>   just vote “Yes” by default.
> 
> Do you have any data backing up this claim about voting "Yes" by default?
> Do you mean that some TUs vote "Yes" without reading the TU application 
> thread?

Hard to have data on this, but I can share that I have two samples of
people admitting they haven't really read it, whatever that means, no
idea what the resulting vote was either. No need for a witch hunt here
as well, I have made clear how bad that is (but you asked for examples).

/* Another related example follows two sections below */

> 
> I find this unlikely, we even rejected some TU applications in the past
> (one in 2014, one in 2016 and another in 2017).
> 
> The most likely explanation for the successful applications is that they
> just didn't raise any serious issue worth a rejection.
> 

Don't want to use a too strong language here as we are speaking about
people behind these but i would have lost lots of trust if we didn't.

Anyway, this purely depends on the set of applicants. We should just
fully keep this part out of the equation as it doesn't provide _any_
value or indication if that's too little or too much and there are no
hard fact to back either.


>> * The implication of some TUs in the distribution is very limited
>>   outside of packaging.
> 
> You can't expect everybody to dedicate all their time to Arch: we all live
> different lives and are already involved in various projects.  Let's just
> accept that there are several ways of contributing and that's fine.
> 

Another example I know of: we also have at least one TU who literally
never ever participates in any IRC, mailinglist or Forum discussions and
also didn't vote in the past until we put up that rule about voting.
Magically this lead to voting, but excuse me I lack the trust to 

Re: [aur-general] TU Application: Daniel M. Capella

[Levente Polyak via aur-general]

On 11/16/18 12:51 AM, Daniel M. Capella via aur-general wrote:
> Quoting Eli Schwartz via aur-general (2018-11-15 00:52:50)
>> On 11/14/18 11:50 PM, Daniel M. Capella via aur-general wrote:
>>> Quoting Levente Polyak via aur-general (2018-11-14 17:00:38)
>>>> - tests are awesome <3 run them whenever possible! more is better!
>>>>   pulling sources from github is favorable when you get free tests
>>>>   and sometimes manpages/docs
>>>
>>> Will work with the upstreams to distribute these. I prefer to use published
>>> offerings as they are what the authors intend to be used. GitHub 
>>> autogenerated
>>> tarballs are also subject to change:
>>> https://marc.info/?l=openbsd-ports=151973450514279=2
>>
>> I've seen the occasional *claim* that this happens, but I've yet to see
>> any actual case where this happens and it isn't because of upstream
>> force-pushing a tag.
>>
>> GitHub is supposed to use git-archive(1) for this, which is guaranteed
>> to be reproducible when generating .tar, although in theory
>> post-filtering this through a compressor like gzip can result in changes
>> from one version of git to another. I say in theory because I don't
>> recall this ever happening, and git-archive uses the fairly boring defaults.
>>
>> I don't see any reason to use substandard sources in order to avoid
>> checksum problems I don't believe in.
> 
> "substandard" 樂 
> https://wiki.archlinux.org/index.php/Python_package_guidelines#Source
> 

Does the wiki really need to be overly specific when its sane to use
which source? Especially when you have one that gives tests, docs and
signatures and the other not?
Or do we really expect to have a paragraph to explicitly allow building
python from the original unprocessed main sources as well?

I don't think so.



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application: Maxim Baz

[Levente Polyak via aur-general]

Hi Maxim,

On 11/6/18 1:05 AM, Maxim Baz via aur-general wrote:
>> You might want to use go-pie btw, to actually have PIE support
>>
>> browserpass W: ELF file ('usr/bin/browserpass') lacks FULL RELRO, check 
>> LDFLAGS.
>> browserpass W: ELF file ('usr/bin/browserpass') lacks PIE.
> 
> Nice, will investigate this.

well replace go with go-pie is all you can do there, you can't (yet) fix
RELRO for go :/


> 
>>> - ttf-emojione (33): Colorful emoji font from EmojiOne. I created a Docker
>>> image that is able to compile the font out of image assets, and configured a
>>> Travis job for EmojiOne team so that the font is automatically being 
>>> compiled
>>> on every commit and attached to every Github release.
>>
>> The .install scriptlet shouldn't contain documentation. 
> 
> Just to confirm, this is not as much documentation as a description of a 
> command
> that user needs to run to make this package work.
> 
> I guess I could create a wiki page for EmojiOne and put there the command to 
> run,
> but how do I let people know that they must visit the wiki? People expect to 
> install
> the font and see it working, but it won't happen until they install 
> fontconfig file.
> 
> I've had positive experience with using .install files to inform people what 
> else
> they need to do after installation, not a single person complained in 
> comments on AUR
> about problems with font! :)
> 
> Also, just saw that wiki [4] encourages to echo important directions that are 
> needed
> to make package work, I believe my .install files fall under this category ;)
> 

This is certainly something that is totally debatable and after all we
are not Debian that does everything imaginable automagically and f.e.
reloads all kind of stuff.
The general statement that .install is not meant for documentation is
correct, if this falls under the category of being well suited for
.install is interpretation and debatable. Personally i don't see basic
fontconfig knowledge to fall under this category and IMO its
documentation that could be stuffed as well in
/usr/share/doc/${pkgname}. After all, our users are expected to be able
to search the wiki, people over the whole net claim we have the best
linux wiki out there after all :p


>>> - grub-btrfs (15): Detects and includes btrfs snapshots in GRUB menu, 
>>> allowing
>>> to easily boot in any existing snapshot. I personally use grub-btrfs in
>>> combination with snap-pac and snap-pac-grub for seamless integration with
>>> snapper and pacman.
>>
>> The .install scriptlet shouldn't really contain documentation. Ideally
>> that should be found on the wiki or in the man pages.
> 
> Same question here, but actually worth confirming with you: is it a bad 
> practice
> to execute "systemctl daemon-reload" in post_install() function? I've seen 
> people
> do that, but so far I was refraining from executing any commands in .install 
> files.
> 
> Creating a wiki page that would only tell people to run "systemctl 
> daemon-reload"
> after installation sounds wrong...
>  

Yes, it is bad practice to use .install file to warn about  "systemctl
daemon-reload". You also don't need a wiki page for that, why should
you? Systemctl warns you itself about this whenever you would do
something that could require a daemon-relload. This is knowledge that is
expected to be gained. We are not debian that does this automatically,
and if so, it should rather be discussed on arch-dev-public to get a
pacman hook support (which IMO we don't need much).

> 
>> * rebuild-detector:
>> * snap-pac-grub:
>>
>> - Source should not be hosted on the AUR 
> 
> I will move to Github since it simplifies collaboration, but I also want to 
> confirm
> if this is a new rule? I don't see this being mentioned on wiki [2,3,4], 
> unless I'm blind :/
> 
> If it is a rule, let's add it to the wiki! ;)
> 

It indeed is a rule and obviously we need to make it very clear. AUR
package tree is not meant to store the actual non-build-related sources,
 signatures, tarballs or similar artifacts. AUR is not a storage and
actual sources belong elsewhere.


cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application: Maxim Baz

[Levente Polyak via aur-general]

On 11/6/18 2:22 AM, Eli Schwartz via aur-general wrote:
> On 11/5/18 7:05 PM, Maxim Baz via aur-general wrote:
>> Same question here, but actually worth confirming with you: is it a bad 
>> practice
>> to execute "systemctl daemon-reload" in post_install() function? I've seen 
>> people
>> do that, but so far I was refraining from executing any commands in .install 
>> files.
>>
>> Creating a wiki page that would only tell people to run "systemctl 
>> daemon-reload"
>> after installation sounds wrong...
> 
> It's pretty wrong to execute this, mostly because the systemd package
> installs a universal hook to do so and it's therefore outdated bloat to
> do so.
> 
> This is, after all, why we developed hooks for pacman. :)
> 
> It was originally added in March of this year:
> https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/systemd=c2ba1fefa6e393e5cb4d2c19ba65a4ec4c33fb9f
> 


Ah, somehow wasn't really aware that we also do this for
daemon-reload... well then, mv my previous paragraph about this to
/dev/null :P

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application: Maxim Baz

[Levente Polyak via aur-general]

On November 6, 2018 10:24:43 AM GMT+01:00, Bruno Pagani 
 wrote:
>
>Le 06/11/2018 à 02:13, Levente Polyak via aur-general a écrit :
>> Hi Maxim,
>>
>> On 11/6/18 1:05 AM, Maxim Baz via aur-general wrote:
>>>> You might want to use go-pie btw, to actually have PIE support
>>>>
>>>> browserpass W: ELF file ('usr/bin/browserpass') lacks FULL RELRO,
>check LDFLAGS.
>>>> browserpass W: ELF file ('usr/bin/browserpass') lacks PIE.
>>> Nice, will investigate this.
>> well replace go with go-pie is all you can do there, you can't (yet)
>fix
>> RELRO for go :/
>
>is wrong. We have managed to do that in cozy-stack, gitea and
>matterbridge to only cite a few (also in mattermost, but the
>corresponding code is not committed anywhere since this is an AUR
>package not maintained by one of us).
>
>We should update Go guidelines to tell about this and also trimming the
>path (since the bug with it seems to have vanished somehow). *starts a
>Foxboron invocation ritual*
>


That's awesome news, please indeed document the dark ritual needed
to achieve this, there are lots of packages that can benefit from it.

This would be good to have ready before jelle finishes the TODO list
for PIE and RELRO that's been worked on. 

Cheers,
Levente 

Re: [aur-general] TU Application: Daniel M. Capella

[Levente Polyak via aur-general]

Hi Daniel,

Small summary of things I repeatedly noticed:

- # Generated by mksrcinfo v8 Wed Nov 14 05:46:26 UTC 2018
  I would say remove this ancient package from your system
  and use makepkg --printsrcinfo instead

- if a setup.py uses entry_points for scripts that
  means setuptools is not just a make but a hard dependency

- tests are awesome <3 run them whenever possible! more is better!
  pulling sources from github is favorable when you get free tests
  and sometimes manpages/docs


[+] Running xxarhtna --verbose --pedantic

asciinema-rs:
- provides asciinema, but where is the conflicts?

black-git:
- this should be called python-black
- running unit tests is missing
- setuptools is a hard dependency, setup.py uses entry_points
- python-aiohttp should be a checkdepends otherwise tests
  deactivate several things

diskus:
- we can use --locked for repro as there is a Cargo.lock

espeak-ng:
- That shouldn't provide espeak, its not a drop in replacement
  and breaks stuff, this epoch on espeak is for a reason:

https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/espeak=fee824f6ed964b1bab1586fdc4342577f2a57bf2
- autogen.sh should be a prepare() thing

firefox-*
- i just skip over those, not a fan of repackaging xpi but meh
- also meh on the lack of firefox dependency when putting
  files in /usr/lib/firefox

firefox-bookmarkdupes:
- building from source will have nice signatures

gitleaks:
- there are tests available for check()
- RELRO ldflags

gixy:
- setuptools is a hard dependency, setup.py uses entry_points
- there are tests available for check() if you pull the real soruces

hangups:
- setuptools is a hard dependency, setup.py uses entry_points
- there are tests available for check() if you pull the real soruces
- you can distribute manpages via docs dir + man target if you pull the real
  soruces (and add python-sphinx as makedepends)

instalooter
- there are tests available for check() if you pull the real soruces
- you can distribute manpages via docs dir + man target if you pull the real
  soruces (and add python-sphinx as makedepends)

mwic
- the hack does upstream do, it will create .py files in usr/share/mwic/lib/
  that lack the pyo/pyc files and if running as root the imports will
  create untracked files in that directory that will remain forever

pcaudiolib
- prepare() is a better place for autogen.sh

pulldown-cmark
- there is a Cargo.lock lets use --locked for reproducible builds
  this requires to pull unstripped sources from github
- there are also tests available but whatever upstream does, some of
  them seem to fail? investigate?

pulseaudio-dlna:
- setuptools is a hard dependency, setup.py uses entry_points

pycoinmon:
- setuptools is a hard dependency, setup.py uses entry_points
- there are tests available for check() if you pull the real soruces

shaderc:
- pacman -Q glslang-git hm no it depends on glslang
- build works perfectly fine with python3
- CMAKE_INSTALL_PREFIX must not use $pkgdir, that belongs to
  DESTDIR for ninja in package()
- i'm sorry, i gonna need to pull this into [extra] as part
  of an update. thanks for the work

pyt:
- setuptools is a hard dependency, setup.py uses entry_points

pyt-git:
- setuptools is a hard dependency, setup.py uses entry_points

python-black:
- setuptools is a hard dependency, setup.py uses entry_points
- python-aiohttp should be a checkdepends otherwise tests
  deactivate several things

python-fake-useragent:
- there are tests available for check() if you pull the real soruces
  needs checkdepends of pytest and mock

python-flake8-bugbear:
- setuptools is a hard dependency, setup.py uses entry_points

python-milksnake:
- setuptools is a hard dependency, setup.py uses entry_points
- there are tests available for check() if you pull the real soruces

python-py-spin:
- there are tests available for check() if you pull the real soruces
  via test_pyspin.py

python-soco:
- there are tests available for check() via py.test
- maybe distribute some docs as well like manpages from docs dir

razercfg:
- razercfg.install could be removed, ldconfig systemd-tmpfiles and udevadm
  are handled via hooks
- do we _really_ need to split razer mouse tool UI and daemon here?
doubt it tbh.

rst2ctags:
- setuptools is a hard dependency, setup.py uses entry_points

rstcheck:
- there are tests available for check() via test_rstcheck.py
- setuptools is a hard dependency, setup.py uses entry_points

socos:
- setuptools is a hard dependency, setup.py uses entry_points

speedtest-zpeters:
- go magic to get RELRO ldflags
- whats wrong with the tests? maybe comment?

spotify-adkiller-git:
- i dont like file-type postfixes in /usr/bin they should be removed
  and ADKILLER= be adjusted

spt:
- this needs a build() func, don't build implicitly in package()
- CPPFLAGS are not respected and should be populated properly
  an upstream patch for that would be best

termdown:
- setuptools is a hard dependency, setup.py uses entry_points

Re: [aur-general] TU Application: Daniel M. Capella

[Levente Polyak via aur-general]

On 11/15/18 5:50 AM, Daniel M. Capella via aur-general wrote:
>> - tests are awesome <3 run them whenever possible! more is better!
>>   pulling sources from github is favorable when you get free tests
>>   and sometimes manpages/docs
> 
> Will work with the upstreams to distribute these. I prefer to use published
> offerings as they are what the authors intend to be used. GitHub autogenerated
> tarballs are also subject to change:
> https://marc.info/?l=openbsd-ports=151973450514279=2
> 

Well source tree is the source of truth as that's where processed stuff
comes from :P

If you can't convince all upstream do distribute their tests and
especially not convince them to distribute the sources for generating
docs I would still say please go for source tree instead as the value of
such additional content is high. We love tests.

Side note, nowadays there are lots of python and other project that git
sign their latest tags and commits but have no other way of detatched
signatures, this adds a big gain as well. Remember two of your packages
had upstream tag signatures but i forgot to point them out.
If I can't convince them to use detatched sinatures as well I nowadays
just switch to pull git and use ?signed


>> python-soco:
>> - maybe distribute some docs as well like manpages from docs dir
> 
> I don't see any manpages there. This is a library.

make -C doc man
Manpages are not exclusive for tools, they are for any kind of
documentation like library APIs
try running:
man 3 sprintf

> 
>> razercfg:
>> - do we _really_ need to split razer mouse tool UI and daemon here?
>> doubt it tbh.
> 
> The UI is completely optional. ¯\_(ツ)_/¯

My point is, its the same source and the packages are not huge and it
doesn't have crazy dependency hells.
Only split up if it really makes sense, if there is no real reason we
keep them combined, like tools + libs + headers and don't go as crazy as
debian about splitting up everything.


> 
>> - CPPFLAGS are not respected and should be populated properly
>>   an upstream patch for that would be best
> 
> Will have to figure that out.

All you need in the PR is add $CPPFLAGS where you already see $CFLAGS.
For time being either backport this patch or just export
CFLAGS="${CFLAGS} ${CPPFLAGS} until its done.

> 
> Thank you very much for the review. Go LDFLAGS is still on the todo. Packaging
> for Go has perhaps been more traumatizing than even Node.js.
> 


You're welcome, always a plesure if people are happy about it :-)



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Auto-generated Github tarballs format change (Was: TU Application: Daniel M. Capella)

[Levente Polyak via aur-general]

On 11/15/18 10:52 AM, Baptiste Jonglez wrote:
> On 15-11-18, Eli Schwartz via aur-general wrote:
>> On 11/14/18 11:50 PM, Daniel M. Capella via aur-general wrote:
>>> Quoting Levente Polyak via aur-general (2018-11-14 17:00:38)
>>>> - tests are awesome <3 run them whenever possible! more is better!
>>>>   pulling sources from github is favorable when you get free tests
>>>>   and sometimes manpages/docs
>>>
>>> Will work with the upstreams to distribute these. I prefer to use published
>>> offerings as they are what the authors intend to be used. GitHub 
>>> autogenerated
>>> tarballs are also subject to change:
>>> https://marc.info/?l=openbsd-ports=151973450514279=2
>>
>> I've seen the occasional *claim* that this happens, but I've yet to see
>> any actual case where this happens and it isn't because of upstream
>> force-pushing a tag.
> 
> See https://bugs.archlinux.org/task/60382 for an example.
> 
> I still had the old archive around so I spent some time comparing it with
> the new one:
> 
> - I compared the checksum of each individual file in the archives, and
>   they were all identical
> 
> - I compared the raw tar files after decompressing, and there were just a
>   few bytes that were moved around
> 
> This really suggests a slight format change in the way the tarball was
> generated (could be file ordering).
> 
> If you want to double check, here they are:
> 
> - old archive from May 2017: 
> https://files.polyno.me/arch/kashmir-20150805-20170525.tar.gz
> 
> - new archive: https://files.polyno.me/arch/kashmir-20150805.tar.gz
> 
> Baptiste
> 

GitHub invalidating caches is not the problem here, they should be
allowed to do it whenever they wish. The root of the issue is
unreproduciblility as already pointed out here.

The tarballs are stable per se if no weird magic applies via git export
rules like dates being exported into files or no force pushes are done
to the tree, they use git archive via tar which itself is reproducible.
In fact, detatched pre-generated tarballs sometimes changes as well so
blame upstream for any such happening (at least nowadays :P).

Anyway, the differences we see here are just our digital legacy where
the format was not reproducible yet.

The example tarball indeed only contains metadata changes related to
ordering of filenames inside the structure. This is definitively stable
today.


PS: You can simply use diffoscope for such analysis, it has been
invented for this very purpose and is not only content but also
meta-data aware.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application_R: Metal A-wing (a-wing)

[Levente Polyak via aur-general]

On January 22, 2019 1:25:20 PM GMT+01:00, Bert Peters via aur-general 
 wrote:
>David Runge schreef op 2019-01-22 12:30:
>> On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote:
>>> On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote:
>>> Why is use
>>> `$(gem env gemdir)`
>>> 
>>> Instead of
>>> 
>>> `$(ruby -e'puts Gem.default_dir')`
>> It's shorter and you don't have to spawn a ruby process to print
>> something, if you can use the gem command directly.
>
>I'm not a TU so take my this with a grain of salt, but I don't think 
>this is the best advice.
>
>It's shorter, admittedly, but `gem` spawns a ruby process just as the 
>`ruby` version does. Using gem doesn't work however when `$GEM_HOME` is
>
>set, since then it reports the contents of that variable.
>
>Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')` is
>
>more convenient since most users do not build in a clean chroot, and
>the 
>wiki actually recommends settings that environment variable so quite a 
>few will have it.
>
>Best,
>
>Bert Peters.

Which seems silly and the whole section should be removed in the first place.
Thats what --user-install switch should be for and that should be default via 
/etc/gemrc
Therefor setting that is just useless fiddling with the system and your gems 
will be searched there as well as it's default gem path besides /usr/lib.

Re: [aur-general] TU application_R: Metal A-wing (a-wing)

[Levente Polyak via aur-general]

On January 22, 2019 4:03:29 PM GMT+01:00, Bert Peters via aur-general 
 wrote:
>Levente Polyak via aur-general schreef op 2019-01-22 13:40:
>> On January 22, 2019 1:25:20 PM GMT+01:00, Bert Peters via aur-general
>>  wrote:
>>> David Runge schreef op 2019-01-22 12:30:
>>>> On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote:
>>>>> On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote:
>>>>> Why is use
>>>>> `$(gem env gemdir)`
>>>>> 
>>>>> Instead of
>>>>> 
>>>>> `$(ruby -e'puts Gem.default_dir')`
>>>> It's shorter and you don't have to spawn a ruby process to print
>>>> something, if you can use the gem command directly.
>>> 
>>> I'm not a TU so take my this with a grain of salt, but I don't think
>>> this is the best advice.
>>> 
>>> It's shorter, admittedly, but `gem` spawns a ruby process just as
>the
>>> `ruby` version does. Using gem doesn't work however when `$GEM_HOME`
>
>>> is
>>> 
>>> set, since then it reports the contents of that variable.
>>> 
>>> Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')`
>
>>> is
>>> 
>>> more convenient since most users do not build in a clean chroot, and
>>> the
>>> wiki actually recommends settings that environment variable so quite
>a
>>> few will have it.
>>> 
>>> Best,
>>> 
>>> Bert Peters.
>> 
>> Which seems silly and the whole section should be removed in the
>first 
>> place.
>> Thats what --user-install switch should be for and that should be
>> default via /etc/gemrc
>> Therefor setting that is just useless fiddling with the system and
>> your gems will be searched there as well as it's default gem path
>> besides /usr/lib.
>
>While `gem` obeys that default, `bundle` (ruby-bundler) does not, and 
>does not
>have that default, opting for a global install by default. You can 
>override
>this by manually adding `--path=~/.gem` to every invocation. That's 
>hardly an
>elegant solution compared to setting an environment variable.


Which is why "bundle config path" exists.
A sane way would be to use that to define BUNDLE_PATH in ~/.bundle/config

Re: [aur-general] Exact purpose of check()

[Levente Polyak via aur-general]

Tox should never ever be used for check() exactly for the reasons
your pointed out. It is supposed to check the build/package
works without regression in the environment it will run in.
Running the test against system libraries that are later after install
used by the runtime is the way check() should behave otherwise
it's pointless in the context of checking the package. 

Re: [aur-general] Trusted user application: Drew DeVault

[Levente Polyak via aur-general]

On 2/28/19 2:58 PM, Jerome Leclanche wrote:
> On Thu, Feb 28, 2019 at 12:51 PM Josef Miegl  wrote:
>> Although I don't have high expectations when dealing with AUR packages, it 
>> is absolutely the maintainers job to keep track of upstream updates. This 
>> mindset is probably the reason why there is so much out of date stuff on the 
>> AUR. It strikes me that a maintainer who doesn't keep track of his own 
>> packages wants to become a TU.
> 
> No, it is not, and please don't expect this of volunteers. The
> responsibility goes as far as security (being made aware ASAP of
> security issues in packages), but knowing in general when a release
> happens is not (and/or shouldn't be) the TU's responsibility.
> Most TUs do know when a release happens in at least a portion of their
> packages, by nature of often maintaining packages they have some
> working relationship with. But the flagging system is very useful in
> crowdsourcing the non-security-sensitive portion of package
> maintenance.


I very strongly disagree on this, nobody forces a volunteer to
_maintain_ a certain package, but If it is chosen by choice then keeping
it up to date is a responsibility as well.
As long as we do not have an automatic system in place it is one of the
responsibilities to track it as good as possible!
This doesn't make the out-of-date flag system non-useful, even when we
would have our automatic flagging system in place, as it could slip
through the radar or tracking like upstream may change the location for
future releases.
I frankly don't like the habit of "i don't give a darn to track, someone
will flag it", this is bad practice, and the best we could agree on is
that we strongly disagree.

sincerely,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Trusted user application: Drew DeVault

[Levente Polyak via aur-general]

On 2/28/19 3:33 PM, Jerome Leclanche wrote:
> 
> We have TUs with hundreds of packages. Beyond automatic checks, do you
> really expect they keep up with every single release?
> I've myself updated several packages that were out of date (and
> unflagged) in [community]. I'm not saying the attitude *should* be "I
> don't give a damn", but in practice, I don't believe this expectation
> you mention is in place (and moreover, I reiterate that I do not think
> there should be such an expectation when it can very efficiently be
> offloaded to scripts and users).
> 
> J. Leclanche
> 

Indeed I am, there are tools like urlwatch, nvchecker and other to
easily get diffs of what changed and those are in the responsibility of
the maintainer to be aware of until our automatic system spec is not
finished and finalized.

TL;DR: yes, i do.

sincerely,
Levente

Re: [aur-general] Trusted user application: Drew DeVault

[Levente Polyak via aur-general]

On 2/28/19 3:43 PM, Jerome Leclanche wrote:
> On Thu, Feb 28, 2019 at 3:36 PM Levente Polyak via aur-general
>  wrote:
>>
>> On 2/28/19 3:33 PM, Jerome Leclanche wrote:
>>>
>>> We have TUs with hundreds of packages. Beyond automatic checks, do you
>>> really expect they keep up with every single release?
>>> I've myself updated several packages that were out of date (and
>>> unflagged) in [community]. I'm not saying the attitude *should* be "I
>>> don't give a damn", but in practice, I don't believe this expectation
>>> you mention is in place (and moreover, I reiterate that I do not think
>>> there should be such an expectation when it can very efficiently be
>>> offloaded to scripts and users).
>>>
>>> J. Leclanche
>>>
>>
>> Indeed I am, there are tools like urlwatch, nvchecker and other to
>> easily get diffs of what changed and those are in the responsibility of
>> the maintainer to be aware of until our automatic system spec is not
>> finished and finalized.
>>
>> TL;DR: yes, i do.
>>
>> sincerely,
>> Levente
> 
> Those are "automatic checks". I'm not sure what you're getting at. If
> they fail for whatever reason, your packages will still be out of
> date; I highly doubt you also manually keep up with all of them.
> 
> J. Leclanche
> 


Thats exactly what i meant by why the system to manually flag it is
useful, even if we have a centralized solution to flag packages
automatically.
Then lets phrase it with your working, yes "automatic checks" are the
responsibility of the maintainer, which in no way makes the manual
crowdsourced system non-useful as previously already stated.

Levente

Re: [aur-general] Trusted user application: Drew DeVault

[Levente Polyak via aur-general]

On 2/28/19 4:49 PM, Drew DeVault via aur-general wrote:
> The AUR is not community. The expectations are higher for trusted users
> - hence the trust. Naturally responding to emails, keeping up with new
> releases, etc, is part of the role. That's why it's a *role* - it serves
> to define the responsibilities. There is no role for AUR package
> maintainer outside of a column in the database. There's no formal
> process for becoming an AUR package maintainer, and Arch Linux
> explicitly disavows AUR packages as having any standard of quality. You
> can't have it both ways - either they're unsupported and maintaining
> them as such isn't a problem, or they are supported and we have to
> address that can of worms.
> 
> And in my opinion, this represents the AUR working as intended. The low
> barrier to entry encourages users who may be novices at packaging or
> have limited time to invest in their package to give it a shot, then
> other users to download these packages and improve the PKGBUILDs,
> hopefully sending their improvements back to the maintainer. We already
> stress that users need to read and evaluate AUR PKGBUILDs for
> themselves. We should be proud that we have a community which encourages
> every user to make packages and devote any amount of time they can to
> supporting them. In short, part of the AUR's value proposition is its
> fast-and-loose criteria for inclusion and maintenance.
> 
> The purpose of community and the trusted user system, as far as I
> understand, is to provide binary packages from the community that meet a
> baseline of quality - wholey different from the AUR. Any packages I
> bring on from the AUR will first be improved to meet these standards,
> and I commit to a higher degree of responsibility in their maintenance.
> I also naturally recognize the value in improving my AUR packages and
> intend to do so over time, but I feel that an approach which is
> non-committal and less urgent is appropriate here.
> 
> I understand the utility in having a history of good AUR packages in
> evaluating someone's potential as a trusted user. To this end I'm
> happily incorporating your feedback into improving my AUR packages. I
> also encourage you to review my history of contributions to Alpine
> Linux, where I am the maintainer of a number of binary packages and have
> established a history of quality packages, fast updates, and engagement
> with the community.
> 
> I feel that this thread has devolved considerably into this rabbit hole,
> even to the point of ad hominem in some replies. I hope that this has
> explained my opinion more clearly and responded to the criticism. If you
> still disagree, I think at this point it should just influence your vote
> rather than continue the argument.
> 

With all the following I'm speaking in general and don't explicitly try
to discredit your examples and facts of maintainership but to show why
it matters.

The problem here is that the initial trust for someone to be classified
as a trusted user does not magically come from the amount of non backed
claims of doing everything differently and properly once its about
official packages, trust comes from facts and examples. In general its
also lot more meaningful or obvious to make a judgement about things in
the domain of Arch instead of other distros where the insights are less
obvious, which doesn't mean its not a bonus.

An ideal trusted user, who is also responsible for the AUR as a
platform, should lead the community by example in terms of behavior and
packaging quality. If even our official members don't care because its
"just wild west" then how and why should it ever improve?

Or let's make it more dramatic: If the AUR itself should be considered
void then a bunch of garbage packages in the AUR plus the claim "but if
I'm elected I will only do super high quality shizzle" shall be enough
to make a judgement to _trust_ someone doing the right thing?

I'm not saying there is no difference in the official repositories and
the AUR, there is! But TUs are responsible to operate the AUR platform
and its really a non nice example for others if even the official's of
that platform just do it for nothing but "personal pride".

We are not talking about random AUR maintainers, but about someone who
wants to be considered a trusted entity of the community and hence it
matters to lead by example.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Trusted user application: Drew DeVault

[Levente Polyak via aur-general]

Hi,

Your build script on the CI does not produce reproducible packages as it uses a 
own simple wrapper to call makepkg. F.e. If there is no SOURCE_DATE_EPOCH 
defined to now or the value already passed it does not create uniform mtimes.

What I have noticed as well, f.e where you are upstream plus downstream, there 
is CPPFLAGS as well which, at least downstream, we must ensure finds its way 
into the compilation flags. 

Out of curiosity, what kind of upstream watch are you using to be made aware of 
new releases? 


Vgo-git:
Should use go-pie as makedepends like all packages that work
it should respect LDFLAGS via extflags like gitea does.
Does not contain git makedepends, you should build in clean chroot via 
makechroot aka extra- wrapper from devtools to catch such case

python:
None of your python packages, neither in aur nor in your repo build CI are 
running any unit tests while most of them provide tests upstream. Using github 
sources and running unit tests to catch regressions is highly recommended, 
please go through them :-) 


Cheers,
Levente

Re: [aur-general] Trusted user application: Drew DeVault

[Levente Polyak via aur-general]

Hey Drew,

I wanted to poke you how things are going? Would love to see my review
being incorporated, it took quite a while to look everything up.
This applies to the first batch as well, not just the list you wanted to
look up later. For example python-sshpubkeys build issue, the FHS
changes and the unit tests from the first batch are not yet in AUR.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] Trusted user application: Drew DeVault

[Levente Polyak via aur-general]

On 2/25/19 5:55 PM, Drew DeVault wrote:
> Thanks for all the feedback! I went through and cleaned up all of my AUR
> packages - something a wiser man would have done before submitting the
> TU application.
> 

You're welcome, but from me this was just the travel version... here
comes the full unleashed feature set of xxarhtna
For now reduced to python only and some random picks, If i find time I
will take a look at the other packages as well.

> 
>> Out of curiosity, what kind of upstream watch are you using to be made
>> aware of new releases? 
> 
> For the AUR I don't keep up with upstream releases, I just wait for
> someone to mark the package as outdated. For Alpine Linux I use a
> combination of subscribing to the upstream -announce mailing list and
> subscribing to GitHub releases as appropriate; would do something
> similar for Arch Linux community.
> 


Well, to be honest its the maintainers responsibility to keep track of
upstream and not outsource out of date flagging to someone else. There
is no difference between [community] and AUR for something that is a
maintainer responsibility.



Back to packages:

Really no offense, but I really had high expectations and got very
surprised: At some point I started wondering if you read error and log
output while trying to package or run tests?
Some of this findings indicates you don't (when you change some stuff)
or at least stop any investigation if f.e. a test suite doesn't run
straight. I would like to see more investigative behavior of a
maintainer in getting things sorted out the correct way instead of just
abandon if it requires a bit of patience and thinking plus time.

Also i encountered some examples of non working pkg build of very recent
changes that make me think changes are pushed straight to the AUR before
any build/test ever happened.

If there is stuff to rule out and you need ideas and another pair of
eyes, just ask for it... that's what a team and a community should be
for, nobody knows everything.
Also some of the packages don't work as they are not python 3.7
compatible at all so i wonder if anyone uses them a all?

Also i noticed you may maybe not know 'namcap' because of so many
missing licenses plus stuff like Non-FHS man page violations.




patchrom:

- Non-FHS man page in /usr/man/man1

mktiupgrade:

- Non-FHS man page in /usr/man/man1

mkrom:

- Non-FHS man page in /usr/man/man1

kpack:

- Non-FHS man page in /usr/man/man1

genkfs:

- Non-FHS man page in /usr/man/man1


sass:

- did you test building this package before pushing
  an added LICENSE dist line 2 days ago? Because this
  indicates something went wrong:
  install: cannot stat 'LICENSE': No such file or directory
  ==> ERROR: A failure occurred in package().


python-sshpubkeys:
- what does the 1.0.5 do in the URL? :P

- do you use proper clean environments for building? asking because:
  ==> ERROR: A failure occurred in build().
  ModuleNotFoundError: No module named 'setuptools'et
  This packages requires setuptools makedepends
  doesn't your CI or AUR testing use clean/isolated and non polluted
  environments for building?

- what does check() do, build the package? that should be 'test' instead
  of 'build' Btw: please use github sources, the pypi re-distribution
  doesn't contain any tests in the first place
  PS: to avoid setuptools download checkdepends it needs:
  cffi, asn1crypto, pycparser (take a look on log output)

- this package doesn't provide LICENSE.txt as github contains, please
  use github sources and include it
  PS: do you use namcap on your packages to find some frequent mistakes?



python-spam-blocklists:

- what does the 0.9.3 do in the URL?

- what does the comment mean about "only py2"?
  if you run the tests reality shows it just doesn't work at all:
  ModuleNotFoundError: No module named 'urlparse'
  sources show from urlparse import urlparse which can't be fulfilled
  anywhere
  nice indicator: Latest commit on Jun 15, 2012, this stuff is just
  dead, nuke


python-pystache:

- doesnt distribute the MIT license which exists in the sources

- there is a test runner using python ./test_pystache.py
  which pretty much shows this is dead non working stuff as well:
  File "/build/python-pystache/src/pystache-0.5.4/pystache/parser.py",
  line 15
  NON_BLANK_RE = re.compile(ur'^(.)', re.M)
  SyntaxError: invalid syntax
  Latest commit 17a5dfd  on Sep 30, 2014


python-patreon:

- license is wrong, if you look at upstream its apache2

- this projects depends on python-six to run

- must depend on setuptools as makedepends instead of distribute
  as thats the correct module it requires

- no tests run, by adding checkdepends for python-mock python-pytest
  python-pytest-cov you can easily run a check() via
  python setup.py test
  which successfully runs 52 passed in 0.82 seconds


python-lark:

- misses python-js2py depends

- "# upstream tests fail due to path resolution errors"
  what exactly do you mean by that? If you investiate the files
  

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

[Levente Polyak via aur-general]

On March 22, 2019 3:02:44 PM GMT+01:00, "Alexander F Rødseth via aur-general" 
 wrote:
>
>TUs, please adopt, if you are interested:
>
>proxytunnel - a program that connects stdin and stdout to a server
>uncrustify - A source code beautifier
>vim-molokai - Port of the monokai colorscheme for TextMate
>vim-nerdtree - Tree explorer plugin for navigating the filesystem

Adopted those,
PS Cleanup is always good

Re: [aur-general] PKGBUILD review request

[Levente Polyak via aur-general]

Hey ho, 


On February 7, 2019 11:13:34 PM GMT+01:00, Josef Miegl  wrote:
>I've been trying to improve my AUR packages for the last few days. I'm
>still a beginner in package maintaining so I would like to have some
>feedback on some of my PKGBUILDs. I would love to hear everything that
>is wrong about them. Thanks!
>
>pkgver() {
>  cd "${srcdir}/${pkgname%-git}"
>  echo $(git describe --always | sed 's/-/./g')
>}
>

Please do not use pkgver functions like that, they
don't work in vercmp as you would assume.
If upstream releases with a fix up version release
you gonna end up with a epoch bump. 

You could do something like described in the wiki

sed 's/\([^-]*-g\)/r\1/;s/-/./g' }

This prefixes the revision count like:
2.0.r6.ga17a017

Which behaves properly. 

https://wiki.archlinux.org/index.php/VCS_package_guidelines#The_pkgver()_function

Re: [aur-general] TU membership application

[Levente Polyak via aur-general]

On August 16, 2019 9:19:56 PM GMT+02:00, Jean Lucas via aur-general 
 wrote:
>
>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]:
>
>... , downgrade,... 
>

It's never been official in the past as that's per
 definition partial upgrade when using anything
 but the version from the repo. 
We do not support partial upgrades and we
 should not officially provide an application
 whose very purpose is to deviate from the
 current repo state to any arbitrary version in the
 past.

Re: [aur-general] TU membership application

[Levente Polyak via aur-general]

On September 4, 2019 4:37:42 PM GMT+02:00, Giancarlo Razzolini via aur-general 
 wrote:
>Em setembro 4, 2019 9:54 Alexander Rødseth via aur-general escreveu:
>> 
>> I did agree to sponsor the TU application of Jean Lucas, provided he
>found
>> another sponsor, but was not aware that he had sent his application
>without
>> any mentoring on my part.
>>
>
>Well, I think it should be the other way around, you first mentor
>someone and look
>with them into their packages and then decided about sponsorship.
>
>> I am not in favor of how the TU application process turned out, nor
>the
>> idea of moving proprietary software packages to [community], but I'll
>stand
>> by my word and sponsor him if there is another sponsor.
>>
>
>Sergej already confirmed sponsorship. But it seems neither of you
>actually mentored
>the applicant.
>
>> In general, we need more TUs and Devs and I think we should have a
>process
>> that feels less judgemental on the applicants (ref. the application
>from
>> Drew DeVault that sadly did not join us as a TU).
>>
>
>While I agree that we should have a more on point discussion with less
>bikeshedding
>regarding other stuff, I don't think that simply foregoing the
>discussion period is
>the way to go.
>
>> If someone dislikes a TU application, it's easy to vote "no" in the
>vote
>> that follows.
>>
>
>That's not how this should be faced. Ideally all the applications
>should have two
>sponsors that are actively mentoring the applicant and are vested into
>their success.
>If we had that, applications would be voted "yes".
>
>ps: I'm not making any judgment on the applicant here. I've talked with
>him privately
>regarding this application process. While he failed to disclose that he
>had asked another
>TU before, I don't think it was in bad faith.
>
>Regards,
>Giancarlo Razzolini

I agree with grazzolini,
sponsors pretty much agreed themselves that
there was zero mentoring happening plus
xyproto obviously is even surprised so many
proprietary blobs are about to be added.

Not judging here by any means about the
applicant himself, but I consider the current
state as void as we frankly did not go through
long discussions and bylaw changes to
implement two sponsors if at the end it doesn't
provide more value than having a bigger number
and "having nothing against because someone
wants a package in the repo" . 

I'm happy to cast votes after the sponsors did
what sponsors shall do and take care of their
applicant - obviously there is much room for
discussing intends etc with sponsors.

Re: [aur-general] TU application: kpcyrd

[Levente Polyak via aur-general]

On 9/20/19 11:41 PM, kpcyrd wrote:
> Oops, sending the application again, this time with a signature
> attached.
> 
> --- 8< ---
> 
> Hello,
> 
> My name is kpcyrd and I'm applying to become a Trusted User with anthraxx', 
> sangys and jelles sponsorship.
> 
> I'm interested in rust, defensive programming and offensive security tooling. 
> Open source became an essential part of my life at some point and the idea of 
> contributing back to the community that gave me so much for free kept me 
> going the last few years.
> 
> I worked as both a software and IT security engineer in the past and I 
> currently do a combination of both as a contractor.
> 
> ---
> 
> # How I started using linux
> 
> - Started with linux by trying to remaster knoppix in 2010 for a while
> - Wiped my laptop in 2011 and installed debian with no way of return since it 
>  was my only computer at that time
> - First successful Arch Linux install I did was by helping a friend in 2013
> - Eventually migrated to Arch Linux myself in 2015 due to anthraxx
> - I currently run a combination of Arch Linux, debian and openbsd at home and 
> on servers
> 
> # How I contributed to the opensource community in the past
> 
> (somewhat chronological)
> 
> - Too many pull requests (stopped counting a long time ago)
> - Assisted debian-security with some issues (redis, mongodb and xul-ext-wot)
> - Wrote some PKGBUILDs that got moved into community
> - Revived http://tests.reproducible-builds.org/archlinux/
> - Packaged software for alpine, brew and openbsd
> - Packaged about 1/3 of the rust packages in debian
> - Co-authored the current reproducible builds rebuilder prototype with NYU
> - Recently became a debian maintainer (while running Arch Linux)
> 
> # AUR packages
> 
> I maintain a few packages in the AUR, the most relevant that I would like to 
> maintain in community at some point are:
> 
> - diesel_cli
> - cargo-tree
> - cargo-fuzz
> - cargo-crev
> - python-fints
> - python-mt-940
> - python-sepaxml
> 
> I'm also interested in co-maintaining reprotest and some of the packages 
> anthraxx currently maintains for me.
> 
> # Community packages I wrote or contributed to
> 
> - cjdns
> - go-ipfs
> - alacritty
> - reprotest
> - sniffglue
> - badtouch
> - rshijack
> - sn0int
> 
> # Upstream for the following packages in Arch Linux
> 
> - sniffglue
> - badtouch
> - rshijack
> - sn0int
> 
> ---
> 
> Thanks for taking the time reading this,
> 
> kpcyrd
> 



I'm hereby confirming my sponsorship. kpcyrd is a friend of mine in
both, cyber- and meatspace. He is a very kind person and I like his way
of thinking. His technical skills would be a great benefit for the TU
community.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application: kpcyrd

[Levente Polyak via aur-general]

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

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application: kpcyrd

[Levente Polyak via aur-general]

On 10/11/19 10:32 PM, Santiago Torres-Arias via aur-general wrote:
> 
> In a few years we will realize this was a success and all of arch will
> be written in Rust.
> 

Hmm, I thought that's the hidden agenda why we sponsored him?
*jokingly* (or maybe not? xD)



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application: kpcyrd

[Levente Polyak via aur-general]

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.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application; freswa

[Levente Polyak via aur-general]

On 5/16/20 10:48 PM, Markus Schaaf wrote:
> Am 16.05.20 um 21:01 schrieb Levente Polyak via aur-general:
> 
>> - shouldn't this package be named exfat-nofuse-dkms-git ? its not
> 
> Why would a fuse-filesystem use dkms? The whole purpose of fuse is to
> run in user space. And renaming packages is an annoyance.
> 
> Just my 2¢, as a user of this package.
> 
> BR
> 


What exactly do you mean? I'm talking about the exfat-dkms-git packages,
which in fact already uses dkms. I'm pretty sure you confuse something here.
And the name is in fact wrong, as its exfat-nofuse git package using
dkms, hence its name should be exfat-nofuse-dkms-git. In general it
doesn't matter much if renaming is annoyance, what matter is if the name
is correct or wrong.

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application; freswa

[Levente Polyak via aur-general]

On 5/6/20 11:19 PM, Frederik Schwan via aur-general wrote:
> 
> I am looking forward to working with you!
> Frederik
> 

Hi Frederik,

I'm happy to _already_ work with you as you are doing a great job on the
bugtracker. I hope we won't loose your power wrangling that beast :D

I managed to cut some free time to review all your packages, so here
comes the feedback,

cheers,
Levente

$ xxarhtna --user freswa

adobe-icc:
- could use TLS in url and source, because why not :}
- would be a good idea to reuse $pkgver in source=()

chisel:
- doesn't use a unique source as v$pkgver.tar.gz may exist
  multiple times. could use githubs full filename endpoint:
  $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz

dovecot-xaps-daemon:
- should not have the conflicts, its always the special
  variants that conflict on the regular variant, not the
  other way around
- doesn't use a unique source as v$pkgver.tar.gz may exist
  multiple times. could use githubs full filename endpoint:
  $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz
- could use the new set of go binary hardening flags so
  sources are fortified, pie, etc: CGO_{L,C,CXX,CPP}FLAGS
- License is a non common one but the distribution of anything
  indicating the license is missing.

dovecot-xaps-daemon-git:
- normally its a bit better to have a pkgver that actually
  has any meaning in what kind of version the installed pkg
  matches, like 0.7.r21.b098747 instead of 94.b098747
  git describe --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'
- could use the new set of go binary hardening flags so
  sources are fortified, pie, etc: CGO_{L,C,CXX,CPP}FLAGS
- License is a non common one but the distribution of anything
  indicating the license is missing.

dovecot-xaps-plugin:
- build function doesn't build anything, the package functions
  "make install" will do the real compilation.
- Should not makedepend on git as its not using git
- should not have the conflicts, its always the special
  variants that conflict on the regular variant, not the
  other way around
- doesn't use a unique source as v$pkgver.tar.gz may exist
  multiple times. could use githubs full filename endpoint:
  $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz
- License is a non common one but the distribution of anything
  indicating the license is missing.
- cmake has a convenient "-B build" to that doesn't require mkdir

dovecot-xaps-plugin-git:
- build function doesn't build anything, the package functions
  "make install" will do the real compilation.
- missing provides and conflicts on the regular non -git variant
- normally its a bit better to have a pkgver that actually
  has any meaning in what kind of version the installed pkg
  matches, like 0.7.r21.b098747 instead of 94.b098747
  git describe --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'
- License is a non common one but the distribution of anything
  indicating the license is missing.
- cmake has a convenient "-B build" to that doesn't require mkdir

duperemove-git:
- should not pull over plaintext git:// but git+https to provide
  endpoint verification and encryption during transit
- missing conflicts on duperemove
- normally its a bit better to have a pkgver that actually
  has any meaning in what kind of version the installed pkg
  matches, like 0.7.r21.b098747 instead of 94.b098747
  git describe --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'

exfat-dkms-git:
- shouldn't this also provide something like exfat and exfat-dkms
- this shouldn't confict on other special git variant exfat-git
- shouldn't this package be named exfat-nofuse-dkms-git ? its not
  just exfat-dkms, this is in fact exfat-nofuse

exfat-utils-nofuse:
- non quoted usage of ${srcdir} which may fail if it contains spaces
- autoreconf could be executed during prepare step

flexbox-udev:
- non quoted usage of ${srcdir} and ${pkgdir } which may fail if it
  contains spaces

gimp-plugin-separate+:
- modifying or patching files should be done during prepare

gtkhotkey:
- modifying or patching files should be done during prepare

heif:
- doesn't use a unique source as v$pkgver.tar.gz may exist
  multiple times. could use githubs full filename endpoint:
  $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz

jtool-bin:
- doesn't use a unique source and should prefix it with $pkgver
- package is outdated as v2 exists

latex-tuda-ci:
- doesn't use a unique source as v$pkgver.tar.gz may exist
  multiple times. could use githubs full filename endpoint:
  $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz

libpurple-lurch:
- should not on every single build side load the whole submodules
  repos, instead they should be declared in source=() and the
  paths updated accordingly -- for an exaple look at the mono package
- static version must not provides=() its -git counterpart

nameinator:
- doesn't use a unique source as v$pkgver.tar.gz may exist
  multiple times. could use githubs full filename endpoint:
  $url/archive/v$pkgver/$pkgname-$pkgver.tar.gz
- could use the new set of go binary 

Re: [aur-general] TU application: hashworks

[Levente Polyak via aur-general]

Hi hashworks,

some findings while I looked over your packages:

Tiny side notes:

nothing that really changes but I noticed you added some prefixed
sources like ${pkgname}-${pkgver}.tar.gz:: to github urls, just wanted
to make you aware github understands the following pattern:
source=("${url}/archive/v${pkgver}/${pkgname}-${pkgver}.tar.gz")

I've seen lots of .gitignore that contain "*.tar.*" and thought maybe
worth mentioning the existence of SRCDEST and PKGDEST which IMO is super
handy compared to spitting out stuff into CWD.

I've nearly never seen the distribution of README.md when it contains
some useful bits that may help people in /usr/share/doc/${pkgname} not
like that's a requirement or such, but can sometimes be super useful.


brickstrap-git:
- should distribute the man page it stores in docs by processing it via
  pandoc --standalone --to man docs/brickstrap.md > docs/brickstrap.1

certbot-dns-hetzner:
- uses setuptools entry_point so python-setuptools is a first level
  hard dependency
- missing hard requires on python-requests and python-zope-interface
  as used in the modules

certbot-dns-hetzner-git:
- same as certbot-dns-hetzner

dns-zone-blacklist-git:
- doesn't properly distribute a license declaration but just a comment
  about the json that declares the license type. Please distribute
  something in the licenses folder and ask upstream to provide a license
  file in tree

filebin:
- downloads all submodules all the time, must be declared in the
  source=() array and the url of the submodules updated to reflect
  the dependencies like f.e. mono does.

kiwix-desktop-git:
- the qmake file doesn't understand CPPFLAGS, you need to add that as a
  workaround to the regular flags to enable fortified sources
- didn't have time, but does PREFIX really need to contain ${pkgdir}?

libzim:
- should add explicit nepends on zstd as in fact it gets enabled
  automatically and hence is a hard dependency

mustache:
- project contains the tests via cmake that can be called in check()
  to ensure stuff most likely will work

pam-ihosts:
- does not respect CPPFLAGS nor LDFLAGS leading to unfortified binary
  without full RELRO as namcap also complains
- declares -fno-stack-protector... excuse me? ehm just no :D
- distributes an empty /usr/bin which isn't desired

pam-ihosts-git:
- same as pam-ihosts

prismatik-bin:
- hmm sources exist and a -git package seems to be possible, why
  not build from source instead? we love sources :)

prismatik-psieg-bin:
- same as prismatik-bin, more source more love

terraformer:
- RADME.md looks super useful, maybe worth distributing

zimwriterfs:
- does this really require gumbo-git, it has like 5 more commits since
  2015 compared to repo gumbo-parser. Maybe would make more sense to
  poke some upstream folks to tag a new version instead?
- seems to soon be superseded by zim-tools anyway


cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application - orhun

[Levente Polyak via aur-general]

Hey folks,

I hereby confirm my sponsorship. I believe Orhun would be a great
Trusted User. Considering his motivation, knowledge, projects and
packages make a good candidate for this role :)

cheers,
Levente



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] TU application - rgacogne

[Levente Polyak via aur-general]

On 11/13/20 8:52 AM, Remi Gacogne via aur-general wrote:
> Hello everyone,
> 
> My name is Remi Gacogne, and I hereby apply to join the Trusted Users
> team, kindly sponsored by Levente Polyak and Morten Linderud.
> 
> I'm 37 years old and live in Paris, France. My journey with Linux
> started around 1999 with Mandrake, quickly replaced by Slackware which
> has been my favourite distribution until I fell in love with Arch,
> around 2009. Since then I have been involved in several aspects of the
> life of the Arch community like the wiki and the bug tracker [1], but my
> main contributions have been to the security team, often bugging you
> folks with security issues in your packages :) You can find me on
> Freenode and OFTC under the nick of rgacogne.
> 
> I have contributed to many FOSS projects over the years, mainly by
> writing and fixing C, C++ and Python code, hopefully not introducing too
> many bugs in the process. Some of them can be found on my GitHub profile
> [2]. I have held positions as a sysadmin, security engineer and software
> engineer in the past, and am currently working for the PowerDNS [3]
> open-source company as a software engineer.
> 
> In my spare time I enjoy climbing, hiking, paragliding and trail
> running, as well as drinking beers. I'm also involved in a few
> non-profit organisations, far away from computers.
> 
> I am currently maintaining a few packages in the AUR [4], although most
> of the popular ones I used to maintain having been moved to community by
> existing TUs along the way, with my blessing and gratitude. As a TU I
> would like to move two of the remaining ones to community:
> - bgpq3
> - dnsdist
> 
> My main motivation for becoming a TU is however not to move those, but
> to relieve the workload of other TUs by helping maintain and/or adopting
> existing community packages. For obvious reasons I have already
> discussed adopting the powerdns and powerdns-recursor packages from
> anthraxx, but I would also be interested in adopting some orphans here
> and there, like for example hiredis, libopenraw and nsd. I should also
> mention that being a TU would be very useful to my work on the security
> team, since I would then be able to help fix critically vulnerable packages.
> My preferred, old-fashioned, way of keeping track of packages updates is
> to subscribe to mailing-lists, but I have come to appreciate the use of
> tools like nvchecker in doing so as well :)
> 
> Cheers,
> 
> Remi
> 
> [1]: https://bugs.archlinux.org/user/9172
> [2]: https://github.com/rgacogne
> [3]: https://www.powerdns.com
> [4]: https://aur.archlinux.org/packages/?SeB=m=rgacogne
> 

I hereby confirm my sponsorship of Remi :)

Basically the same story as Morten mentioned, we also first met in meat
space during the Chaos Communication Congress, however he did not
thought that i was jelle as well :P

I got to know him on multiple real life and virtual occasions as a very
friendly and kind person with a profound technical knowledge and lot of
contributions. I have no doubt that we will be a valuable Trusted User
and strengthen our team -- and on top will gain a bit more scope of
action for the Security Team duties.

Let the discussion period officially begin :)

cheers,
Levente



signature.asc
Description: OpenPGP digital signature