July 2018 - Arch-dev-public - lists.archlinux.org

[arch-dev-public] Can anyone take nvidia-390xx?
by Sven-Hendrik Haase 23 Feb '20

23 Feb '20

I don't run nvidia-390xx on any of my devices. I would appreciate it if somebody could take those drivers. I will continue maintaining the mainline nvidia package.

2 1

[arch-dev-public] Improving overall experience for contributors
by Bartłomiej Piotrowski 06 Feb '19

06 Feb '19

Hi all, Spending some time outside the regular Arch circles, I realized that the way we "outreach" potential contributors is at least imperfect. One of the problems I keep hearing about is that there is no clear place where potential contributors could start. Sure, some things seem obvious to us: take care of some wiki article or adopt orphan AUR packages. It isn't actually that easy. Not everyone is interested in editing or maintaining random packages, and while there is plenty to do, how someone new could know it? We could use help not only with existing projects like archweb, pyalpm or namcap, but also with development of new code (for example a maintainable rebuild automation) and infrastructure side (which is in fact too generic term that could be better described). I am totally in love with What can I do for Mozilla?[1] which is open source, so why not steal this wonderful idea? But it also means we need a way to communicate with people interested in helping us: at least an IRC channel and new mailing list. Another thing that I heard in last few months isthat it is actually hard for potential TU candidates to find a sponsor. While I believe it is perfectly fine to e-mail few potential sponsors to ask for opinion, throwing random messages at people doesn't sound really appealing. In my humble opinion, we should rethink the way we recruit people and probably introduce fine-grained permissions to dbscripts that would allow to limit new maintainers to limited set of packages. We should also lower our expectations towards candidates. At least once we rejected one for some stupid reason (no fingerpointing here, I'm not saint either), leaving packages they wanted to adopt virtually orphan. It's better to help amn inexperienced packager gain experience than voting no, really; to be brutally honest, quite a lot of packaging work we are handling doesn't have much in common with rocket science. I also wanted to touch mailing lists vs GitHub vs Gitlab topic but we will tackle it another time. Your thoughts? Bartłomiej [1] https://whatcanidoformozilla.org/

8 11

[arch-dev-public] Arch Linux Cloud Images (virtualbox and Qemu)
by Christian Rebischke 07 Nov '18

07 Nov '18

Hello everybody, Some months ago Bartlomiej had the awesome idea to generate qemu and virtualbox images as well. Afterwards we had a small discussion about this topic in #archlinux-projects. I would like to refresh this discussion and move it to this mail thread. So, our vagrant boxes are building automatically and without issues for a few months now. I could just generate virtualbox and qemu images as side products monthly, but I have no idea how we would release them. Another big topic is security. The vagrant images are at the moment not signed and seems like vagrantcloud doesn't support this either. This doesn't mean that we shouldn't sign our qemu or virtualbox images. We could just generate an automated cloud image signing key (only for this purpose) of course and automatically sign the images with that key. Problem with this is: If our build server ever get pwned the person will have these keys for signing cloud images as well. Any opinion about this? In my humble opinion I would be fine with a signing key that follows only this particular purpose. Another idea would be to move the whole production process to a physical server behind a firewall that is physical accessible by one or more Arch Linux Developers. I really would like to push this forward. Any comments? Chris

4 4

[arch-dev-public] Improving the package guidelines
by Morten Linderud 30 Aug '18

30 Aug '18

Yo! In April there was some discussion regarding how to properly do unit testing in Python PKGBUILDs[1]. Felix had some amazing notes that was super useful. But as pointed out we don't really strive to document these things[2]. To try help and spark some interest in improving the current package guidelines, I have spent a some time restructuring and rewriting parts of the Python and Golang package guidelines. I'd appreciate reviews on them! https://wiki.archlinux.org/index.php/User:Foxboron/Python_packaging_guideli… https://wiki.archlinux.org/index.php/User:Foxboron/Go_packaging_guidelines It really doesn't take that much time to note down what you know about packaging and what the current standards are. I think this helps both fellow maintainers and AUR maintainers in writing better PKGBUILDs and sharing knowledge. If people think editing wikis are annoying, maybe we could setup a github repository with example PKGBUILDs we can work on? [1]: https://lists.archlinux.org/pipermail/arch-dev-public/2018-April/029228.html [2]: https://lists.archlinux.org/pipermail/arch-dev-public/2018-April/029233.html -- Morten Linderud PGP: 9C02FF419FECBE16

4 8

[arch-dev-public] dropping luxrender packages
by Lukas Jirkovsky 29 Jul '18

29 Jul '18

Hi, I'd like to drop the luxrays, luxrender and luxblend25 packages from [community]. They have always required continuous attention to keep working which I can no longer provide with sufficient quality and right now the luxrender package is blocking the Python 3.7 rebuild. Moreover, the luxrender project has been abandoned and it was superseded by LuxCoreRender which has an active maintainer in AUR. If nobody steps in, I will remove them tomorrow. Lukas

2 2

[arch-dev-public] jack rebuild required
by David Runge 29 Jul '18

29 Jul '18

Hey all, I've now created a realtime-privileges package to support a more general approach to acquiring realtime and rebuilt jack2 against those changes [2], making the aforementioned package an optional dependency for jack2 (while removing the redundant realtime settings). These changes are currently still in [community-testing]. As jack is in [extra], I'm unable to rebuild it with the changes, but I've prepared an update to its PKGBUILD [2]. I would be happy if some developer could rebuild jack with the updated build script and `svn rm jack.install, 40-hpet-permissions.rules, 99-audio.conf` before uploading. The changes have the benefit of outsourcing the settings, making it possible to reuse them in other applications, as previously discussed [3]. Best, David [1] https://lists.archlinux.org/pipermail/arch-proaudio/2018-July/000163.html [2] https://pkgbuild.com/~dvzrv/extra/jack/PKGBUILD [3] https://lists.archlinux.org/pipermail/arch-dev-public/2018-February/029172.… -- https://sleepmap.de

1 0

[arch-dev-public] [arch-general] proposal to add "aurpublish" to community
by Eli Schwartz 29 Jul '18

29 Jul '18

On 07/20/2018 04:23 AM, WorMzy Tykashi via arch-general wrote: > On 20 July 2018 at 08:38, Jelle van der Waa <jelle(a)vdwaa.nl> wrote: > >> On 07/20/18 at 09:05am, Jelle van der Waa wrote: >>> On 07/19/18 at 07:23pm, Florian Pritz via arch-dev-public wrote: >>>> On Wed 18.07.18 - 15:28, Eli Schwartz via arch-dev-public wrote: >>>>> I would like to add this to [community], but I'm unsure what people >>>>> think about this; specifically, whether this might come too close to >>>>> "supporting the AUR via [community] packages". Note that this is >> *not* >>>>> an AUR helper and is strictly a tool for package *maintainers* to use >>>>> during the process of uploading. >>>> >>>> Uploaders are fine by me and I think we had one in previously. >>> >>> From what I can recall, we had one in, some discussion and it was gone >>> again. I'll try to find the post in the archives. >>> >> >> Gotcha, it was cower. [1] >> >> [1] https://lists.archlinux.org/pipermail/aur-general/2010- >> December/012763.html >> >> -- >> Jelle van der Waa >> > > (apologies for crosslist posting) > > For uploaders, there was 'burp' in [extra] which which was added without > any serious opposition, and remained in the repos until shortly after AUR4 > was launched (which made it redundant). See > https://lists.archlinux.org/pipermail/arch-dev-public/2012-April/022787.html > and https://bugs.archlinux.org/task/46210 > > Cheers, > > > WorMzy So yeah, it seems like at least in the past there's been a distinction made between uploaders (burp, aurpublish) and downloaders (cower). Anyway if no one has a serious objection by the end of the week I guess I will add it. :) -- Eli Schwartz Bug Wrangler and Trusted User

2 2

[arch-dev-public] Away until Aug 17
by Antonio Rojas 27 Jul '18

27 Jul '18

Vacation time. Will be intermittently available via email/irc but won't do any packaging.

2 1

[arch-dev-public] away until 5th August
by Andreas Radke 20 Jul '18

20 Jul '18

Time for two weeks offline with my family. -Andy

1 0

[arch-dev-public] proposal to add "aurpublish" to community
by Eli Schwartz 20 Jul '18

20 Jul '18

Hi, so for a while now I've been using a tool I wrote at https://github.com/eli-schwartz/aurpublish -- recently split out from a vendored script in https://github.com/eli-schwartz/pkgbuilds -- to maintain my AUR packages. Some of you will probably have heard about it before. :) I certainly think it's a nifty tool :D and apparently a number of other people do too. It makes things faster and simpler, and especially prevents people from accidentally uploading PKGBUILDs with out of date .SRCINFO which is obviously a huge plus... I would like to add this to [community], but I'm unsure what people think about this; specifically, whether this might come too close to "supporting the AUR via [community] packages". Note that this is *not* an AUR helper and is strictly a tool for package *maintainers* to use during the process of uploading. What do you all think? -- Eli Schwartz Bug Wrangler and Trusted User

3 3