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 18:42:39 -0400] Eli Schwartz via arch-dev-public: > On 8/29/18 6:35 PM, Gaetan Bisson via arch-dev-public wrote: > > [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? > > The email from May 22nd that began this email thread, specifically, the > ArchWiki packaging guidelines for Python and Golang. > > You can see the work that has been done, by looking at Foxboron's User > namespace on the wiki. Ah, my mistake. I thought you were talking about general packaging guidelines, not language specific ones. Sorry for the noise. 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
Re: [arch-dev-public] Replace Gentoo mime-types with Fedora mailcap?
[2017-11-22 19:24:20 +] Jan Alexander Steffens via arch-dev-public: > I would like to propose replacing mime-types with mailcap from Fedora[3], > which is still maintained; it fixes the above bug. It's quite different from our current mime.types but sure let's try it. > and /etc/mailcap (not used by anything we have?). >From what I can see it just calls xdg-open regardless of the mime type; not sure that's very useful but it's certainly harmless. Cheers. -- Gaetan
Re: [arch-dev-public] Switching the bugtracker to Bugzilla
[2017-11-14 22:11:02 +0100] Johannes Löthberg via arch-dev-public: > My first reaction is that it'd be nice to not have a bunch of old cruft > around, For what it's worth: I completely agree. My choice would be to start over with a clean bug tracker and not migrate anything. Everyone who cares will create their account on the new tracker and every bug that matters will be recreated. And in the process we'll get rid of hundreds of very old bug no one cares about. > but if we autoclose them and we could get the migrated bugs to > have the same ID it would simplify having the old links still work with > just a simple redirect to the new URL with the same ID, If that's straightforward to implement, sure, that'd be nice. But if not I don't think it's worth patching bugzilla for. > and it would > mean that we wouldn't need to keep the current bugtracker around for the > indefinite future. We can convert the current tracker into a bunch of static pages. Personally I'd find that a very clean archival solution... Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Migrating mail server on Sunday
Hi Florian, [2017-09-02 20:33:11 +0200] Florian Pritz via arch-dev-public: > User passwords are not migrated so you will have to set the password > again on orion using `passwd`. If you have already set a password > previously but forgot it, I can remove the password for you. Can you please do that for my account: username==bisson. (I always use a ssh key to log in and have no idea what password I might have set in the past.) Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Bringing Multipath TCP kernel (linux-mptcp) to [community]
[2017-06-06 22:58:01 +0200] Baptiste Jonglez: > Since a few years, I maintain a variant of the linux kernel in the AUR [1] > that adds support for Multipath TCP [2]. The most recent version is based > on linux 4.4, and the package I maintain tries to follow the "linux" > package from [core] as much as possible. > > There is no short- or medium-term perspective to merge Multipath TCP > upstream, so I would like to bring this package to [community]. There are > already several kernel variants in the official repos, but I would like to > get some feedback before adding another one. We already have an official linux package in [core] which is very well maintained and works great for 99% of our users, so I'd really like if you tried to explain why we need another variant and why the AUR is not suitable for it anymore. As you're aware, we've had another package (linux-grsec) with a user base certainly much larger than linux-multipath come and go because upstream went another direction and nobody had the resources to fork it. I'd really like our packages to enjoy some level of support and not just go to [community] "because they can" and get dropped just as fast. What could you tell us about linux-multipath on that front? Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Improving overall experience for contributors
[2017-05-24 13:08:18 +0200] Bartłomiej Piotrowski: > How long do you expect people to be happy to send their changes to > /dev/null before they give up? Because I already met some people that > are more clever than me in every packaging related area that decided to > switch to a distribution where joining is easier. > > [...] > > We are at the point where we have needs in every area, and ad-hoc > recruitment is silly idea in 2017, where some distributions are > successfully having way smaller development team and are capable of > accepting tens of one-off contributions every week (been there, done > that). I do not propose to give up on sponsorship process entirely, I > mean that we need a place to communicate with contributors and that also > includes mentoring potential packagers. Thanks for taking the time to explain what you meant. Now that I understand your point it seems like a good one indeed. Cheers. -- Gaetan
Re: [arch-dev-public] Improving overall experience for contributors
[2017-05-23 22:23:51 +0200] Bartłomiej Piotrowski: > Another thing that I heard in last few months isthat it is actually hard > for potential TU candidates to find a sponsor. While I believe it is > perfectly fine to e-mail few potential sponsors to ask for opinion, > throwing random messages at people doesn't sound really appealing. In my opinion writing emails to strangers should be part of the application process. In my duties as packager maintainer I often find myself writing emails to various persons I've never met: other distro devs, upstream maintainers, etc. I'm sure the same goes for all of us. It's just basic communication skills. Do we need contributors this badly that we could consider accepting applicants who are too shy to write an email to a stranger? > In my humble opinion, we should rethink the way we recruit people I don't understand what you mean. In the past when we've had specific needs in particular areas, ad-hoc recruitment processes were devised to fill those needs. Shouldn't that be good enough? What kind of new process would you like to see implemented? > I also wanted to touch mailing lists vs GitHub vs Gitlab topic but we > will tackle it another time. Please do create a new thread as soon as possible; I just can't contain all my boiling thoughts on this... :) Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] OpenSSL 1.1.0
[2017-04-22 18:05:27 +0200] Sébastien Luttringer: > When do you plan to move openssl rebuild out of testing? Quoting arojas on IRC: 2017-04-20 09:11:27 arojas: current blocker for openssl if FS#53618 2017-04-20 09:11:47 arojas: someone needs to decide whether we care about it or not, and if yes do something to fix it -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Packages for adoption
[2017-04-18 08:53:07 +0200] Bartłomiej Piotrowski: > tcpdump > whois I've just adopted them; they can stay in [extra]. Cheers. -- Gaetan
Re: [arch-dev-public] AUR ToS (aka making AUR user names public)
[2017-03-07 09:05:28 +0100] Lukas Fleischer: > If we *really* think that we need to keep user names secret, I think we > should take down the whole AUR website because we already share this > information everywhere without explicitly telling our users we do so. Or > at least censor the user names on every single page they appear on which > would be a lot of work. Intent matters a lot in court. It's not just pure logic arguments. There's a big difference between showing the usernames of package maintainers, or comment posters, as users would expect, and plainly giving the whole list out to a third party --- as they wouldn't expect. Cheers. -- Gaetan
Re: [arch-dev-public] AUR ToS (aka making AUR user names public)
Dave, You appeared to have inserted some text in the middle of Lukas' message with no indication whatsoever which paragraphs are yours and which are his. I'm sure GMail can tell them apart but for those of us who use run-of-the-mill emails could you find a way to fix this behavior? I'm attaching your mail as it got into my inbox. Cheers. -- Gaetan dave.mbox Description: application/mbox
Re: [arch-dev-public] AUR ToS (aka making AUR user names public)
[2017-03-05 14:35:05 +0100] Lukas Fleischer: > My original questions was: Are we fine with sharing the list of AUR > accounts names (only user names, no real names or email addresses) with > a researcher that seems trustworthy and agrees to not share the data in > any form other than the resulting anonymized statistics? I am strongly against this because it seems to me it would put us in a very weak legal position (though as always IANAL). The simple argument is that when users sign up for an AUR account they have no expectation that any data they submit (including their username) might be shared with a third-party. Now as you've noticed with other Internet services, sharing data with third-parties is kind of a big deal. To the point that many services can only be used after you've agreed to some kind of EULA where you consent to your data being shared. For us it's even worse, there's no EULA, just what users might expect us to do with their data. So please let's err on the safe side here. Surely there's tons of other username lists on the Internet this researcher can use... Cheers. -- Gaetan
Re: [arch-dev-public] Dropping cdrkit, replacing with cdrtools
[2017-01-21 00:39:52 +0100] Jan de Groot: > Since we're dropping dead packages, I have one package remaining on the > "missing sources" todo list: cdrkit. > > Given the fact that Debian has forked an old cdrtools release, applied > some patches and then abandoned the project completely, I would like to > remove it and replace it with the original software which is still > developed. Sounds good to me. > cdrtools is already in community, so it only needs a move to extra. > It's already a drop-in replacement for cdrkit, so we can handle the > dependencies later. > > Last note: only thing that keeps me from moving this right now is the > maintenance. The current maintainer in community has maintained this > package for 5 years with regular updates and does a good job > maintaining his packages. It would be nice if he could continue > maintaining the package, but I think it's good to have mkisofs and > cdrecord in extra instead of community. Any thoughts about this? It really makes no difference if mkisofs and cdrecord (or most packages for that matter) are in [community] rather than [extra]. Cheers. -- Gaetan
Re: [arch-dev-public] Phasing out webkitgtk{,2}
[2017-01-18 22:42:38 +] Jan Alexander Steffens via arch-dev-public: > WebkitGTK+ 2.4 has been unmaintained for quite a while, and lots of CVEs > have accumulated. The last release fixing CVEs, 2.4.10, only fixed about > half the vulnerabilities known, and that release was only made because > 2.4.9 was broken with GTK+ 3.20, and Evolution quickly needed a working > HTML renderer. > > For more information about the WebKit situation, take a look at > https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/ > > We currently have the following packages depending on webkitgtk: > > webkitgtk > ├─balsa > ├─eclipse-common > │ ├─eclipse-cpp > │ ├─eclipse-java > │ ├─eclipse-jee > │ └─eclipse-php > ├─empathy > ├─geary > ├─gnome-web-photo > ├─gtkpod > ├─liferea > ├─midori > ├─uzbl-core > │ └─uzbl-browser > │ └─uzbl-tabbed > ├─variety > ├─webkitgtk-sharp > │ └─sparkleshare > └─xombrero > > And, for webkitgtk2: > > webkitgtk2 > ├─atril > ├─boinc > ├─codeblocks > ├─dwb > ├─geany-plugins > ├─gnucash > ├─gphpedit > ├─guitarix2 > ├─java-openjfx > │ └─pdfsam > ├─java-openjfx-doc > ├─java-openjfx-src > ├─luakit > ├─midori-gtk2 > ├─moneymanagerex > ├─osmo > ├─pan > ├─perl-gtk2-webkit > ├─python2-deepin-utils > │ └─python2-deepin-ui > │ ├─deepin-game > │ └─deepin-music > ├─pywebkitgtk > │ ├─python2-deepin-ui > │ ├─python2-deepin-utils > │ ├─python2-jswebkit > │ │ └─deepin-game > │ └─screenlets > │ └─screenlets-pack-basic > ├─surf > └─webkit-sharp > ├─blam > └─mono-tools > > To protect our users we should try to limit the packages using > webkitgtk(2)., with the goal of eventually getting rid of it completely. I > propose making a TODO that covers all these packages, with the following > policy: > >- If it can be updated to webkit2gtk, do so. >- Otherwise, if WebKit is an optional dependency, build without it. >- Otherwise, consider removing the package, especially if it's a browser. > > Thoughts? Sounds good to me. I know many of us won't be happy to see packages we rely on dropped to the AUR, but it's either that or a myriad of security holes: the choice is clear to me. Cheers. -- Gaetan
Re: [arch-dev-public] [RFC] pyalpm maintainership
[2016-12-24 20:18:21 +0100] Jelle van der Waa: > I'd like to see some improvements in the maintenance of pyalpm. I'm not sure what improvements you have in mind but there's two things called pyalpm: Remy's personal git repo (projects:users/remy/pyalpm.git) and our package. I'm assuming you're thinking of the repo. Why not fork it? If a fork is demonstrably better it would surely convince Remy to merge the changes back into his personal repo. Or if Remy is unavailable we could even decide to use the fork as upstream for our pyalpm package. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Shadowing i686, round 1
[2016-12-12 21:51:31 +0100] Bartłomiej Piotrowski: > In September we discussed upgrading the default -march value for > packages to include SSE2 (and possibly more instructions). I think the > general consensus was that we don't agree what we should do and we just > left the problem intact. > > Semi-necrobumping that thread, I want to bring back one proposal – let's > deprecate i686 architecture. All my machines at home and work are > x86_64. Building i686 packages is a chore I'm less and less willing to > do, and I boot up a 32-bit virtual machine only if bug has been reported > against that architecture. No, I don't do even smoke tests – I assume > that i686 works if x86_64 does. (Don't beat me up too hard for that.) > > To back up my idea, our completely unreliable pkgstats data says that > 8.53% came from i686 installs, but only a little over 4% is incompatible > with amd64. Obviously there is no way to verify this data, but I suspect > that these numbers are even lower in the reality. We're just wasting our > time. > > I'd like to set a certain date of dropping i686 completely. During that > time, community and/or interested packagers could come up with either > automated build solution, making it "tier 2" architecture. Otherwise it > would just die of natural cause. That sounds great to me. How about June 1st, 2017? It's about six months for now, surely that's enough time to see things coming for those who still care about i686. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] todo list for moving http -> https sources
[2016-11-01 09:55:11 -0400] Dave Reisner: > On Mon, Oct 31, 2016 at 04:09:40PM -1000, Gaetan Bisson wrote: > > [2016-10-31 10:05:26 -0400] Dave Reisner: > > > On Sun, Oct 30, 2016 at 04:43:04PM -1000, Gaetan Bisson wrote: > > > > I agree with Sébastien. We should encourage upstream to digitally sign > > > > their releases, and verify their authenticity in our PKGBUILDs. > > > > > > > > Downloading releases over HTTPS gives a false sense of security: > > > > everybody knows the CA model is severely broken. In terms of security > > > > this simply does not compare with OpenPGP... In my view, switching our > > > > download links to HTTPS is nothing but an annoyance. > > > > > > The CA model is broken. http clients have bugs. http servers have bugs. > > > pgp has bugs. sovereign states might be snooping on connections. None of > > > these are reasons to avoid an attempt at providing another layer of > > > security. That's all TLS is and I'm not suggesting it's some panacea. > > > > > > Asking every upstream to provide a PGP signature isn't a process which > > > will scale, and some of them will likely not be interested in doing such > > > a thing. If an upstream won't provide PGP signatures, do you have > > > another suggestion as to how we can secure our process of obtaining > > > upstream sources in a reliable manner? > > > > All the nuances in my message were apparently lost on you... > > > > I said OpenPGP provides a much higher degree of security than HTTPS, so > > that's what we should strive to use. Obviously, for cases where digital > > signatures aren't available, downloading sources over HTTPS is better > > than nothing. What I argued, however, is that it's not much better than > > nothing, so we shouldn't become complacent and trust sources just > > because they came over TLS. > > I'll take this to mean that you don't have any objections about > adding additional layers of security. My point is they're not "additional layers of security", just "additional layers". But whatever, if you feel that strongly about this, go right ahead. -- Gaetan
Re: [arch-dev-public] todo list for moving http -> https sources
[2016-10-31 15:19:40 +0100] NicoHood: > I'd also vote for https. It does not hurt to use a secure channel to > download the sources from. It would be great if we as ArchLinux team > could make the first step into that direction. > > Using PGP signatures is another discussion, also the hash algorithm. I > think we should discuss that in another post, appart from https. From my > point of view its highly important to use a strong hash function as its > highly important for the source integrity and not only meant as checksum > for corruption detection. You know HTTPS uses hash functions too, right? And you know they are in many cases much weaker than those GnuPG uses by default, right? -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] todo list for moving http -> https sources
[2016-10-31 10:05:26 -0400] Dave Reisner: > On Sun, Oct 30, 2016 at 04:43:04PM -1000, Gaetan Bisson wrote: > > I agree with Sébastien. We should encourage upstream to digitally sign > > their releases, and verify their authenticity in our PKGBUILDs. > > > > Downloading releases over HTTPS gives a false sense of security: > > everybody knows the CA model is severely broken. In terms of security > > this simply does not compare with OpenPGP... In my view, switching our > > download links to HTTPS is nothing but an annoyance. > > The CA model is broken. http clients have bugs. http servers have bugs. > pgp has bugs. sovereign states might be snooping on connections. None of > these are reasons to avoid an attempt at providing another layer of > security. That's all TLS is and I'm not suggesting it's some panacea. > > Asking every upstream to provide a PGP signature isn't a process which > will scale, and some of them will likely not be interested in doing such > a thing. If an upstream won't provide PGP signatures, do you have > another suggestion as to how we can secure our process of obtaining > upstream sources in a reliable manner? All the nuances in my message were apparently lost on you... I said OpenPGP provides a much higher degree of security than HTTPS, so that's what we should strive to use. Obviously, for cases where digital signatures aren't available, downloading sources over HTTPS is better than nothing. What I argued, however, is that it's not much better than nothing, so we shouldn't become complacent and trust sources just because they came over TLS. Cheers. -- Gaetan
Re: [arch-dev-public] todo list for moving http -> https sources
[2016-10-31 03:23:48 +0100] Sébastien Luttringer: > On Sun, 2016-10-30 at 20:55 -0400, Dave Reisner wrote: > > There's been a sizeable number of bugs filed over the past month or so > > about changin PKGBUILDs to acquire sources from https rather than http. > > Rather than continue to flood the bug tracker, would anyone mind if I > > wrote a script to find instances of this and start a TODO list? This > > would, of course, be low priority. Even if no one does anything, we at > > least have a statement of work and can avoid having these "bugs" > > littered around flyspray. > > > > Unless there's strong opposition to this (and I'd be very interested to > > know why), I'll polish up my automation and create the list. > > The few BR that reached me also requested the addition of a .sig. > As I use a transparent http cache at home (2Mb/s bandwidth), so far I only > added the signature, and not the https as it breaks the cache. > > Except the confidentiality of the request, what's the point to force https? I agree with Sébastien. We should encourage upstream to digitally sign their releases, and verify their authenticity in our PKGBUILDs. Downloading releases over HTTPS gives a false sense of security: everybody knows the CA model is severely broken. In terms of security this simply does not compare with OpenPGP... In my view, switching our download links to HTTPS is nothing but an annoyance. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] i686 and SSE2
[2016-09-19 20:57:01 +0200] Balló György via arch-dev-public: > 2016-09-19 15:34 GMT+02:00 Allan McRae : > > > > If we limit our choice based on your CPU, then we need to limit based on > > the other CPU mentioned in this thread. > > > > That should not be a consideration at all. What we need to do is think > > about what make our distribution worthy of being a distribution. > > Original the selling points were rolling release, vanilla packages and > > optimised binaries. We have lost the latter. Do we want to get it back? > > > > Another option could be to keep i686 and x86_64 as is, and introduce new > architectures with automatically built optimised packages for i686 + SSE2 > or SSE3, and for x86_64 + SSE4.2 or AVX. This is something similar to your > option #4, but keeps the compatibility with all existing systems. Yes! And I vote to put you in charge of the legacy platforms so the rest of us can focus on building software that uses more than half of the transistors >90% of us own. Besides, you'll do a much better job at it than me, given it's been nearly five years I last tested an i686 binary. So I say we create a new architecture that includes all extensions available on >90% of currently available hardware, make that our primary architecture, and let people interested in legacy platforms figure out the rest of the plan. Cheers. -- Gaetan
Re: [arch-dev-public] Long out of date packages
[2016-08-06 16:10:04 +0300] Jerome Leclanche: > > https://www.archlinux.org/packages/community/any/firefox-firebug/ > > We shouldn't really be packaging Firefox extensions... It really makes no difference whether it's a browser extension or an ordinary piece of software: we simply shouldn't keep packages in our repos that we aren't able to update in a timely manner. -- Gaetan
Re: [arch-dev-public] Discussion about optional dependencies
[2016-07-19 11:13:22 +1000] Allan McRae: > My opinion is the primary binary for a > package should run out of the box. If you really need to reduce > dependencies, then a split package should be considered. That makes sense to me. -- Gaetan
Re: [arch-dev-public] signoffs are dead
[2016-07-01 21:24:47 +0200] Florian Pritz via arch-dev-public: > Am 2016-06-30 09:41, schrieb Johannes Löthberg via arch-dev-public: > > That has actually come up on IRC a lot of times over the last couple > > years, users asking how to sign-off packages / if they can help > > signing-off. > > I've already got 4 people willing to help, but nobody here voiced an opinion > on this matter yet. Do we want such tester from a dev/TU perspective? That sounds like the best idea so far. It also gives users running [testing] some kind of a purpose besides the fun of the occasional breakage. Cheers. -- Gaetan
[arch-dev-public] signoffs are dead
Dear all, For a while now packages in [testing] have gotten little to no signoffs and I've been moving mine to [core] after a week without feedback. I suspect many of you have been doing this too. Here's the signoff reports over the last ten days: - June 19: 0 signoffs - June 20: 6 from me, 4 from anthraxx - June 21: 0 - June 22: 5 from me - June 23: 2 from demize - June 24: 1 from me - June 25: 0 - June 26: 1 from me - June 27: 3 from me, 1 from eworm - June 28: 3 from heftig, 2 from arojas So I've decided to shorten the wait in [testing] to 48 hours. Many updates to [core] packages include security fixes and they have better move sooner rather than later. We used to be able to gather enough signoffs to move these within a day or two, and that's what I intend to do with or without signoffs. Any comment, and especially any other idea to fix this situation, is welcome. Cheers. -- Gaetan
[arch-dev-public] Announcement for screen-4.4.0-1
Hi, I'll post the following announcement when screen-4.4.0-1 moves to [core]. Feedback is welcome as always. Cheers. Title: screen-4.4.0-1 unable to attach old sessions As you upgrade to screen-4.4.0-1 you will be unable to reattach sessions started with earlier screen versions. Please make sure all your sessions are closed before upgrading. -- Gaetan
Re: [arch-dev-public] [PATCH 1/1] move initramfs generation from install script to pacman hook
[2016-05-18 08:42:49 -1000] Gaetan Bisson: > [2016-05-18 13:55:40 +0200] Christian Hesse: > > From: Christian Hesse > > > > Signed-off-by: Christian Hesse > > --- > > PKGBUILD | 5 + > > linux-initramfs.hook | 11 +++ > > linux.install| 4 > > 3 files changed, 16 insertions(+), 4 deletions(-) > > create mode 100644 linux-initramfs.hook > > Sorry but how is a hook better than the install scriptlet in this case? > Are there other packages that need to run mkinitcpio? Never mind. Seeing no commit message I was at loss but I was referred to an earlier discussion: https://lists.archlinux.org/pipermail/arch-dev-public/2016-May/027978.html -- Gaetan
Re: [arch-dev-public] [PATCH 1/1] move initramfs generation from install script to pacman hook
[2016-05-18 13:55:40 +0200] Christian Hesse: > From: Christian Hesse > > Signed-off-by: Christian Hesse > --- > PKGBUILD | 5 + > linux-initramfs.hook | 11 +++ > linux.install| 4 > 3 files changed, 16 insertions(+), 4 deletions(-) > create mode 100644 linux-initramfs.hook Sorry but how is a hook better than the install scriptlet in this case? Are there other packages that need to run mkinitcpio? -- Gaetan
Re: [arch-dev-public] Conclusion: DKMS modules
[2016-04-13 02:05:13 +0200] Sébastien Luttringer: > I started promoting a way to manage o-o-t modules with only dkms. > During the discussion, providing binary modules make consensus. So, I made a > concession and moved to a position close to yours, which can be sum as, if we > provide binary modules, we should provides them for all kernels. That's not at all how I understood your last message. I'm sorry you had to take a break from Arch and I apologize if my reply was part of the problem in any way, but I still think what you said goes against most of the views other developers have expressed in this thread. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] vivaldi browser in community
[2016-04-02 12:14:11 +0200] Jelle van der Waa: > On 04/01/16 at 09:17pm, Ike Devolder wrote: > > Are there any objections to bring in vivaldi browser [1] into our > > community repo once its stable is released? > > > > Vivaldi is a chromium based browser, and it is different from most other > > browser in the sense that it offers a lot more UI customizability and > > some unique features not found in other browsers. > > Does their license allow re-distributing of the binaries? > I couldn't figure much out from the information of their EULA. [1] > > Personally I don't see the benefit of having another closed-source > browser in our repos like opera. That's also my opinion. We should avoid packaging proprietary binaries unless they bring a clear benefit for our users. I'm quite sure nvidia does, for instance, but I've yet to be convinced for that new browser. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Conclusion: DKMS modules
Sébastien, [2016-03-23 22:28:36 +0100] Sébastien Luttringer: > Unexpectedly we got the most feedback from persons who are not dealing > currently with the burden of managing kernels and their modules. It's been more than two weeks since Allan's original message; everybody who wanted to contribute to this discussion has contributed. There's really no need to try and discredit the whole thread with a classical "the silent majority sides with me" fallacy. > 4) No one object to having dkms available for all modules; It's even supported > by several fellows and this is offering support for AUR and custom kernels at > almost no maintenance cost. > ==> We must provides dkms build for all modules. Except those covered by 2. Seriously, man, how do you go from "no one objects to having dkms" to "we must provide dkms"? I mean, we're all trying to have a reasonable discussion here. On this mailing list more than anywhere else. Please refrain from jumping to your own conclusions all the time, it's really annoying, in particular when you have to twist the logic of other people's arguments for that. Allan already pointed this out, but I feel like I must insist: > 5) There is no much discussion about which should be the default (a binary > flavor or dkms). I would propose a solution which let the user choose which > module he want needs by pulling a defined dep like module-$modulename. > ==> Applications should pull a generic deps to let users decide which module > he > wants (flavored or dkms). Absolutely no. We are a binary distribution. Binary should be the default. Nobody but you argued otherwise. > 6) Binary modules should be built from the dkms package. Wow! Where on earth do you get crazy stuff like that from? It's never been part of this discussion. And what purpose would his additional requirement serve exactly? I really wish you'd argue in good faith instead of simply trying to steer things your way. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Consensus: DKMS modules
[2016-03-15 19:49:25 -0400] Daniel Micay: > > To me the issue is people pushing new kernels to the repos but not > > being > > able to provide the same level of support that we have for mainline. > > Offloading out-of-tree module rebuilds to end users instead of doing > > it > > ourselves is clearly not the right solution. > > > > So I say: remove each non-mainline kernel of which the maintainer is > > unwilling to support the corresponding out-of-tree modules. After > > all, > > as Allan points out, rebuilding them is a simple script job... > > > > Cheers. > > In general, out-of-tree modules aren't compatible with linux-grsec. It > is not enough to simply rebuild them. It would require actively keeping > them compatible by maintaining patches for them and possibly working > with the upstreams for the out-of-tree modules for cases where bugs are > being uncovered rather than false positives / tweaks for compatibility. > > Some out-of-tree modules aren't going to be compatible with the chosen > configuration at all, similar to how Xen support is disabled in favour > of having the hardening features marked as incompatible with it. > > The NVIDIA driver and broadcom-wl need to be patched and and VirtualBox > is semi-incompatible with the chosen configuration. AFAIK, users would > need to rebuild the kernel with a couple options disabled for all the > VirtualBox features to work. So linux-grsec supports no out-of-tree module? No requirement on dkms for it, then. Fine by me. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Consensus: DKMS modules
[2016-03-15 10:06:22 +1000] Allan McRae: > On 14/03/16 09:07, Allan McRae wrote: > > On 13/03/16 00:52, Sébastien Luttringer wrote: > >> Please note that as an ideal target, I would have all our kernel modules > >> available via dkms _and_ via prebuilt modules for each kernel flavor we > >> provide. I read on the dev IRC that few modules could only be shipped from > >> sources. Not sure of that btw. > >> > >> For example, we could, for simplicity says that we provide pre-built > >> modules > >> only for the main kernel and dkms for all others kernels. > >> > >> What I would like is a team consensus/decision on how we handle kernel oot > >> modules not complains directed on virtualbox only. > > > > > > I vote for binary modules for all kernels in [core] and dkms versions. > > Kernels outside of [core] can have binary modules provided at the > > maintainer's choice. > > > > We are going to need more opinions here to build a consensus... To me the issue is people pushing new kernels to the repos but not being able to provide the same level of support that we have for mainline. Offloading out-of-tree module rebuilds to end users instead of doing it ourselves is clearly not the right solution. So I say: remove each non-mainline kernel of which the maintainer is unwilling to support the corresponding out-of-tree modules. After all, as Allan points out, rebuilding them is a simple script job... Cheers. -- Gaetan
Re: [arch-dev-public] Master key holders response time
[2015-12-06 08:52:04 +1000] Allan McRae: > Is it time to cycle our key holders? I vote yes. It should only be natural to step down from the responsibilities one does not anymore have the time to assume. Simply because that is in the best interests of the distro. This also includes orphaning some packages on archweb, announcing temporary inactivity, or asking to become a fellow. Many of us have consistently been doing that, and I consider it a drag for our distro that some do not. -- Gaetan
[arch-dev-public] AFK until mid-January
Hi guys, I was diving and got bit by a moray eel. Nothing too serious but my right-hand will have to be at rest for the next few weeks. Typing is slow with my left... And then I'll go on a small road trip for the holidays. So please feel free to take care of my packages while I'm AFK, likely until mid-January. Cheers. -- Gaetan
Re: [arch-dev-public] [RFC] archive.archlinux.org
[2015-10-17 21:02:00 +0200] Sébastien Luttringer: > Q: We will support old packages? > A: No. Nothing change. We already have to check when people report bugs > they upgraded their system to the last version. I note that we provide aur.archlinux.org as a service to the community, but with a big warning that AUR packages are not supported. To me, your project would be exactly the same: we'd provide an archive.archlinux.org service (with associated helper scripts) but it would come with big warnings that this is for diagnosis purposes only, and that outdated packages are not supported. Cheers. -- Gaetan
Re: [arch-dev-public] [RFC] archive.archlinux.org
[2015-10-17 21:02:00 +0200] Sébastien Luttringer: > More than one year ago[1] we started to discuss making the Arch > Rollback Machine more official. There were pros and cons and I would > give us the opportunity to move forward. I think this is great. You've now been running that project unofficially for a while anyhow, so I don't see anything left for us to do other than put our official stamp on it. The only potential reason why we wouldn't want do that is if we didn't find that project useful, but I do not think anyone here believes it isn't. I just have one question. What is "fsociety.archlinux.org" for? Could it follow our current naming scheme? Is it different from "archive.al.org"? Cheers! -- Gaetan
Re: [arch-dev-public] News item for openssh-7.0p1-1
[2015-08-13 12:34:07 +0900] Gaetan Bisson: > Oh, sure. Here's a new proposal: Better wording. Title: openssh-7.0p1 deprecates ssh-dss keys In light of recently discovered vulnerabilities, the new `openssh-7.0p1` release deprecates keys of `ssh-dss` type, also known as DSA keys. See the [upstream announcement](http://lists.mindrot.org/pipermail/openssh-unix-announce/2015-August/000122.html) for details. Before updating and restarting `sshd` on a remote host, make sure you do not rely on such keys for connecting to it. To enumerate DSA keys granting access to a given account, use: grep ssh-dss ~/.ssh/authorized_keys If you have any, ensure you have alternative means of logging in, such as key pairs of a different type, or password authentication. Finally, host keys of `ssh-dss` type being deprecated too, you might have to confirm a new fingerprint (for a host key of a different type) when connecting to a freshly updated server. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] News item for openssh-7.0p1-1
[2015-08-12 20:24:07 +0200] Jens Adam:
> Thu, 13 Aug 2015 00:03:59 +0900
> Gaetan Bisson :
>
> > Hi,
> >
> > I'd like to suggest the following piece of news to be posted when
> > openssh-7.0p1-1 lands in [core]:
> >
> >
> > The new openssh-7.0p1 release deprecates certain types of SSH keys
> > that are now considered vulnerable. For details, see the
> > [upstream
> > announcement](http://lists.mindrot.org/pipermail/openssh-unix-announce/2015-August/000122.html).
> >
> > Before updating and restarting sshd on remote hosts, if you rely on
> > SSH keys for authentication, please make sure that you have a recent
> > key pair set up, or alternative means of logging in (such as using
> > password authentication).
>
> Perhaps you could clarify that this only affects people using ssh-dss
> keys for authentication and how to check for them, e.g. "use 'grep
> ssh-dss ~/.ssh/{known_hosts,authorized_keys*,*.pub}' to find legacy
> keys".
Oh, sure. Here's a new proposal:
The new `openssh-7.0p1` release deprecates keys of `ssh-dss` type (also
known as DSA) in light of recently discovered vulnerabilities. For
details, see the
[upstream
announcement](http://lists.mindrot.org/pipermail/openssh-unix-announce/2015-August/000122.html).
Before updating and restarting sshd on remote hosts, make sure you do
not rely solely on DSA keys for connecting to it. You may enumerate DSA
keys that allow connecting to a remote account with:
grep ssh-dss ~/.ssh/authorized_keys
If you have any, ensure you have alternative means of logging in (such
a key pair of a different type, or password authentication).
Note that host keys of `ssh-dss` type are also deprecated; if you were
relying on them to connect to a server, after updating it, you will have
to confirm the fingerprint of a key of another type to reconnect.
--
Gaetan
signature.asc
Description: PGP signature
Re: [arch-dev-public] News item for openssh-7.0p1-1
[2015-08-12 23:15:34 +0200] Christian Hesse: > Gaetan Bisson on Thu, 2015/08/13 00:03: > > Hi, > > > > I'd like to suggest the following piece of news to be posted when > > openssh-7.0p1-1 lands in [core]: > > > > > > The new openssh-7.0p1 release deprecates certain types of SSH keys that > > are now considered vulnerable. For details, see the > > [upstream > > announcement](http://lists.mindrot.org/pipermail/openssh-unix-announce/2015-August/000122.html). > > > > Before updating and restarting sshd on remote hosts, if you rely on SSH > > keys for authentication, please make sure that you have a recent key > > pair set up, or alternative means of logging in (such as using password > > authentication). > > This does not only apply for public key authentication but for host keys as > well. Do we want to add a note about that? If updating your openssh client breaks connectivity to an old SSH server, that's fine, you can just roll back the openssh client, fix things, and update later. The only issue is updating servers. But host keys are not a problem because sshdgenkeys.service generates all key types. If a user deliberately chose to only trust a DSS key (by default, it would have been RSA keys) then they just have to "blindly" trust a key of another type to connect to the updated server. That does not sound like a big issue to me. Cheers. -- Gaetan signature.asc Description: PGP signature
[arch-dev-public] News item for openssh-7.0p1-1
Hi, I'd like to suggest the following piece of news to be posted when openssh-7.0p1-1 lands in [core]: The new openssh-7.0p1 release deprecates certain types of SSH keys that are now considered vulnerable. For details, see the [upstream announcement](http://lists.mindrot.org/pipermail/openssh-unix-announce/2015-August/000122.html). Before updating and restarting sshd on remote hosts, if you rely on SSH keys for authentication, please make sure that you have a recent key pair set up, or alternative means of logging in (such as using password authentication). -- Gaetan
Re: [arch-dev-public] [core] build failures
[2015-08-12 20:42:21 +1000] Allan McRae: > Failure in package(): > FAIL: ldns - build failed It works for me. Do you build from trunk? -- Gaetan
Re: [arch-dev-public] Fwd: Non-core kernel
[2015-07-19 16:37:42 +0200] Jan Alexander Steffens: > I recently noticed we have community/linux-grsec. Do we have a stance > on additional kernels? I vaguely remember some stigma against it but > not the details. Maybe I'm completely wrong. For reference, it was discussed there: https://lists.archlinux.org/pipermail/arch-dev-public/2014-April/026170.html >From what I remember, essentially, quite a few people were against officially supporting another kernel, particularly since the feature gain was not clear and it seemed like the grsec world would at some point also need to interfere with userland packages, but Daniel Micay kept replying he would take care of everything himself and that there would be no interference. > If it is agreeable, I would like to bring the ZEN kernel[1] into > either [extra] or [community]. You make it sound like that package would differ very little from our current linux package and require little additional maintenance; it really seems fine to me to bring it to [community]. Cheers. -- Gaetan
Re: [arch-dev-public] git packages and checksums
[2015-07-19 06:52:39 +0200] Jerome Leclanche: > git tags can and should be pgp-signed, especially if the upstream is > relying purely on git for releases. Is any package not covered by > that? That would certainly be the ideal way of doing things but I don't believe pacman currently knows how to verify these. Cheers. -- Gaetan
Re: [arch-dev-public] git packages and checksums
[2015-07-18 22:32:47 -0400] Dave Reisner: > Tags are more explicitly published by upstreams than commit hashes. I'm > not sure I understand the benefit of switching. Why is it preferrable to > use the "value" rather than the "pointer"? What makes it better? The commit hash is a checksum that ensures the integrity of the particular source tree you want. The tag, however, provides no information to verify the integrity. In other words, if someone hijacks your DNS resolver, github.com, or any other part of your connection to the git server, they can feed you malicious data and #tag=$version will never notice, while #commit=hash will. -- Gaetan
Re: [arch-dev-public] git packages and checksums
[2015-07-18 15:13:43 -0700] Anatol Pomozov:
> On Sat, Jul 18, 2015 at 1:04 PM, Gaetan Bisson wrote:
> > Instead I suggest we use the full commit hash. In the example above,
> > that'd become something like:
> >
> > _commit=9a50ce20ef60263a6c88c29470ce761fcc424f2d
> > source=("git://github.com/systemd/systemd.git#commit=$_commit")
> > md5sums=('SKIP')
>
> Would it be better to improve *sums=() function to work with
> directories? This will also help svn/hg based packages.
>
> A simple solution is to tar whole directory and then calculate the checksum:
>
> tar -c $DIR | md5sum
This involves file attributes, so it seems the md5sum would change any
time you do a new `git clone` even if no actual content has changed.
Also I think the commit hash is an intrinsically better value because it
is explicitly published by upstream. Just as checksums are (or should
be) published next to release tarballs.
Cheers.
--
Gaetan
[arch-dev-public] git packages and checksums
Hi,
As more of our official packages use git sources, I'd like to suggest we
always enforce some kind of checksum verification. More specifically,
I'd like us to avoid using straightforward source arrays such as:
source=("git://github.com/systemd/systemd.git#tag=v$pkgver")
md5sums=('SKIP')
Instead I suggest we use the full commit hash. In the example above,
that'd become something like:
_commit=9a50ce20ef60263a6c88c29470ce761fcc424f2d
source=("git://github.com/systemd/systemd.git#commit=$_commit")
md5sums=('SKIP')
Does that sound like a good idea?
--
Gaetan
Re: [arch-dev-public] Packages added to todo list 'Perl 5.22'
[2015-06-02 21:17:03 +0200] Florian Pritz: > On 02.06.2015 19:47, Gaetan Bisson wrote: > > What if I want perl to be in optdepends, not depends? > > Even if it is possible to put a versioned entry in optdeps (I don't > know), it wouldn't help really because pacman doesn't actually check > those. Just omit it and rebuild as always. > > I've now also updated the TODO list so this is hopefully a bit clearer. Thanks! -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] Packages added to todo list 'Perl 5.22'
[2015-06-02 08:10:43 -] Arch Website Notification: > Todo list information: > Name: Perl 5.22 > URL: https://www.archlinux.org/todo/perl-522/ > Creator: Florian Pritz > Description: > Include the following line at the end (inside) of each package() function: > > # template input; name=perl-binary-module-dependency; > > Then run makepkg-template and build as normal. Push to staging. What if I want perl to be in optdepends, not depends? Is there a clean way to do that with templates? Cheers. -- Gaetan
[arch-dev-public] Merging UID/GID database into filesystem
Dear all, Following up on the User/Group management TODO list [1], I'd like to merge the users and group from the UID/GID Database [2] into the passwd and group files our filesystem package provides. [1] https://www.archlinux.org/todo/usergroup-management/ [2] https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database We all obviously think of these UID and GID as static, and Allan even argued that they should never be removed, so it makes little sense to create them dynamically in packages' post_install scriplets, especially since their values must already be hardcoded into the PKGBUILD to avoid the new pacman warnings (even before post_install creates the UID/GID). So for those of my packages that have an entry in [2] I'd like to replace the UID/GID management part of the install scriptlet by entries in the passwd and group files in our filesystem package. And I'd also like to invite other devs to do the same. Are there any objections, comments or suggestions on that? Cheers. -- Gaetan
Re: [arch-dev-public] Packages added to todo list 'Fix source file names'
[2015-03-02 12:54:56 -0600] Dan McGee: > Future plans aside, there are 19 packages involved here. We can spend > time proposing alternate solutions without patches and complaining, or > we could just fix these packages. I'd rather write a patch myself than see tiny workarounds pile up in our PKGBUILDs. Yes, that's more work, but that's how I prefer to spend my own free time. Now I was discussing whether such a patch is viable before actually working on it. Are you interested in this discussion? -- Gaetan
Re: [arch-dev-public] Packages added to todo list 'Fix source file names'
[2015-03-02 12:28:46 -0500] Dave Reisner: > On Mon, Mar 02, 2015 at 06:49:13AM -1000, Gaetan Bisson wrote: > > > If upstream's tarball is called v0.4.1.tar.gz then I'd rather not > > override that... > > Not sure you've presented any reasoning here other than "I'm lazy". > Don't worry, I'm with you on that, but I think we can do better here > without increasing maintenance burden. My reasoning is that there's no reason to complicate our PKGBUILDs to fix something I don't consider a problem. We should really just be able to copy-paste an upstream URL; and if the filenames collide I'd rather have this fixed automatically rather than manually in every PKGBUILD. > Another option would be to teach makepkg to shard out SRCDEST by > $pkgbase, allowing source contents to be "namespaced" to a degree. We could also do what wget does: use the full URL as path. So the source file http://github.com/libfoo/v0.4.1.tar.gz would end up being downloaded as $SRCDEST/github.com/libfoo/v0.4.1.tar.gz . That's clean and generic. Are there any tools that rely on SCRDEST and that would be disturbed by a change like this? Cheers. -- Gaetan
Re: [arch-dev-public] Packages added to todo list 'Fix source file names'
[2015-03-02 15:58:37 -] Arch Website Notification: > Todo list information: > Name: Fix source file names > URL: https://www.archlinux.org/todo/fix-source-file-names/ > Creator: Sergej Pupykin > Description: > Following packages have potential file name conflicts if you use SRCDEST in > makepkg.conf. > > Please add "$pkgname-$pkgver.tar.gz::" into beginning of URL. > > Urls like this > > https://github.com///archive/v0.4.1.tar.gz > > should be changed to > > $pkgname-$pkgver.tar.gz::https://github.com///archive/v0.4.1.tar.gz > > so source will be downloaded into unique named file. Should we really try to enforce unique tarball names? Then should we enforce unique patch names too (and anything else that might go in the source array)? If upstream's tarball is called v0.4.1.tar.gz then I'd rather not override that... -- Gaetan
