Statically linking X libraries into your program is an extremely bad
idea.
Signed-off-by: Matt Turner
---
eclass/xorg-2.eclass | 23 +--
1 file changed, 1 insertion(+), 22 deletions(-)
diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
index f3b282e1a11..f9a18b8ec26 10
Statically linking X libraries into your program is an extremely bad
idea.
Signed-off-by: Matt Turner
---
eclass/xorg-3.eclass | 22 --
1 file changed, 22 deletions(-)
diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
index ece4d97b433..399fc8661f4 100644
--- a/eclass
In some setups where users are changed/managed not only via ebuilds,
for example through configuration management systems, it could be
problematic if acct-user.eclass will restore user/group settings
to values set in ebuild.
Setting ACCT_USER_NO_MODIFY to a non-zero value will allow system
adminis
On Fri, 2021-01-08 at 22:05 +0100, Thomas Deutschmann wrote:
> On 2021-01-08 21:58, Michał Górny wrote:
> > > +# @ECLASS-VARIABLE: ACCT_USER_ALREADY_EXISTS
> > > +# @INTERNAL
> > > +# @DESCRIPTION:
> > > +# Status variable which indicates if user already exists.
> >
> > Please prefix internal vari
On 2021-01-08 21:58, Michał Górny wrote:
+# @ECLASS-VARIABLE: ACCT_USER_ALREADY_EXISTS
+# @INTERNAL
+# @DESCRIPTION:
+# Status variable which indicates if user already exists.
Please prefix internal variables with an underscore.
You mean renaming ACCT_USER_ALREADY_EXISTS to _ACCT_USER_ALREADY
On Fri, 2021-01-08 at 21:19 +0100, Thomas Deutschmann wrote:
> In some setups where users are changed/managed not only via ebuilds,
> for example through configuration management systems, it could be
> problematic if acct-user.eclass will restore user/group settings
> to values set in ebuild.
>
>
Am Freitag, 8. Januar 2021, 14:26:32 EET schrieb Joonas Niilola:
> # Now my question is, does anyone find any of these packages useful?
> Should we go ahead and last-rite them, since it doesn't seem useful to
> carry these in Gentoo? The ones broken are heading towards last-riting
> nevertheless.
In some setups where users are changed/managed not only via ebuilds,
for example through configuration management systems, it could be
problematic if acct-user.eclass will restore user/group settings
to values set in ebuild.
Setting ACCT_USER_NO_MODIFY to a non-zero value will allow system
adminis
Hi,
Here is a forum thread that I started for this topic:
https://forums.gentoo.org/viewtopic-p-8557255.html#8557255
--
Best regards,
Alex
On Fri, Jan 8, 2021 at 1:31 PM Michał Górny wrote:
> Again, I don't understand why you continue escalating this. I have
> already indicated that I'm fine with adding an option to disable this,
> given that 1) the current behavior remains the default, and 2) people
> are given big fat warning that
On Thu, Jan 7, 2021 at 3:42 AM Mart Raudsepp wrote:
> Ühel kenal päeval, K, 06.01.2021 kell 19:27, kirjutas Matt Turner:
> > From: David Michael
> > The vala dependencies are declared in BDEPEND since EAPI 7 so that
> > the valac command is natively executable. With no arguments, the
> > has_ver
On Fri, 2021-01-08 at 19:23 +0100, Thomas Deutschmann wrote:
> On 2021-01-08 19:14, Michał Górny wrote:
> > The one floppym suggested, i.e. the same as sent patch but with
> > the default staying on the current behavior.
>
> Do I understand correctly? You are willing to accept my patch but with
>
On Fri, 2021-01-08 at 19:10 +0100, Thomas Deutschmann wrote:
> On 2021-01-08 18:06, Mike Gilbert wrote:
> > I disagree with your premise: I argue that the eclass is not "broken",
> > and the code works as designed. You just don't like aspects of its
> > design.
>
> Several people, not just me... *
On 2021-01-08 19:14, Michał Górny wrote:
The one floppym suggested, i.e. the same as sent patch but with
the default staying on the current behavior.
Do I understand correctly? You are willing to accept my patch but with
> ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED
defaulting to a non-zero
On Fri, 2021-01-08 at 19:11 +0100, Fabian Groffen wrote:
> On 04-01-2021 17:14:47 +0100, Michał Górny wrote:
> > Yes, I don't mind an option, as long as it spews a big fat ewarn that
> > the user loses the right to support. However, that's still not
> > the right solution to the immediate problem,
On 04-01-2021 17:14:47 +0100, Michał Górny wrote:
> Yes, I don't mind an option, as long as it spews a big fat ewarn that
> the user loses the right to support. However, that's still not
> the right solution to the immediate problem, and I'm currently working
> on a better patch, so I'd prefer if
On 2021-01-08 18:06, Mike Gilbert wrote:
I disagree with your premise: I argue that the eclass is not "broken",
and the code works as designed. You just don't like aspects of its
design.
Several people, not just me... *users*, other devs like robbat2 and
antarus, all with experience in maintai
On Freitag, 8. Januar 2021 13:26:32 CET Joonas Niilola wrote:
> # So the final list of "useless" libs is:
> dev-libs/atcore
This has IUSE="gui", EAPI=7 and kde proj as maintainer. Please keep.
Regards
signature.asc
Description: This is a digitally signed message part.
On 1/8/21 5:42 PM, Thomas Deutschmann wrote:
> Hi,
>
> I wonder how you composed this list. If you just checked if there is
> any revdep, the check was probably useless:
>
> For example,
>
>> dev-libs/cyberjack
>
> is up-to-date, has an active dev as maintainer and is required for any
> ReinerSCT
On Fri, 2021-01-08 at 17:29 +0100, Thomas Deutschmann wrote:
> On 2021-01-08 17:03, Mike Gilbert wrote:
> > I strongly object to you pushing this patch as-is. There have been
> > plenty of non-technical objections, including from the eclass
> > maintainer.
>
> The eclass maintainer has disqualifie
On Fri, Jan 8, 2021 at 11:29 AM Thomas Deutschmann wrote:
> This is a technical mailing list. Currently, acct-* stuff is breaking
> stuff. Nobody has challenged this yet.
>
> Now I proposed a way how to unbreak stuff.
>
> Please tell me why we should keep broken stuff for non-technical reason
> an
On Fri, Jan 8, 2021 at 7:27 AM Joonas Niilola wrote:
> dev-libs/clhpp
We want to keep this, though I admit I don't recall why nothing depends on it.
On Fri, Jan 8, 2021 at 11:29 AM Thomas Deutschmann wrote:
>
> On 2021-01-08 17:03, Mike Gilbert wrote:
> > I strongly object to you pushing this patch as-is. There have been
> > plenty of non-technical objections, including from the eclass
> > maintainer.
>
> The eclass maintainer has disqualified
Hi,
please forget my previous mail. I was informed that I misread your mail,
sorry about that!
--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
OpenPGP_signature
Description: OpenPGP digital signature
On 2021-01-08 17:03, Mike Gilbert wrote:
I strongly object to you pushing this patch as-is. There have been
plenty of non-technical objections, including from the eclass
maintainer.
The eclass maintainer has disqualified himself going into a technical
debate with saying
So, over my dead com
On Fri, Jan 8, 2021 at 10:48 AM Thomas Deutschmann wrote:
>
> Hi,
>
> since nobody posted any technical objections, I am going to push the
> proposed patch on Saturday to address the current issue and allow any
> professional Gentoo user relying on usermod/configuration management
> tool to move o
Hi,
since nobody posted any technical objections, I am going to push the
proposed patch on Saturday to address the current issue and allow any
professional Gentoo user relying on usermod/configuration management
tool to move on.
If someone will spend time on further improvements like impleme
Hi,
I wonder how you composed this list. If you just checked if there is any
revdep, the check was probably useless:
For example,
dev-libs/cyberjack
is up-to-date, has an active dev as maintainer and is required for any
ReinerSCT chipcard reader.
--
Regards,
Thomas Deutschmann / Gentoo
Hi,
On 2021/01/08 15:39, Andreas Sturmlechner wrote:
> On Freitag, 8. Januar 2021 08:10:05 CET Jaco Kroon wrote:
>> Would it be possible to point at alternatives? pm-utils worked well for
>> me until now, and I'm fairly certain this won't be abandoned unless
>> there are other (better?) alternati
On Freitag, 8. Januar 2021 08:10:05 CET Jaco Kroon wrote:
> Would it be possible to point at alternatives? pm-utils worked well for
> me until now, and I'm fairly certain this won't be abandoned unless
> there are other (better?) alternatives available.
>
It is replaced by elogind or systemd bui
On Fri, 8 Jan 2021 14:26:32 +0200
Joonas Niilola wrote:
> dev-libs/libgcrypt-compat
> dev-libs/libpcre-debian
These are maintained by me and I'd like to keep them. They can be
pulled in by running the esteam tool in steam-overlay for games that
need them. They could potentially be used for other
# With the help of jkroon I went through all dev-libs/* and media-libs/*
packages and located each one without reverse deps,
# List of dev-libs/* and media-libs/* without any revdeps:
dev-libs/atcore
dev-libs/bcm2835
dev-libs/bemenu
dev-libs/bitset
dev-libs/boost-mpl-cartesian_product
dev-libs/cali
32 matches
Mail list logo
