Re: [gentoo-dev] [PATCH] glep-0075: Update for reference implementation
On Thu, 2019-10-24 at 22:39 +0200, Ulrich Mueller wrote: > > > > > > On Thu, 24 Oct 2019, Michał Górny wrote: > > +in 2⁴ = 16 directories), and each of this directories would have > > s/this/these/ (This was there before, but can be corrected while at it.) > > > +The implementations are only required to support cutoffs being multiples > > s/The implementations/Implementations/ Both fixed in place. Since they're grammar fixes, I suppose there's no need to send v2 over it. > > > +and maintaining mirrors via ``emirrordist``. The implementation > > +supports both listed layouts, with all hash functions supported > > +by Portage and cutoffs being multiples of 4. > > In the rationale section, one reason given for the choice of the hash > algorithm (BLAKE2B) was to "avoid code duplication". Isn't that argument > moot, if all hashes supported by Portage are implemented? (Or in other > words, couldn't a faster hash function like MD5 be used?) That's a very Portage-centric thinking. Technically, today's PM needs only to be implement SHA512 and BLAKE2B. The former is legacy, so in the future we will probably throw it away and either leave BLAKE2B only, or add another new hash. In either case, BLAKE2B is the most future-proof choice today. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] RFC: UID/GID assignment for www-misc/vdradmin-am (453/453)
Hello gentoo-dev. I would like to ask to assign uid/gid 453 for the package www-misc/vdradmin-am Martin (proxy-maintainer) signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: UID/GID assignment for media-video/vdr (452/452)
Hello gentoo-dev. I would like to ask to assign uid/gid 452 for the package media-video/vdr and its many plugins media-plugins/vdr-* Martin (proxy-maintainer) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Editing RDEPEND without a new revision (again)
On Fri, 25 Oct 2019 03:03:26 +0100 Michael Everitt wrote: > Forgive my lack of git-fu, but which commit did this? Can we name & shame > the author and committer publicly, and in front of QA, so that this kind of > violation is highlighted to all, and noted for future reference? I think you can blame zlogene. I didn't use git-fu, I just searched my email logs of gentoo-commits ;) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=db5beca3 pgpXekqVjkZC7.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Editing RDEPEND without a new revision (again)
On 24/10/19 23:04, Michael Orlitzky wrote: > Here we go again. All week I've been trying to update @world. I'm trying > to troubleshoot a portage bug[0], deal with portage taking forever to > fail, and now I've got to deal with the fact that someone was too clever > to follow the PMS and replaced virtual/pam with sys-libs/pam across the > entire tree (and immediately masked the package that we all have > installed) without creating any new revisions. > Forgive my lack of git-fu, but which commit did this? Can we name & shame the author and committer publicly, and in front of QA, so that this kind of violation is highlighted to all, and noted for future reference? signature.asc Description: OpenPGP digital signature
[gentoo-dev] Editing RDEPEND without a new revision (again)
Here we go again. All week I've been trying to update @world. I'm trying to troubleshoot a portage bug[0], deal with portage taking forever to fail, and now I've got to deal with the fact that someone was too clever to follow the PMS and replaced virtual/pam with sys-libs/pam across the entire tree (and immediately masked the package that we all have installed) without creating any new revisions. Thanks to the aforementioned portage bug, I can't follow the non-PMS suggestion to update everything with --changed-deps. So I either have to live with the fact that I have a masked package (virtual/pam) installed -- which pisses portage off and makes it impossible to troubleshoot my dependency resolution problem -- or try to uninstall it and then resolve the rebuilds myself. This is how that goes: $ time emerge -puDN --tree @world These are the packages that would be merged, in reverse order: Calculating dependencies... done! [nomerge ] net-print/cups-2.2.12 [ebuild N#] virtual/pam-0-r1 The following mask changes are necessary to proceed: (see "package.unmask" in the portage(5) man page for more details) ... =virtual/pam-0-r1 NOTE: The --autounmask-keep-masks option will prevent emerge from creating package.unmask or ** keyword changes. * In order to avoid wasting time, backtracking has terminated early * due to the above autounmask change(s). The --autounmask-backtrack=y * option can be used to force further backtracking, but there is no * guarantee that it will produce a solution. real 4m37.909s user 4m35.287s sys 0m1.437s Now I re-emerge cups, and try again. Then net-fs/samba fails. Then sys-libs/libcap fails. Then sys-apps/shadow fails. Then x11-themes/slim-themes fails. And so on. These are all things that I have to sit in front of the keyboard for 4m37.909s, time and time again to deal with, all because RDEPEND was changed without a new revision. That's it, that's all I did for Gentoo today. I started out at 8am trying to fix two bugs, and I spent all of my free time today unfucking my system. Now it's 6pm and I'm out of time with nothing accomplished. I haven't even found all of the packages that I need to rebuild yet, so this is where I'll start again tomorrow, too. And it's not like this is a rare problem. Please, just follow the damned PMS and make a new revision when you change dependencies. It's not much harder to do things right, so cutting corners and wasting my whole day is pretty selfish. And as a bonus, the people who don't use portage won't think you're an asshole for telling them to fix the problem by using portage. [0] https://bugs.gentoo.org/698232
Re: [gentoo-dev] [PATCH] glep-0075: Update for reference implementation
On Thu, 24 Oct 2019 22:39:06 +0200 Ulrich Mueller wrote: > In the rationale section, one reason given for the choice of the hash > algorithm (BLAKE2B) was to "avoid code duplication". Isn't that > argument moot, if all hashes supported by Portage are implemented? > (Or in other words, couldn't a faster hash function like MD5 be used?) FWIW blake2b is faster than md5. That was one of the design goals [1]. [1] https://blake2.net/ -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 pgpOM0rnOKMot.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] glep-0075: Update for reference implementation
> On Thu, 24 Oct 2019, Michał Górny wrote: > +in 2⁴ = 16 directories), and each of this directories would have s/this/these/ (This was there before, but can be corrected while at it.) > +The implementations are only required to support cutoffs being multiples s/The implementations/Implementations/ > +and maintaining mirrors via ``emirrordist``. The implementation > +supports both listed layouts, with all hash functions supported > +by Portage and cutoffs being multiples of 4. In the rationale section, one reason given for the choice of the hash algorithm (BLAKE2B) was to "avoid code duplication". Isn't that argument moot, if all hashes supported by Portage are implemented? (Or in other words, couldn't a faster hash function like MD5 be used?) Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] uid/gid request for www-apps/redmine
OK, I will take 451 uid/gid for redmine. чт, 24 окт. 2019 г. в 21:02, Michael Everitt : > On 24/10/19 18:58, Azamat Hackimov wrote: > > Hello. > > As per https://github.com/gentoo/gentoo/pull/12807 I need UID/GID for > web-application Redmine. Could I please get those for it? Any available > number will OK. > > -- > From Siberia with Love! > > Check https://api.gentoo.org/uid-gid.txt .. give it a couple of weeks, if > nobody objects, post a confirmation.. voila! > -- >From Siberia with Love!
Re: [gentoo-dev] uid/gid request for www-apps/redmine
On 24/10/19 18:58, Azamat Hackimov wrote: > Hello. > > As per https://github.com/gentoo/gentoo/pull/12807 I need UID/GID for > web-application Redmine. Could I please get those for it? Any available > number will OK. > > -- > From Siberia with Love! Check https://api.gentoo.org/uid-gid.txt .. give it a couple of weeks, if nobody objects, post a confirmation.. voila! signature.asc Description: OpenPGP digital signature
[gentoo-dev] uid/gid request for www-apps/redmine
Hello. As per https://github.com/gentoo/gentoo/pull/12807 I need UID/GID for web-application Redmine. Could I please get those for it? Any available number will OK. -- >From Siberia with Love!
Re: [gentoo-dev] The demotivating process of contributing to devmanual
On Thu, 2019-10-24 at 12:44 -0400, Gokturk Yuksek wrote: > > I'm really glad this is resolved, and that the things started moving > > again. I'd like to thank you for all your hard work on devmanual. > > > > I'm glad we reached a compromise too. We may not always see eye to eye > but I'll always respect genuine contribution efforts. > > Just so that we're on the same page, for the future PRs I'll take a look > at the overall idea, ask one more dev to ack it (doesn't have to be a > devmanual team member), and do the changes I think are necessary post-merge. > > Just let me know if you need any further changes to the workflow. > Thank you, I believe that's all we need. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] The demotivating process of contributing to devmanual
Hi, Michał Górny: > On Tue, 2019-10-15 at 17:20 -0400, Gokturk Yuksek wrote: >> I wish you communicated this particular frustration clearly before it >> made you very angry. > > I'm sorry that I vented off here. I have explicitly requested in some > of my pull requests that you can apply any wording changes directly but > I guess it was easy to miss. > Seeing this: https://github.com/gentoo/devmanual.gentoo.org/pull/104#issuecomment-533978623 I stand corrected. I just assumed it was meant to apply for that particular PR and not in general. > I'm really glad this is resolved, and that the things started moving > again. I'd like to thank you for all your hard work on devmanual. > I'm glad we reached a compromise too. We may not always see eye to eye but I'll always respect genuine contribution efforts. Just so that we're on the same page, for the future PRs I'll take a look at the overall idea, ask one more dev to ack it (doesn't have to be a devmanual team member), and do the changes I think are necessary post-merge. Just let me know if you need any further changes to the workflow. -- gokturk signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] Removing obsolete thick Manifest compatibility from MetaManifests
Hello, TL;DR: I'd like to disable thick Manifest support in Portage, in order to disable some of the compatibility quirks from MetaManifest format. All files would still be verified by gemato. We're using GLEP 74 MetaManifests for 2 years now. The specification was originally written to account for compatibility with existing (thick) Manifest files. I believe we can start considering removing at least some of that compatibility today. What I'd like to propose is disabling thick Manifests in the rsync variant of Gentoo repository (in layout.conf). This would cause Portage to stop verifying file entries directly (on-sync verification via gemato would still happen). Notably, this would limit the needed compatibility to DIST entries. Why? 1. Thick Manifest verification happening in Portage is mostly redundant these days, and when it's not its advantages are weak. 1a. Majority of Portage users are using on-sync verification via gemato. In this case, repeated partial checks from Portage are at most redundant. 1b. While not using gemato, Portage verifies only leaf Manifests without checking the OpenPGP signature. There's no real security gain in this. 1c. With transmission-level checksumming (and filesystem-level checksums becoming more common), there is no reason to assume we need to verify integrity of rsync result. 2. Thick Manifest support in Portage is still relying on legacy entries. While technically we could either make Portage use gemato fully, or reimplement the new features, I don't think it's worth the effort given the above. 2a. Removing legacy entries from ::gentoo will make it possible to remove the backwards compatibility code from gemato. We may also remove some of the redundant code from Portage. 2b. We will gain the ability to use the new format more efficiently. In particular, I'm considering moving non-DIST entries to category-level Manifests and taking advantage of compression (but I don't know if it's going to provide real gain at the moment). 3. Thick Manifests are generally PITA to power users and developers. 3a. You need to regenerate them every time you edit an ebuild. It's like having to type 'yes, I really wanted to edit that file' every time. 3b. You need to regenerate Manifests when moving ebuilds between git and rsync checkouts. 3c. Proxied maintainers keep forgetting about that and submitting thick Manifests. WDYT? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH] glep-0075: Update for reference implementation
Fill in the reference implementation section. Reduce the requirements for cutoffs to support only multiples of 4, as there is no point in making the implementation more complex for something we aren't using anyway. Fix a typo. Signed-off-by: Michał Górny --- glep-0075.rst | 38 +- 1 file changed, 29 insertions(+), 9 deletions(-) diff --git a/glep-0075.rst b/glep-0075.rst index 31553e7..4586463 100644 --- a/glep-0075.rst +++ b/glep-0075.rst @@ -7,8 +7,8 @@ Type: Standards Track Status: Draft Version: 1 Created: 2018-01-26 -Last-Modified: 2018-12-01 -Post-History: 2018-01-27 +Last-Modified: 2019-10-24 +Post-History: 2018-01-27, 2019-10-24 Content-Type: text/x-rst --- @@ -100,11 +100,14 @@ and the policies for introducing new hashes are covered by GLEP 59 The cutoffs list specifies one or more integers separated by colons (``:``), indicating the number of bits (starting with the most significant bit) of the hash used to form subsequent subdirectory names. -For example, the list of ``2:4`` would indicate that top-level directory -names are formed using 2 most significant bits of the hash (resulting -in 2² = 4 directories), and each of this directories would have -subdirectories formed using the next 4 bits of the hash (resulting -in 2⁴ = 16 subdirectories each). +For example, the list of ``4:8`` would indicate that top-level directory +names are formed using 4 most significant bits of the hash (resulting +in 2⁴ = 16 directories), and each of this directories would have +subdirectories formed using the next 8 bits of the hash (resulting +in 2⁸ = 256 subdirectories each). + +The implementations are only required to support cutoffs being multiples +of 4. Support for other values is optional. The exact algorithm for determining the distfile location follows: @@ -296,6 +299,16 @@ relatively low complexity and being reasonably future-proof. (x — content checksum, + — filename checksum) +Cutoff values +- +The original draft allowed any cutoff values. This was changed since +multiples of 4 are much easier to implement — they can be trivially cut +from hexadecimal representation of the hash value. This representation +is commonly used by hash function implementations, including the Portage +utility functions, pkgcore utility functions (snakeoil) and ``b2sum`` +utility from coreutils. + + Layout file --- The presence of control file has been suggested in the original @@ -363,7 +376,14 @@ to an appropriate subdirectory. Reference Implementation -TODO. +The support for this specification has been implemented in Portage, +as of version 2.3.77. This includes both fetching distfiles, +and maintaining mirrors via ``emirrordist``. The implementation +supports both listed layouts, with all hash functions supported +by Portage and cutoffs being multiples of 4. + +As of 2019-10-18, the Gentoo Infrastructure team has successfully +deployed the ``filename-hash BLAKE2B 8`` layout on Gentoo mirrors. References @@ -389,7 +409,7 @@ References for each directory computed in a way to have the files distributed evenly' (https://archives.gentoo.org/gentoo-dev/message/611bdaa76be049c1d650e8995748e7b8) -.. [#PKGNAME] Jason Zamal's reply including 'using the same dir layout +.. [#PKGNAME] Jason Zaman's reply including 'using the same dir layout as the packages themselves) (https://archives.gentoo.org/gentoo-dev/message/f26ed870c3a6d4ecf69a821723642975) -- 2.23.0
