Re: [gentoo-dev] rfc: "emerge --sync" vs "emaint sync"
On Wed, 6 May 2020 17:02:42 -0500
William Hubbs wrote:
> All,
>
> I know that most of our documentation tells people to use "emerge
> --sync"; however, today I heard about "emaint sync" for the first
> time. ;-)
>
> Which one should we use? Will there be a phase-out for "emerge
> --sync" or "emaint sync"? Are the plans to keep both available?
>
> Thanks,
>
> William
>
Hi William. emaint --sync is not going to replace emerge --sync.
They both use the same plugin sync modules.
The difference between them is that emerge --sync is generally done to
sync all repositories defined which have [auto-sync] = yes. Zac
extended it to do individual repositories as well if you specify the
repo name.
ie: emerge --sync foo
emaint --sync offers fine grained syncing of individual repositories
via several options. With emaint you can set a repo's [auto-sync] = no
and still manually sync it on demand from emaint. It offers some
additional capabilities that some power users/devs may need/enjoy
depending on their work flow.
Here are the emaint sync options:
-r REPO, --repo REPO (sync module only): -r, --repo Sync the specified repo
-A, --allrepos(sync module only): -A, --allrepos Sync all repos that
have a sync-url defined
-a, --auto(sync module only): -a, --auto Sync auto-sync enabled
repos only
--sync-submodule {glsa,news,profiles}
(sync module only): Restrict sync to the specified
submodule(s)
ie: emaint sync -r foo -r bar
The --sync-submodule option was added for developers working from the
git tree with the other git tree submodules added the the base gentoo
git ebuild tree. In our case the profiles did end up as part of the
main ebuild tree. But you can add the glsa and news git repos to the
git ebuild tree in order to make a complete repository.
NOTE: the above pertains to the developer git tree, not the anonymous
git tree. That git repo has had the glsa and news repos added to it
for general consumption.
Re: [gentoo-dev] rfc: "emerge --sync" vs "emaint sync"
Well I use eix-sync... As I can see in comment in the script beginning eix-sync uses emerge --sync: > This script calls emerge --sync and shows the differences. So that kind of transition to emaint sync would require a review from the current tools. On 5/6/20 11:11 PM, Zac Medico wrote: > On 5/6/20 3:02 PM, William Hubbs wrote: >> All, >> >> I know that most of our documentation tells people to use "emerge --sync"; >> however, today I heard about "emaint sync" for the first time. ;-) >> >> Which one should we use? Will there be a phase-out for "emerge --sync" or >> "emaint sync"? Are the plans to keep both available? > I'm strongly against removal of emerge --sync, since I don't want to > deal with inevitable backlash from trying to force users to change their > habits for no apparent reason. > >> Thanks, >> >> William >> > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: "emerge --sync" vs "emaint sync"
On 5/6/20 3:02 PM, William Hubbs wrote: > All, > > I know that most of our documentation tells people to use "emerge --sync"; > however, today I heard about "emaint sync" for the first time. ;-) > > Which one should we use? Will there be a phase-out for "emerge --sync" or > "emaint sync"? Are the plans to keep both available? I'm strongly against removal of emerge --sync, since I don't want to deal with inevitable backlash from trying to force users to change their habits for no apparent reason. > > Thanks, > > William > -- Thanks, Zac signature.asc Description: OpenPGP digital signature
[gentoo-dev] rfc: "emerge --sync" vs "emaint sync"
All, I know that most of our documentation tells people to use "emerge --sync"; however, today I heard about "emaint sync" for the first time. ;-) Which one should we use? Will there be a phase-out for "emerge --sync" or "emaint sync"? Are the plans to keep both available? Thanks, William signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: media-video/subliminal
> On 2 May 2020, at 11:12, Nikos Chantziaras wrote: > > On 19/04/2020 22:47, Michał Górny wrote: >> # Michał Górny (2020-04-19) >> # Unmaintained. Stuck on Python 3.6. Last release in 2016. >> # Removal in 30 days. Bug #718410. >> media-video/subliminal > > It's an active project. Just not doing releases often. Today 2.1.0 was > released: > > https://github.com/Diaoul/subliminal/releases/tag/2.1.0 > > Add support for python 3.6, 3.7 and 3.8 > Drop support for python 3.3 and 3.4 > > Yes, I will be saving this. I just had an email about the release.
Re: [gentoo-dev] Cleaning up the installation handbook (Legacy boot / MBR / ...)
> On 2 May 2020, at 21:30, Andreas K. Hüttel wrote: > > Hey all, > > our installation handbook is right now something of a mess (in particular > regarding partitioning, bootloader, gpt/uefi, ...) > > I'm hereby volunteering to clean things up. But - I'll go the brutal way: > > * Legacy boot and MBR will get kicked out. * > My preference would be to have a “preferred stream” detailed on the page, and some links to the old content for users on legacy. The old content could be moved as-is, just not deleted. Some people have modernish systems but cannot choose non-legacy due to vendors. Sam
Re: [gentoo-dev] [RFC] Should NATTkA reject keywordreqs for packages with -arch (-*) keywords?
On Wed, 2020-05-06 at 03:41 +0200, Thomas Deutschmann wrote: > On 2020-05-06 00:52, James Le Cuirot wrote: > > On Tue, 05 May 2020 22:19:59 +0200 > > Michał Górny wrote: > > > WDYT? > > > > Play it safe. -* is frequently used for binary packages where an > > arch > > will simply either work or it won't, with little likelihood of the > > situation changing. -arch is so rare that I don't recall ever > > seeing > > it. In either case, restoring an arch should be an explicit action. > > +1 > +1 with the addition that -arch (by opposition to -*) is usually used for specifying "this has been tested and is broken, don't waste your time on it". Or at least used to be used that way. If a package relies on arch specific support, then we could make a case that it should be '-*' + a whitelist of arches having said support. So, IMHO, -arch is quite version specific: package being broken is likely due to a bug that may or may not be fixed in later versions, hence, to me it makes total sense to have keyword reqs even for -arch if this is a newer version that the one that initially had its -arch added. I also believe tools like ekeyword or repoman should reset -arch to nothing, or at least issue a warning when adding new ebuilds with it, which would make this simpler for nattka. Alexis.
Re: [gentoo-dev] [RFC] Adding potentially questionable license AcePerl-Indemnity
On Thu, 23 Apr 2020 10:32:41 +1200 Kent Fredric wrote: Ugh. I just discovered this approach is in use in multiple packages. https://metacpan.org/source/LDS/AcePerl-1.92/DISCLAIMER.txt https://metacpan.org/source/LDS/Bio-SamTools-1.00/DISCLAIMER https://metacpan.org/source/AVULLO/Bio-DB-HTS-3.01/DISCLAIMER So most of my proposal would have to get re-thought anyway if we were going to do something about this. pgpr8nPzWwjWt.pgp Description: OpenPGP digital signature
