RE: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)
> Is it really still an open question whether Debian is a political> project that has opinions on non-technical topics like the board of the> FSF or the legal status of Taiwan, Palestine and Kosovo, or whether> Debian is a technical project where people of diverse backgrounds and> political opinions can work together on making a good distribution? I'm very new to the project, but for those who were unaware of this discussion, it makes the project a lot less appealing to contribute to upon hearing about it. It doesn't make any sense for a "FOSS" project to have any weight whatsoever on political on goings. To put it bluntly, political opinion shouting is repulsive, and very disappointing at best. I can probably safely say that many people who are a part of this project already work for the elite IT companies who push their garbage political agendas all day, every day. The last thing people want to do is contribute to a project in their free time that does the same thing. -Brian Thompson Best regards, Brian Thompson From: Donald NorwoodSent: Sunday, April 18, 2021 5:54 PMTo: Adrian Bunk; debian-devel@lists.debian.orgSubject: Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result) On 4/18/21 9:56 AM, Adrian Bunk wrote: > Is it really still an open question whether Debian is a political> project that has opinions on non-technical topics like the board of the> FSF or the legal status of Taiwan, Palestine and Kosovo, or whether> Debian is a technical project where people of diverse backgrounds and> political opinions can work together on making a good distribution?Excellent question. From some online postings I have read and emails I have received on thetopic, there is a growing consensus that Debian on a whole is movingfrom a quality software development organization to yet another angrypolitical leveraging machine. So on this I would say perhaps that is a valid question to put forth andto seek dialog and answers on. People on the outside are confused on thematter, and I would put forth maybe a few on the inside as well. Be well, -Donald-- ---⢀⣴⠾⠻⢶⣦⠀⣾⠁⢠⠒⠀⣿⡁ Donald Norwood⢿⡄⠘⠷⠚⠋⠀ B7A1 5F45 5B28 7F38 4174⠈⠳⣄ D5E9 E5EC 4AC9 BD62 7B05
RE: Debian Installer Bullseye RC 1 release
Looks to be fixed now. -Brian Best regards, Brian Thompson From: Andrew M.A. CaterSent: Friday, April 23, 2021 3:46 AMTo: debian-devel-annou...@lists.debian.orgCc: debian-b...@lists.debian.orgSubject: Re: Debian Installer Bullseye RC 1 release Unfortunately, the website links to media still only point to the Alpha-3 release :( All best, Andy C
Re: Regarding the new "Debian User Repository"
On Mon, Jul 05, 2021 at 12:44:15AM -0500, Hunter Wittenborn wrote: >> By the way, how many users do you currently have? > >At the time of checking there's 46 registered users. > >There's also a counter on the DUR website (bottom-right corner) that displays >the amount of users. Thanks, I haven't viewed the site yet. :) Thanks for coming to the appropriate channel to discuss this and take care of the legal side of things. -- Best regards, Brian T B.S. Computer Science 2014 (Truman State University) Minor Stasitics Minor Chemistry Minor Mathematics signature.asc Description: PGP signature
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)
On Tue, 2021-07-20 at 21:13 -0400, Polyna-Maude Racicot-Summerside wrote: > Ended up with a 3 month useless discussion regarding if this would > give > a bad impression, that we need to use node for doing development. > Later on I was working on a plugin that treated huge amount of data. > So > I introduced Vue.JS, again a three month discussion with people > saying > it's a overhead, even after explaining that you can't always do > server > side processing and serve all the data at a time. Even if people > didn't > understand a word about the global concept and the system as a whole, > they halted the project. > So I just let go my participation. > Now 4 years later, they are integrating Vue.JS and Node doing code > validation while development. > > One of the main reason some people don't want to invest time in FOSS > project is exactly because of that type of toxic situation that make > everyone look like crazy nut head. I find it pretty crazy that you think FOSS is toxic, when in reality the only toxic thing about this situation was when you labeled a discussion as "useless". They didn't want to use your technology stack four years ago. Now they do. Throwing a temper tantrum when you don't get your way isn't doing anyone else any favors. P.S. You may be the biggest hippocrit in these mailing lists. -- BT signature.asc Description: This is a digitally signed message part
Re: Debian package manager privilege escalation attack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2021-08-11 at 23:30 -0400, Timothy M Butterworth wrote: > All, > > I just ran across this article > https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested > the attacks on Debian 11 and they work successfully giving me a root > shell prompt. > > Tim Thank you for bringing this to everyone's attention. This are very real vulnerabilities. NPM has similar issues with stopping malicious packages from being published to the FTP server. They have made some improvements after they were aware of the issue, but I haven't heard any new developments at NPM about how to stop malicious packages from making it to the server. Malicious packages can and do make it into the dependency sets of popular packages. This is a problem. I don't think that any amount of human effort and attention can prevent malicious packages from making it to the FTP server. I think that AI would be better-equipped to handle the critical checks necessary for FTP upload security to be top-of-the-line. The AI couldn't just be left unchecked, though, and humans are still needed to monitor, tweak, and make sure the AI is working and behaving in a responsible manner. As far as behaving responsibly is concerned, the main issue I foresee is having the AI flag false positives, and making sure the AI doesn't evolve into something insidious. I'm not sure if that last point can exist within limited AI, because I am not an AI expert. Perhaps a workaround for users right now would be to have a user with package management sudo access, and not much else. sudo access for package managers would have to be disallowed at the root and [other] user levels. I am not even sure that this would even work for all use cases, and having a manual ad-hoc hotfix is far from ideal. What does the Debian community think about this? Also, we should notify our upstream projects, and the Linux community as a whole, of these vulnerabilities. I believe that to be a moral obligation. - -- Best regards, Brian T. -BEGIN PGP SIGNATURE- iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEUm8ATHGJyaWFuQGhh c2h2YXVsdC5pbwAKCRCDDY1y7c2GfYQuD/47aYb4u7hIZ0n8yAdfzPVHVjvYrOzc Ke7sSSHktgtsBPxWulXjwggm4/XlYlk06TEmDycr60/Ql1ncPZkZ9L2WaKUWabiy fZ3wSaN7Sd8fCM2ls4GGr6m66UiqjIYzmlJJrn3WdVQxXvuMULWPyD2yGEYbLydu QQynSkB18OzTxNtwZYEBV7y7Qe69vZBFa0jfd4kH+zLk6lbmyHLFKn8smnFVQdby uaFGynpX5faYTeY7ccBUkeveBJMUJcomDlzJZ6XbsmSvaDgX1aPJNkkOzirr8L/5 ilSzydrtifmrvkBcvcesPwEwqHp9xMExYazM7Nz1iLhqafYZHMOiwFnQDF9Tn0cW mTIEzqz5Jbk9LoBxNMxfcPAd6XHGK/zntUbNhxDGNqgnYHjeWhIKWNj6qAP8yKPp 8W1loXMoKyHeE1A4d7ILJNYczYoGz5V2QlfXgHnWgwzrATDmqs6RHmhHM4BNKYTl AQAMili65MdULWwkKjtDHube8UVxLyKxkLgfRChSrXq8mkhSb9zRyqthv5z87G84 pKeiy92TXxkV/KZfWyMX8naYnnckcA9x4FS7tLZGqPN6fqRpUNW8XM3snaW99Jbk GqlCpE1XkQXDhdb3TPd8Uo3FQAVbgce9tmec99HGhWpBrMtay4N7p1xLUQG/mbNM uyrGcXtiLlGefQ== =iA8K -END PGP SIGNATURE-
Re: Debian package manager privilege escalation attack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2021-08-12 at 07:38 +0200, Niels Thykier wrote: > Timothy M Butterworth: > > All, > > > > I just ran across this article > > https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I > > tested > > the attacks on Debian 11 and they work successfully giving me a root > > shell prompt. > > > > Tim > > > > Hi Tim, > > All of the attacks presented assumes that the local user has "sudo" > permissions to run apt and use that as the basis for escalating > privileges (not commenting on yum or snap). > > I think it is a good demonstration of how some sudo policies are too > lenient and can be exploited. Though I am not sure this is a bug in > apt, as I do not think apt ever promised to be "safe" to use from a > constrained sudo policy. > Would you agree that there is an issue with sudo access that is enabled by default on most Debian and Debian-based distributions? The bug may not be in apt, but it definitely lives somewhere. > Thanks, > ~Niels > -BEGIN PGP SIGNATURE- iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEUu9UTHGJyaWFuQGhh c2h2YXVsdC5pbwAKCRCDDY1y7c2Gfb8QD/sH4ko8qsI7Dxyf4t8oM7bRWnGeyYXG C+e/7kb8ePKXJcSIspbzlEHefsp/chqjWQnA8f3Kqjdn77eGVecxk5O7cyN0nJyC Ih3LyLvuU2CoeLsPw7+0g4Ta81sdNh22xl/M1V3Fkbg5E1AWL7dSLwuj7LzgH5Fo w/YudfGKiyZD7gtdgOP3rfae0rLsgxklUsZQOSEEHyYGuwWZRhwNimWnytKI9XC2 z4LrAxeW07e3GA/RjUWp86/+Lub7RchirCvkV2HpAFRY88mBQbHGLjskyRma3FQ4 rfkuGOQ8R34MHuth7HeSjzuKQhqQ7FRFbH5n0rPB1O20jnjbtO/0UuQ88Foha2Um +S//kLXXpPEo/52nBGnT9KmRTTaMAmqbZPTuE2F5T2hLtNBhgK8HPEcMpn7jW1vT EYYg3aoNvO6pFe0jL9gGomViS+JoCcFkXQI4xaPqkQchjOkTaQNym8alxDiZqwEk rKq8Fz3mTlMYQHpuTM9qNLPCkTWlMg+mFsEarZJcWtjrHiqIKFFPAH+G9SMqHRxD LUcU0iKcoZtBvtSnDnt8QFhwc9eWPFqitoPihliAkfORC7KMmMJ5QgEd0TN/5r6n LmyVo7n8zF2D1ZwUAty3WfWMpRgx8TC2keXsuLWyqW9EZO/PSQplO86tjzYDYWfg WgY5vDsL7eMzFg== =QmLv -END PGP SIGNATURE-
Re: Debian package manager privilege escalation attack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2021-08-12 at 10:44 +0500, Andrey Rahmatullin wrote: > On Wed, Aug 11, 2021 at 10:55:44PM -0500, Brian Thompson wrote: > > Thank you for bringing this to everyone's attention. This are very > > real > > vulnerabilities. > How are they vulnerabilities? > They are vulnerabilities because the user is susceptible to this kind of attack by default. I don't think a lot of users are security-conscious enough to prevent sudo access for commands like apt and snap. > > NPM has similar issues with stopping malicious packages from being > > published to the FTP server. > That's not what is the article about. Correct, but NPM served as an anecdote for a point I was trying to make. > Ah, so you haven't read the article. No, I read the article. - -- Best regards, Brian T. -BEGIN PGP SIGNATURE- iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEUvN8THGJyaWFuQGhh c2h2YXVsdC5pbwAKCRCDDY1y7c2GfZx5D/4i2kVC+zcYFXYad13SPPJjwIRI0pM3 PMKwdb4NIFG8eG3vurWbq/p7cUihXjahpq1xbTkifzfAnE22y9k7Sj85vDR5j2F/ Pfir09qymjLoOdmFCCRuRdraBe8bUuaWolHnHIVdT0Jif3KeRk/I6njn0ZKa0dI3 2yaA9owJPIxRUGki7OMFLwz5WdoTU4t77AHD3JiU9e1QExV/Z2AQi6twGAVqJVVY JtUan3P/NmWBsBjPxPg+zuAp3/YVPpHBS02mI3A+sHp2qzQDUQ3S9lpuEx/QuxN0 BhLynoqugG8ZQDJvymENFCvr2WYRz1/0heE/YouR9MCLpchdZidSzyTsgvj6BH9d WipAdocRzqgEWvL+vDbcnG8JKHhzGqpeny08fbMKbl/Nmm7cS781MdWtw7tmk0Nq Bs3yzneBihgi9duQrvlIncaroBv5FkoGCzNPvL8dKudA8dVLyPWG0rlPSrkRLSfs zYSVRL/D99G+f8YCz+HmPq1CYEKNxeATZI/l1qrUZq6K5yAlUWHlmEnylZILcUAm ZnAgIQnpTq/SrH8QLH/03qSZ/lqYi05Rn/Q0WOkv8g+t5I7mytvzKWu9qsZUopWg YFmVp/4+eyg1SjaCM5PCO6tv2D8AjK8UW0uzwTXT1LF+2DeM7sC8/hgIU49Ebv/T Q6ZdTfoS3cbL3g== =W0yz -END PGP SIGNATURE-
Re: Debian package manager privilege escalation attack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2021-08-12 at 11:19 +0500, Andrey Rahmatullin wrote: > On Thu, Aug 12, 2021 at 01:12:37AM -0500, Brian Thompson wrote: > > Would you agree that there is an issue with sudo access that is > > enabled > > by default on most Debian and Debian-based distributions? The bug > > may > > not be in apt, but it definitely lives somewhere. > Do you think "sudo access" itself is a "privilege escalation attack"? I do not. I think that the possibility of dangerously configured sudo access is a vulnerability. -BEGIN PGP SIGNATURE- iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEUvsITHGJyaWFuQGhh c2h2YXVsdC5pbwAKCRCDDY1y7c2GffuzD/9+1W9z3AA/DFy5HgBgV5ntSiP6hhQ4 PdybHxQ1zP7A4uZHdGV4IqsfOKWkuhnzV/dA5Rpk7pvT1iWDQgkz7uEK5HXkQT4N QCg3MeBbqdDpqG5UakVnyu+qGJ26pRyQYmq54dZOUFmNJL8uF5BwnPg7d4NWikds 0e2QrYtyaFFVaInhDHE7uM+eYQtmWSP5yXYxGy9RLjUpLB1SPqAxeR4bZxeJ2yAz 873L1VpWOHbmxsRZj6NRH6dh2o87fqAq1BcnJZrLpbm38YKIE8PKtaNjKlhFLItt hwnGPJfobrxGG4gPgwJBB2S+FP+K6kWxSSA9y1lpAo+kLZlZFENWWxnGpgBIZ2+Q DZTFM6nPkwAvWLz1rpP5tf9Kqa7ABLyHnHdNqHAd44VtihCjwFkRtzPQgoysPGux nghHMpCmdYXuen6xaPaDSvR5emy6XVuuYvEBVjGMtR4VwJsYwgLOv1hbh+yN+fTx ItpwQjOXsD0PgGPs5BjF2G2aGHiVcHLuAZ6q0JbBo+QsCC5T3cDEJyPyuImRpNUX zQ9oyA8crGO5kq/7qz1I8/mMBrbaHKtgI9sCwwOwT56EUCvN2J0VcQGgrqQ0mVEB fJnCJFGlBrixpwbrMOik/P4QtibprVh070MgATb0QunTxyJLvnC3y/1XySkRCY8j eLvWe2IBKBalmw== =4yEj -END PGP SIGNATURE-
Re: Bits from the Release Team: say hello to our studious bookworm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 2021-08-15 at 00:02 +0100, Jonathan Wiltshire wrote: > Hi, > > On 14th August 2021 we released Debian 11 "bullseye". > > There are too many people who should be thanked for their work on > getting > us to this point to list them all individually, and we would be sure > to > miss some. Nevertheless, we would like to particularly thank the > installer > team, the buildd and ftp teams, the CD team, the publicity team, the > webmasters, the Release Notes editors, porters and all the bug > squashers, > NMUers, package maintainers and translators who have contributed to > making > bullseye a great release of which we should all be proud. > > First point release > === > > As on previous occasions, we anticipate that the first point release > for > bullseye will occur in approximately one month's time. > > Please co-ordinate fixes which you would like to see included in the > point > release with the Stable Release Managers (SRMs) via a "pu" bug against > the > release.debian.org pseudopackage, including a debdiff of the current > and > proposed source packages. Remember to use reportbug unless you enjoy > crafting the metadata by hand. > > Autopkgtests continue to be crucial to migration > > > Following the release of bullseye, we can confirm that autopkgtests > (when > provided) will continue to be considered across all architectures for > migration to bookworm. In other words, the tests need to succeed on > all > release architectures for your package to migrate. > > Start working on bookworm > = > > With the start of the bookworm release cycle, you can now upload to > unstable those changes you've been holding off during the freeze. > Please do > not rush to upload everything all at once, in order to manage load on > the > buildds etc. Automatic testing migration is not yet re-enabled, but > that > will happen during the next few days. > > As with bullseye, we would ask that you co-ordinate particularly large > transitions or changes; if your plans involve major toolchain changes > or > otherwise have the potential to cause problems in unstable for a long > time > (e.g. due to FTBFS issues), please talk to us. We know that there are > a > large number of changes which have been waiting for the release to > happen > and we're keen not to stand in the way of those but would also like to > avoid a number of larger transitions becoming entangled. > > That's it for now; it is time for the celebrations to begin, whether > at a > Release Party[1] or otherwise. :-) > > Thank you everyone for all your hard work! - -- Best regards, Brian T. -BEGIN PGP SIGNATURE- iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEYccETHGJyaWFuQGhh c2h2YXVsdC5pbwAKCRCDDY1y7c2GfacLD/9hOuSji6aJQprXk05lvJ+mKHhnhCV9 jX6eEN9exJ4v+gtbD62PYoegqUScVCMYR/B49Je4CKIqlh+9EmcjwnURSBtZPA3F dP0wgO2zU9j5P4wwCdLEtY5pKYD5Guxl4pqDEvasuoJqV+1RMtyiHC6X8DUeQgJS O1QtpYgukZEsCaAcQIXFPsI3x3wgMKjiT9WNYLvccknwkEqXikZnvA2T+Dpkijsx N4MidaOf0syVD1bh3X6uiB+r2WbLdT8j0zJ8Og5dqTWsT011PKnMCf4H8z6PIxwp RsMokIabZdn1ul99PTTILPMAMD2oV8E8XMzI49++00PH5bJ14xsHBnIbguaxuDa6 aeOyCNZoWn5gKknEsG0LOkAoagkzvaUUq+ZEBOEKeqbuQDPZU9aMMrlH4gsQVXfJ LEa2h7DNSkShK7NTFugYDaRmec4YFs8CkS7BhbhEvWXaZHMYOaWBcxpzoFaxrJiQ KQfrjxlE/ddI8JFy+KsAQdmM8jE40vNeFf6H/XXrY3Zj6s5rFG87wqaxGW+iVuV/ 1BqpLhXsn8mQN9W+FPHc9zTEco1vDo3fwvDatEWktkNJM/zk2TURG/VBATBd1N+z kansOpHtQ0grEDlhVcYhKBF8XnpmphGGKt4NGN+RE6MYsSa/tErt/bgD6HksVcVa o/HMNFHI8J+PJw== =fGSa -END PGP SIGNATURE-
Re: Debian choice of upstream tarballs for packaging
On 0825, Simon Richter wrote: >Hi, > >On 8/25/21 1:21 AM, Sean Whitton wrote: > >> From my point of view, signing git tags is no less well established a >>best practice than signing tarballs -- in fact, to me, it seems *more* >>well established. > >That is ecosystem dependent. > >FWIW, I'd love to see git bundles as a source archive format -- this would >allow shipping a (signed) tag, its commit, and the tree and blob objects for >that commit as a single file that can be built in a reproducible way and allows >changes on top to be easily tracked, including the branch point. > >In the absence of an "official" upstream release tarball, using this format >also makes it clear that this is a git snapshot, so no explanation is needed >how that archive was created. Ecosystem-dependent or not, I can see being able to verify who uploaded the Git tag (or anything for that matter) as being increasingly valuably in a world where there is a lot of uncaught or ignored plagiarism. Uploaders and creators should have integrity so that their users can rely on them and be confident to deliver quality work. -- Best regards, Brian T signature.asc Description: PGP signature
Consensus on closing old bugs
I understand that the usual way to close out bug reports is having the original author do it themselves. What's the policy on closing bug reports that haven't had activity in over 6 months? Specifically I am talking about the following: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007922 Sincerely, Brian publickey - brianrobt@proton.me - 688c834d.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Consensus on closing old bugs
On Mon, 2023-02-06 at 11:51 +0100, Santiago Vila wrote: > Let the maintainers handle their bugs. > Old bugs should not be closed just because they are "old". > > For example, I have an open bug which is 26 years old: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=5898 > > and I don't see any reason to close it. Fair enough. Thanks! signature.asc Description: This is a digitally signed message part publickey - brianrobt@proton.me - 688c834d.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Bug#1030780: Maintainers wanted for softether-vpn
On Tue, 2023-02-07 at 14:23 +0100, Andrej Shadura wrote: > Package: wnpp > Severity: normal > X-Debbugs-Cc: debian-devel@lists.debian.org > > Hi all, > > I packaged SoftEther VPN back in 2020 when people in Belarus protested > against decades of > dictatorship, and they needed a safe way to communicate with the outside > world and with each > other, circumventing the state censorship. > > Since then, due to a massive crackdown on protests and repressions against > anyone remotely > involved, most of my friends have moved abroad, and I, personally, don't know > a single user of > this VPN right now. Packaging is not hard, but not super trivial either, and > requires some work to > package subsequent releases. Not using this software myself, I'm really not > in position to > continue being the maintainer, and if nobody takes it over, I will have to > orphan it eventually. > > Please let me know if you can help. > > -- > Cheers, > Andrej > Hi Andrej. The package's history sounds really interesting. I would be honored to continue maintaining it. -- Sincerely, Brian signature.asc Description: This is a digitally signed message part publickey - brianrobt@proton.me - 688c834d.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Bug#1030780: Maintainers wanted for softether-vpn
On Wed, 2023-02-08 at 05:52 -0600, Brian Thompson wrote: > On Tue, 2023-02-07 at 14:23 +0100, Andrej Shadura wrote: > > Package: wnpp > > Severity: normal > > X-Debbugs-Cc: debian-devel@lists.debian.org > > > > Hi all, > > > > I packaged SoftEther VPN back in 2020 when people in Belarus protested > > against decades of > > dictatorship, and they needed a safe way to communicate with the outside > > world and with each > > other, circumventing the state censorship. > > > > Since then, due to a massive crackdown on protests and repressions against > > anyone remotely > > involved, most of my friends have moved abroad, and I, personally, don't > > know a single user of > > this VPN right now. Packaging is not hard, but not super trivial either, > > and requires some work to > > package subsequent releases. Not using this software myself, I'm really not > > in position to > > continue being the maintainer, and if nobody takes it over, I will have to > > orphan it eventually. > > > > Please let me know if you can help. > > > > -- > > Cheers, > > Andrej > > > > Hi Andrej. The package's history sounds really interesting. I would be > honored to continue > maintaining it. > Andrej, I have packaged the latest Stable version (https://github.com/SoftEtherVPN/SoftEtherVPN_Stable/releases?page=1) locally but have some questions for you. We can connect on IRC (or wherever) outside of the mailing list if you'd like. My IRC@OFTC is brianrobt. -- Sincerely, Brian GPG fingerprint: 60B2 99C0 F893 81E0 AA81 6205 6C9B 5E73 B3E1 2C3B signature.asc Description: This is a digitally signed message part publickey - brianrobt@proton.me - 688c834d.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: Reducing allowed Vcs for packaging?
On Sun, 2023-02-26 at 14:24 +0100, Bastian Germann wrote:
> Hi!
>
> During the last weeks I had a look at the Vcs situation in Debian. Currently,
> there are eight possible systems allowed and one might specify several of them
> for
> one package. No package makes use of several Vcs references and frankly I do
> not
> see why this was supported in the first place.
>
> For the allowed systems the situation in unstable is the following:
> arch is used by 2 packages pointing to bad URLs: #1025510, 1025511.
> bzr is used by ~50 packages, half of which point to bad URLs.
> cvs is used by 3 packages, 2 of which point to bad URLs: #1031312, #1031313.
> svn is used by ~130 packages, many of which point to bad URLs.
> darcs, mtn, and hg are not used.
>
> We can see: The Vcs wars are over; with git there is a clear winner and in my
> opinion, we should remove the possibility to use most of them for package
> maintenance. It is one additional barrier to get into package maintenance and
> we should remove the barriers that are not necessary.
>
> I would like to suggest removing the possibility to specify several systems
> and
> removing all systems except bzr, svn, and git, while deprecating bzr and
> possibly svn.
> This means solving the four listed bugs and convincing the cvsd maintainer to
> switch or drop the Vcs-Cvs reference. Then, the Debian Developer's Reference
> should specify the changes in §6.2.5 and whatever parses Vcs-* in
> debian/control
> should be adapted to do the specified thing.
>
> Finally, we can drop the orphaned packages {cvs,mercurial}-buildpackage
> (see #1026433) and add deprecation notices in brz-debian and svn-buildpackage.
>
> Thanks for any comments,
> Bastian
>
It does seem like the VCS wars are over--for now. Who knows what type of
situation could force our hand to use a different VCS than Git? That future is
hard to imagine but is certainly a possibility. I think I'm understanding your
point that it would make the package maintainers lives' easier, and it does
sound like some of the packages using non-Git VCS are rotting, at least in that
regard. However, I would be hesitant to remove support for the other VCS
systems.
From my experience, whenever software engineers are actively limited for
seemingly no or little gain, they tend to turn their attention elsewhere. Also,
ripping out logic to support 7 other VCS systems stifles creativity and puts us
down a one-way street. Sure, you could argue that adding that logic back in
wouldn't be hard, but then why remove it in the first place? Wouldn't it be
more prudent just to update the non-Git packages to use Git? That's going to
have to be done anyway for a lot of them (or not).
My point is, the gain doesn't seem to be larger than the possible (and not that
probable in the near future) cost. Admittedly, it's difficult to gauge the
costs of these things.
--
Sincerely,
Brian T
publickey - brianrobt@pm.me - c8f2ec48.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
