Re: [gentoo-dev] [PATCH data/dtd] metadata.dtd: Add nimble remote-id type
> On Wed, 13 Jul 2022, Ionen Wolkens wrote: >> > Please also submit a PR to pkgcore/pkgcheck that adds support for >> > verifying these ids. This should be pretty easy to add based >> > on existing entries. >> >> We also need to document the syntax in the wiki: >> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Upstream_remote-id_types > On that note, I watch this new page for changes so I can update my own > things too (iwdevtools has ids too). Anyone hard coding these may want > to do the same. So, we have these things that must be updated: - DTD - XML schema - pkgcore (has a copy of the XML schema) - pkgcheck - soko (packages.gentoo.org) - iwdevtools - nxml-gentoo-schemas (for Emacs) Anything else? Maybe we should also list them on the wiki page, so we don't forget? Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH data/dtd] metadata.dtd: Add nimble remote-id type
On Fri, 2022-07-15 at 09:19 +0200, Ulrich Mueller wrote: > > > > > > On Wed, 13 Jul 2022, Ionen Wolkens wrote: > > > > > Please also submit a PR to pkgcore/pkgcheck that adds support > > > > for > > > > verifying these ids. This should be pretty easy to add based > > > > on existing entries. > > > > > > We also need to document the syntax in the wiki: > > > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Upstream_remote-id_types > > > On that note, I watch this new page for changes so I can update my > > own > > things too (iwdevtools has ids too). Anyone hard coding these may > > want > > to do the same. > > So, we have these things that must be updated: > - DTD > - XML schema > - pkgcore (has a copy of the XML schema) > - pkgcheck > - soko (packages.gentoo.org) > - iwdevtools > - nxml-gentoo-schemas (for Emacs) > > Anything else? > > Maybe we should also list them on the wiki page, so we don't forget? Let's add adding them to the wiki page to the TODO, so we don't forget ;-). -- Best regards, Michał Górny
[gentoo-dev] [PATCH] profiles: add "screencast" global USE
Bug: https://bugs.gentoo.org/744622
Bug: https://bugs.gentoo.org/818253
Signed-off-by: Sam James
---
profiles/use.desc | 1 +
1 file changed, 1 insertion(+)
diff --git a/profiles/use.desc b/profiles/use.desc
index 52f51fa3cdbe..aacc3a2b7a02 100644
--- a/profiles/use.desc
+++ b/profiles/use.desc
@@ -271,6 +271,7 @@ samba - Add support for SAMBA (Windows File and Printer
sharing)
sasl - Add support for the Simple Authentication and Security Layer
savedconfig - Use this to restore your config from /etc/portage/savedconfig
${CATEGORY}/${PN}. Make sure your USE flags allow for appropriate dependencies
scanner - Add support for scanner hardware (e.g. build the sane frontend in
kdegraphics)
+screencast - Enable support for remote desktop and screen cast using PipeWire
sctp - Support for Stream Control Transmission Protocol
sdl - Add support for Simple Direct Layer (media library)
seccomp - Enable seccomp (secure computing mode) to perform system call
filtering at runtime to increase security of programs
--
2.37.1
[gentoo-dev] Last rites: dev-util/docker-ls
# Sam James (2022-07-15) # No activity upstream since early 2021, uses deprecated Go eclass, # open bugs: bug #680358, bug #844694. Removal on 2022-08-15. dev-util/docker-ls signature.asc Description: Message signed with OpenPGP
[gentoo-dev] [PATCH] eclass/ruby-fakegem.eclass: guard against broken rdoc
Skip building documentation rather than generating an error when rdoc is
missing but documentation is requested. rdoc should not be missing
normally, but this is a common problem when updating from one ruby
target straight to another one. There can be a gap when eselect has not
been triggered again yet for rdoc and another core ruby package may
require rdoc. This is commonly bundler since it has a +doc USE flag.
Signed-off-by: Hans de Graaff
---
eclass/ruby-fakegem.eclass | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/eclass/ruby-fakegem.eclass b/eclass/ruby-fakegem.eclass
index 6f561f4f6a2f..64c285d70559 100644
--- a/eclass/ruby-fakegem.eclass
+++ b/eclass/ruby-fakegem.eclass
@@ -458,8 +458,13 @@ all_fakegem_compile() {
rake ${RUBY_FAKEGEM_TASK_DOC} || die "failed to
(re)build documentation"
;;
rdoc)
- rdoc ${RUBY_FAKEGEM_DOC_SOURCES} || die "failed
to (re)build documentation"
- rm -f doc/js/*.gz || die "failed to remove
duplicated compressed javascript files"
+ rdoc=$(type -p rdoc)
+ if [[ -x ${rdoc} ]]; then
+ ${rdoc} ${RUBY_FAKEGEM_DOC_SOURCES} ||
die "failed to (re)build documentation"
+ rm -f doc/js/*.gz || die "failed to
remove duplicated compressed javascript files"
+ else
+ ewarn "No executable rdoc found,
skipping documentation"
+ fi
;;
yard)
yard doc ${RUBY_FAKEGEM_DOC_SOURCES} || die
"failed to (re)build documentation"
--
2.35.1
Re: [gentoo-dev] [PATCH] eclass/ruby-fakegem.eclass: guard against broken rdoc
> On 15 Jul 2022, at 11:17, Hans de Graaff wrote: > > Skip building documentation rather than generating an error when rdoc is > missing but documentation is requested. rdoc should not be missing > normally, but this is a common problem when updating from one ruby > target straight to another one. There can be a gap when eselect has not > been triggered again yet for rdoc and another core ruby package may > require rdoc. This is commonly bundler since it has a +doc USE flag. > I worry a bit about silently skipping given it can go further and lead to e.g. unpredictably broken binpkgs. I'd probably prefer not doing +doc but I assume it's there for a reason. Anyway, the situation is what it is until we get a ruby-exec or similar, so go for it. Thanks for figuring out a workaround, as this one is often a bit painful. > Signed-off-by: Hans de Graaff > --- Best,, sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
On Mon, Jun 27, 2022 at 01:43:19AM +0200, Zoltan Puskas wrote: *snip* > First of all one of the advantages of Gentoo is that it gets it's source > code from upstream (yes, I'm aware of mirrors acting as a cache layer), > which means that poisoning source code needs to be done at upstream > level (effectively means hacking GitHub, PyPi, or some standalone > project's Gitea/cgit/gitlab/etc. instance or similar), sources which > either have more scrutiny or have a limited blast radius. I don't quite follow what you mean. Upstream for go modules is actually proxy.golang.org, or some other similar proxy, which the go tooling knows how to access [1]. > Additionally if an upstream dependency has a security issue it's easier > to scan all EGO_SUM content and find packages that potentially depend on > a broken dependency and force a re-pinning and rebuild. The tarball > magic hides this completely and makes searching very expensive. I'm not comfortable at all with us changing the dependencies like this downstream for the same reason the Debian folks ultimately were against it for kubernetes. If you make these kinds of changes you are affectively creating a fork, and that would mean we would be building packages with untested libraries [2]. *snip* > Considering that BTRFS (and possibly other filesystems) support on the > fly compression the physical cost of a few inflated ebuilds and The problem here is the size of SRC_URI when you add the EGO_SUM_SRC_URI to it. SRC_URI gets exported to the environment, so it can crash portage if it is too big. > Manifests is actually way smaller than the logical size would indicate. > Compare that to the huge incompressible tarballs that now we need to > store. > > As a proxied maintainer or overlay owner hosting these huge tarballs > also becomes problem (i.e. we need some public space with potentially > gigabytes of free space and enough bandwidth to push that to users). > Pushing toward vendor tarballs creates an extra expense on every level > (Gentoo infra, mirrors, proxy maintainers, overlay owners, users). I agree that creating the dependency tarballs is not ideal. We asked for another option [3], but as you can see from the bug this was refused by the PMS team. That refusal is the only reason we have to worry about dependency tarballs. > It also breaks reproducibility. With EGO_SUM I can check out an older > version of portage tree (well to some extent) and rebuild packages since > dependency upstream is very likely to host old versions of their source. > With the tarballs this breaks since as soon as an ebuild is dropped from > mainline portage the vendor tarballs follow them too. There is no way > for the user to roll back a package a few weeks back (e.g. if new > version has bugs), unlike with EGO_SUM. The contents of a dependency tarball is created using "go mod download", which is controlled by the go.mod/go.sum files in the package. So, it is possible to recreate the dependency tarball any time. I do not see any advantage EGO_SUM offers over the dependency tarballs in this space. > Finally with EGO_SUM we had a nice tool get-ego-vendor which produced > the EGO_SUM for maintainers which has made maintenance easier. However I > haven't found any new guidance yet on how to maintain go packages with > the new tarball method (e.g. what needs to go into the vendor tarball, > what changes are needed in ebuilds). Overall this complifates further > ebuild development and verification of PRs. The documentation for how to build dependency tarballs is in the eclass. The GOMODCACHE environment variable is used in the eclass to point to the location where the dependency tarball is unpacked, and that location is read by the normal go tooling. > In summary, IMHO the EGO_SUM way of handling of go packages has more > benefits than drawbacks compared to the vendor tarballs. EGO_SUM can cause portage to break; that is the primary reason support is going away. We attempted another solution that was refused, so the only option we have currently is to build the dependency tarballs. > > Cheers, > Zoltan > > [1] > https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/ > [1] https://go.dev/ref/mod [2] https://lwn.net/Articles/835599/ [3] https://bugs.gentoo.org/833567 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-project] gitlab accessibility
Let's keep this thread on -project, so please see my answer there. Thanks, William signature.asc Description: PGP signature
Re: [gentoo-dev] proposal
On Wed, Jul 06, 2022 at 02:42:34PM +0200, Florian Schmaus wrote: > On 04/07/2022 17.27, David Seifert wrote: > > Ultimately, all these things really matter when only the defaults > > change. Turn-right-on-red in the US is such a thing, because unless > > otherwise stated, it's the norm. Knowing our devbase, with roughly 75% > > mostly AWOL and barely reading the MLs, I don't think this idea will > > bring about the desired change. > > This sounds like you assume that the majority of Gentoo devs are OK with > other people making changes to their packages. This very well could be > true, but without an indication you never know if the maintainer feels > this way. I was on vacation when this thread started, so that's why I'm responding now. The default assumption according to the dev manual is that maintainers are not ok with others touching their packages without permission except for very trivial changes. IMO this is the safer default. https://devmanual.gentoo.org/general-concepts/package-maintainers/index.html > > > > Instead, we should really just go for > > the tag, because my feeling is that > > the default will be that most maintainers don't mind non-maintainer > > commits, except a select few territorial ones. > > It appears that we have at least two options here: > > A) Establish that the default is non-maintainer-commits-welcome, and > introduce a metadata element. This would go against the default from the dev manual, so if we go with it, which I do not recommend, we should fix the dev manual. > B) Declare the default to be unspecified and introduce two metadata > elements: and > . > > I think you are proposing A) here, but please correct me if I am wrong. > > Personally I would tend to B). But I have no strong opinion on this, as > long as some kind of signalling is established. > > How do others feel about this? I would suggest the default be consistent with the dev manual and we add a element. William signature.asc Description: PGP signature
