[aur-general] TU Application: Dan Printzell

newer
[aur-general] Package proprietary...

Dan Printzell

27 Jul 2017 27 Jul '17

8:52 p.m.

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/

Attachments:

attachment.sig (application/pgp-signature — 833 bytes)

Show replies by date

Johannes Löthberg

27 Jul 27 Jul

8:58 p.m.

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! -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 PGP Key FP: 5134 EF9E AF65 F95B 6BB1 608E 50FB 9B27 3A9D 0BB5 https://theos.kyriasis.com/~kyrias/

Johannes Löthberg

1 Aug 1 Aug

12:29 p.m.

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 -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 PGP Key FP: 5134 EF9E AF65 F95B 6BB1 608E 50FB 9B27 3A9D 0BB5 https://theos.kyriasis.com/~kyrias/

Johannes Löthberg

8 Aug 8 Aug

4:03 p.m.

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! -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 PGP Key FP: 5134 EF9E AF65 F95B 6BB1 608E 50FB 9B27 3A9D 0BB5 https://theos.kyriasis.com/~kyrias/

Christian Rebischke

27 Jul 27 Jul

11:14 p.m.

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 [1] https://www.tiobe.com/tiobe-index/

Bartłomiej Piotrowski

28 Jul 28 Jul

9:49 a.m.

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.

...

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

Jelle van der Waa

11:56 a.m.

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 :-) -- Jelle van der Waa

Eli Schwartz

3:09 p.m.

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.

...
1. 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* -- Eli Schwartz

Dan Printzell

2:32 p.m.

(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 ======

...

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.

Thanks, I will change that.

...

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

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

Will do

...

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.

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

Dan Printzell

2:36 p.m.

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

Christian Rebischke

31 Jul 31 Jul

6:09 p.m.

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

Florian Bruhin

6:12 p.m.

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 -- https://www.qutebrowser.org | me@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/

Eli Schwartz

6:16 p.m.

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

Doug Newgard

7:35 p.m.

On Mon, 31 Jul 2017 14:16:33 -0400 Eli Schwartz 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.

Eli Schwartz

7:52 p.m.

New subject: [aur-general] [pacman-dev] Handling git submodules (Was: Re: TU Application: Dan Printzell)

On 07/31/2017 03:35 PM, Doug Newgard wrote:

...

On Mon, 31 Jul 2017 14:16:33 -0400 Eli Schwartz 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

Dan B

8:25 p.m.

New subject: [aur-general] [pacman-dev] Handling git submodules (Was: Re: TU Application: Dan Printzell)

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 wrote:

...

On 07/31/2017 03:35 PM, Doug Newgard wrote:

...
On Mon, 31 Jul 2017 14:16:33 -0400 Eli Schwartz 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

Dan Printzell

2 Aug 2 Aug

8:37 p.m.

New subject: [aur-general] [pacman-dev] Handling git submodules (Was: Re: TU Application: Dan Printzell)

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

Doug Newgard

11:22 p.m.

New subject: [aur-general] [pacman-dev] Handling git submodules (Was: Re: TU Application: Dan Printzell)

On Wed, 02 Aug 2017 20:37:49 +0000 Dan Printzell 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

Antonio Rojas

29 Jul 29 Jul

8:36 a.m.

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)

2453

Age (days ago)

2465

Last active (days ago)

List overview

Download

18 comments

10 participants

participants (10)

Antonio Rojas
Bartłomiej Piotrowski
Christian Rebischke
Dan B
Dan Printzell
Doug Newgard
Eli Schwartz
Florian Bruhin
Jelle van der Waa
Johannes Löthberg