Hi All,
My name is Giancarlo Razzolini (grazzolini) and I would like to become a TU. Before anything, I want to thank Jelle van der Waa for agreeing to become my sponsor.
I'm 33 years old. I am a developer and infrastructure manager at my own company. I have been using Linux since 1999. Despite my name, I am not Italian, but I'm Brazilian (of Italian descent). My first experience with Linux was with Conectiva Linux, but soon I moved to Slackware, where I stayed for many years. For work reasons, I ended up using Ubuntu for some years. In 2013 I moved to Arch, and it was love at first sight. Or better, at first use.
Right from the beginning I started to contribute, first helping out with the wiki. Later, when I found out about the simplicity of creating and maintaining packages, I started to put some on the AUR. Also, I adapted some tools I had developed for Ubuntu initramfs system, to Arch. Also, I created new ones. Most of them are related with remote unlocking of an encrypted root partition, so lots of early userspace networking. I am also very active on IRC.
Recently I also subscribed as a tester, and I do give signoff's to the packages I am able to test. If I become a TU, I would like to bring some of the packages I maintain on the AUR[0] to community, specially:
keepass-plugin-keeagent tinyssh (co-maintained) ucspi-tcp
I would also like to bring some of my own project's packages, specially:
mkinitcpio-netconf[1] mkinitcpio-dropbear[2] mkinitcpio-tinyssh[3] mkinitcpio-utils[4]
I am willing to adopt packages also. From the list of orphaned packages, I am willing to adopt right away terminator and all it's dependencies.
Thanks in advance, Giancarlo Razzolini
[0]https://aur.archlinux.org/packages/?SeB=m&K=grazzolini [1]https://github.com/grazzolini/mkinitcpio-netconf [2]https://github.com/grazzolini/mkinitcpio-dropbear [3]https://github.com/grazzolini/mkinitcpio-tinyssh [4]https://github.com/grazzolini/mkinitcpio-utils
On 10/20/16 at 11:23am, Giancarlo Razzolini via aur-general wrote:
Hi All,
My name is Giancarlo Razzolini (grazzolini) and I would like to become a TU. Before anything, I want to thank Jelle van der Waa for agreeing to become my sponsor.
I confirm sponsoring grazzolini! Let the discussion period begin!
P.S. It helps if you set the textwidth to 76 characters for readability :)
Hi Giancarlo,
thanks for your application and jelle for sponsoring.
As always I want to give my 2 cents to your PKGBUILDs so you could improve certain points before the voting period starts. Please don't be scared! :)
cheers, Levente
PS: some of the blocks are copy-paste, its just lot easier this way :]
chkboot: ======== - the non VCS packages should not have provides,conflicts,replaces to any packages that provide the "main" one (like chkboot-git), it should always be the other way around.
- the .install file used in the install= variable does not need to be in the sources array.
- all download targets in the source array must be unique as they could overlap if using the same download directory. f.e. are cases like github where the tarball only has version number. those should be renamed by adding pkgname, f.e.: ${pkgname}-${pkgver}.tar.gz::https...
esekeyd: ======== - the .install file used in the install= variable does not need to be in the sources array.
- any use of $pkgdir and $srcdir must be put into double-quotes as they may contain spaces. (package() function)
- simple documentation like mentioning to edit config file and use systemctl should not be put into .install files, thats not their purpose
keepass-plugin-keeagent: ======================== - the .install file used in the install= variable does not need to be in the sources array.
- the "main" packages should not have provides,conflicts,replaces to any packages that provide the "main" one (like keepass-plugin- keeagent-beta), it should always be the other way around.
- any use of $pkgdir must be put into double-quotes as they may contain spaces. (package() function)
keepass-plugin-keeagent-beta: ============================= - the .install file used in the install= variable does not need to be in the sources array.
- any use of $pkgdir must be put into double-quotes as they may contain spaces. (package() function)
memlockd: ========= - the .install file used in the install= variable does not need to be in the sources array.
- any use of $pkgdir and $srcdir must be put into double-quotes as they may contain spaces. (package() function)
- never delete user accounts with userdel in the .install files as they may possibly still own files. there is no point doing so (for further information you can search the arch-dev-public ML)
mkinitcpio-chkcryptoboot: ========================= - the .install file used in the install= variable does not need to be in the sources array.
- _huge_ chunk of documentation in the .install file. that really shouldn't be the place and purpose of such. A wiki entry and/or a text file in the /usr/share/doc/${pkgname} is a better place.
mkinitcpio-ddns: ================ - most likely one of the longest description I have ever encountered. Matter of taste but i find that slightly too long :P
- the .install file used in the install= variable does not need to be in the sources array.
- _huge_ chunk of documentation in the .install file. that really shouldn't be the place and purpose of such. A wiki entry and/or a text file in the /usr/share/doc/${pkgname} is a better place.
mkinitcpio-dropbear: ==================== - documentation should normally not be in the .install file but a wiki entry and/or a text file in the /usr/share/doc/${pkgname} is a better place.
mkinitcpio-netconf: =================== - any use of $pkgdir and $srcdir must be put into double-quotes as they may contain spaces. (package() function)
- _huge_ chunk of documentation in the .install file. that really shouldn't be the place and purpose of such. A wiki entry and/or a text file in the /usr/share/doc/${pkgname} is a better place.
mkinitcpio-ppp: =============== - the .install file used in the install= variable does not need to be in the sources array.
- _huge_ chunk of documentation in the .install file. that really shouldn't be the place and purpose of such. A wiki entry and/or a text file in the /usr/share/doc/${pkgname} is a better place.
mkinitcpio-tinyssh: =================== - _huge_ chunk of documentation in the .install file. that really shouldn't be the place and purpose of such. A wiki entry and/or a text file in the /usr/share/doc/${pkgname} is a better place.
mkinitcpio-utils: ================= - documentation should normally not be in the .install file but a wiki entry and/or a text file in the /usr/share/doc/${pkgname} is a better place.
tinyssh-convert: ================ - any use of $pkgdir must be put into double-quotes as they may contain spaces. (package() function)
- the non VCS packages should not have provides,conflicts,replaces to any packages that provide the "main" one (like ${pkgname}-git), it should always be the other way around.
tinyssh-convert-git: ==================== - any use of $pkgdir must be put into double-quotes as they may contain spaces. (package() function)
ucspi-tcp: ========== - any use of $srcdir must be put into double-quotes as they may contain spaces. (package() function)
- no need for any || return 1
- patching should be done in prepare()
- make should be done in build()
- 'gcc' 'make' 'patch' all belong to base-devel and is not needed as makedepends
wine-ivb: ========= - any use of $pkgdir must be put into double-quotes as they may contain spaces. (prepare() function)
wine-staging-ivb: ================= - all download targets in the source array must be unique as they could overlap if using the same download directory. f.e. the staging-$_pkgbasever.tar.gz may not be unique. those should be renamed by adding pkgname, f.e.: ${pkgname}-${pkgver}.tar.gz::https...
- any use of $pkgdir must be put into double-quotes as they may contain spaces. (prepare() function)
Em outubro 20, 2016 15:39 Levente Polyak escreveu:
Hi Giancarlo,
thanks for your application and jelle for sponsoring.
As always I want to give my 2 cents to your PKGBUILDs so you could improve certain points before the voting period starts. Please don't be scared! :)
cheers, Levente
PS: some of the blocks are copy-paste, its just lot easier this way :]
Hi Levante,
I always appreciate input. Jelle did already provide some, and I have hunt down all the namcap issues I found. Since there is a lot of copy and paste, I'll reply in the same manner, condensing where possible.
*: - I am aware that the .install file does not need to be on the sources. But If I am not mistaken, if it is not on the sources array, it also does not have it's checksum validated. Since most of those .install files run code, I have always put them on the sources array. I am open to suggestions though.
- I will correct any usage of $pkgdir and $srcdir without quotes on them.
- I fixed the download target of some packages, specially because of the github versioning. But it makes sense to fix all of them to do the same.
- Main vs. VCS provides/conflicts: Will fix them to not have those.
chkboot: - the chkboot-git conflict was because the package was named chkboot-git before. I can safely remove that.
memlockd: - I was in doubt regarding the user deletion. In this specific instance that dir is the user home dir. I don't think it does create any files there though. Do you have any recommendation on how to tackle this one? I don't want to leave just an empty dir as leftover of the package uninstall.
ucspi-tcp: - I took over that package on the migration of the AUR3 to the AUR4 and, since there weren't new releases of that software since then, I didn't pay much attention to it. Will apply the suggestions.
I plan to do these corrections as soon as possible (possibly still today, tomorrow at max).
Thanks for the input, Giancarlo Razzolini
On Thu, Oct 20, 2016 at 8:51 PM, Giancarlo Razzolini via aur-general aur-general@archlinux.org wrote:
Em outubro 20, 2016 15:39 Levente Polyak escreveu:
Hi Giancarlo,
thanks for your application and jelle for sponsoring.
As always I want to give my 2 cents to your PKGBUILDs so you could improve certain points before the voting period starts. Please don't be scared! :)
cheers, Levente
PS: some of the blocks are copy-paste, its just lot easier this way :]
Hi Levante,
I always appreciate input. Jelle did already provide some, and I have hunt down all the namcap issues I found. Since there is a lot of copy and paste, I'll reply in the same manner, condensing where possible.
*: - I am aware that the .install file does not need to be on the sources. But If I am not mistaken, if it is not on the sources array, it also does not have it's checksum validated. Since most of those .install files run code, I have always put them on the sources array. I am open to suggestions though.
Damn!
Now go + make sure to leave your concern on the pacman bugtracker.
cheers! mar77i
Hi Giancarlo,
On 10/20/2016 08:51 PM, Giancarlo Razzolini via aur-general wrote:
- I am aware that the .install file does not need to be on thesources. But If I am not mistaken, if it is not on the sources array, it also does not have it's checksum validated. Since most of those .install files run code, I have always put them on the sources array. I am open to suggestions though.
Well I don't see reason to have a checksum for that one, its contained within the source (PKGBUILD) and not downloaded from a remote. It either comes through git or via a pkg-src tarball. The PKGBUILD itself (that contains that checksum) comes through the very same way and also runs code itself.
- I was in doubt regarding the user deletion. In this specificinstance that dir is the user home dir. I don't think it does create any files there though. Do you have any recommendation on how to tackle this one? I don't want to leave just an empty dir as leftover of the package uninstall.
I would say: just leave it around. In fact we had a big TODO list [0] cleaning up all the userdel from all packages in the whole repos (not the AUR). It doesn't hurt much and in fact if it ever creates some files (now or in the future) you definitively don't want to wipe them and definitively don't want to delete the user-name associated with the UID of those files.
ucspi-tcp: - I took over that package on the migration of the AUR3 to the AUR4 and, since there weren't new releases of that software since then, I didn't pay much attention to it. Will apply the suggestions.
cool. that's especially important to get some attention onto it when you consider moving such to the repo ;)
I plan to do these corrections as soon as possible (possibly stilltoday, tomorrow at max).
That's great to hear *thumbs*
Thanks for the input
you're welcome! I always try to be as helpful as possible. cheers, Levente
Em outubro 20, 2016 17:36 Levente Polyak escreveu:
Hi Giancarlo,
Well I don't see reason to have a checksum for that one, its contained within the source (PKGBUILD) and not downloaded from a remote. It either comes through git or via a pkg-src tarball. The PKGBUILD itself (that contains that checksum) comes through the very same way and also runs code itself.
Indeed. I removed all .install files from the source array of my packages.
I would say: just leave it around. In fact we had a big TODO list [0] cleaning up all the userdel from all packages in the whole repos (not the AUR). It doesn't hurt much and in fact if it ever creates some files (now or in the future) you definitively don't want to wipe them and definitively don't want to delete the user-name associated with the UID of those files.
I kept the userdel for now. But I will follow how this develops.
cool. that's especially important to get some attention onto it when you consider moving such to the repo ;)
I just updated the uscpi-tcp package and all the others with the suggested improvements. As for my own packages, I removed their .install files for now. I agree it is not the proper place for documentation. Some of them already have wiki entries documenting their install process. Some do not. I will probably move that text to a proper file in /usr/share/doc and will also improve their documentation on the github.
Cheers, Giancarlo Razzolini
On October 21, 2016 1:38:06 PM GMT+02:00, Giancarlo Razzolini via aur-general aur-general@archlinux.org wrote:
I would say: just leave it around. In fact we had a big TODO list [0] cleaning up all the userdel from all packages in the whole repos (not the AUR). It doesn't hurt much and in fact if it ever creates some files (now
or
in the future) you definitively don't want to wipe them and
definitively
don't want to delete the user-name associated with the UID of those files.
I kept the userdel for now. But I will follow how this develops.
Well I don't see why it shouldn't be but as long as it's the AUR most likely that won't be enforce anyway as there isn't even proper UID GID registry.
But any package in the repo must not delete user and group accounts, that's what that TODO list was all about. I don't see why this will change anytime soon so please keep that rule in mind :)
I just updated the uscpi-tcp package and all the others with the suggested improvements. As for my own packages, I removed their .install files for now. I agree it is not the proper place for documentation. Some of them
already have wiki entries documenting their install process. Some do not. I will probably move that text to a proper file in /usr/share/doc and will also improve their documentation on the github.
Cool that was quite fast :) Cheers Levente
Em outubro 21, 2016 10:10 Levente Polyak escreveu:
Well I don't see why it shouldn't be but as long as it's the AUR most likely that won't be enforce anyway as there isn't even proper UID GID registry.
But any package in the repo must not delete user and group accounts, that's what that TODO list was all about. I don't see why this will change anytime soon so please keep that rule in mind :)
I don't plan on bringing memlockd to community, if I become a TU. I made it's package because I'm working on porting TAILS memory erasure process to archlinux. And they use memlockd. If I ever manage to port it, then we will see.
Cheers, Giancarlo Razzolini
On 21.10.2016 14:19, Giancarlo Razzolini via aur-general wrote:
Em outubro 21, 2016 10:10 Levente Polyak escreveu:
Well I don't see why it shouldn't be but as long as it's the AUR most likely that won't be enforce anyway as there isn't even proper UID GID registry.
I don't plan on bringing memlockd to community, if I become a TU.
I feel like the goal should be that every AUR package is in a state that allows it to be simply moved to community without requiring any changes.
Sadly, most of the time I want to move stuff I have to invest a couple of hours/days into making sure it builds properly and follows our (implicit?) standards. Like keeping users after removal, not including tons of patches, using split packages only when necessary or depending on all dependencies. It appears many people still build with plain makepkg and without build chroots.
Also please keep in mind that AUR packages are influenced by each other. If you have one package doing things a certain way and you only clean them up when necessary, you'll have to clean them up every time. If people get used to the way we want packages, moving could be much simpler and every package you improve is a step in the right direction.
Florian
Em outubro 22, 2016 13:17 Florian Pritz via aur-general escreveu:
I feel like the goal should be that every AUR package is in a state that allows it to be simply moved to community without requiring any changes.
Sadly, most of the time I want to move stuff I have to invest a couple of hours/days into making sure it builds properly and follows our (implicit?) standards. Like keeping users after removal, not including tons of patches, using split packages only when necessary or depending on all dependencies. It appears many people still build with plain makepkg and without build chroots.
I agree with all this. I have been using the devtools for a while now. Not only I use a clean chroot build, but I have developed a testing procedure where I test the packages on both VM's and on bare metal machines, before pushing them to the AUR. Not only that, but I invest some effort into making sure I got the right upstream sources. I have a multi ISP/VPN/TOR download tool that I plan on polishing and releasing that automates in part the retrieval of the sources (also making sure you have the right one).
Also please keep in mind that AUR packages are influenced by each other. If you have one package doing things a certain way and you only clean them up when necessary, you'll have to clean them up every time. If people get used to the way we want packages, moving could be much simpler and every package you improve is a step in the right direction.
This experience, even if I don't get in, has been much fruitful. I will continue helping either way, whenever I can.
Cheers, Giancarlo Razzolini
On 10/24/2016 01:32 AM, Giancarlo Razzolini via aur-general wrote:
Em outubro 22, 2016 13:17 Florian Pritz via aur-general escreveu:
I feel like the goal should be that every AUR package is in a state that allows it to be simply moved to community without requiring any changes. [...]
I agree with all this. [...]
Well I actually don't planned to jump in again on this topic... but if you fully agree on all that, then it pretty much boils down to the fact that you definitively want to get rid of userdel. I'm quite convinced that's explicitly a part of what Florian tried to explain as that is something that would require adjustment before moving ;-)
cheers, Levente
Em outubro 23, 2016 22:17 Levente Polyak escreveu:
On 10/24/2016 01:32 AM, Giancarlo Razzolini via aur-general wrote:
Well I actually don't planned to jump in again on this topic... but if you fully agree on all that, then it pretty much boils down to the fact that you definitively want to get rid of userdel. I'm quite convinced that's explicitly a part of what Florian tried to explain as that is something that would require adjustment before moving ;-)
Yes, I understood this. I already changed the package in question and I am testing it as I type this. But, as I said, I don't plan on moving it to community for now, if I become a TU.
I know that TU's and dev's are not only expected, but required, to push the envelope on PKGBUILD quality. And I plan on be a part of it, regardless of anything else.
Cheers, Giancarlo Razzolini
On 10/20/16 at 11:23am, Giancarlo Razzolini via aur-general wrote:
Hi All,
My name is Giancarlo Razzolini (grazzolini) and I would like to become a TU. Before anything, I want to thank Jelle van der Waa for agreeing to become my sponsor.
The discussion period has ended, please cast your votes!
On Thu, Oct 27, 2016 at 09:28:42PM +0200, Jelle van der Waa wrote:
The discussion period has ended, please cast your votes!
I assume voting period is still seven days and has ended, what was result?
Thanks
On 27/10, Jelle van der Waa wrote:
On 10/20/16 at 11:23am, Giancarlo Razzolini via aur-general wrote:
Hi All,
My name is Giancarlo Razzolini (grazzolini) and I would like to become a TU. Before anything, I want to thank Jelle van der Waa for agreeing to become my sponsor.
The discussion period has ended, please cast your votes!
Heh, seems Jelle inconveniently went on vacation just before it ended, so on behalf of Jelle:
Congrats grazzolini, you've been accepted!
Yes: 20 No: 6 Abstain: 6
Please continue by following the TODO for new Trusted Users[0].
[0] https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines
Heh, seems Jelle inconveniently went on vacation just before it ended, so on behalf of Jelle:
Congrats grazzolini, you've been accepted!
Yes: 20 No: 6 Abstain: 6
Oh of course - how did I forget he went on vacation.
Congratulations, grazzolini, and best wishes ☺
Em novembro 10, 2016 7:07 Johannes Löthberg via aur-general escreveu:
Heh, seems Jelle inconveniently went on vacation just before it ended, so on behalf of Jelle:
Congrats grazzolini, you've been accepted!
Yes: 20 No: 6 Abstain: 6
Please continue by following the TODO for new Trusted Users[0].
[0] https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines
Hi all,
I was aware Jelle went on vacation, which is why I was ok waiting for him to come back. As someone mentioned on IRC, TU's are humans too. Anyway, I want to thank you all for this opportunity. I will start on the TODO right now.
Cheers, Giancarlo Razzolini
On 2016-11-10 14:00 +0000 Giancarlo Razzolini via aur-general wrote:
As someone mentioned on IRC, TU's are humans too.
Filthy lies! Don't believe everything you read online.
Welcome aboard!
I was aware Jelle went on vacation, which is why I was ok waiting for him to come back. As someone mentioned on IRC, TU's are humans too. Anyway, I want to thank you all for this opportunity. I will start on the TODO right now.
Sorry about that :) Needed some vacation and time off from the internets :)
I've upgraded your AUR account to a TU one. And now working on adding your gpg pubkey to the packages keyring.
On Thu, 2016-11-10 at 10:07 +0100, Johannes Löthberg via aur-general wrote:
On 27/10, Jelle van der Waa wrote:
On 10/20/16 at 11:23am, Giancarlo Razzolini via aur-general wrote:
Hi All,
My name is Giancarlo Razzolini (grazzolini) and I would like to become a TU. Before anything, I want to thank Jelle van der Waa for agreeing to become my sponsor.
The discussion period has ended, please cast your votes!
Heh, seems Jelle inconveniently went on vacation just before it ended, so on behalf of Jelle:
Congrats grazzolini, you've been accepted!
Yes: 20 No: 6 Abstain: 6
Please continue by following the TODO for new Trusted Users[0].
[0] https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines
Congrats and welcome abroad.
Cheers,
Heh, seems Jelle inconveniently went on vacation just before it ended, so on behalf of Jelle:
Congrats grazzolini, you've been accepted!
Yes: 20 No: 6 Abstain: 6
Thanks Johannes for sending this e-mail!
I admit I was secretly hiding in the desert!
Please continue by following the TODO for new Trusted Users[0].
[0] https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines
-- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
aur-general@lists.archlinux.org