Hi Arch people.
My name is Dan Printzell, but I often go by Wild/Vild or when I use an old account, WildN00b. I'm writing this TU application because I want to maintain the dlang packages that are currently orphaned or being dropped from [community]. I'm being sponsored by Johannes Löthberg.
A little about me. I'm 21 years old programmer from Sweden. I'm currently studying game programming at BTH. On my freetime I'm usually code on my operating system that I'm writing in D from scratch [1]. I usually stream this development on my twitch channel [2].
The first time I touched Linux I believe was back in '08, when I was about 12. I order those free CD with Ubuntu and played around with it a lot. After that I have been switching between Windows and Linux distroes as my main driver depending on if I wanted to be productive and code, or if wanted to play games. I started to use Arch maybe 5-6 years ago, where the latest 4 years I have been using it as my main driver for all my computers. I think I choose Arch because pacman made sense to me compared to apt-{get,cache,whatever}.
I created my first package about 3 years ago for my custom bar, but it is long gone after the AUR3 update. Around the same time I started to use dlang as my main language and I started to maintain a few -git packages for the different helper tools, and when the none -git packages got orphaned or dropped from [community] I took over them.
If I were to become a TU I would want to maintain all the dlang packages that are orphaned in [community] [3]. I would also like to move these packages to [community]: - dcd [4] - dfmt [5] - dscanner [6] - dub [7] - workspace-d [8]
TL;DR I use the D programming language, so I want to maintain it.
Thanks Dan Printzell GPG KEY: 0x22E3B67B4A86FDE7 https://github.com/Vild/ https://vild.io/
[1] https://github.com/PowerNex/PowerNex [2] http://twitch.tv/wildn00b/ [3] https://www.archlinux.org/groups/x86_64/dlang/ [4] https://aur.archlinux.org/packages/dcd/ [5] https://aur.archlinux.org/packages/dfmt/ [6] https://aur.archlinux.org/packages/dscanner/ [7] https://aur.archlinux.org/packages/dub/ [8] https://aur.archlinux.org/packages/workspace-d/
Quoting Dan Printzell (2017-07-27 22:52:10)
Hi Arch people.
My name is Dan Printzell, but I often go by Wild/Vild or when I use an old account, WildN00b. I'm writing this TU application because I want to maintain the dlang packages that are currently orphaned or being dropped from [community]. I'm being sponsored by Johannes Löthberg.
A little about me. I'm 21 years old programmer from Sweden. I'm currently studying game programming at BTH. On my freetime I'm usually code on my operating system that I'm writing in D from scratch [1]. I usually stream this development on my twitch channel [2].
The first time I touched Linux I believe was back in '08, when I was about 12. I order those free CD with Ubuntu and played around with it a lot. After that I have been switching between Windows and Linux distroes as my main driver depending on if I wanted to be productive and code, or if wanted to play games. I started to use Arch maybe 5-6 years ago, where the latest 4 years I have been using it as my main driver for all my computers. I think I choose Arch because pacman made sense to me compared to apt-{get,cache,whatever}.
I created my first package about 3 years ago for my custom bar, but it is long gone after the AUR3 update. Around the same time I started to use dlang as my main language and I started to maintain a few -git packages for the different helper tools, and when the none -git packages got orphaned or dropped from [community] I took over them.
If I were to become a TU I would want to maintain all the dlang packages that are orphaned in [community] [3]. I would also like to move these packages to [community]:
- dcd [4]
- dfmt [5]
- dscanner [6]
- dub [7]
- workspace-d [8]
TL;DR I use the D programming language, so I want to maintain it.
Thanks Dan Printzell GPG KEY: 0x22E3B67B4A86FDE7 https://github.com/Vild/ https://vild.io/
[1] https://github.com/PowerNex/PowerNex [2] http://twitch.tv/wildn00b/ [3] https://www.archlinux.org/groups/x86_64/dlang/ [4] https://aur.archlinux.org/packages/dcd/ [5] https://aur.archlinux.org/packages/dfmt/ [6] https://aur.archlinux.org/packages/dscanner/ [7] https://aur.archlinux.org/packages/dub/ [8] https://aur.archlinux.org/packages/workspace-d/
I confirm my sponsorship, let the discussion period begin!
Quoting Johannes Löthberg (2017-07-27 22:58:58)
I confirm my sponsorship, let the discussion period begin!
The discussion period is over, and the voting period starts now!
TUs can cast their votes here: https://aur.archlinux.org/tu/?id=94
Quoting Johannes Löthberg (2017-08-01 14:29:38)
Quoting Johannes Löthberg (2017-07-27 22:58:58)
I confirm my sponsorship, let the discussion period begin!
The discussion period is over, and the voting period starts now!
TUs can cast their votes here: https://aur.archlinux.org/tu/?id=94
The vote has been closed, and you have been accepted as a TU Wild!
Results:
* Yes: 42 * No: 2 * Abstain: 10 * Total: 39
Congrats Wild!
Hello Dan, Glad that you like to participate. Here are some questions + feedback to your PKGBUILDs...
If I were to become a TU I would want to maintain all the dlang packages that are orphaned in [community] [3]. I would also like to move these packages to [community]:
- dcd [4]
- dfmt [5]
- dscanner [6]
- dub [7]
- workspace-d [8]
Don't get that wrong, but I am wondering how much people this D-packages really need. Do we have so much D programmers outside? I never used that language and according to some programming language popularity board it's not that popular. (It's not under the big 20)[1] Additionally some of the package that you want to move don't have so much votes nor popularity.
So I would like to know: Are you also interested in maintaing other packages besides D specific packages? We have really a lot of orphans in community.
Here is some feedback to your packages:
--------------- executing /usr/bin/xxarhtna -------------------- - dcd ======
1. you want `#commit=` instead of `#tag=` in the source. Git tags are variable so you need to pin it at a commit to make sure nobody changes it after setting the git tag in your PKGBUILD. 2. You want to also pin the commit for the other source repositories. So for each repository pick a stable commit
- dfmt ======
1. Same for dfmt. You want to pin the commit not the tag. 2. Same for the other sources you want to pin to a stable commit. 3. You have a space at the end of your description (sorry for the nut-picking)
- dnscanner ===========
1. Same for dnscanner. You want to pin the commit not the tag. 2. Same for the other sources.
- dub =====
1. You want to surround $pkgname-$pkgver and $pkgver in your source with double quotes:
source=("$pkgname-$pkgver.tar.gz::https://github.com/dlang/dub/archive/v$pkgver.tar.gz")
2. You compile that binary with dmd.. so just out of curiosity: Does dmd has any security features for their created binaries? Stuff like PIE? Would be cool if you could enable that as well.
- workspace-d =============
1. You want to pin the commit instead of the tag.
-------------- end of xxarhtna output --------------------------------
Thats all. Thanks for your mail and sorry for the nut-picking.
best regards,
chris
On 2017-07-28 01:14, Christian Rebischke wrote:
Don't get that wrong, but I am wondering how much people this D-packages really need. Do we have so much D programmers outside?
Don't get me wrong, but I am wondering how much people use systemtap or playerctl? According to pkgstats it's not 2% and 5% and both aren't even listed in Stackoverflow!
Additionally some of the package that you want to move don't have so much votes nor popularity.
It never was a hard rule.
So I would like to know: Are you also interested in maintaing other packages besides D specific packages? We have really a lot of orphans in community.
Will leave that to Dan to respond in detail but first, D toolchain is orphan anyway and second, it's fine to take care only of one area in repository.
- You want to surround $pkgname-$pkgver and $pkgver in your source with
double quotes:
And I guess it has to be done because suddenly manually set variables will explode with whitespace?
B
On 07/28/17 at 11:49am, Bartłomiej Piotrowski wrote:
On 2017-07-28 01:14, Christian Rebischke wrote:
Don't get that wrong, but I am wondering how much people this D-packages really need. Do we have so much D programmers outside?
Don't get me wrong, but I am wondering how much people use systemtap or playerctl? According to pkgstats it's not 2% and 5% and both aren't even listed in Stackoverflow!
Additionally some of the package that you want to move don't have so much votes nor popularity.
It never was a hard rule.
So I would like to know: Are you also interested in maintaing other packages besides D specific packages? We have really a lot of orphans in community.
Will leave that to Dan to respond in detail but first, D toolchain is orphan anyway and second, it's fine to take care only of one area in repository.
Second that, I want D experts to maintain D packages instead of people who don't know what they are doing :-)
On 07/28/2017 05:49 AM, Bartłomiej Piotrowski wrote:
On 2017-07-28 01:14, Christian Rebischke wrote:
Don't get that wrong, but I am wondering how much people this D-packages really need. Do we have so much D programmers outside?
Don't get me wrong, but I am wondering how much people use systemtap or playerctl? According to pkgstats it's not 2% and 5% and both aren't even listed in Stackoverflow!
Additionally some of the package that you want to move don't have so much votes nor popularity.
It never was a hard rule.
Yeah, even the rule itself always gave me the impression of being a floor on what is okay for inclusion, since the repos shouldn't be filled with packages no one actually uses other than the maintainer and like 2 other people in the world.
So I would like to know: Are you also interested in maintaing other packages besides D specific packages? We have really a lot of orphans in community.
Will leave that to Dan to respond in detail but first, D toolchain is orphan anyway and second, it's fine to take care only of one area in repository.
- You want to surround $pkgname-$pkgver and $pkgver in your source with
double quotes:
And I guess it has to be done because suddenly manually set variables will explode with whitespace?
I certainly hope that isn't a criteria for becoming a TU, given that I see a pattern whereby repository PKGBUILDs start losing their quotes around every variable that cannot have whitespace, as a specific style approach of a number of Devs/TUs.
e.g. the *depends* license and arch arrays.
At least one TU even manually generates their checksums and inserts them by hand without the single quotes `makepkg -g` creates.
...
And now the inconsistency is bothering me, because I don't think anyone ever quotes the pkgver/pkgrel/epoch, and usually not the pkgname either, so by rights we *shouldn't* quote the arch, make/depends, conflicts, replaces, provides, *sums, validpgpgkeys, and some optdepends and licenses either.
*looks at his AUR packages and shudders*
(Sorry about the double reply Christian, I replyed to the wrong address)
Excerpts from Christian Rebischke's message of July 28, 2017 1:14 am:
Hello Dan, Glad that you like to participate. Here are some questions + feedback to your PKGBUILDs...
If I were to become a TU I would want to maintain all the dlang packages that are orphaned in [community] [3]. I would also like to move these packages to [community]:
- dcd [4]
- dfmt [5]
- dscanner [6]
- dub [7]
- workspace-d [8]
Don't get that wrong, but I am wondering how much people this D-packages really need. Do we have so much D programmers outside? I never used that language and according to some programming language popularity board it's not that popular. (It's not under the big 20)[1] Additionally some of the package that you want to move don't have so much votes nor popularity.
dub is the default package manager for D and was dropped from [community] a couple of days ago. So I really want to move it back to [community] again. DCD was also dropped from [community] some time ago. DCD, dfmt and dscanner are programs that most editors use to implement D support. So I would say that these would really help the D community if they were in [community].
workspace-d would be nice if it were in [community] but I'll not move it unless it gains more popularity.
So I would like to know: Are you also interested in maintaing other packages besides D specific packages? We have really a lot of orphans in community.
I could maintain other packages as well, but I would prioritize my D packages.
Here is some feedback to your packages:
--------------- executing /usr/bin/xxarhtna --------------------
- dcd
======
- you want `#commit=` instead of `#tag=` in the source. Git tags are
variable so you need to pin it at a commit to make sure nobody changes it after setting the git tag in your PKGBUILD.
Thanks, I will change that.
- You want to also pin the commit for the other source repositories. So
for each repository pick a stable commit
Do I really need to do this? Won't the 'git submodule update' command choose the correct commit?
- dfmt
====== 3. You have a space at the end of your description (sorry for the nut-picking)
np, I'll fix that
- dub
=====
- You want to surround $pkgname-$pkgver and $pkgver in your source with
double quotes:
source=("$pkgname-$pkgver.tar.gz::https://github.com/dlang/dub/archive/v$pkgver.tar.gz")
Will do
- You compile that binary with dmd.. so just out of curiosity: Does dmd
has any security features for their created binaries? Stuff like PIE? Would be cool if you could enable that as well.
There is a -fPIC flag for dmd, I can enable this. I can also apply a patch to the other packages so they also use compile with -fPIC.
Thats all. Thanks for your mail and sorry for the nut-picking.
Np, I appreciate all the help I can get.
- Dan
Excerpts from Dan Printzell's message of July 28, 2017 4:32 pm:
There is a -fPIC flag for dmd, I can enable this. I can also apply a patch to the other packages so they also use compile with -fPIC.
I just saw that this flag was enabled by default for all compilations with dmd, so no patch needed.
- Dan
On Fri, Jul 28, 2017 at 02:32:07PM +0000, Dan Printzell wrote:
I could maintain other packages as well, but I would prioritize my D packages.
Thats what I wanted to hear :)
Do I really need to do this? Won't the 'git submodule update' command choose the correct commit?
May somebody else correct me, but I don't think so. `git submodule update` will just update to the HEAD of the sub repository. And we want stable builds. Therefore it's important to pin the software at a specific commit and it's dependencies, too.
There is a -fPIC flag for dmd, I can enable this. I can also apply a patch to the other packages so they also use compile with -fPIC.
Awesome!
Best regards,
Chris
On Mon, Jul 31, 2017 at 08:09:56PM +0200, Christian Rebischke wrote:
On Fri, Jul 28, 2017 at 02:32:07PM +0000, Dan Printzell wrote:
Do I really need to do this? Won't the 'git submodule update' command choose the correct commit?
May somebody else correct me, but I don't think so. `git submodule update` will just update to the HEAD of the sub repository. And we want stable builds. Therefore it's important to pin the software at a specific commit and it's dependencies, too.
No, it checks out the commit pinned in the superproject.
Florian
On 07/31/2017 02:09 PM, Christian Rebischke wrote:
Do I really need to do this? Won't the 'git submodule update' command choose the correct commit?
May somebody else correct me, but I don't think so. `git submodule update` will just update to the HEAD of the sub repository. And we want stable builds. Therefore it's important to pin the software at a specific commit and it's dependencies, too.
You're both right and wrong. "$srcdir/$submodulename" will be at origin/master, but `git submodule update` in the primary repo will completely ignore that clone altogether and just cares about the git objects which it uses in yet another clone.
On Mon, 31 Jul 2017 14:16:33 -0400 Eli Schwartz eschwartz@archlinux.org wrote:
On 07/31/2017 02:09 PM, Christian Rebischke wrote:
Do I really need to do this? Won't the 'git submodule update' command choose the correct commit?
May somebody else correct me, but I don't think so. `git submodule update` will just update to the HEAD of the sub repository. And we want stable builds. Therefore it's important to pin the software at a specific commit and it's dependencies, too.
You're both right and wrong. "$srcdir/$submodulename" will be at origin/master, but `git submodule update` in the primary repo will completely ignore that clone altogether and just cares about the git objects which it uses in yet another clone.
This is a bit confusing. You set the URL of the submodule to the location of the local clone, so it doesn't ignore it, it just clones from the local clone. And yes, it does use the specific commit specified in the main repo, so setting #commit= for the submodule is useless.
On 07/31/2017 03:35 PM, Doug Newgard wrote:
On Mon, 31 Jul 2017 14:16:33 -0400 Eli Schwartz eschwartz@archlinux.org wrote:
You're both right and wrong. "$srcdir/$submodulename" will be at origin/master, but `git submodule update` in the primary repo will completely ignore that clone altogether and just cares about the git objects which it uses in yet another clone.
This is a bit confusing. You set the URL of the submodule to the location of the local clone, so it doesn't ignore it, it just clones from the local clone. And yes, it does use the specific commit specified in the main repo, so setting #commit= for the submodule is useless.
Yeah, that. Although now I am starting to think...
I don't have any PKGBUILDs that do this myself. So it's never really been on my radar. However, I am wondering if it would make more sense to allow/use: - $SRCDEST/$repo for the submodule url. The variable should be accessible, we just don't document its availability for use in a PKGBUILD. - Implement noextract=() for source/git.sh to avoid having two checkouts with that ugly layer of indirection. - Update the "VCS package guidelines" wiki page
Here's how I was told the correct way to handle it was: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mono-git#n57
I've got a few more that use git submodules as well: ags-git and rofi-git are ones I know offhand.
Implement noextract=() for source/git.sh to avoid having two checkouts
with that ugly layer of indirection.
+1
On Mon, Jul 31, 2017 at 2:52 PM Eli Schwartz eschwartz@archlinux.org wrote:
On 07/31/2017 03:35 PM, Doug Newgard wrote:
On Mon, 31 Jul 2017 14:16:33 -0400 Eli Schwartz eschwartz@archlinux.org wrote:
You're both right and wrong. "$srcdir/$submodulename" will be at origin/master, but `git submodule update` in the primary repo will completely ignore that clone altogether and just cares about the git objects which it uses in yet another clone.
This is a bit confusing. You set the URL of the submodule to the
location of
the local clone, so it doesn't ignore it, it just clones from the local
clone.
And yes, it does use the specific commit specified in the main repo, so
setting
#commit= for the submodule is useless.
Yeah, that. Although now I am starting to think...
I don't have any PKGBUILDs that do this myself. So it's never really been on my radar. However, I am wondering if it would make more sense to allow/use:
- $SRCDEST/$repo for the submodule url. The variable should be accessible, we just don't document its availability for use in a PKGBUILD.
- Implement noextract=() for source/git.sh to avoid having two checkouts with that ugly layer of indirection.
- Update the "VCS package guidelines" wiki page
-- Eli Schwartz
Excerpts from Dan B via aur-general's message of July 31, 2017 10:25 pm:
Here's how I was told the correct way to handle it was: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mono-git#n57
From what I can gather in this thread is that I don't need to #commit= any submodules. I can keep doing what I do (which is the same as the package above).
Is this correct?
- Dan
On Wed, 02 Aug 2017 20:37:49 +0000 Dan Printzell arch@vild.io wrote:
Excerpts from Dan B via aur-general's message of July 31, 2017 10:25 pm:
Here's how I was told the correct way to handle it was: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mono-git#n57
From what I can gather in this thread is that I don't need to #commit= any submodules. I can keep doing what I do (which is the same as the package above).
Is this correct?
- Dan
Correct
El Thu, 27 Jul 2017 20:52:10 +0000, Dan Printzell escribió:
Hi Arch people.
My name is Dan Printzell, but I often go by Wild/Vild or when I use an old account, WildN00b. I'm writing this TU application because I want to maintain the dlang packages that are currently orphaned or being dropped from [community]. I'm being sponsored by Johannes Löthberg.
As the maintainer of the only (AFAIK) package in our repos written in D I must say I'm really looking forward to someone who actually cares maintaining the D stack, trying to keep it up to date in the latest months has been a real PITA.
You could start by investigating why dmd segfaults when building on i686 (I ended up dropping i686 entirely as to not block the update)
aur-general@lists.archlinux.org