Re: [gentoo-user] Re: replacement for ftp?

[Kent Fredric]

On Tue, 16 May 2017 04:58:44 +0200
Kai Krakow  wrote:

> If this is the underlying (and perfectly legitimate) problem, you need
> to deploy a solution that's most easy for your users and not for you.
> That may involve a custom transfer solution where they simply can drop
> files to. The underlying technology is then up to you: Use what is
> appropriate.

If users have difficulty with keyboard/mouse, but you find a client
that's to their liking, but they're not necessarily capable of
configuring for your service, it might be possible to find a "config
file" for that client which they can fetch over plain ol' http:// with
whatever tools they usually use for downloading http:// things.

If the program they use doesn't have a "launcher config thinger" but
can be imagined to use whatever transfer technology you choose ( ssh ),
and you don't fancy writing a dedicated client, it could be simpler to
write an installer for them, which configures their existing client for
your service.

But I'd imagine lots of confusion is emanating from this list due to
the requirements not being entirely clear/obvious.


pgptIKpyxTiAF.pgp
Description: OpenPGP digital signature

[gentoo-user] Re: Wow, the GTK3 file browser is awful!

[Grant Edwards]

On 2017-05-22, Mick  wrote:
> On Monday 22 May 2017 18:33:47 Grant Edwards wrote:
>> Having just recently allowed Firefox to upgrade from 45 to 52, I'm now
>> hobbled with the GTK3 file browser dialog.
>> 
>> It's horrible.
>> 
>> First of all, it's freaking _huge_!  It wastes acres of display
>> real-estate.  It was obviously designed by a megalomaniac who thinks
>> your computer belongs to him, and that while his filebrowser code is
>> running, nothing else must be visible.
>
> Hmm ... I haven't noticed this here.

Interesting.  It seems to open using the same size it was last time it
was closed.  I'm not sure why somebody thinks that's a good idea,
either.

>> I used to be able to just start typing a path.  Now, that triggeres
>> some bizzarre "search" feature that shows a spinner for a minutes at a
>> time shows a long list of files I don't care about.
>
> You can go to Edit/Preferences/Advanced and deselect 'Search for text when I 
> start typing'

That's something different.  That controls searching the content of
pages.  I'm talking about entering a path in the filebrowser.  You
used to be able to click on a "browse" button to upload a file and
then type a path.

-- 
Grant Edwards   grant.b.edwardsYow! You were s'posed
  at   to laugh!
  gmail.com

Re: [gentoo-user] Wow, the GTK3 file browser is awful!

[Mick]

On Monday 22 May 2017 18:33:47 Grant Edwards wrote:
> Having just recently allowed Firefox to upgrade from 45 to 52, I'm now
> hobbled with the GTK3 file browser dialog.
> 
> It's horrible.
> 
> First of all, it's freaking _huge_!  It wastes acres of display
> real-estate.  It was obviously designed by a megalomaniac who thinks
> your computer belongs to him, and that while his filebrowser code is
> running, nothing else must be visible.

Hmm ... I haven't noticed this here.


> I used to be able to just start typing a path.  Now, that triggeres
> some bizzarre "search" feature that shows a spinner for a minutes at a
> time shows a long list of files I don't care about.

You can go to Edit/Preferences/Advanced and deselect 'Search for text when I 
start typing'


> I've discovered that hitting Ctrl-L makes it minimally functional, and
> I can at least enter a path again.
> 
> I shall probably die still longing for the days of GTK2...

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Wow, the GTK3 file browser is awful!

[Kent Fredric]

On Mon, 22 May 2017 18:33:47 + (UTC)
Grant Edwards  wrote:

> Having just recently allowed Firefox to upgrade from 45 to 52, I'm now
> hobbled with the GTK3 file browser dialog.
> 
> It's horrible.

Indeed :/. You're not alone, but what can we do about it?

Its not like we have sufficient staff to maintain a "Firefox but with
GTK2" fork, heck, we can't even keep alsa support.

I've gone to using other older firefox forks (palemoon) instead simply
because this march of progress doesn't seem to be delivering on that
"progress", only making the user experience more boring and generic,
and thus, more useless.

"One size fits all, copy everyone else" is not a useful axiom to me.

But at this rate, every browser trying to be "more like what the masses
want" will end me up having no browser that exists and works that works
how I want.


pgpxnPvHPD9H9.pgp
Description: OpenPGP digital signature

[gentoo-user] Wow, the GTK3 file browser is awful!

[Grant Edwards]

Having just recently allowed Firefox to upgrade from 45 to 52, I'm now
hobbled with the GTK3 file browser dialog.

It's horrible.

First of all, it's freaking _huge_!  It wastes acres of display
real-estate.  It was obviously designed by a megalomaniac who thinks
your computer belongs to him, and that while his filebrowser code is
running, nothing else must be visible.

I used to be able to just start typing a path.  Now, that triggeres
some bizzarre "search" feature that shows a spinner for a minutes at a
time shows a long list of files I don't care about.

I've discovered that hitting Ctrl-L makes it minimally functional, and
I can at least enter a path again.

I shall probably die still longing for the days of GTK2...

-- 
Grant Edwards   grant.b.edwardsYow! I had pancake makeup
  at   for brunch!
  gmail.com

[gentoo-user] Re: Qt-4.8.7 bug

[Jörg Schaible]

Hello Kai,

Kai Krakow wrote:

> Am Mon, 22 May 2017 19:33:55 +0200
> schrieb Jörg Schaible :
> 
>> Peter Humphrey wrote:

[snip]

>> > 
>> > I can only suggest you read bug report 618922 if you haven't
>> > already, including following its reference to bug 595618. It makes
>> > sense to me.
>> 
>> It does not for me. My packages were already compiled with gcc-5.4.0.
>> Those Buzilla issues only talk about (plasma/qt) packages compiled
>> with previous gcc-4.x which are supposed to be incompatible. All of
>> the plasma/qt related packages that have been recompiled, because
>> they were built upon libQtCore.so.4 were already recompiled with
>> gcc5. I've checked my logs.
> 
> Is the problem maybe order of building packages?
> 
> From your description I see one edge case: Plasma could have been
> compiled with gcc-5 but linked to qt still built with gcc-4. Then, qt
> was rebuilt after this and is compiled by gcc-5 now.
> 
> Without reading the bug report I would guess that is what the bug is
> about: Linking plasma against gcc-4 built qt binaries... Even when you
> rebuild qt with gcc-5 after this, you'd need to relink plasma.
> 
> From your logs, you should see the order in which those packages were
> rebuilt and linked.
> 
> revdep-rebuild is not always able to perfectly order packages right for
> emerge, and emerge in turn has no problem with wrong ordering because
> it is rebuilding packages and the dependency constraints are already
> fulfilled (read: runtime and build deps are already there). Portage
> does not consider rebuilds as a hard dependency/precondition for
> rebuilding other packages...
> 
> As far as I understood, "--changed-deps" should fix this and also
> rebuild packages depending on the rebuilt packages _after_ they've been
> rebuilt.
> 
> The "--empty" option would have a similar effect, tho rebuild many more
> packages.
> 
> You could've tried if "revdep-rebuild ... -- --changed-deps" would've
> done anything better. I would be interested...

Too late now for this, but your assumption can be true. The rebuild for the 
gcc5 switch did not work smoothly because emerge failed to build all 515 
packages reported by revdep-rebuild in correct order. Especially the Kontact 
suite was affected, because emerge tried to build kdepim-common-libs before 
some of the dependent packages (happened to me on two different machines). A 
second run rebuilding only the failed stuff succeeded in the end, but that 
might have lead to the linker situation you've described above. I wonder, 
what else might still be affected :-/

Cheers,
Jörg

[gentoo-user] Re: Qt-4.8.7 bug

[Kai Krakow]

Am Mon, 22 May 2017 19:33:55 +0200
schrieb Jörg Schaible :

> Peter Humphrey wrote:
> 
> > On Monday 22 May 2017 09:49:01 Jörg Schaible wrote:  
> >> Hi Peter,
> >> 
> >> Peter Humphrey wrote:
> >> 
> >> [snip]
> >>   
>  [...]  
> >> 
> >> well, this does not seem to be the complete truth. When I switched
> >> to gcc 5.x I did a revdep-rebuild for anything that was compiled
> >> against libstdc++.so.6 just like the according news entry was
> >> recommending. And I am quite sure that those Qt plugins were part
> >> of my 515 recompiled packages.
> >> 
> >> Nevertheless, my KDE 4 apps were broken after the update to Qt
> >> 4.8.7. Rebuilding anything that was using libQtCore.so.4 solved
> >> it, but I fail to see how this is related to the gcc update two
> >> weeks ago.  
> > 
> > I can only suggest you read bug report 618922 if you haven't
> > already, including following its reference to bug 595618. It makes
> > sense to me.  
> 
> It does not for me. My packages were already compiled with gcc-5.4.0.
> Those Buzilla issues only talk about (plasma/qt) packages compiled
> with previous gcc-4.x which are supposed to be incompatible. All of
> the plasma/qt related packages that have been recompiled, because
> they were built upon libQtCore.so.4 were already recompiled with
> gcc5. I've checked my logs.

Is the problem maybe order of building packages?

From your description I see one edge case: Plasma could have been
compiled with gcc-5 but linked to qt still built with gcc-4. Then, qt
was rebuilt after this and is compiled by gcc-5 now.

Without reading the bug report I would guess that is what the bug is
about: Linking plasma against gcc-4 built qt binaries... Even when you
rebuild qt with gcc-5 after this, you'd need to relink plasma.

From your logs, you should see the order in which those packages were
rebuilt and linked.

revdep-rebuild is not always able to perfectly order packages right for
emerge, and emerge in turn has no problem with wrong ordering because
it is rebuilding packages and the dependency constraints are already
fulfilled (read: runtime and build deps are already there). Portage
does not consider rebuilds as a hard dependency/precondition for
rebuilding other packages...

As far as I understood, "--changed-deps" should fix this and also
rebuild packages depending on the rebuilt packages _after_ they've been
rebuilt.

The "--empty" option would have a similar effect, tho rebuild many more
packages.

You could've tried if "revdep-rebuild ... -- --changed-deps" would've
done anything better. I would be interested...


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: Re: Re: Qt-4.8.7 bug

[Jörg Schaible]

Peter Humphrey wrote:

> On Monday 22 May 2017 09:49:01 Jörg Schaible wrote:
>> Hi Peter,
>> 
>> Peter Humphrey wrote:
>> 
>> [snip]
>> 
>> > Have you seen https://bugs.gentoo.org/show_bug.cgi?id=595618 ? It says
>> > that "Qt plugins compiled with gcc-4 are incompatible with
>> > > > be
>> > expected to anticipate that. On the other hand, some kind of notice
>> > could
>> > be issued, and bug 618922 is pursuing that. (That's the one I started
>> > this thread with.)
>> 
>> well, this does not seem to be the complete truth. When I switched to gcc
>> 5.x I did a revdep-rebuild for anything that was compiled against
>> libstdc++.so.6 just like the according news entry was recommending. And I
>> am quite sure that those Qt plugins were part of my 515 recompiled
>> packages.
>> 
>> Nevertheless, my KDE 4 apps were broken after the update to Qt 4.8.7.
>> Rebuilding anything that was using libQtCore.so.4 solved it, but I fail
>> to see how this is related to the gcc update two weeks ago.
> 
> I can only suggest you read bug report 618922 if you haven't already,
> including following its reference to bug 595618. It makes sense to me.

It does not for me. My packages were already compiled with gcc-5.4.0. Those 
Buzilla issues only talk about (plasma/qt) packages compiled with previous 
gcc-4.x which are supposed to be incompatible. All of the plasma/qt related 
packages that have been recompiled, because they were built upon 
libQtCore.so.4 were already recompiled with gcc5. I've checked my logs.

Cheers,
Jörg

Re: [gentoo-user] Re: Issues with AMD_IOMMU

[Alan Grimes]

Here's the grub command line I was using on my Phenom II on a 990FX
board, I had only commented it out after upgrading to Ryzen

#GRUB_CMDLINE_LINUX="check_enable_amd_mmconf amd_iommu=fullflush iommu=soft"


-- 
Strange Game.
The only winning move is not to play. 

Powers are not rights.

Re: [gentoo-user] gdm fails to start

[Hogren]

Hello,

Very simple question but did you have "pam" in your global USE flag or
Systemd USE flag ?

If this is on the first, did you compile systemd and may be dependencies
after add it ?

Did you try that:

|systemctl reset-failed|

|For a guy on github, that solve (without explanation) the problem:
|

|https://github.com/coreos/bugs/issues/1498|
||



Hogren





On 22/05/2017 14:13, Raffaele Belardi wrote:
> On Mon, 2017-05-22 at 13:02 +0300, Alexander Kapshuk wrote:
>> On Mon, May 22, 2017 at 1:00 PM, Raffaele Belardi
>>  wrote:
>>> On Mon, 2017-05-22 at 12:47 +0300, Alexander Kapshuk wrote:
 A Google search found this systemd issue:
 https://github.com/systemd/systemd/issues/4342
 Quote:
 @poettering I see I left no account modules in the bare-bones PAM
 config. Maybe it is pam_acct_mgmt failing then?

 @yuwata what happens if you add account required pam_unix.so ?

 @fsateler Thanks. By adding the line, user sessions successfully
 start
 without the error messages. Do you think the line should be added
 to
 the minimal PAM file?

 See if that helps.

>>> Yes, I saw that but the solution is not at all clear to me: which
>>> PAM
>>> config file are they referring to?
>>>
>>> raffaele
>>>
>>>
>> Could it be this one, /etc/pam.d/systemd-user?
>>
> Done then issued 'systemctl daemon-reload' and 'systemctl start gdm',
> no change:
>
> $ cat /etc/pam.d/systemd-user 
> # This file is part of systemd.
> #
> # Used by systemd --user instances.
>
> account include system-auth
> # [RB]
> account required pam_unix.so
> session include system-auth
> session optional pam_keyinit.so force revoke
> session optional pam_systemd.so
>
> #journalctl -b
> ...
> systemd[1]: Created slice User Slice of gdm.
> systemd[1]: Starting User Manager for UID 32...
> systemd[1]: Started Session c519 of user gdm.
> systemd-logind[173]: New session c519 of user gdm.
> systemd[15240]: user@32.service: Failed at step PAM spawning
> /usr/lib/systemd/systemd: Operation not permitted
> systemd[1]: Failed to start User Manager for UID 32.
> systemd[1]: user@32.service: Unit entered failed state.
> systemd[1]: user@32.service: Failed with result 'protocol'.
> gdm-launch-environment][15237]: pam_systemd(gdm-launch-
> environment:session): Failed to create session: Start job for unit user
> @32.service failed with 'failed'
> systemd-logind[173]: Removed session c519.
>

Re: [gentoo-user] Re: Issues with AMD_IOMMU

[Corbin Bird]

On 05/21/2017 06:12 PM, Adam Carter wrote:
> 
> 
> > [0.991863] iommu: Adding device :06:00.0 to group 12
> > [0.991982] iommu: Adding device :07:04.0 to group 12
> > [1.063849] AMD-Vi: Found IOMMU at :00:00.2 cap 0x40
> > [1.063962] AMD-Vi: Interrupt remapping enabled
> > [1.064145] AMD-Vi: Lazy IO/TLB flushing enabled
> > [1.065331] perf: AMD NB counters detected
> 
> 
> I'm similar, but have a couple of extra entries. I've read a little bit
> about them, but so far am unable to determine if their existence
> indicates a better or worse kernel config.
> 
> [1.036309] AMD-Vi: Lazy IO/TLB flushing enabled
> [1.036419] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
> [1.036529] software IO TLB [mem 0xba61a000-0xbe61a000] (64MB) mapped
> at [a3b87a61a000-a3b87e619fff]
> [1.036744] perf: AMD NB counters detected
> 
> And the Linux AGP Driver ( in-kernel ) is working now.
> 
> Now this is showing properly with lspci :
> 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD/ATI] RD890S/RD990 I/O
> Memory Management Unit (IOMMU)
> 
> 
> Same.

The (SWIOTLB) should not be the default.

What kernel parameters for IOMMUs are you using now?

The listed result I posted is with nothing related to IOMMUs in the
kernel parameters, and NO GART IOMMU support compiled.


Corbin

Re: [gentoo-user] gdm fails to start

[Raffaele Belardi]

On Mon, 2017-05-22 at 13:02 +0300, Alexander Kapshuk wrote:
> On Mon, May 22, 2017 at 1:00 PM, Raffaele Belardi
>  wrote:
> > On Mon, 2017-05-22 at 12:47 +0300, Alexander Kapshuk wrote:
> > > 
> > > A Google search found this systemd issue:
> > > https://github.com/systemd/systemd/issues/4342
> > > Quote:
> > > @poettering I see I left no account modules in the bare-bones PAM
> > > config. Maybe it is pam_acct_mgmt failing then?
> > > 
> > > @yuwata what happens if you add account required pam_unix.so ?
> > > 
> > > @fsateler Thanks. By adding the line, user sessions successfully
> > > start
> > > without the error messages. Do you think the line should be added
> > > to
> > > the minimal PAM file?
> > > 
> > > See if that helps.
> > > 
> > 
> > Yes, I saw that but the solution is not at all clear to me: which
> > PAM
> > config file are they referring to?
> > 
> > raffaele
> > 
> > 
> 
> Could it be this one, /etc/pam.d/systemd-user?
> 

Done then issued 'systemctl daemon-reload' and 'systemctl start gdm',
no change:

$ cat /etc/pam.d/systemd-user 
# This file is part of systemd.
#
# Used by systemd --user instances.

account include system-auth
# [RB]
account required pam_unix.so
session include system-auth
session optional pam_keyinit.so force revoke
session optional pam_systemd.so

#journalctl -b
...
systemd[1]: Created slice User Slice of gdm.
systemd[1]: Starting User Manager for UID 32...
systemd[1]: Started Session c519 of user gdm.
systemd-logind[173]: New session c519 of user gdm.
systemd[15240]: user@32.service: Failed at step PAM spawning
/usr/lib/systemd/systemd: Operation not permitted
systemd[1]: Failed to start User Manager for UID 32.
systemd[1]: user@32.service: Unit entered failed state.
systemd[1]: user@32.service: Failed with result 'protocol'.
gdm-launch-environment][15237]: pam_systemd(gdm-launch-
environment:session): Failed to create session: Start job for unit user
@32.service failed with 'failed'
systemd-logind[173]: Removed session c519.

Re: [gentoo-user] Re: Re: Qt-4.8.7 bug

[Peter Humphrey]

On Monday 22 May 2017 09:49:01 Jörg Schaible wrote:
> Hi Peter,
> 
> Peter Humphrey wrote:
> 
> [snip]
> 
> > Have you seen https://bugs.gentoo.org/show_bug.cgi?id=595618 ? It says
> > that "Qt plugins compiled with gcc-4 are incompatible with
> >  > be
> > expected to anticipate that. On the other hand, some kind of notice
> > could
> > be issued, and bug 618922 is pursuing that. (That's the one I started
> > this thread with.)
> 
> well, this does not seem to be the complete truth. When I switched to gcc
> 5.x I did a revdep-rebuild for anything that was compiled against
> libstdc++.so.6 just like the according news entry was recommending. And I
> am quite sure that those Qt plugins were part of my 515 recompiled
> packages.
> 
> Nevertheless, my KDE 4 apps were broken after the update to Qt 4.8.7.
> Rebuilding anything that was using libQtCore.so.4 solved it, but I fail to
> see how this is related to the gcc update two weeks ago.

I can only suggest you read bug report 618922 if you haven't already, 
including following its reference to bug 595618. It makes sense to me.

-- 
Regards
Peter

Re: [gentoo-user] gdm fails to start

[Alexander Kapshuk]

On Mon, May 22, 2017 at 1:00 PM, Raffaele Belardi
 wrote:
> On Mon, 2017-05-22 at 12:47 +0300, Alexander Kapshuk wrote:
>>
>> A Google search found this systemd issue:
>> https://github.com/systemd/systemd/issues/4342
>> Quote:
>> @poettering I see I left no account modules in the bare-bones PAM
>> config. Maybe it is pam_acct_mgmt failing then?
>>
>> @yuwata what happens if you add account required pam_unix.so ?
>>
>> @fsateler Thanks. By adding the line, user sessions successfully
>> start
>> without the error messages. Do you think the line should be added to
>> the minimal PAM file?
>>
>> See if that helps.
>>
>
> Yes, I saw that but the solution is not at all clear to me: which PAM
> config file are they referring to?
>
> raffaele
>
>
>
Could it be this one, /etc/pam.d/systemd-user?

Re: [gentoo-user] gdm fails to start

[Raffaele Belardi]

On Mon, 2017-05-22 at 12:47 +0300, Alexander Kapshuk wrote:
> 
> A Google search found this systemd issue:
> https://github.com/systemd/systemd/issues/4342
> Quote:
> @poettering I see I left no account modules in the bare-bones PAM
> config. Maybe it is pam_acct_mgmt failing then?
> 
> @yuwata what happens if you add account required pam_unix.so ?
> 
> @fsateler Thanks. By adding the line, user sessions successfully
> start
> without the error messages. Do you think the line should be added to
> the minimal PAM file?
> 
> See if that helps.
> 

Yes, I saw that but the solution is not at all clear to me: which PAM
config file are they referring to?

raffaele

Re: [gentoo-user] gdm fails to start

[Alexander Kapshuk]

On Mon, May 22, 2017 at 11:16 AM, Raffaele Belardi
 wrote:
> I'm unable to start the gdm service on a recently installed gnome
> desktop (~x86): the service continuously fails and restarts with the
> errors below. If I disable the service and login into a text console,
> startx works fine but the Gnome session misses some features (e.g.
> screen lock). I enabled debug logging on gdm but nothing significant
> appears.
>
> Any suggestions?
>
> thanks,
>
> raffaele
>
>
> systemd[356]: user@32.service: Failed at step PAM spawning
> /usr/lib/systemd/systemd: Operation not permitted
> systemd[1]: Failed to start User Manager for UID 32.
> gdm-launch-environment][310]: pam_systemd(gdm-launch-
> environment:session): Failed to create session: Start job for unit user
> @32.service failed with 'failed'
> systemd[1]: user@32.service: Unit entered failed state.
> systemd[1]: user@32.service: Failed with result 'protocol'.
>
> ...
>
> /usr/libexec/gdm-x-session[359]: Activated service
> 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1
> exited with stat
> /usr/libexec/gdm-x-session[359]: Unable to register display with
> display manager
>
>  # grep 32 /etc/passwd
> gdm:x:32:32:GDM:/var/lib/gdm:/bin/false
>
> # eselect profile list
> Available profile symlink targets:
>   [1]   default/linux/x86/13.0
>   [2]   default/linux/x86/13.0/selinux
>   [3]   default/linux/x86/13.0/desktop
>   [4]   default/linux/x86/13.0/desktop/gnome
>   [5]   default/linux/x86/13.0/desktop/gnome/systemd *
>   [6]   default/linux/x86/13.0/desktop/plasma
>   [7]   default/linux/x86/13.0/desktop/plasma/systemd
>   [8]   default/linux/x86/13.0/developer
>   [9]   default/linux/x86/13.0/systemd
>   [10]  hardened/linux/x86
>   [11]  hardened/linux/x86/selinux
>   [12]  hardened/linux/musl/x86
>   [13]  default/linux/uclibc/x86
>   [14]  hardened/linux/uclibc/x86
>

A Google search found this systemd issue:
https://github.com/systemd/systemd/issues/4342
Quote:
@poettering I see I left no account modules in the bare-bones PAM
config. Maybe it is pam_acct_mgmt failing then?

@yuwata what happens if you add account required pam_unix.so ?

@fsateler Thanks. By adding the line, user sessions successfully start
without the error messages. Do you think the line should be added to
the minimal PAM file?

See if that helps.

Re: [gentoo-user] Re: Issues with AMD_IOMMU

[Adam Carter]

On Mon, May 22, 2017 at 7:15 PM, taii...@gmx.com  wrote:

> Worse, ideally you wouldn't be using SWIOTLB but I don't know how to
> disable this without re-compiling the kernel.
>

Can you point to some definitive documentation on this?

When i read https://wiki.gentoo.org/wiki/IOMMU_SWIOTLB i dont come to that
conclusion.

Re: [gentoo-user] Re: Issues with AMD_IOMMU

[taii...@gmx.com]

Worse, ideally you wouldn't be using SWIOTLB but I don't know how to 
disable this without re-compiling the kernel.



On 05/21/2017 07:12 PM, Adam Carter wrote:




[0.991863] iommu: Adding device :06:00.0 to group 12
[0.991982] iommu: Adding device :07:04.0 to group 12
[1.063849] AMD-Vi: Found IOMMU at :00:00.2 cap 0x40
[1.063962] AMD-Vi: Interrupt remapping enabled
[1.064145] AMD-Vi: Lazy IO/TLB flushing enabled
[1.065331] perf: AMD NB counters detected

q
I'm similar, but have a couple of extra entries. I've read a little bit
about them, but so far am unable to determine if their existence indicates
a better or worse kernel config.

[1.036309] AMD-Vi: Lazy IO/TLB flushing enabled
[1.036419] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[1.036529] software IO TLB [mem 0xba61a000-0xbe61a000] (64MB) mapped at
[a3b87a61a000-a3b87e619fff]
[1.036744] perf: AMD NB counters detected

And the Linux AGP Driver ( in-kernel ) is working now.

Now this is showing properly with lspci :
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD/ATI] RD890S/RD990 I/O
Memory Management Unit (IOMMU)


Same.

[gentoo-user] gdm fails to start

[Raffaele Belardi]

I'm unable to start the gdm service on a recently installed gnome
desktop (~x86): the service continuously fails and restarts with the
errors below. If I disable the service and login into a text console,
startx works fine but the Gnome session misses some features (e.g.
screen lock). I enabled debug logging on gdm but nothing significant
appears.

Any suggestions?

thanks,

raffaele


systemd[356]: user@32.service: Failed at step PAM spawning
/usr/lib/systemd/systemd: Operation not permitted
systemd[1]: Failed to start User Manager for UID 32.
gdm-launch-environment][310]: pam_systemd(gdm-launch-
environment:session): Failed to create session: Start job for unit user
@32.service failed with 'failed'
systemd[1]: user@32.service: Unit entered failed state.
systemd[1]: user@32.service: Failed with result 'protocol'.

...

/usr/libexec/gdm-x-session[359]: Activated service
'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1
exited with stat
/usr/libexec/gdm-x-session[359]: Unable to register display with
display manager

 # grep 32 /etc/passwd
gdm:x:32:32:GDM:/var/lib/gdm:/bin/false

# eselect profile list
Available profile symlink targets:
  [1]   default/linux/x86/13.0
  [2]   default/linux/x86/13.0/selinux
  [3]   default/linux/x86/13.0/desktop
  [4]   default/linux/x86/13.0/desktop/gnome
  [5]   default/linux/x86/13.0/desktop/gnome/systemd *
  [6]   default/linux/x86/13.0/desktop/plasma
  [7]   default/linux/x86/13.0/desktop/plasma/systemd
  [8]   default/linux/x86/13.0/developer
  [9]   default/linux/x86/13.0/systemd
  [10]  hardened/linux/x86
  [11]  hardened/linux/x86/selinux
  [12]  hardened/linux/musl/x86
  [13]  default/linux/uclibc/x86
  [14]  hardened/linux/uclibc/x86

[gentoo-user] Re: Re: Qt-4.8.7 bug

[Jörg Schaible]

Hi Peter,

Peter Humphrey wrote:

[snip]

> Have you seen https://bugs.gentoo.org/show_bug.cgi?id=595618 ? It says
> that "Qt plugins compiled with gcc-4 are incompatible with
>  expected to anticipate that. On the other hand, some kind of notice could
> be issued, and bug 618922 is pursuing that. (That's the one I started this
> thread with.)

well, this does not seem to be the complete truth. When I switched to gcc 
5.x I did a revdep-rebuild for anything that was compiled against 
libstdc++.so.6 just like the according news entry was recommending. And I am 
quite sure that those Qt plugins were part of my 515 recompiled packages.

Nevertheless, my KDE 4 apps were broken after the update to Qt 4.8.7. 
Rebuilding anything that was using libQtCore.so.4 solved it, but I fail to 
see how this is related to the gcc update two weeks ago.

Cheers,
Jörg