Re: [aur-general] TU removal: Ray Rashif

[David Runge]

On 2019-10-11 14:44:27 (+0200), David Runge wrote:
> In accordance to the bylaws a vote has now been started:
> https://aur.archlinux.org/tu/?id=120

The results are in:

Yes: 36
No: 7
Abstain: 6
Total: 49
Participation: 87.50%

The quorum of 66% has been reached with a larger number of "Yes", than
"No" votes.

This means Ray Rashif is no longer a Trusted User.

On behalf of the team I would like to thank Ray for his dedication
towards the community and distribution over the years.

I hope that his time permits further involvement in the future. :)

Bests,
David

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

Re: [aur-general] TU removal: Ray Rashif

[David Runge]

On 2019-10-08 14:35:22 (+0200), David Runge wrote:
> I would like to start the discussion period for a Trusted User removal
> of Ray 'schiv' Rashif on the grounds of 'Special Removal of an
> Inactive TU' [1]. Note, that this is separate from any motion in
> regards to Ray's developer status.
In accordance to the bylaws a vote has now been started:
https://aur.archlinux.org/tu/?id=120

Best,
David

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

Re: [aur-general] TU removal: Ray Rashif

[David Runge]

Hey Giancarlo,

On 2019-10-08 10:41:44 (-0300), Giancarlo Razzolini via aur-general wrote:
> I believe that the discussion period for removal by inactivity is 3
> days, not 7.  The voting period is 5 days.
Correct, somehow I had the 'Removal of a TU' rules in mind when writing
the mail.

> Other than that, the current proposal is 119, but it has not ended
> yet.
True, I misinterpreted the 'Last vote' column.

> If, during the discussion period, Ray ends up voting on that one,
> we'll have to stop this process.
How so? Not only are all three points matching, but also is voting (as
far as I understand the bylaws) specifically excluded as required action
(so we don't just have voters but no doers) in the first half of the
statement.
The first half of the statement is therefore true, no matter if Ray
votes or not.

Bests,
David

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

[aur-general] TU removal: Ray Rashif

[David Runge]

Hi all,

I would like to start the discussion period for a Trusted User removal
of Ray 'schiv' Rashif on the grounds of 'Special Removal of an Inactive
TU' [1]. Note, that this is separate from any motion in regards to Ray's
developer status.

Currently Ray is the maintainer of 60 packages in [community] and
[extra], of which none are actively maintained by him (for years).
Ray's last action as a community member (in archweb) has been on
'2019-03-12 12:50'.
The account 'schivmeister' doesn't maintain any packages in the AUR and
the last login in aurweb was on '2019-03-12'.
However, the last counted Trusted User vote is number 117 (current vote:
118).

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

Bests,
David

[1] 
https://aur.archlinux.org/trusted-user/TUbylaws.html#_special_removal_of_an_inactive_tu

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

Re: [aur-general] [arch-dev-public] Retiring as a Trusted User

[David Runge]

On 2019-10-02 11:10:59 (+0200), Florian Pritz via arch-dev-public wrote:
> openshot libopenshot libopenshot-audio
I adopted those (and libquicktime).

Thank you!

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

Re: [aur-general] TU membership application

[David Runge]

On 2019-08-16 17:10:41 (-0400), Jean Lucas via aur-general wrote:
> I would definitely be willing to very politely ask the five respective
> companies for redistribution permissions for Arch Linux.
In the case of reaper, I've already been in contact with Cockos to try
and move that to [community] and they didn't reply to multiple requests
through several channels.
On its own, I have not been able to make sense out of the OEM
distribution license [1] for that matter either.
"... but I'm not a lawyer (TM)."

Best,
David

[1] https://www.reaper.fm/dist-agreement.php

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

Re: [aur-general] Spam account/comments

[David Runge]

On 2019-07-01 21:20:01 (+0200), Joan Figueras via aur-general wrote:
> Hi, just saw a comment in one of my packages (icecat). The account seems
> clearly a spammer:
> 
> https://aur.archlinux.org/account/jennifer247/comments

Thanks! Taken care of.

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

Re: [aur-general] Another spammer

[David Runge]

On 2019-06-18 02:05:37 (+0300), Edvinas Valatka via aur-general wrote:
> https://aur.archlinux.org/account/rosaleefay
Thanks! Taken care of!

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

Re: [aur-general] Purge of packages orphaned, out-of-date, and last updated before 2017

[David Runge]

On 2019-01-26 08:01:46 (+0100), Alad Wenter via aur-general wrote:
> Not too long after I became TU I deleted something of ~2000 packages,
> based on similar "criteria" and after seeing no "objections" on IRC
> after a while. After the deed was done I got emails, angry shouting on
> IRC and complaints for the following 6 months on BBS and other places. 
"they took our packages" *rantyface* *screaming*

> tl;dr use requests like everyone else, or patch aurweb to have "batch 
> requests"
Yes, please requests! This way stuff at least gets to the mailing list
and is somewhat documented.

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

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

[David Runge]

On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote:
> On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote:
> > * pkgname: avoid composition
> What should I do?
It's more readable and less error-prone to do `pkgname=name` instead of
`pkgname="name${something_else}"`.

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

> >  LICENSE.md can be installed using 'install -t'
> 
> Why is use
> `install -t`
The upside is, that you can ommit the specific destination (unless you
want to rename the destination file).
e.g. `install -vDm 644 LICENSE -t
"${pkgdir}/usr/share/licenses/${pkgname}/"` creates the directory
"${pkgdir}/usr/share/licenses/${pkgname}/" for you, if it doesn't exist
and will install the source file to that directory, without you having
to specifically name the destination file.

Whereas the following requires you to specify the destination file as
well: `install -vDm 644 LICENSE
"${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"

Not using the `-t` flag is only useful, if you need to rename the
destination file, e.g.:

`install -vDm 644 WEIRDNAME_FOR_A_LICENSE
"${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"

In short: This is shorter and implies the creation of the destination
directory.

Closing: Please use a mail client, that doesn't break threads (i.e.
replies to the thread that was initially created, instead of creating a
new one.
Mailman is somewhat able to order these threads in the list archive, but
in mail clients this is horrible to follow up on (there are now 4
separate threads [1] [2] [3] [4]). Compare the 'In-Reply-To' header in
the messages with those of others.

Aside from that, happy packaging! :)
David

[1] https://lists.archlinux.org/pipermail/aur-general/2018-December/034744.html
[2] https://lists.archlinux.org/pipermail/aur-general/2018-December/034758.html
[3] https://lists.archlinux.org/pipermail/aur-general/2019-January/034799.html
[4] https://lists.archlinux.org/pipermail/aur-general/2019-January/034848.html

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

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

[David Runge]

On 2018-12-27 15:50:49 (+0800), Metal A-wing wrote:
> I'm sorry, my last application was bad a few days ago.
Not so easy for reviews, if you're applying between Christmas and New
Years (lots of people are not home and/or busy hanging out with people
then).

> I am a Web Developer. uav cloud management system dev in UAV company.
> (not DJI)
Would you also be interested in improving the AUR, and website?

> I use ruby on rails web-application framework Or express.js, Koa.js,
> and Frontend Single Page Application（SPA）use vue.js
Probably helps maintaining ruby /rails stuff then!

> In 2017, I started Archlinux
That's not true! :-P
https://wiki.archlinux.org/index.php/Arch_Linux#History

> About my involvement in Arch Linux, I have 11 packages on AUR [1].
vrzvd 0.0.1 starting up...

* electron-netease-cloud-music
  * electron-netease-cloud-music.sh: just call `/usr/bin/electron
   /usr/lib/electron-netease-cloud-music/electron-netease-cloud-music.asar`
   and remove the rest
  * electron-netease-cloud-music.png: remove and download from upstream
if necessary
  * pkgdesc: clinet should be client
  * arch: not set! should be 'any'
  * license: should be 'GPL3' (see `pacman -Ql licenses`)
  * depends: single quotes missing
  * source_x86_64: should be source, don't upload binary data to the
AUR, 
  * md5sums_x86_64: should be md5sums
  * prepare(): use gendesk to create the missing XDG desktop file
instead of adding it to the repository
  * package(): cd to $srcdir is unnecessary, remove commented line
installing svg, asar should be called in prepare() to extract
LICENSE, LICENSE can be installed using 'install -t'

* ruby-actionable
  * pkgname: avoid composition
  * arch: single quote
  * url: use double quotes and a correct upstream url... ERROR:
upstream missing: https://rubygems.org/gems/actionable but part of
rails: https://github.com/rails/rails/tree/master/actioncable
  * license: single quotes missing
  * depends: differs from rubygems information (
https://rubygems.org/gems/actionable ), single quotes missing
  * build(): not building from source!
  * check(): no check is run
  * package(): _gemdir can be derived from $(gem env gemdir),
MIT-LICENSE can be installed using 'install -t'

* ruby-activejob
  * pkgname: avoid composition
  * arch: single quote
  * url: use double quotes and a correct upstream url... ERROR:
upstream missing: https://rubygems.org/gems/activejob but part of
rails: https://github.com/rails/rails/tree/master/activejob
  * license: single quotes missing
  * depends: single quotes missing
  * build(): not building from source!
  * check(): no check is run
  * package(): _gemdir can be derived from $(gem env gemdir),
MIT-LICENSE can be installed using 'install -t'

* ruby-activestorage
  * pkgname: avoid composition
  * arch: single quote
  * url: use double quotes and a correct upstream url... ERROR:
upstream missing: https://rubygems.org/gems/activestorage but part
of rails: https://github.com/rails/rails/tree/master/activestorage
  * license: single quotes missing
  * depends: single quotes missing
  * check(): no check is run
  * package(): _gemdir can be derived from $(gem env gemdir),
MIT-LICENSE can be installed using 'install -t'

* ruby-bacon
  * pkgname: avoid composition
  * pkgdesc: start with capital letter
  * arch: single quote
  * url: use double quotes and a correct upstream url... ERROR:
upstream missing: https://rubygems.org/gems/activejob but part of
rails: https://github.com/rails/rails/tree/master/activestorage
  * license: must not be empty!
  * depends: single quotes missing
  * build(): not building from source!
  * check(): no check is run
  * package(): _gemdir can be derived from $(gem env gemdir),
COPYING can be installed using 'install -t'

* ruby-erubi
  * pkgname: avoid composition
  * arch: single quote
  * url: use double quotes
  * license: single quotes missing
  * depends: single quotes missing
  * makedepends: single quotes missing
  * build(): not building from source!
  * check(): no check is run
  * package(): _gemdir can be derived from $(gem env gemdir),
MIT-LICENSE can be installed using 'install -t'

* ruby-globalid
  * pkgname: avoid composition
  * arch: single quotes missing
  * url: use double quotes and a correct upstream url
https://github.com/rails/globalid
  * license: single quotes missing
  * depends: single quotes missing
  * build(): not building from source!
  * check(): no check is run
  * package(): _gemdir can be derived from $(gem env gemdir),
MIT-LICENSE can be installed using 'install -t'

* ruby-marcel
  * pkgname: avoid composition
  * arch: single quotes missing
  * url: use double quotes
  * license: single quotes missing
  * depends: single quotes missing
  * makedepends: single quotes missing
  * build(): not building from source!
  * check(): no check is run
  * package(): _gemdir can be derived from $(gem env gemdir),

Re: [aur-general] Sound in systemd service

[David Runge]

Hi!

TL;DR: Don't. Use what the package provides and start it as a systemd
user service!

On 2019-01-02 00:56:24 (+0100), NicoHood wrote:
> I currently try to create a system-wide spotifyd service that can play
> music from a dedicated user/group. I used the spotifyd package from AUR
> as a base:
> https://aur.archlinux.org/packages/spotifyd/
> 
> I added a user directory for the user and added it to the audio group:
> u spotifyd - "Spotify daemon user" /var/lib/spotifyd
> m spotifyd audio
That's not a good idea.

> The directory is created like this:
> d /var/lib/spotifyd 0750 spotifyd spotifyd -
That also is unneeded.

> I've added to the system service to start with a config file in
> /etc/sptoifyd.conf and start with:
> User=spotifyd
> Group=spotifyd
Also pointless.

> Now the service is running fine in the background, I can select it in
> spotify. But no sound will play. I am also running a gnome desktop
> environment with pulseaudio on the machine. And I dont know how to get
> audio working within this service. The software supports alsa backend
> and pulseaudio backend, but none of them seem to give me a sound.
Not sure how to operate multiple pulseaudio sinks of multiple users to
work together. However, ALSA will only allow to be accessed by *one*
application/mixer/whatever.

> If I run locally, I get:
> $ sudo -u spotifyd -g spotifyd /usr/bin/spotifyd --no-daemon --config
> /etc/spotifyd.conf
> 
> ```
> No protocol specified
> xcb_connection_has_error() returned true
> ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave
> 00:42:24 [ERROR] Alsa error PCM open -2
> 00:42:24 [ERROR] Could not start audio: Alsa error: PCM open failed
> ```
AFAICS this is because your user session with activated pulseaudio
already grabs the ALSA device. There can only be one client.
Additionally: Arch actually doesn't require being in the audio group and
might be more in the way than anything else (it's also not required for
your own user!):
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/PerfectSetup/

> This does not happen with my local user, even with `sudo -u nicohood`.
Well, if you have a user session with that user, pulseaudio will have
already grabbed the device.
Running notifyd with sudo -u (see `man sudo`) roughly equals just
running directly as your user.

> Using a more simpler command gives me the same problem:
> $ sudo -u spotifyd -g spotifyd aplay
> /usr/share/sounds/alsa/Front_Center.wav No protocol specified
> xcb_connection_has_error() returned true
> ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave
> aplay: main:828: audio open error: No such file or directory
Same problem as above.

> Can anyone give me a hint how to get audio running with this separated
> user/service?
Start the user service with your session (running spotifyd as your user)
and use the pulseaudio backend to not use ALSA directly and block your
device for other applications.

That's btw. also what upstream intends:
https://github.com/Spotifyd/spotifyd#running-as-a-systemd-service
And it's also how the packager installs it:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=spotifyd#n35

Additionally:

If it was Tidal, you could use mpd:
https://www.musicpd.org/doc/html/plugins.html#tidal
While looking at mpd, I realized, that the mpd user is in the audio
group... and I'm not sure, but this might actually break fast user
switching and should probably be removed.

If it had a JACK backend, you could use $JACK_PROMISCUOUS_MODE to access
a local jackd with multiple clients (from different users).

Best,
David

P.S.: We now have the arch-proaudio mailing list, where one can ask
about these types of setups/ideas.

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

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

[David Runge]

On 2018-11-28 20:10:52 (+0100), Robin Broda via aur-general wrote:
> On 11/18/18 3:52 AM, Xyne wrote:
> > On 2018-11-12 12:22 +0100
> > Levente Polyak via aur-general wrote:
> >> 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.
> > 
> > However, rather than requiring multiple sponsors just to apply, I suggest
> > requiring multiple sponsors to proceed to the vote. The procedure would be:
> > 1. A TU identifies a good candidate and discusses the idea with them.
> > 2. The TU reviews the candidate's packages and community participation
> >thoroughly and suggests improvements if necessary.
> > 3. Once all suggested improvements have been made, the TU agrees to sponsor 
> > and
> >the candidate applies.
> > 4. The TU confirms and explains their sponsorship, citing specifics.
> > 5. Other TUs review the application. TUs that are confident in the candidate
> >after review then vouch for the candidate by co-sponsoring them. In 
> > addition
> >to the quality of packages, the co-sponsors should have at least been 
> > aware
> >of the candidate within the community for an extended period of time.
> > 6. If x TUs agree to sponsor within the discussion period, the vote goes 
> > ahead 
> >as usual. If not, the candidate has to wait as usual to reapply. During 
> > the
> >wait, TUs can pay closer attention to the candidate until they feel
> >confident enough to co-sponsor.
> 
> Should we get these points formalized in the bylaws?
I think so.

> I feel like maybe if we split up each point and have a vote for each
> of them, we could figure out what exactly the others from the team are
> looking for - without blocking some of the proposals here by batching
> them up with the ones that weren't so well received.
I agree with that and generally like the ideas put forward by Xyne (in
extension of what Levente wrote).
Having them separetely votable is preferable I guess.

I see, that we need more participation in the voting and reviewing
process and I think that a more formalized rule set can help in doing so
(and not just having one or two people do the review and then feeling
overwhelmed at some point).

I also think, that this has the potential to raise the overall package
quality (aka teamwork) and help TUs across the board to learn new
things.

I don't believe in a separate gremium, that will magically fix this.
Some TUs are exactly that involuntarily already (e.g. by choosing to
review) - or at least it somewhat feels like it ;-)
However, no single person can and or should do that all the time.

> What are your thoughts?
Let's do it!

Best,
David

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

Re: [aur-general] Spam Account

[David Runge]

On 2018-11-23 08:40:32 (+), Morgan Adamiec via aur-general wrote:
> Another spam account:
> https://aur.archlinux.org/account/markwilliamson/
Thanks for the notification!
The account is now suspended and spam comments have been removed.

Best,
David

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

Re: [aur-general] TU Membership Application

[David Runge]

On 2018-11-09 19:05:58 (+0100), David Runge wrote:
> Let's vote! :)

The results are in (the vote ended nearly an hour ago)!

Yes:  26
No:9
Abstain:  12
Participation 90.38% (come on, don't drop the ball on this! ;-))

I have just updated your account status in the AUR to 'Trusted User'.
Congratulations!

Please follow up on the TODO for new Trusted Users [1].

See you on IRC :)

Bests,
David

[1] 
https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_for_new_Trusted_Users

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

Re: [aur-general] TU Membership Application

[David Runge]

On 2018-11-09 13:11:19 (-0500), Eli Schwartz via aur-general wrote:
> This definitely lists the right time period:
> https://aur.archlinux.org/trusted-user/TUbylaws.html#_addition_of_a_tu
Yep, sorry, that was just a brainfart from my side. ;-)

Here's the link to the vote btw:
https://aur.archlinux.org/tu/?id=112

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

Re: [aur-general] TU Membership Application

[David Runge]

As the (newish, but still not updated [1]) discussion period of 14 days
is now over, I have started the vote.

Thanks again to all reviewers and active TUs in this discussion period!
I think Brett will make a good TU!

Let's vote! :)

[1] 
https://aur.archlinux.org/trusted-user/TUbylaws.html#_standard_voting_procedure

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

Re: [aur-general] TU Membership Application

[David Runge]

On 2018-10-25 08:26:11 (-0600), Brett Cornwall via aur-general wrote:
> I am being sponsored by dvzrv.
I hereby ACK that and apologize for the confusion the last time (again).

> I would like to get valuable tools promoted into [community], such as
> residualvm or the 'pass' plasmoid (after prodding upstream to have a formal
> release). Other packages that I do not maintain in the AUR would be ripe for
> picking as well, such as sc-controller or ttf-lato. I would also work with
> dvzrv on maintaining pro-audio packages, many of which were abandoned when
> SpepS left.
That would be very awesome!

The best of luck to you and let the discussion begin!
This seems to be a good month for TU applications.

Best,
David

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!

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

Re: [aur-general] Greetings and Documentation Proposals

[David Runge]

On 2018-10-07 20:06:47 (+0200), David Runge wrote:
> I hereby ACK my sponsorship!
> 
> Let the discussion begin :-)
As there has been quite a misunderstanding on my side, regarding when
and how Brett wanted to apply to become a TU, please disregard my last
e-mail. (I should stop replying to mails on my phone, when only
half-awake).

In case he does apply in the future though, I'd be happy to be the
sponsor.

Best,
David

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

Re: [aur-general] Greetings and Documentation Proposals

[David Runge]

On October 7, 2018 5:41:41 PM GMT+02:00, Brett Cornwall via aur-general 
 wrote:
>Hello, fellow Archers. My name is Brett and I've been making PKGBUILDs 
>for the AUR for some time under the moniker 'Ainola'. A number of these
>
>packages have been kindly pulled into [community] by David Runge. I've 
>since had a desire to get some of my other packages into [community],
>so 
>I'm interested in working towards getting TU status. I'm also involved 
>in the LibreOffice community (I just got back from the conference in 
>Albania).
>
>David has been kind enough to give suggestions to my current packages; 
>I'd love to nab some other packages throughout the AUR, improve them, 
>and get them included in the repositories for mass consumption.
>
>I would also like to improve the documentation for the devtools: There 
>are no manpages, /usr/share/docs/ items, or wiki articles. Unless I'm 
>mistaken it appears that the only documentation that currently exists
>is 
>just invoking the program with -h. I'd like to fix that. :)

I hereby ACK my sponsorship!

Let the discussion begin :-)
-- 
https://sleepmap.de

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

[David Runge]

On 2018-04-04 11:01:20 (-0500), Doug Newgard via aur-general wrote:
> > Please be specific. We aren't talking about hours and bumping
> > package version.  Common sense can be used to know when taking
> > action will make people worse-off.
> > The package was managed so efficiently that even upstream benefited
> > from it.  Archlinux maintainer dosen't have to do anything else than
> > copy-paste existing PKGBUILD. All work and testing is already done.
> > 
> > ​Jordan
> 
> I have been specific; the rules are in place for a reason, common sense says
> that they're necessary. This case is not special.
> 
> C the entire PKGBUILD would be a huge mistake. Those sed commands
> are...marginal, to be generous.

While being in line with what Doug wrote on the topic, I agree, that it
took quite some time to upgrade, but behold! dnscrypt-proxy 2.0.8 is now
in community-testing (btw: no, not just c/p) [1].
I do understand that a longer wait time can be frustrating for users,
but it's no reason to get aggressive about it.
The upstream situation was far from "easy going" IMHO, which was all the
more reason to wait and see what would happen.

A few (unpaid) hands are trying to keep up the shape of what Arch is. I
have the feeling, that sometimes it is easily forgotten, that we are a
community of like-minded (and from what I read, passionate) people. If
you find a problem, go ahead and fix it (e.g. by applying to become a
TU and engaging in the overall quality of the distribution), but please
keep in mind, that we're all doing this in our free time.

[1] https://www.archlinux.org/packages/community-testing/x86_64/dnscrypt-proxy/

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

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

[David Runge]

On 2018-02-03 14:41:33 (+0100), Pierre Neidhardt wrote:
> You are probably right about that.  I think however that this should be
> reported upstream to systemd rather than being part of the xss-lock
> package.
Hmm, I could find a (probably) related RFE [1].

[1] https://github.com/systemd/systemd/issues/6978


-- 
https://sleepmap.de


signature.asc
Description: PGP signature

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

[David Runge]

On 2018-02-03 14:00:29 (+0100), Pierre Neidhardt wrote:
> As far as I can tell, xss-lock is already run when I resume from a
> suspend.
Ah lol... I was under the impression, that xss-lock would need to be
told to lock.
It seems loginctl sends out the 'lock-sessions' after waking up from
suspend by default.

> I'm no systemd expert: what is the intent of the suggest systemd unit?
This would only ensure, that lock already happens right before suspend
(in the case, someone wants that).
This use-case gets around the problem of showing a small portion of
what's going on in your DE/WM right after suspend and only then
locking/blanking.
IMHO locking before suspend is preferred, but that's probably a matter
of taste.

Best,
David

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

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

[David Runge]

Hi Pierre,

On 2018-01-23 10:14:12 (+0100), Pierre Neidhardt via aur-general wrote:
> No answer from the dev so far, so I've packaged the latest commit as Eli 
> suggested.
> Let me know if there is anything wrong.
nice to see this in [community]!

Could you also include a service file, that propagates the lock-sessions
command, in the vein of what was suggested upstream [1]?

IMHO that would be very useful!

Best,
David


[1] 
https://bitbucket.org/raymonad/xss-lock/issues/18/systemd-unit-for-locking-on-sleep

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

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

[David Runge]

On January 19, 2018 9:42:26 AM GMT+01:00, Bennett Piater  
wrote:
>
>
>On 01/18/2018 09:37 PM, Alad Wenter via aur-general wrote:
>> See the bug report I linked in the first reply.
>> 
>>
>https://bitbucket.org/raymonad/xss-lock/issues/17/does-not-report-activity-to-systemd-logind
>
>Right, that is actually something else than what I did.
>I used `xset s` to trigger on inactivity, and xss-lock correctly locks
>the screen when that happens.
>
>So it seems like it can still be used as a replacement for xautolock.
Fwitw (and sorry for hijacking), I recently tried xprintidle (with a forked 
upstream, different from the one in the AUR) and it seems to work.
This might still be used in a script to lock screens automatically under X, but 
it's clunky. I'd much prefer a more complete solution, as xautolock is aging 
(not so well) and at least in my case produces undesirable  defuncts from time 
to time.
xss-lock seemed too broken at that time, so I never used it.
Are there any other alternatives not mentioned in the wiki?

Best,
David

-- 
https://sleepmap.de

Re: [aur-general] TU Application: David Runge

[David Runge]

On November 1, 2017 11:17:27 AM GMT+01:00, Eli Schwartz 
 wrote:
>On 10/31/2017 03:17 PM, Ray Rashif via aur-general wrote:
>> Congratulations, David, you are now an Arch Linux Trusted User!
Thanks for... well, the trust I guess!

>Congratulations, David!
>
>As Ray said, you seem to have two bugtracker usernames, dave.ze.rave
>and
>davezerave, but Flyspray throws errors when I try to access the former
>and the latter is the only one that has actually seen activity, so I
>have assumed your bugtracker account is
>https://bugs.archlinux.org/user/9560
>
>I have upgraded it to be part of the Trusted Users group in the
>Community Packages project, and given you access to the Keyring project
>as well.
Thanks, Eli!
I think the former had an issue and might be registered under a now 
non-existent mail address.
It can probably even be deleted, if flyspray supports that.

Anyone lurking in the TU IRC channel and able to send me the access password?

Will get around the rest of the TU todos later in the evening.

Best,
David

-- 
https://sleepmap.de

Re: [aur-general] TU Application: David Runge

[David Runge]

On 2017-10-25 00:08:31 (-0400), Eli Schwartz wrote:
> Well, yeah. It's more clear what you're doing.
> 
> FWIW, I typically use a source url like this:
> 
> _file=742770
> source=("${_pkgname}-${pkgver}.xpi::https://addons.mozilla.org/firefox/downloads/file/${_file}/;)
Hmm, this doesn't seem to provide a valid download url for tab tree.
In any case, I changed it to a more sane/readable file name already.

> It's a pity that Mozilla doesn't provide a stable API to get an
> extension by name and version, and the only way is with a file instead.
Yes.

> >> mantisbt:
> >> - this incredibly gross install script messes around with unpackaged
> >>   files, please don't do this
> > Okay. What would be a good alternative though?
> > Using the application during upgrade might potentially break the
> > database. However, the mantis_offline.php file prevents users from
> > interacting with the application.
> > I know that hooks such as the one introduced for nextcloud quite
> > recently (for a while) won't work either.
> 
> Hmm, actually I'm not sure what the solution to that is. Has upstream
> ever considered doing something more sane like autotriggering offline
> mode when the version in the *database* indicates it is out of date? :D
I think that would indeed be a good feature request. ;-)

> But the major thing that I didn't like was the rm -rf in the
> post_remove. I cannot think of a good reason to be doing that, unless
> the application stores user data there, and in that case I don't think
> you should be deleting user data. The user can clean up their leftover
> data by hand once they are sure they don't need it anymore, which is
> safer than causing it to accidentally get deleted when they didn't
> intend to do so.
That's correct and I removed it (also: version bump).
I should have probably thought about the install script more, when
mantisbt was dropped from community [1].
Maybe it was introduced to take care of dead copies of the
mantis_offline.php file... but also that doesn't make much sense.

> > Also: Debugging seems to be activated in the main repository as well. oO
> 
> I have no good explanation for this, but speps isn't really around much
> to ask him anymore...
> 
> Originally added in pd 0.46.7-1 back in 2015 and never changed.
> 
> This is why it would be nice to have debugging repos, of course. Also
> special --enable-debug flags are generally not needed when using
> options=('debug') will enable debug flags in CFLAGS anyway, so if for
> some reason debug was enabled at all, I'd expect to see that happen in
> the options array.
It would be indeed a very nice thing to have. Often, when running into
issues with more complex pieces of software, such as DAWs, it can be
very helpful (if you can actually reproduce your issue).

> >> - patching should also go in prepare(), and come before autogen on
> >>   principle
> > Sadly I have to patch configure. Upstream is vry slow on
> > merging pull requests, so the switch to qt5, that would make this all go
> > away, is still not upon us :(
> > Moved.
> 
> Well, no. You "need" to patch configure.ac instead. :D
Whoops. That's correct.
Guess I jumped a step, as I rebuilt it very frequently for my thesis.
What would be the thing to do for the non-git version of the package
though, as configure is already present? I could run autoreconf again I
guess.

> >> supercollider-git:
> git describe HEAD is the same as git describe, the HEAD there just seems
> a bit out of place (and introduces a very minor degree of complexity to
> analyze). As per git-describe(1), "Commit-ish object names to describe.
> Defaults to HEAD if omitted."
Fixed.

> As for their tagging problems, seems to me there's a blatantly simple
> solution. :D Just use annotated tags for all versioned releases, and use
> lightweight tags for whatever inaccurate tag-which-should-be-a-branch
> they want
> 
> But if you want real fun, see the qbittorrent-git PKGBUILD which I
> co-maintain.
> It appears to be policy to maintain a master branch for development and
> a vX_X_X branch for cherry-picking release commits just in time for
> tagging a release. Or something.
"Not listening..." :>

> >> - why some big complicated switch for configuring based on the CARCH,
> >>   why don't you just use the $CARCH variable you already have available,
> >>   and if you actually have to do different things depending on the
> >>   CARCH, then you can make this a lot easier to read by including extra
> >>   options in a bash array for safe tokenization.
> > Sounds interesting. Will rework this, as soon as I have my Pis up and
> > running again.
> > Note however, that some hacks are necessary for supercollider to
> > function on a headless system (which embedded systems often are).
> 
> Hacks are fine, making the application of those hacks more readable is
> even better. ;)
True. Hope I can (finally) unpack my ARMs this week again.

> Happy to help, this is a bit of a hobby of mine. :) Thanks for the quick

Re: [aur-general] TU Application: David Runge

[David Runge]

On 2017-10-24 22:43:50 (+0600), Rashif Ray Rahman wrote:
> I do have one thing to say to David: please do think about the time
> commitment associated with this. If you think that you won't be able
> to commit much starting out, then it will be quite sad moving forward.
I have thought about this a lot of course, before applying.
Like anyone else I have a life with a job (or several from time to
time). This week is quite extreme though (even by my standards) work
wise and I should have communicated that before applying. Some projects
or new things (in work life) turn out to eat more time and energy than
intially expected though.

> Otherwise, I say again that David's proposal has followed standard
> procedure, including a holistic review by myself the sponsor. Some
> issues were raised based on automated tool reports, which I think
> David will be able to resolve.
I hope my mail from earlier could clear things up.

> Good luck!
Thanks!

Best,
David


-- 
https://sleepmap.de


signature.asc
Description: PGP signature

Re: [aur-general] TU Application: David Runge

[David Runge]

Hey again,

multiple occurences are not quoted again.

On 2017-10-22 23:44:39 (-0400), Eli Schwartz wrote:
> crypted-backups-git:
> - empty variables and arrays are messy
Fixed.

> - unquoted $pkgdir, though $srcdir is consistently quoted
Fixed.

> - the pkgver() fallback for non-tagged repos can be simplified
Fixed.

> - build() does nothing, why does it exist?
Reasons unknown. Deleted.

> - source urls for git repositories should be cloned over https:// rather
>   than git:// in order to take advantage of cacert verification
Thanks! Completely forgot to enable that on my server and used git://
ever since...

> - source urls do not need to be prepended with "${_pkg}::" when they
>   don't actually need to be renamed
Fixed.

> - there is no need to `install -d ... && install -Dm644 ...`, just do
>   the second part
Ah... the source's expansion prevented a successful -Dm***, so I used -d
to create the destination first.
I should've used the -t switch.
Fixed.

> easytranscript:
> - inconsistent quoting of array elements; why does license have double
>   quotes?
Reasons unknown. Fixed.

> firefox-extension-tab-tree:
> - pkgdesc is self-referential, see the wiki for guidance on a good
>   pkgdesc: https://wiki.archlinux.org/index.php/PKGBUILD#pkgdesc
Fixed.

> - depends does not need to have a versioned Firefox requirement
Fixed.

> - why is "${source##*/}" obfuscated when it will always be the same
>   thing?
I'm not sure I get, what you mean by that.
"${source##*/}" retrieves the .xpi file name from the link stored in
${source}. I could of course also write
"${_plugin_name}-${pkgver}-fx-linux.xpi", but does that make it better?

> grub-customizer:
> - there is no need to `install -d ... && install -Dm644 ...`, just do
>   the second part
> - package() also runs the compilation and `sed`s the desktop file, there
>   is a good reason we now do split build/package functions...
Fixed.

> - the use of `|| return 1` is deprecated, makepkg sets errexit
Fixed.

> - inconsistent quoting of array elements; why is provides=() alone in
>   not quoting this? why does license have double-quotes?
Fixed.

> - why is there a backslash escape for a multiline source=() array?
Fixed.

> - there is no need for pkgbranch, use ${pkgver%.*} instead, but if you
>   do use it you should name it _pkgbranch to mark it as a custom var
Fixed.

> - the install file is outdated, we have pacman hooks for that now
Fixed.

> - consider specifying a reason for the optdepends
Will have to ask upstream about that one.

> jackcpp-git:
> - unquoted $pkgdir and $srcdir
Fixed.

> - source urls for git repositories should be cloned over https:// rather
>   than git:// in order to take advantage of cacert verification
Fixed.

> - source urls do not need to be prepended with "$_basename::" when they
>   don't actually need to be renamed
Fixed.

> - the url should use HTTPS
Fixed.

> - this is marked as an "any" package when it contains compiled ELF
>   binaries which is a huge no-no
Fixed.

> - by the way, the nonstandard ordering of makepkg variables had me
>   looking for a second to make sure you actually listed everything
Security through obscurity ;-)
Fixed.

> khard-git:
> - build() does nothing, it should run python setup.py build
Fixed.

> - setuptools installations usually also use --skip-build --optimize=1 in
>   the package() function
Fixed.

> - why do you explicitly use !emptydirs instead of the makepkg.conf
>   default, does the package depend on it?
Legacy problem. Removed.

> liblo-git:
> - source urls for git repositories should be cloned over https:// rather
>   than git:// in order to take advantage of cacert verification; in
>   sourceforge's case that means using the following url:
>   https://git.code.sf.net/p/liblo/git
> - source urls do not need to be prepended with "$_basename::" when they
>   don't actually need to be renamed, but see the above point
Now it does.

> - provides a hardcoded version of liblo, $pkgver should be fine but if
>   not, consider using ${pkgver%%.r*}
Okay.

> - autogen should really go in prepare(), also autogen should die and be
>   replaced by autoreconf in nearly every case. If they really have weird
>   special sauce in there, at least tell autogen to not run ./configure
Switched to autoreconf, seems to work fine with minor fix.
Thanks for that hint!

> mantisbt:
> - this incredibly gross install script messes around with unpackaged
>   files, please don't do this
Okay. What would be a good alternative though?
Using the application during upgrade might potentially break the
database. However, the mantis_offline.php file prevents users from
interacting with the application.
I know that hooks such as the one introduced for nextcloud quite
recently (for a while) won't work either.

> nextcloud-news-updater:
> owncloud-news-updater:
> - what is a "parllel" feed updater anyway?
A typo. Nice one.

> - source tarball violates shared SRCDEST, $pkgver.tar.gz clashes with
>   other packages that have the 

Re: [aur-general] TU Application: David Runge

[David Runge]

Hi Eli,

thanks for the many remarks.

On 2017-10-22 23:44:39 (-0400), Eli Schwartz wrote:
> General commentary on your AUR packages, since xxarhtna is being a
> slacker who slacks:
Due to two work arrangements this week, I won't have time to fix them
before this evening.

I'll get back to it later!

Best,
David


-- 
https://sleepmap.de


signature.asc
Description: PGP signature

[aur-general] TU Application: David Runge

[David Runge]

Hi all,

my name is David Runge. You may have come across me somewhere on the
wiki [1], the forums [2] (not so recently), the AUR [3] or the mailing
lists (mainly arch-general). I'm sponsored by Ray Rashif.

I'm 31, currently live in Berlin and have just finished a Master's
degree in audio communication and technology.
I've been working in (sadly Debian) Linux based computer pools and
electronic music studios (at the Technical University of Berlin) over
the past six years and am currently a freelancing audio engineer and
programmer.

I've been with Arch for roughly ten years now, after a short period of
time spent with Debian and Ubuntu and disliking the clutter and the
amount of preset environments.
I have a huge interest in pro-audio on Linux (I organized the Linux
Audio Conference 2016 and have been using Arch for small scale stereo
projects to massive multi-channel applications) and web applications and
their security (probably a good idea when running one's own
infrastructure).
In my free time I build modular synthesizers and make music with them,
code weird music things using SuperCollider or try to optimize my
packages and systems.

As a TU I'd like to help Ray test and maintain the motherload of
pro-audio packages he's taking care of [4] and take over some (or all)
of the ones that are currently leftover from speps [5].
Additionally, I would like to spend some time to bring further useful
dsp programming languages, such as faust [6], or spatial audio
renderers, such as the ssr [7] to [community].

Best,
David

[1] https://wiki.archlinux.org/index.php/Special:Contributions/Davezerave
[2] https://bbs.archlinux.org/profile.php?id=20912
[3] https://aur.archlinux.org/packages/?K=dvzrv=m
[4] https://www.archlinux.org/packages/?sort===schiv=
[5] https://www.archlinux.org/packages/?sort===speps=
[6] https://aur.archlinux.org/packages/faust/
[7] https://aur.archlinux.org/packages/ssr/

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

Re: [aur-general] mantisbt blacklisted?

[David Runge]

Helloes,

On 2016-09-10 23:27:59 (+0200), Johannes Löthberg wrote:
> Some mishaps meant that the old blacklist was still in effect even though it
> was no longer updated, it should work now!
It does! Thank you!

Best,
David

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

Re: [aur-general] mantisbt blacklisted?

[David Runge]

> Did it used to be in community? Because it isn't in the repos, but it is
Yes.
> in the svntogit archive. (And if it was dropped from the repos, I
> thought the branch was supposed to be dropped.)
I see.
Alucryd moved it to the AUR: https://bugs.archlinux.org/task/50206
I adopted it afterwards (also wrote the bug report).
> 
> -- 
> Eli Schwartz

Cheerios,
David

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

[aur-general] mantisbt blacklisted?

[David Runge]

Helloes everyone,

I was just trying to push a new version of mantisbt (1.3.1), which I
adopted from alucryd.

However, I get this odd message:

remote: error: package is blacklisted: mantisbt
remote: error: hook declined to update refs/heads/master
To aur.archlinux.org:mantisbt
 ! [remote rejected] master -> master (hook declined)
 error: failed to push some refs to 'a...@aur.archlinux.org:mantisbt'

Does anyone know, why this is happening, and why mantisbt would be
blacklisted?

Cheerios,
David

-- 
https://sleepmap.de


signature.asc
Description: PGP signature