Re: Re : Re: [gentoo-portage-dev] Constraint-Based Dependency Solver for Portage: a prototype

[Michael Lienhardt]

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?

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2018-01-07 23:59 UTC

[Robin H. Johnson]

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

Re: [gentoo-dev] Improving the support for minor arches and less common profiles in CI

[Michał Górny]

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

[gentoo-dev] Re: [PATCH] Migrate CROSSCOMPILE_OPTS=headers-only -> USE=headers-only

[Sergei Trofimovich]

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

Re: [gentoo-dev] Re: Deleting old news items

[Denis Lisov]

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.

Re: [gentoo-dev] Re: Dropped EAPI 2/3 support in virtualx.eclass

[Aaron Bauman]

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 [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. =:^)

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.