[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2017-06-11 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2017-06-11 23:59 UTC. Removals: app-cdr/backlite 20170607-15:44 billie6553d279dde dev-perl/encoding-warnings 20170608-00:16 dilfridge a5036558498 dev-perl/ExtUtils-Constant 20170608-00:18 dilfridge 44c781fae29 dev-util/kdevelop-php-docs 20170605-12:19 asturmc9633f65567 dev-util/kdevelop-qmake 20170605-12:20 asturm3349b0fd803 dev-util/kdevelop-qmljs 20170605-12:20 asturmdf00518c2d8 kde-apps/attica 20170605-12:37 asturm342bf3466b5 kde-apps/drkonqi 20170605-12:37 asturm342bf3466b5 kde-apps/kcontrol20170605-12:37 asturm342bf3466b5 kde-apps/kdebase-desktoptheme20170605-12:37 asturm342bf3466b5 kde-apps/kdebase-menu20170605-12:37 asturm342bf3466b5 kde-apps/kdebase-menu-icons 20170605-12:37 asturm342bf3466b5 kde-apps/kdebugdialog20170605-12:37 asturm342bf3466b5 kde-apps/kdepasswd 20170605-12:37 asturm342bf3466b5 kde-apps/kdesu 20170605-12:37 asturm342bf3466b5 kde-apps/kfmclient 20170605-12:37 asturm342bf3466b5 kde-apps/kglobalaccel20170605-12:37 asturm342bf3466b5 kde-apps/kiconfinder 20170605-12:37 asturm342bf3466b5 kde-apps/kimgio 20170605-12:37 asturm342bf3466b5 kde-apps/knetattach 20170605-12:37 asturm342bf3466b5 kde-apps/konq-plugins20170605-12:37 asturm342bf3466b5 kde-apps/kpasswdserver 20170605-12:37 asturm342bf3466b5 kde-apps/kquitapp20170605-12:37 asturm342bf3466b5 kde-apps/kstart 20170605-12:37 asturm342bf3466b5 kde-apps/kuiserver 20170605-12:37 asturm342bf3466b5 kde-apps/kurifilter-plugins 20170605-12:37 asturm342bf3466b5 kde-apps/libkonq 20170605-12:37 asturm342bf3466b5 kde-apps/nsplugins 20170605-12:37 asturm342bf3466b5 kde-apps/plasma-apps 20170605-12:37 asturm342bf3466b5 kde-apps/renamedlg-plugins 20170605-12:37 asturm342bf3466b5 kde-apps/solid-runtime 20170605-12:37 asturm342bf3466b5 kde-misc/kim420170605-12:29 asturm2330f2d1817 kde-misc/kio-ftps20170605-12:29 asturm68266a49cbd kde-misc/quadkonsole 20170605-12:30 asturm3b775e677cc sys-auth/polkit-kde-agent20170605-12:26 asturm91589327cc9 Additions: app-misc/go-jira 20170605-15:00 mrueg 99546bff477 dev-python/sabyenc 20170607-21:31 jsbronder eb697a36540 dev-texlive/texlive-plaingeneric 20170608-10:58 aballier 13718b32098 dev-util/clair 20170605-22:21 mrueg 85988119100 kde-plasma/plymouth-kcm 20170607-16:40 johu ab5aab52d2c net-misc/yangcli-pro 20170607-10:45 chainsaw 0b3bf9c4b8b sys-cluster/zetcd20170608-12:50 mrueg 1a1337abdd6 sys-kernel/kpatch20170604-00:51 soap 37f7d400908 -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-perl/ExtUtils-Constant,removed,dilfridge,20170608-00:18,44c781fae29 dev-perl/encoding-warnings,removed,dilfridge,20170608-00:16,a5036558498 app-cdr/backlite,removed,billie,20170607-15:44,6553d279dde kde-apps/attica,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/drkonqi,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/kcontrol,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/kdebase-desktoptheme,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/kdebase-menu-icons,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/kdebase-menu,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/kdebugdialog,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/kdepasswd,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/kdesu,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/kfmclient,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/kglobalaccel,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/kiconfinder,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/kimgio,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/knetattach,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/konq-plugins,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/kpasswdserver,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/kquitapp,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/kstart,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/kuiserver,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/kurifilter-plugins,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/libkonq,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/nsplugins,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/plasma-apps,removed,asturm,20170605-12:37,342bf3466b5 kde-apps/renamedlg-plugins,removed,asturm
Re: [gentoo-dev] [PATCH] systemd.eclass: Improve systemd_install_serviced documentation
On Sun, Jun 11, 2017 at 3:23 PM, Chris Mayo wrote: > Signed-off-by: Chris Mayo Signed-off-by is not required for Gentoo contributions. > --- > > Nothing added, just suggesting how it could be made easier to understand. > > Chris The patch looks ok; I'll push it if there are no objections over the next day or so.
[gentoo-dev] Hardening a default profile
Hello, so I've been running Gentoo Hardened for a few years on my laptop, my desktop, and a server made from an older desktop. Because of Grsecurity closing access to its source to non-subscribers, I decided that I would just try to stick with Gentoo-sources and harden the default profile and follow the KSSP guidelines to get as close as possible without losing the testing kernel. Because of this, I no longer used the PaX features and decided switch to the default profile and enabling my own flags. I enabled pie, ssp, and appended my CFLAGS with -fstack-protector-all and LDFLAGS with full RELRO support (and --sort-common). I saw that GCC still uses the FORTIFY patch so I didn't need to add that. So far I've had absolutely no issues with this setup but I was trying to see if there's anything else I could do to bridge it closer to where it was and noticed that there are several warnings against this as it could break packages (including glibc). I've had no breakages myself that are visable at least and no build failures. So I was just wondering if ~arch is ready for more secure defaults on the 17.0 profiles in the linker flags. There are several distributions which ship RELRO by default and I am not aware of any performance issues regarding this. At least to me it shouldn't be warned against unless there are lots of build failures these days. Of course though, I'm not a dev and would like to see your perspective on this. Thank you, Michael Brinkman
[gentoo-dev] gna.org shutdown requires ~80 ebuilds without maintainer to be fixed
Dear all, Sylvain from the gna.org team announced on 2016-11-20 to shut down the repository [1]. Today we have still ~80 ebuilds with gna.org in the SRC_URI and/or HOMEPAGE variables in the tree. Unfortunately these ebuilds have no maintainer. A list is online [2] Please fix the ebuilds, in order to save them from getting on the treeclean candidates list. More than 5 large repositories shut down in the last 3 years. A wiki page for shut down repositories was prepared to keep a better overview [3]. [1] http://web.archive.org/web/20170327102552/https://mail.gna.org/public/project/2016-11/msg1.html [2] https://wiki.gentoo.org/wiki/Upstream_repository_shutdowns/gna.org [3] https://wiki.gentoo.org/wiki/Upstream_repository_shutdowns -- Best, Jonas
Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac
Ühel kenal päeval, P, 11.06.2017 kell 13:08, kirjutas William Hubbs: > On Sun, Jun 11, 2017 at 07:14:52PM +0300, Mart Raudsepp wrote: > > Ühel kenal päeval, P, 11.06.2017 kell 11:12, kirjutas William > > Hubbs: > > > On Sun, Jun 11, 2017 at 05:35:53PM +0200, Kristian Fiskerstrand > > > wrote: > > > > On 06/11/2017 05:24 PM, David Seifert wrote: > > > > > > We can always patch the eclass at that point if that is > > > > > > still a > > > > > > big > > > > > > concern, but I fundamentally agree with William on this, > > > > > > starting > > > > > > point > > > > > > should be fixing it upstream, so can start with a tracking > > > > > > bug > > > > > > on > > > > > > affected packages. > > > > > > > > > > > > > > > > Here's a deal: you can start filing + fixing them. > > > > > > > > > > > > > The [tracker] is already started, it was determined to add QA > > > > warning > > > > with info on filing upstream bugs in [bug 426262] and the > > > > proper > > > > solution is again iterated in [bug 546614], so its not like > > > > this is > > > > a > > > > new approach that is being suggested, but sure, we should all > > > > file > > > > bugs > > > > when we encounter them. > > > > > > > > References: > > > > [tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632 > > > > > > > > [bug 426262] > > > > https://bugs.gentoo.org/show_bug.cgi?id=426262 > > > > > > > > [bug 546614] > > > > https://bugs.gentoo.org/show_bug.cgi?id=546614 > > > > > > It seems that the proper fix to this, even for a package that > > > won't > > > do > > > the fix upstream is to use WANT_AUTOCONF in the ebuild to force > > > the > > > version of autoconf you need. > > > > No. It appears you don't know how WANT_AUTOCONF works. > > > From the eclass: > > # @ECLASS-VARIABLE: WANT_AUTOCONF > # @DESCRIPTION: > # The major version of autoconf your package needs > > That leads me to believe that you can set WANT_AUTOCONF="someversion" > in your ebuild and your package will use that version of autoconf. > > If that's wrong, it needs to be fixed and that's a different bug > entirely, but it doesn't change my position on adding this particular > change to autotools.eclass. It is the major version, as documented. Yes, it could specify what these valid versions currently are, as they really are: none 2.1 2.5 latest Currently latest equals 2.5 and is the default. In practice, none means not to add an autoconf atom to DEPEND (even with the default AUTOTOOLS_AUTO_DEPEND=yes) - if ebuild/eclass inheriting autotools.eclass handles its own exact autoconf depend atom (eautoconf will get called in eautoreconf regardless). Only main tree consumer of this appears to be gtk-sharp-module.eclass that adds its own autoconf/automake atoms when needed, because eautoreconf is conditional by variables used by that eclass and it needed autoconf 2.61 or newer, not just 2.59. 2.1 means autoconf:2.1 2.5 and latest currently means >=autoconf-2.59 Patches welcome to documentation, I suppose. It is usually a bad sign if you need to change it away from latest for some reason in the ebuild and ideally they'd all be the default (latest). There was no configure.ac before autoconf-2.50, only configure.in, and thus a warning doesn't make sense. The real warning here is the need for WANT_AUTOCONF=2.1 HTH, Mart
[gentoo-dev] [PATCH] systemd.eclass: Improve systemd_install_serviced documentation
Signed-off-by: Chris Mayo
---
Nothing added, just suggesting how it could be made easier to understand.
Chris
eclass/systemd.eclass | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
index 7e46e80119c..49f7480228b 100644
--- a/eclass/systemd.eclass
+++ b/eclass/systemd.eclass
@@ -178,12 +178,12 @@ systemd_newuserunit() {
}
# @FUNCTION: systemd_install_serviced
-# @USAGE: []
+# @USAGE: []
# @DESCRIPTION:
-# Install the file as service.d/00gentoo.conf template.
-# The argument specifies the configured service name.
-# If not specified, the configuration file name will be used with .conf
-# suffix stripped (e.g. foo.service.conf -> foo.service).
+# Install as the template .d/00gentoo.conf.
+# If is not specified
+# with the .conf suffix stripped is used
+# (e.g. foo.service.conf -> foo.service.d/00gentoo.conf).
systemd_install_serviced() {
debug-print-function ${FUNCNAME} "${@}"
--
2.13.0
Re: [gentoo-dev] New 17.0 release profiles
On Sun, Jun 11, 2017, at 13:39 CDT, "Walter Dnes" wrote: > 1) Should I be doing bug reports on the Gentoo bugzilla or upstream? Please check [1] and if not already reported open a bug report blocking [1] on our bugzilla. Best, Matthias [1] https://bugs.gentoo.org/show_bug.cgi?id=gcc-6
Re: [gentoo-dev] New 17.0 release profiles
On Sat, Jun 10, 2017 at 05:15:05PM +0200, Andreas K. Huettel wrote
> -> The new profiles will NOT have any entries in profiles.desc
> yet. For "normal people" that means DO NOT SWITCH to these profiles
> yet. <-
>
> However, if you're involved with toolchain, languages, etc, already
> run gcc-6, and know what you're doing, feel free to adjust your
> profile symlink manually. You will have to rebuild all packages
> installing static archives because of the PIC flip.
>
> All testing is appreciated, as is writing of documentation. Just be
> advised to watch this list for news since THINGS MAY STILL CHANGE
> in weird and wonderful ways.
I'm running GCC 6.3.0 on a few machines with almost all other packages
stable. Only busybox is static on my machines, and it's been rebuilt.
So far I've run into...
* games-board/xfreecell needs CXXFLAGS="${CXXFLAGS} -Wno-narrowing"
in a custom env to build.
* x11-wm/icewm segfaults right after startup when built with GCC 6.3.0
so I have to build with 5.4.0. /var/log/Xorg.0.log is useless because
it sees a normal startup and a "normal exit". Other people on the
Gentoo user forum report no problems with ICEWM under GCC 6.3.0.
The above 2 items happen on an older desktop and netbook (both 32-bit
Gentoo), and a newer desktop (64-bit Gentoo). I'm partially finished
re-installing on a "newer" notebook (64-bit Gentoo). Questions...
1) Should I be doing bug reports on the Gentoo bugzilla or upstream?
2) What is the detailed procedure for adjusting symlinks to the 17.0
profile? Probably simple enough after you've done it once or twice,
but I've never had to do it manually before. According to
https://wiki.gentoo.org/wiki/Upgrading_Gentoo
> In the simplest case users only have to change the
> /etc/portage/make.profile symlink, in the worst case they may have
> to recompile the entire system from scratch while doing a neat
> voodoo dance.
--
Walter Dnes
I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac
On Sun, Jun 11, 2017 at 07:14:52PM +0300, Mart Raudsepp wrote: > Ühel kenal päeval, P, 11.06.2017 kell 11:12, kirjutas William Hubbs: > > On Sun, Jun 11, 2017 at 05:35:53PM +0200, Kristian Fiskerstrand > > wrote: > > > On 06/11/2017 05:24 PM, David Seifert wrote: > > > > > We can always patch the eclass at that point if that is still a > > > > > big > > > > > concern, but I fundamentally agree with William on this, > > > > > starting > > > > > point > > > > > should be fixing it upstream, so can start with a tracking bug > > > > > on > > > > > affected packages. > > > > > > > > > > > > > Here's a deal: you can start filing + fixing them. > > > > > > > > > > The [tracker] is already started, it was determined to add QA > > > warning > > > with info on filing upstream bugs in [bug 426262] and the proper > > > solution is again iterated in [bug 546614], so its not like this is > > > a > > > new approach that is being suggested, but sure, we should all file > > > bugs > > > when we encounter them. > > > > > > References: > > > [tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632 > > > > > > [bug 426262] > > > https://bugs.gentoo.org/show_bug.cgi?id=426262 > > > > > > [bug 546614] > > > https://bugs.gentoo.org/show_bug.cgi?id=546614 > > > > It seems that the proper fix to this, even for a package that won't > > do > > the fix upstream is to use WANT_AUTOCONF in the ebuild to force the > > version of autoconf you need. > > No. It appears you don't know how WANT_AUTOCONF works. From the eclass: # @ECLASS-VARIABLE: WANT_AUTOCONF # @DESCRIPTION: # The major version of autoconf your package needs That leads me to believe that you can set WANT_AUTOCONF="someversion" in your ebuild and your package will use that version of autoconf. If that's wrong, it needs to be fixed and that's a different bug entirely, but it doesn't change my position on adding this particular change to autotools.eclass. William signature.asc Description: Digital signature
Re: [gentoo-dev] Last rites: www-client/phantomjs and dev-ruby/poltergeist
On Sun, 11 Jun 2017 08:38:26 +0200 Hans de Graaff wrote: > I've updated the proposed timeframe in the mask to 90 days. That's reasonable. Thanks :) pgpFU7aP7HlSq.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Restricting allowed nesting of REQUIRED_USE
On Sat, 10 Jun 2017 00:30:07 +0200 Michał Górny wrote: > Hi, everyone. > > As you may or may not know, PMS says rather little about REQUIRED_USE > [1,2]. The largest past of the definition is shared with other > dependency-like specifications [3]. > > Similarly to regular dependency specifications, PMS is rather lax in > nesting things. While this isn't a major problem for dependencies > where the syntax is limited to any-of, all-of and USE-conditional > groups (though it already may cause some confusion there), it allows > quite a bit of a mayhem with the full set of REQUIRED_USE clauses. > > We have five different kinds of clauses there: any-of, at-most-one-of, > exactly-one-of, all-of and USE-conditional. Furthermore, unlike > in dependency specifications, the last type is circular with flags > enforced by REQUIRED_USE constraints. > > While nesting all of those clauses is technically valid (and can be > logically verified), it has no proven usability. As a result, it is > either not used at all or has a few use cases which suffer from poor > readability and can be easily replaced with *much simpler* > constraints. In fact, allowing them is not solving any issues but > only introducing more when developers fail at using them. > > I would therefore like to discuss restricting nesting of REQUIRED_USE > clauses. > > > What's my take in this? As you have probably noticed (and stopped > reading) I am working with Alexis on solving REQUIRED_USE constraints > automatically. We're working towards a few goals: keeping things > simple, giving predictable solutions, and being able to automatically > validate whether the constraints are solvable. > > While we're near solving almost everything, the complex clauses add > unnecessary complexity (both to the spec and to the code) which does > not really benefit anyone, and bring solutions that can not be > predictable because the clauses are ambiguous by design. > > To avoid adding this complexity, it would be reasonable to ban at > least some of the non-useful combinations. This means either banning > them completely (in a future EAPI + possibly repoman) so that > developers do not even try to use them, or disabling autosolving when > they are being used). I'm not sure it is worth restricting too much in the spec, at least now. It certainly has benefits, but the extra complexity they add forces to thoroughly think about how to design the proper solver, which I don't see as a bad thing. The main problem is that the solver, in those complex cases, will provide results that, at least to me, do not seem natural. It'd probably be a very good thing to restrict the allowed nesting since they add (runtime) complexity to the solver & checker, like a repoman warning and/or error, depending on some threshold. On the other hand, the syntax you propose seems way much saner. I like it and consider it is a good way to guide developers into writing easily predictable constraints. However, I would not disable auto solving when this does not match, I would have a generic algorithm, and wait for field testing before deciding if people are happy with the results or if they prefer to rewrite their constraints in a saner way to have a straightforward interpretation of the solver results. Bests, Alexis.
Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac
Ühel kenal päeval, P, 11.06.2017 kell 11:12, kirjutas William Hubbs: > On Sun, Jun 11, 2017 at 05:35:53PM +0200, Kristian Fiskerstrand > wrote: > > On 06/11/2017 05:24 PM, David Seifert wrote: > > > > We can always patch the eclass at that point if that is still a > > > > big > > > > concern, but I fundamentally agree with William on this, > > > > starting > > > > point > > > > should be fixing it upstream, so can start with a tracking bug > > > > on > > > > affected packages. > > > > > > > > > > Here's a deal: you can start filing + fixing them. > > > > > > > The [tracker] is already started, it was determined to add QA > > warning > > with info on filing upstream bugs in [bug 426262] and the proper > > solution is again iterated in [bug 546614], so its not like this is > > a > > new approach that is being suggested, but sure, we should all file > > bugs > > when we encounter them. > > > > References: > > [tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632 > > > > [bug 426262] > > https://bugs.gentoo.org/show_bug.cgi?id=426262 > > > > [bug 546614] > > https://bugs.gentoo.org/show_bug.cgi?id=546614 > > It seems that the proper fix to this, even for a package that won't > do > the fix upstream is to use WANT_AUTOCONF in the ebuild to force the > version of autoconf you need. No. It appears you don't know how WANT_AUTOCONF works.
Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac
On Sun, Jun 11, 2017 at 05:35:53PM +0200, Kristian Fiskerstrand wrote: > On 06/11/2017 05:24 PM, David Seifert wrote: > >> We can always patch the eclass at that point if that is still a big > >> concern, but I fundamentally agree with William on this, starting > >> point > >> should be fixing it upstream, so can start with a tracking bug on > >> affected packages. > >> > > Here's a deal: you can start filing + fixing them. > > > > The [tracker] is already started, it was determined to add QA warning > with info on filing upstream bugs in [bug 426262] and the proper > solution is again iterated in [bug 546614], so its not like this is a > new approach that is being suggested, but sure, we should all file bugs > when we encounter them. > > References: > [tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632 > > [bug 426262] > https://bugs.gentoo.org/show_bug.cgi?id=426262 > > [bug 546614] > https://bugs.gentoo.org/show_bug.cgi?id=546614 It seems that the proper fix to this, even for a package that won't do the fix upstream is to use WANT_AUTOCONF in the ebuild to force the version of autoconf you need. Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)
On Fri, 09 Jun 2017 18:21:50 +0200
Michał Górny wrote:
> (cut off the parts where I agree and there's nothing to add)
>
> On pią, 2017-06-09 at 16:16 +0200, Alexis Ballier wrote:
> > [...]
> > > > In your example above, we'd call 'nsolve("|| ( X )")' and
> > > > 'nsolve("|| ( Y )")' (or even simpler, depending on how
> > > > simplify() is defined). If both X and Y are masked on a
> > > > profile, then that'd reduce to 'nsolve("False")' which would
> > > > rant.
> > >
> > > So you're talking about reducing prior to transforming? Yes,
> > > that'd work. As I mentioned in one of the first mails wrt my
> > > reference implementation, I've used reordering (stable sort)
> > > instead of reducing since it was simpler.
> > >
> > > If you reduce (simplify), you need to account for special cases
> > > like getting '|| ()' etc. If you reorder only, things just fail
> > > the normal way.
> >
> > While the reordering idea seems nice as it factors both user
> > preference and masks, the problem with reordering is that nothing
> > guarantees that the solver won't try to enable a masked flag. We'd
> > have to deal with that somehow.
>
> Well, yes and no.
>
> The algorithm always needs to account for the possibility of
> constraints altering immutable flags. Of course, there's more than
> one way of doing it.
>
> AFAIU you are aiming for separate processing of immutable flags
> and explicit failure if the constraints would attempt to force value
> of those flags. That surely makes sense for verification.
The semi-hidden goal here for me is to have purely ast rewriting rules
giving a list of implications. This makes the solver trivial as those
are read as "if condition then constraint" and can be used as input for
the checker. Failing that, this would need to be done on the checker
side anyway and then we might run into problems like the checker not
really checking reality since the solver behaves a little bit
differently.
> My approach was simpler -- marking the flags immutable, and failing if
> something actually tries to alter their value. I think it's a simpler
> solution for the plain solver and it works as well. After all, we do
> not want the solver to attempt to find workarounds for the problem
> but just fail.
This should be equivalent: masked flags will be toggled as last resort
and fail; eliminated flags will not be toggled at all and fail if
having them as immutable causes a contradiction
> The above applies clearly to the plain conflicts such as:
>
> foo? ( bar )
>
> where bar is immutable. The n-ary operators can be flexed a little.
> That's what reordering achieves -- it makes sure they come as the most
> or the least preferred as appropriate. Which means that the same
> algorithm either succeeds (by not having to touch them) or fails at
> attempting to flip them.
>
> Think of:
>
> ?? ( a b c )
>
> with both b&c in use.force. This gets reordered to:
>
> ?? ( b c a )
>
> The order between b&c doesn't matter. Since b comes first now, it
> forces c being disabled. Since c is immutable, the solver fails with
> ImmutabilityError. We solve the problem with minimal code redundancy.
Considering that code should ideally be checked, that'd be '?? ( a true
true )' reducing to 'false' and a repoman error.
> > I think reordering should be kept for user preferences
> > (soft-enable/soft-disable) while masks for hard-no's or hard-yes'es.
> >
> >
> > Be careful with reordering though:
> > '^^ ( a b ) b? ( a )' can be solved in one pass.
> > (it disables b if both are set and enables a if none are set)
> >
> > while:
> > '^^ ( b a ) b? ( a )' loops
> > (if both are set it disables 'a' for the 1st clause but then
> > enables it for the 2nd)
> >
> > This is not checked by nsolve().
>
> Yes, this is a problem I was considering. I planned to think a bit if
> we could possibly generate some more complex transformations to
> trigger nsolve to notice this kind of issues.
Except feeding the n! possible reorderings to nsolve() and checking them
all I don't see many other possibilities.
We could think about a transformation that would be order agnostic,
like '|| ( a b c )' giving the same output as '|| ( b c a )' but then
this would not express any preference anymore. Remember: The whole
point of the solver is to break the symmetry of SAT formulas so that
there is a natural way to solve them instead of just "figure out some
useflags that make it work". In other words, order does actually
matter a lot, otherwise you fall into the "solve SAT" trap again.
> And now two updates on other matters.
>
> Firstly, all-of inside ??. Per the construct:
>
> ?? ( ( a b ) c )
>
> the expansion would be:
>
> [a b]? ( !c ) c? ( ![a b] )
>
> which means we should be able to easily affect the effective behavior
> of both implementations by defining how to handle/expand negations of
> all- of groups.
>
> It's then a matter of replacing it with:
>
> a. !a, or
>
> b. !a !b.
>
> As you pointed o
Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac
On Sun, 11 Jun 2017 17:20:49 +0200 Kristian Fiskerstrand wrote: > On 06/11/2017 05:17 PM, Mart Raudsepp wrote: > >> We can always patch the eclass at that point if that is still a big > >> concern, but I fundamentally agree with William on this, starting > >> point > >> should be fixing it upstream, so can start with a tracking bug on > >> affected packages. > > That's a complete useless waste of time, to track some ancient > > packages that don't get any upstream update anyway. The active ones > > have updated it long ago. And it'd be a joke to propose last riting > > for the reason of a file being named configure.in instead of > > configure.ac. > > > > > > That determination can be made on a package-by-package basis and fixed > in ebuild if needed. > Funny thing is that packages still using autoconf 2.1* don't get any warning and packages setting WANT_AUTOCONF to some older version will never break...
Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac
On 06/11/2017 05:24 PM, David Seifert wrote: >> We can always patch the eclass at that point if that is still a big >> concern, but I fundamentally agree with William on this, starting >> point >> should be fixing it upstream, so can start with a tracking bug on >> affected packages. >> > Here's a deal: you can start filing + fixing them. > The [tracker] is already started, it was determined to add QA warning with info on filing upstream bugs in [bug 426262] and the proper solution is again iterated in [bug 546614], so its not like this is a new approach that is being suggested, but sure, we should all file bugs when we encounter them. References: [tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632 [bug 426262] https://bugs.gentoo.org/show_bug.cgi?id=426262 [bug 546614] https://bugs.gentoo.org/show_bug.cgi?id=546614 -- 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] autotools.eclass: automatically move configure.in to configure.ac
On Sun, 2017-06-11 at 17:12 +0200, Kristian Fiskerstrand wrote:
> On 06/11/2017 05:07 PM, Mart Raudsepp wrote:
> > Ühel kenal päeval, P, 11.06.2017 kell 10:00, kirjutas William
> > Hubbs:
> > > On Sat, Jun 10, 2017 at 01:04:06PM +0100, Sergei Trofimovich
> > > wrote:
> > > > On Sat, 10 Jun 2017 13:28:19 +0200
> > > > Jeroen Roovers wrote:
> > > >
> > > > > https://bugs.gentoo.org/show_bug.cgi?id=426262
> > > > > + mv configure.{in,ac} || die
> > > >
> > > > Looks good.
> > > >
> > > > --
> > > >
> > > > Sergei
> > >
> > > -1
> > >
> > > I think this should be handled by the packages, not at the eclass
> > > level.
> > >
> > > https://bugs.gentoo.org/show_bug.cgi?id=426262#c3
> > >
> > > The packages should either mv the configure.in to configure.ac
> > > internally, or better yet, the maintainers should ask upstream
> > > for
> > > their
> > > packages to fix it.
> >
> > +1, otherwise we will never be able to add/unmask a newer autoconf
> > that
> > doesn't look at configure.in anymore, once such a version
> > eventually
> > happens.
> >
>
> We can always patch the eclass at that point if that is still a big
> concern, but I fundamentally agree with William on this, starting
> point
> should be fixing it upstream, so can start with a tracking bug on
> affected packages.
>
Here's a deal: you can start filing + fixing them.
David
Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac
On 06/11/2017 05:17 PM, Mart Raudsepp wrote: >> We can always patch the eclass at that point if that is still a big >> concern, but I fundamentally agree with William on this, starting >> point >> should be fixing it upstream, so can start with a tracking bug on >> affected packages. > That's a complete useless waste of time, to track some ancient packages > that don't get any upstream update anyway. The active ones have updated > it long ago. And it'd be a joke to propose last riting for the reason > of a file being named configure.in instead of configure.ac. > > That determination can be made on a package-by-package basis and fixed in ebuild if needed. -- 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] autotools.eclass: automatically move configure.in to configure.ac
Ühel kenal päeval, P, 11.06.2017 kell 17:12, kirjutas Kristian
Fiskerstrand:
> On 06/11/2017 05:07 PM, Mart Raudsepp wrote:
> > Ühel kenal päeval, P, 11.06.2017 kell 10:00, kirjutas William
> > Hubbs:
> > > On Sat, Jun 10, 2017 at 01:04:06PM +0100, Sergei Trofimovich
> > > wrote:
> > > > On Sat, 10 Jun 2017 13:28:19 +0200
> > > > Jeroen Roovers wrote:
> > > >
> > > > > https://bugs.gentoo.org/show_bug.cgi?id=426262
> > > > > + mv configure.{in,ac} || die
> > > >
> > > > Looks good.
> > > >
> > > > --
> > > >
> > > > Sergei
> > >
> > > -1
> > >
> > > I think this should be handled by the packages, not at the eclass
> > > level.
> > >
> > > https://bugs.gentoo.org/show_bug.cgi?id=426262#c3
> > >
> > > The packages should either mv the configure.in to configure.ac
> > > internally, or better yet, the maintainers should ask upstream
> > > for
> > > their
> > > packages to fix it.
> >
> > +1, otherwise we will never be able to add/unmask a newer autoconf
> > that
> > doesn't look at configure.in anymore, once such a version
> > eventually
> > happens.
> >
>
> We can always patch the eclass at that point if that is still a big
> concern, but I fundamentally agree with William on this, starting
> point
> should be fixing it upstream, so can start with a tracking bug on
> affected packages.
That's a complete useless waste of time, to track some ancient packages
that don't get any upstream update anyway. The active ones have updated
it long ago. And it'd be a joke to propose last riting for the reason
of a file being named configure.in instead of configure.ac.
Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac
On 06/11/2017 05:07 PM, Mart Raudsepp wrote:
> Ühel kenal päeval, P, 11.06.2017 kell 10:00, kirjutas William Hubbs:
>> On Sat, Jun 10, 2017 at 01:04:06PM +0100, Sergei Trofimovich wrote:
>>> On Sat, 10 Jun 2017 13:28:19 +0200
>>> Jeroen Roovers wrote:
>>>
https://bugs.gentoo.org/show_bug.cgi?id=426262
+ mv configure.{in,ac} || die
>>>
>>> Looks good.
>>>
>>> --
>>>
>>> Sergei
>>
>> -1
>>
>> I think this should be handled by the packages, not at the eclass
>> level.
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=426262#c3
>>
>> The packages should either mv the configure.in to configure.ac
>> internally, or better yet, the maintainers should ask upstream for
>> their
>> packages to fix it.
>
> +1, otherwise we will never be able to add/unmask a newer autoconf that
> doesn't look at configure.in anymore, once such a version eventually
> happens.
>
We can always patch the eclass at that point if that is still a big
concern, but I fundamentally agree with William on this, starting point
should be fixing it upstream, so can start with a tracking bug on
affected packages.
--
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] autotools.eclass: automatically move configure.in to configure.ac
Ühel kenal päeval, P, 11.06.2017 kell 10:00, kirjutas William Hubbs:
> On Sat, Jun 10, 2017 at 01:04:06PM +0100, Sergei Trofimovich wrote:
> > On Sat, 10 Jun 2017 13:28:19 +0200
> > Jeroen Roovers wrote:
> >
> > > https://bugs.gentoo.org/show_bug.cgi?id=426262
> > > + mv configure.{in,ac} || die
> >
> > Looks good.
> >
> > --
> >
> > Sergei
>
> -1
>
> I think this should be handled by the packages, not at the eclass
> level.
>
> https://bugs.gentoo.org/show_bug.cgi?id=426262#c3
>
> The packages should either mv the configure.in to configure.ac
> internally, or better yet, the maintainers should ask upstream for
> their
> packages to fix it.
+1, otherwise we will never be able to add/unmask a newer autoconf that
doesn't look at configure.in anymore, once such a version eventually
happens.
Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac
On Sat, Jun 10, 2017 at 01:04:06PM +0100, Sergei Trofimovich wrote:
> On Sat, 10 Jun 2017 13:28:19 +0200
> Jeroen Roovers wrote:
>
> > https://bugs.gentoo.org/show_bug.cgi?id=426262
>
> > + mv configure.{in,ac} || die
>
> Looks good.
>
> --
>
> Sergei
-1
I think this should be handled by the packages, not at the eclass level.
https://bugs.gentoo.org/show_bug.cgi?id=426262#c3
The packages should either mv the configure.in to configure.ac
internally, or better yet, the maintainers should ask upstream for their
packages to fix it.
Thanks,
William
signature.asc
Description: Digital signature
