[gentoo-dev] Re: Deleting old news items
Michał Górny posted on Sat, 06 Jan 2018 00:55:58 +0100 as excerpted: > W dniu pią, 05.01.2018 o godzinie 23∶09 +0100, użytkownik Kristian > Fiskerstrand napisał: >> On 01/05/2018 10:28 PM, Aaron W. Swenson wrote: >>> On 2018-01-05 15:16, William Hubbs wrote: If we have a default expiration, it should be one year after the date posted to go along with our current policy of not supporting things that are older than a year. >>> >>> I thought it was three years. AFAIK, the one-year policy is on upgrades-from. If a user hasn't synced and updated in a year, updating is likely to be "problematic", and may require techniques such as digging old tree states a year or so apart out of git and using those to update a year's worth of updates at a time, and/ or updating the system in increments, the few packages that will update successfully first, then trying again to get the ones that can now update due to the improved base of the first set, and again... It helps if there's other systems you keep more current, so you've already dealt with most changes one or a few at a time. I know this from experience as while I keep my main system current (I'm antsy if it's more than a week between syncs), I used to have a 32-bit- only first-gen atom, that I built updates for in a chroot and synced over, that I'd sometimes go over a year between updates on. (Personal policy was nothing private on that machine, and it was normally not internet connected, so I wasn't horribly worried about security.) So over a year, while the above update method is normally still /possible/, the easier/recommended/supported method is simply using the old install to fetch a new stage-3 to a chroot, and install new to it, except that you can "cheat" by basing your new config including USE flags, etc, off the old one. The 3-year may well be for individual packages, but all I've ever seen for the entire tree and full system update is 1 year. >>> At any rate, I think a year is too short. >>> >>> How about 18 months? That seems a reasonable default... >> I might sound like a broken CD here, but why define the expiration as >> part of the news format instead of specifying it in the package manager >> as a user defined variable? Various use cases requires different >> treatment, so leaving it up to user seems more relevant to me, and we >> could allow information to be presented as part of stages to give a >> hint for what dates to look for? >> >> > To be honest, I kinda agree with Kristian here. I feel like this header > isn't going to work well. > > While the idea may initially sound good, I'm afraid we'll have the usual > developer split here: some developers will set very long times, some > will set very short times, some will not care and just copy some random > value (default, the value from some other news item). In the end, users > will end up seeing very old news items from dev X, while newer items > from dev Y will disappear. > > So yes, I think having a single predefined time is better, > for consistency at least. And allowing user to adjust that time based on > his own is certainly better than making it only dev-settable. $ equery b news.eselect app-admin/eselect-1.4.10 (/usr/share/eselect/modules/news.eselect) So in that case it's not the PM, but eselect. But a new eselect version that ships a default /etc/eselect/news/expiry that looks something like this: # Days after which unread news messages will no longer be shown # Default is 548, 18 months, (365*1.5 rounded up) expiry=548 ... and which then looks there for the value, seems reasonable to me. * Being in /etc the file would be subject to normal config-protection. * Can be accomplished with a bit of code and simple eselect package version bump, presumably with a post-install message mentioning the new config option. No need for all the bureaucracy of a GLEP update, etc. * Handbook and etc. documentation that I believe already mentions news and suggests eselect news as the default reader can be updated to mention this config option as well. * A news item announcing the new default expiry and config for it might be appropriate as well. * Should that general approach be agreed, all that would remain to debate would be whether 548 days (365*1.5 rounded up) is appropriate. The precise config file path, name and format would be up to the implementer and/or eselect news module maintainer. * Other news readers could of course set and ship their own default expiry, if desired. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: Deleting old news items
> On Sat, 6 Jan 2018, Duncan wrote: > $ equery b news.eselect > app-admin/eselect-1.4.10 (/usr/share/eselect/modules/news.eselect) > So in that case it's not the PM, but eselect. In fact, it is the PM that would do the filtering, before filling the list of unread news items in /var/lib/gentoo/news/news-gentoo.read. Filtering in eselect news would be problematic: Obtaining the list of items with "eselect news list" and e.g. reading them with "eselect news read" are issued as separate commands, which requires that the list of valid items does not change. However, time-based filtering could cause a race condition, like an item expiring between execution of the two commands. Ulrich pgpKPkjTXKbN6.pgp Description: PGP signature
[gentoo-dev] Packages up for grabs: app-cdr/{b5i,ccd,nrg,uif}2iso, app-cdr/bchunk
Hello, The following packages are now up for grabs due to their proxied maintainer retiring: app-cdr/b5i2iso app-cdr/bchunk app-cdr/ccd2iso app-cdr/nrg2iso app-cdr/uif2iso Those are practically zero-maintenance packages -- they're very old, probably don't need any updates and were bumped to EAPI 6 recently. -- Best regards, Michał Górny
[gentoo-dev] Improving the support for minor arches and less common profiles in CI
Hi, everyone. I think most of us agree that support for minor arches in Gentoo is suboptimal, and that we've pretty much been focusing on avoiding the problem than really solving it. At this moment, we have 8 arches with stable profiles: alpha amd64 arm hppa ia64 ppc ppc64 x86 We have 8 arches whose profiles are purely dev/exp: arm64 m68k mips nios2 riscv s390 sh sparc We also have dev/exp *-fbsd and prefix profiles. Of those arches: a. mips, *-fbsd and prefix use ~arch only, b. arm64 and sparc have reasonably supported stable tree (the former aiming to become stable profile, the latter recently lost the status), c. other minor arches have stable keywords added haphazardly. The main problems I see are: 1. The most of mainline tooling (repoman, CI, stable-bot) default to ignoring non-stable profiles because of the inconsistencies in dependency tree of those profiles. Sadly, this means that developers keep making it worse by missing new breakages they're introducing. This gives us an awful chicken-and-egg problem. 2. The meanings of 'dev' and 'exp' are really unclear to me. I'm not really sure if anyone follows a really clear criteria in classifying profiles to either. 3. We can't really expect to get all profiles of given type (dev or exp) to start passing at the same time. What I would really like to achieve is improvement of dependency tree consistency across different profiles. Ideally, we'd check that on all profiles, including dev and exp but realistically I don't think that could happen. The goal we've been originally pursuing was fixing depgraphs of different arches (arm64, mips) to the point when it became correct and marking them stable once that state was achieved. However, I'm not sure if this is eventually going to fly because: 一. We don't really seem to be getting much closer, and as I mentioned people keep committing new breakage. 二. I suppose marking mips stable would create some confusion resulting in people trying to stabilize stuff. 三. This wouldn't help e.g. sparc which has recently lost stable status. I'd still like to see it correct but I don't think the Council will agree upon restoring the stable status without proper arch team backing it. So I'm thinking of an alternate idea: to start adding staging warnings for additional profile class, combined with arch restriction. In other words, change CI from: -p stable to: -p stable,something -a alpha,amd64,...,mips,... with a separate class for NonSolvableDeps in non-stable profiles (like repoman's badindev/badinexp) that triggers only a staging-class warning. However, this means that: ১. We need to settle for either dev or exp being 'more' supported, and drop all unsupported profiles to the other group. ২. We need to fix the appropriate class of profiles for stable arches (or move them to the other group). ৩. The arches in question still need to generate reasonably low number of warnings. Your thoughts? -- Best regards, Michał Górny
Re: [gentoo-dev] Re: Deleting old news items
On 01/06/2018 05:05 AM, Ulrich Mueller wrote: >> On Sat, 6 Jan 2018, Duncan wrote: >> $ equery b news.eselect >> app-admin/eselect-1.4.10 (/usr/share/eselect/modules/news.eselect) >> So in that case it's not the PM, but eselect. > In fact, it is the PM that would do the filtering, before filling the > list of unread news items in /var/lib/gentoo/news/news-gentoo.read. > > Filtering in eselect news would be problematic: Obtaining the list > of items with "eselect news list" and e.g. reading them with "eselect > news read" are issued as separate commands, which requires that the > list of valid items does not change. However, time-based filtering > could cause a race condition, like an item expiring between execution > of the two commands. > > Ulrich The race condition could be addressed by issuing a warning at or around the time when expirations occur (midnight), with or without detecting specific expirations which may have occurred: WARNING: [n] is about to / has expired, and the list order is about to / has just changed (as appropriate for list and read respectively) Otherwise just warn when the commands run near midnight. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Dropped EAPI 2/3 support in virtualx.eclass
Hi all
As there are no consumers [1] of the virtualx.eclass using ancient EAPIs
I dropped support for EAPI=2/3
Best,
Justin
1)
https://qa-reports.gentoo.org/output/eapi-per-eclass/virtualx.eclass/
diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass
index d66149b70ba..38e629eef4f 100644
--- a/eclass/virtualx.eclass
+++ b/eclass/virtualx.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2015 Gentoo Foundation
+# Copyright 1999-2018 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: virtualx.eclass
@@ -11,17 +11,17 @@
if [[ ! ${_VIRTUAL_X} ]]; then
case "${EAPI:-0}" in
- 0|1)
+ 0|1|2|3)
die "virtualx.eclass: EAPI ${EAPI} is too old."
;;
- 2|3|4|5|6)
+ 4|5|6)
;;
*)
die "virtualx.eclass: EAPI ${EAPI} is not supported yet."
;;
esac
-[[ ${EAPI} == [2345] ]] && inherit eutils
+[[ ${EAPI} == [45] ]] && inherit eutils
# @ECLASS-VARIABLE: VIRTUALX_REQUIRED
# @DESCRIPTION:
@@ -57,7 +57,7 @@ case ${VIRTUALX_REQUIRED} in
RDEPEND=""
;;
optional|tests)
- [[ ${EAPI} == [2345] ]] \
+ [[ ${EAPI} == [45] ]] \
|| die 'Values "optional" and "tests" for
VIRTUALX_REQUIRED are
banned in EAPI > 5'
# deprecated section YAY.
eqawarn "VIRTUALX_REQUIRED=optional and VIRTUALX_REQUIRED=tests
are
deprecated."
@@ -90,12 +90,12 @@ esac
virtualmake() {
debug-print-function ${FUNCNAME} "$@"
- [[ ${EAPI} == [2345] ]] \
+ [[ ${EAPI} == [45] ]] \
|| die "${FUNCNAME} is unsupported in EAPI > 5, please use
virtx"
# backcompat for maketype
if [[ -n ${maketype} ]]; then
- [[ ${EAPI} == [2345] ]] || die "maketype is banned in EAPI > 5"
+ [[ ${EAPI} == [45] ]] || die "maketype is banned in EAPI > 5"
eqawarn "ebuild is exporting \$maketype=${maketype}"
eqawarn "Ebuild should be migrated to use 'virtx command'
instead."
VIRTUALX_COMMAND=${maketype}
@@ -205,13 +205,8 @@ virtx() {
# Do not break on error, but setup $retval, as we need
# to kill Xvfb
debug-print "${FUNCNAME}: $@"
- if has "${EAPI}" 2 3; then
- "$@"
- retval=$?
- else
- nonfatal "$@"
- retval=$?
- fi
+ nonfatal "$@"
+ retval=$?
# Now kill Xvfb
kill $(cat /tmp/.X${XDISPLAY}-lock)
@@ -229,7 +224,7 @@ virtx() {
Xmake() {
debug-print-function ${FUNCNAME} "$@"
- [[ ${EAPI} == [2345] ]] \
+ [[ ${EAPI} == [45] ]] \
|| die "${FUNCNAME} is unsupported in EAPI > 5, please use
'virtx
emake -j1 '"
eqawarn "you should not execute make directly"
@@ -243,7 +238,7 @@ Xmake() {
Xemake() {
debug-print-function ${FUNCNAME} "$@"
- [[ ${EAPI} == [2345] ]] \
+ [[ ${EAPI} == [45] ]] \
|| die "${FUNCNAME} is unsupported in EAPI > 5, please use
'virtx
emake '"
VIRTUALX_COMMAND="emake" virtualmake "$@"
@@ -255,7 +250,7 @@ Xemake() {
Xeconf() {
debug-print-function ${FUNCNAME} "$@"
- [[ ${EAPI} == [2345] ]] \
+ [[ ${EAPI} == [45] ]] \
|| die "${FUNCNAME} is unsupported in EAPI > 5, please use
'virtx
econf '"
VIRTUALX_COMMAND="econf" virtualmake "$@"
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Improving the support for minor arches and less common profiles in CI
Am Samstag, 6. Januar 2018, 12:10:53 CET schrieb Michał Górny: > Hi, everyone. > > I think most of us agree that support for minor arches in Gentoo > is suboptimal, and that we've pretty much been focusing on avoiding > the problem than really solving it. > I think it would help here to get the arches.desc glep off the ground. Sorry, I've been busy with a lot of other things, but I'll try to get this done soon. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, perl, libreoffice, comrel) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Deleting old news items
On Sat, 6 Jan 2018 08:18:19 -0500 kuzetsa wrote: > On 01/06/2018 05:05 AM, Ulrich Mueller wrote: > >> On Sat, 6 Jan 2018, Duncan wrote: > >> $ equery b news.eselect > >> app-admin/eselect-1.4.10 (/usr/share/eselect/modules/news.eselect) > >> So in that case it's not the PM, but eselect. > > In fact, it is the PM that would do the filtering, before filling > > the list of unread news items > > in /var/lib/gentoo/news/news-gentoo.read. > > > > Filtering in eselect news would be problematic: Obtaining the list > > of items with "eselect news list" and e.g. reading them with > > "eselect news read" are issued as separate commands, which requires > > that the list of valid items does not change. However, time-based > > filtering could cause a race condition, like an item expiring > > between execution of the two commands. > > The race condition could be addressed by issuing a warning > at or around the time when expirations occur (midnight), > with or without detecting specific expirations which may > have occurred: How accurate is "around"? Obviously we'd need to introduce a user configuration option so different users could set appropriate values for their needs. Seriously though, all this complexity is just highlighting that dates are a really bad way of deciding when a news item should expire, and that if we need anything, it's more Display-If conditions. -- Ciaran McCreesh
Re: [gentoo-dev] Re: Deleting old news items
On Sat, Jan 6, 2018 at 11:25 AM, Ciaran McCreesh < ciaran.mccre...@googlemail.com> wrote: > On Sat, 6 Jan 2018 08:18:19 -0500 > kuzetsa wrote: > > On 01/06/2018 05:05 AM, Ulrich Mueller wrote: > > >> On Sat, 6 Jan 2018, Duncan wrote: > > >> $ equery b news.eselect > > >> app-admin/eselect-1.4.10 (/usr/share/eselect/modules/news.eselect) > > >> So in that case it's not the PM, but eselect. > > > In fact, it is the PM that would do the filtering, before filling > > > the list of unread news items > > > in /var/lib/gentoo/news/news-gentoo.read. > > > > > > Filtering in eselect news would be problematic: Obtaining the list > > > of items with "eselect news list" and e.g. reading them with > > > "eselect news read" are issued as separate commands, which requires > > > that the list of valid items does not change. However, time-based > > > filtering could cause a race condition, like an item expiring > > > between execution of the two commands. > > > > The race condition could be addressed by issuing a warning > > at or around the time when expirations occur (midnight), > > with or without detecting specific expirations which may > > have occurred: > > How accurate is "around"? Obviously we'd need to introduce a user > configuration option so different users could set appropriate values > for their needs. > > Seriously though, all this complexity is just highlighting that dates > are a really bad way of deciding when a news item should expire, and > that if we need anything, it's more Display-If conditions. > > I rescind my patches; I'm fairly sure portage is broken and I don't really relish fixing it; I've already spent more than 2 hours working on this and this isn't worth spending more time on anyway. -A > -- > Ciaran McCreesh > >
Re: [gentoo-dev] Re: Deleting old news items
As a non-dev... > >In fact, it is the PM that would do the filtering, before filling the >list of unread news items in... How come news' transport is tied to the pm / package tree at all? It would seem more natural to fetch news using e.g. rss and have a reader (which i can configure) sort out what to fetch/display when. Anders
Re: [gentoo-dev] Re: Deleting old news items
On Sat, Jan 6, 2018 at 2:51 PM, Anders Thomson wrote: > > > As a non-dev... > > > >In fact, it is the PM that would do the filtering, before filling the > >list of unread news items in... > > How come news' transport is tied to the pm / package tree at all? It would > seem more natural to fetch news using e.g. rss and have a reader (which i > can configure) sort out what to fetch/display when. https://www.gentoo.org/glep/glep-0042.html#requirements details the whys. -A > > Anders > >
Re: [gentoo-dev] Re: Deleting old news items
On January 6, 2018 9:30:51 PM GMT+01:00, Alec Warner wrote: >On Sat, Jan 6, 2018 at 2:51 PM, Anders Thomson > >wrote: > >> >> >> As a non-dev... >> > >> >In fact, it is the PM that would do the filtering, before filling >the >> >list of unread news items in... >> >> How come news' transport is tied to the pm / package tree at all? It >would >> seem more natural to fetch news using e.g. rss and have a reader >(which i >> can configure) sort out what to fetch/display when. > > >https://www.gentoo.org/glep/glep-0042.html#requirements details the >whys. > Thanks. Which of the requirements requires transport to be in a particular manner? I see implications on pm, but nothing on transport. A -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[gentoo-dev] Package up for grabs: net-misc/bopm
Hi, everyone. Due to proxied maintainer taking a prolonged break, the following package is up for grabs: net-misc/bopm FWICS, this package is dead since 2015 [1]. If you're still using it, that notice recommends switching to hopm [2] which you can package for Gentoo! [1]:https://github.com/blitzed-org/bopm/commit/20a3406ad1c453a094e6be5b64ad45d9842c6f98 [2]:https://github.com/ircd-hybrid/hopm -- Best regards, Michał Górny
Re: [gentoo-dev] Re: Deleting old news items
On 01/06/2018 11:11 PM, Anders Thomson wrote: > Thanks. Which of the requirements requires transport to be in a > particular manner? I see implications on pm, but nothing on > transport. tl;dr; the PM knows which packages are installed on the specific system, a specific feed does not (although that doesn't exclude the possibility of getting feed of all messages, which is already part of git repository) -- 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] Re: Dropped EAPI 2/3 support in virtualx.eclass
Justin Lecher posted on Sat, 06 Jan 2018 13:23:12 + as excerpted: > As there are no consumers [1] of the virtualx.eclass using ancient EAPIs > I dropped support for EAPI=2/3 > > Best, > Justin > > 1) https://qa-reports.gentoo.org/output/eapi-per-eclass/virtualx.eclass/ > > > diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass Dropped, past tense, the commit is already made to the tree, or will drop using that diff, assuming no strong objections here? Keep in mind that people may still be using it in the overlays even when it's out of the main tree. That isn't on its own a reason to avoid dropping it from the eclass in the tree, but part of the idea of posting such changes here is to at least warn people maintaining overlays that /might/ use it, so they can either port or grab a copy of the eclass for their overlay before the change. So that past-tense "dropped", if indeed that's what it was, looks a bit rude, not giving notice at all. But if it's "dropped in this patch, but this patch not yet applied, so will drop in the tree when it is", carry- on with the usual timing, then. =:^) (My non-scientific observation seems to indicate at least a week of notice appears to be the norm, if there's no substantial changes suggested or a wait requested. If there's a wait requested, for out-of- tree I'd say perhaps a month, max, no longer necessary for out-of-tree unless you simply want to be extra nice, because if nothing else they can just grab a copy before the change and if they can't even do /that/ in a month... . Beyond that and the old version can always be dug out of git if necessary.) Either way, thanks for the cleanup. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] [PATCH 1/2] preserve-libs.eclass: Split off preserve_old_lib from eutils.
On Thu, 4 Jan 2018 10:35:23 -0500 Mike Gilbert wrote: > On Thu, Jan 4, 2018 at 5:23 AM, Pacho Ramos wrote: > > I have seen this is only used by: > > app-arch/xz-utils > > dev-libs/gmp > > dev-libs/libpcre > > dev-libs/mpc > > dev-libs/mpfr > > net-nds/openldap > > sys-libs/gdbm > > sys-libs/ncurses > > sys-libs/readline > > sys-process/audit > > > > Maybe we could deprecate it and try to drop it in the future :/ > > > > As Soap touched on earlier, this should probably not be > deprecated/removed until a solution compatible with Paludis and > pkgcore is implemented. > > A couple of options for that: > > 1. Add functionality similar to preserve-libs to these alternate > package managers. This is unlikely to happen. IMHO having profiles mandate a preserve-libs behavior (and thus PMS define this) for a few select packages (the ones above) is the way to go here: preserve-libs is evil but really the least evil in this case. If you miss the warning from the eclass, you can very easily end up with binaries loading the two versions of the library; preserve-libs has the advantage that portage is very loud about this.
