Re: [arch-dev-public] Archweb migration
On 18/12/2020 21:42, Giancarlo Razzolini via arch-dev-public wrote: Em dezembro 18, 2020 14:24 Giancarlo Razzolini via arch-dev-public escreveu: Em dezembro 16, 2020 10:34 Giancarlo Razzolini via arch-dev-public escreveu: Hi All, Continuing with the efforts to migrate each service to their own, separate VPS, we are now going to migrate archweb (our site). The tentative date for migration is tomorrow, 17, with a backup date this Friday, 18, around 6PM UTC. The site will be in maintenance mode and the service that updates the packages on archweb's database will be stopped on gemini. I expect the migration to last around 2 hours, but it might be faster than that. Also, we're changing the current redirection, which is to redirect anything to www.archlinux.org, to instead redirect anything to just archlinux.org. There's no rush to update any links, since we'll keep the redirections indefinitely. Regards, Giancarlo Razzolini Hi all, The migration didn't happen yesterday due to some email issues. But everything is fixed and the migration is going to start in about half an hour. Regards, Giancarlo Razzolini Hi, The migration is complete. There shouldn't be any issues, but, please let us know if you notice anything. Thanks a lot for the migration! Greetings, Jelle van der Waa OpenPGP_signature Description: OpenPGP digital signature
[arch-dev-public] New Archive Mirrors available
Hi All, I am happy to announce that thanks to Kake/PIA sponsoring us dedicated servers, we now have three new Arch Linux Archive servers available at: https://america.archive.pkgbuild.com/ https://europe.archive.pkgbuild.com/ https://asia.archive.pkgbuild.com/ The servers have 3 x 9.1 TiB disks and have similar capacity to our canonical archive. Greetings, Jelle van der Waa OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] Boost 1.74 Rebuilds
On 06/12/2020 21:07, Jelle van der Waa wrote: Hi all, We've started the Boost rebuilds with automated builds in [staging], if required a todolist will be created for the failing builds. Please don't schedule any rebuilds which conflict with boost. Hopefully packages will arrive in [testing] before the end of the week :) And it's in [testing] now! Greetings, Jelle
[arch-dev-public] Boost 1.74 Rebuilds
Hi all, We've started the Boost rebuilds with automated builds in [staging], if required a todolist will be created for the failing builds. Please don't schedule any rebuilds which conflict with boost. Hopefully packages will arrive in [testing] before the end of the week :) Greetings, Jelle OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] [RFC] Debug packages and debuginfod
On 23/11/2020 16:52, Morten Linderud via arch-dev-public wrote: > > Give me cake, or give me debug symbols. > - Some comedian, probably. > > Yo! > > For quite a few years people has wanted debug packages, but there has never > really been any progress towards them. Pacman got support almost 10 years ago, > and Allan wrote a POC for dbscripts in 2015[1]. > > In recent years this has largely been a discussion how large such a repository > would become, and how to distribute it. But since we don't have any numbers > things have more or less stalled with things being discussed, but never worked > on. Dropping an imaginary 100 GB on some poor mirror hosts doesn't seem quite > right. > > However, things has been been progressing for the better when it comes to the > distribution of debug symbols that can hopefully make this entire process > easier > for us. debuginfod has been introduced into elfutils which allows a > standardized > API for fetching remote debug symbols [2]. Eli and I have have been chatting > a little with upstream since February to ensure we could get our package > format supported. This was fairly straight forward with an example package > from us and things have been working nicely. > > Patches in elfutils: > https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=499129e77aa88b94756bd6c8d50347721689065c > https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=0245c6ed65a80bceb105317525f0cf38bf27b623 > https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=ad09e791320d13149854ce7a0529842ea0d41a3d > > We have been distributing debuginfod since 0.178-1 and debuginfod support came > to gdb with the 10.1 release, which is why I'm picking up on this now :) > > We did some testing with the debuginfod support with Stapelberg during the > summer, and it works fairly well [3]. Eli has also started writing up the > support for splitting out the debug packages into a separate pool [4]. I have > since merged some of Elis dbscripts patches to the POC git migration server to > test things. Cool! > The idea is to allow uploads of debug packages to repos.a.o into a separate > package pool, have a public reachable debuginfod and then consider if we > want/need debug package distribution. We can then check the new mirror > requirements, and give a clear heads up to any potential mirror admin while > providing debug packages. I think this is a reasonable compromise for > everyone. > OpenSUSE already has one such server as an example [5]. > > There isn't any one way we have to progress on this, but my proposed timeline > is > as follows: > > - Add a debuginfod role to the infrastructure repository. Please create a new ticket in the infra repo with some requirements/details! Especially with information where we host debuginfod, size requirements etc. > - Test and deploy the dbscripts support for debug packages. Is this separate of the Git migration? Or is the git migration a requirement to get debug packages > - Add support to devtools for uploading debug packages. > - Announce debuginfod support. > - Discuss how to distribute the packages. We can at least host them on gemini and make them staff only in the beginning. Greetings, Jelle OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] Add active Python versions to the repos
On 21/11/2020 15:34, Filipe Laíns via arch-dev-public wrote: Hi all, I want to propose adding all active Python versions to [community], not just the latest one. This would only entail adding the interpreter itself, no other packages. Having access to interpreters for older active versions is really helpful for Python developers. This allows them to easily run test suites against older versions. It is very common for developers to maintain software against a couple major releases. Tools like tox or nox are able to automate testing against multiple Python versions, just needing the interpreter. The current active Python releases are: - 3.9 - 3.8 - 3.7 - 3.6 - 2.7 The list can be found here[1]. So, I propose introducing 2 new packages: - python3.7 - python3.6 And when we update the python package to 3.9: - python3.8 I am not super in favor of providing an old version, as we strive to provide the latest and greatest. However some things come to mind: * Does the Python foundation still maintain older Python versions and do they provide proper security updates? * This seems to be purely for Development right? Users would use this Python version to bootstrap a virtualenv I guess? Greetings, Jelle OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] Arch Linux in GSOC 2021
On 30/10/2020 20:18, Konstantin Gizdov wrote: > Hi all! > > Last year Arch Linux applied to be a mentoring organisation in the > Google Summer of Code program. There were quite a few cool projects and > lots of keen people. Unfortunately, we were not selected. > > However, I was hoping people are excited about trying again this year as > well. I have already been contacted by a couple of people who saw the > GSOC page on the Dev Wiki and are showing quite some interest. I > presume, if we advertise we will get a lot of interested people. My feedback from the previous attempt last year is that we took too little time to really write a decent application and provide a clear list of potential GsoC projects. > GSOC application period starts on January 29, 2021 for mentoring > organisations and closes on February 19, 2021. We should make sure we > satisfy the requirements [1]: > 1. Mentor organisations must run an active open source or free software > project. > 2. Have produced and released software under an OSI approved license [2]. > 3. Must not be based in a country currently embargoed by the United States. We do meet these requirements, but the last time I remember we had to fill in a lot of forms for our organization application. This goes for projects and for the whole organization fill in form, which is sadly not available yet and we will have 2-3 weeks to fill in. > I think we do fall into those categories and I would suggest this year > we start preparing a bit earlier to improve our chances. Let's try and > coordinate an effort. Maybe start with the people keen on mentoring and > collation of prospective project ideas. Yes! Please try to get some people together, maybe do a monthly/biwkeely mumble chat and get shared pad/thing to easily collaborate ideas. Greetings, Jelle van der Waa signature.asc Description: OpenPGP digital signature
[arch-dev-public] Orion retirement
Hi All, Our dedicated server orion (used to host repos.archlinux.org/mail.archlinux.org) has been cancelled which means it will be no longer accessible in 30 days. If you have anything of value in your home directory, please copy it before the 10th of November as then the server will be completely wiped. As the DNS entry is already gone you'll need to login into 88.198.91.70 We do have backups of this server, but do not wish to query them on demand if not required :) Greetings, Jelle signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Mail server migration
On 23/10/2020 22:12, Jelle van der Waa wrote: > Hi All, > > Tomorrow we will migrate the mail server starting at Saturday the 24th > October (tomorrow) on 12:00 GMT. The migration should take around four > hours, but could take longer. The migration is finished successfully. If you have problems accessing your email via IMAP, please report your issue in #archlinux-devops. Greetings, Jelle signature.asc Description: OpenPGP digital signature
[arch-dev-public] Mail server migration
Hi All, Tomorrow we will migrate the mail server starting at Saturday the 24th October (tomorrow) on 12:00 GMT. The migration should take around four hours, but could take longer. This migration affects everything which sends email, so not only your @archlinux.org address but also the bbs, AUR, etc. The reason is why we migrate the mail server, the current server costs us ~ 40-60 euro / month (dedicated server) and we will be moving to a VPS which is around ~ 3 euro / month. Greetings, Jelle signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Autumn extra cleaning
On 06/10/2020 03:15, Daniel Bermond via arch-dev-public wrote: > On 05/10/2020 02:16, Sven-Hendrik Haase via arch-dev-public wrote: >> and TUs >> can notify which packages they are interested to maintain in [community] > >> chromaprint > >> gifsicle Moved >> x11vnc Moved >> xine-lib >> xine-ui Moved Thanks! signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Autumn extra cleaning
On 06/10/2020 05:17, Ivy Foster via arch-dev-public wrote: > On 05 Oct 2020, at 7:16 am +0200, Sven-Hendrik Haase via arch-dev-public > wrote: >> ttf-junicode >> ttf-linux-libertine >> x11-ssh-askpass Moved to [community] thanks! signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Autumn extra cleaning
On 05/10/2020 07:16, Sven-Hendrik Haase via arch-dev-public wrote: > Hey everyone, > > It was suggested as part of this year's spring cleanup of [community] > that we should be have a cleanup in [core]/[extra] and move packages > downwards into [community]. > > This round only concerns [extra] packages. > > Devs that want the packages in [extra], please adopt packages, and TUs > can notify which packages they are interested to maintain in [community] > > fakechroot Adopted as test dep of pacman > ifplugd David, this is also an archiso dep signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Bug tracker migration
On 30/08/2020 01:02, Frederik Schwan via arch-dev-public wrote: > Hi folks, > I'd like to migrate the beloved Flyspray bug tracker to our new Gitlab > instance. Nice! > TLDR: > - Bug wrangling day on the 13th of September; see 1) > - Flyspray will be read-only after we rewrite the Archweb URLs > - new bug tracker -> Gitlab > > > 1) I'd like to hold a bug wrangling day, where our goal is to close as many > bugs as possible. >Any TU, Reporter and bug wrangler is invited to help out :) Unfortunately > I can't offer any cookies that day :/ This is coordinated on #archlinux-bugs on Freenode right? >Rules: > a) Bug with no reply for at least 6 months which has been submitted for > a different version than the current one in > the repos shall be closed with a message that a reopen request may be > filled if this issue is still present. I think we have a lot of issues which are fixable but the packager has not been able to do it yet. In my opinion we should also try to fix as much packages as possible, which everyone should be able to do. > b) Any infrastructure ticket shall not be touched. This will be handled > by $DevOps. What infrastructure tickets are there on flyspray? What about other projects such as aurweb, pacman etc? > 2) Afterwards we will point the bug tracker links in the Archweb to the new > location and opening new tickets in Flyspray >will be disabled. The project structure of the future Gitlab bug tracker > will be discussed in a seperate mail and >is not part of this mail(thread). It would be amazing if this goes together with the Git migration, how would the bug tracker on Gitlab work for community/core/extra? > 3) When enough tickets are closed or when $DevOps is tired enough of > Flyspray, we'll migrate the rest of the tickets to >Gitlab. We seek to keep Flyspray as a static homepage to allow the > reference in the new bug tracker to old tickets and >to keep the integrity of search engine results. Can you create an isse on the infrastructure repository with these steps? Would be nice to keep track of the progress in a central location. Thanks! Jelle van der Waa signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Reproducible Builds July Update
On 09/07/2020 23:00, Jelle van der Waa wrote: > Hi All, > > A lot of work has been put into getting Arch packages 100% reproducible, > the [community] repository has been added to the rebuilderd instance on > reproducible.archlinux.org. As of now [community] is 60% reproducible > and packages with file ordering issues have been rebuild and are about > to be moved to [community] which will hopefully increase the > reproducible package percentage! > > Archweb now imports the rebuilderd status into it's database so, you are > now able to your reproducible package issues. [1] > > In your Archweb profile, it's possible to get an email notifications > when packages change from reproducible to unreproducible. [2] > > As of now, the software which rebuilds our packages store no logs/diffs > of the unreproducible packages. To get a diff: > > 1) Retrieve the package > 2) run "repro -d $pkg" > > Or when a package is freshly build: > > $ repro -ndf $pkg > > To rebuild the newly build package. > > For some package groups there are "structural" issues such as KDE > packages, packages with JAR files and Haskell packages see the wiki for > those issues. [3] > > For Haskell packages, a filesystem/perl bug has to resolved. [4] Forgot to link the filesystem/perl bug, it's https://bugs.archlinux.org/task/66338 signature.asc Description: OpenPGP digital signature
[arch-dev-public] Reproducible Builds July Update
Hi All, A lot of work has been put into getting Arch packages 100% reproducible, the [community] repository has been added to the rebuilderd instance on reproducible.archlinux.org. As of now [community] is 60% reproducible and packages with file ordering issues have been rebuild and are about to be moved to [community] which will hopefully increase the reproducible package percentage! Archweb now imports the rebuilderd status into it's database so, you are now able to your reproducible package issues. [1] In your Archweb profile, it's possible to get an email notifications when packages change from reproducible to unreproducible. [2] As of now, the software which rebuilds our packages store no logs/diffs of the unreproducible packages. To get a diff: 1) Retrieve the package 2) run "repro -d $pkg" Or when a package is freshly build: $ repro -ndf $pkg To rebuild the newly build package. For some package groups there are "structural" issues such as KDE packages, packages with JAR files and Haskell packages see the wiki for those issues. [3] For Haskell packages, a filesystem/perl bug has to resolved. [4] [1] https://www.archlinux.org/devel/reports/non-reproducible-packages/$username/ [2] https://www.archlinux.org/devel/profile/ [3] https://wiki.archlinux.org/index.php/Reproducible_Builds/Status [4] https://wiki.archlinux.org/index.php/Reproducible_Builds/Status Greetings, Jelle signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Use detached package signatures by default
On 09/07/2020 05:05, Anatol Pomozov via arch-dev-public wrote: > TLDR; let’s start using detached package signatures to make system > updates faster. > > Hi folks, > > Some time ago there was a discussion at IRC where someone (Allan > maybe?) proposed to stop using embedded PGP signatures in favor of > detached signature files. I would like to bring this idea here and > quantify it with some numbers. The downside of not having the package signatures in the database is that consumers can not easily obtain this information. For archweb that's showing who signed the package on the package details page. How would I implement an efficient alternative without fetching package files or all the sig files? A separate sig database? :P As far now I'll have to adjust the code not to break because of a missing PGPSIG entry. > Here is a bit of technical details on this topic. Pacman has the > ability to verify authenticity of package files with PGP signatures. > PGP signatures add protection against undesired package modifications > by a third-party and it improves security aspects of the package > management. This feature can be configured per repository and the > official Arch Linux repos have it enabled. Package signatures have > been used by Arch Linux successfully for a couple of years now. > An alternative to embedded signatures are detached signatures. These > are signatures stored in a separate file next to the package itself > (in a .sig file to be specific). Instead of downloading *all* > signatures every time a database is updated, detached signatures are > downloaded only when a specific package is installed/updated. If Arch > could switch to this model then database files become 3 times smaller > that saves users bandwidth and system update time. It would be insightful to provide the database numbers, because one could argue 30% of 1MB is nothing, as 30% of 100M is nice improvement. Our biggest database should be community (5M atm), and with all the savings that would now be ~ 2 MB? Would be nice to have an overview of the real life numbers :) Greetings, Jelle van der Waa signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] repos.archlinux.org has been migrated to a new server
On 26/06/2020 02:50, Gaetan Bisson via arch-dev-public wrote: > Hi Jelle, > > [2020-06-25 23:36:15 +0200] Jelle van der Waa: >> repos.archlinux.org, svn.archlinux.org and rsync.archlinux.org are now >> on a new server which has plenty of diskspace for us to continue >> packaging for a while (16T free). > > On the old host I had a systemd user service to populate this: > > https://sources.archlinux.org/other/packages/iana-etc/ > > And also other admittedly less important things in my home directory > that I'd still like to see moved to the new host. Could you make a > tarball of my homedir on the old host and/or tell me how to access it? During the migration we only allowed root login to circumvent any repository inconsistencies. You should now be able to login again as I just removed the AlowUsers rule on orion.archlinux.org mail.archlinux.org will stay on orion until it's migrated to a new machine. Greetings, Jelle van der Waa signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] repos.archlinux.org has been migrated to a new server
On 25/06/2020 23:36, Jelle van der Waa wrote: > Hi all, > > repos.archlinux.org, svn.archlinux.org and rsync.archlinux.org are now > on a new server which has plenty of diskspace for us to continue > packaging for a while (16T free). It seems the script which converts svn to git is broken after the migration. As in the git status won't be updated but there are changes in svn. P.S. I can't figure how to fix it, foutrelis can you take a look? Greetings, Jelle van der Waa signature.asc Description: OpenPGP digital signature
[arch-dev-public] repos.archlinux.org has been migrated to a new server
Hi all, repos.archlinux.org, svn.archlinux.org and rsync.archlinux.org are now on a new server which has plenty of diskspace for us to continue packaging for a while (16T free). Some important notes: The ssh hostkeys changed for repos.archlinux.org which means if you use archco/communityco this will fail without a useful error. So take care of your .ssh/known_hosts. The ssh host keys for gemini/repos.archlinux.org are: # gemini.archlinux.org 1024 SHA256:F1Corf6i2U72yub+CIzzGHLOMVKVnjALh1YHM8gBjxE r...@gemini.archlinux.org (DSA) 256 SHA256:If51DkTftUpDAFz65totgDfTd/ddu/2w/RBZIHtY74U r...@gemini.archlinux.org (ECDSA) 256 SHA256:wUrJYf9+zOpIEUQ3ndgarK0PjzPICa1frmu7mpL4e14 r...@gemini.archlinux.org (ED25519) 3072 SHA256:Rltnuln3bjsHJwVbys/LnYCj7hO6srPoa15JP8QhmlQ r...@gemini.archlinux.org (RSA) https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/docs/ssh-hostkeys.txt#L67 https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/docs/ssh-known_hosts.txt#L31 If anything unexpected happens please either mail arch-dev...@lists.archlinux.org or #archlinux-devops on irc. Greetings, Jelle signature.asc Description: OpenPGP digital signature
[arch-dev-public] Thursday 25th June 14:00 UTC repos.archlinux.org migration
Hi al, On Thursday 25th June at 14:00 UTC work will begin on migrating the following services to a new machine: * repos.archlinux.org * svn.archlinux.org * Arch mirror infrastructure This will impact all packaging and svn activities as those services are not available during the migration period. The services will be migrated to a new server as diskspace is running low on the current server, the migration is expected to take at least four hours. When the migration is successfully completed an email will be send that the services are available and packaging can resume. TLDR: No packaging can be done on the 25th of June starting at 14:00 UTC till the migration is done. Greetings, Jelle
Re: [arch-dev-public] Reproducible builds progress report #3
On 29/05/2020 11:20, Allan McRae via arch-dev-public wrote: > Hi all, > > A quick updated on the progress of reproducible builds. > > You may have noticed a couple of large rebuilds that occurred recently. > These fixed issues of non-reproducible file ordering with old versions > of makepkg. This and other hard work by the team improving our tooling > and fixing packaging issues has resulted in 96% of [core] being > reproducible, and 90% of [extra]. You can see the status of which > packages are reproducible here [1]. > > The remaining packages to fix in [core] are dnssec-anchors, linux, > linux-lts, nss and perl. With the possible exception of perl, these are > in the "hard" basket. There is plans on how to fix the kernel packages, > but that will require some time to sort out. We would be happy for more > people to help out so we can get [core] to 100% reproducible. > > We have investigated some of the packages in [extra] that fail to > reproduce here [2]. Note that there are quite a few packages that > currently "Failed to build from source" (FTBFS) - it would be very > helpful for the reproducible builds team if their maintainers can help > fix the packages. You can also use the CI of Arch packages run by Debian > to get an overview what the issue is with these packages and see many > other packages that are currently failing to build [3]. I would recommend everyone to stop using gitlab to pull patches as the output of the patches changes over time due to the encoding of the git version number. So it's best to just svn add those, Github does not have this issue. > We also need help to investigate and fix the packages that fail to > reproduce that we have not investigated as of yet. There are two easy to > use tools to attempt to reproduce a package - "makerepropkg" from > devtools and "repro" from the archlinux-repro package. Once these have > rebuilt a package, you can use the "diffoscope" tool to look at the > differences. Jump in the #archlinux-reproducible IRC channel if you want > help interpreting the output, or you could just link to a copy of it in > the wiki. All Java packages are unreproducible due to encoding the timestamp of jar files which needs to be resolved upstream in openjdk. Other distributions workaround the problem with a special program which runs after build and strips / fixes timestamps for these files. > [1] https://reproducible.archlinux.org/ > [2] https://wiki.archlinux.org/index.php/Reproducible_Builds/Status > [3] https://tests.reproducible-builds.org/archlinux/extra.html >
[arch-dev-public] Packages spring cleanup!
Hi all, I'm going to disown some packages as I no longer actively use them and I want to shift focus into my on other Arch roles: ettercap openttd-opensfx openttd-opengfx rdesktop tesseract tesseract-* tidy unshield vim-pastie vim-align pstreams pdf2djvu bonnie++ gsmartcontrol leptonica jbigkit pbpst ccd2iso chromium-bsu fsarchiver dot2tex If packages need to be moved to [community] for you to be able to adopt them, please say so. Greetings, Jelle
[arch-dev-public] planet.archlinux.org news proposal
Hi, The new planet.archlinux.org has a different implementation and RSS feed url. I've added fallback urls for two variants of the RSS feed but would like users to switch to the new url so a news post seemed appropriate. News proposal below: # Planet Arch Linux migration The software behind planet.archlinux.org was implemented in Python 2 and no longer maintained upstream. This functionality has now been implemented in archlinux.org's archweb backend which is actively maintained by offers a slightly different experience. The most notable change is the offered feeds and the feed location. Archweb only offers an Atom feed which is located at https://archlinux.org/feeds/planet. signature.asc Description: PGP signature
Re: [arch-dev-public] Archweb update
On 02/14/20 at 09:24am, Andrea Scarpino via arch-dev-public wrote: > On Thursday, 13 February 2020 23:59:17 CET Jelle van der Waa wrote: > > * Implement planet functionality for archweb, to replace > > planet.archlinux.org which is Python 2 and not going to be ported. > > Every user on archweb can configure the website and website_rss urls > > in their profile which will be shown on planet after a systemd service > > pulls the RSS feeds in. [1] [2] > > Hi Jelle, > > what about former developers' blogs? It will be still possible to link theirs > blogs? How? Former developers are usually marked as "inactive" and can't login to archweb. I have not taken into account that we wanted to include former staff and not sure if we want too. Greetings, Jelle van der Waa signature.asc Description: PGP signature
[arch-dev-public] Archweb update
Hi, A new archweb has been deployed with the following notable changes: * Implement planet functionality for archweb, to replace planet.archlinux.org which is Python 2 and not going to be ported. Every user on archweb can configure the website and website_rss urls in their profile which will be shown on planet after a systemd service pulls the RSS feeds in. [1] [2] Note that the implementation is a bit different from a normal planet, since only a limited amount of text is saved in archweb and the HTML is "purified" using python-bleach. It is mostly aimed at aggregating our feeds. * Add new RSS feeds for stable / non stable repos [3] Note that soon planet.archlinux.org will point to archweb and the old planet will die. [1] https://www.archlinux.org/devel/profile/ [2] https://www.archlinux.org/planet/ [3] https://www.archlinux.org/feeds/ signature.asc Description: PGP signature
[arch-dev-public] Archweb update
Hi, A new archweb has been deployed with the following notable changes: * Implement planet functionality for archweb, to replace planet.archlinux.org which is Python 2 and not going to be ported. Every user on archweb can configure the website and website_rss urls in their profile which will be shown on planet after a systemd service pulls the RSS feeds in. [1] [2] Note that the implementation is a bit different from a normal planet, since only a limited amount of text is saved in archweb and the HTML is "purified" using python-bleach. It is mostly aimed at aggregating our feeds. * Add new RSS feeds for stable / non stable repos [3] Note that soon planet.archlinux.org will point to archweb and the old planet will die. [1] https://www.archlinux.org/devel/profile/ [2] https://www.archlinux.org/planet/ [3] https://www.archlinux.org/feeds/ signature.asc Description: PGP signature
Re: [arch-dev-public] Package openvpn in [core]?
On 01/24/20 at 11:27am, Christian Hesse wrote: > Hello everybody, > > currently the package openvpn is located in our [core] repository and it's > like that since the beginning of time. [0] > > Following a discussion on IRC and our definition for official repositories > [1] we think there is no reason to have it there. Thus I would like to move > it (and its dependency pkcs11-helper) to [extra]. > If you have any concern please raise your hand now! Sounds good to me, openvpn is not really installation critical. -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Todos for language specific rebuilds
On 01/11/20 at 09:04am, Anatol Pomozov via arch-dev-public wrote: > Hello > > On Sat, Jan 11, 2020 at 6:58 AM Dave Reisner wrote: > > > > On Fri, Jan 10, 2020, 16:43 Christian Rebischke via arch-dev-public < > > arch-dev-public@archlinux.org> wrote: > > > > > Hi everybody, > > > > > > I would like to propose that we create todos for rebuilds of language > > > specific packages. > > > > > > We had two major rebuilds in the last months: python3.8 and ruby2.7. > > > > > > Can we agree that we create a todo before such rebuilds? > > > The advantages outweigh the disadvantages. We would gain: > > > > > > > Hi, > > > > I'm not sure I understand. Can you clearly state the problems we've > > encountered due to not doing this? What downsides do you see to your > > proposal? Can you think of any alternative solutions? > > > > * More people help rebuilding the packages. > > > > > > > Solving the wrong problem, IMO. This is largely toil and should be > > automated away. > > I agree with every statement that Dave made. Especially with this one. Yes, we should make this rebuilder official in some way and properly document it so multiple people can use it. Some languages however require special treatment such as Haskell and require rebuilds from GHC => Haskell-foo => Haskell-bar etc which can become complicated. For example if I want to update a dependency of taskell I will have to rebuild all depending programs/libs so tooling which makes that easier is welcome to me. I know Felix has some stuff but we should make this more visible. I would propose to document how to rebuild a library/program on the Package Guidelines pages which I plan to do for Haskell after talking with Felix. > We need to automate as much our daily routine as possible. > Scripting/automation > is the only way to keep the increasing complexity of the system under control. Yes! > > As a maintainer, I don't care that you're rebuilding my package to keep up > > with library changes. Rather, I'm thankful to whomever did this for me. > > > > Why would a language rebuild differ from any other soname bump? For Haskell this is the case, but I am not sure if this is unique. > > * Maintainers have the possibility to test the packages. > > Did you have any problems with testing the recent language rebuilds? We have never tested anything in [staging] where rebuilds happen since that's not possible at all since it's always half broken. Testing happens in [testing]. -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Killing Python 2 (v2)
On 01/02/20 at 05:12pm, Jelle van der Waa wrote: > Hi All, > > 2020 happened and Python 2 is very much still alive, even worse there > will be an update in April. Looking at unneeded orphans on archweb we can remove more packages if no one adopts them at the end of the week: [1] * mypaint * oblogout * ocrfeeder [1] https://www.archlinux.org/devel/reports/unneeded-orphans/ P.S. seems it's time for a new year cleanup! -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] cleanup dead Xorg packages
On 12/19/19 at 04:19pm, Andreas Radke via arch-dev-public wrote: > I've created a bug[1] to follow a long overdue Xorg cleanup to drop > legacy and dead code from our packages. This will require fixing > makedepends in a 2nd step. I will do the most work over the next > days/weeks. This all didn't fit well into a single ToDo list. > > If you find more really dead Xorg packages add it please to the bug > tracker with a link to its removal. Use the mailing list for further > discussion if needed when you think a certain feature isn't widely used > and should be dropped as well. > > -Andy > > [1] https://bugs.archlinux.org/task/64892 I just noticed that a lot of packages are not building in our reproducible builds test CI. This is due to the removal of 'xf86dgaproto' and possibly other Xorg related packages. Can we get this fixed? [1] [2] I am all for removing dead packages but breaking building packages is not ok. Seems the Python 2 removal also made people break other packages which are makedepends of another package such as python-pytest-shutil. [3] Please don't do this, you are giving other maintainers extra work by removing their makedepends! [1] https://www.archlinux.org/devel/reports/non-existing-dependencies/ [2] https://tests.reproducible-builds.org/archlinux/state_DEPWAIT.html [3] https://www.archlinux.org/packages/community/any/python-pytest-shutil/ -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Killing Python 2 (v2)
On 01/02/20 at 11:18am, Santiago Torres-Arias via arch-dev-public wrote: > On Thu, Jan 02, 2020 at 05:12:33PM +0100, Jelle van der Waa wrote: > > > For packages still providing python2 functionality such as vim and > > others I propose we remove python2 support to actively to discourage > > people using it. > > I was +1 on this > > > # Remove python2 support > > > > * pycharm-community-edition - remove python2 support > > * vim - remove python2 support > > Until I saw this. > > I imagine editors and such may/could be an exception? So following up from what grazollini and Eli have said, I guess we can keep it for vim, maybe focus more on optdepends and actual makedepends for I've found a lot of gnome packages having a python2 makedepends which can be removed or moved to python 3. Felix brought up a more radical approach of removing check() for python2 modules which would allow a lot of python2 modules to be removed. This is also blocking him from updating packages since he needs to bring new python2 modules in to update some python/python2 modules iirc. Felix, can you enlighten us? I don't want you to be blocked from keeping Arch rolling =) Greetings, Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Killing Python 2 (v2)
On 01/02/20 at 07:09pm, keenerd via arch-dev-public wrote: > On 1/2/20, Jelle van der Waa wrote: > > * armagetronad - dead upstream, optional dep can be removed > > Fixed instead. It still works a treat. Thanks a lot! This was my hidden agenda all along ^_^ I've found many packages which have been building with Python 3 but simply weren't adjusted yet Thanks in advance, Jelle van der Waa signature.asc Description: PGP signature
[arch-dev-public] Killing Python 2 (v2)
Hi All, 2020 happened and Python 2 is very much still alive, even worse there will be an update in April. However we should actively strive to get rid of Python 2 before it. Some upstreams are (still) working on porting to Python 3 such as Kodi, inkscape, mercurial and many more but for packages with dead upstreams and being unrequired I propose we remove them. For packages still providing python2 functionality such as vim and others I propose we remove python2 support to actively to discourage people using it. Dropping non-ported python2 packages: * rox - python2, dead and GTK2 * wifite - upstream dead * shedskin - python2 specific, won't be updated * jmc - dead upstream * pydb - python debugger (python2 specific) * pyrex - dead upstream * mcomix - dead upstream * singularity - dead upstream * pathological - dead upstream * armagetronad - dead upstream, optional dep can be removed * ming - no python2 compatibility * ipcheck - dead upstream * mediaproxy - dead upstream * wicd/wicd-gtk - dead upstream, better alternatives available * sgmltools-lite - dead upstream # Remove python2 support * pycharm-community-edition - remove python2 support * vim - remove python2 support * graphviz - remove python2 bindings or update to python3 * notmuch - switch to python3 bindings * libproxy - remove python2 bindings * many others! Greetings, Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] zstd rollout complete
On 12/27/19 at 07:10pm, Sven-Hendrik Haase via arch-dev-public wrote: > On Fri, Dec 27, 2019, 16:31 Robin Broda via arch-dev-public < > arch-dev-public@archlinux.org> wrote: > > > Hello everyone, > > > > We have just tested and released everything necessary for zstd packages in > > our repos. > > > > Right now, the updated devtools is still in [testing], > > but our preliminary testing shows that nothing immediately combusted on > > release, so I'm confident. > > > > Once it has left testing, packages built with devtools will automatically > > use zstd with the correct options. > > > > There is no intervention necessary, this should be an essentially > > transparent process. > > > > > > Happy packaging and greetings from 36c3. > > > > We found out that the historical archive uploader is broken as python > doesn't have native zstd support in the tarfile package. We're trying to > fix this currently. Sadly tarfile does not support .zst so we need to use xtarfile. But xtarfile does not handle our way of opening package files with tarfile. [1] The xtarfile_open method raises a NotImplementedError since it seemingly does not handle 'r|*' while 'r' works thanks to svenstaro's patch. [2] Further digging around by removing the '|*' and "encoding='utf-8'" seems to actually make it workable.. [3] I'll check if I at least can get it working again... [1] https://github.com/archlinux/arch-historical-archive/blob/master/upload_pkg_internetarchive.py#L42 [2] https://github.com/ascoderu/xtarfile/blob/master/xtarfile/xtarfile.py#L30 [3] https://github.com/ascoderu/xtarfile/issues/3 signature.asc Description: PGP signature
Re: [arch-dev-public] Python 2 modules
On 02/16/19 at 11:19am, Allan McRae via arch-dev-public wrote: > Hi all, > > Python 2 reaches End of Life on 2020-01-01. We currently have >950 > python2 modules in the repos. A lot of these are not used by any other > package in the repositories. I think we should work towards removing them. I've just updated the todolist for the unneeded python2 module removal with data from archweb since the list lacked a lot of packages. Everyone who has archweb with all repos importd can run the following to get a list of packages which require python2 but aren't required by anything else. from main.models import Package pkg = Package.objects.filter(pkgname='python2').first() for repopkg in pkg.get_requiredby(): if not repopkg.pkg.get_requiredby(): print(repopkg.pkg) -- Jelle van der Waa > > Leaving only python2 modules that are really required by other software, > highlights what needs worked on to port to python3. > > Note Fedora is doing a similar removal for F30: > https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal > > What are opinions on this? Should I make a TODO list? > > > Below is a list of python2 modules that are a dependency for any other > package. I did not check makedepends and I did not check recursively to > build this list. > > python2-acme > python2-antlr2 > python2-anyjson > python2-anytree > python2-apache-libcloud > python2-apispec > python2-argcomplete > python2-argon2_cffi > python2-argparse > python2-args > python2-arrow > python2-aspectlib > python2-astor > python2-atspi > python2-aubio > python2-audit > python2-augeas > python2-autobahn > python2-autopep8 > python2-backports.lzma > python2-basemap > python2-betamax-matchers > python2-betamax-serializers > python2-binary-memcached > python2-biopython > python2-bitvector > python2-blist > python2-blosc > python2-bluepy > python2-bottle > python2-bottleneck > python2-braintree > python2-breathe > python2-bsddb > python2-btchip > python2-btrees > python2-cached-property > python2-caja > python2-cchardet > python2-celery > python2-chai > python2-chameleon > python2-characteristic > python2-cjkwrap > python2-click-log > python2-click-threading > python2-cloudflare > python2-cmarkgfm > python2-colander > python2-colorclass > python2-configargparse > python2-construct > python2-couchdb > python2-cram > python2-crayons > python2-cryptography-vectors > python2-cson > python2-cssselect2 > python2-cssutils > python2-cx_freeze > python2-d2to1 > python2-daemon > python2-daemonize > python2-datrie > python2-ddt > python2-digitalocean > python2-discid > python2-distutils-extra > python2-django > python2-dnslib > python2-dockerpty > python2-docopt > python2-docs > python2-doublex-expects > python2-dpcontracts > python2-dropbox > python2-editdistance > python2-egenix-mx-base > python2-elasticsearch-curator > python2-email-validator > python2-envisage > python2-eric > python2-ethtool > python2-evdev > python2-exam > python2-exiv2 > python2-eyed3 > python2-factory-boy > python2-fastpbkdf2 > python2-faulthandler > python2-flake8-blind-except > python2-flake8-debugger > python2-flaky > python2-flask-gravatar > python2-flask-htmlmin > python2-flask-jwt > python2-flask-mail > python2-flask-migrate > python2-flask-paranoid > python2-flask-restful > python2-flask-security > python2-flask-socketio > python2-flask-talisman > python2-flask-wtf > python2-flexmock > python2-flickrapi > python2-flup > python2-fonttools > python2-foolscap > python2-fpconst > python2-freezegun > python2-fs > python2-funcy > python2-furl > python2-fxa > python2-gasp > python2-gcp-devrel-py-tools > python2-gdal > python2-gdata > python2-genshi > python2-genty > python2-geoip > python2-gevent-websocket > python2-gflags > python2-gitpython > python2-gnupg > python2-gnupginterface > python2-gnuplot > python2-gpgme > python2-grequests > python2-gtkspellcheck > python2-gudev > python2-h2 > python2-h5py > python2-h5py-openmpi > python2-hacking > python2-harparser > python2-helper > python2-hexdump > python2-hglib > python2-httpretty > python2-hunter > python2-hypothesis > python2-i3-py > python2-ibm-db-sa > python2-icalendar > python2-igraph > python2-importlib_resources > python2-inet_diag > python2-invoke > python2-iocapture > python2-ipdb > python2-irc > python2-isomd5sum > python2-iwlib > python2-jieba > python2-js2py > python2-jsbeautifier > python2-json-logger > python2-jsonrpclib-pelix > python2-kaitaistruct &
Re: [arch-dev-public] [arch-devops] soyuz (pkgbuild.com) server move to homedir.archlinux.org
On 11/18/19 at 09:06am, Sven-Hendrik Haase via arch-devops wrote: > On Mon, 18 Nov 2019 at 09:00, Konstantin Gizdov wrote: > > > Sounds good. One question - where do we move our email aliases? > > > > Not quite sure what you mean. All email is still being handled by apollo > unless I'm mistaken and soyuz had more duties than I thought. In the latter > case, we should migrate that to apollo. Could anyone shed some light on > this? All mail is handled by mail.archlinux.org (orion), not by pkgbuild.com or apollo. Nothing changes in this regard. -- Jelle van der Waa signature.asc Description: PGP signature
[arch-dev-public] Looking for an Arch ISO maintainer
Hi all, Gerardo has stepped down as Arch ISO maintainer, which makes archiso unmaintained. I've asked Pierres if he was interested in maintaining the project and he is willing to do bug fixes when required but no major maintenance. Which means that we are looking for a new maintainer :-) To be completely honest, I am not sure what maintenance archiso requires but there are a few things I would love to see: - Proper CI / automated testing of the archiso - Reproducible archiso (patches on the mailing list) [1] - Support secure boot [2] - Accessibility improvements (patches available on the mailing list) [3] Please reply if you are interested in becoming an archiso maintainer, so far Alad has shown interested. [1] https://bugs.archlinux.org/task/63683?project=6 [2] https://bugs.archlinux.org/task/53864?project=6 [3] https://bugs.archlinux.org/task/63166?project=6 -- Jelle van der Waa signature.asc Description: PGP signature
[arch-dev-public] new archweb release
Hi all, A new archweb release has been deployed on our server, with a couple of notable changes: - Signoff status has been moved up in the Developer Dashboard for more attention - When enough signoffs are reached, archweb automatically sends a mail to the packager that the package has reached the target signoffs! If this is too spammy we can consider a "daily" report. In the future release, I aim to improve onboarding of testers and further investigate where the lack of signoffs comes from. So far it seems we have around ~ 18 "active" testers. signature.asc Description: PGP signature
[arch-dev-public] Database maintenance affecting AUR & BBS
Hi all, Luna requires some database maintenance to improve the stability of MySQL. This will affect the AUR and the BBS (forums) which will be down for some time to dump and import the aur and bbs database. It is expected that this will take an hour at max. Maintenance will shall start today at 12:00 UTC. -- Jelle van der Waa signature.asc Description: PGP signature
[arch-dev-public] Archweb updates
Hi all, In the latest archweb release on our website there is a new report called "non existing dependencies" which shows packages with missing (opt|check|make)depends these should be fixed. [1] Apart from that, the signoff overview page on /devel now shows the packager and maintainer which can be useful for rebuilds. [2] [1] https://www.archlinux.org/devel/reports/non-existing-dependencies/ [2] https://www.archlinux.org/devel/ -- Jelle van der Waa signature.asc Description: PGP signature
[arch-dev-public] Unmaintained packages from Dan
Hi all,
We have some packages which used to be maintained by toofishes which he
no longer seems to take care of. So if anyone is willing to maintain
these packages, please adopt them, if they need to be moved to
[community] for a TU, ping me. The packages are:
* munin{,-node}
* numactl
* irqbalance
* cvsps
* csope
* nilfs-tools (I added myself as co-maintainer but I don't really use
it)
Also look at the bugtracker for old bugs, munin for example has a bunch
signature.asc
Description: PGP signature
[arch-dev-public] FroSCon 2019
Hi Archers, This there is another FroSCon 2019 organized! Last year we had a dev room on sunday and two talks, if enough dev/tu/community members want to hold a talk then I can organize a room again :-) [1] https://www.froscon.de/en/cfp/ -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Archweb migration
On 02/07/19 at 10:22pm, Jelle van der Waa wrote: > Hi All, > > Tommorow night (CET) I will update archweb (archlinux.org) to Python 3. > We've already tested it on a staging server and it seems to work well so > tommorow I'll update it on our main server. > > This will mean that archlinux.org will be unavailabe for ~ 30 minutes > since the upgrade requires some manual work with removing and creating a > new virtualenv. Well, that didn't take 30 minutes, but more like < 5 min. website updated. Please report any issues you encouter, one issue is already known Signed by lists unknown, see: https://www.archlinux.org/packages/testing/x86_64/kmod/ Note, that since the code is now Python 3, more updates will come such as CSP, 2 FA logon and hopefully automatic out of date checking. -- Jelle van der Waa
[arch-dev-public] Archweb migration
Hi All, Tommorow night (CET) I will update archweb (archlinux.org) to Python 3. We've already tested it on a staging server and it seems to work well so tommorow I'll update it on our main server. This will mean that archlinux.org will be unavailabe for ~ 30 minutes since the upgrade requires some manual work with removing and creating a new virtualenv. -- Jelle van der Waa
[arch-dev-public] Improving overall experience for contributors follow up
Hi, I still believe we should take some initiative on thse issues. What we have so far is: - Getting involved page, not sure where it's linked from? Only findable on the wiki. [1] Which links to a nice list of projects with an already dedicated irc channel and mailing lists. (I was not even aware of #archlinux-projects). But does anyone ever find this page? I think we should at least link it from archlinux.org. - The mozilla idea, I'm up for it? Should we host it under whatcanidofor.archlinux.org? Note that this also requires some effort from the team's side. We should however keep our bugtracker tidy and maybe label "new contributor" tickets since this is quite crucial to get new people in. I however have also some thoughts on things which these days have no tickets, but could be worked on for example: - revamping the Ruby guidelines. They should be as nice as the Python ones - Hardening our custom systemd services and creating bugs with patches, for example grafana has hardening applied now. [5] - Man pages for more devtools binaries. I'm quite sure others others have such projects on their mind which are not publicly findable yet. (sogrep to devtools for example) [1] https://wiki.archlinux.org/index.php/Getting_involved [2] https://wiki.archlinux.org/index.php/DeveloperWiki:Projects [3] https://github.com/archlinux/archweb/issues [4] https://github.com/archlinux/pyalpm/issues [5] https://git.archlinux.org/svntogit/community.git/tree/trunk/grafana.ser= vice?h=3Dpackages/grafana P.S. sorry for splitting up into a new thread, but it seems replying makes spamassasian mark my reply to the thread as spam. -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Improving overall experience for contributors
On 05/23/17 at 10:23pm, Bartłomiej Piotrowski wrote: > > 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. I still believe we should take some initiative on thse issues. What we have so far is: - Getting involved page, not sure where it's linked from? Only findable on the wiki. [1] Which links to a nice list of projects with an already dedicated irc channel and mailing lists. (I was not even aware of #archlinux-projects). But does anyone ever find this page? I think we should at least link it from archlinux.org. - The mozilla idea, I'm up for it? Should we host it under whatcanidofor.archlinux.org? Note that this also requires some effort from the team's side. We should however keep our bugtracker tidy and maybe label "new contributor" tickets since this is quite crucial to get new people in. I however have also some thoughts on things which these days have no tickets, but could be worked on for example: - revamping the Ruby guidelines. They should be as nice as the Python ones - Hardening our custom systemd services and creating bugs with patches, for example grafana has hardening applied now. [5] - Man pages for more devtools binaries. I'm quite sure others others have such projects on their mind which are not publicly findable yet. (sogrep to devtools for example) [1] https://wiki.archlinux.org/index.php/Getting_involved [2] https://wiki.archlinux.org/index.php/DeveloperWiki:Projects [3] https://github.com/archlinux/archweb/issues [4] https://github.com/archlinux/pyalpm/issues [5] https://git.archlinux.org/svntogit/community.git/tree/trunk/grafana.ser= vice?h=3Dpackages/grafana signature.asc Description: PGP signature
Re: [arch-dev-public] Arch Conf
Hi All, On 12/06/18 at 08:35pm, David Runge wrote: > Fellow Archers! > > Some of us (in #archlinux-conf) are thinking of organizing an event for > our community: A new Arch Conf! Yay! > We would like to do a conference (earliest in the 2nd half of 2019), > that concentrates on our internal community: The developers, trusted > users and support staff. > Most of us have never met in real life, which would in itself be quite > nice to change. However, we also have many issues and challenges to > tackle in Arch Linux. > Doing a dedicated conference (in the scope of two days) again [1] seems > to be a good starting point! I'm all for organizing a conf. One of the steps we should take as follow up is probably gather how many people would be interested. Since it probably does not make a lot of sense to gather a list of interested TU's/Dev's/Support Staff as well as required travel funds. > As many of us live somewhere in central Europe, countries such as > Germany have been taken into consideration. > We looked at some free and paid locations in Berlin and Hamburg and > Delft (The Netherlands), but nothing is decided yet. > > We are currently trying to figure out options for sponsorship, as we > would also like to be able to (help) fly in developers from further away > (without compromising). > For this we would like to get more input from you. I really want to see a lot of attendees from our team, which would mean getting a lot of travel funds. Since some of us are further away from Europe :) This wouldn't be doable without getting sponsors, does anyone have an idea on getting sponsors, handling donations? I believe debconf set's up a separate SPI account for it. > We were thinking of involvement for topics e.g. from the DevOps and > security teams, but also more broad subjects, such as package > repositories, bug tracker, wiki, etc. This would be a real opportunity to tackle some interesting issues, such as our Git migration, bug tracker migration and sharing information. > An Arch Conf will of course not only require involvement in the form of > presentations and workshops, but volunteers to help prepare and handle a > potential location and the event itself. > Also, there should be video streaming (e.g. the VOC [2] offers free > services for free software conferences) for those that can't be there. > > We would like to get some input from all of you regarding time, space > and scope :) > > [1] > https://web.archive.org/web/20130313105945/http://www.archlinux.ca/archcon2010/ > [2] https://c3voc.de/ > > -- > https://sleepmap.de -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Bug Day
On 12/02/18 at 04:32pm, Santiago Torres-Arias via arch-dev-public wrote: > > I propose we hold another (in)famous bug day on the first weekend of > > January > > i.e. 5th and 6th of January. To start the new year with a cleaned up bug > > tracker. > > +1. I love the idea. > > I'll reserve both days to help with it* > > (Also, implicit here, are TU's part of this plan?) Yes, community has about 575 open tasks, where the longest bugs are from 2014-02-04. In my opinion everyone should be able to participate in fixing these bugs. Especially ancient ones otherwise these bugs can be reproduced, patches made and submitted to the tracker :) -- Jelle van der Waa signature.asc Description: PGP signature
[arch-dev-public] Bug Day
Hi All, I propose we hold another (in)famous bug day on the first weekend of January i.e. 5th and 6th of January. To start the new year with a cleaned up bug tracker. -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Rebuilding old packages (2016)
On 11/10/18 at 08:15pm, Eli Schwartz via arch-dev-public wrote: > On 11/9/18 5:29 PM, Jelle van der Waa wrote: > > On 11/09/18 at 10:54pm, Jelle van der Waa wrote: > >> Hi all, > >> > >> There are rebuilds ongoing for packages build before 2017-01-01, this > >> *should* add PIE and the newer BUILDINFO format to these old packages. > >> And uncovers some build failures, which should be fixed and I will make > >> a todolist for. > > > > Fake news, we are rebuilding everything before 2017-08-01! > > We more or less need to rebuild everything since 2018-09-11 because svn > propsets aren't reproducible no matter what BUILDINFO format you use. :p Sure, but we do things in batches. My current goal is first see how far we can come with PIE. When we really have something official for reproducing our packages, we should indeed fix those packages. -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Rebuilding old packages (2016)
On 11/09/18 at 10:54pm, Jelle van der Waa wrote: > Hi all, > > There are rebuilds ongoing for packages build before 2017-01-01, this > *should* add PIE and the newer BUILDINFO format to these old packages. > And uncovers some build failures, which should be fixed and I will make > a todolist for. Fake news, we are rebuilding everything before 2017-08-01! -- Jelle van der Waa signature.asc Description: PGP signature
[arch-dev-public] Rebuilding old packages (2016)
Hi all, There are rebuilds ongoing for packages build before 2017-01-01, this *should* add PIE and the newer BUILDINFO format to these old packages. And uncovers some build failures, which should be fixed and I will make a todolist for. Note, that we still not have PIE for everything :-( Packages without PIE are listed here, note that Haskell will require some research to enable PIE. Golang/Rust packages also require special treatment. [1] [1] http://pkgbuild.com/~jelle/repro_sec_status.txt -- Jelle van der Waa signature.asc Description: PGP signature
[arch-dev-public] Away for two weeks
Hi all, I'll be away for two weeks without a laptop so I won't be able to do any packaging. Feel free to update my packages or fix my open bugs ^_^ If there is something really urgent, I should be able to reply via e-mail. -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] [RFC] Remove svn propset id's
On 09/04/18 at 08:54pm, Jelle van der Waa wrote: > On 08/29/18 at 10:23pm, Jelle van der Waa wrote: > > Most of our PKGBUILDs svn propset's break reproducible builds and the > > pkgbuild_sha256sum in the BUILDINFO file. When building a package before > > commiting the PKGBUILD the propset $Id will differ since the $Id is set on > > commit. > > So far, I've only gotten positive reactions. If no one objects I propose > to remove the propsets treewide after a week, so everyone has time > enough to object. Removal will be done as following: > > $ sed -ri '/\$Id/d' */trunk/PKGBUILD > $ svn propdel svn:keywords */trunk/PKGBUILD The propsets have been removed from both community and packages. We can now continue the reproducible build effort knowing that the PKGBUILD hash in trunk and in BUILDINFO matches :) -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] [RFC] Remove svn propset id's
On 08/29/18 at 10:23pm, Jelle van der Waa wrote: > Most of our PKGBUILDs svn propset's break reproducible builds and the > pkgbuild_sha256sum in the BUILDINFO file. When building a package before > commiting the PKGBUILD the propset $Id will differ since the $Id is set on > commit. So far, I've only gotten positive reactions. If no one objects I propose to remove the propsets treewide after a week, so everyone has time enough to object. Removal will be done as following: $ sed -ri '/\$Id/d' */trunk/PKGBUILD $ svn propdel svn:keywords */trunk/PKGBUILD -- Jelle van der Waa signature.asc Description: PGP signature
[arch-dev-public] [RFC] Remove svn propset id's
Most of our PKGBUILDs svn propset's break reproducible builds and the pkgbuild_sha256sum in the BUILDINFO file. When building a package before commiting the PKGBUILD the propset $Id will differ since the $Id is set on commit. This has a few implications, pkgbuild_sha256sum is useless and we can't reproduce packages due to the BUILDINFO not matching. Also the reproduce tool uses ASP to retrieve the PKGBUILD and therefore can't verify that it got the correct PKGBUILD (it relies on pkgbuild_sha256sum). To resolve this issue we could simply remove the propset id's, since for me, although not sure about others they don't seem particulary useful. The proof that the sha256sums's don't match: $ extra-x86_64-build $ grep sha256 .BUILDINFO pkgbuild_sha256sum = 8748d60d2c782f477cb7e692a3dad30be90491cdc13fe8951340da4c0bc7f19e $ $repopkg $ sha256sum PKGBUILD d8ab51a983026dd4a6e2f48e9dc66177eca8cf6c1c0ffefb950b093db299e304 PKGBUILD # The git checkout [jelle@helium][/tmp/bar/community/python-psutil/trunk]%sha256sum PKGBUILD ce7f1e68a3b426412a24f46016817d30721860c8ef6b3d0a2dddac8ff2448b84 PKGBUILD [jelle@helium][/tmp/bar/community/python-psutil/trunk]%diff PKGBUILD /tmp/python-psutil/trunk/PKGBUILD 1c1 < # $Id$ --- > # $Id: PKGBUILD 375007 2018-08-28 17:24:26Z jelle $ -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] /r/linux AMA
On 08/09/18 at 06:41pm, Morten Linderud via arch-dev-public wrote: > Yo! > > The subreddit /r/linux have started organizing AMA threads for relevant > projects. Gentoo had one of these a few months ago and is an interesting read. > > https://www.reddit.com/r/linux/comments/8nsdj0/we_are_gentoo_developers_ama/ > https://www.reddit.com/r/linux/comments/93qlow/established_project_developer_team_member_flairs/ > > I think it's a good idea Arch Linux does an AMA as it's might give users some > incentive to help contributing to the project. I have chatted with a subreddit > mod at /r/linux, and the AMA should preferably start on any Monday from 27th > and > onwards. It will also run for a few days, so there is no need to be present > all > the time, or when it starts. > > > If you are interested participating please reply to the list with the > following > information: > > * Reddit username. > * What you do. > * What Monday fits for you? * jvdwaa * Developer, Security Team, DevOps, Reproducible builds, Archweb maintainer * Most mondays -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Automatic Signing of ISOs, pacman databases and everything else (was: Arch Linux Cloud Images (virtualbox and Qemu))
On 05/15/18 at 05:43pm, Bruno Pagani via arch-dev-public wrote: > Le 15/05/2018 à 17:25, Florian Pritz via arch-dev-public a écrit : Just going to necro-bump this thread, since we didn't arrive at a conclusive descision. > > > On 13.05.2018 22:47, Christian Rebischke via arch-dev-public wrote: > >> 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? > > We had that discussion some years ago about signing our pacman > > databases. I mostly remember that we didn't reach a consensus, but you > > might want to search the archives for details. At some point there was a > > proposal to have a dedicated signing host that is well protected and > > receives files and then returns the signature. I'm not sure if that was > > turned down or if there was simply nobody to work on this. Does anyone > > remember that? > > > > I think this would be a viable option for us. We could also implement > > some form of rate limiting and sanity checks to ensure we only sign > > things that we want to sign. For example, only one ISO can be signed per > > month and the request must come from a specific IP. I probably won't do > > any implementation, but I'd offer to provide feedback and design help if > > someone wants to work on this. Assuming we first agree that we want to > > do it this way. I believe this solution is the way to go. > To me this is quite a good idea. :) > > I had a bit more sophisticated design in mind, where the signing host > /retrieves/ the file to be signed (so that the connection is initiated > from it, not toward it) by having the filename added to some text file > on an other (almost?) dedicated host (so that having access to the hosts > where the DB/iso/whatever are built is not enough and vice-versa, see > just after), text file that the signing host would be watching a way or > another (but should be in an authenticated way). Of course you need to > restrict what kind of files can be retrieved from what host (like you > proposed for the request coming from a specified IP). > > The goal of this setup is to have no open port on the signing host, > requiring physical/IPMI access to it to make any change. > > But maybe that does not bring much more than your setup, while adding > much more complexity… > > Just as you, I cannot help on implementing, but I can offer ideas and > design feedback if anyone want to take this task in charge. That sounds rather complicated, since we also wants this for the repo db as well. I wonder if we use the proposed method but restrict access not only source ip but also on the user who can make the request? On a seperate note, I don't believe the signing issue is new I know that Fedora and OpenSuSe have both signing solutions. For the OpenSuse Build Service, they have a daemon called obs-signd. [1] Their solution is a sperate machine with a port open for their signing daemon. I'm not sure how they resolve the don't sign any arbitrary file problem. For Fedora I couldn't find any information, I've reached out to a Fedora Dev for some more information. The only thing I can find is a proposal. [2] Maybe we should create a wiki page for signing the repository DB and ISO's. So we can list all the benefits and downsides along with the threat vector. [1] https://en.opensuse.org/openSUSE:Build_Service_Signer [2] https://fedoraproject.org/wiki/Koji_Build_Autosign_Proposal -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] proposal to add "aurpublish" to community
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 signature.asc Description: PGP signature
Re: [arch-dev-public] proposal to add "aurpublish" to community
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. -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] FrOSCon Arch Linux DevRoom
On 06/17/18 at 10:29pm, Jelle van der Waa wrote: > On 06/17/18 at 07:09pm, Pierre Schmitz wrote: > > I could do a talk I guess. Do you know till when we have to create our > > program to get it on the Froscon schedule? > > Yup, qouting the mail I received: > > > You are free to plan your own program, however if you offer talks or > > workshops we strongly encourage that you follow the schedule of the > > main program. This was a wish of our guests in the last years. The > > schedule is attached to this mail. > > > If you would like your program to appear in your online schedule, you > > need to enter the talks into our conference system Frab. > > So far I have two other Developer/Tu's who might be able to give a talk > and with you and myself included that will be 4 talks. 4 talks of 30 > minutes + ~ 15 minute break. If you want to give a talk, please contact me, I can now add them to Frab. Or write a proposal here! https://wiki.archlinux.org/index.php/User:Jelly/Froscon -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Removing 'orphan' python2 modules
On 06/27/18 at 10:37pm, Bruno Pagani via arch-dev-public wrote: > Le 27/06/2018 à 21:51, Antonio Rojas via arch-dev-public a écrit : > > >> Please reply if you have objections. > >> A list of modules / programs can be obtained as following or viewed here > > That list doesn't take makedepends/optdepends into account. There are a few > > optdepends of sagemath there (pkgconfig, pynormaliz) > > That, as well as actual program (sonata). I did not go through the whole > list, they were too many false positives from the start. The list is just quickly made up, the idea is to get rid of as many python2 orphans as possible. No required/makedepends/programs should be removed, but please check for the programs on the list if there is a Python 3 equivalent. -- Jelle van der Waa signature.asc Description: PGP signature
[arch-dev-public] Removing 'orphan' python2 modules
Hi All, Our repository contains a lot of python2 modules which are required by any package in the repository. I'd like to propose to remove these modules pre-emptively since they serve no purpose and python2 is dead. We should strive to be a modern distro, so promoting Python3 should be a big part of it :) Please reply if you have objections. A list of modules / programs can be obtained as following or viewed here [1] $ pacman -Sqs python2 > list $ expac -S '%n %N' -l ' ' - < list | awk NF==1 [1] http://pkgbuild.com/~jelle/python2_modules.txt -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] [core] / [extra] cleanup
On 06/23/18 at 10:57pm, Felix Yan via arch-dev-public wrote: > On 06/23/2018 10:37 PM, Doug Newgard via arch-dev-public wrote: > >>>> *Remove* > >>>> - pcmciautils - Ancient technology > >>> > >>> Felix moved it to [extra], not sure why? So removed it from [core] > >> > >> Was a mistake when trying to rebuild for the BUILDINFO todo. Sorry for > >> that. > >> > > > > And two and a half weeks later and it's still there? > > I'm still waiting for a conclusion of original proposal, the other > packages are still not removed either. Since no one replied with objections, I guess we can start cleaning up the repo. -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] FrOSCon Arch Linux DevRoom
On 06/17/18 at 07:09pm, Pierre Schmitz wrote: > I could do a talk I guess. Do you know till when we have to create our > program to get it on the Froscon schedule? Yup, qouting the mail I received: > You are free to plan your own program, however if you offer talks or > workshops we strongly encourage that you follow the schedule of the > main program. This was a wish of our guests in the last years. The > schedule is attached to this mail. > If you would like your program to appear in your online schedule, you > need to enter the talks into our conference system Frab. So far I have two other Developer/Tu's who might be able to give a talk and with you and myself included that will be 4 talks. 4 talks of 30 minutes + ~ 15 minute break. > On Sun, Jun 10, 2018 at 4:25 PM, Jelle van der Waa wrote: > > Hi all, > > > > I've managed to get a room for Arch Linux on the Sunday of FrOSCon. > > FrOSCon is a conference ran for a weekend at 25th and 26th August in > > Bonn-Rhein-Sieg. It's a free event thanks to all the sponsors. > > > > We are free to plan our own program on Sunday, however it would be great > > if we could give some talks or a workshop. Since I'm not sure how much > > of the TU/Dev's can attend, community members are also welcome to mail > > me with an proposal for a talk! > > > > P.S. I'll hope to bring Arch stickers. > > > > -- > > Jelle van der Waa -- Jelle van der Waa signature.asc Description: PGP signature
[arch-dev-public] FrOSCon Arch Linux DevRoom
Hi all, I've managed to get a room for Arch Linux on the Sunday of FrOSCon. FrOSCon is a conference ran for a weekend at 25th and 26th August in Bonn-Rhein-Sieg. It's a free event thanks to all the sponsors. We are free to plan our own program on Sunday, however it would be great if we could give some talks or a workshop. Since I'm not sure how much of the TU/Dev's can attend, community members are also welcome to mail me with an proposal for a talk! P.S. I'll hope to bring Arch stickers. -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] [core] / [extra] cleanup
On 02/06/18 17:06, Jelle van der Waa wrote: > Looking at the packages in the BUILDINFO rebuild list, I've found some > packages which are so old that they might not longer suit [core] or our > repos in general. So I'd like to propose that we either move or remove > the following packages: > > *Remove* > - pcmciautils - Ancient technology Felix moved it to [extra], not sure why? So removed it from [core] > - speedtouch - If you are using a linux kernel >= 2.6.10 , you should > use the kernel module instead. Removed. > - bootchart - Replaced by systemd-bootchart > - zd1211-firmware - really really old WiFi chip. Move to [extra] or > remove > - linux-atm - Not sure what this is, but looks old. > > *Move to [extra]* > > - ifenslave - Don't see why it is required in core, also orphan > - libgssglue/librpcsecgss - move to extra, nothing in [core] deps on it. > (archboot and nfs-utils used to dep on it) > - b43-fwcutter - Is this still required for more recent broadcom cards?
[arch-dev-public] [core] / [extra] cleanup
Looking at the packages in the BUILDINFO rebuild list, I've found some packages which are so old that they might not longer suit [core] or our repos in general. So I'd like to propose that we either move or remove the following packages: *Remove* - pcmciautils - Ancient technology - speedtouch - If you are using a linux kernel >= 2.6.10 , you should use the kernel module instead. - bootchart - Replaced by systemd-bootchart - zd1211-firmware - really really old WiFi chip. Move to [extra] or remove - linux-atm - Not sure what this is, but looks old. *Move to [extra]* - ifenslave - Don't see why it is required in core, also orphan - libgssglue/librpcsecgss - move to extra, nothing in [core] deps on it. (archboot and nfs-utils used to dep on it) - b43-fwcutter - Is this still required for more recent broadcom cards? -- Jelle van der Waa signature.asc Description: PGP signature
[arch-dev-public] Archweb (archlinux.org) upgrade
Hi all, Tommorow evening we will be updating https://archlinux.org (archweb), so expect some downtime due to upgrading. Since it's a major version bump 1.8 => 1.11 some issues might occur, but in general it should be a smooth upgrade (tm). P.S. Next up is porting archweb to Python 3, any help is appreciated! -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Arch Linux Docker / Vagrant: Current situation
On 01/29/18 at 12:31pm, Santiago Torres-Arias via arch-dev-public wrote: > Hi, > > Sorry I've been quite sick (to the point of barely having energy to look > at the computer). I'm back on my feet now though :) > > > > Sangy/Santiago[3] was so nice to speak with the docker guys. They said > > > they would approve our docker image and we could move it to the other > > > official images[4]. But for this we need to do some changes on our > > > docker repository on github. (As long I understood sangy correct it > > > would be just some new branches). > > > > Can you actually give more details how it's going to look like? > > > > The official images projects info is on [1] and [2] if you want to read > more in-depth/updated information. I'll summarize here though: > > 1) A TU/Arch Linux "affiliate" submits a PR to the official images > repository, which basically contains the following: > 1. A tag name/image name > 2. A sha256/ref of a commit/tag containig the image's information on > *another* repository (in this case, our official dockerr image repo) > 3. Image building instructions. A PR to this repository is also required, not sure if you mentioned it :) [1] -- Jelle van der Waa [1] https://github.com/docker-library/docs signature.asc Description: PGP signature
Re: [arch-dev-public] Arch Linux Docker / Vagrant: Current situation
On 01/20/18 at 08:19pm, Christian Rebischke via arch-dev-public wrote: > Hello Everybody, > It's now over a half year ago that I've started working together with > sangy and pierre on our vagrant and docker images. I would like to give > you a short update on this topic. > > > The Arch Linux Vagrant images are currently be build for libvirt and > virtualbox. We have over 3800 downloads at the moment and slowly > catching up to the community based arch linux vagrant images.[1] > > My first goal has been to add some hypervisors, but due to > the fact that we have only libvirt and virtualbox in our repositories I > have dismissed this plan. Sounds good enough, this is also easier to manage. > The automated build process works fine so far > (except some issues with qemu[2] and the dependency on punctual iso > releases on soyuz. The latter should we definitly fix. Currently the iso > images are build manually. Can we automate this somehow? I really rely > on punctual releases otherwise the automated build will fail and > somebody needs to trigger the build again manually. Happened about 1-2 > times..) I'm all for automatic builds, and the improvement where multiple people know how the ISO's are build & released. How would we however sign these builds? And is the bootstrap image also generated in the same manner? > The other topic is the docker image. Has anybody of you contact to > pierre? He doesn't answer my mails and he is the only one with access to > the repository on github. I or others can grant write access to the repository, see the owners on the Github organization. I would however first want to ask pierres about it since he irregurarly is on IRC. Are these docker builds going to be automated as well btw? Oh and testing images :-) > Sangy/Santiago[3] was so nice to speak with the docker guys. They said > they would approve our docker image and we could move it to the other > official images[4]. But for this we need to do some changes on our > docker repository on github. (As long I understood sangy correct it > would be just some new branches). This would be nice, how do we share the credentials to the docker login though? Or can we make multiple people owners? [1] https://github.com/orgs/archlinux/people -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] 2017 repository cleanup
On 12/18/17 at 10:47am, Gaetan Bisson via arch-dev-public wrote: > [2017-12-18 10:54:37 +0100] Bartłomiej Piotrowski via arch-dev-public: > > - tclap: > > bisson: hugin > > I've just orphaned hugin too. Happy adopting! :) Gotta catch them all! -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Switching the bugtracker to Bugzilla
On 11/16/17 at 02:01pm, Morten Linderud wrote: > On Tue, Nov 14, 2017 at 08:30:21PM +0100, Jelle van der Waa wrote: > > [snip] > > # Products > > > > * Arch packages (core/extra or split this up) > > * Community packages (community) > > * Pacman > > * AURWeb > > * Keyring > > * Archweb (new) > > * Arch VM / Docker images (new) > > * Release engineering > > > > I think core and extra should be split up. There is also some work being done > to > help the communication between the testers, currently discussed at > #archlinux-testing. I propose another component could be `testing` that > encompasses bugs found from testing, community-testing and multilib-testing. > > It would make be a lot simpler for testers and others using the testing repos > to > find bugs and issues holding back package releases. Sounds good, I intent to start with a small PoC. But migration is a little bit more troublesome now, since I used an old db for conversion while the flyspray db changed it's schema. -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Switching the bugtracker to Bugzilla
On 11/15/17 at 09:07am, Lukas Fleischer wrote: > On Tue, 14 Nov 2017 at 20:30:21, Jelle van der Waa wrote: > > It's time to switch our to something which is maintained and can be > > extended to > > our wishes. Flyspray isn't actively maintained, has had several security > > issues [1] [2]. > > [...] > > Great! Thanks! Most of the credit goes to Bluewind for coming up with the idea and poking me about the status ;-) Note that Bugzilla, also has an REST API, which unlocks some more possibilities. > > > # Migration > > > > There are several options for migrating the bug history to Bugzilla and a > > few options are under > > debate. (input welcome) > > > > * No migration at all > > * Migrate open bugs > > * Migrate open bugs and auto-closing them > > * Migrate all bugs > > * Migrate all bugs and auto-closing them > > > > In either case, I believe it would be nice to "archive" the current > > bugtracker and make it read > > only. > > Doing no migration and having an archive of the current tickets sounds > like a good idea to me -- I can only talk about the aurweb project and > the packages projects, though -- maintainers of other components might > disagree. Ok, but it seems Allan would love to migrate all of his bugs, so we could see if that would be possible for aurweb as well. The biggest migration would be for packages. > After the migration, I would go through the open aurweb tickets on the > Flyspray archive, create new tickets for the most important issues > (should not be more than 10), fix/implement some of the easy stuff and > close the tickets which I think are not worth fixing or implementing. > > # User migration > > > > User migration should be possible as well, except migrating the password, a > > mass password reset > > would be wise. Since I'm not sure what kind of old hashing method / salt > > flyspray uses. > > Sounds good to me, although I do not see the benefit of doing this if we > do not migrate tickets. If users need to reset their passwords, they can > as well reregister. There aren't too many things to configure and the > profile settings in Flyspray will likely not match what you can > configure in Bugzilla anyways. We currently have 12821 users in flyspray, of which there are ~ 50 with invalid email addresses and I'm not sure how many are actually 'active', since flyspray doesn't log the last logged in date. > > Generally speaking, I am in favor of setting up a fresh Bugzilla > instance and not doing any sort of migration. The idea of switching to a > new bug tracker came up at least four years ago and my feeling is that > all this migration work is what was holding it back for a long time. > However, we should make sure that the old Flyspray URLs still work (and > redirect to the Flyspray archive). Setting up Bugzilla in Ansible, and figuring how to auto-create and sync products will still be some effort. And we have to make sure that Bugzilla, isn't as slow as it's showcased ;-) My todolist is here: https://wiki.archlinux.org/index.php/User:jelly/Bugzilla#TODO > > * Release engineering > > Sounds good to me. I would split [core] and [extra]. I would also call > the packages projects "[core] packages", "[extra] packages" and > "[community] packages"; unless there are technical limitations > preventing the use of brackets. These brackets make it much clearer that > the names are referring to pacman repositories; and to a novice Arch > user, it may not be 100% clear what a "community package" or an "extra > package" is. I'm in favor, this should make it more clear where to report bugs, also with the automatic product selection. -- Jelle van der Waa signature.asc Description: PGP signature
[arch-dev-public] Switching the bugtracker to Bugzilla
It's time to switch our to something which is maintained and can be extended to our wishes. Flyspray isn't actively maintained, has had several security issues [1] [2]. It seems to be time to move on, and Bugzilla is one of the more active and maintained bugtrackers out there. Used by several big projects such as Gnome, LLVM and Mozilla. One of the benefits of moving would be the possibility of default assignees per 'component'. # Migration There are several options for migrating the bug history to Bugzilla and a few options are under debate. (input welcome) * No migration at all * Migrate open bugs * Migrate open bugs and auto-closing them * Migrate all bugs * Migrate all bugs and auto-closing them In either case, I believe it would be nice to "archive" the current bugtracker and make it read only. # User migration User migration should be possible as well, except migrating the password, a mass password reset would be wise. Since I'm not sure what kind of old hashing method / salt flyspray uses. # Migration Projects Bugzilla has a concept of products with components, so for all our packages we can create a component counterpart. It should be possible to auto-assign bugs with the pkgname <-> maintainer information from archweb. Possible products would be. # Products * Arch packages (core/extra or split this up) * Community packages (community) * Pacman * AURWeb * Keyring * Archweb (new) * Arch VM / Docker images (new) * Release engineering Input would be welcome, on what we should migrate from flyspray and what products we should define. [1] https://github.com/Flyspray/flyspray/releases/tag/v1.0-rc6 [2] https://github.com/Flyspray/flyspray/releases/tag/v1.0-rc4 -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] switching to systemd-stable
Hi, On 07/06/17 at 09:44am, NicoHood wrote: > On 07/06/2017 09:12 AM, Bartłomiej Piotrowski wrote: > > On 2017-07-06 02:11, NicoHood wrote: > >> On 07/05/2017 12:10 AM, Christian Hesse wrote: > >>> Dave Reisner <d...@falconindy.com> on Sat, 2017/07/01 13:22: > >>>> Hey all, > >>>> > >>>> This should be pretty much a no-brainer, but wanted to be sure I wasn't > >>>> missing anything. Systemd upstream publishes a "systemd-stable" repo [1] > >>>> which branches at each tag and cherry-picks backports. I'd like to > >>>> switch our systemd package to this repo to avoid some of the duplication > >>>> of work that Jan, Christian and myself have done in the past. The repo > >>>> sees a bunch more activity than what our own backporting strategy has > >>>> been, and I see that as a positive. > >>> > >>> Just a little heads-up... systemd 233.75-1 landed in [testing]. So give > >>> it a > >>> try! ;) > >>> > >>> BTW, we had just one backported commit to be removed, so 74 new commits > >>> landed in this package compared to 233-7. Let's hope this gives some > >>> benefit. > >>> > >> > >> Systemd still does not use https sources. Regarding the recent > >> discussion about tricking git about wrong tags and other evil stuff it > >> is highly recommended to switch to https. Please do it in favor for all > >> ArchLinux users security. > >> > >> Once more the reference: > >> https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias > >> > > > > Regarding the recent discussion: > > > > https://lists.archlinux.org/pipermail/arch-dev-public/2017-July/028919.html > > > > I really hoped I don't have to put "NicoHood" on top to make you realize > > it's addressed to you. Please do it in favor for all Arch Linux packagers. > > > > What are you blaming me for now? This is a package everyone must install > and you are telling me we have other serious problems? Sure we have, but > compared to the time it takes to add an "s" to "http" this is a simple > excuse. And this is not about checksums man, this is about https where > even gpg signatures by git can be tricked. I believe that a large group of Dev/Tu's do believe that security is a serious issue and that we should put some effort into security. And I can't thank everyone enough who has done a lot of work for example for the Security Tracker. A few people have worked hard, without much complaining and realy made a difference. For the whole signing issue we have a todolist for GPG signatures and never decided as far as I know on the sha256 or sha512 (or any poison) sums. Yet there is one individual in our community who keeps harassing (yes it's called harassment) Dev/Tu's to get GPG / HTTPS in PKGBUILD's. I would appreciate it if the discussion regarding GPG sigs etc, would be less dramatic. I'm kinda done with these requirements if I keep getting bugged that it's missing md5sums, https while I have a GPG sig. Calling out people, bugging them, isn't really the method to get things done. Note that this is my personal opinion, I surely do not speak for Arch as a whole. > And yes, I am doing stuff in the background. I wrote a guide and a tool > that simplifies source code signing[1] and I am doing a detailed > security analysis on all ArchLinux packages. And once it is ready I will > request gpg signatures from every upstream source, especially packages > from [core]. I appreciate the effort of contacting upstream about providing GPG signatures, that's really great! -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Changing compilation flags
On 06/30/17 at 09:49pm, Evangelos Foutras via arch-dev-public wrote: > On 30 June 2017 at 18:56, Daniel Micay via arch-dev-public > <arch-dev-public@archlinux.org> wrote: > > It's probably a good idea to leave it in CFLAGS for Clang. > > I am planning to patch Clang to follow GCC's behavior similarly to > what Alpine does. [1] > > We can discuss dropping the related compilation flags from > makepkg.conf at a later stage. > > [1] https://git.alpinelinux.org/cgit/aports/tree/main/clang Seeing that Arch is defined, will you upstream these changes? If so (+1) -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Outdated orphans
On 06/29/17 at 07:09pm, Antonio Rojas wrote: > The following packages are orphan and outdated, some of them for months or > even years, and some have been broken for a while (FS#54615). If you're > interested, please adopt them and fix them, otherwise they should be > removed so they can be properly maintained in AUR > > - xen (xenstore, xe-guest-utilities, python2-xenstore) > - openvas (-cli,-libraries,-manager,greenbone) Unless anthraxx wants to maintain it, I'd say drop it. -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Arch Linux Container and Boxes
On 05/31/17 at 01:05am, Christian Rebischke wrote: > Hello everybody, > I am pleased to announce that pierre and me founded the 'Archlinux' > Organisation on hub.docker.com and pierre pushed his awesome docker > container to this repository. (Big thanks to pierre!). [1][2] > > His docker container is a huge improvement to the other docker > containers in the hub. Most of them are insecure, ship private keys > within the container or ship more applications as needed. > Awesome! How often is the container updated? > > So my question to you is now: > > Can we make this project official? Or do we even want to make this > official? I would like to start a discussion with this questions. What would be needed to make it official? And which part, as I see the docker container as being official (tm). Thanks for all the effort btw! -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Improving overall experience for contributors
On 05/23/17 at 10:47am, Gaetan Bisson wrote: > [2017-05-23 22:23:51 +0200] Bartłomiej Piotrowski: > > 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 opinion writing emails to strangers should be part of the > application process. In my duties as packager maintainer I often find > myself writing emails to various persons I've never met: other distro > devs, upstream maintainers, etc. I'm sure the same goes for all of us. > It's just basic communication skills. > > Do we need contributors this badly that we could consider accepting > applicants who are too shy to write an email to a stranger? > > > In my humble opinion, we should rethink the way we recruit people > > I don't understand what you mean. In the past when we've had specific > needs in particular areas, ad-hoc recruitment processes were devised to > fill those needs. Shouldn't that be good enough? What kind of new > process would you like to see implemented? I disagree, I have the feeling there are a lot of ideas which would improve Arch Linux a lot. Which are now not being worked on (as far as I know). Therefore I think it would be great if there was a page where first time contributors can find projects, but this will require mentoring from Developers or TU's. A few things I can think of which need help: * Automate rebuilds, this is something we really need to keep rolling. * New dbscripts, moving to git, etc. * Archweb, although a lot of work is currently in progress. -- Jelle van der Waa signature.asc Description: PGP signature
[arch-dev-public] FroSCon developer room
Hi all, I'm going to FroSCon and was there a few years ago when we had an Arch Linux room. I'm wondering if more archers are going and if we want to get a room again this year, the submission deadline is the 23rd. [1] [2] [1] https://www.froscon.de/1/home/ [2] https://www.froscon.de/1/cfp/cfprojects/ -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] archweb upgrade from Django 1.7 to 1.8
On 05/17/17 at 11:34pm, Angel Velásquez wrote: > Hello, > > Just so you know, we just deployed a major upgrade of archweb we updated > the version of the framework from 1.7 to Django 1.8 (current LTS > version), the main author of this was jelle which became a very > important contributor of this project. > Thanks for the upgrade! 1.8 will still received security updates till April 2018. So before that date archweb should be upgraded to 1.11 LTS. -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Kernel 4.11 status
On 05/05/17 at 06:58am, Jan Alexander Steffens via arch-dev-public wrote: > On Fri, May 5, 2017 at 8:29 AM Tobias Powalowski via arch-dev-public < > arch-dev-public@archlinux.org> wrote: > > > Problematic with 4.11, license needs to be patched I don't think this is > > legal. > > http://rglinuxtech.com/?p=1935 > > > We could patch the kernel to make the needed symbols non-GPL instead. That > at least sounds less problematic (IANAL). There is a patch for 4.12 to undo the change from GregKH. [1] [1] https://github.com/torvalds/linux/commit/d557d1b58b3546bab2c5bc2d624c5709840e6b10.patch -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Can we have optional deps on AUR packages?
On 04/19/17 at 11:18pm, Giancarlo Razzolini wrote: > Em abril 19, 2017 17:47 Florian Pritz via arch-dev-public escreveu: > > > > Just pull the packages into the repos or don't include the deps. > > > > I also think we shouldn't depend, even if it's an optional dependency, on AUR > packages. As I already said in aur-general, I agree that we should keep this separate to avoid confusion. -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Packages for adoption
I've adopted bitlbee. -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] More packages for adoption
On 04/18/17 at 09:33am, Pierre Schmitz wrote: > Hi all, > > * fcgi > * fetchmail > * hefur > * imap > * lighttpd > * logrotate > * lynx > * rsync I'd adopt rsync -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Moving form testing to community-testing
On 03/29/17 at 03:54pm, Nicola Squartini via arch-dev-public wrote: > Hi, > > I mistakenly committed the new version of parity to [testing] rather > than [community-testing]. The command The package did not end up in [testing], so just community-testingpkg it and everything should be fine. -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] [RFC] Deprecate ABS?
On 03/25/17 at 10:35pm, Florian Pritz via arch-dev-public wrote: > On 25.03.2017 22:19, Allan McRae wrote: > > I have been working on and off to include source packages into a pacman > > database to allow pacman to directly replace these. > > Having this in pacman would be the best solution IMHO, but I think we > should be fine with svn/git right now. We have a lot more resources than > we had back then. We could also set up automatic mirrors on github once > we use git or just mirror the repos internally. +1 for the Github mirror and for dropping abs. -- Jelle van der Waa signature.asc Description: PGP signature
[arch-dev-public] Reminder for OpenSSL 1.1.0 rebuild
Hi all, I would like to remind everyone that we still have an OpenSSL 1.1.0 open, there are 198 (i686 and x86_64) packages left some of them even build fine without patches. If the package requires a lot of patches or no trivial patches are avaliable then openssl-1.0 can be used. Some modifications are needed: For cmake projects: cmake it's -DOPENSSL_INCLUDE_DIR=/usr/include/openssl-1.0 -DOPENSSL_SSL_LIBRARY=/usr/lib/openssl-1.0/libssl.so -DOPENSSL_CRYPTO_LIBRARY=/usr/lib/openssl-1.0/libcrypto.so For pkg-config builds use: export PKG_CONFIG_PATH=/usr/lib/openssl-1.0/pkgconfig Let's finish this before April fools day! -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Integrity Check x86_64: core, extra, community, multilib 27-02-2017
Never really studied the output, but it contains some valid warnings. On 02/27/17 at 12:22am, repoma...@archlinux.org wrote: > Mismatched Pkgnames > - > python-polib vs. /srv/abs/rsync/any/community/python2-polib Faidoc can you make python-polib, provide both the python2 and python variant and then remove python2-polib. Since some day we will get rid of Python 2. > Duplicate PKGBUILDs > - > /srv/abs/rsync/any/community/python-munkres vs. > /srv/abs/rsync/any/community/python2-munkres > /srv/abs/rsync/any/community/python-musicbrainzngs vs. > /srv/abs/rsync/any/community/python2-musicbrainzngs > /srv/abs/rsync/x86_64/community/python-jellyfish vs. > /srv/abs/rsync/x86_64/community/python2-jellyfish Fixed.. > extra/perl-autovivification --> armv7h Fixed. signature.asc Description: PGP signature
Re: [arch-dev-public] Upgrade to Berkeley DB 6
On 02/25/17 at 01:41pm, Jelle van der Waa wrote: > On 02/25/17 at 01:32pm, Nicola Squartini via arch-dev-public wrote: > > Hi, > > > > Berkeley DB is currently at version 6.2.23, while Arch is still at > > 5.3.28. Is any compatibility reason preventing the upgrade? > > It seems I missed some history. [1] https://lists.archlinux.org/pipermail/arch-dev-public/2013-August/025307.html -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Upgrade to Berkeley DB 6
On 02/25/17 at 01:32pm, Nicola Squartini via arch-dev-public wrote: > Hi, > > Berkeley DB is currently at version 6.2.23, while Arch is still at > 5.3.28. Is any compatibility reason preventing the upgrade? > Well it's not flagged out of date is it? :-) -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] [RFC] Mirror load distribution
On 01/30/17 at 08:39pm, Florian Pritz via arch-dev-public wrote: > Hi, > > I've just received a report from a mirror admin about some very heavy > traffic. After some investigation it appears that the traffic towards > his mirror started to rise around the beginning of the new year when we > disabled the mirror checker on gerolde. Since we now only have a mirror > checker running in Germany and his server is actually in the same data > centre as ours, the mirror checks completed very quickly. I can't think of an elegant solution for this issue. > I'm thinking about removing the mirror score from archweb's output and > more importantly, not sorting mirrors based on this score but rather > randomizing the list returned in [2]. It could still take the score into > account by limiting the returned set to mirror that are not totally out > of date, but I'd remove the sorting. The score doesn't really have a lot > a meaning anyways since it's just from our point of view. > > Does anyone have hard feeling about this? If not I'll prepare a patch in > the next few days. Idea sounds good to me, don't forget that you can also 'generate a mirrorlist' here, so you might want to remove the 'use mirror status' option there too. (or was that not part of the plan?) [1] [1] https://www.archlinux.org/mirrorlist/ -- Jelle van der Waa signature.asc Description: PGP signature
[arch-dev-public] Dropping goocanvas1
To keep up the initiative of dropping old stuff, I will be dropping goocanvas1, the only real user still using it is shutter. Felix mentioned that it can be dropped since it already depends on a lot of old libraries. I will drop pygoocanvas tonight and later this week shutter, perl-goo-canvas and goocanvas1 will hopefully disappear. -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Phasing out gstreamer0.10
On 01/19/17 at 02:18am, Balló György via arch-dev-public wrote: > Beside to WebkitGTK+, GStreamer 0.10 is unmaintained too. [1] The last > release was in 2012. Most of the applications are already ported to > GStreamer 1. The last major user is wxGTK, but an upstream patch is > available for GStreamer 1 support. [2] Actually a new release is out 3.1.0 with gstreamer 1.0 support. [1] > │ └─wxgtk2.8 > │ ├─amule > │ ├─codeblocks There is a bugreport for compilation with wxgtk, maybe it's applicable for other packages depending on wxgtk2.8 although most of them have better alternatives... [2] > │ ├─lib32-wxgtk2.8 > │ ├─pgadmin3 > │ ├─rapidsvn > │ ├─scorched3d > │ ├─truecrypt veracrypt replaces this package I'd say. > │ ├─wxpython2.8 This is required by at least 2 other packages: - cycle (dead upstream) , mayavi (as dead upstream ~ 2005) [1] http://wxwidgets.org/news/2016/02/wxwidgets-3.1.0-released/ [2] https://bugs.archlinux.org/task/52516 P.S. seems new years clean up has started :) Mayhbe I should drop pygoocanvas and goocanvas1 too. -- Jelle van der Waa signature.asc Description: PGP signature
[arch-dev-public] FrOSCon 2017
Hi all, After meeting Levente and Sven at 33c3, I would like to see another developer / TU meetup at FrOSCon. The last time I was at FrOSCon, pierre or brain0 or heftig? managed to book an project room for us. It would be awesome if we can get a room and work on some of our (bigger) projects for example: * archweb * auto staging-rebuild system * dbscripts * reproducible builds * security tracker * 32 bit deprecation :) The date and location for FrOSCon is: 19. + 20. August 2017 Hochschule Bonn-Rhein-Sieg https://www.froscon.de/en/faq/ -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] [RFC] pyalpm maintainership
On 12/24/16 at 09:28am, Gaetan Bisson wrote: > [2016-12-24 20:18:21 +0100] Jelle van der Waa: > > I'd like to see some improvements in the maintenance of pyalpm. > > I'm not sure what improvements you have in mind but there's two things > called pyalpm: Remy's personal git repo (projects:users/remy/pyalpm.git) > and our package. I'm assuming you're thinking of the repo. Yes the Git repo. > Why not fork it? If a fork is demonstrably better it would surely > convince Remy to merge the changes back into his personal repo. Or if > Remy is unavailable we could even decide to use the fork as upstream for > our pyalpm package. Well I've mailed remy patches but didn't get any response. So now I've forked pyalpm. [1] [1] https://github.com/jelly/pyalpm > > Cheers. > > -- > Gaetan -- Jelle van der Waa signature.asc Description: PGP signature
[arch-dev-public] [RFC] pyalpm maintainership
I'd like to see some improvements in the maintenance of pyalpm. The last update of pyalpm added pacman 5 compatibility support although several improvements patches where posted from October 2015 till 2016. [1] [2] [3] [4] [5]. I would love to see a more active maintenace of pyalpm, since it's vital for the arch-security tracker and namcap. I've mailed Remy about these patches but so far haven't gotten any response. [1] https://git.archlinux.org/users/remy/pyalpm.git/ [2] https://lists.archlinux.org/pipermail/arch-projects/2016-October/004413.html [3] https://lists.archlinux.org/pipermail/arch-projects/2016-October/004424.html [4] https://lists.archlinux.org/pipermail/arch-projects/2016-October/004420.html [5] https://lists.archlinux.org/pipermail/arch-projects/2015-October/004309.html ~ -- Jelle van der Waa signature.asc Description: PGP signature
Re: [arch-dev-public] Shadowing i686, round 1
On 12/12/16 at 09:51pm, Bartłomiej Piotrowski wrote: > against that architecture. No, I don't do even smoke tests – I assume > that i686 works if x86_64 does. (Don't beat me up too hard for that.) I know for sure that you are not the only one :) > I'd like to set a certain date of dropping i686 completely. During that > time, community and/or interested packagers could come up with either > automated build solution, making it "tier 2" architecture. Otherwise it > would just die of natural cause. I'm in favor of an auto build solution, since this has multiple bonusses. We could extend the auto build solution for reproducible builds (yay!). Auto rebuilds and maybe later when vendors get their act togehter (aarch64 *cough*). -- Jelle van der Waa signature.asc Description: PGP signature
