Hi!
On 21.10.20 20:21, Morten Linderud wrote:
> On Sun, Oct 18, 2020 at 05:39:41PM +0200, Tim Meusel via aur-general wrote:
>> Hi!
>
> Yo!
>
>> Besides working on open source projects, I spent a huge amount of time
>> for my second passion, cooking and doing BBQ. From time to time I also
>> attend ice hockey events as visitor but also as hobby-referee or player.
>
> Yes.. I heard some rumors about team members ice skating and ending up with
> stitches during this years FOSDEM. This might be more useful information then
> you know :D
Good to know! I'm usually around at FOSDEM (at of course config
management camp in Ghent the following three days)
>
>> As a trusted user I would like to co-maintain those packages, enable
>> tests on the PKGBUILDs where tests are currently missing (for example
>> ruby-puppet-resource_api, ruby-semantic_puppet and Puppet), fix the
>> remaining namcap warnings (for example on facter and libwhereami) and
>> also import some other Puppet related tools into the official
>> repository. Some of them are already in the AUR (not all maintained by
>> myself):
>>
>> [snip package list]
>
> How interested would you be to pick up a bit on the Ruby Gem package
> guidelines
> on the wiki, and how are you currently keeping track of package updates?
>
> https://wiki.archlinux.org/index.php/Ruby_Gem_package_guidelines
sure, I already talked a few times to anthraxx about packaging
guidelines for Ruby and want to update the page in the future.
I'm involved in most of the open source projects I created PKGBUILDs
for. besides that I've their rubygems.org release feed in my RSS client
and/or GitHub notifies me about new releases.
>
>> I talked to shibumi and hashworks in the past days, both reviewed the
>> packages and agreed to sponsor my application.
>
> Generally they look nice and I don't spot any major rewrites as part of the
> sponsor reviewing. Which is a good sign I guess! I don't know ruby very well,
> which is why it was *very* fortunate that you uploaded a Go PKGBUILD today :)
> Now I have some pointers!
>
> Generally speaking it's fine. I think the `glibc` in `depends` makes no sense
> when there are other dependencies present, but it's generally not an issue.
>
thanks for this point! I don't have an opinion on adding dependencies
that are already pulled in because other deps also depend on them. I was
a bit unsure here and asked multiple trusted users about this. 50% said
it should be added, 50% were against. anthraxx also recommended adding
it so I went with that.
> Before `prepare` you have listed up 8 environment variables for the go
> compiler,
> generally they should be inside the given functions as makepkg does magic to
> the
> environment between the different prepare/build/check/package steps. So this
> is
> wrong and should be moved inside build and check.
>
> `prepare` is fine, but `$srcdir` is not really needed. But that is more a
> cosmetic thing.
>
> build is fine, but it has a few issues. Where is the build.SHA from? BuildDate
> is set to current time, which is not reproducible. Preferably it should adhere
> to `SOURCE_DATE_EPOCH` as noted by Reproduible Builds like so:
>
> -X 'github.com/choria-io/go-choria/build.BuildDate=$(date
> -d@"${SOURCE_DATE_EPOCH}" '+%F %T %z')'
>
> But apart from that both check and package is fine.
Thanks for all the feedback on the PKGBUILD! I'm pretty new to the Go
world and based this PKGBUILD on the consul/vault ones that are in
community. I managed to build choria properly and execute the tests, but
I'm not yet happy with the PKGBUILD and don't consider it complete. I
will update it in the next days.
>
>> I'm available on Freenode as bastelfreak. I'm pretty active in
>> #archlinux.de and #voxpupuli. My GPG key fingerprint is
>> C10B6298A584A5632E254DA304D659E6BF1C4CC0
>
> As noted in another email, rsa2048 is bordering on weak these days. It would
> be
> preferable to update the keysize if you do get accepted. Preferably as part of
> the application :)
>
Thanks for the note, I'm aware of this. I think it's always a tradeoff
between using an established key with multiple signatures vs a new one
with stronger ciphers. My plan was to create a new key dedicated for TU
work, if I get accepted, and crossign it with my current private key.
Maybe it would have been smarter to send the application directly with a
new key.
>> best regards, Tim
>
> Cheers and good luck!
>
signature.asc
Description: OpenPGP digital signature
