Re: [aur-general] [tu-bylaws] [PATCH] Clarify the process for Special Removal of an inactive TU

[Eli Schwartz via aur-general]

On 01/23/2018 12:54 PM, Eli Schwartz wrote:
> On 01/18/2018 06:18 PM, Eli Schwartz wrote:
>> Not everything that is available only to an aurweb account of the
>> Trusted User type, qualifies as a TU "privilege"
>>
>> Signed-off-by: Eli Schwartz 
>> ---
>>
>> Handy link to context and surrounding discussion:
>>
>> https://lists.archlinux.org/pipermail/aur-general/2018-January/033789.html
>>
>> The current wording of the bylaws indicates that there are two ways for
>> a TU to qualify for special removal due to inactivity:
>>
>> 1) Do not participate in voting, thereby potentially blockading a quorum.
>>
>> 2) Do not participate in general TU'ish activities like maintaining
>>[community], administrating the AUR and the packagers and users therein,
>>being representative of TUs in general on this mailing list by being
>>awesome and stuff, i.e. posting (hopefully useful information that helps
>>AUR users), and... um... voting?
>>
>> Point #2 calls out "performed any action that required TU privileges on
>> the AUR", but does the tu voting interface on aurweb count as that or
>> not? Moreover, do we *want* it to count? It seems to be somewhat
>> defeating the purpose of the process, i.e. as long as a TU doesn't
>> actually block quorum during a vote, they can remain while not actually
>> performing any of the inherent functions of a TU.
>>
>> Now, I would argue that under a common sense interpretation the original
>> intent of the bylaws was almost certainly that voting does not count as
>> a "TU privilege", since a TU is someone who has the "privilege" to
>> administrate AUR packages and users in order to keep good order, and
>> select good packages to upload to [community]. 
>>
>> But bylaws exist in order to prevent people from having different
>> interpretations of common sense. So this should be clarified no matter
>> what.
> 
> Thus far, we've (I think) only seen people argue that:
> 
> 1) this is what the bylaws really mean, let us clarify it for the sake
> of less confusion some other day,
> 
> 2) The bylaws do not mean this and should not do this.
> 
> 
> Can I assume that means there is no one who feels this *should* be true,
> but currently *isn't*?
> 
> ...
> 
> Does anyone have any last-minute proposals to modify the wording for
> grammar etc. in the event that this is accepted?

The discussion period is over, time to vote!

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

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] amiwm PKGBUILD file

[Panayotis Katsaloulis via aur-general]

Exactly that's the reason.

I tried to contact upstream and see how it goes.


Στις Τετ, 24 Ιαν, 2018 at 1:44 ΜΜ, ο/η Eli Schwartz via 
aur-general  έγραψε:
> On 01/24/2018 05:32 AM, Panayotis Katsaloulis via aur-general wrote:
>>  Thank you for the comments.
>>  Indeed I didn't try to use "namcap" to catch most of the comments. 
>> Now
>>  I did and sorry about that.
>> 
>> 
>>  Looking deeper at the resutls, I found another issue, which I don't
>>  know which is the most appropriate method to fix it.
>> 
>>  Inside the produced package has references to the build directory, 
>> i.e.
>> 
>>  
>> lib/amiwm/Xsession2:DEFAULT_XINITRC="/home/teras/Sources/amiwm/pkg/amiwm/usr/lib/amiwm/Xinitrc"
>>  lib/amiwm/Xinitrc:/home/teras/Sources/amiwm/pkg/amiwm/usr/bin/amiwm 
>> &
>>  wmpid=$!
>>  lib/amiwm/Xinitrc:
>>  /home/teras/Sources/amiwm/pkg/amiwm/usr/lib/amiwm/amiwm-init#
>>  Default amiwm tools
>>  lib/amiwm/Xsession: export
>>  
>> SDT_ALT_SESSION="/home/teras/Sources/amiwm/pkg/amiwm/usr/lib/amiwm/Xsession2"
>> 
>> 
>>  All of them "remember" the "/home/teras/Sources/amiwm" which if I am
>>  not mistaken is the ${pkgdir} folder.
>>  Should I do something like:
>> 
>>  for i in "${pkgdir}/usr/lib/amiwm/{Xsession2,Xinitrc,Xsession}" ; do
>>  sed -e "s%${pkgdir}%%g" "$i" >"$i.fix"; mv -v "$i.fix" "$i" ; done
> 
> 
> 
> This happens because you use prefix="$pkgdir/usr" during package(), 
> does
> the software not support DESTDIR?
> 
> If not, then you'll need to copy everything over by hand rather than
> using make install. Or, if upstream is still alive, asking them to fix
> their Makefile so it respects DESTDIR.
> 
> You could also fix the Makefile, and ship a patch alongside the
> PKGBUILD, then apply it in prepare() via `patch`.
> 
> --
> Eli Schwartz
> Bug Wrangler and Trusted User
> 

Re: [aur-general] amiwm PKGBUILD file

[Eli Schwartz via aur-general]

On 01/24/2018 05:32 AM, Panayotis Katsaloulis via aur-general wrote:
> Thank you for the comments.
> Indeed I didn't try to use "namcap" to catch most of the comments. Now 
> I did and sorry about that.
> 
> 
> Looking deeper at the resutls, I found another issue, which I don't 
> know which is the most appropriate method to fix it.
> 
> Inside the produced package has references to the build directory, i.e.
> 
> lib/amiwm/Xsession2:DEFAULT_XINITRC="/home/teras/Sources/amiwm/pkg/amiwm/usr/lib/amiwm/Xinitrc"
> lib/amiwm/Xinitrc:/home/teras/Sources/amiwm/pkg/amiwm/usr/bin/amiwm & 
> wmpid=$!
> lib/amiwm/Xinitrc:
> /home/teras/Sources/amiwm/pkg/amiwm/usr/lib/amiwm/amiwm-init  # 
> Default amiwm tools
> lib/amiwm/Xsession:   export 
> SDT_ALT_SESSION="/home/teras/Sources/amiwm/pkg/amiwm/usr/lib/amiwm/Xsession2"
> 
> 
> All of them "remember" the "/home/teras/Sources/amiwm" which if I am 
> not mistaken is the ${pkgdir} folder.
> Should I do something like:
> 
> for i in "${pkgdir}/usr/lib/amiwm/{Xsession2,Xinitrc,Xsession}" ; do 
> sed -e "s%${pkgdir}%%g" "$i" >"$i.fix"; mv -v "$i.fix" "$i" ; done



This happens because you use prefix="$pkgdir/usr" during package(), does
the software not support DESTDIR?

If not, then you'll need to copy everything over by hand rather than
using make install. Or, if upstream is still alive, asking them to fix
their Makefile so it respects DESTDIR.

You could also fix the Makefile, and ship a patch alongside the
PKGBUILD, then apply it in prepare() via `patch`.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [aur-general] amiwm PKGBUILD file

[Panayotis Katsaloulis via aur-general]

Thank you for the comments.
Indeed I didn't try to use "namcap" to catch most of the comments. Now 
I did and sorry about that.


Looking deeper at the resutls, I found another issue, which I don't 
know which is the most appropriate method to fix it.

Inside the produced package has references to the build directory, i.e.

lib/amiwm/Xsession2:DEFAULT_XINITRC="/home/teras/Sources/amiwm/pkg/amiwm/usr/lib/amiwm/Xinitrc"
lib/amiwm/Xinitrc:/home/teras/Sources/amiwm/pkg/amiwm/usr/bin/amiwm & 
wmpid=$!
lib/amiwm/Xinitrc:
/home/teras/Sources/amiwm/pkg/amiwm/usr/lib/amiwm/amiwm-init# 
Default amiwm tools
lib/amiwm/Xsession: export 
SDT_ALT_SESSION="/home/teras/Sources/amiwm/pkg/amiwm/usr/lib/amiwm/Xsession2"


All of them "remember" the "/home/teras/Sources/amiwm" which if I am 
not mistaken is the ${pkgdir} folder.
Should I do something like:

for i in "${pkgdir}/usr/lib/amiwm/{Xsession2,Xinitrc,Xsession}" ; do 
sed -e "s%${pkgdir}%%g" "$i" >"$i.fix"; mv -v "$i.fix" "$i" ; done


The full corected PKGBUILD follows:


# Maintainer: Panayotis Katsaloulis 
pkgname=amiwm
pkgver=0.21pl2
pkgrel=1
pkgdesc="An X window manager that tries to make your display look and 
feel like an Amiga® Workbench® screen"
arch=('x86_64' 'i686')
url="https://www.lysator.liu.se/~marcus/amiwm.html;
license=('CUSTOM')
source=("ftp://ftp.lysator.liu.se/pub/X11/wm/amiwm/amiwm${pkgver}.tar.gz;)
md5sums=('3a47e88e2be2978363220cf815ef')
depends=('libxmu')

build() {
cd "$pkgname$pkgver"
./configure --prefix=/usr
make
}

package() {
cd "$pkgname$pkgver"
make prefix="$pkgdir/usr" install
rm -v "$pkgdir/usr/bin/requestchoice"
mv -v "${pkgdir}/usr/man" "${pkgdir}/usr/share"
for i in "${pkgdir}"/usr/lib/amiwm/{Xsession2,Xinitrc,Xsession} ; 
do sed -e "s%${pkgdir}%%g" "$i" >"$i.fix" ; mv -v "$i.fix" "$i" ; done
install -v -Dm644 LICENSE 
"$pkgdir"/usr/share/licenses/$pkgname/LICENSE
}