W dniu sob, 06.01.2018 o godzinie 12∶10 +0100, użytkownik Michał Górny napisał: > 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. > I'd like to follow this with a more precise proposal. Namely, redefine the current profile statuses to apply the following: a. stable -> fully tested, all depgraph breakages are errors, b. exp -> fully tested, all depgraph breakages are warnings, c. dev -> developer's playground, not tested. This would specifically mean that: 1. Any 'exp' profiles with serious breakage will temporarily be downgraded to 'dev'. 2. A 'dev' profile can be upgraded to 'exp' if its scale of depgraph breakage is reasonable (i.e. doesn't clutter the QA report with too many warnings). 3. A 'exp' profile can be upgraded to 'stable' only if it has no depgraph breakages. I don't have a strong opinion on whether we should pursue marking all profiles 'stable', or if we support keeping 'exp' indefinitely. The CI would be updated to test 'exp' profiles and report staging warnings appropriately. Repoman would be updated to have warning-class dependency.badinexp (like it has for .badindev right now) and to check exp profiles by default. Your thoughts? -- Best regards, Michał Górny
On January 6, 2018 8:11:09 PM EST, Duncan <1i5t5.dun...@cox.net> wrote: >Justin Lecher posted on Sat, 06 Jan 2018 13:23:12 + as excerpted: > >> As there are no consumers  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. =:^) You think a distribution should wait a month for changes in order to not break something that is unsupported? He did give you the diff if you're that concerned. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Sat, 30 Dec 2017 18:48:02 + Sergei Trofimovich
wrote: > CROSSCOMPILE_OPTS is a USE_EXPAND of a single item: headers-only. > Convert it to a global USE flag instead. > > The changes are: > - mechanical ebuild rename (touches libcs and kernel headers): > $ sed -e 's@crosscompile_opts_headers-only@headers-only@g' \ > -i $(git grep -l headers-only) > - added global 'headers-only' USE > - CROSSCOMPILE_OPTS USE_EXPAND is removed > > 'headers-only' flag is used by crossdev to bootstrap stage1 compiler > before libc is available. > > crossdev switched to USE=headers-only in =sys-devel/crossdev-20171230. > After crossdev goes stable this change can go in. > > CC: toolch...@gentoo.org > CC: embed...@gentoo.org > CC: ker...@gentoo.org > CC: b...@gentoo.org > CC: bluen...@gentoo.org > CC: lu_z...@gentoo.org > Reported-by: Michał Górny > Bug: https://bugs.gentoo.org/642712 > Signed-off-by: Sergei Trofimovich Pushed as a batch of commits: 8dd32dc8bd8 profiles: drop CROSSCOMPILE_OPTS USE_EXPAND, bug #642712 e1172c04556 toolchain.eclass: Migrate CROSSCOMPILE_OPTS=headers-only -> USE=headers-only 60b276fb7c3 toolchain-glibc.eclass: Migrate CROSSCOMPILE_OPTS=headers-only -> USE=headers-only ce86854ff88 kernel-2.eclass: Migrate CROSSCOMPILE_OPTS=headers-only -> USE=headers-only 98965f4b376 dev-embedded/avr-libc: Migrate CROSSCOMPILE_OPTS=headers-only -> USE=headers-only e18277296d7 dev-libs/cygwin: Migrate CROSSCOMPILE_OPTS=headers-only -> USE=headers-only d4ea3345c87 dev-util/mingw-runtime: Migrate CROSSCOMPILE_OPTS=headers-only -> USE=headers-only 67ec9ae5fc7 dev-util/mingw64-runtime: Migrate CROSSCOMPILE_OPTS=headers-only -> USE=headers-only 84524c10349 dev-util/w32api: Migrate CROSSCOMPILE_OPTS=headers-only -> USE=headers-only 11ad885f29c sys-freebsd/freebsd-lib: Migrate CROSSCOMPILE_OPTS=headers-only -> USE=headers-only 91a02442c5a sys-libs/glibc: Migrate CROSSCOMPILE_OPTS=headers-only -> USE=headers-only d0bf3364d71 sys-libs/musl: Migrate CROSSCOMPILE_OPTS=headers-only -> USE=headers-only 7ebe9beefaf sys-libs/newlib: Migrate CROSSCOMPILE_OPTS=headers-only -> USE=headers-only 113d629bf4c sys-libs/uclibc: Migrate CROSSCOMPILE_OPTS=headers-only -> USE=headers-only 365914db135 sys-libs/uclibc-ng: Migrate CROSSCOMPILE_OPTS=headers-only -> USE=headers-only 7866e987215 profiles/use.desc: add new USE=headers-only global flag -- Sergei
On Sat, Jan 6, 2018 at 1:05 PM, Ulrich Mueller
wrote: > 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. Would it be possible to make the expiration times use not the wall clock time, but the timestamp of the repository if one is available? That would not only be more predictable (can expire on repository manipulations only), but also better suited for updating severely outdated systems. You can advance the repository state by 1 year and read the news items as they were at that time, not half of them expired and hidden. Denis Lisov.
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2018-01-07 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2018-01-07 23:59 UTC. Removals: app-admin/python-updater 20180106-10:33 zlogene 34d03159133 app-backup/obnam 20180106-13:45 zlogene e3029bf8c21 app-emulation/wine 20180106-10:45 zlogene c467bbb5c5f app-office/qchartdiary 20171231-15:34 asturm 8c3af46979e dev-perl/Mail-SPF-Query20180103-11:30 kentnl 518eb5a3a78 dev-python/whirlpool 20180106-10:11 zlogene fb968a71783 dev-tex/isotope20180106-15:59 zlogene bdb8fda5a5a dev-tex/notoccite 20180106-16:02 zlogene d2f0d3edaad dev-util/qfsm 20180106-09:59 zlogene bda69cb3e18 dev-util/ticpp 20180106-13:30 zlogene 821242f604f dev-vcs/bzr-explorer 20180103-20:14 asturm 87e9bbe5508 dev-vcs/qbzr 20180103-20:14 asturm 87e9bbe5508 dev-vcs/qct20180107-11:21 zlogene 6423e37b129 dev-vcs/qsvn 20180103-11:34 kensington 65db4508eb3 games-board/capicity 20171231-15:34 asturm 8c3af46979e games-board/holdingnuts20171231-15:34 asturm 8c3af46979e games-board/kcheckers 20171231-15:34 asturm 8c3af46979e games-board/qcheckers 20171231-15:34 asturm 8c3af46979e games-board/qgo20171231-15:34 asturm 8c3af46979e games-emulation/dboxfe 20171231-15:34 asturm 8c3af46979e games-emulation/virtualjaguar 20171231-15:34 asturm 8c3af46979e games-kids/cubetest20171231-15:34 asturm 8c3af46979e games-misc/ggencoder 20171231-15:34 asturm 8c3af46979e games-misc/qlife 20171231-15:34 asturm 8c3af46979e games-puzzle/bubble-chains 20171231-15:34 asturm 8c3af46979e games-puzzle/jag 20171231-15:34 asturm 8c3af46979e media-gfx/kpovmodeler 20171231-15:34 asturm 8c3af46979e net-analyzer/aimsniff 20180103-08:48 jstein be38db17570 net-analyzer/ntop 20180106-14:41 zlogene bf5252b406c net-ftp/oneclickftp20180107-11:47 zlogene 3ce8698387c net-im/pork20180107-14:19 zlogene 636d2a65484 net-im/pyaim-t 20180107-14:22 zlogene 7dbf45d0ac6 net-im/reaim 20180107-14:25 zlogene a049adcefca net-misc/arm 20180106-15:24 zlogene dbc4fad40f9 net-misc/mediatomb 20180104-17:56 thev00d00 294d8e32d9a net-misc/ocsync20180101-17:34 voyageuref9e4219ab4 sci-geosciences/gmapcatcher20180106-14:19 zlogene 741cab355bc sys-auth/pam-csync 20180101-17:35 voyageur9ef058de136 sys-kernel/tuxonice-sources20180106-12:00 zlogene a7dde116c54 www-apps/eyeos 20180101-17:32 voyageurd4bf7a29abf x11-drivers/afb-ucode 20180101-22:40 soapfd9be3c3ed4 x11-drivers/xf86-input-acecad 20180105-17:41 mattst88ed3b17b6bec x11-drivers/xf86-input-aiptek 20180105-17:41 mattst88ed3b17b6bec x11-drivers/xf86-input-fpit20180105-17:41 mattst88ed3b17b6bec x11-drivers/xf86-input-hyperpen20180105-17:41 mattst88ed3b17b6bec x11-drivers/xf86-input-mutouch 20180105-17:41 mattst88ed3b17b6bec x11-drivers/xf86-input-penmount20180105-17:41 mattst88ed3b17b6bec x11-drivers/xf86-video-apm 20180101-22:40 soapfd9be3c3ed4 x11-drivers/xf86-video-ark 20180101-22:40 soapfd9be3c3ed4 x11-drivers/xf86-video-chips 20180101-22:40 soapfd9be3c3ed4 x11-drivers/xf86-video-cirrus 20180101-22:40 soapfd9be3c3ed4 x11-drivers/xf86-video-freedreno 20180101-22:40 soapfd9be3c3ed4 x11-drivers/xf86-video-i12820180101-22:40 soapfd9be3c3ed4 x11-drivers/xf86-video-i74020180101-22:40 soapfd9be3c3ed4 x11-drivers/xf86-video-mach64 20180101-22:40 soapfd9be3c3ed4 x11-drivers/xf86-video-modesetting 20180105-17:39 mattst8817fcc04fd68 x11-drivers/xf86-video-neomagic20180101-22:40 soapfd9be3c3ed4 x11-drivers/xf86-video-opentegra 20180101-22:40 soapfd9be3c3ed4 x11-drivers/xf86-video-rendition 20180101-22:40 soapfd9be3c3ed4 x11-drivers/xf86-video-s3 20180101-22:40 soapfd9be3c3ed4 x11-drivers/xf86-video-s3virge 20180101-22:40 soapfd9be3c3ed4 x11-drivers/xf86-video-savage 20180101-22:40 soapfd9be3c3ed4 x11-drivers/xf86-video-sis 20180101-22:40 soapfd9be3c3ed4 x11-drivers/xf86-video-sisusb 20180101-22:40 soapfd9be3c3ed4 x11-drivers/xf86-video-suncg14 20180101-22:40 soapfd9be3c3ed4 x11-drivers/xf86-video-suncg3 20180101-22:40
Dear Alexander, Many thanks for the advices. I started few discussions on the forum and will go to FOSDEM. I'll see where it will go. Best, Michael Il 16/12/2017 14:39, Alexander Berntsen ha scritto: On 13/12/17 02:52, michael.lienha...@laposte.net wrote: But maybe there are things we can do to help start a dialog, like: - reaching in other mailing lists I don't think a post to gentoo-dev would be remiss in this case. - posting on a Gentoo forum Always useful, I'm told, though I don't venture there. But that way you're far more likely to engage *users*. - participating in a workshop/conference/other where we could directly meet and discuss with the community FOSDEM and Linux Days are probably the best choices. - or simply starting an informal discussion by email where instead of having to look into the Github repository, you could directly ask me If someone has the time, that'll probably naturally happen through the MLs. Christmas time tends to be peak bikeshedding hours at Gentoo, so maybe cross-post to -dev closer to the holidays?