Re: [gentoo-user] Re: Rubygems and Rake problem

[Bertram Scharpf]

Hi,

On Thursday, 28. Jan 2021, 06:52:37 +0100, Hans de Graaff wrote:
> On Wed, 27 Jan 2021 19:13:37 +0100, Bertram Scharpf wrote:
> 
> > after a long period with a lot of problems installing Ruby Gems and
> > Gentoo packages containing Ruby Gems, I found the following solution: I
> > added a line
> > 
> > s.executables = ["rake".freeze]
>  
> > What do you think? Maybe someone likes to confirm this.
> > I will definitely not file any report or patch to neither the RubyGems
> > nor the Rake project any more.
> 
> Could you file a but about this at https://bugs.gentoo.org/ including an 
> example of the problem this is causing for you? As far as I'm aware this 
> is not a known issue.

I tried to reproduce the problem, but the Gem installer
immediately updates the Rake gem so that the messy gem
specification of the old version will no longer be accessed.
I suppose the error only surfaces in times when the Rake
package is the newest version.

Nevertheless, the missing executable specification line
definitely is a bug, probably on the RubyGems side, not in
Gentoo Portage.

Again, and I can’t stress this enough, I'm tired of
searching for bugs in these lousy written tools RubyGems and
Rake. I will not make any effort to report any bugs there
any more and I do not want to be responsible for anything
these tools do.

Bertram


-- 
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-scharpf.de

Re: [gentoo-user] Nodejs overlay

[Aisha Tammy]

I agree with all of mjo's points below.

Nodejs is so bad that I don't think its worth investing
your effort into it. There is really very little hope
of fixing their crap. This is a case of its not
you, its them.

But if you do manage to get some sanity into this craziness
I might just try nodejs someday <3

Best of luck,
Aisha

On 1/31/21 7:20 PM, Michael Orlitzky wrote:
> On Sun, 2021-01-31 at 18:42 -0500, Andrew Udvare wrote:
>>
>> Our best option is to treat Nodejs stuff the way we treat Rust and Go
>> packages. Pretend Nodejs 'binaries' are 'built' statically and
>> therefore, grab all the dependencies in the main package ebuild.
> 
> The only thing a package manager does for you is that it allows one
> person (the Gentoo developer, in this case) to invest a little bit of
> time to save everyone else (the Gentoo users) a lot of time. When
> software has been packaged correctly, it integrates well with the rest
> of the system, gets constant maintenance and security updates, and can
> be managed from a central location in a consistent manner.
> 
> "Packaging" software like you describe isn't packaging it in this
> sense. When you bundle everything together,
> 
>   1. Nothing is shared between packages so build time and disk 
>  usage skyrockets.
> 
>   2. The number of updates and thus the amount of work required
>
>  also skyrockets, for the same reason: when nothing is shared, you 
>
>  have to update each package whenever a dependency of a dependency 
>
>  of a dependency... changes.
> 
>   3. There are no security updates, ever. If you use anything written 
>  in Rust or Go on Gentoo, or if you use anything that uses 
>  anything written in Rust or Go, or. it will NEVER get a 
>  security update. No one even bothers looking for security
>  issues in these languages because the "find a bug then fix it"
>  algorithm is infeasible.
> 
>   4. You do get to do updates with e.g. "emerge -puDN @world", but not 
>  really, because no one is actually updating Gentoo packages every 
>  time a dependency of a dependency changes.
> 
> So ultimately, there's little benefit and it introduces security
> vulnerabilities to our users who might be better off just using NPM or
> whatever (or using software written in a sane language).
> 
> 
> 

Re: [gentoo-user] Nodejs overlay

[Aisha Tammy]

On 1/31/21 8:49 AM, Alessandro Barbieri wrote:
> I'm trying to package nodejs software and I made an overlay for it here
> https://github.com/Alessandro-Barbieri/node-overlay 
> 
> Could you try it and send feedback?


I have to confess, I don't like nodejs a lot.
But don't node packages have a very strict version dependency?
Does this handle version conflicts?

X needs >=A-1.2 and <=A-1.3
Y needs >=A-1.5

How would this be solved here? Isn't it for this reason that
package installs are to a local folder for each application?

I don't know if going to global installs is the best idea.
But I'm willing to be enlightened and proven wrong :)

Best,
Aisha

Re: [gentoo-user] Nodejs overlay

[Michael Orlitzky]

On Sun, 2021-01-31 at 18:42 -0500, Andrew Udvare wrote:
> 
> Our best option is to treat Nodejs stuff the way we treat Rust and Go
> packages. Pretend Nodejs 'binaries' are 'built' statically and
> therefore, grab all the dependencies in the main package ebuild.

The only thing a package manager does for you is that it allows one
person (the Gentoo developer, in this case) to invest a little bit of
time to save everyone else (the Gentoo users) a lot of time. When
software has been packaged correctly, it integrates well with the rest
of the system, gets constant maintenance and security updates, and can
be managed from a central location in a consistent manner.

"Packaging" software like you describe isn't packaging it in this
sense. When you bundle everything together,

  1. Nothing is shared between packages so build time and disk 
 usage skyrockets.

  2. The number of updates and thus the amount of work required
   
 also skyrockets, for the same reason: when nothing is shared, you 
   
 have to update each package whenever a dependency of a dependency 
   
 of a dependency... changes.

  3. There are no security updates, ever. If you use anything written 
 in Rust or Go on Gentoo, or if you use anything that uses 
 anything written in Rust or Go, or. it will NEVER get a 
 security update. No one even bothers looking for security
 issues in these languages because the "find a bug then fix it"
 algorithm is infeasible.

  4. You do get to do updates with e.g. "emerge -puDN @world", but not 
 really, because no one is actually updating Gentoo packages every 
 time a dependency of a dependency changes.

So ultimately, there's little benefit and it introduces security
vulnerabilities to our users who might be better off just using NPM or
whatever (or using software written in a sane language).

Re: [gentoo-user] Nodejs overlay

[Andrew Udvare]

> On 2021-01-31, at 18:17, Aisha Tammy  wrote:
> 
> On 1/31/21 8:49 AM, Alessandro Barbieri wrote:
>> I'm trying to package nodejs software and I made an overlay for it here
>> https://github.com/Alessandro-Barbieri/node-overlay 
>> 
>> Could you try it and send feedback?
> 
> 
> I have to confess, I don't like nodejs a lot.
> But don't node packages have a very strict version dependency?
> Does this handle version conflicts?
> 
> X needs >=A-1.2 and <=A-1.3
> Y needs >=A-1.5
> 
> How would this be solved here? Isn't it for this reason that
> package installs are to a local folder for each application?

It can't be done in a sane way. Nodejs, because of their unwillingness to solve 
dependency issues and allowing insane amounts of tiny packages to exist (blame 
the community), allow insane dependency trees that make it impossible to put it 
on top of a normal package manager.

Even if we did find packages that don't have these conflicts, having Portage 
manage thousands of packages just for a single thing like eslint seems like a 
very bad idea.

Our best option is to treat Nodejs stuff the way we treat Rust and Go packages. 
Pretend Nodejs 'binaries' are 'built' statically and therefore, grab all the 
dependencies in the main package ebuild. One example is this overlay's vscode 
ebuild: 
https://data.gpo.zugaina.org/pf4public/app-editors/vscode/vscode-1.52.1.ebuild

The process of generating the SRC_URI can be automated. Eclasses could be 
written for to help with the phases, especially src_unpack and src_prepare.

[gentoo-user] followup

[Alan Grimes]

turns out my problem was profoundly simple, I hadn't updated my portage
mirror list in either of the past two geological ages...  (it should
have reported "WAITING ON FETCH" in the emerge update, that would have
saved me about 2 days figuring that out...)

Mirrorselect actually worked. =O

Perl cleaner or whatever it's called solved the rest... Actually just
turning on yet more verbosity allowed me to manually clean everything
out in a reasonable amount of time... My make.conf is starting to look
like a litany of verbosity enables.


-- 
The vaccine is a LIE. 
#EggCrisis 
White is the new Kulak.
Powers are not rights.

Re: [gentoo-user] Blank screen when re-logged IN

[Frank Steinmetzger]

Am Fri, Jan 29, 2021 at 10:49:50AM -0700 schrieb the...@sys-concept.com:
> I have a recent Gentoo installation and I'm experiencing strange behaviour.  
> I don't know if it has something to do with the hardware (video card) or 
> software issue.
> Video card is:  GeForce GTX 1050
> I'm using "nvidia" video driver. 
> 
> Sometimes when I log-out and try to log-in back, all I get is black screen 
> with mouse cursor pointer showing but the screen is black, nothing is 
> displaying.
> How to trouble shoot it? 
> It only happens when I "log-out" and try to "log-in" back.
> 
> The only thing I can do is to ssh from another terminal and "reboot" the PC.  

I find that if I log out and back in too quickly, KDE does not load up
correctly either (though KDE is probably another beast compared to XFCE).

I noticed that KDE takes a while after logout to end all processes that were
associated with the session. Stuff like pulse and other daemons. So just out
of curiosity: before you log out of XFCE, log in remotely as root, open htop
and filter for your normal user (or use any other method of choice to show
processes owned by your user).
Now log out of XFCE. After a while, the filtered list in htop should be
empty (unless you set up some other background stuff that is independent
from any graphical session).

-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

Light travels faster than sound.
This is why some people appear bright until you hear them speak.


signature.asc
Description: PGP signature

Re: [gentoo-user] followup

[Rich Freeman]

On Sun, Jan 31, 2021 at 2:12 PM Neil Bothwick  wrote:
>
> On Sun, 31 Jan 2021 13:52:32 -0500, Alan Grimes wrote:
>
> > turns out my problem was profoundly simple, I hadn't updated my portage
> > mirror list in either of the past two geological ages...  (it should
> > have reported "WAITING ON FETCH" in the emerge update, that would have
> > saved me about 2 days figuring that out...)
> >
> > Mirrorselect actually worked. =O
> >
> > Perl cleaner or whatever it's called solved the rest... Actually just
> > turning on yet more verbosity allowed me to manually clean everything
> > out in a reasonable amount of time... My make.conf is starting to look
> > like a litany of verbosity enables.
>
> I take it the is the closest anyone can expect to an apology for the
> torrent of abuse in your previous email?

Simple solution for that stuff is to just kill the thread.

If you want help, then use an informative subject line and just
explain what is going wrong.  When you post hysterical subject lines
and it just goes downhill from there I don't even bother reading the
messages.  Nobody wants to see you suffer, but nobody around here is
obligated to help either, so at least try to be nice about it...

-- 
Rich

Re: [gentoo-user] news 2021-01-30-display-manager-init -- blocked package

[Rich Freeman]

On Sat, Jan 30, 2021 at 11:01 PM Kusoneko  wrote:
>
> It states that starting the next xorg-server version, ...
>
> ... Doing the required update is currently impossible.
>
> I am definitely not gonna remember about this
> in a week or 2 so I'd like to deal with whatever
> this issue is asap. Is there any way to do this?

You hit on the issue.  You can either wait and not have to mess with
much, or you can force things using keywords as Jacques suggested, and
then if you want to go back to stable do more work later to transition
back.

Personally I'd just treat this as a heads-up and when you see the
xorg-server update down the road you know to not install it until
you're ready to do the other work.

-- 
Rich

Re: [gentoo-user] news 2021-01-30-display-manager-init -- blocked package

[Neil Bothwick]

On Sun, 31 Jan 2021 14:12:44 -0500, Kusoneko wrote:

> Thanks Jacques, your solution worked perfectly.
> 
> Thanks for attempting to help Neil, however
> I did mention that I wished to deal with it
> asap rather than postpone it by unreading
> the news as I'll inevitably end up reading it
> again eventually and re-attempting it and
> face the same issue. Having it done and dealt
> with like this is easier for me.

I understand, which is why I suggested using the -r1 version, which is
what you ended up doing.

Timing of the news announcements can be tricky, a compromise between not
announcing too early and not leaving it until the last minute. In this
case, it should really have included the steps necessary to implement the
change now, as has been done with other news items.


-- 
Neil Bothwick

Is that "woof" feed me; "woof" walk me; "woof" there's a burglar? What??


pgpAr8qWicVOu.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] news 2021-01-30-display-manager-init -- blocked package

[Kusoneko]

On Sun, Jan 31, 2021 at 03:56:48PM +0100, Jacques Montier wrote:
> Le dim. 31 janv. 2021 à 11:45, Neil Bothwick  a écrit :
> 
> > On Sat, 30 Jan 2021 23:01:42 -0500, Kusoneko wrote:
> >
> > > Following my daily syncing today, 2 news items appeared,
> > > the important one for this being the following:
> > >
> > > 2021-01-30-display-manager-init
> > >
> > > It states that starting the next xorg-server version,
> > > the xdm init script will be removed and that one
> > > install gui-libs/display-manager-init to replace it.
> > > Following the instructions to install said package
> > > leads to a wonderful error stating that the package
> > > is blocked by the following packages:
> > >
> > > x11-apps/xinit-1.4.1
> > > sys-apps/sysvinit-2.98
> > > x11-base/xorg-server-1.20.10
> > >
> > > Removing xorg-server is not gonna happen, so
> > > looking at what emerge says, there's a bit of an
> > > issue here:
> > >
> > > https://zifb.in/GUtgto4VcX
> > >
> > > Doing the required update is currently impossible.
> > >
> > > I am definitely not gonna remember about this
> > > in a week or 2 so I'd like to deal with whatever
> > > this issue is asap. Is there any way to do this?
> >
> > You could use eselect to mark the news unread.To get
> >
> > You cannot use display-manager-init with the current stable xorg-server,
> > because of this depend
> >
> > !<=x11-base/xorg-server-1.20.10
> >
> > However, you can use it with the -r1 version, which is currently ~arch.
> > The differences between the ebuilds relate to the init handling, they
> > install the same server code, so you have two choices: add -r1 to
> > package.accept_keywords or wait a couple of weeks and hope you remember.
> >
> > The worst that is likely to happen is you forget and boot to a console
> > one day, at which point you will almost certainly remember :)
> >
> >
> > --
> > Neil Bothwick
> >
> > Normal people believe that if it ain't broke, don't fix it. Engineers
> > believe that if it ain't broke, it doesn't have enough features yet."
> >
> 
> 
> 
> Hello all,
> 
> To get display-manager-init built and installed, i had to accept_keywords :
> xinit, sysvinit and xorg-server.
> As  specified in the news :
> - changing the DISPLAYMANAGER variable in /etc/conf.d/display-manager
> (lightdm for me)
> - rc-update del xdm default
> - rc-update add display-manager
> - reboot
> 
> Everything works fine.
> 
> Cheers,
> 
> Jacques

Thanks Jacques, your solution worked perfectly.

Thanks for attempting to help Neil, however
I did mention that I wished to deal with it
asap rather than postpone it by unreading
the news as I'll inevitably end up reading it
again eventually and re-attempting it and
face the same issue. Having it done and dealt
with like this is easier for me.

Kusoneko.


signature.asc
Description: PGP signature

Re: [gentoo-user] followup

[Neil Bothwick]

On Sun, 31 Jan 2021 13:52:32 -0500, Alan Grimes wrote:

> turns out my problem was profoundly simple, I hadn't updated my portage
> mirror list in either of the past two geological ages...  (it should
> have reported "WAITING ON FETCH" in the emerge update, that would have
> saved me about 2 days figuring that out...)
> 
> Mirrorselect actually worked. =O
> 
> Perl cleaner or whatever it's called solved the rest... Actually just
> turning on yet more verbosity allowed me to manually clean everything
> out in a reasonable amount of time... My make.conf is starting to look
> like a litany of verbosity enables.

I take it the is the closest anyone can expect to an apology for the
torrent of abuse in your previous email?


-- 
Neil Bothwick

I believe the technical term is "Oops!"


pgplOp08FC1tV.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] app-crypt/pinentry - major rework: "/usr/bin/pinentry-gtk-2" missing [RESOLVED]

[Ramon Fischer]

Thanks!

The USE flag "gtk" for the package "app-crypt/gcr" was missing.

After following your instructions, it is working again using 
"/usr/bin/pinentry-gnome3":


   $ < /etc/portage/package.use/pinentry
   app-crypt/pinentry gtk
   app-crypt/gcr gtk
   $ emerge --ask --changed-use gcr
   $ emerge --ask pinentry
   $ ls -l /usr/bin/pinentry-gnome3
   -rwxr-xr-x 1 root root 81520 Jan 31 17:21 /usr/bin/pinentry-gnome3
   $ eselect pinentry list
   Available pinentry binary implementations:
  [1] pinentry-gnome3
  [2] pinentry-curses *
  [3] pinentry-tty
   $ eselect pinentry set 1
   $ eselect pinentry list
   Available pinentry binary implementations:
  [1]   pinentry-gnome3 *
  [2]   pinentry-curses
  [3]   pinentry-tty

From the issue ticket:

Therefore I propose that if app-crypt/pinentry uses +gtk, there should be a 
dependency for app-crypt/gcr +gtk

I totally agree with this.


See 
    This module is heading towards planned deprecation.
    It will continue to be supported and API/ABI stable throughout the 
GNOME 2.x series,
    but we do not recommend using it in new applications unless you 
require

    functionality that has not already been moved elsewhere.

It have been un-recommended for a long time.

Thanks for the clarification!

-Ramon

On 31/01/2021 13:43, Wynn Wolf Arbor wrote:

On 2021-01-31 13:03, Ramon Fischer wrote:

The USE flag "gtk" was not removed:

-IUSE="caps emacs gnome-keyring fltk gtk ncurses qt5"
+IUSE="caps emacs gnome-keyring gtk ncurses qt5"

Since when is this obsolete and is there any alternative?

I cannot comment directly on the obsolescence of pinentry-gtk2 (most
certainly a decision upstream), but the alternative is pinentry-gnome3.

The gtk flag was not removed because it now configures pinentry-gnome3
instead of -gtk2. You should be able to select that using 'eselect
pinentry', but because of [1] you'll have to enable the gtk flag for
app-crypt/gcr first and then rebuild app-crypt/pinentry.

[1] https://bugs.gentoo.org/show_bug.cgi?id=767424



--
GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF




OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-user] news 2021-01-30-display-manager-init -- blocked package

[Jacques Montier]

Le dim. 31 janv. 2021 à 11:45, Neil Bothwick  a écrit :

> On Sat, 30 Jan 2021 23:01:42 -0500, Kusoneko wrote:
>
> > Following my daily syncing today, 2 news items appeared,
> > the important one for this being the following:
> >
> > 2021-01-30-display-manager-init
> >
> > It states that starting the next xorg-server version,
> > the xdm init script will be removed and that one
> > install gui-libs/display-manager-init to replace it.
> > Following the instructions to install said package
> > leads to a wonderful error stating that the package
> > is blocked by the following packages:
> >
> > x11-apps/xinit-1.4.1
> > sys-apps/sysvinit-2.98
> > x11-base/xorg-server-1.20.10
> >
> > Removing xorg-server is not gonna happen, so
> > looking at what emerge says, there's a bit of an
> > issue here:
> >
> > https://zifb.in/GUtgto4VcX
> >
> > Doing the required update is currently impossible.
> >
> > I am definitely not gonna remember about this
> > in a week or 2 so I'd like to deal with whatever
> > this issue is asap. Is there any way to do this?
>
> You could use eselect to mark the news unread.To get
>
> You cannot use display-manager-init with the current stable xorg-server,
> because of this depend
>
> !<=x11-base/xorg-server-1.20.10
>
> However, you can use it with the -r1 version, which is currently ~arch.
> The differences between the ebuilds relate to the init handling, they
> install the same server code, so you have two choices: add -r1 to
> package.accept_keywords or wait a couple of weeks and hope you remember.
>
> The worst that is likely to happen is you forget and boot to a console
> one day, at which point you will almost certainly remember :)
>
>
> --
> Neil Bothwick
>
> Normal people believe that if it ain't broke, don't fix it. Engineers
> believe that if it ain't broke, it doesn't have enough features yet."
>



Hello all,

To get display-manager-init built and installed, i had to accept_keywords :
xinit, sysvinit and xorg-server.
As  specified in the news :
- changing the DISPLAYMANAGER variable in /etc/conf.d/display-manager
(lightdm for me)
- rc-update del xdm default
- rc-update add display-manager
- reboot

Everything works fine.

Cheers,

Jacques

Re: [gentoo-user] State of emergency is now in effect.

[Alessandro Barbieri]

Il Sab 30 Gen 2021, 10:40 Alan Grimes  ha scritto:

>
>  * Error: circular dependencies:
>
> (dev-java/openjdk-11.0.9_p11:11/11::gentoo, ebuild scheduled for merge)
> depends on
>  (dev-java/openjdk-11.0.9_p11:11/11::gentoo, ebuild scheduled for merge)
> (buildtime)
>
>  * Note that circular dependencies can often be avoided by temporarily
>  * disabling USE flags that trigger optional dependencies.
>

You nee to install openjdk-bin to solve this issue

>

[gentoo-user] Nodejs overlay

[Alessandro Barbieri]

I'm trying to package nodejs software and I made an overlay for it here
https://github.com/Alessandro-Barbieri/node-overlay
Could you try it and send feedback?

Re: [gentoo-user] app-crypt/pinentry - major rework: "/usr/bin/pinentry-gtk-2" missing

[bobwxc]

在 2021/1/31 下午8:43, Wynn Wolf Arbor 写道:

On 2021-01-31 13:03, Ramon Fischer wrote:

The USE flag "gtk" was not removed:

-IUSE="caps emacs gnome-keyring fltk gtk ncurses qt5"
+IUSE="caps emacs gnome-keyring gtk ncurses qt5"

Since when is this obsolete and is there any alternative?

I cannot comment directly on the obsolescence of pinentry-gtk2 (most
certainly a decision upstream), but the alternative is pinentry-gnome3.

The gtk flag was not removed because it now configures pinentry-gnome3
instead of -gtk2. You should be able to select that using 'eselect
pinentry', but because of [1] you'll have to enable the gtk flag for
app-crypt/gcr first and then rebuild app-crypt/pinentry.

[1] https://bugs.gentoo.org/show_bug.cgi?id=767424


See 
    This module is heading towards planned deprecation.
    It will continue to be supported and API/ABI stable throughout the 
GNOME 2.x series,
    but we do not recommend using it in new applications unless you 
require

    functionality that has not already been moved elsewhere.

It have been un-recommended for a long time.

--
bobwxc
F645 5C7A 08E8 A637 24C6  D59E 36E9 4EAB B53E 516B




OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-user] news 2021-01-30-display-manager-init -- blocked package

[Aisha Tammy]

On 1/30/21 11:01 PM, Kusoneko wrote:
> 
> Following my daily syncing today, 2 news items appeared,
> the important one for this being the following:
> 
> 2021-01-30-display-manager-init
> 
> It states that starting the next xorg-server version,
> the xdm init script will be removed and that one
> install gui-libs/display-manager-init to replace it.
> Following the instructions to install said package
> leads to a wonderful error stating that the package
> is blocked by the following packages:
> 
> x11-apps/xinit-1.4.1
> sys-apps/sysvinit-2.98
> x11-base/xorg-server-1.20.10
> 
> Removing xorg-server is not gonna happen, so
> looking at what emerge says, there's a bit of an
> issue here:
> 
> https://zifb.in/GUtgto4VcX
> 
> Doing the required update is currently impossible.
> 
> I am definitely not gonna remember about this
> in a week or 2 so I'd like to deal with whatever
> this issue is asap. Is there any way to do this?
> 
> Note: all 3 of the blocking packages and whatever
> pulls them in are NOT using the ~amd64 keyword
> at the moment, except for nvidia-drivers.
> 

Yes, they are currently ~ARCH, you have to use
the ~amd64 keywords right now.

Aisha

> Thanks for any help,
> Kusoneko.
> 

Re: [gentoo-user] app-crypt/pinentry - major rework: "/usr/bin/pinentry-gtk-2" missing

[Wynn Wolf Arbor]

On 2021-01-31 13:03, Ramon Fischer wrote:
> The USE flag "gtk" was not removed:
> 
>-IUSE="caps emacs gnome-keyring fltk gtk ncurses qt5"
>+IUSE="caps emacs gnome-keyring gtk ncurses qt5"
> 
> Since when is this obsolete and is there any alternative?

I cannot comment directly on the obsolescence of pinentry-gtk2 (most
certainly a decision upstream), but the alternative is pinentry-gnome3.

The gtk flag was not removed because it now configures pinentry-gnome3
instead of -gtk2. You should be able to select that using 'eselect
pinentry', but because of [1] you'll have to enable the gtk flag for
app-crypt/gcr first and then rebuild app-crypt/pinentry.

[1] https://bugs.gentoo.org/show_bug.cgi?id=767424

-- 
Wolf

[gentoo-user] app-crypt/pinentry - major rework: "/usr/bin/pinentry-gtk-2" missing

[Ramon Fischer]

Hello list,

I recently updated "app-crypt/pinentry" and suddenly 
"/usr/bin/pinentry-gtk-2" was missing.


I am using "pinentry-gtk-2", so I can enter the passphrase for my GPG 
private key, when using the browser extension "Gopass Bridge".


Taking a look at the commit of the package[1], it states:

   [...]
   -disable gtk2 (obsolete)
   [...]

   @@ -58,16 +57,15 @@ src_configure() {
        econf \
        [...]
        --disable-pinentry-gtk2 \
        [...]

The USE flag "gtk" was not removed:

   -IUSE="caps emacs gnome-keyring fltk gtk ncurses qt5"
   +IUSE="caps emacs gnome-keyring gtk ncurses qt5"

Since when is this obsolete and is there any alternative?

-Ramon

[1] 
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=acad5327d6e44f7f4b2dd8a5eb6a563a1297aac3


--
GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF




OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-user] news 2021-01-30-display-manager-init -- blocked package

[Neil Bothwick]

On Sat, 30 Jan 2021 23:01:42 -0500, Kusoneko wrote:

> Following my daily syncing today, 2 news items appeared,
> the important one for this being the following:
> 
> 2021-01-30-display-manager-init
> 
> It states that starting the next xorg-server version,
> the xdm init script will be removed and that one
> install gui-libs/display-manager-init to replace it.
> Following the instructions to install said package
> leads to a wonderful error stating that the package
> is blocked by the following packages:
> 
> x11-apps/xinit-1.4.1
> sys-apps/sysvinit-2.98
> x11-base/xorg-server-1.20.10
> 
> Removing xorg-server is not gonna happen, so
> looking at what emerge says, there's a bit of an
> issue here:
> 
> https://zifb.in/GUtgto4VcX
> 
> Doing the required update is currently impossible.
> 
> I am definitely not gonna remember about this
> in a week or 2 so I'd like to deal with whatever
> this issue is asap. Is there any way to do this?

You could use eselect to mark the news unread.

You cannot use display-manager-init with the current stable xorg-server,
because of this depend

!<=x11-base/xorg-server-1.20.10

However, you can use it with the -r1 version, which is currently ~arch.
The differences between the ebuilds relate to the init handling, they
install the same server code, so you have two choices: add -r1 to
package.accept_keywords or wait a couple of weeks and hope you remember.

The worst that is likely to happen is you forget and boot to a console
one day, at which point you will almost certainly remember :)


-- 
Neil Bothwick

Normal people believe that if it ain't broke, don't fix it. Engineers
believe that if it ain't broke, it doesn't have enough features yet."


pgp9TXquye6ae.pgp
Description: OpenPGP digital signature