Re: [arch-dev-public] Ciao
[2020-08-19 20:59:13 -0400] Daniel M. Capella: > On August 19, 2020 6:43:14 PM EDT, Gaetan Bisson via arch-dev-public > wrote: > > Dear all, > > > > I've joined the Arch team in 2010 and spent a decade as a developer; > > it's been a great privilege to be a part of such an awesome community > > and also a lot of fun. However I felt the ten-year mark was a good > > opportunity for me to move on since I recognize the majority's views > > on > > the future of the distro have of late steadily been diverging from > > mine. > > > > And thus I hereby resign my position of Arch Linux Developer. > > > > All the best in your future endeavors! > > I'm interested to know if there is anything in particular that you would like > for us to maintain or explore. From what I've seen, I appreciated your style, > farewell! Thank you but I really meant what I wrote wishing you all the best in your future endeavors: those who do should be those who decide. So take the distro wherever you please. Cheers. -- Gaetan
[arch-dev-public] Ciao
Dear all, I've joined the Arch team in 2010 and spent a decade as a developer; it's been a great privilege to be a part of such an awesome community and also a lot of fun. However I felt the ten-year mark was a good opportunity for me to move on since I recognize the majority's views on the future of the distro have of late steadily been diverging from mine. And thus I hereby resign my position of Arch Linux Developer. All the best in your future endeavors! -- Gaetan
Re: [arch-dev-public] [aur-general] AUR migration
[2020-07-28 13:46:23 +0100] Filipe Laíns: > If one machine gets compromised the keys are also compromised. I never suggested to use the same keys for multiple servers. Only that if luna's main purpose is to provide a service and this service is moved to a different host, it makes sense to move the SSH host keys too, and to generate new keys for luna. > 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 wanted to point out that I consider copying user home directories over to a new host an important part of any migration. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] [aur-general] AUR migration
[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... > 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... Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] [aur-general] AUR migration
[2020-07-25 00:18:55 +0200] Baptiste Jonglez: > On 24-07-20, Giancarlo Razzolini via arch-dev-public 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 > > Can't you just copy the SSH host keys from the old machines? > > It's the same service as before and (presumably) the host private keys > were not compromised, so there is no reason to change keys. It's quite unsettling that we seem to be rushing to write a news post while this very reasonable suggestion remains completely ignored. 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). Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] repos.archlinux.org has been migrated to a new server
[2020-06-26 10:37:44 +0200] Jelle van der Waa: > 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. My issues are now fixed. Thanks. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] repos.archlinux.org has been migrated to a new server
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? Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] SDR package naming
[2020-06-05 15:30:54 +0100] Filipe Laíns via arch-dev-public: > No consensus came from my attempt at > contacting him. And there was no discussion, it was one sided, so I > feel like this issue is not resolved. There are still relevant points > that I want to see addressed. It looks to me like Kyle answered your questions and then had better things to do than continue debating naming conventions, especially as the only kind of "solution" you appear to seek is compliance with your demands. But if you do not accept that a consensus is emerging from replies to your question by Kyle, Eli and myself, do you wish to call for a vote? Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] SDR package naming
[2020-06-04 23:03:23 +0100] Filipe Laíns via arch-dev-public: > 1) Rename libuhd to uhd > 2) Use the gr- prefix instead of gnuradio- for GNURadio[2] blocks Your proposed changes indeed seem the correct thing to do, but Kyle appears to have done a good job maintaining those packages over the years. Do you really think it is worth bypassing his decision using a community vote for something of almost no consequence? If we are to work together, we must sometimes learn to accept others' decisions we don't 100% agree with... Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Discussion - Increasing our CPU requirements
[2020-03-29 16:25:48 +0100] Filipe Laíns via arch-dev-public: > What I would for us to do is to create a x86-64-axv2, etc. that would > complement x86-64. We would not add it as a target for all packages, > just for the ones that make sense. > > For this pacman would have to support architecture priority. We could > have something like this: > > Architecture = x86-64-axv2 x86-64 I'd like to say why not but everything remains to be done, here. Whereas pacman and our toolchain have mature support for multiple architectures, and they have it today. > My point here is that to me it does not really make sense to drop > support for older CPUs. We will have little benefit in newer CPUs. Nothing is being dropped. Every CPU that does not support the new architecture can keep running the x86_64 packages they currently do. > Then automate it? Is there any reason why we can't have the tooling > build all architectures for us? Why not have an `extra-build` helper > that will call extra-$arch-build for all every architecture? That would be awesome but the tooling does not yet exist. Personally I do not consider it terribly bothersome to build packages for multiple architectures like we did for i686 and x86_64. And I think it would be preferable to introduce a new architecture tomorrow than wait a few more months in the hope someone implements your proposed scheme. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Urgent news item: sshd needs restarting after upgrading to openssh-8.2p1
[2020-02-16 20:03:16 -0500] Eli Schwartz via arch-dev-public: > It's pretty plausible that this commit is simply incompatible with the > previous version of sshd, therefore it could not reexec: > https://github.com/openssh/openssh-portable/commit/c2bd7f74b0e0f3a3ee9d19ac549e6ba89013abaf > > So this is "expected" behavior. That seems likely indeed. What troubles me is that upstream has never broken live SSH daemons in such a way before, maybe it was just pure luck, but I had assumed this was a conscious design choice on their part. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Urgent news item: sshd needs restarting after upgrading to openssh-8.2p1
[2020-02-16 19:53:53 -0500] Santiago Torres-Arias via arch-dev-public: > On Sun, Feb 16, 2020 at 07:51:19PM -0500, Eli Schwartz via arch-dev-public > wrote: > > On 2/16/20 7:47 PM, Gaetan Bisson via arch-dev-public wrote: > > > Dear all, > > > > > > I'd like to post the following news item within the hour. > > > > > > > > > > > > Title: sshd needs restarting after upgrading to openssh-8.2p1 > > > > > > Conent: After upgrading to openssh-8.2p1, the existing SSH daemon will > > > be unable to accept new connections. When upgrading remote > > > hosts, please make sure to restart the SSH daemon using > > > `systemctl restart sshd` right after `pacman -Syu`. > > > > > > > > > > > > I deeply regret not spotting this while the package was in [testing]. > > > And I also regret not being able to diagnose what the exact problem is > > > just now. Given time is of the essence, I propose posting the above news > > > quickly even I don't consider it a very satisfying solution... > > > > Is it sufficient to add a post_upgrade message? > > > > The issue is that the package is already out iiuc. Let's do both: announcement and new package with post_upgrade. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Urgent news item: sshd needs restarting after upgrading to openssh-8.2p1
[2020-02-16 19:51:19 -0500] Eli Schwartz via arch-dev-public: > On 2/16/20 7:47 PM, Gaetan Bisson via arch-dev-public wrote: > > Dear all, > > > > I'd like to post the following news item within the hour. > > > > > > > > Title: sshd needs restarting after upgrading to openssh-8.2p1 > > > > Conent: After upgrading to openssh-8.2p1, the existing SSH daemon will > > be unable to accept new connections. When upgrading remote > > hosts, please make sure to restart the SSH daemon using > > `systemctl restart sshd` right after `pacman -Syu`. > > > > > > > > I deeply regret not spotting this while the package was in [testing]. > > And I also regret not being able to diagnose what the exact problem is > > just now. Given time is of the essence, I propose posting the above news > > quickly even I don't consider it a very satisfying solution... > > Is it sufficient to add a post_upgrade message? Probably, yes but then we'd need a new package out of [testing] fast. And users might complain that the post_upgrade message wasn't visible enough... :) Cheers. -- Gaetan signature.asc Description: PGP signature
[arch-dev-public] Urgent news item: sshd needs restarting after upgrading to openssh-8.2p1
Dear all, I'd like to post the following news item within the hour. Title: sshd needs restarting after upgrading to openssh-8.2p1 Conent: After upgrading to openssh-8.2p1, the existing SSH daemon will be unable to accept new connections. When upgrading remote hosts, please make sure to restart the SSH daemon using `systemctl restart sshd` right after `pacman -Syu`. I deeply regret not spotting this while the package was in [testing]. And I also regret not being able to diagnose what the exact problem is just now. Given time is of the essence, I propose posting the above news quickly even I don't consider it a very satisfying solution... Cheers. -- Gaetan
Re: [arch-dev-public] Guidelines for news posting
[2020-01-06 23:11:57 +0100] Sven-Hendrik Haase via arch-dev-public: > Every news post needs to have a corresponding draft submitted to > arch-dev-public and wait for feedback for at least 24 hours unless: > 1. it is urgent (and would be too late after 24 hours) > 2. it is a simple --overwrite rule, or > 3. there are strong reasons for the team member posting the draft to > believe that it should not be visible to the public before it is announced. > In this third case, the draft should be submitted to the > st...@lists.archlinux.org ML instead. That sounds great, Sven, thank you. I would however propose to remove rule 2. Mostly because I don't like exceptions and also because we should try our best to keep the number of such announcements to a minimum. Cheers. -- Gaetan
Re: [arch-dev-public] Restricting ability to post news items
[2020-01-06 16:48:48 -0300] Giancarlo Razzolini: > I'm moving this to staff@, please stop replying on a-d-p. Doing dirty laundry > in public is not necessary. And I'm moving this back to arch-dev-public because most staff aren't concerned with posting news items. Besides, there's nothing secret about this and I don't believe in hiding policy discussions out of the public eye. > For making that argument, you must first demonstrate that the news *wasn't* > used responsibly or there was any abuse of any kind. My reply was only to your suggestion that "everything should be written down". For clarity, let me recall how the conversation went: - Allan: Do we really need to write down everything? - Giancarlo: Yes, we do. - Me: No, we don't. As you can see I expressed no opinion on whether the latest news item was responsible. But since you ask, I think that question is moot since it's already been posted. However I deeply deplore that it was not discussed beforehand on arch-dev-public first. > Also, you're implying that this particular news entry wasn't thought through, > when in fact I can preset mounts of evidence to the contrary. Just a look at > the > logs for #archlinux-tu for the 3th and 4th will tell you that. I don't have access to #archlinux-tu. Even if I did, I would not have been constantly monitoring the channel during the 3th and the 4th. What I don't understand is why you don't advocate the use of a medium of communication that encompasses both devs and TUs and allows people in different timezones or with different schedules to contribute. > If we are going to start *punishing* people, you damn right we *need* > guidelines for it. I strongly disagree. We don't need rules and we don't need punishments. We just entrust staff members with powers and expect them to use said powers responsibly. If they don't, we discuss on a case-by-case basis whether to strip them of the power they abused. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Restricting ability to post news items
[2020-01-05 21:27:19 -0300] Giancarlo Razzolini via arch-dev-public: > Em janeiro 5, 2020 21:04 Allan McRae via arch-dev-public escreveu: > > > > 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. No, we don't. We should be able to entrust devs and TUs with powerful tools and assume they'll use them responsibly. Our distro is lost if being a dev or TU is about following a guidebook. Anyone could have noticed the many threads on arch-dev-public discussing news post proposals, and anyone could also have refrained from pressing the "add new post" button on archweb before thinking this through... Obviously everyone thinks their news post is benign, but you wouldn't push packages directly to [core], would you? Same logic applies here. Since it appears not everyone can do the above, I must agree with Allan: there must be some moderation in place for news posts... Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Proposal: Build a ruleset for new packages and package quality
[2019-12-12 13:21:42 +0100] Christian Rebischke via arch-dev-public: > 1. find a consensus on rules which packages we allow in our repositories > and which don't. There's no need for hard rules except "don't put stuff in the repos that will cause legal problems". We certainly strive to ship stable versions. But for some projects those are outdated and there are valid reasons to prefer shipping a newer release even if it's tagged as unstable by upstream. Those decisions are left to the best judgment of individual maintainers. If a conflict arises, it should be discussed on this mailing list. > 2. find a consensus on rules on violating our rules regarding package > requirements. (e.g. What happens when TU/Dev XY violates our package > requirements? what is the punishment?) If there's a disagreement as to what should or should not be packaged, it should be discussed here on a case-by-case basis. If consensus is reached that the package should be removed, then the packager must remove it. Obviously if the packager does not abide the decision made, there will be serious repercussions. But there's no need to set anything in stone: this will be decided on a case-by-case basis. > 5. What do we do with the existing beta and alpha packages? Are they > granted asylum? Or do we remove them, to be consistent? > > extra libmspack 1:0.10.1alpha-2 > extra qt5-webkit 5.212.0alpha3-6 > community d-containers 0.8.0alpha.19-1 > extra frozen-bubble 2.2.1beta1-14 > extra hddtemp 0.3.beta15.53-1 > extra libcaca 0.99.beta19-2 > extra tsocks 1.8beta5-8 > community hydrogen 1.0.0beta1-1 > community lablgtk3 3.0.beta6-2 > community modclean 3.0.0beta.1-1 > community sdedit 4.2beta8-1 > community sniffit 0.3.7.beta-17 > community vbindiff 3.0_beta5-1 > community wqy-microhei 0.2.0_beta-9 > community wqy-microhei-lite 0.2.0_beta-9 We shouldn't aim to replace those packages just because they have alpha or beta in their name. Assume the individual maintainers made an informed decision. Now if someone has a good reason why we should ship a different version than the above for a given package, please bring it up and we can discuss it. I can only speak for hddtemp and tsocks: they're old releases, but there hasn't been any newer one and their last stable release are really ancient. Those "beta" releases provide the best feature/stability for our users. > 7. Another topic is a rule about "touching packages of others". In the > #archlinux-tu channel we came to the conclusion that TUs or devs should > ask the package maintainer before touching another devs/TUs package, how > do we want to handle this? Is this the consensus, or are touches without > prior question allowed? What do we do if somebody violates our rules? > etc If it's something as trivial as a pkgrel bump and rebuild, no permission is required. If it's something more substantial, it should be discussed before. As usual, if a conflict arises, it should be discussed here. > https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_versioning > > My questions to this guidelines: > > 8.1. under which consensus where this rules defined? Are these rules the > result of a developer vote? of a leader decision? Or are they made up by > a few persons without consensus. They're just guidelines. Try to abide them and when you don't make sure you have a really good reason not to. > 8.2 I can't find any list about punishments for violations of these > rules. Again, punishment is uncalled for at this stage. If a packager repeatedly ignores warnings and repeatedly violates decisions made by consensus, then sure, we'll start a discussion about removing them. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] [arch-dev] State of OCaml-Update (stuck by deprecation of camlp4)
[2019-08-06 19:21:11 +0200] Jürgen Hötzel: > Unfortunately it is not possible to compile camlp4 with OCaml >= 4.08. > > But some well known packages depend on this preprocessor. E.g. :Haxe, > lablgtk2 (therefore also: Unison and Coq). > > I don't see that these projects will be migrated to camlp5 or ppx in the > near future. Therefore there are only 2 options from my point of view: > > 1. OCaml-4.07 and Ocaml >= 4.08 in [EXTRA]. > 2. removal of Haxe, lablgtk2, Unison and Coq. > > I prefer 1. What do you think? I'm a heavy unison user so I definitely prefer option one to option two though if that's too heavy a maintenance burden I'd perfectly understand dropping the relevant packages to the AUR. That's while we're waiting for Debian/upstream porting those projects to camlp5, of course. :) Cheers. -- Gaetan
Re: [arch-dev-public] Away until June 17
[2019-06-07 09:54:25 +0200] Laurent Carlier via arch-dev-public: > For holidays Me too! I'll be travelling for business and pleasure from today until July 24. Though I should remain reachable by email, my response latency will probably increase and might reach 48h or so. So feel free to do anything urgent without asking. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Proposal for a new organisation structure
[2019-06-02 06:06:35 +0200] Christian Rebischke: > On Sat, Jun 01, 2019 at 04:10:45PM -1000, Public mailing list for Arch Linux > development wrote: > Thanks for your mail. I remember now that you have told me this some > months ago. This leads to a question: Why are these types of dicussions > not public? Our discussion some months ago was public, just like this one. Most discussions among devs are public. Some aren't because we feel certain sensitive topics are better discussed in an environment where nobody is afraid to speak their mind. That includes topics like the addition of new developers, although like Lukas said in most cases those solely contain positive support for the proposal. Again, to the best of my knowledge, all devs are very happy with this process and do not want to change it. > Well, that's point. I don't really think the current system works as it > could be. Why being happy with the current state of organisation if we > could achieve much more with a more simplified and more contributor > friendly model? Feel free to explain what does not currently work as best as it could, what could be simplified, what could be more contributor friendly, etc. If you discussed specific problems, we could all have a go at proposing solutions a little more realistic than overhauling our organisational structure... > If you and the others see no point in > changing the current structure this is totally fine, I just think it's > important to rethink processes from time over time. What I think is most wrong with your current and previous "proposals" is that you obviously don't understand how the present dev system works, yet you want to change it! Have some humility, man, and remember this system has worked for about a hundred devs and for over a decade. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Proposal for a new organisation structure
Hi Christian, [2019-06-02 01:08:30 +0200] Christian Rebischke via arch-dev-public: > inspired by the last thread about moving proprietary software to > community, our general problem of getting more people involved in Arch > Linux and the (for me) chaotic organisation structure and hierarchy I > would like to propose a discussion about changes. I seem to recall we've had a similar discussion just a couple of months ago but allow me to reiterate some key points. First, contrary to what you keep saying, the process by which devs make decisions is very clear: by discussing things until a consensus emerges. In extreme cases where a consensus cannot be reached, we can take a vote or let our leader decide, but this has never happened in the nine years I've been a dev. To the best of my knowledge, we're all very happy with this system and do not want to change it. Second, our current organizational structure has served us well for many years. What problem are you trying to solve by overhauling it? What piece of evidence do you have that your suggestions will fix those problems? I'm certainly going to support imposing more bureaucracy just for the sake of bureaucracy. Again, if a certain system works for TUs, I'm glad and I'm certainly not going to impose my views on how TUs work; after all, that's why the TUs were made a self-governing body. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Spring cleaning (take 2)
[2019-03-27 18:08:02 +0100] Christian Rebischke via arch-dev-public: > I would adopt: > ttf-baekmuk > ttf-hannom > ttf-khmer > ttf-sazanami > ttf-tibetan-machine I've just moved those to [community] for the greater good! Enjoy. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Spring cleaning (take 2)
[2019-03-27 17:19:34 +0100] Antonio Rojas via arch-dev-public: > geeqie I've adopted that one. Cheers. -- Gaetan
Re: [arch-dev-public] RFC: (devtools) Changing default compression method to zstd
[2019-03-25 00:46:15 +0100] Morten Linderud via arch-dev-public: > On Sun, Mar 24, 2019 at 04:39:54PM -0700, Andrew Gregory via arch-dev-public > wrote: > > I don't consider hoping that libarchive doesn't need a rebuild in the > > near future a great strategy. That being said, this is really > > a question of how long of a period we need between libarchive v3.3.3 > > and us making the switch. I'm not a packager, so I don't have much of > > an opinion on that. > > Well, we pride ourselves with having competent users. I think waiting a year > is > conservative and safe. However, personally I think we can wait for the next > pacman release and write an announcment. Then we give everyone a month to > update > and we can have a smooth transition. Assuming of course that everyone is > on-board with this change. So far we all seem to agree it's a change for the better. However your timeline is confused: we only need to wait for a new pacman release to start building zstd-compressed packages; we can then push them to the repos straight away, assuming users have had enough time to update libarchive-3.3.3. It's already been in [core] for more than six months. Traditionally we wait a year before pushing changes that break backward compatibility. That always seemed a bit extreme to me so I'd personally be fine with doing the switch in a month or two with certain precautions: - Post an announcement warning users they'll need libarchive-3.3.3 or higher a month from now and telling them to update if they haven't done so in the last six months. - Prepare a static build of libarchive-3.3.3 compressed with xz and write a wiki page with detailed instructions on how to manually switch from an old system (for users who might want to switch even later). Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Follow-up on the “Proposal: minimal base system”
[2019-03-18 08:39:45 +0100] Bartłomiej Piotrowski via arch-dev-public: > I asked Bruno to start another round as previous thread is way too long > for people who missed the party to catch up. So some of us have taken the time to discuss this issue just a month ago but because it's too much to read for you we must start all over again? > Currently maintainers either put actual dependencies into depends=(), > including glibc if something dynamically links to libc.so or assume that > base is group expected to be present on every installation, which I > wholeheartedly disagree with I'm fine with both but, again, I note that we've been using the second option for as far back as I can remember, even before you became a TU. Some people were pushing for sodeps at some point but it did not go far. If it's not too much to read, have a look at this old thread that discussed your exact issue: https://lists.archlinux.org/pipermail/aur-general/2011-January/013256.html Anyhow. We currently have a base group that you're not happy with. Levente and Bruno suggest to update its package list and/or maybe make it a meta- package. From your perspective that would be no better and no worse than the current situation, right? So I don't see why you are against this change but if you are please tell us what concretely you propose we do? Cheers. -- Gaetan
Re: [arch-dev-public] Proposal: minimal base system
[2019-03-17 13:35:55 -1000] Gaetan Bisson: > Only 156 packages have glibc in their depends array. My bad. It's 624 packages for a total of 10.000. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Proposal: minimal base system
[2019-03-18 00:25:09 +0100] Alad Wenter via arch-dev-public: > Assuming we implement this group or meta-package as something of policy, i.e. > every repository package is assumed to depend on it. This would then make > base similar to base-devel, except for depends() instead of makedepends(). > > With base-devel, we've always encouraged people to remove the makedepends > already in that group. Would we do the same for "base", i.e. remove > dependencies that, beforehand, were explicit? We've been doing this for as long as I can remember. Only 156 packages have glibc in their depends array. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Follow-up on the “Proposal: minimal base system”
[2019-03-17 23:29:12 +0100] Bruno Pagani via arch-dev-public: > I was satisfied with the consensus we reached, but when I asked on IRC > how I should revive the thread so that we move on with that proposal to > an actual implementation, I faced concerns about this proposal from > several persons. I see. Most devs, myself included, have no idea who told you what on IRC and I really wish you'd give zero credit to the opinions of those who cannot be bothered to write their thoughts clearly and send a public message to this list so everyone has a chance to read and comment on them. We're reached consensus in the open discussion we've had here last month, where every dev and TU was free to contribute, without timezone problems, etc. That's all that matters. > The conclusion of our discussions was that we > apparently didn’t even agree on the premises, so that the discussion > should restart at a more fundamental level. That doesn't sound like moving forward to me. Agreeing on conclusions should be enough. We don't need to see eye-to-eye on everything. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Follow-up on the “Proposal: minimal base system”
[2019-03-17 19:07:23 +0100] Bruno Pagani via arch-dev-public: > This is a follow-up on the last month discussion about a “minimal base > system”. Creating a new thread removed from the discussion we had a month ago just makes it so much harder for all of us to remember what everyone's arguments and counter-arguments were. Please do not do this. For my part, I thought we had reached consensus with Allan's message: https://lists.archlinux.org/pipermail/arch-dev-public/2019-February/029471.html Summary: You propose what you want your new group to be (metapackage, list of dependencies, etc.) and we adopt this as the new base. If that is not satisfactory to you, please reply to that specific message and say why. That would have been far more constructive than your present message which rehashes some of the discussion we've already had and adds new questions I have no idea where you're going with. > From this discussion and parallel ones that happened on IRC, Not everyone is awake all the time, which is why decisions are made on this very list, not on IRC. New arguments should have been posted to the previous thread. > Before going further on any proposal in those directions, I’ve thought > it surely requires more input, and not only from the ~10 people at most > that already participated in those discussions It's probably safe to guess that people who haven't participated so far just aren't interesting in participating. Besides, I think you'd have more feedback and clear answers to a concrete proposal. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] A contrib repository
[2019-03-13 23:46:10 +0100] Morten Linderud via arch-dev-public: > There is a *lot* of small tools people have written over the years that > resides > in bin/ directories which could be useful for more people. We also have > several > such tools on soyuz, where sogrep was added to devtools this week. > > I have been thinking it could be great to have a simple `contrib` repository > where every team member has commit access. This could work as a staging area > for > tools we would like to promote to `devtools` later on. > > We could maybe sort this into directories for its purpose: > * packaging > * security > * devops > * testing > * bugwrangler > * misc > > Tools that can be added here is the `ch` scripts from Bluewind, and the pkg-* > tools eli has created. I also have some tools to look for pkgname in archweb, > check them out from svn and check them against a nvchecker file. > > This would hopefully give us a space where we can experiment with new > maintainer > tools in a collaborative manner. I'd love to hear some feedback or thoughs on > this! I think it's a great idea but it needs a solid maintainer. Without a clear leader it's (probably) going to be a free for all and we'll drown under bikeshedding issues within a month. But of course that doesn't mean we'd lose anything trying anyhow. Among other things, I'd personally like to see the repo maintainer enforce sensible and consistent naming for the tools, preferring longer, explicit names over shorter ones. For instance, I'm sure many of us have one-letter scripts and if we contribute them all there's bound to be collisions along with the problem of not knowing at first glance what each tool does. We could maintain a bash alias file containing everyone's favorite nickname for each tool. My two cents. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Proposal: minimal base system
[2019-02-13 08:55:27 +1000] Allan McRae via arch-dev-public: > On 13/2/19 8:17 am, Levente Polyak via arch-dev-public wrote: > > On 2/12/19 7:16 PM, Gaetan Bisson via arch-dev-public wrote: > >> [2019-02-12 16:40:08 +0100] Bruno Pagani via arch-dev-public: > >>> Just in case it wasn’t clear, my answer would have been mostly the same > >>> as Eli’s. > >>> > >>> So, Gaetan, Allan and Bartłomiej (or anyone else for that matter), do > >>> you have further comments/questions regarding this, does the existence > >>> of the base group alongside the arch/minimal-system now makes sense or > >>> would you still prefer to go without it? > >> > >> Allan and I have both stated that we don't want to introduce a new group > >> since we believe it would be highly redundant with base. > >> > >> Nothing new has been said since our last messages except Eli's post > >> which argues that the base group is largely inadequate in its current > >> state. This further supports our proposal that base should be improved > >> instead of introducing a new group. > >> > >> So I really don't see what arguments could have changed our minds... > >> It's also strange to me how you can concur with Eli's post without > >> agreeing with our conclusions. > >> > >> To go forward I suggest you propose a clear definition of the perfect > >> "minimal system" group you'd want to have, along with a proposed list of > >> packages. When consensus is reached, we adopt this list of packages for > >> base and put this definition on the wiki. > >> > >> Cheers. > >> > > > > To make it as short as possible, the idea is not just to strip down the > > base group further but primarily to not use a group in the first place. > > It should be replaced with something that is consistent within itself > > over the whole lifetime of the system. > > Groups are the wrong tool for such a set: you explicitly install all > > those packages so they won't automatically be mark as not-required > > anymore once removed from that group, as well as new additions are not > > consistent during the lifetime of the system. > > We are clear about that. Call it a group or metapackage or whatever, > the objection is having the current base and the new "group" at the same > time. My thoughts exactly. What Bruno said is fine as long as the current base group is removed first. Calling the new metapackage "base" sounds logical to me but anything else like "minimal-system" is fine too. Cheers. -- Gaetan
Re: [arch-dev-public] Proposal: minimal base system
[2019-02-12 16:40:08 +0100] Bruno Pagani via arch-dev-public: > Just in case it wasn’t clear, my answer would have been mostly the same > as Eli’s. > > So, Gaetan, Allan and Bartłomiej (or anyone else for that matter), do > you have further comments/questions regarding this, does the existence > of the base group alongside the arch/minimal-system now makes sense or > would you still prefer to go without it? Allan and I have both stated that we don't want to introduce a new group since we believe it would be highly redundant with base. Nothing new has been said since our last messages except Eli's post which argues that the base group is largely inadequate in its current state. This further supports our proposal that base should be improved instead of introducing a new group. So I really don't see what arguments could have changed our minds... It's also strange to me how you can concur with Eli's post without agreeing with our conclusions. To go forward I suggest you propose a clear definition of the perfect "minimal system" group you'd want to have, along with a proposed list of packages. When consensus is reached, we adopt this list of packages for base and put this definition on the wiki. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Proposal: minimal base system
Bruno, We all seem to agree that [base] plays no satisfactory role in its current state, so I think Allan definitely has a point: let us first turn [base] into something useful, and only then wonder if we need something more. [2019-02-05 14:38:26 +0100] Bruno Pagani via arch-dev-public: > Le 05/02/2019 à 12:54, Allan McRae a écrit : > > If someone knows they want to set up logical volumes and drive > > encryption, then they know enough to install lvm and cryptsetup. Same > > with jfsutils, xfsutils. So I don't think they should be in the base > > group (e.g. I would not call jfsutils a standard tool). > > Maybe. As I said in my answer to Bartłomiej, I don’t know if beginners > know enough things to install what they need beyond the minimum system, > or if they just read the wiki about doing this or that, which might > assume they have the current base group installed. Then the wiki should just be updated to say: "first, install jfsutils." It's up to the wiki to document the project, not up to the project to follow the wiki's rule. > > If we remove the excess from base, then we are down to a very small > > difference between that and archlinux-system. Only e2fsprogs, man, and > > an editor different? > > > > So I see the proposed archlinux-system group being essentially what base > > should be. > > That is because you see base as the minimal system. > So I’ll turn this > differently: do you have objections against having, outside of the > minimal meta-package described in our proposal, a packages group of > “relatively standard” tools, that is purposed at beginner wanting to > have only one simple pacstrap command to issue in order to get started? Yes because those two things seem the same to me. Or at any rate their difference is too small to be worth the distinction. Perhaps I'm not understanding what exact roles you envision for [base] and [minimal- system]; it would help to know exactly what packages you would put in the former and not the latter. Allan suggested e2fsprogs, man, and vim. We can certainly agree that three is too few to warrant creating two distinct groups. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Proposal: minimal base system
[2019-01-21 18:58:54 -0500] Eli Schwartz via arch-dev-public: > On 1/21/19 6:53 PM, Giancarlo Razzolini via arch-dev-public wrote: > > I agree with this package list. It's missing mkinitcpio though. > > No it is not, mkinitcpio is definitively not needed. > > It's only required in order to execute the pacman hooks for a linux > kernel package (or do so manually). And core/linux is not required to > use archlinux, although it is required to boot it on bare metal. > > The most recent version of my PKGBUILD draft for this "base-system" > PKGBUILD (which I shared with Levente during the planning stages of this > proposal) can be found here: https://paste.xinu.at/KZmYqQwIO/ That sounds good to me but I think the name of this new virtual group needs to really emphasize its difference to the current (and future) base group more clearly. Perhaps something like `minimal-system` or anything else somebody clever than me can think of, so long as it does not include the words `base` or `core` to avoid confusion. Apart from this important bikeshedding issue, I'm all in favor of this. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] TU application process
[2018-11-06 12:13:54 +0100] Bruno Pagani via arch-dev-public: > Le 06/11/2018 à 11:37, Allan McRae a écrit : > > But because you asked my opinion, I think a TU council is > > a really, really, really bad idea. No need to set some TUs above > > others. > Well some already are, because they are devs too. I do not understand this. When TUs vote, those who also happen to be devs only have one ballot each, just as any other TU. So how are they "set above" others? Being a dev does not grant you any extra TU powers, does it? > > We have never had a formal hierarchy in the developers (apart > > from our glorious leader), > Here again I would argue that they are devs that have [core] pushing > rights, as well as devs that are Master Key holders. So even if you > don’t want to write this black on white, this actually means a small > group of people have the real control over the distro (technically, > Master Key holders could revoke everyone else). I personally see the holding of master keys as a bureaucratic chore which I'm glad to have other people doing. Likewise, any dev with nonzero experience on the team can have access to [core] by just asking. Contrast this false hierarchies with the fact that anyone can send an email to arch-dev-public saying "I'm going to do this; any objections?" and a lack of replies from the community means "Feel free to go ahead." So there really is no hierarchy in the sense that no specific people decide what others can and cannot do. Like Allan said, I think this system has worked very well for Arch. > > and are instead run by those who step up to > > lead what needs done. I believe that this is what makes Arch work, and > > governance would be detrimental to the distribution as a whole. > Because you think Arch work, we (as some TUs/devs) think they are a > number of issues. We have certainly not run out of things to improve, but I seriously doubt that more bureaucracy will do anything to help. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Dropping KDE4 libs
[2018-09-04 14:46:15 +0200] Bruno Pagani: > Le 25/08/2018 à 01:31, Gaetan Bisson a écrit : > > [2018-08-24 18:45:33 +0200] Bruno Pagani: > >> I have a ready PKGBUILD > >> (https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=scribus-devel) > >> that I can push (after changing the pkgname) if scribus is moved to > >> [community]. And we can co-maintain it there, co-maintaining is the new > >> sexy. ;) > > It's already in [community]. :) > > > >> I can build into [community-testing] first so that people can check they > >> don’t have issue with it (I don’t, but once again I only work on a small > >> project, so I did not test everything). > > Sounds good to me! Feel free to go ahead with your proposed changes. > > > > Cheers. > > > Just a small heads up, scribus 1.5.4 has been in testing for the past 10 > days. ;) Not sure if we want to wait for signoffs or anything before moving. I don't believe many people sign off on packages not headed to [core]. Definitely feel free to move scribus to [community]. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Improving the package guidelines
[2018-08-29 20:20:29 +0200] Morten Linderud via arch-dev-public: > The rewrites have been up for a few months now and I intend to merge them > soon. > Feel free to still review them, either with a reply on the ML or on IRC. > Whatever > you prefer :) Sorry but I don't recall such a thing ever being discussed on this list. What rewrites are we talking about? Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Dropping KDE4 libs
[2018-08-24 18:45:33 +0200] Bruno Pagani: > I have a ready PKGBUILD > (https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=scribus-devel) > that I can push (after changing the pkgname) if scribus is moved to > [community]. And we can co-maintain it there, co-maintaining is the new > sexy. ;) It's already in [community]. :) > I can build into [community-testing] first so that people can check they > don’t have issue with it (I don’t, but once again I only work on a small > project, so I did not test everything). Sounds good to me! Feel free to go ahead with your proposed changes. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Dropping KDE4 libs
[2018-08-24 11:51:30 +0200] Bruno Pagani via arch-dev-public: > > scribus > > The develop branch (1.5.x), available as scribus-devel in the AUR (and > maintained by myself), is Qt5. It has been in development for the past 3 > years already, and still no ETA AFAIK… I’ve been using it instead of > scribus from repo for the past 2 years with no issue, but my use case is > limited w.r.t. all the possibilities this software offers. Last time I > asked about even packaging the -devel version in [community], fellow TUs > were not fond of the idea. So about replacing the repo version with it… Great idea. I have no objection and can get to it as soon as I'm back from holidays. Or if you're happy to maintain scribus in [community] yourself please do push a suitably-tested development snapshot and I'll transfer ownership of the package to you. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Away until Aug 17
[2018-07-27 15:43:22 +0200] Antonio Rojas via arch-dev-public: > Vacation time. Will be intermittently available via email/irc but won't do > any packaging. Same here though I might sporadically get some packaging done. Will be back full time from Sept 1 on. Cheers. -- Gaetan
Re: [arch-dev-public] Enforcing 2FA in GitHub organization
[2018-06-29 10:09:21 +0200] Bartłomiej Piotrowski via arch-dev-public: > 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. No worries as far as I'm concerned: I only use GitHub once every other year... -- Gaetan
Re: [arch-dev-public] New build server in the US?
[2018-04-19 21:19:43 +0200] Florian Pritz via arch-dev-public: > Some feedback on how people use soyuz would probably help a lot here. > What are your build times, how quickly do you want the result, do you > need to see live output, does the latency to the machine matter > (interactive usage?), ...? For my own limited use, short build times are what matters most: if a build is slowed down or delayed I'll likely have forgotten about it by the time it's finished. I'm glad you mentioned the Singapore server was underused. I've switched my build scripts to using it since I'm the same ping time away from it and soyuz. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Windows Subsystem Linux - Arch Linux as official container?
[2018-01-29 22:00:28 +0100] Christian Rebischke via arch-dev-public: > They even implemented a subsystem on Windows 10 for executing natively > ELF binaries on Windows. This system is based on docker images and some > nice guys from Microsoft have asked Allan and me if Arch Linux would be > interested to participate in this project. > > The steps for getting into the project are: > > * Signup in the Microsoft Appstore (we would get a free voucher if we > want to participate) as Organization (we need the ok from one of our > trademark holders for this step) > * modifying our docker container a little bit > * pushing it into the microsoft appstore Setups like this make me uncomfortable for one reason: we would not be in control of this docker image or its distribution. This officially endorsed Arch Linux image could be modified in any way Microsoft wants. I'd be really surprised if we did not grant them this right as part of agreeing to their appstore terms. Sure, we could notice the changes eventually and pull back our official endorsement, but would they have to stop using our trademark the moment we told them to? (That's not abstract paranoia either: things like this happened with sourceforge and, well, is Microsoft more trustworthy than Dice? Tough question.) On the other hand, my profound lack of interest for WSL means I truly have no idea whether this can be useful for others, so I'll vote blank. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] New dbscripts maintainer (aka: Making dbscripts great again!)
[2018-01-29 16:51:54 +0100] Florian Pritz via arch-dev-public: > Eli offered to take the lead on getting that done and also later > migrating us to git instead of svn. If there are no objections I'll help > where necessary and give him access to the dbscripts and devtools repos > in two weeks. That sounds great! -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] 2017 repository cleanup
[2017-12-18 22:20:02 +0100] Bruno Pagani via arch-dev-public: > I’m taking it too. ;) But I can’t take tclap since it’s in extra, though > this could be easily moved to [community] since hugin is the only > package depending on it. It's just moved. Enjoy! (Note: I just did a rebuild because extra2community was not happy about tclap's repos dir not having a .BUILDINFO in it. The package was last built in 2014, you see.) -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] 2017 repository cleanup
[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! :) -- Gaetan
