Re: [gentoo-dev] rfc: moving default location of portage tree
> On Mon, 9 Jul 2018, Rich Freeman wrote: > I'd also consider /var/cache here as well. FHS specifically suggests > using it for web caches and the like (let's set aside the issue with > making that global), though for the most part it is more metadata > caching. A key principle is that it can be wiped without loss of > data, and I think that is generally true for the repository since it > can be synced. I don't think that criterium is fulfilled, because you cannot easily restore the previous state after it's been wiped. At least not when syncing from a rsync mirror (which may have been updated in the mean time). Also Portage doesn't treat it likea a cache, i.e. it doesn't start to fetch ebuilds from remote if it doesn't find them in the local tree. Ulrich pgpWGN18tTNne.pgp Description: PGP signature
Re: [gentoo-dev] rfc: moving default location of portage tree
On Mon, Jul 9, 2018 at 2:11 PM Johannes Huber wrote: > > Am 09.07.2018 um 20:05 schrieb Rich Freeman: > > On Mon, Jul 9, 2018 at 1:40 PM Ulrich Mueller wrote: > >> > >>> On Mon, 9 Jul 2018, William Hubbs wrote: > >> > >>> is there a tracker for when the portage tree can be moved out of > >>> /usr/portage by default? > >> > >>> If not, what is the status of us being able to do this? > >> > >> Please remind me, what was the plan for the new location? > >> Somewhere under /var/db or /var/lib, IIRC? > >> > > > > I'd also consider /var/cache here as well. FHS specifically suggests > > using it for web caches and the like (let's set aside the issue with > > making that global), though for the most part it is more metadata > > caching. A key principle is that it can be wiped without loss of > > data, and I think that is generally true for the repository since it > > can be synced. > > > > Stuff in /var/lib can't be deleted without some kind of loss of > > application state. /var/db isn't in FHS, and I note that even mysql > > sticks its stuff in /var/lib. > > > > Imho it would make sense to split up portage files with this change. > Move the tree (ebuilds, profiles etc) to /var/lib/... and the metadata > cache to /var/db as it can be regenerated out of the tree. > Are you talking about the metadata that gets synced as part of the repository? Conceptually I like the idea of splitting it out, but IMO the whole repository is really just one big cache, so keeping it together since it always has to be consistent isn't a huge problem. If you're talking about the stuff in /var/cache/edb, then that should be separate from the repository, but should still be in cache. I'd probably create /var/cache/portage, with subdirectories for repositories (with a subdir for each one synced by portage), edb, distfiles, and binary packages. /var/cache/portage/repos/main /var/cache/portage/repos/my-favorite-overlay /var/cache/portage/distfiles /var/cache/portage/edb The stuff in /var/db/pkg should probably go in /var/lib/portage/pkg or something like that, at least long-term. -- Rich
Re: [gentoo-dev] rfc: moving default location of portage tree
On Mon, Jul 09, 2018 at 08:36:33PM +0200, Ulrich Mueller wrote: > > On Mon, 9 Jul 2018, Rich Freeman wrote: > > > I'd also consider /var/cache here as well. FHS specifically suggests > > using it for web caches and the like (let's set aside the issue with > > making that global), though for the most part it is more metadata > > caching. A key principle is that it can be wiped without loss of > > data, and I think that is generally true for the repository since it > > can be synced. > > I don't think that criterium is fulfilled, because you cannot easily > restore the previous state after it's been wiped. At least not when > syncing from a rsync mirror (which may have been updated in the mean > time). The criteria for /var/cache do not require being able to restore the exact previous state; they just require that the application be able to regenerate or restore the data , so they are definitely fulfilled.[1]. > Also Portage doesn't treat it likea a cache, i.e. it doesn't start to > fetch ebuilds from remote if it doesn't find them in the local tree. There is no definition of how a cache should be treated in fhs, so I don't see this as an argument against /var/cache either. William [1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#varcacheApplicationCacheData signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: moving default location of portage tree
On Mon, Jul 9, 2018 at 4:13 PM Michał Górny wrote: > > W dniu pon, 09.07.2018 o godzinie 15∶11 -0500, użytkownik William Hubbs > napisał: > > On Mon, Jul 09, 2018 at 08:43:31PM +0200, Michał Górny wrote: > > > sys-apps/portage-mgorny has already done that. The defaults locations > > > have been changed to: > > > > > > DISTDIR="/var/cache/portage/distfiles" > > > PKGDIR="/var/cache/portage/packages" > > > RPMDIR="/var/cache/portage/rpm" > > > > > > Plus repositories are in /var/db/repos/. This is also the layout > > > used by eselect-repository. > > > > I like this idea, but slightly different; I think we should stay out of > > /var/db. We don't want folks to go messing around in there and nuke > > /var/db/pkg by mistake. > > > > Following that reasoning, we shouldn't use /var at all because people > might 'go messing around in there and nuke /var/* by mistake'. Or any > directory. Our only hope is Windows where we can create P:\ and not > worry that people might 'go messing around in there and nuke the system > by mistake'. > ++ Though I do prefer /var/lib or /var/cache over /var/db, simply because /var/lib is actually in FHS. That said, all my comments should be taken as suggestions. I don't really have a huge concern with most of these proposals. Any of them are better than /usr, with distfiles being stacked inside the repo (ugh!). -- Rich
Re: [gentoo-dev] rfc: moving default location of portage tree
On Mon, 9 Jul 2018 12:21:36 -0500 William Hubbs wrote: > All, > > is there a tracker for when the portage tree can be moved out of > /usr/portage by default? > > If not, what is the status of us being able to do this? > > Thanks, > > William > I don't recall a tracker bug ever being created. It required the stages be generated by catalyst-3 which can be configured to any location for the tree defaults. catalyst-2 had paths hard-coded all over the place, plus used those paths as keys in python dictionaries... I believe all stages are now built with catalyst-3 for all arches, but I don't know about some of the lesser used arches as some of those are older dates. That and a portage release with the new default location set in it's backup configs. So, it should be ready to convert if the minor arches stage are being generated with catalyst-3 -- Brian Dolbec pgpJWo1O2DkxL.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: moving default location of portage tree
On Mon, Jul 09, 2018 at 08:43:31PM +0200, Michał Górny wrote: > sys-apps/portage-mgorny has already done that. The defaults locations > have been changed to: > > DISTDIR="/var/cache/portage/distfiles" > PKGDIR="/var/cache/portage/packages" > RPMDIR="/var/cache/portage/rpm" > > Plus repositories are in /var/db/repos/. This is also the layout > used by eselect-repository. I like this idea, but slightly different; I think we should stay out of /var/db. We don't want folks to go messing around in there and nuke /var/db/pkg by mistake. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: moving default location of portage tree
W dniu pon, 09.07.2018 o godzinie 15∶11 -0500, użytkownik William Hubbs napisał: > On Mon, Jul 09, 2018 at 08:43:31PM +0200, Michał Górny wrote: > > sys-apps/portage-mgorny has already done that. The defaults locations > > have been changed to: > > > > DISTDIR="/var/cache/portage/distfiles" > > PKGDIR="/var/cache/portage/packages" > > RPMDIR="/var/cache/portage/rpm" > > > > Plus repositories are in /var/db/repos/. This is also the layout > > used by eselect-repository. > > I like this idea, but slightly different; I think we should stay out of > /var/db. We don't want folks to go messing around in there and nuke > /var/db/pkg by mistake. > Following that reasoning, we shouldn't use /var at all because people might 'go messing around in there and nuke /var/* by mistake'. Or any directory. Our only hope is Windows where we can create P:\ and not worry that people might 'go messing around in there and nuke the system by mistake'. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address
W dniu pon, 09.07.2018 o godzinie 22∶12 +0200, użytkownik Manuel Rüger napisał: > On 09.07.2018 10:40, Michał Górny wrote: > > Hi, > > > > We currently don't enforce any particular standard for e-mail addresses > > for developers committing to gentoo.git. FWICS, the majority of > > developers is using their @gentoo.org e-mail addresses. However, a few > > developers are using some other addresses. > > > > Using n...@gentoo.org e-mail addresses generally causes problems > > in accounting for commits. For example, our retirement scripts can't > > detect commits made using non-Gentoo e-mail address. My dev-timeline > > scripts [1] account for all emails in LDAP (which doesn't cover all > > addresses developers use). FWIK gkeys accounts for all addresses > > in the OpenPGP key UIDs. In my opinion, that's a lot of hoops to jump > > through to workaround bad practice. > > > > Therefore, I'd like to start enforcing (at the level of the hook > > verifying signatures) that all commits made to gentoo.git (and other > > repositories requiring dev signatures) are made using @gentoo.org e-mail > > address (for committer field). > > > > Is anyone opposed to that? Does anyone know of a valid reason to use > > n...@gentoo.org address when committing? > > > > [1]:https://dev.gentoo.org/~mgorny/dev-timeline.html > > > > Hi Michał, > > just to be clear on the wording, are you talking about the author email > of a git commit (authorship) or the comitter email to the upstream git > repository (committer)? > «[...] are made using @gentoo.org e-mail address **(for committer field)**.» -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: moving default location of portage tree
On Mon, Jul 9, 2018 at 5:34 PM Kristian Fiskerstrand wrote: > > I'd mostly argue any such change should only affect new systems > ++ If a user wants to migrate it is pretty easy to do. Update the setting and do an mv, or don't do an mv in which case it will just regenerate. I think /var/db/pkg is the only thing that is particularly sensitive there (if users lose that then they have a mess - probably recoverable if they do an emerge -e world and then go hunting for orphans). -- Rich
Re: [gentoo-dev] rfc: moving default location of portage tree
On 09/07/18 23:12, Zac Medico wrote: > On 07/09/2018 02:34 PM, Kristian Fiskerstrand wrote: >> I'd mostly argue any such change should only affect new systems >> > Yes, changing defaults for existing systems would be annoying. > > My recommendation is to have catalyst set the new defaults in the stage > tarballs. > > When sys-apps/portage changes its internal defaults, I'd like for the > upgrade process to call a tool that generates configuration files when > necessary to ensure that the existing paths remain constant. I think it should be possible for RelEng to make a start on catalyst updates - is there anything that would inhibit going ahead with this, potentially? MJE signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: moving default location of portage tree
On 07/09/2018 02:34 PM, Kristian Fiskerstrand wrote: > > I'd mostly argue any such change should only affect new systems > Yes, changing defaults for existing systems would be annoying. My recommendation is to have catalyst set the new defaults in the stage tarballs. When sys-apps/portage changes its internal defaults, I'd like for the upgrade process to call a tool that generates configuration files when necessary to ensure that the existing paths remain constant. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On Sun, Jul 01, 2018 at 10:57:40AM +0200, Pacho Ramos wrote: > net-im/mcabber > net-libs/loudmouth Taking these. signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: moving default location of portage tree
On Mon, Jul 09, 2018 at 04:53:43PM -0400, Rich Freeman wrote: > On Mon, Jul 9, 2018 at 4:13 PM Michał Górny wrote: > > > > W dniu pon, 09.07.2018 o godzinie 15∶11 -0500, użytkownik William Hubbs > > napisał: > > > On Mon, Jul 09, 2018 at 08:43:31PM +0200, Michał Górny wrote: > > > > sys-apps/portage-mgorny has already done that. The defaults locations > > > > have been changed to: > > > > > > > > DISTDIR="/var/cache/portage/distfiles" > > > > PKGDIR="/var/cache/portage/packages" > > > > RPMDIR="/var/cache/portage/rpm" > > > > > > > > Plus repositories are in /var/db/repos/. This is also the layout > > > > used by eselect-repository. > > > > > > I like this idea, but slightly different; I think we should stay out of > > > /var/db. We don't want folks to go messing around in there and nuke > > > /var/db/pkg by mistake. > > > > > > > Following that reasoning, we shouldn't use /var at all because people > > might 'go messing around in there and nuke /var/* by mistake'. Or any > > directory. Our only hope is Windows where we can create P:\ and not > > worry that people might 'go messing around in there and nuke the system > > by mistake'. > > > > ++ > > Though I do prefer /var/lib or /var/cache over /var/db, simply because > /var/lib is actually in FHS. Agreed, /var/db I guess is a Gentoo invention of some kind? William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: moving default location of portage tree
> On Mon, 9 Jul 2018, William Hubbs wrote: > On Mon, Jul 09, 2018 at 04:53:43PM -0400, Rich Freeman wrote: >> Though I do prefer /var/lib or /var/cache over /var/db, simply >> because /var/lib is actually in FHS. > Agreed, /var/db I guess is a Gentoo invention of some kind? No, it exists in FreeBSD too. pgpTQoqGY9KyG.pgp Description: PGP signature
Re: [gentoo-dev] rfc: moving default location of portage tree
On 07/09/2018 03:27 PM, M. J. Everitt wrote: > On 09/07/18 23:12, Zac Medico wrote: >> On 07/09/2018 02:34 PM, Kristian Fiskerstrand wrote: >>> I'd mostly argue any such change should only affect new systems >>> >> Yes, changing defaults for existing systems would be annoying. >> >> My recommendation is to have catalyst set the new defaults in the stage >> tarballs. >> >> When sys-apps/portage changes its internal defaults, I'd like for the >> upgrade process to call a tool that generates configuration files when >> necessary to ensure that the existing paths remain constant. > I think it should be possible for RelEng to make a start on catalyst > updates - is there anything that would inhibit going ahead with this, > potentially? No, nothing. Whatever catalyst puts it the default config will become our new default. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: moving default location of portage tree
On 07/09/2018 11:14 PM, William Hubbs wrote: >> Though I do prefer /var/lib or /var/cache over /var/db, simply because >> /var/lib is actually in FHS. > Agreed, /var/db I guess is a Gentoo invention of some kind? well, for a gentoo-based PMS that might not be a bad thing.. but I'd say cache is out of the question, whether it is /var/lib or /var/db doesn't matter too much to me, but it needs to be announced properly ahead of time to adjust LVM2 volumes etc etc if impacting existing systems... I'd mostly argue any such change should only affect new systems -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: moving default location of portage tree
On 07/09/2018 01:00 PM, William Hubbs wrote: > On Mon, Jul 09, 2018 at 08:36:33PM +0200, Ulrich Mueller wrote: >>> On Mon, 9 Jul 2018, Rich Freeman wrote: >> >>> I'd also consider /var/cache here as well. FHS specifically suggests >>> using it for web caches and the like (let's set aside the issue with >>> making that global), though for the most part it is more metadata >>> caching. A key principle is that it can be wiped without loss of >>> data, and I think that is generally true for the repository since it >>> can be synced. >> >> I don't think that criterium is fulfilled, because you cannot easily >> restore the previous state after it's been wiped. At least not when >> syncing from a rsync mirror (which may have been updated in the mean >> time). > > The criteria for /var/cache do not require being able to restore the > exact previous state; they just require that the application be able to > regenerate or restore the data , so they are definitely fulfilled.[1]. If it's an rsync tree then we cannot restore the precise state, for example you might not be able to rebuild one of your installed packages if the corresponding ebuild has been removed upstream. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address
On 09.07.2018 10:40, Michał Górny wrote: > Hi, > > We currently don't enforce any particular standard for e-mail addresses > for developers committing to gentoo.git. FWICS, the majority of > developers is using their @gentoo.org e-mail addresses. However, a few > developers are using some other addresses. > > Using n...@gentoo.org e-mail addresses generally causes problems > in accounting for commits. For example, our retirement scripts can't > detect commits made using non-Gentoo e-mail address. My dev-timeline > scripts [1] account for all emails in LDAP (which doesn't cover all > addresses developers use). FWIK gkeys accounts for all addresses > in the OpenPGP key UIDs. In my opinion, that's a lot of hoops to jump > through to workaround bad practice. > > Therefore, I'd like to start enforcing (at the level of the hook > verifying signatures) that all commits made to gentoo.git (and other > repositories requiring dev signatures) are made using @gentoo.org e-mail > address (for committer field). > > Is anyone opposed to that? Does anyone know of a valid reason to use > n...@gentoo.org address when committing? > > [1]:https://dev.gentoo.org/~mgorny/dev-timeline.html > Hi Michał, just to be clear on the wording, are you talking about the author email of a git commit (authorship) or the comitter email to the upstream git repository (committer)? Thanks, Manuel
Re: [gentoo-dev] rfc: moving default location of portage tree
W dniu pon, 09.07.2018 o godzinie 12∶21 -0500, użytkownik William Hubbs napisał: > All, > > is there a tracker for when the portage tree can be moved out of > /usr/portage by default? > > If not, what is the status of us being able to do this? sys-apps/portage-mgorny has already done that. The defaults locations have been changed to: DISTDIR="/var/cache/portage/distfiles" PKGDIR="/var/cache/portage/packages" RPMDIR="/var/cache/portage/rpm" Plus repositories are in /var/db/repos/. This is also the layout used by eselect-repository. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: moving default location of portage tree
On 07/09/2018 01:07 PM, Zac Medico wrote: > On 07/09/2018 01:00 PM, William Hubbs wrote: >> On Mon, Jul 09, 2018 at 08:36:33PM +0200, Ulrich Mueller wrote: On Mon, 9 Jul 2018, Rich Freeman wrote: >>> I'd also consider /var/cache here as well. FHS specifically suggests using it for web caches and the like (let's set aside the issue with making that global), though for the most part it is more metadata caching. A key principle is that it can be wiped without loss of data, and I think that is generally true for the repository since it can be synced. >>> >>> I don't think that criterium is fulfilled, because you cannot easily >>> restore the previous state after it's been wiped. At least not when >>> syncing from a rsync mirror (which may have been updated in the mean >>> time). >> >> The criteria for /var/cache do not require being able to restore the >> exact previous state; they just require that the application be able to >> regenerate or restore the data , so they are definitely fulfilled.[1]. > > If it's an rsync tree then we cannot restore the precise state, for > example you might not be able to rebuild one of your installed packages > if the corresponding ebuild has been removed upstream. Whoops I didn't mean to simply repeat what Ulrich said. My point is that the spirit of the FHS might be that "nothing is lost", but you certainly can lose some valuable state if it's an rsync tree. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address
On July 9, 2018 4:40:22 AM EDT, "Michał Górny" wrote: >Hi, > >We currently don't enforce any particular standard for e-mail addresses >for developers committing to gentoo.git. FWICS, the majority of >developers is using their @gentoo.org e-mail addresses. However, a few >developers are using some other addresses. > >Using n...@gentoo.org e-mail addresses generally causes problems >in accounting for commits. For example, our retirement scripts can't >detect commits made using non-Gentoo e-mail address. My dev-timeline >scripts [1] account for all emails in LDAP (which doesn't cover all >addresses developers use). FWIK gkeys accounts for all addresses >in the OpenPGP key UIDs. In my opinion, that's a lot of hoops to jump >through to workaround bad practice. > >Therefore, I'd like to start enforcing (at the level of the hook >verifying signatures) that all commits made to gentoo.git (and other >repositories requiring dev signatures) are made using @gentoo.org >e-mail >address (for committer field). > >Is anyone opposed to that? Does anyone know of a valid reason to use >n...@gentoo.org address when committing? > >[1]:https://dev.gentoo.org/~mgorny/dev-timeline.html No reason I can see to not enforce this. Please do! -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[gentoo-dev] Last Rites: dev-python/pgasync
# Aaron W. Swenson (9 Jul 2018) # Hasn’t been updated in years, upstream’s download source is blank, and depends # on an outdated twisted-core (Bug 660668). Removal after 2018-08-08. dev-python/pgasync signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address
Ühel kenal päeval, E, 09.07.2018 kell 10:40, kirjutas Michał Górny: > Hi, > > We currently don't enforce any particular standard for e-mail > addresses > for developers committing to gentoo.git. FWICS, the majority of > developers is using their @gentoo.org e-mail addresses. However, a > few > developers are using some other addresses. > > Using n...@gentoo.org e-mail addresses generally causes problems > in accounting for commits. For example, our retirement scripts can't > detect commits made using non-Gentoo e-mail address. My dev-timeline > scripts [1] account for all emails in LDAP (which doesn't cover all > addresses developers use). FWIK gkeys accounts for all addresses > in the OpenPGP key UIDs. In my opinion, that's a lot of hoops to > jump > through to workaround bad practice. > > Therefore, I'd like to start enforcing (at the level of the hook > verifying signatures) that all commits made to gentoo.git (and other > repositories requiring dev signatures) are made using @gentoo.org e- > mail > address (for committer field). > > Is anyone opposed to that? Does anyone know of a valid reason to use > n...@gentoo.org address when committing? As long as that doesn't imply authorship, which seems to be as planned (for committer field only, as you said). Hopefully it's easy for people to set it up so that it uses gentoo address for committer and something else for author, albeit I don't see any config for it, but should be able to at least go via a script that uses the appropriate env vars. That's then for work computers where the Gentoo developer is doing work necessary for his/her employer, on employers paid time. Appropriate then to have their work e-mail as author, especially if employer rightfully requests that to be used for authorship. But yeah, committer field should be fine, they can do author with one address, committer with Gentoo address. The only issue I see is that of slight complications on handling the different addresses for author and commit, that's all that comes to mind. Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] News Item: Portage rsync hardlink support
On 07/08/2018 11:59 PM, Zac Medico wrote: >> It used to make a special statement for a new stable Portage and >> strongly recommended that it be emerged first. It should probably do the >> same for openpgp-keys-gentoo-release. > Sure, but it this case we have a chicken-and-egg problem, because I > needed the latest openpgp-keys-gentoo-release installed but in order to > do that I had to sync, but then verification failed because I didn't > have the latest openpgp-keys-gentoo-release. We're hopefully attributing that to a startup problem. Obviously as we go along we need to have proper key rollover procedures so this should never happen including backup keys. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
Re: [gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address
On 07/09/2018 10:40 AM, Michał Górny wrote: > Therefore, I'd like to start enforcing (at the level of the hook > verifying signatures) that all commits made to gentoo.git (and other > repositories requiring dev signatures) are made using @gentoo.org e-mail > address (for committer field). Sounds like a good thing, go for it! -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address
Hi, We currently don't enforce any particular standard for e-mail addresses for developers committing to gentoo.git. FWICS, the majority of developers is using their @gentoo.org e-mail addresses. However, a few developers are using some other addresses. Using n...@gentoo.org e-mail addresses generally causes problems in accounting for commits. For example, our retirement scripts can't detect commits made using non-Gentoo e-mail address. My dev-timeline scripts [1] account for all emails in LDAP (which doesn't cover all addresses developers use). FWIK gkeys accounts for all addresses in the OpenPGP key UIDs. In my opinion, that's a lot of hoops to jump through to workaround bad practice. Therefore, I'd like to start enforcing (at the level of the hook verifying signatures) that all commits made to gentoo.git (and other repositories requiring dev signatures) are made using @gentoo.org e-mail address (for committer field). Is anyone opposed to that? Does anyone know of a valid reason to use n...@gentoo.org address when committing? [1]:https://dev.gentoo.org/~mgorny/dev-timeline.html -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [PATCH 0/5]-r1 toolchain.eclass: Prefix patches, Cygwin related
On 06/22/2018 03:10 PM, Michael Haubenwallner wrote: > Hi, > > now reordered for EAPI 7 first. > > Also, the downloaded cygwindist patches file now is renamed to > gcc-cygwindist-.tar.gz rather than just .tar.gz. > > Thanks for the reviews, pushed now, thanks! /haubi/
[gentoo-dev] rfc: moving default location of portage tree
All, is there a tracker for when the portage tree can be moved out of /usr/portage by default? If not, what is the status of us being able to do this? Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: moving default location of portage tree
On Mon, Jul 9, 2018 at 1:21 PM, William Hubbs wrote: > All, > > is there a tracker for when the portage tree can be moved out of > /usr/portage by default? I suspect the answer is 'whenever' but that mostly depends on implementation and what you want to accomplish. Do you want: - All hosts everywhere to move from $CURRENT to $NEW? - Only new installs to move from $CURRENT to $NEW? > > If not, what is the status of us being able to do this? The former is probably 3 times easier than the latter. - Get testers to move their tree and report issues[0]. - Change the stage3 defaults to be the new location. - Explicitly do nothing else. New installs will get the new location, old installs will get the old location. The latter is harder (one must design and execute a migration for existing installs) and I suspect the value of such a migration is low and the risk high. Is there any advantage to migrating existing installs? [0] A number of people already point PORTDIR at some other location and appear to operate without major issues. > > Thanks, > > William > >
Re: [gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address
On Mon, 2018-07-09 at 10:40 +0200, Michał Górny wrote: > Hi, > > We currently don't enforce any particular standard for e-mail > addresses > for developers committing to gentoo.git. FWICS, the majority of > developers is using their @gentoo.org e-mail addresses. However, a > few > developers are using some other addresses. > > Using n...@gentoo.org e-mail addresses generally causes problems > in accounting for commits. For example, our retirement scripts can't > detect commits made using non-Gentoo e-mail address. My dev-timeline > scripts [1] account for all emails in LDAP (which doesn't cover all > addresses developers use). FWIK gkeys accounts for all addresses > in the OpenPGP key UIDs. In my opinion, that's a lot of hoops to > jump > through to workaround bad practice. > > Therefore, I'd like to start enforcing (at the level of the hook > verifying signatures) that all commits made to gentoo.git (and other > repositories requiring dev signatures) are made using @gentoo.org e- > mail > address (for committer field). > > Is anyone opposed to that? Does anyone know of a valid reason to use > n...@gentoo.org address when committing? > > [1]:https://dev.gentoo.org/~mgorny/dev-timeline.html > +1
Re: [gentoo-dev] rfc: moving default location of portage tree
On Monday, 9 July 2018 19:26:54 CEST Alec Warner wrote:
> [0] A number of people already point PORTDIR at some other location and
> appear to operate without major issues.
I do have it in /var/cache/portage/gentoo (alongside /var/cache/portage/
{distfiles,packages,local} and that works quite well.
--Dennis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: moving default location of portage tree
> On Mon, 9 Jul 2018, William Hubbs wrote: > is there a tracker for when the portage tree can be moved out of > /usr/portage by default? > If not, what is the status of us being able to do this? Please remind me, what was the plan for the new location? Somewhere under /var/db or /var/lib, IIRC? Ulrich pgpRbE4DJzMgU.pgp Description: PGP signature
Re: [gentoo-dev] rfc: moving default location of portage tree
On Mon, Jul 9, 2018 at 1:26 PM Alec Warner wrote: > > The former is probably 3 times easier than the latter. > - Get testers to move their tree and report issues[0]. > - Change the stage3 defaults to be the new location. > - Explicitly do nothing else. > > New installs will get the new location, old installs will get the old > location. > > [0] A number of people already point PORTDIR at some other location and > appear to operate without major issues. > IMO it would be best to just fix this for new installs, and post a news item about it with some instructions for users to migrate. There really isn't much to it though. I'd think you could just move it at the filesystem level and then change the pointers. Or you can just change the pointers and do a sync to pull down a fresh copy and clean up later. I'm not sure where we default distfiles to these days but that should also go outside of /usr. It should also not be a subdirectory of PORTDIR. Ideally you should just be able to rm -r $PORTDIR and then do a sync and get it right back. (Also, your email got former/latter swapped around.) -- Rich
Re: [gentoo-dev] rfc: moving default location of portage tree
On Mon, Jul 9, 2018 at 1:40 PM Ulrich Mueller wrote: > > > On Mon, 9 Jul 2018, William Hubbs wrote: > > > is there a tracker for when the portage tree can be moved out of > > /usr/portage by default? > > > If not, what is the status of us being able to do this? > > Please remind me, what was the plan for the new location? > Somewhere under /var/db or /var/lib, IIRC? > I'd also consider /var/cache here as well. FHS specifically suggests using it for web caches and the like (let's set aside the issue with making that global), though for the most part it is more metadata caching. A key principle is that it can be wiped without loss of data, and I think that is generally true for the repository since it can be synced. Stuff in /var/lib can't be deleted without some kind of loss of application state. /var/db isn't in FHS, and I note that even mysql sticks its stuff in /var/lib. -- Rich
Re: [gentoo-dev] rfc: moving default location of portage tree
Am 09.07.2018 um 20:05 schrieb Rich Freeman: > On Mon, Jul 9, 2018 at 1:40 PM Ulrich Mueller wrote: >> >>> On Mon, 9 Jul 2018, William Hubbs wrote: >> >>> is there a tracker for when the portage tree can be moved out of >>> /usr/portage by default? >> >>> If not, what is the status of us being able to do this? >> >> Please remind me, what was the plan for the new location? >> Somewhere under /var/db or /var/lib, IIRC? >> > > I'd also consider /var/cache here as well. FHS specifically suggests > using it for web caches and the like (let's set aside the issue with > making that global), though for the most part it is more metadata > caching. A key principle is that it can be wiped without loss of > data, and I think that is generally true for the repository since it > can be synced. > > Stuff in /var/lib can't be deleted without some kind of loss of > application state. /var/db isn't in FHS, and I note that even mysql > sticks its stuff in /var/lib. > Imho it would make sense to split up portage files with this change. Move the tree (ebuilds, profiles etc) to /var/lib/... and the metadata cache to /var/db as it can be regenerated out of the tree. Best regards, Johannes signature.asc Description: OpenPGP digital signature
