Re: [aur-general] Trusted user application: Drew DeVault
Hey Christian! On 2019-02-25 6:21 PM, Christian Rebischke via aur-general wrote: > 1. Can you describe in a few sentences how you build your packages for > the AUR and for your own repository? For the AUR: I just run makepkg -i and makepkg --printsrcinfo > .SRCINFO. I keep it pretty casual for the AUR. For my own repository: I have a script called pkgkit[0] which automates some of the work. It automatically takes care of things like bumping pkgrel & checksums, common sources of human error. Then I submit it to my CI with this[1] build manifest, which boots up a fresh Arch Linux VM to build the package on, and uploads it to my repo. [0] https://git.sr.ht/~sircmpwn/sr.ht-pkgbuilds/tree/master/pkgkit [1] https://git.sr.ht/~sircmpwn/sr.ht-pkgbuilds/tree/master/build.yml > 2. How do you keep track of updates of upstream software? Do you use a > specific software for it? Which one? For the AUR I don't keep up with upstream releases, I just wait for someone to mark the package as outdated. For Alpine Linux I use a combination of subscribing to the upstream -announce mailing list and subscribing to GitHub releases as appropriate; would do something similar for Arch Linux community. > 3. Do you plan to socialize with the community? If yes: on which > plattforms? If no: why? Sure, and I already do some. Just on IRC. > 4. What do you like about Arch Linux at most? What do you hate about it? > (You can be open here, I will not judge ^___^) I like that everything is up to date and for the most part Just Werks. I dislike glibc and systemd, but we needn't take that particular flamewar any further than that. > 5. Are you willing to attend real-life meetups on conferences like > FrosCon, CCC, etc? Yep. I met many Arch Linux developers at FOSDEM a few weeks ago. > 6. Do you have any experience with security? This is a pretty broad and open ended question. I suppose my answer is "yes"? > 7. A user opens a bug report, where the user reports a security > vulnerability in one of your packages. The security vulnerability is > unknown and seems to be a 0-day. How do you react? I let upstream know about the issue and then hand them the reins. I consider security vulnerability an upstream problem and delegate authority on how to proceed to them. When a fix is available I'll ship it in my Arch package. I'm not really into the whole responsible disclosure aka pressuring upstream into fixing it yesterday kind of approach. > Thats all from me. Thanks for your hard work with sway btw :) :)
Re: [aur-general] Trusted user application: Drew DeVault
On Sun, Feb 24, 2019 at 06:24:59PM -0500, Discussion about the Arch User Repository (AUR) wrote: > Hiya! Jerome convinced me to finally apply for TU, and Sven-Hendrik > agreed to co-sponsor my application (both Cc'd). > [...] > As a long time fan and user of Arch Linux, I'm looking forward to the > chance to give back to the community. If anyone has any questions, > please let me know. > > -- > Drew DeVault Hi Drew, I have a few questions to you: 1. Can you describe in a few sentences how you build your packages for the AUR and for your own repository? 2. How do you keep track of updates of upstream software? Do you use a specific software for it? Which one? 3. Do you plan to socialize with the community? If yes: on which plattforms? If no: why? 4. What do you like about Arch Linux at most? What do you hate about it? (You can be open here, I will not judge ^___^) 5. Are you willing to attend real-life meetups on conferences like FrosCon, CCC, etc? 6. Do you have any experience with security? 7. A user opens a bug report, where the user reports a security vulnerability in one of your packages. The security vulnerability is unknown and seems to be a 0-day. How do you react? Thats all from me. Thanks for your hard work with sway btw :) best regards, chris / shibumi signature.asc Description: PGP signature
Re: [aur-general] Trusted user application: Drew DeVault
Thanks for all the feedback! I went through and cleaned up all of my AUR packages - something a wiser man would have done before submitting the TU application. Note that in some cases I disowned packages I was no longer interested in maintaining, and in the case of vgo both disowned and filed a deletion request; rather than normalize the PKGBUILDs. On 2019-02-24 6:40 PM, Brett Cornwall wrote: > I must jokingly admit that my first instinct is to vote against your > application so that you'd spend more time on wlroots and Sway. You're not > allowed to work on anything else, slave! Hehe, don't worry, this wouldn't be much more work than I already take on for Arch Linux - it'd just be formalizing that relationship. > * Prefer sha256sums over sha1sums and md5sums > * "$srcdir" can often be omitted as the PKGBUILD functions all begin > in "$srcdir" already - this will make PKGBUILDs much more readable > * MIT-licensed packages are not installing their licenses. > * i386/i686 architectures should be removed. > * update python-distribute makedeps to python-setuptools > * source= lines should save sources to a "$pkgname-$pkgver.tar.gz" file > * Python distutil packages should be built and packaged separately [3]: > * python-spam-blocklists - fill that depends() list, I'm sure it needs > something. Fixed on all counts. > ## python-flask-markdown, python-haxor > * source has https, so use it! Fixed - I normalized all of my Python package's source URLs to the pypi source, using variable substitution to rejigger the names. On 2019-02-25 9:46 AM, Morten Linderud via aur-general wrote: > ## python-asyncio_redis > * I'm a bit unsure what 2 clause BSD is traditionally called. But it's not `2 > clause BSD`. After some searching from the repos it seems like `BSD` should > be > enough(?) Updated to use the SPDX identifier. > Also want to stress the lack of MIT license being places in > `/usr/share/licenses/`, along with source not currently enforcing shared > SRCDEST as Brett pointerd out. Fixed this everywhere I found it. On 2019-02-25 9:58 AM, Levente Polyak via aur-general wrote: > Your build script on the CI does not produce reproducible packages as > it uses a own simple wrapper to call makepkg. F.e. If there is no > SOURCE_DATE_EPOCH defined to now or the value already passed it does > not create uniform mtimes. Filed a ticket to address this at a later date: https://todo.sr.ht/~sircmpwn/sr.ht/165 This shouldn't be an issue for community, though. > Out of curiosity, what kind of upstream watch are you using to be made > aware of new releases? For the AUR I don't keep up with upstream releases, I just wait for someone to mark the package as outdated. For Alpine Linux I use a combination of subscribing to the upstream -announce mailing list and subscribing to GitHub releases as appropriate; would do something similar for Arch Linux community. > Vgo-git should use go-pie as makedepends like all packages that work I dropped vgo, but fixed this for my other Go-based packages. > None of your python packages, neither in aur nor in your repo build CI > are running any unit tests while most of them provide tests upstream. Fixed in many places in my AUR packages. Will do this for sr.ht-pkgbuilds later: https://todo.sr.ht/~sircmpwn/sr.ht/167
Re: [aur-general] Trusted user application: Drew DeVault
On 25/02/2019 00.23, Drew DeVault wrote: > Hiya! Jerome convinced me to finally apply for TU, and Sven-Hendrik > agreed to co-sponsor my application (both Cc'd). > > I'm a generalist that works on free software full time. I maintain the > following AUR packages: > > https://aur.archlinux.org/packages/?SeB=m=sircmpwn > > I also maintain a third-party Arch repo and oversee some automation for > helping to build and publish new packages: > > https://git.sr.ht/~sircmpwn/sr.ht-pkgbuilds > > I'm also the upstream maintainer for several packages in community, > including wlroots, sway, and scdoc; and I maintain numerous packages for > Alpine Linux as well. I maintain many other free software projects, > most notably sourcehut, and I also contribute to many projects > maintained by others as well. > > I think Jerome has been hoping for some relief from the packages I > maintain the upstream for, so I may start by relieving that burden. I'd > also like to move the samuari package into community, and likely some > of the Python packages from my third-party repository as well. > > Outside of packaging, I have also been doing some exploratory work that > I hope will lead to finally moving Arch Linux from SVN to git. > > As a long time fan and user of Arch Linux, I'm looking forward to the > chance to give back to the community. If anyone has any questions, > please let me know. > > -- > Drew DeVault I confirm my co-sponsorship. Let the discussion period begin! signature.asc Description: OpenPGP digital signature
Re: [aur-general] Trusted user application: Drew DeVault
Hi, Your build script on the CI does not produce reproducible packages as it uses a own simple wrapper to call makepkg. F.e. If there is no SOURCE_DATE_EPOCH defined to now or the value already passed it does not create uniform mtimes. What I have noticed as well, f.e where you are upstream plus downstream, there is CPPFLAGS as well which, at least downstream, we must ensure finds its way into the compilation flags. Out of curiosity, what kind of upstream watch are you using to be made aware of new releases? Vgo-git: Should use go-pie as makedepends like all packages that work it should respect LDFLAGS via extflags like gitea does. Does not contain git makedepends, you should build in clean chroot via makechroot aka extra- wrapper from devtools to catch such case python: None of your python packages, neither in aur nor in your repo build CI are running any unit tests while most of them provide tests upstream. Using github sources and running unit tests to catch regressions is highly recommended, please go through them :-) Cheers, Levente
Re: [aur-general] Trusted user application: Drew DeVault
On Sun, Feb 24, 2019 at 06:40:13PM -0700, Brett Cornwall via aur-general wrote: > Here's a PKGBUILD review: Some additional points! > ## madonctl * This package needs to drop `go get` as we have vendored deps. > ## python-activipy-git * "v" should be removed from the pkgver as we are dealing with versioned tags. > ## vgo-git * This package has support for go modules. So it can drop all of the voodoo it is currently doing. ## python-asyncio_redis * I'm a bit unsure what 2 clause BSD is traditionally called. But it's not `2 clause BSD`. After some searching from the repos it seems like `BSD` should be enough(?) Also want to stress the lack of MIT license being places in `/usr/share/licenses/`, along with source not currently enforcing shared SRCDEST as Brett pointerd out. Else the review from Brett seems decent :) Great work. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
