Re: [arch-dev-public] Goodbye
On Thu, 21 Jan 2021 14:08:11 +0100 Bartłomiej Piotrowski via arch-dev-public wrote: > Hi everyone, > > I'm stepping down as a developer. It's been mostly fantastic ride for > the last 10 years but it's clear to me now that for better or worse > it's far from the project I initially joined. > > Thank you and good luck with everything, > Bart Hi Bart Sad to see you go and thank you for all your work, especially bringing me onboard as a TU. Arch means a lot to me after all these years. Wszystkiego najlepszego! -- Regards, Felix Yan pgpHKFBpmtHmO.pgp Description: OpenPGP digital signature
Re: [arch-dev-public] Spring cleanup '21
On Thursday, April 29, 2021 12:16:48 AM CST Antonio Rojas via arch-dev- public wrote: >It's been over a year since our last package cleanup and orphans keep >piling up. Please head to >https://archlinux.org/devel/reports/unneeded-orphans/ and adopt >packages you'd like to keep in the repos. I have adopted privoxy. Thanks for taking care of this. -- Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
[arch-dev-public] Deprecating systemd-swap
As per suggested by upstream [1], systemd-swap is now deprecated and will be removed from [community] in the following days. zram-generator has been added to [community] as the suggested alternative. [1] https://github.com/Nefelim4ag/systemd-swap#users-should-migrate-to-systemdzram-generator-since-zram-should-be-enough-in-most-systems -- Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
[arch-dev-public] Disowning ruby packages
Hi All, I am disowning most of my ruby packages since I don't use any of them nowadays. Please consider adopting the following ones as they are now orphans: ruby-cairo ruby-faraday-middleware ruby-ffi ruby-multi_json ruby-power_assert ruby-test-unit -- Regards, Felix Yan signature.asc Description: This is a digitally signed message part.
Re: [arch-dev-public] Starting x86_64_v3 port
On 1/29/22 02:12, Allan McRae via arch-dev-public wrote: The decision to be made is who will package for this repo? I think these are the options: A) packagers upload both x86_64 and x86_64_v3 to the repos. Our build server will help those without x86_64_v3 machines. B) we recruit some packagers to build the x86_64_v3 packages. C) Some combination of A+B. My understanding is our x86_64 port started with B, then C, then A. I am fine with either and could happily help with B in long term. For me the issue with either B or C is that our packages are often FTBFS and we are slow to fix them, generally. To make the port really usable for a B/C workflow, we need a way to fill in the time gap (because the old package could be unusable for the time, like missing a so-name bump etc). Do you find it acceptable if the x86_64_v3 rebuilders put back in the new x86_64 package until the build was fixed and probably a point pkgrel was added for the real x86_64_v3 rebuild, as long as we use B/C to build for x86_64_v3, in the long term? -- Regards, Felix Yan OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] [RFC] archweb nvchecker integration
On 2/2/22 19:59, Anatol Pomozov via arch-dev-public wrote: And here is one more tool to check if package version is of out-of-date https://github.com/anatol/pkgoutofdate It is a pretty simple tool that does not require any modification to Arch repo. It simply tries to guess what is the next possible version and then checks the upstream download site for it. The drawback is that it does not handle slotted packages and projects that do not use semver release numbering. According to my past experience with it, there is an important additional drawback: it often detects pre-releases and broken (withdrawn) releases (as marked in a web page, github releases, or the corresponding repository) and the mechanism has no way to tell about this. I am also a regular user of this tool but unfortunately I don't think it's a good idea to use as the main tool. It's a nice addition to my nvchecker config to occasionally check the consistency among different upstream sources (like new version in PyPI but there is no corresponding git tag, or maybe the PyPI package has been moved to a different repository, etc). I think it would still be better to be explicit here. The maintainer should decide about which source to use. -- Regards, Felix Yan OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] [RFC] archweb nvchecker integration
On 2/1/22 22:54, George Rawlinson via arch-dev-public wrote: On 22-02-01 08:21, Morten Linderud via arch-dev-public wrote: At this stage, the following [community] packages that I maintain require massaging of HTML sources: * html-xml-utils * oil * parallel * libmilter (bundled with sendmail source) * time I suppose if a nvchecker plugin existed that utilised bs4 (beautiful soup), that would work. But I assume that would still fit your definition of "arbitrary script". :p There is a regex plugin and a htmlparser plugin for this. The htmlparser plugin accepts XPath, but if you want to process it further the regex plugin may just work better. Examples for your packages: [html-xml-utils] source = "regex" url = "https://www.w3.org/Tools/HTML-XML-utils/"; regex = "html-xml-utils-(.*?).tar.gz" [oil] source = "htmlparser" url = "https://www.oilshell.org/release/latest/"; xpath = "//h1/text()" prefix = "Oil " -- Regards, Felix Yan OpenPGP_signature Description: OpenPGP digital signature
[arch-dev-public] Disowning some packages
Hi, I am disowning the following packages as an attempt to shorten my TODO and focus on packages I still use. certbot certbot-apache certbot-dns-cloudflare certbot-dns-cloudxns certbot-dns-digitalocean certbot-dns-dnsimple certbot-dns-dnsmadeeasy certbot-dns-gehirn certbot-dns-google certbot-dns-linode certbot-dns-luadns certbot-dns-nsone certbot-dns-ovh certbot-dns-rfc2136 certbot-dns-route53 certbot-dns-sakuracloud certbot-nginx dart python-acme python-jaraco.envs python-pkginfo python-readme-renderer python-sqlalchemy python-telegram-bot python-tqdm ruby-bundler treefrog-framework twine Please consider adopting what you or your packages use. Thanks. -- Regards, Felix Yan OpenPGP_signature Description: OpenPGP digital signature
