Re: [gentoo-dev] Experimental binary package hosting
On Thursday, September 23rd, 2021 at 10:11, Andreas K. Huettel wrote: > 3. an easy way to figure out if a binary package repo is suitable for > a profile / arch / ... or not, and a standard for path names > This is not so important right now, and partially also already present > There is a PROFILE data in Packages index, but it is not useful if we are going to mix multiple profiles together, like KDE/GNOME. Also currently package manager does not care about the CFLAGS / microarchitecture of the binary package, like from x86-64 to x86-64-v4. Additional metadata and matches need to be added. Thanks, Sheng Yu
Re: [gentoo-dev] Experimental binary package hosting
On Thu, Sep 23, 2021 at 7:12 AM Andreas K. Huettel wrote: > > Hi Vadim, > > > Finally it happened! > > I already planned to try to ask infra/council about sponsoring few > > servers for build farm for "official gentoo binhosts" when I had > > enough time, but fortunately, you've already did that. > > It's very good news. > > Thanks! Nice to see that this is appreciated :) > > So far I'm only using "spare time" on the machine that builds the > releng stages (amd64, x86, m68k, riscv). So no need for a big server > farm. > > > Btw, do you need any help with that? > > I'd be very happy to help with that project. > > Sure! Feel free to add yourself to the Project:Binhost wiki page. I'll > ask for an alias and a channel soon. > > The most useful steps now are only half related to actual building. I > barely know any python and am not very familiar with portage > internals... this is what in my opinion we'd need next: > > 1) a tool to manage and manipulate a binpkg/ directory tree > The main functions that I see needed are > * delete packages/versions that are not in the gentoo repository > anymore (xpak and in index file), maybe with some grace time > * merge xpak files built elsewhere into the directory (also in the > index file) eclean packages from gentoolkit does this exactly.
Re: [gentoo-dev] [GLEP78] Updating specification r2
Hi Ulrich, Sorry, I don't know why the response I sent on September 13 didn't get forward by mailing list. So I write here again. ‐‐‐ Original Message ‐‐‐ On Thursday, September 23rd, 2021 at 06:30, Ulrich Mueller wrote: > Since you haven't addressed my comments from the first round of review, > I repeat them here: > > | Given that the outer archive is uncompressed tar, every file will be > | zero-padded to a full block which adds some amount of bloat. So, could > | the signature be inlined in the Manifest file? That's also what GLEP 74 > | specifies. Using inline signature makes sense but leads to another problem: we allowed user-defined GPG commands, which gives us no control over exactly what format is generated, and how to verify it. And I do not feel hard coded "--clear-sign" and "--detach-sign" to the commands are good practices. Also this is a very limited space saver, probably only max 1kb per package. This specification only using the Manifest DATA tag format in GLEP 74: DATA ... and their definition. So the inlined signature is not applied here. > | > | Also, IIRC one of the goals of the format was to allow partial download > | of metadata. That will only work if the Manifest file will be the first > | file in the archive (or at least appear before the image archive). The metadata signature is strictly requested to be the next file after the metadata archive, so it can be used to verify metadata without need Manifest. Although the specification said that non-standard order should be supported, but this does not apply to remote fetches. The biggest problem with moving the Manifest to the head is how to write it. Since this file can only be created after all other operations have been completed. To do this, we either have to store other files in the temporary area and copy them into binary package when the Manifest is created, and double the free space requirement. (especially for those who use tmpfs to get faster IO). Or reserve space in the binary package container and overwriting it later. But since both Manifest and signature size are variable, how much space to reserve becomes an issue. Too small, the package manager needs to copy the whole package, too big will require adding a padding file. Thanks, Sheng Yu
Re: [gentoo-dev] Guidance on distributed patented software
Joshua Kinard wrote: > Hmm, it looks like dropbear is relying heavily on the ecc/ecdsa functions > provided in libtomcrypt, and that library's homepage states all its code is > public domain. Our ebuild has no bindist restrictions on that library. > Perhaps that is how dropbear, and thus Red Hat, avoids the issues with > licensing or patents? Licenses apply to implementations and patents apply to inventions/ideas. A software license can allow you to theoretically use an implementation while a patent says no you can't without licensing that right separately. The reverse is equally possible; an expired patent means that using the invention/idea is not restricted by the patent anymore, but there may still be no free/open source implementation (yet). AIUI USE=-bindist is all three variants (swlicense_says_no || patent_says_no) while USE=bindist promises that (swlicense_says_yes && patent_says_yes) is guaranteed to be true at the cost of functionality? //Peter
Re: [gentoo-dev] Experimental binary package hosting
Hi Vadim, > Finally it happened! > I already planned to try to ask infra/council about sponsoring few > servers for build farm for "official gentoo binhosts" when I had > enough time, but fortunately, you've already did that. > It's very good news. Thanks! Nice to see that this is appreciated :) So far I'm only using "spare time" on the machine that builds the releng stages (amd64, x86, m68k, riscv). So no need for a big server farm. > Btw, do you need any help with that? > I'd be very happy to help with that project. Sure! Feel free to add yourself to the Project:Binhost wiki page. I'll ask for an alias and a channel soon. The most useful steps now are only half related to actual building. I barely know any python and am not very familiar with portage internals... this is what in my opinion we'd need next: 1) a tool to manage and manipulate a binpkg/ directory tree The main functions that I see needed are * delete packages/versions that are not in the gentoo repository anymore (xpak and in index file), maybe with some grace time * merge xpak files built elsewhere into the directory (also in the index file) (imagine you have a second container that builds with same CFLAGS, but with use settings for gnome, not plasma... or with updated dependencies because of changes in gentoo.git... you want to merge the trees for distribution without having duplicate builds) 2) binary package cryptographic signing and verification Essentially we need to finish support for GLEP78; this is being worked on in RinCat's pull request https://github.com/gentoo/portage/pull/562 See also https://www.gentoo.org/glep/glep-0078.html 3) an easy way to figure out if a binary package repo is suitable for a profile / arch / ... or not, and a standard for path names This is not so important right now, and partially also already present I guess. The actual builder right now is very simple and wired up with a single daily cron job; the mirrors are only updated manually by me until bug 813528 is handled. Cheers Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP78] Updating specification r2
> On Thu, 23 Sep 2021, Sheng Yu wrote: > Hi, > I attached second revision of the new draft of GLEP78 "Gentoo Binary > Package Container Format" > Please feel free to give any comments and suggestions. Since you haven't addressed my comments from the first round of review, I repeat them here: | Given that the outer archive is uncompressed tar, every file will be | zero-padded to a full block which adds some amount of bloat. So, could | the signature be inlined in the Manifest file? That's also what GLEP 74 | specifies. | | Also, IIRC one of the goals of the format was to allow partial download | of metadata. That will only work if the Manifest file will be the first | file in the archive (or at least appear before the image archive). Ulrich signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-python/python-jwt
# Michał Górny (2021-09-23) # Ancient version from 2016 that collides with dev-python/pyjwt. # Never bumped by the maintainer. The only revdep turned out to be # false positive. # Removal on 2021-10-23. Bug #814449. dev-python/python-jwt -- Best regards, Michał Górny
