[gentoo-dev] News item: sys-apps/s6 ftrig ABI change
Hello, here's a draft for a news item I'd like to publish before bumping sys-apps/s6 to 2.8.0.0: Title: sys-apps/s6 2.8 ftrig ABI change Author: Luis Ressel Posted: 2019-03-?? Revision: 1 News-Item-Format: 2.0 Display-If-Installed:
[gentoo-dev] Package up for grab: dev-util/rebar
Hello everyone, I'm stepping down as the maintainer of dev-util/rebar, since I haven't been using it for quite a while. I already pointed this out on this very list a couple of months ago (when djc dropped erlang), but since noone else showed interest, I've dropped it to m-n now. rebar itself is EOL, but it can't be lastrited yet due to a number of revdeps. There's a successor being developed at https://github.com/erlang/rebar3, but it's not 100% compatible, so it should probably be added to the tree as a new ebuild or a new slot. Apart from a request to do this, there are no open bugs. @aidecoe: CC'ing you as the maintainer of rebar.eclass. Cheers, Luis Ressel
Re: [gentoo-dev] The status of grsecurity upstream and hardened-sources downstream
On Sun, 25 Jun 2017 23:47:48 -0400 Joshua Kinard wrote: > Safe for now to just switch to gentoo-sources while retaining hardened > toolchain? Or would there be a few additional steps needed? I only > use PaX for mprotect() and the ALSR capabilities, though I suspect > those might be in the standard sauce by now. As such, I haven't had > to deal with userland issues and PaX too much over the years. A full rebuild shouldn't be neccessary after a switch to gentoo-sources or vanilla-sources. At least, I can't think of any reason why it would, and I haven't encountered any problems after switching on my own hosts. Just keep in mind that vanilla-sources doesn't support the PaX xattrs properly (AFAIR), so if you ever want to switch *back* from vanilla to hardened, some pax markings will be missing. This shouldn't be an issue for gentoo-sources, though. Cheers, Luis Ressel pgpNbGvSbzkd0.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/
On Sun, 21 May 2017 10:46:25 -0700 Raymond Jennings wrote: > Just out of curiosity, and for the curious: > > 1. How often do cache updates happen? > 2. How long do they take? > 3. Is there any downside to only having one such update running at a > time and just skipping them if there's already an update pending? I'm generating metadata locally. There are changes to some of the more important eclasses roughly every other week; and after such a change, the regen takes 10-25 minutes on my hardware. I don't understand your question (3). Regards, Luis Ressel pgpnERfyAGpjK.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [RFC] News item: GCC 6 defaults to USE="pie ssp"
On Wed, 10 May 2017 07:28:15 + (UTC) Martin Vaeth wrote: > For instance, you cannot even compile the kernel without special > patches (which disable pie) if you use a gcc which default-enables > pie. Now I'm curious. Wouldn't that also affect the hardened gcc? I've never had any issues compiling vanilla-sources with my hardened gcc. Regards, Luis Ressel pgpcIzUTAKWA0.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On Thu, 27 Apr 2017 12:58:23 +0200 Dirkjan Ochtman wrote: > I also want to drop the following: > > - dev-lang/erlang It'd be great if whoever takes over maintainership of erlang could also take care of dev-util/rebar. Dirkjan is currently proxying it for me, but I don't use it anymore. (In fact, I'd totally forgotten I'm still the maintainer; djc has handled the updates for the past few years. Sorry about that, Dirkjan!) Regards, Luis pgpVYsgPDVd3d.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Commit signing for metadata/* repos
On Sun, 8 Jan 2017 10:40:15 -0500 Mike Gilbert wrote: > The content of gentoo-news.git should already be covered by the > detached signatures that are required to be present for each file. > What is the benefit to requiring the commits themselves be signed? Oh, I didn't know about those file signatures. But I think signing the commits would make sense nonetheless, as this offers some advantages: * Commit signatures are easy to verify: Everyone who is interested in verifying their /usr/portage image will already have an infrastructure in place to verify commit signatures, because that's how things are done for repo/gentoo.git. * The detached news signatures are nontrivial to verify (in an automated fashion): Just looping over all news files in the repo and verifying their signatures is not an option, because some of the signatures on older news items can't be verified anymore (expired keys, signatures by retired devs, etc.). Hence, one will have to write some code to verify just the new news items introduced after a git pull. * Commit signatures have slightly better security guarantees: If we only verify the detached signatures, attackers can still mess around with the commit graph; in particular, an MITM attacker could silently drop some of the news during a pull. With commit signatures, the only way for the attacker to achieve this is to pretend there aren't any new commits at all (something the user would probably notice after a while). At the same time, I don't see any disadvantages to requiring commit signatures; does anyone else? Regards, Luis Ressel
[gentoo-dev] Commit signing for metadata/* repos
Hello, there are some additional git repositories which need to be added to metadata/ subdirectories to make the 'gentoo' git repository usable for /usr/portage. Specifically, those are dtd, glsa, news and xml-schema. It'd be great if developers could sign their commits in these repos, too. (I don't really care about dtd and xml-schema, but for the other two, I think this would make much sense.) Currently, it looks like commits to xml-schema aren't signed at all, all commits to glsa are signed, and commits to the other two repos are partly signed. Regards, Luis Ressel
Re: [gentoo-dev] Proposal for changes for the next EAPI version
On Tue, 17 May 2016 13:07:43 +0530 Pallav Agarwal wrote: > Tests run in src_test are provided by upstream, and does not > guarantee that a package that has been merged will actually run on > the system. If the maintainer could add a couple small scripts to > check basic functionality of the merged package, it would make > testing for arch testers much easier and reliable. Automated post-merge tests sound kinda dangerous to me. And I don't think there's any stipulation about src_test() only running upstream-provided test suites. IMHO, src_test() would be a good place for most of the maintainter-provided tests you have in mind. Of course, there are some possible tests for which the src_test() environment isn't suitable (because they're either interactive or really need to run post-merge), I just don't expect there'd be many of them. Therefore, I think we'd be better off providing such tests out-of-band (test plans in the wiki), or perhaps stuffing them into pkg_config(). Don't get me wrong, I'm not at all opposed to your idea of easing the ATs' life, I'm just not convinced of the neccessity of EAPI changes. :) -- Regards, Luis Ressel Luis Ressel GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD
Re: [gentoo-dev] Proposal for changes for the next EAPI version
On Mon, 16 May 2016 18:13:33 +0530 Pallav Agarwal wrote: > What I'm suggesting is to add a new function post_install_test. The > function will run only if the build is being run for stabilization > (either as a part of automated stabilization, or manual) which can be > controlled by a USE flag. The function would also require independent > dependencies in case it uses external applications to test the one > being built. Could you please elaborate on this? We already have src_test() for automated tests. Why would we want to run additional tests after the package has been merged? -- Regards, Luis Ressel Luis Ressel GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD pgpBC7jG9HFAG.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Bug #565566: Why is it still not fixed?
On Wed, 24 Feb 2016 11:18:55 -0800 Raymond Jennings wrote: > As far as changelog generation, what about causing the changelogs to > be autogenerated by the end user's computer? Divide and conquer. That would require a local git clone. And that's exactly what those who still want Changelogs are trying to avoid. -- Regards, Luis Ressel pgpq6zs8rkL_V.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM
On Tue, 9 Feb 2016 07:37:10 +0100 Patrick Lauer wrote: > And now I can't figure out what I need to enable to have "rewrite" > work. Good job! > > The names match the internal module names, which is what I care about. > Figuring out if I need USE="zlib" or USE="compress" or even a combo > is a lot more effort and frustrating than having to enable the > useflag that has the name of the module. > > It might not be 'pure' or very aesthetical, but we try to get stuff > done here. > > I agree concering rewrite, USE=rewrite would be better suited for that. But zlib is a very obvious choice of USE flag, and most of the other flags I listed had (nearly) verbatim the same names as upstream's modules anyway (perl, geoip, auth_pam -> pam, auth_ldap -> ldap). I think the fact that we can use global USE's this way matters very much. If enable geoip or ldap in my make.conf, I expect packages with optional geoip/ldap support to enable this support. Also, if you wish to document this mapping in more detail, that's exactly what we have the tags in metadata.xml for. You can even write whole sentences in there! :) Regards, Luis Ressel
Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM
On Tue, 9 Feb 2016 12:22:51 +1300 Kent Fredric wrote: > The only way you could make that scheme better is having an early > stage in NGINX that shows which module are going to be built /based > on/ the USE flag combinations, and then something with savedconfig > could potentially bar building certain modules. > > > Dependency control : USE flags representing the dep > > Feature control: SavedConfig > > And then the "Feature control" could be tightened up/managed with USE > flags used more sparingly when things depended on them. > That might be useful, if the maintainer is willing to implement it. :) > The biggest downside of this is the disconnect for a user between > "What I want" and "What do I have to select to get what I want" ( For > instance, USE=pcre turning on rewrite support is weird , > Sure, that's why I said these two (image_filter and rewrite) were less obvious. I agree it'd be better to use a local 'rewrite' USE for the rewrite module. > While mgorny is more focused on "Why do I have this dependency" not > "What feature do I want" > > And this of course does nothing for us in regards to the large > collection of USE controlled SRC_URIs . > Yes, but we have those in other ebuilds, too, most of which don't use USE_EXPAND. And this thread is supposed to be about the usage of USE_EXPAND in nginx, right? > Because NGINX is monolithic, but its sources are aggregated from a > bunch of different authors for some fun reason, sort of like having a > `linux-kernel` ebuild with a SRC_URI for every single vendor name ( > *barf* ) > > I really do not envy the nginx maintainer. > Me neither. @mrueg or whoever's the maintainer: Thanks for sparing the rest of us from this insanity. :) Regards, Luis Ressel
Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM
On Tue, 9 Feb 2016 11:34:12 +1300 Kent Fredric wrote: > nginx_modules_http_lua? ( !luajit? ( dev-lang/lua:0= ) luajit? > ( dev-lang/luajit:2= ) ) This should of course also be changed to the global 'lua' useflag. Currently, you're even mixing NGINX_MODULES and normal USE flags here for maximum confusion. -- aranea
Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM
On Tue, 9 Feb 2016 11:34:12 +1300 Kent Fredric wrote: > nginx_modules_http_geoip? ( dev-libs/geoip ) > nginx_modules_http_gunzip? ( sys-libs/zlib ) > nginx_modules_http_gzip? ( sys-libs/zlib ) > nginx_modules_http_gzip_static? ( sys-libs/zlib ) > nginx_modules_http_image_filter? ( media-libs/gd[jpeg,png] ) > nginx_modules_http_perl? ( >=dev-lang/perl-5.8 ) > nginx_modules_http_rewrite? ( >=dev-libs/libpcre-4.2 ) > nginx_modules_http_secure_link? ( > userland_GNU? ( > !libressl? ( dev-libs/openssl:0= ) > libressl? ( dev-libs/libressl:= ) > ) > ) > nginx_modules_http_xslt? ( dev-libs/libxml2 dev-libs/libxslt ) > nginx_modules_http_lua? ( !luajit? ( dev-lang/lua:0= ) luajit? > ( dev-lang/luajit:2= ) ) > nginx_modules_http_auth_pam? ( virtual/pam ) > nginx_modules_http_metrics? ( dev-libs/yajl ) > nginx_modules_http_dav_ext? ( dev-libs/expat ) > nginx_modules_http_security? ( >=dev-libs/libxml2-2.7.8 > dev-libs/apr-util www-servers/apache ) > nginx_modules_http_auth_ldap? ( net-nds/openldap[ssl?] ) > Thanks for citing this, I think it demonstrates mgorny's point rather nicely; we have global USE flags for many of those modules: * nginx_modules_http_perl -> perl * nginx_modules_http_auth_pam -> pam * nginx_modules_http_auth_ldap -> ldap * nginx_modules_http_geoip -> geoip * nginx_modules_http_g(un)zip -> zlib * nginx_modules_http_secure_link -> ssl The following two ones aren't quite as obvious, but could also be changed: * nginx_modules_http_rewrite -> pcre * nginx_modules_http_image_filter -> gd Introduce new USE flags for the remaining few modules -- voilà, there you go, no need for a new USE_EXPAND and the users will even get a useful set of default modules enabled based on their global USE flags. -- Luis Ressel
Re: [gentoo-dev] GLEP 67 is in, please update your metadata.dtd!
On Mon, 25 Jan 2016 10:37:15 +0100 Michał Górny wrote: > Hello, everyone. > > I've finished the GLEP 67 transition last night, and it officially > applies to all metadata.xml files now. > Great! > In order to have repoman apply it correct (and not throw errors on new > metadata.xml files), it needs to refetch metadata.dtd. Sadly, this > currently happens once a week, so it's better to remove the file > manually to force refetch: > > rm "$(portageq envvar DISTDIR)"/metadata.dtd > I might be asking this for a second time, but why does repoman download the metadata.dtd at all? If one fetches from git://../gentoo-mirror/gentoo (or via rsync, afaik) it is included in /usr/portage/metadata/dtd/. For me, it's in fact very annoying when repoman wants to download metatdata.dtd, as my "normal" unix user isn't a member of the portage group. By the way, the herds.xml file is still available at https://api.gentoo.org/packages/herds.xml and can probably be removed from there as well. -- Regards, Luis Ressel
Re: [gentoo-dev] Herd up for grabs: gpe
On Sun, 17 Jan 2016 20:39:18 +0100 Michał Górny wrote: > On Sun, 17 Jan 2016 19:25:33 + > James Le Cuirot wrote: > > > On Sun, 17 Jan 2016 19:35:55 +0100 > > Michał Górny wrote: > > > > > The only maintainer of gpe herd is MIA for some time, and this > > > pretty much renders the whole thing maintainer-needed. > > > > > > Is anyone interested in keeping the herd as-is and maintaining all > > > packages in it? If I get no reply till 2016-01-24, I will > > > effectively remove the herd and announce the packages that landed > > > in maintainer- -needed as a result. > > > > All that stuff got masked for removal by Pacho recently anyway. > > If you mean the matchbox set, it doesn't cover all of those packages. > Unless they were masked separately. > Only x11-libs/libfakekey and x11-libs/libxsettings-client are still unmasked; both of them have additional maintainers, so nothing will have to go to maintainer-neeeded@ when the GPE herd is disbanded. By the way, x11-libs/libxsettings-client doesn't have any revdeps and looks like it could be removed along with the other GPE stuff. libfakekey still has some revdeps, though. -- Luis Ressel
Re: [gentoo-dev] ChangeLogs: Digest verification failed
On Thu, 12 Nov 2015 18:25:23 + "Robin H. Johnson" wrote: > This is being tracked in bug #565574; > > egencache it turns out updates the Manifest BEFORE writing the > ChangeLog; with predictable results if the ChangeLog is updated. > > I have put a workaround in place of forcing a regen of the Manifests > after the ChangeLogs for the moment. > Why on earth are the ChangeLogs tracked in the Manifest at all? Aren't they auto-generated by the rsync mirrors these days anyway? Manifests are nice for DIST files, but tracking ChangeLogs seems a bit useless to me. Regards, Luis Ressel
Re: [gentoo-dev] ssl vs openssl vs libressl vs gnutls USE flag foo
On Fri, 30 Oct 2015 23:40:28 +0100 hasufell wrote: > On 10/30/2015 10:16 PM, Anthony G. Basile wrote: > > On 10/30/15 3:35 PM, hasufell wrote: > >> On 10/30/2015 06:55 PM, Michał Górny wrote: > >>> We have no way of saying 'I prefer polarssl, then gnutls, then > >>> libressl, and never openssl'. > >> I don't think this is something that can be reasonably supported > >> and it sounds awfully automagic. And I don't see how this is > >> possible right now, so I'm not really sure what you expect to get > >> worse. > >> > >> E.g. -gnutls pulling in dev-libs/openssl is not really something > >> you'd expect. If we go for provider USE flags, then things become > >> consistent, explicit and unambiguous. The only problem is our > >> crappy implementation of providers USE flags via REQUIRED_USE. > >> > > I'm not sure what mgorny has in mind, but the problem I see with > > saying I want just X to be my provider system wide is that some > > pkgs build with X others don't, other pkgs might need a different > > provider. So it might make sense to order them in terms of > > preference: X1 > X2 > X3 ... and then when emerging a package, the > > first provider in the preference list that works is pulled in for > > that package. > > Isn't that basically what the proposal B already was, except that we > don't use REQUIRED_USE for it but some sort of pkg_setup/pkg_pretend > function? I don't see how those ideas even conflict. > Well, not exactly. If I understood them right, mgorny and blueness are asking for a user-supplied preference list (e.g. "I want packages to link with libressl if possible, gnutls otherwise"), not an ebuild-supplied preference list ("This package prefers gnutls, but openssl is also supported"). Side note: These ebuild-side preferences are used by some ebuilds (e.g. cyrus-sasl, it uses gdbm if both gdbm and berkdb use flags are enabled), but for ssl, we might want to specify "REQUIRED_USE = ^^ (..)" so it's possible to use USE dependencies in order to avoid namespace conflicts. If there's no REQUIRED_USE, "somelibrary[libressl]" might be satisfied even though somelibrary is actually linked to openssl. -- Regards, Luis Ressel
[gentoo-dev] Non-fast-forward push to gentoo repository
On Wednesday, someone seems to have done a --force'd push to the gentoo repository. The commits * 5e04009 sci-mathematics/minisat: rev-bump and build fixes for latest, QA cleanup * 9c9fce9 media-libs/urt: build fixes, QA cleanups, new shared lib build, SRC_URI are now missing from the repo, they were overwritten by cbb7cfa sys-kernel/tuxonice-sources: Version bumps. Was this intended? If not, @nerdboy: You might want to commit these changes again. Regards, Luis Ressel
Re: [gentoo-dev] Policies for games dirs, new group "gamestat" for sgid binaries
On Sun, 22 Feb 2015 18:17:00 +1300 Kent Fredric wrote: > For instance, perhaps a sysadmin simply wants to lock up GCC and make, > having a straight forward way do to that in bashrc would help them > achieve that, without them having to dish out a full ACL/LDAP setup, > and without then needing to retouch the perms manually every install. > And why would anyone want to lock up GCC? If an attacker can execute files he's created himself, he'll always find a way to get a compiler (or at least an assembler) up and running. And if he can't (which *would* be a sensible security feature for which implementations are available, for example grSecurity's TPE) -- well, then the GCC won't be of any help for the attacker, because he can't execute the compiled binary. Not that it matters. :) -- Luis Ressel GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD pgpXbFXj0pClM.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2015-02-22 23:59 UTC
On Mon, 23 Feb 2015 00:05:19 + "Robin H. Johnson" wrote: > The attached list notes all of the packages that were added or removed > from the tree, for the week ending 2015-02-22 23:59 UTC. > > Additions: > sys-firmware/iwl7265-ucode 2015-02-22 04:06:56 prometheanfire IIRC, just one or two months ago several of the sys-firmware/iwl*-ucode packages were lastrited with the recommendation of using sys-kernel/linux-firmware instead. So why are we adding new firmware ebuilds now? The iwl7625 firmware seems to be in linux-firmware, too. Regards, Luis Ressel -- Luis Ressel GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD pgpjS6jv4sP92.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: app-emulation/fig
On Thu, 26 Feb 2015 10:13:14 -0600 Alex Brandt wrote: > # Alex Brandt (21 Feb 2015) > # Upstream renamed to docker-compose for all future releases > app-emulation/fig > Wouldn't a pkgmove be the better way to handle this? -- Luis Ressel GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD
Re: [gentoo-dev] Figuring out the solution to in-network-sandbox distcc
On Wed, 21 Jan 2015 10:38:20 -0500 Rich Freeman wrote: > On Wed, Jan 21, 2015 at 10:00 AM, Alexis Ballier > wrote: > > On Wed, 21 Jan 2015 11:05:34 +0100 > > Michał Górny wrote: > > > >> Hello, developers. > >> > >> As you may recall, the main blocker for wide-establishment of > >> FEATURES=network-sandbox prohibiting network access within the > >> build environment is distcc. Since all connectivity is disabled, > >> distcc can no longer reach other distcc servers and build > >> efficiently. I therefore find it important to figure out a > >> solution. > >> > >> I see two generic approaches possible here: > >> > >> 1. proxying distcc from within the build environment, or > >> > >> 2. moving distcc-spawned processes back to parent's namespace. > > > > > > I haven't followed this at all, so this might be very stupid: > > Isn't it possible to whitelist distcc hosts ? > > That would only work with a proxy of some kind. > > A process running in a separate network namespace doesn't see any > network interfaces. It can't even get as far as iptables/etc for some > kind of filtering. Now, you could define an interface in the new > namespace, and then bridge that to the host network, and then apply > iptables rules to it. > Your last sentence mentions a nice possibility: 1) Connect the sandbox network namespace to the global namespace (using a veth pair?) 2) Enable forwarding (if I understand it right, it's even possible to do this for individual interfaces instead of globally, using /proc/sys/net/ipv{4,6}/conf/veth0 ) 3) Set up suitable rules in the netfiler FORWARD chain to ensure only distcc gets through 4) Set up SNAT or MASQUERADE in netfilter's nat table 5) There you go! This is beautiful because is doesn't require any userland proxies, but of course, it would be difficult to set up in an automated fashion. So my proposal would be just to stay with the status quo, and document the above in the wiki for those who really want to use both network-sandbox and distcc despite the hassle. Regards, Luis Ressel
Re: [gentoo-dev] Re: qa last rites -- long list
On Thu, 8 Jan 2015 09:16:36 -0600 William Hubbs wrote: > Rich is correct, maintainers are no longer bound by the games team > policy. > I didn't know this. If that's the case, I'd like to proxy-maintain nethack. I'll try and prepare the neccessary ebuild changes. Luis Ressel pgpDC_qIfUsBS.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On Wed, 30 Jul 2014 15:33:19 +0300 Samuli Suominen wrote: > There is no need to package.mask if proper if -logic is used, like, > for example, > > if [[ ${PV} == * ]]; then > inherit git-r3 > KEYWORDS="" > else > KEYWORDS="~amd64 ~arm ~arm64 ~x86" > fi > > Then you can just `cp foo-.ebuild foo-1.2.3.ebuild` and it'll have > the KEYWORDS > ready, and 1.2.3 and ebuilds can be identical > > That's what this thread was originally about... That's how x265's > ebuild work, just like eg. > media-libs/xine-lib or sys-fs/udev ebuilds does > > (It just seemed this was unclear to some replying in this thread.) > > - Samuli > > Thanks for the clarification. This approach seems to be the optimum. Regards, Luis Ressel signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On Wed, 30 Jul 2014 09:38:16 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > In the context of that policy and a content-touchless-bump goal, I > suppose I'd script the bump, pulling keywords from the highest > previous version, prepending the ~ as necessary and inserting them in > the keywords line after copying the file from the live-ebuild . That > wouldn't be content-touchless, but the touch would be automated so as > to avoid mistakes and unnecessary work. That proposed script reminds me of http://xkcd.com/1319/. ;) I think I'd rather go with the original workflow. Okay, perhaps package.masking - is a bit uncommon and clutters package.mask, but it's not all *that* bad and it eases the workflow. Regards, Luis Ressel signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
On Fri, 25 Jul 2014 15:23:47 -0400 Ian Stakenvicius wrote: > This is something that should only be done on a case-by-case basis, as > needed -- for instance, with virtual/krb5 only one provider can be > installed at a time as they block eachother. > > We could leave it up to portage to error on mit-krb5 and heimdal being > forced into the installation despite blocking eachother, but i think > portage would have a better chance telling end-users about the > conflict (and maybe helping to resolve it better via --autounmask?) if > there was a REQUIRED_USE. Okay, I didn't think of that. I'm not sure if the blocker deps or the REQUIRED_USE would be more helpful for Portage, but generally I think that the REQUIRED_USE error message is quite hard to understand for unexperienced users -- much more so than the error generated by a blocker dep. " The following REQUIRED_USE flag constraints are unsatisfied: heimdal? ( !mit-krb5 ) mit-krb5? ( !heimdal )" " might be a bit confusing to some people, and remember that constraint string would grow much longer if there were more providers, as grows quadratically. Regards, Luis Ressel signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
I guess that would solve some of the issues we've had with virtuals in the past. I support the idea, however, I'm not sure of the technical consequences it might have. I would leave the REQUIRED_USE out. It's a hassle to write, and if an user decides to set multiple use flags on such a virtual, why not just let him do it? Regards, Luis Ressel signature.asc Description: PGP signature
Re: [gentoo-dev] local repo kernel ebuild search for tar.bz2 instead of tar.xz
The kernel-2.eclass calls epatch_user, so AFAIK you don't have to create a local ebuild copy in order to patch the kernel, just drop your patches in /etc/portage/patches/sys-kernel/hardened-sources/. Regards, Luis Ressel signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox & network-sandbox by default
On Thu, 15 May 2014 16:48:24 +0100 Ciaran McCreesh wrote: > Sandboxing isn't about security. It's about catching mistakes. Ciaran has a point here. Thomas, you assumed that network-sandbox is the only thing stopping an ebuild from accessing local services or the internet. However, even with network-sandbox being enabled such behaviour would still constitue a major bug which would be fixed by the devs. So yes, network-sandbox (and same goes for ipc-sandbox) is mainly a debugging aid for developers which will help them spot such problems more easily. -- Regards, Luis Ressel signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default
On Mon, 12 May 2014 19:39:09 +0200 Michał Górny wrote: > I don't know postgresql well enough but does the test db reside > in temporary build directory? That is, can you guarantee that: > > 1) it will never ever collide with user's database, > > 2) it will be properly cleaned up even if the test suite terminates > unexpectedly? The closest thing you could do would be to create a separate tablespace residing in the build directory. I wouldn't consider this a good idea however, as you'd need postgres superuser permissions, it would have some unintented side effects (like breaking on SELinux machines), you'd have to patch the test suites and it still wouldn't ensure an automatic cleanup -- on unexpected test suite terminations the dir in which the tablespace resides would vanish, but postgres would still expect one there, which might even create further problems (especially on re-emerge). I wouldn't recommend using this approach even when accessing the host postgres. On top of that, many postgres installations with reasonably secure configuration wouldn't grant portage access anyway. As it isn't hard at all to run a separate postgres instance (upstream is explicitly supporting it), I'd strongly recommend doing so even with network-sandbox being disabled. -- Regards, Luis Ressel signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
On Wed, 9 Apr 2014 22:48:55 +0200 Luis Ressel wrote: > On Wed, 09 Apr 2014 22:34:07 +0200 > Pacho Ramos wrote: > > > mail-filter/bogofilter > > If no dev wants it, I'll proxy-maintain it. Okay, that's obsolete now that johu stepped up... Regards, Luis Ressel signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
On Wed, 09 Apr 2014 22:34:07 +0200 Pacho Ramos wrote: > mail-filter/bogofilter If no dev wants it, I'll proxy-maintain it. Regards, Luis Ressel signature.asc Description: PGP signature
[gentoo-dev] [PATCH] gnome2-utils.eclass: Fix SELinux labeling issue in gnome2_gdk_pixbuf_update()
The internals of gnome2-utils.eclass' gnome2_gdk_pixbuf_update(), which is responsable for updating x11-libs/gdk-pixbuf's loaders.cache, unfortunately cause problems with SELinux, as the mentioned file doesn't get a correct context and is therefore inaccessible by applications. The trivial patch which I've proposed on b.g.o (#499636) has already been acknowledged by the SELinux and GNOME herds, however the latter asked me to send a mail to this ML as well. So, does anyone have objections about this change? --- gnome2-utils.eclass 2014-01-28 23:14:31.419135392 +0100 +++ gnome2-utils.eclass 2014-01-28 23:17:06.569269202 +0100 @@ -436,7 +436,8 @@ local tmp_file=$(mktemp -t tmp.XX_gdkpixbuf) ${updater} 1> "${tmp_file}" && chmod 0644 "${tmp_file}" && - mv -f "${tmp_file}" "${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache" + cp -f "${tmp_file}" "${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache" && + rm "${tmp_file}" # don't replace this with mv, required for SELinux support eend $? } -- Luis Ressel GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD signature.asc Description: PGP signature
Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team)
On Mon, 13 Jan 2014 16:46:08 +0100 Tom Wijsman wrote: > On Mon, 13 Jan 2014 16:38:59 +0100 > Luis Ressel wrote: > > > On Mon, 13 Jan 2014 15:58:13 +0100 > > Tom Wijsman wrote: > > > > > Half a minute if you disable backtracking which you don't need. :) > > > > Which sadly also means that some updates get skipped silently. > > (Those which would trigger rebuilds of other packages because of > > sub-slot deps, had that case yesterday). > > Can you give an example of that? > > Rebuilds don't cause a different solution in the graph afaik; so, I > wouldn't see how that would form a big problem. I also think this > would still be covered by preserved-rebuild and/or revdep-rebuild > afterwards. No, the problem wasn't that rebuilds weren't done (btw: this is not about @preserved-rebuilds, but about subslot dependencies), but that updates which would trigger such rebuilds are silently ignored. This happened to me yesterday while trying --backtrack=0. The available update to dev-haskell/parsec simply didn't show up (haskell ebuilds make heavy use of subslot deps), I only noticed this because I knew there was in fact an update available (thanks to eix-diff). Only after enabling backtracking Portage found the update. This might well be a bug, perhaps I'll examine the situation when I've got more time. -- Luis Ressel GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD signature.asc Description: PGP signature
Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team)
On Mon, 13 Jan 2014 15:58:13 +0100 Tom Wijsman wrote: > On Mon, 13 Jan 2014 10:31:56 +0100 > Fabio Erculiani wrote: > > > Portage can still take *minutes* to calculate the merge queue of a > > pkg with all its deps satisfied. > > Half a minute if you disable backtracking which you don't need. :) Which sadly also means that some updates get skipped silently. (Those which would trigger rebuilds of other packages because of sub-slot deps, had that case yesterday). > > Ironically, launching the same emerge command twice, will take more > > or less the same time. > > Determinism results in more or less the same time, that's correct; > proper benchmarks would show you a similar result. I guess he means that the (according to the file sizes) extensive caching doesn't seem to be of much use. -- Luis Ressel GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: storing predefined INSTALL_MASK directory lists in repos
On Sat, 11 Jan 2014 17:01:34 +0100 Michał Górny wrote: > That's a side goal. > > I was thinking of something like: > > INSTALL_MASK="linguas -linguas_XX" > > that would remove all linguas except for language XX. That would be enough for me. A bit of a duplication of information, but if it eases the implementation, that shouldn't be much of a problem. But imho it'd be nice if this approach didn't require a separate config entry for each language (that'd be 233 entries). -- Luis Ressel GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: storing predefined INSTALL_MASK directory lists in repos
I've got an additional proposal: It would be interesting if this feature could also make use of the LINGUAS var for selectively filtering /usr/share/man and and /usr/share/locale, as most ebuilds don't respect this variable natively. -- Luis Ressel GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Thu, 02 Jan 2014 12:13:47 -0500 Ian Stakenvicius wrote: > RESTRICT="fetch" requires the user to do their own fetching; since > they're doing that, it should be pretty obvious that the distfile is > restricted somehow. Of course, they are still able to do whatever > they want, but I expect anyone that is keeping DISTDIR and > NODISTCACHEDIR as separate targets would know to not place the fetched > distfile in their self-distributing directory, or at least know to > read the license restrictions already present in the listed LICENSEs Yes, I totally forgot that. Portage doesn't download these files, so there's no point in creating a variable telling it where to put them... Luis signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Thu, 2 Jan 2014 17:53:45 +0100 Ulrich Mueller wrote: > RESTRICT is somewhat complementary to LICENSE and cannot provide as > much information. Especially, RESTRICT="mirror" doesn't say under > what license the restricted pieces are, and doesn't allow for > ACCEPT_LICENSE filtering. But is this detailed information really neccessary? The use-case is ensuring the legality of distfiles mirroring -- you're either allowed to do it nor not, the exact license doesn't matter here. Luis signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Fri, 3 Jan 2014 05:37:33 +1300 Kent Fredric wrote: > Fair point. I was more seeing a pattern emerging and exploring where > that might lead. > > Though I figure it a useful distinction for convenience sake. > > Consider if you wanted to archive some files to make a subsequent > gentoo installation easier. > > It would be optimal to backup and replicate the nofetch directory for > the subsequent installation, because that's the only directory that > portage would be unable to populate itself from upstream sources. > > so it becomes: > > /distfiles # Gentoo Replicated and Fetchable from upstream > /distfiles-normirror # Fetch from upstream only > /distfiles-nofetch # manual fetching only > > So it was more a practical benefit than a legal one =). > > ( Also if you were tight on space, you'd obliterate distfiles/ first, > distfiles-nomirror/ second, and distfiles-nofetch/ last ) These are good arguments. Just to be clear: Would you favor if the default setup did this separation? I personally also like the idea, but I'd prefer to leave the default at "one distdir for *", and just make it configurable via the proposed variables. Luis signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Thu, 02 Jan 2014 11:10:54 -0500 Ian Stakenvicius wrote: > ..or we could just do this, using the existing RESTRICT="mirror" > that's already in ebuilds -- have a DISTDIR and a NODISTCACHEDIR, > NODISTCACHEDIR defaults to DISTDIR; if RESTRICT="mirror" then > distfiles are saved to NODISTCACHEDIR, otherwise are saved to DISTDIR. IMHO, this is the best solution proposed so far. It doesn't need a new USE flag duplicating information which is already in RESTRICT (or am I missing some corner cases here?), and it doesn't bother those who don't care about this issue with new distfiles-*/ dirs, as with Kent's proposal. @Kent: Why do you think another distinction for RESTRICT=fetch is neccessary? If it really is, it could also be integrated into this solution, but I don't get the point -- either you're allowed to redistribute it, or you're not. RESTRICT=fetch just signals Portage that it won't be *technically* able to download the distfiles. Luis signature.asc Description: PGP signature
Re: [gentoo-dev] openrc 0.12 - netifrc/newnet mix-up
On Sat, 14 Dec 2013 15:57:04 -0600 William Hubbs wrote: > On Sat, Dec 14, 2013 at 08:47:01PM +, Jorge Manuel B. S. Vicetto > wrote: > > OK, I see what you mean. > > To be clear, I'm not ready to have a stage3 without netifrc. If / > > when we update catalyst so that the new stage3 is the sum of > > @system and additional packages, we can move netifrc to that list. > > Actually I'm not even sure how necessary that kind of update is. > > I didn't quite follow what the reasoning against my second proposal > was. > > Once openrc-0.12.4 is stable everywhere it is going to go stable, I > want to add virtual/network-manager to the tree. This would contain a > list of network manager providers. > > I think adding it to the tree is good, because we have other virtuals > for multiple packages that perform the same function -- > virtual/logger, virtual/mta, etc. > > Once that is done, we could easily add it to @system then I would drop > the netifrc use flag. That would take care of the situation if netifrc > was the default provider. > > Then, if you decide to add the function you are talking about to > catalyst, we could look into dropping virtual/network-manager from > @system. > > I'll attach the ebuild below so everyone sees it. > > William > IMHO this virtual shouldn't be added. It would be a pure meta package for the user. That case is not directly comparable with virtual/mta: We've got this for other packages to depend on it, at least that is my understanding. In a case like this, a handbook entry should suffice. Luis Ressel signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
On Sat, 23 Mar 2013 10:52:00 +0100 Martin Dummer wrote: > If I manage one day to achieve the gentoo dev status then I am willing > to pick up maintainership of > > > app-laptop/nvidiabl > > but until then? What about proxy-maintainership? Luis signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Tue, 26 Feb 2013 17:10:56 +0700 (NOVT) gro...@gentoo.org wrote: > Hello *, > I am stuck and have many questions. > [In the process of becoming a dev, I've generated a gpg key, of course. It > vwas on an old notebook. When I switched to a newer notebook, I forgot to > copy it, because I don't use gpg regularly. No risk that it became known - > the disk was re-partitioned and re-formatted. Probably, that key has expired > anyway.] > 1. So, I start > gpg --gen-key > It creates ~/.gnupg/ and some files in it. Should I press ctrl-C, then edit > ~/.gnupg/gpg.conf, and then re-start gpg --gen-key? Or editing gpg.conf can > be done later? Editing the conf should be done first, some of the preferences (e.g. personal-digest-preference and cert-digest-algo) affect the creation of keys. > 2. Then I choose 1, 3y, y, then my name and the @gentoo.org email address. > After that, > gpg --list-keys > says > /home//.gnupg/pubring.gpg > --- > pub 4096R/0x<16_hex_digits_1> 2013-02-26 [expires: 2016-02-26] > uid [ultimate] sub > 4096R/0x<16_hex_digits_2> 2013-02-26 [expires: 2016-02-26] > So, my key id is 0x<16_hex_digits_1>, right? Yep, but why did you bother to replace the information? > 3. Now I do > gpg --edit-key 0x<16_hex_digits_1> > addkey > Then I choose > (4) RSA (sign only) > right? Then I choose 4096, 1y, y, y, save. Now > gpg --list-keys > gives > /home//.gnupg/pubring.gpg > --- > pub 4096R/0x<16_hex_digits_1> 2013-02-26 [expires: 2016-02-26] > uid [ultimate] > sub 4096R/0x<16_hex_digits_2> 2013-02-26 [expires: 2016-02-26] > sub 4096R/0x<16_hex_digits_3> 2013-02-26 [expires: 2014-02-26] > 4. I do > gpg --output revoke.asc --gen-revoke 0x<16_hex_digits_1> > and choose 1. That's all correct. > > 6. Encrypted backup of your secret keys. > I don't understand this. It'd make sense to have an backup of your keys (~/.gnupg/secring.gpg) stored in a safe place, just as with everything else... If you want, you can protect it by another layer of encryption, but it's not that important, because the keys are already protected by your passphrase. > > 7. In your gpg.conf: > > # include an unambiguous indicator of which key made a signature: > > # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234) > > sig-notation issuer-...@notations.openpgp.fifthhorseman.net=%g > I don't understand this. Neither do I (I know what it does, but I don't see what it's good for) – just leave it out, it's not necessary. > 5. I do > gpg --keyserver subkeys.pgp.net --send-key 0x<16_hex_digits_1> > 6. On dev.gentoo.org, I am supposed to do > perl_ldap -b user -M gpgkey > perl_ldap -b user -M gpgfingerprint > Is 0x<16_hex_digits_1>? Or 0x<16_hex_digits_3>? What is > and how do I get it? Is my username on > dev.gentoo.org? > What's even more important, perl_ldap asks my ldap password. I suppose I > haven't got one. My usual Gentoo password (used in bugzilla, forums) does not > work. How do I get an ldap password? I can't help you with that, as I don't have access to any gentoo infrastructure. But IIRC, that's the password you once set on d.g.o with passwd. > 7. If I'll ever complete all the above, I'll add sign to FEATURES in > /etc/portage/make.conf, and > PORTAGE_GPG_DIR="/home//.gnupg" > and also > PORTAGE_GPG_KEY="0x<16_hex_digits_3>!" > Is this correct? Is it <16_hex_digits_3>, and not, say, <16_hex_digits_1>? > Should I add ! at the end, as suggested by mgorny? 16_hex_digits_3 (the one you added later via addkey) is the correct one. And adding a ! is absolutely necessary. > During the time I'm reading all these instructions, I could bump 10 packages. > Very complicated for a person who does not use gpg and knows next to nothing > about it. Security can be hard to grasp at times. Sadly... HTH, Luis signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Wed, 20 Feb 2013 21:37:38 + "Robin H. Johnson" wrote: > Ideally keeping your primary key offline to increase security. > > However, the original theory was that if there was some attack that > required a large amount of ciphertext or a targeted plaintext input, > you would be limiting the ciphertext to only gentoo-specific content, > and could trivially rotate the subkey without any impact on your > primary key. I totally agree with the idea of having a separate subkey for signing purposes, but look at my key, for example: I already have a separate subkey for signing, the primary key is only used for certifications (and is actually kept offline ;). If I was a Gentoo dev, it wouldn't seem that logical to have to create yet another signing subkey. Therefore, I'd propose to remove the "Gentoo" part from "Dedicated Gentoo signing subkey". Luis signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Mon, 18 Feb 2013 23:27:46 + "Robin H. Johnson" wrote: > 3. Dedicated Gentoo signing subkey What's the point of this, btw? Luis signature.asc Description: PGP signature