[arch-dev-public] Apollo decommission
Hi All, All the services that were hosted on apollo were moved to their own VPS'es or were removed. We plan to fully decommission the server on the 31th. If anyone knows any reason not to, please, let us know. We'll keep backups of it for a couple of months, after it's gone. Regards, Giancarlo Razzolini pgpCLF1HRddXd.pgp Description: PGP signature
Re: [arch-dev-public] Patchwork migration
Em dezembro 22, 2020 14:59 Giancarlo Razzolini via arch-dev-public escreveu: Hi All, As part of the apollo deprecation effort that's ongoing, we are now migrating patchwork to its own machine. Eventually it *might* be entirely deprecated in favor of gitlab, but we should keep it running for now. The migration will happen tomorrow around 1PM UTC, if there aren't any issues. As part of this effort, patchwork has also been migrated to version 3.0.0. Regards, Giancarlo Razzolini Hi All, The migration is complete. One notable change is that we stopped using postfix for incoming patches and we're now using fetchmail. We have done a few tests with incoming emails, but if there are any issues, please, let us know. Regards, Giancarlo Razzolini pgpO8_LTq3o2h.pgp Description: PGP signature
[arch-dev-public] Patchwork migration
Hi All, As part of the apollo deprecation effort that's ongoing, we are now migrating patchwork to its own machine. Eventually it *might* be entirely deprecated in favor of gitlab, but we should keep it running for now. The migration will happen tomorrow around 1PM UTC, if there aren't any issues. As part of this effort, patchwork has also been migrated to version 3.0.0. Regards, Giancarlo Razzolini pgpKhQVc_UF6a.pgp Description: PGP signature
Re: [arch-dev-public] Wiki migration
Em dezembro 20, 2020 16:35 Giancarlo Razzolini via arch-dev-public escreveu: Hi All, We are going to migrate the wiki to a new VPS as well. The migration will happen tomorrow, 21, around 6PM UTC. If there's any issue, the migration will be pushed to 22, same time. I expect the migration to take around 1 hour, but it can be faster than that. During that time, the wiki will be under maintenance. Regards, Giancarlo Razzolini Hi All, The migration is complete. Started a bit later than 6PM, but it was uneventful. Let me know if you notice any issues. Regards, Giancarlo Razzolini pgp3RgTe_N9Fk.pgp Description: PGP signature
[arch-dev-public] Wiki migration
Hi All, We are going to migrate the wiki to a new VPS as well. The migration will happen tomorrow, 21, around 6PM UTC. If there's any issue, the migration will be pushed to 22, same time. I expect the migration to take around 1 hour, but it can be faster than that. During that time, the wiki will be under maintenance. Regards, Giancarlo Razzolini pgp7myxzKXnyQ.pgp Description: PGP signature
Re: [arch-dev-public] Archweb migration
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. Regards, Giancarlo Razzolini pgpBp96tqhNe4.pgp Description: PGP signature
Re: [arch-dev-public] Archweb migration
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 pgpQJVM3oxKpu.pgp Description: PGP signature
[arch-dev-public] Archweb migration
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 pgpjjrvANU8OI.pgp Description: PGP signature
Re: [arch-dev-public] archiso v49 with new features
Em outubro 30, 2020 14:14 David Runge escreveu: If this mail reads like a changelog, then well, it is because I don't have a changelog in the project yet! ;-) Apart from that I thought it might be worthwhile to write a news item about it after the next ISO has been released and share the above two changes on the website. What do you think? I think accessibility is a huge milestone that, on its down, deserve a news entry. I have assisted a blind person to install Arch some time ago and it was very difficult. In the end, I wrote a small script to help with the installation. And this is not because the person wasn't technically able, but our iso didn't made it easy. Nice work! Regards, Giancarlo Razzolini pgpEh2nU2vMRZ.pgp Description: PGP signature
Re: [arch-dev-public] Packages up for adoption
Em outubro 14, 2020 14:31 Bartłomiej Piotrowski via arch-dev-public escreveu: Hi, Due to lack of free time, I've orphaned some packages I don't want to think about: bash bash-completion chrome-gnome-shell expat gdbm libcap libffi libunistring libusb networkmanager-fortisslvpn ncurses openfortivpn readline texinfo wpa_supplicant I've also disowned some packages I've been co-maintaining with other packagers but that's not so interesting. Bart Hi, I have adopted both bash and bash-completion and I'm also going to adopt readline. But I think these packages should have at least one co-maintainer, given their importance, so, co-maintain away, please. Regards, Giancarlo Razzolini pgpxTrHGuXxc8.pgp Description: PGP signature
Re: [arch-dev-public] Pam lockout
Em setembro 11, 2020 10:55 Tobias Powalowski via arch-dev-public escreveu: Hi guys, https://bugs.archlinux.org/task/67644 I second Levente's post of it's a configuration issue that needs to be addressed by user and not by the package itself. Typing 3 times wrong password is a sane default imho. Any other opinions out there? I third you and Levente's opinion. This is a sane upstream default and should be handled by users, if they wish to. We shouldn't deviate from upstream in this case. Regards, Giancarlo Razzolini pgpoyj_nHbPOe.pgp Description: PGP signature
[arch-dev-public] Mail server migration
Hi Guys, Continuing with our migration efforts, we're now going to migrate the last running service on orion which is the mail server and all the software related to it. This is also getting migrated to a VPS [0]. We plan on making this as transparent as possible, so all the mailboxes, sieve filters and .forward files and anything else mail related will be copied from the home directions each user has on orion. We also plan on syncing /etc/shadow, to make sure all the passwords remain the same. However, the SSH Host keys will also be changed on the process. These keys will be documented beforehand on [1] as well as sent to this thread. SSH access will only be used for password changing and for putting/editing .forward files and/or sieve filters. Eventually the mail server will not support SSH access anymore, as we plan on transitioning authentication to keycloak in the future. But for foreseeable future, things won't change. Also, with this change, since mail is the last thing on orion, that machine will be decommissioned. So, please, everyone make sure that you don't have anything on your home directory that you wish to keep. We'll take a backup, but the only things getting moved to the new mail server are mail related files. There's no date yet for both the migration and for orion's decommissioning, but the mail migration will happen next week, and orion's decommission following that and provided the mail migration is successful. There will be a period of time where the pop and imap services will be unavailable, as well as sending emails. We plan on not disrupting the incoming of emails, and I'll sync the queue between the machines, to avoid any lost email, while the DNS records are changing. Regards, Giancarlo Razzolini [0] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/92 [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/docs/ssh-hostkeys.txt pgpnEoLUzDgp_.pgp Description: PGP signature
Re: [arch-dev-public] Use detached package signatures by default
Em julho 28, 2020 16:26 Anatol Pomozov via arch-dev-public escreveu: It sounds great. If we go this route for pacman 6.0 then it will take about 1 year to switch to the detached signatures. As it is quite an important change I would love to see its codepath tested as much as possible before we remove the embedded signatures from pacman database files. It will help to catch issues like https://bugs.archlinux.org/task/67232. What do you think about starting to use detached signatures by default *and* having embedded signatures as a backup option for time being? i.e. pacman database will have the signatures (the same as now) but it will be ignored. Instead pacman will use the detached *.sig files. And in case if there is a major issue with this implementation then a user would be able to switch back to embedded signatures using a pacman.conf option (e.g. "UseEmbeddedSignatures"). If folks are fine with it I can implement a patch for it. Hi Anatol, Can't we go with a different option here? Instead of an option the user sets on their end, we make pacman fallback to embedded db sigs, if there are no detached *or* if the signature check fails for some reason. This could be maintained as a patch on the package, it doesn't necessarily have to be on pacman's code itself. Just so we make this transition as painless as possible to users. Regards, Giancarlo Razzolini pgpraXRYuv3EK.pgp Description: PGP signature
Re: [arch-dev-public] [aur-general] AUR migration
Em julho 28, 2020 9:46 Filipe Laíns escreveu: On Mon, 2020-07-27 at 14:43 -1000, Gaetan Bisson via arch-dev-public wrote: [2020-07-27 21:10:23 -0300] Giancarlo Razzolini: > Em julho 27, 2020 21:03 Gaetan Bisson escreveu: > > It's quite unsettling that we seem to be rushing to write a news post > > while this very reasonable suggestion remains completely ignored. > > > > It wasn't ignored. They keys were deliberately changed in the process. Why? Baptiste rightly points out "it's the same service as before and (presumably) the host private keys were not compromised, so there is no reason to change keys." Yet his message remains unanswered... If one machine gets compromised the keys are also compromised. If we can just use different keys on each machine to mitigate this, why wouldn't we? I think the short term bothers of changing the key do not warrant at all compromising security like this. But your experience might be different, is there anything in specific you are worried about or find annoying? I have been trying to figure what would possibly justify this but I can't, please let me know. Baptiste's answer was presumably under the assumption that the full machine would be migrated, but he would have to confirm. On which case, his request would be perfectly reasonable IMO. > I think the issue you refer to happened on the orion -> gemini migration and You are correct. > I personally think that everything that runs as a service on Arch servers should > be properly tracked on ansible, even if it's a user service. That is certainly a worthy goal but it does not imply that we must kill everything that is not tracked by ansible at every migration. Copying home directories over to the new host used to be standard practice for any administrator of a system which serves multiple users... None of this happened, when it did hapen in soyuz everyone got properly notified and had plenty time to get their stuff out, on top of that, the system was backed up in case someone forgot. I don't understand what issue you are trying to get on here, Grazzolini already explained this did not happen. I agree with what you said, no machine should be killed without a proper handling of the user data, but what is the issue right now? Cheers, Filipe Laíns Guys, the news is out, the keys are changed. I've taken a look at the remaining migrations and I don't think ssh keys are going to be an issue, because all the services that depend on ssh keys are migrated already. The orion mail migration will hopefully use keycloak for authentication, so no need for users to login to the machine for setting up/changing passwords. Most things are separated and isolated now to their own VPS, so, if in the future we need to do these migrations, it's easier to use the same keys, or rely on the UpdateHostKeys functionality to be able to gracefully change host keys. Thank you all for the help. Regards, Giancarlo Razzolini pgpXT2TUQKjak.pgp Description: PGP signature
Re: [arch-dev-public] [aur-general] AUR migration
Em julho 27, 2020 21:03 Gaetan Bisson escreveu: It's quite unsettling that we seem to be rushing to write a news post while this very reasonable suggestion remains completely ignored. It wasn't ignored. They keys were deliberately changed in the process. For future migrations I would greatly appreciate if not all on-disk data were thrown away. On top of SSH keys, there are home directories which contain not only user data but also in some cases things useful for the distro as a whole (such as the service I use to version iana-etc files). The AUR was running on luna, which still hosts git.archlinux.org (where a few projects still are) and lists.archlinux.org. No data was deleted from it, only the AUR database and uploads were copied to the new machine. I think the issue you refer to happened on the orion -> gemini migration and I personally think that everything that runs as a service on Arch servers should be properly tracked on ansible, even if it's a user service. Regards, Giancarlo Razzolini pgpjbq_c6akLb.pgp Description: PGP signature
[arch-dev-public] News draft: AUR migration
Hi guys, Given that the SSH host keys were changed during the AUR migration, and, due to the fact that not everyone will see this on the home page for the AUR or on aur-general, I propose the following news draft: > AUR migration: New SSH Host keys Due to the fact the AUR was migrated to a new server, the SSH HostKeys used to pushed packages were changed in the process. These are the new keys fingerprints: Ed25519: SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4 ECDSA: SHA256:uTa/0PndEgPZTf76e1DFqXKJEXKsn7m9ivhLQtzGOCI RSA: SHA256:5s5cIyReIfNNVGRFdDbe3hdYiI5OelHGpw2rOUud3Q8 They can also be found on the AUR home page when not logged in. < Given this is somewhat urgent and the migration was done on Friday, I'll not wait the full 24 hours before posting this, but I'll probably post this by the end of the day, today, instead. Let me know if anyone has any objections. Regards, Giancarlo Razzolini pgpzqRT_0W8cM.pgp Description: PGP signature
Re: [arch-dev-public] [aur-general] AUR migration
Em julho 27, 2020 9:35 Henry-Joseph Audéoud escreveu: On 24/07/2020 21:24, Giancarlo Razzolini via aur-general wrote: The migration is almost done. Since we are moving to a new machine, it will have new host keys. They are: Ed25519: SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4 ECDSA: SHA256:5s5cIyReIfNNVGRFdDbe3hdYiI5OelHGpw2rOUud3Q8 RSA: SHA256:uTa/0PndEgPZTf76e1DFqXKJEXKsn7m9ivhLQtzGOCI You swapped the fingerprints of keys ECDSA and RSA. From my computer, I get that fingerprints (and Ricardo Band has the same for ECDSA): ED25519: SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4 ECDSA:SHA256:uTa/0PndEgPZTf76e1DFqXKJEXKsn7m9ivhLQtzGOCI RSA: SHA256:5s5cIyReIfNNVGRFdDbe3hdYiI5OelHGpw2rOUud3Q8 Yes, this is correct. The configuration is with the keys swapped. I'm going to fix it and also create a news post about this. Regards, Giancarlo Razzolini pgpUyAEicMGav.pgp Description: PGP signature
Re: [arch-dev-public] [aur-general] AUR migration
Em julho 23, 2020 17:09 Giancarlo Razzolini via aur-general escreveu: Hi All, In continuing with the improvements being done to our infrastructure, we're planning to migrate the AUR to another machine. This means that, during the migration, there *will* be downtime of the whole AUR. I expect the migration to take around two hours and happen either tomorrow (Friday) or on Saturday, depending on availability. Regards, Giancarlo Razzolini The migration is almost done. Since we are moving to a new machine, it will have new host keys. They are: Ed25519: SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4 ECDSA: SHA256:5s5cIyReIfNNVGRFdDbe3hdYiI5OelHGpw2rOUud3Q8 RSA: SHA256:uTa/0PndEgPZTf76e1DFqXKJEXKsn7m9ivhLQtzGOCI They are also be available on the home page when logged out. Regards, Giancarlo Razzolini pgpY8wTyRiQvB.pgp Description: PGP signature
[arch-dev-public] AUR migration
Hi All, In continuing with the improvements being done to our infrastructure, we're planning to migrate the AUR to another machine. This means that, during the migration, there *will* be downtime of the whole AUR. I expect the migration to take around two hours and happen either tomorrow (Friday) or on Saturday, depending on availability. Regards, Giancarlo Razzolini pgpIohV3exN1R.pgp Description: PGP signature
Re: [arch-dev-public] help wanted / IPP based printing/scanning
Em julho 8, 2020 8:30 Andreas Radke via arch-dev-public escreveu: There's some major effort going on to move from driver based scanning and printing to driverless scanning and printing both based on IPP specifications offered by newer devices. While IPP based printing is already there for some time and usable with cups+cups-filters [1] there's more work going on recently for IPP based scanning lately. There are a few projects we should probably support and add to our repos. I'm thinking about adding Sane-airscan [2][3] to extra. There's also a new ipp-usb proxy to allow IPP protocol access with USB connected printers and scanner as well [4][5]. I've prepared a simple package here of this one. Sadly my own printer is has a broken IPP implementation and thus can't be used with driverless printing [6]. My scanner is an old extra devices with plain usb connection. Both devices keep working well and I have no plan to replace them. So I cannot test anything of the new IPP stuff. If there's desire to have the new IPP stack fully available form our repos I can do the packaging because it's heavily related to recent multidevices and openprinting.org projects. But any help is welcome and I would prefer someone to become a backup and co-maintainer. If somebody has interest to help out here and maybe owns a modern IPP based multidevice please drop me a line. If nobody steps up or complains I plan to add sane-airscan and ipp-usb and maybe more if needed. -Andy Hi Andreas, As we have discussed over IRC, I do have one of the printers supported by this model of driverless printing. Although, as of now, I'm using hplip, I could possibly switch to use this and help testing. It even has a scanner as well, so driverless scanning could be tested. I'm not sure how up to date our wiki pages are, perhaps we should start improving that as well. Regards, Giancarlo Razzolini pgpmE3fZOtz0_.pgp Description: PGP signature
Re: [arch-dev-public] moving dhcpcd to [extra]?
Em abril 22, 2020 6:38 Antonio Rojas via arch-dev-public escreveu: Is there any reason to keep dhcpcd in [core]? It's only an optional dependency of netctl in [core], it currently lacks an active maintainer, it doesn't seem to be much used (given the slow pace of signoffs), and there's already a basic dhcp tool in [core] (networkd). Any objections to move it to [extra]? I don't mind it being moved to [extra], but I use it still, so I'm willing to help maintain it. Is Ronald still active? Regards, Giancarlo Razzolini pgp3Zf_WHPezL.pgp Description: PGP signature
Re: [arch-dev-public] Looking for an Arch ISO maintainer
Em março 28, 2020 10:11 David Runge escreveu: On 2019-11-11 09:40:14 (-0300), Giancarlo Razzolini via arch-dev-public wrote: But, we still don't have anyone wanting to become the actual maintainer of archiso to help implement these changes. I'd be up for it. I have some ideas around certain possible test scenarios in regards to packer and ansible already. What is currently still unclear to me is how the archiso and bootstrap images on our download page are exactly generated from archiso (the actual specific calls) and whether a semi-automated way of doing that exists (I guess this question is aimed towards Pierre). I would like to automate this as far as possible and make this more transparent when maintaining archiso. How do we go on from here? Best, David Hi David, Thanks for coming forward to handle this. I'm going to set your write access to the git repository for Archiso. Regards, Giancarlo Razzolini pgpZ22WwH8cXT.pgp Description: PGP signature
Re: [arch-dev-public] Spring cleaning (moving orphaned packages from [community] to AUR)
Em fevereiro 27, 2020 6:11 Alexander F Rødseth via arch-dev-public escreveu: It's time for the semi-yearly package cleanup of [community] packages, as is tradition. I have gathered a list of "unneeded orphans" in [community] (packages that currently has no maintainer, and no other package depends on them) from the excellent list on our web page. TUs and Devs, please adopt, if you're interested: adapta-kde - Adapta theme for KDE Plasma 5 agg - High Quality Rendering Engine for C++ aide - A file integrity checker and intrusion detection program. arch - A modern and remarkable revision control system. arc-kde - Arc theme for KDE Plasma 5 aspell-it - Italian dictionary for aspell aspell-ru - Russian dictionary for aspell bar - A script for showing progress bars. bomberclone - Clone of the game Atomic Bomberman cellwriter - A grid-entry natural handwriting input panel. curseofwar - Fast-paced RTS/Action game with ncurses interface dcfldd - DCFL (DoD Computer Forensics Lab) dd replacement with hashing dumb-a4 - IT, XM, S3M and MOD player library (for Allegro 4) easystroke - Use mouse gestures to initiate commands and hotkeys. eclipse-cpp - Highly extensible IDE for C++ eclipse-java - Highly extensible IDE for Java eclipse-javascript - Highly extensible IDE for JavaScript eclipse-jee - Highly extensible IDE for JEE eclipse-php - Highly extensible IDE for PHP eclipse-rust - Highly extensible IDE for Rust esmtp - An easy SMTP forwarder. gimp-dbp - Davids batch processor for the GIMP gimp-plugin-fblur - Makes out of focus with luminosity and depth gimp-plugin-lqr - Plugin for The GIMP providing Liquid Rescale gimp-plugin-wavelet-denoise - Tool to reduce noise in each channel of an image separately gimp-refocus - A sharpen plugin for gimp using FIR Wiener filtering glide - Dependency management and vendoring for Go projects glitz - OpenGL image compositing library gnunet-gtk - A frontend for GNUnet gtk-theme-switch2 - Gtk2 theme switcher gvmd - greenbone-vulnerability-manager gvm-tools - greenbone-vulnerability-manager tools ifuse - A fuse filesystem to access the contents of an iPhone or iPod Touch iverilog - Icarus Verilog compiler and simulation tool javasqlite - Java wrapper including a basic JDBC driver for the SQLite 2/3 database engine matrix-appservice-irc - Node.js IRC bridge for Matrix minbif - An IRC gateway to IM networks that uses libpurple. mod_wsgi - Python WSGI adapter module for Apache monica - Monitor calibration tool mythes-pl - Polish thesaurus ode - High performance library for simulating rigid body dynamics openvas - Vulnerability scanning Daemon pinta - Drawing/editing program modeled after Paint.NET. Its goal is to provide a simplified alternative to GIMP for casual users processing - Programming environment for creating images, animations and interactions projectm-pulseaudio - Music visualizer which uses 3D accelerated iterative image based rendering (pulseaudio) projectm-sdl - Music visualizer which uses 3D accelerated iterative image based rendering (sdl) python2-pyxmpp - Python XMPP and Jabber implementation based on libxml2 python-pyinsane - Python library to access and use image scanners qtspim - New user interface for spim, a MIPS simulator. rdiff-backup - A utility for local/remote mirroring and incremental backups. remacs - Emacs with parts of it written in Rust steghide - Embeds a message in a file by replacing some of the least significant bits surf - A simple web browser based on WebKit/GTK+. tabbed - Simple generic tabbed fronted to xembed aware applications. transset-df - A patched version of X.Orgs transset with added functionality. tuxpaint-config - Tux Paint configuration tool uncrustify - A source code beautifier vim-jellybeans - Colorful, dark color scheme, inspired by ir_black and twilight vim-ultisnips - TextMate-style snippets for Vim. wren - Small, fast, class-based concurrent scripting language xautomation - Controls X from the command line and does visual scraping. xbindkeys - Launch shell commands with your keyboard or your mouse under X zapcc - C++ compiler based on Clang, but significantly faster zeal - An offline API documentation browser I'll wait two weeks before adding them to AUR, running both `db-remove` and `svn rm` on the unmaintained packages. PS. If unmaintained orphans in [core] could be moved to [extra], and unmaintained orphans in [extra] could be moved to [community], that could be a nice "trickle down" effect and would be an appreciated cleanup as well, but that is just my opinion. To quote our newly elected leader, in connection with the previous spring cleaning: I have just orphaned usbmuxd. I don't have an iOS hardware to test it anymore, so I can't maintain it efficiently. Please somebody else take it. It has one dependency, libimobiledevice, which is maintained by jgc/arojas. Regards, Giancarlo Razzolini pgpO6DUUMbBOO.pgp Description: PGP signature
Re: [arch-dev-public] Restricting ability to post news items
Em janeiro 5, 2020 21:04 Allan McRae via arch-dev-public escreveu: My apologies. I believed this had been covered on the mailing list and I am told it was only on IRC, and never passed on to the TU channel, which I will accept as an excuse despite everyone(?) involved but the poster being on both channels... It indeed never crossed to -tu. But I should have told Robin to send the draft to a-d-p, my bad. Do we really need to write down everything? Have we reached a point in the distro where common sense has stopped? Why would an announcement that affects the whole distro not be run past all team members by default? Yes, we do. Specially if we are talking about punishment, which clearly is the case here. I have seen drafts being discussed on arch-dev only too, and we never involved staff members on them. We have to have this written somewhere. Regards, Giancarlo Razzolini pgpQ0ipGSHO1u.pgp Description: PGP signature
Re: [arch-dev-public] Restricting ability to post news items
Em janeiro 5, 2020 19:25 Allan McRae via arch-dev-public escreveu: Read the original message and not the partial quote that you made. I explicitly said there was an exception for --overwrite type posts. But any restriction being made on posting due to not posting drafts to the list would be complete. Hi Allan, I think you're overreacting (again) for something that's not properly coded anywhere. And, the last time this was discussed, I have talked about cases of news that couldn't be brought on a-d-p for discussion. We have other places to discuss those (staff@), but still, until we have *clear* guidelines about this, let's not rush to implement anything. I have proposed a news entry regarding zstd, Robin did the statistics and we've discussed this for 2 days on #archlinux-tu. If you're looking for somebody to blame, look no further. Take away my news posting rights (you'll have to also take away my archweb admin rights in this case). And let's properly codify this ok? Because it's not codified anywhere. I could've asked Robin to send an email to a-d-p, but most of the work we've done on the draft was on a pad. This was reviewed by quite a few people. I asked Robin to do it, because since they pushed zstd, they should've also be the ones doing the news entry. But I would do it myself this week, if they didn't. Regards, Giancarlo Razzolini pgp4FyQvxlNmQ.pgp Description: PGP signature
Re: [arch-dev-public] Killing Python 2 (v2)
Em janeiro 2, 2020 14:10 Brett Cornwall escreveu: On 2020-01-02 13:43, Giancarlo Razzolini via arch-dev-public wrote: Er, the first end-of-life was five years ago and was then extended to 2020 to help accommodate the transition. I think a five-year grace period was long enough already... While I agree with that, it doesn't change the fact that having python2 lint and syntax checking tools will *still* be helpful in the foreseeable future. There are lots of reasons, educational ones, proprietary legacy code ones, etc. Let's not throw the baby out with the water. Just saying, if there's an opportunity to keep linters and syntax checkers/highlighters that don't necessarily require python2, it's not doing any *real* harm, provided they still are maintained projects. Will we eventually remove those as well? Sure. But the ability to read python2 code properly is independent of the ability to *run* python2 code. They are separate things. Regards, Giancarlo Razzolini pgpdT5McYol9j.pgp Description: PGP signature
Re: [arch-dev-public] Killing Python 2 (v2)
Em janeiro 2, 2020 13:24 Eli Schwartz via arch-dev-public escreveu: * pycharm-community-edition - remove python2 support Seems reasonable to not encourage people to use python2 in an IDE these days. Hi All, As we have discussed on IRC, I think that editors and python2 *lint* and *syntax* checkers, should be exempt from this. I'm for one use pycharm *a lot* and I'm expected/expecting to convert thousands of python2 code to python3 code in the coming *years*, not months, years. I'm perfectly fine installing python2 from the AUR for *running* python2 code, but how can people be encouraged to convert python2 code without even being able to syntax check it? So, in that regards, editores/linters/syntax checkers/etc, should be exempt from this, but *only* if they don't necessarily require python2 for that. As far as I know, pycharm doesn't require python2 itself for syntax highlighting and lint. Don't know about the others though. Regards, Giancarlo Razzolini pgpp47yWQL2JQ.pgp Description: PGP signature
Re: [arch-dev-public] RFC: (devtools) Changing default compression method to zstd
Em dezembro 31, 2019 12:08 Andrew Crerar escreveu: On 12/31/19 10:04 AM, Giancarlo Razzolini via arch-dev-public wrote: Just an addendum, the ordering on my previous email was wrong. The first zst package we got (after devtools, ofc) was texstudio. So, it's Sven that should get the kudos. Regards, Giancarlo Razzolini pgpF9YYY7SjYY.pgp Description: PGP signature
Re: [arch-dev-public] RFC: (devtools) Changing default compression method to zstd
Em dezembro 15, 2019 15:22 Robin Broda via arch-dev-public escreveu: All known issues have been dealt with. We are waiting on the patches to land, thus: - https://www.archlinux.org/packages/extra/any/namcap/ being upgraded to 3.2.9 - https://github.com/archlinux/archivetools/pull/8 being merged - https://github.com/coderobe/infrastructure/commit/7155521ed6f823ac6c6d06d1b9dcdb8a5165c417 being picked into infrastructure.git - this *depends on* the archivetools patch - archive-cleaner is not mission-critical, it does not need to be patched before the scheduled deployment - Foxboron is working on a patch These can all be dealt with during the deployment if they do not happen beforehand anyways. This means the deployment will happen as planned. Hi All, We seem to be getting .zst packages just fine. The following packages are on zstd format already: git kdevelop remind ipython chromium exim libva perl-xml-sax clang llvm llvm lib32-llvm nodejs ldc youtube-viewer cuda xfce4-terminal qt5-tools llvm lib32-llvm mpv qtcreator jenkins texstudio python-keyring ldc lldb you-get openmp python-keyrings-alt log4cplus acorn libfm-qt min matrix-synapse lld udftools v2ray compiler-rt trojan netcdf-openmpi shiboken2 shiboken2 python-parameterized parity-ethereum cbindgen ibm-sw-tpm2 golang-gopkg-check.v1 golang-golang-x-sys golang-golang-x-crypto golang-golang-x-image python-cfn-lint python-dephell mill python-gdspy tpm2-totp python-poetry ruby-public_suffix ruby-ffi devtools python-zstandard terraform-provider-keycloak wishbone-utils s-nail python-rdflib-jsonld libarchive grub openvpn Also, this is the order they were added to the repositories, so, kudos Christian for sending our very first .zst package. We haven't had any complaints either, so I think everything is good. Regards, Giancarlo Razzolini pgpk33CTWTKXy.pgp Description: PGP signature
Re: [arch-dev-public] cleanup dead Xorg packages | news draft
Em dezembro 19, 2019 19:45 Jan Alexander Steffens via arch-dev-public escreveu: On Thu, Dec 19, 2019, 23:35 Andreas Radke via arch-dev-public < arch-dev-public@archlinux.org> wrote: when updating, use: `pacman -Rdd libdmx libxxf86dga && pacman -Syu` Shouldn't we suggest -Rc instead of -Rdd here? I've had to run -Rc here. But I'm not sure we can force users to do that, and -Rc might have unintended consequences. I'm not sure what's the best approach is, but we will have manual intervention regardless, it seems. Regards, Giancarlo Razzolini pgpOmn167xeij.pgp Description: PGP signature
Re: [arch-dev-public] Missing bugtracker assignment emails
Em dezembro 16, 2019 14:43 Giancarlo Razzolini via arch-dev-public escreveu: I have found the issue. There's a 100 recipients per 6h limit being applied to emails coming from bugs.archlinux.org, which clearly explains why this sometimes works, and sometimes doesn't. I think we should check thoroughly the new relay setup that was done for postfix to see if there aren't any kind of limits being applied to other any other server. It looks that, after adding a new machine as a VPS, there's a need to run the postfwd role against orion. This should really be documented. I have ran the playbook and I'm monitoring the bug tracker for errors. I think it's fixed now. Let me know in case any of you notice missing emails. Regards, Giancarlo Razzolini pgps87wKJozWd.pgp Description: PGP signature
Re: [arch-dev-public] Missing bugtracker assignment emails
Em dezembro 16, 2019 3:53 Antonio Rojas via arch-dev-public escreveu: I missed emails for some comments in my assigned bugreports yesterday, so this is definitely not completely fixed. It just happens randomly. I have found the issue. There's a 100 recipients per 6h limit being applied to emails coming from bugs.archlinux.org, which clearly explains why this sometimes works, and sometimes doesn't. I think we should check thoroughly the new relay setup that was done for postfix to see if there aren't any kind of limits being applied to other any other server. Regards, Giancarlo Razzolini pgpRRc0lCSsbV.pgp Description: PGP signature
Re: [arch-dev-public] Flyspray migration to a VPS
Em novembro 30, 2019 11:40 Giancarlo Razzolini via arch-dev-public escreveu: Hi All, If everything goes well, I'll be moving flyspray (bugs.archlinux.org) to a VPS later today. In fact, the VPS already has a copy of our flyspray instance, I'll just make a final dump and take a last copy of the attachments and make the move. So, expect it to be unavailable for some time later today. I expect to start working on this at around 16-17 UTC and the downtime should be around one hour, plus the time it takes for the DNS changes to propagate. Regards, Giancarlo Razzolini Hi All, The migration ended up happening today. Everything is working as expected, but, if you notice any issue, let me know. Regards, Giancarlo Razzolini pgpWY6fw2KkPW.pgp Description: PGP signature
[arch-dev-public] Flyspray migration to a VPS
Hi All, If everything goes well, I'll be moving flyspray (bugs.archlinux.org) to a VPS later today. In fact, the VPS already has a copy of our flyspray instance, I'll just make a final dump and take a last copy of the attachments and make the move. So, expect it to be unavailable for some time later today. I expect to start working on this at around 16-17 UTC and the downtime should be around one hour, plus the time it takes for the DNS changes to propagate. Regards, Giancarlo Razzolini pgpH8sazVS861.pgp Description: PGP signature
Re: [arch-dev-public] Reproducible builds progress and the upcoming rebuild of [core]
Em novembro 14, 2019 14:21 Robin Broda via arch-dev-public escreveu: Hmm, what do you think about postponing this until we roll out zstd, which should be somewhat soon? As i don't think we're gonna rebuild everything for zstd, this would be a great opportunity to get both of these things done at once. Too late, we have a [core] rebuild already sitting on [testing]. Regards, Giancarlo Razzolini pgpXNCW5PJSWT.pgp Description: PGP signature
Re: [arch-dev-public] New kernel packages and mkinitcpio hooks
Em novembro 12, 2019 15:24 Sébastien Luttringer via arch-dev-public escreveu: kernel-install runs a collection of scripts (hooks), with the systemd overriding logic. There is no huge difference with the pacman hooks, except the logic is cross distro, provided by systemd, and not tied to pacman. Improvements can be shared. What it makes me prefer systemd kernel-install than pacman hooks logic. I just disagree with the part where it somehow implies that improvements can't be made to the current hooks. The main reason I started mirroring the mkinitcpio on github is so we can receive contributions more easily. Using kernel-install, on Arch, is also pacman dependent, because you trigger it using pacman hooks. The only difference is what do you call. As I've said, even though I *personally* don't like it too much, nothing prevents us from using it in the future. Now that the kernel package doesn't install the kernel anymore, we can even provide more than one option for the user to install it wherever they want. So far we have only mkinitcpio hooks for doing that, soon dracut hooks as well. We can have a single hook in the future that reads from a configuration file which method the user wants. Regards, Giancarlo Razzolini pgpn6pdXUkVlr.pgp Description: PGP signature
Re: [arch-dev-public] New kernel packages and mkinitcpio hooks
Em novembro 11, 2019 16:18 Gaël PORTAY escreveu: Hi Giancarlo, On Sun, Nov 10, 2019 at 06:41:38PM -0300, Giancarlo Razzolini via arch-dev-public wrote: I have been working on hooks for dracut to install the kernels to /boot, as mkinitcpio does, and also create a simple configuration file for each kernel. Right now dracut does not conflict with mkinitcpio, and it is possible to have both installed at the same time on a system. The hooks I'm writing for dracut will, however, check if mkinitcpio is installed and won't run if it is. We might eventually conflict them if we decide dracut is mature enough for usage with Arch Linux. As a side note, I have been using it for the past 8 months without any issues. Do you have commited your hooks somewhere? I would like to have a look to them and probably to test them. They should land on the dracut package itself sometime this week, or start of the next week. I might commit them to svn before that, so probably keep an eye on the dracut package git repository, but I make no promises. There will probably be some default dracut configuration as well. And each kernel might end up having two dracut.d configuration files, one for each image (regular and fallback), created from a preset, in a similar way mkinitcpio does it now. Regards, Giancarlo Razzolini pgpvxjDKwy0C9.pgp Description: PGP signature
Re: [arch-dev-public] New kernel packages and mkinitcpio hooks
Em novembro 10, 2019 23:54 Sébastien Luttringer escreveu: Hello, Nice to see that moving forward. It is a smart to move pacman installed kernel out of /boot. Why do you rely on mkinitcpio (or later dracut) to install them in /boot instead of the systemd kernel-install logic? Hi Seblu, This has been discussed a bit on the dracut thread, as well on some other threads over time. I *personally* don't like the complexity of kernel-install that much. I'm not saying we will never use it, just that I don't see the case for using it *right now*. Things are a bit more flexible now, and anyone can override the hooks/scripts to install the kernel whatever way they want. Also, I plan more changes to mkinitcpio to make it even more flexible. Also, dracut is not set in stone and right now it's an experimental/secondary thing. mkinitcpio remains the default initramfs generator for Arch. I'll try to make sure it gets the changes, but there are some that will depend on upstream taking them, as well. Regards, Giancarlo Razzolini pgpEXmn5jhMPM.pgp Description: PGP signature
Re: [arch-dev-public] Looking for an Arch ISO maintainer
Em novembro 9, 2019 8:03 David Runge escreveu: On 2019-11-08 10:22:44 (+0100), Jelle van der Waa wrote: 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 I agree and was surprised to see, that we don't really have that yet. Automated testing of archiso actually sounds pretty interesting, albeit challenging. - Reproducible archiso (patches on the mailing list) [1] - Support secure boot [2] - Accessibility improvements (patches available on the mailing list) [3] I worked on a blocker around this topic (i.e. brltty). Please reply if you are interested in becoming an archiso maintainer, so far Alad has shown interested. I'm not exactly blessed with plenty of free time, but I'd be interested in giving it a go. Hi All, Love to see a lot of people stepping up to help with archiso. Perhaps we should do feature hunts more often, even for projects that have maintainers. But, we still don't have anyone wanting to become the actual maintainer of archiso to help implement these changes. I don't really see archiso being a handful as it is now. But, that might change with these features being introduced. Whomever takes it, should be able to cope with that. Regards, Giancarlo Razzolini pgpHcsTUeSkWf.pgp Description: PGP signature
[arch-dev-public] New kernel packages and mkinitcpio hooks
Hi All, As most of you have noticed already, the kernel packages had some recent changes where they do not install the kernel to /boot, as well as they do not have any kmod [0] nor mkinitcpio hooks anymore. Neither they do install mkinitcpio presets [1]. These changes were made after a lot of discussions between myself, Jen and the maintainers of the other kernels as well. We have spent a lot of time to arrive at this current format. [2] Kernels and presets are not installed and generated by mkinitcpio alpm hooks and scripts. All kernels that have a pkgbase entry file [3] will be processed by these scripts. We have changed all our officials kernels. Also, kernel removals are handled by mkinitcpio as well. We want to make the boot process more flexible, while also keeping it backwards compatible by default. There are a few changes I have planned for the next mkinitcpio release [4] that will help even further to achieve this. I have been working on hooks for dracut to install the kernels to /boot, as mkinitcpio does, and also create a simple configuration file for each kernel. Right now dracut does not conflict with mkinitcpio, and it is possible to have both installed at the same time on a system. The hooks I'm writing for dracut will, however, check if mkinitcpio is installed and won't run if it is. We might eventually conflict them if we decide dracut is mature enough for usage with Arch Linux. As a side note, I have been using it for the past 8 months without any issues. Regards, Giancarlo Razzolini [0] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/kmod=9e2016961cc34830957ceee0593a80bfa9e05ba9 [1] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux=43c5745a17e2ebe413a7140d4ef9326e26d6cb20 [2] https://github.com/archlinux/mkinitcpio/pull/7 [3] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux=f1c97a49a09b0fd8d7d1c3f6e8e635ef45974373 [4] https://github.com/archlinux/mkinitcpio/issues pgpQksquBfwtW.pgp Description: PGP signature
Re: [arch-dev-public] Retiring as a Trusted User
Em outubro 2, 2019 6:10 Florian Pritz via arch-dev-public escreveu: Hi, I no longer have the time necessary to properly handle actual TU duties so I am retiring my TU hat. I will still continue maintaining some packages I have in [community] via my developer hat. That said, I'd like to orphan some of them too. If anyone is interested in taking over one of these packages (and its dependencies), please feel free to adopt it and tell me so that I can orphan it. asciidoc filezilla libfilezilla gcolor2 gmrun obconf openbox openshot libopenshot libopenshot-audio pydf slock tipp10 vimpager xplc zim Florian Hi, Can you also send a signed email? Regards, Giancarlo Razzolini pgp3S5TfSqODb.pgp Description: PGP signature
Re: [arch-dev-public] Semi-away till 2019
Em setembro 3, 2019 13:44 Bartłomiej Piotrowski via arch-dev-public escreveu: Damn calendars, how do they even work!? Yes, I meant 2020. As we've already talked on IRC, I'll adopt and maintain the nginx package and it's modules. Makes sense, since I maintain -mainline. I can also help with the toolchain, in case you don't have time for it. Regards, Giancarlo Razzolini pgpEnnxIx_PlS.pgp Description: PGP signature
Re: [arch-dev-public] Dropping nvidia-340xx series
Em maio 21, 2019 14:52 Giancarlo Razzolini via arch-dev-public escreveu: Em maio 21, 2019 11:40 Ralph Corderoy escreveu: Doesn't help keeping it rotting in our repo when the next kernel update will make it obsolete. As announced previously, I have removed all packages related to 340xx from the repositories. I haven't uploaded anything to the AUR, since I would probably need to orphan the packages after uploading them. Therefore, I'll leave it up to the AUR community itself to upload them again, if it's needed. Regards, Giancarlo Razzolini pgpFuNMPZdkPQ.pgp Description: PGP signature
Re: [arch-dev-public] Proposal for a new organisation structure
Em junho 1, 2019 20:08 Christian Rebischke via arch-dev-public escreveu: DISCLAIMER: Sorry for the huge mail, I didn't thought it would get so long. If you feel attacked/angry or whatever about it, take a deep breath before you answer. I hope for a constructive discussion without personal attacks. Ok. Here we go. At the moment we have the following three Groups (If I miss something feel free to correct me): - Devs - Trusted Users - Support Staff The lines are not that clear cut, but in a general sense we have those 3. At least that's what's on our website, so I'll give you that. I'm a perfect example of why this is not always the case. These three groups have the following 'features' and tasks: - Devs: - Tasks: The developers care about [core] and [extra] repositories, they form a direction for the whole project 'arch linux' and they seem to have a veto-permission for TU decisions. Furthermore they have access on most infrastructure and they are maintaining/developing the core software like pacman. Some devs also care about trademarks, legal requests and finance or community events. Devs can also care about [community], if they are also a TU. Also, regarding what you said about veto, there's no such thing. Yes, devs *can* have a final say on stuff, but that's different from vetoing it. A veto, by definition, means no discussion at all. I don't recall ever some dev simply saying something wouldn't happen and no discussion regarding it. Also, common sense applies here (you can't get it on writing though). Regarding infrastructure, the devops team has access to the infrastructure, but that doesn't mean dev's have access by default. Yes, a lot of people on the devops team are dev's, but it's not a requirement, at all. I've applied to TU, to only then learn about the devops team. I would probably started contributing there first, instead of applying to TU if I learned about it sooner. By the way, this brings back the discussion about having a one stop page for contributions. - How to be a developer?: The developers will decide in a non public and secrete ritual who is worthy to be a developer. The process is unclear. There's no ritual. One of the things I did after becoming a dev was to go through arch-dev's archives. I didn't saw any arcane rituals or goat sacrifices. It's basically: Hey, let's promote X to dev? +1. Some discussion might ensue, but it's rare and I never saw one promotion that didn't go through in these years I've been dev. - Trusted Users: I'll skip, you described this accurately. - Support Staff: - Tasks: They do various tasks like infrastructure administration, wiki administration, bug wrangling, software contribution, forum moderators, security team, but they have no access to any repository. Just to point out that some staff have access to a lot of stuff. Even if it's not clear immediately. - How to be a support staff: It's unclear, mostly a new contributor just knows the right people and does the right thing at the right time and get somehow acknowledged by developers or TUs for their work. Mostly because staffers are doing the work nobody wants to. I have the uttermost respect for our bug wranglers, wiki, forums and other staff. Also, you didn't include in this our testers. 1. Simplified repositories Currently we have [core], [extra] and [community]. These three repositories are there, because they have grown to this structure over time. At the moment I don't see any real meaning for the split of [core] and [extra]. So one suggestion would be to either: - merge [extra] and [core] - or use [extra] for a new purpose, like for example a proprietary repository, for all proprietary software. (I know that this is not possible for all packages, because we have binary blobs in device drivers and kernel modules). You forgot to mention that [core] has mandatory testing, even if, it's not enforced by the tooling. 3. Organisation structure Depending on the repository access, we could reduce our organisation structure to just two groups: Devs and maintainers (a similar approach to big distributions like Debian). Devs could still have the 'superpower' for caring about infrastructure and legal/finance stuff and the group of trusted users and support staff would merge to one group of maintainers. With person-related access to package repositories we could tear down the whole repository structure to one, maybe two, repositories and we could give co-maintainership an actual meaning (permission to modify a foreign package). You're not account here for the bus factor. There's a reason why everyone can touch everyone's else packages. We're a volunteer based distro. Sometimes people can't handle stuff, but are still interested on the project. 4. More transparency At the moment the recruiting
Re: [arch-dev-public] Dropping nvidia-340xx series
Em maio 21, 2019 11:40 Ralph Corderoy escreveu: That's a good idea. I'll try switching to nouveau and seeing if that handles video well on here now. https://wiki.archlinux.org/index.php/Nouveau#Keep_NVIDIA_driver_installed I think nouveau will probably perform better for most of the hardware covered by 340xx. If nobody steps up in the following days I'll drop the package to the AUR. Doesn't help keeping it rotting in our repo when the next kernel update will make it obsolete. Regards, Giancarlo Razzolini pgp8wcuW4gbnN.pgp Description: PGP signature
Re: [arch-dev-public] Mkinitcpio replacement with Dracut
Em maio 21, 2019 14:08 Doug Newgard via arch-dev-public escreveu: A hook would be good, but might need to be in the kernel packages like the current hooks are. Kernel versions are hard-coded in the hook. It would also be nice to rename the initramfs so that we've got both available, I just put -dracut in it for testing this. Yes the hook could be versioned, but dracut has --kver and some other stuff we can use to rebuild the image when you update the kernel and the kernel on disk is different than the booted one. You can use the -dracut nomenclature for now, or you can replace the default initramfs. Your choice really. As long as you have the fallback working, shouldn't be a problem. I also cannot emphasize this more, people testing dracut should probably have an arch iso handy in case something goes wrong. Other than that, please lets test everything possible. Regards, Giancarlo Razzolini pgpOWdnSfzZ5D.pgp Description: PGP signature
Re: [arch-dev-public] Mkinitcpio replacement with Dracut
Em maio 21, 2019 12:29 Maxime Gauduin via arch-dev-public escreveu: Hi Giancarlo, Did some initial testing on my system, I was almost able to get a working initrd after a few tweaks [0] and a little patching [1] to use fs-lib with bash and without systemd. However I can't use my usb keyboard and mouse when greeted by gdm. I'll keep looking into it unless you have some pointers at the ready. Using the following command to generate the initrd: mkinitrd --xz /boot/initramfs-5.1.3-zen1-1-zen.img And the resulting lsinitrd [2]. Thanks. This is precisely the kind of testing we need. Including different kernels. I tried only on linux and linux-lts so far. It's weird your keyboard is not running when hitting gdm, because, at that point the initramfs shouldn't have any interference. Also, any reason to use xz? I know that not everyone has a big boot partition and images created by dracut (even with -H) are larger than mkinitcpio's. By jelle's suggestion, can we concentrate the bug reports on the bugtracker? I think it will be better. Thanks again. Regards, Giancarlo Razzolini pgpNpFk2xIf4W.pgp Description: PGP signature
Re: [arch-dev-public] Mkinitcpio replacement with Dracut
Em maio 21, 2019 2:24 Ike Devolder via arch-dev-public escreveu: Without looking at dracut yet, I have a few questions: - Is there a description how to move from mkinitcpio to dracut? No, not yet. But it is as simple as running dracut -H -f /boot/initramfs-linux.img, for trying it out. I'll work later this week on a wiki page, but the good thing is, it has plenty documentation available. - Does dracut support what mkinitcpio has? all the hooks and stuff It does support even more than we do currently. It can boot from pretty much anything, including NFS and NBD. - did you already add pacman hooks for dracut as we need for mkinitcpio, or is that not needed? We will certainly need a hook to trigger the rebuild, but I didn't add it as a part of the dracut package yet, because I need to write them, but I want first to see if dracut is a good fit for Arch or not. When I have some time to spare I certainly will try it out. Please do. And make sure you have your fallback image working when you do. Regards, Giancarlo Razzolini pgpTcubyZp3iF.pgp Description: PGP signature
[arch-dev-public] Mkinitcpio replacement with Dracut
Hi All, Recently, Dave announced his intention to step down as mkinitcpio maintainer. I have been handling a few things on it, made some small changes to our mkinitcpio-busybox [0], closed a few old bugs, while also made sure some of the other bug reports are still valid. [1] I have been testing a few patches to mkinitcpio for a while to fix those bugs, but last week Dave and I had a discussion on IRC and we agreed that we could spend better time contributing somewhere else than keeping working with mkinitcpio. Currently mkinitcpio cannot boot from NFS properly, mknitcpio-nfs-utils [2] uses very old code. Even though ipconfig works, it has several drawbacks compared to using more modern tools. Not to mention that we have two use cases for mkinitcpio, which are base and systemd enabled initramfs. Even though we use by default our base enabled initramfs, we have to support systemd related issues and we have to keep developing our systemd hooks. I have been looking into dracut for some time now, I copied some stuff from them on a few of my own scripts and they also have an actual test suite, that we currently can't use on Arch, but I plan to change that. With this in mind, I have packaged dracut for Arch and put it on Extra [3]. I have been using a dracut initramfs for a while now to boot my encrypted partition. Surprisingly, I only had to create a small patch to one of the dm-crypt module scripts [4] In this initial phase I want to ask as many of you to test this as a replacement to mkinitcpio in your setups, as many as possible, and in as many scenarios as possible. We will probably have to keep both packages on our repos for a long time, but once we are confident it's a good fit, we can replace mkinitcpio on our iso and base, so new installs get dracut by default. Please, drop in your comments as well. Regards, Giancarlo Razzolini [0] https://git.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/mkinitcpio-busybox=489fbd6f2ed1defd1c7f1b57e7d6edd25185e6d8 [1] https://bugs.archlinux.org/index.php?string=mkinitcpio=0 [2] https://git.archlinux.org/mkinitcpio-nfs-utils.git/ [3] https://www.archlinux.org/packages/extra/x86_64/dracut/ [4] https://git.archlinux.org/svntogit/packages.git/tree/trunk/0001-90crypt-Change-the-module-setup.sh-to-use-uname-r-in.patch?h=packages/dracut pgpKfovbqwPOx.pgp Description: PGP signature
[arch-dev-public] Dropping nvidia-340xx series
Hi All, As you might be aware, this last kernel broke (again) the nvidia-340xx driver. Usually when this happens, it delays our kernel or we end up pushing a kernel without the driver. We have to wait on nvidia to fix it or we have to use patches that are not always trivial, nor there is enough people working on them. Up until four months ago, however, I was always testing this on actual hardware. But, that machine do not have a monitor on it anymore. And, the card itself is troublesome, it sometimes make the whole machine crash when it heats. Having said this, I'm going to orphan the package in a couple of weeks, if nobody is interested in maintaining it. But, I would propose this package get dropped to the AUR so someone with the actual hardware can maintain it. P.s: Ironically I used the (almost) exact subject Felix use almost 3 years ago when proposing this. Cheers, Giancarlo Razzolini pgpj25SHSPyWo.pgp Description: PGP signature
Re: [arch-dev-public] Proposal: minimal base system
Em janeiro 21, 2019 20:03 Levente Polyak via arch-dev-public escreveu: # Proposal There is no strict definition of what a minimal Arch Linux system installation must contain. However in reality we mostly don’t add any packages that are in the base group as a dependency to other packages, which basically makes it a hard requirement. First of all, I'm glad you're bringing this up, even if the last two times this was brought up, either it ended on bikeshedding or the thread simply died. We have been recommending users to install base at least since 2007. I went through the wiki history and found the entry when we started telling users to install base. It is on another thread about this "base-system" group. I don't want to dig it up. To overcome the disadvantages, a better way to handle a strictly defined set would be a simple virtual base-system package that depends on the bare minimum of what we define as given and required. This virtual package can be changed/extended and every installation will pull it in during the next system upgrade. base-system with the bare minimal is the way to go, I agree with this. With strict dependency between packages. No more "assuming" base is installed. Everything that won’t be part of base-system needs to be added as a dependency to all requiring packages; alternatively don't omit any first level runtime dependencies at all. This package should only depend on strictly required explicit packages to get a working minimal Arch Linux system. The proposed end result is: - base: convenient helper group for quickly getting a working system when installing, must include the new base-system package - base-system: package defining the minimum dependencies for a working base runtime Possible candidates for the virtual package: Base requirements: - filesystem - gcc-libs - glibc - bash - coreutils Distro requirements: - licenses - pacman - systemd Some POSIX tools - coreutils - file - findutils - gawk - grep - procps-ng - sed - tar - gettext - pciutils - psmisc - shadow - util-linux - bzip2 - gzip - xz Some networking tools - iputils - iproute2 I agree with this package list. It's missing mkinitcpio though. Hopefully this time we'll get this moving along. Count me in for testing. Regards, Giancarlo Razzolini pgpoLOAdy9xmu.pgp Description: PGP signature
Re: [arch-dev-public] Looking for maintainer for mkinitcpio/a-i-s
Em dezembro 16, 2018 18:52 Dave Reisner escreveu: Hi, I'm finding myself lacking these days in both time and motivation to continue maintenance of both mkinitcpio and arch-install-scripts. Is anyone interested in taking these over? Both projects are fairly stable, but bugs do crop up as the rest of the OS evolves. dR Hi Dave, I can help with mkinicpio. As you know I have several hooks and scripts for it and I'm familiar with the code. Other than the bugs reported here [0], is there anything else you know about or are tracking somewhere else? Cheers, Giancarlo Razzolini [0] https://bugs.archlinux.org/?project=1=mkinitcpio pgpAQb5tHvuCX.pgp Description: PGP signature
Re: [arch-dev-public] Remove CAcert root certs
Em agosto 21, 2018 15:25 Pierre Schmitz escreveu: Absolutely fine with me. Things have changed and there are better options like "Let's Encrypt". On Tue, Aug 21, 2018 at 8:21 PM, Jan Alexander Steffens wrote: Hi list, I completely agree with https://bugs.archlinux.org/task/59690 and would like to remove the ca-certificates-cacert package from our repos and our default providers. The ca-certificates package will lose the depends and gain a replaces and conflicts on -cacert. Any objections? + 1 for removal. We don't use CACert and I don't think anyone else should be using it for anything production related. Regards, Giancarlo Razzolini pgpacAtMIh4UD.pgp Description: PGP signature
[arch-dev-public] Github Domain Verification
Hi All, I have added verification for our organization's domain on github [0]. This is an extra security feature that shows a "verified" badge [1] on our organization's profile. This is to help avoid impersonations to both our users and to our developers. Make sure you're always seeing the verified badge when using it. Regards, Giancarlo Razzolini [0] https://help.github.com/articles/verifying-your-organization-s-domain/ [1] https://paste.xinu.at/CgBNjk/ pgpPgyGlZkvjH.pgp Description: PGP signature
Re: [arch-dev-public] [arch-general] proposal to add "aurpublish" to community
Em julho 22, 2018 13:55 Eli Schwartz via arch-dev-public escreveu: So yeah, it seems like at least in the past there's been a distinction made between uploaders (burp, aurpublish) and downloaders (cower). Anyway if no one has a serious objection by the end of the week I guess I will add it. :) As long as you don't add downloading and/or packaging functionality in the future, I'm okay with it being in [community] as well. As side note, I didn't knew about it, and I'm thing it's great. I had a hack to update all my repos. Guess I'll start using aurpublish. Regards, Giancarlo Razzolini pgpwzohHsR5x4.pgp Description: PGP signature
Re: [arch-dev-public] Enforcing 2FA in GitHub organization
Em junho 29, 2018 5:09 Bartłomiej Piotrowski via arch-dev-public escreveu: Hi all, I want to enable mandatory two-factor authentication in our GitHub organization. Few of you unfortunately don't use it and will be effectively removed when I flip the switch, which I plan to do next week, 6th July. allanbrokeit anthraxx Atsutane Bluewind brain0 City-busz djgera eli-schwartz foutrelis lordheavy phrakture SantiagoTorres seblu shibumi vesath wonder Hi All, I have just enabled 2FA for the archlinux organization on github. The following users were removed: allanbrokeit brain0 City-busz djgera lordheavy phrakture seblu vesath wonder These users need to enable 2FA on their accounts and ask one of the owners to add them back to the organization. Regards, Giancarlo Razzolini pgpiZgP51fBSG.pgp Description: PGP signature
Re: [arch-dev-public] Enforcing 2FA in GitHub organization
Em junho 29, 2018 5:09 Bartłomiej Piotrowski via arch-dev-public escreveu: Hi all, I want to enable mandatory two-factor authentication in our GitHub organization. Few of you unfortunately don't use it and will be effectively removed when I flip the switch, which I plan to do next week, 6th July. allanbrokeit anthraxx Atsutane Bluewind brain0 City-busz djgera eli-schwartz foutrelis lordheavy phrakture SantiagoTorres seblu shibumi vesath wonder Hi Bartłomiej, I'm the manager of a github organization with more than 4k repos. Enabling mandatory 2FA is a good start. But there are some more things I would like to do: - Disable the permission for repository deletion by members (even with admin on the repo). Only owners should be able to delete repositories upon request. - Reduce the number of owners to a bare minimum. - Review all the 3rd party access and integration (so far I only saw travis). Also, I do have some scripts that use github's API to work with github's audit logs. Perhaps we can add something to our monitoring. Regards, Giancarlo Razzolini pgpQnE0ndY1k8.pgp Description: PGP signature
Re: [arch-dev-public] Archweb (archlinux.org) upgrade
Em abril 19, 2018 17:37 Giancarlo Razzolini via arch-dev-public escreveu: Hi all, I expect we should have a downtime of about 1-2 hours. If you notice anything different post upgrade, please let us know. Both me and Jelle are going to probably be around on IRC too during the upgrade. Hi all, We have upgraded archweb to django version 1.11. We found one issue only (which was fixed). All the services seem to be running just fine, as well all the pages are working. If any of you spot something wrong, please let me and Jelle know. Congrats to Jelle for the awesome work in getting this upgrade done. Cheers, Giancarlo Razzolini pgpjnG4GjGrj3.pgp Description: PGP signature
Re: [arch-dev-public] Archweb (archlinux.org) upgrade
Em abril 19, 2018 17:52 Andrew Crerar escreveu: Good luck folks! I'll be watching :) Slightly OT but do we have staging servers for testing archweb or is the roll out pretty much cutting a release from GitHub and deploying? Hi Andrew, Thanks to the awesome work Jelle did, we have a staging env on https://archweb-dev.archlinux.org/. We used it, plus some other things, to test this upgrade. Of course, things can still go wrong, which is why we plan to bring the site under maintenance mode and take a full backup before anything else is done. Regards, Giancarlo Razzolini pgpIYbK36bhnZ.pgp Description: PGP signature
Re: [arch-dev-public] Archweb (archlinux.org) upgrade
Em abril 19, 2018 17:04 Jelle van der Waa escreveu: 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! Hi all, I expect we should have a downtime of about 1-2 hours. If you notice anything different post upgrade, please let us know. Both me and Jelle are going to probably be around on IRC too during the upgrade. Regards, Giancarlo Razzolini pgpBN_PNnMuo4.pgp Description: PGP signature
[arch-dev-public] Arch Linux Wiki move
Hi All, I am about to move the wiki to apollo. I'm estimating that it will be down for one to two hours. Please, let me know if any of you notice something not working on it. I have tested the role extensively, but you never know. Regards, Giancarlo Razzolini pgpREr9Z_mWaI.pgp Description: PGP signature
Re: [arch-dev-public] Abandoning nvidia 340xx packages - does anyone want them?
Em janeiro 30, 2018 23:03 Sven-Hendrik Haase escreveu: I just orphaned them. You have to take lib32-nvidia-340xx-utils, nvidia-340xx-utils and nvidia-340xx. Enjoy and thanks! Your first task is to somehow make them build against kernel 4.15. Going to adopt all of them. Do you plan on keep maintaining the -lts version? Jan mentioned that there is a patch for r8168 that I could try to adapt for the nvidia driver. Presuming it's the same issue. Regards, Giancarlo Razzolini pgpDkK6UUuOf7.pgp Description: PGP signature
Re: [arch-dev-public] Abandoning nvidia 340xx packages - does anyone want them?
Em janeiro 29, 2018 16:37 Sven-Hendrik Haase escreveu: I do not have any devices which require me to run nvidia 340xx packages and I haven't tested them for quite some time now. The most recent nvidia devices which require 340xx because the regular nvidia package dropped support for them are now 8-9 years old. I still have at least one machine with one of those. I'm not really sure there is merit in maintaining these so unless anyone wants them I'll drop them to AUR in two weeks. I can adopt it, if you plan on dropping them. Regards, Giancarlo Razzolini pgpYMC1wcgOvV.pgp Description: PGP signature
Re: [arch-dev-public] 2017 repository cleanup
Em dezembro 18, 2017 6:54 Bartłomiej Piotrowski via arch-dev-public escreveu: - icoutils: lcarlier: playonlinux grazzolini: keepass I have adopted this package. I did not went through the uneeded orphans list yet, but I'm sure there's something in there I use. Regards, Giancarlo Razzolini pgpnBhLSoJWip.pgp Description: PGP signature
