Re: [gentoo-user] Borg 1.1 is out, when can we expect it in the repos?

[J. Roeleveld]

On Sunday, October 8, 2017 6:48:14 PM CEST Viktar Patotski wrote:
> Hi,
> 
> The proper to get it done is to submit an upgrade request to
> https://bugs.gentoo.org/ . And then even probably provide ebuild for
> maintainers to pick it up.
> 
> Best regards,
> Viktar
> 
> On Sun, Oct 8, 2017 at 7:36 PM, azarus  wrote:
> > Hi,
> > 
> > there's a new release of Borg (app-backup/borgbackup) out, and I was
> > wondering when it'd arrive in the Gentoo repos. I've tested it a bit on
> > my Gentoo boxes (manually edited an ebuild for that) and it runs
> > perfectly fine.
> > 
> > Thanks for the information!
> > 
> > Best regards,
> > --
> > azarus
> > email: aza...@posteo.net
> > xmpp:  aza...@azarus.ch
> > PGP:   3A79D6CFD2567CF9

If that is picked up by a developer, then yes.
My experience with providing bugs with ebuilds is that they get closed 
eventually due to open security bugs (fixed in supplied versions for a few 
years) and lack of maintainership.

--
Joost

Re: [gentoo-user] Borg 1.1 is out, when can we expect it in the repos?

[Stroller]

> On 8 Oct 2017, at 17:48, Viktar Patotski  wrote:
> 
> The proper to get it done is to submit an upgrade request to 
> https://bugs.gentoo.org/  . And then even probably 
> provide ebuild for maintainers to pick it up.

Someone's done it now: https://bugs.gentoo.org/633814

Stroller.

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[allan gottlieb]

On Mon, Oct 09 2017, Grant Edwards wrote:

> On 2017-10-09, Grant Edwards  wrote:
>> On 2017-10-09, R0b0t1  wrote:
>>
>>> In this case the namespace of the missing declaration is inside
>>> Mozilla's, e.g. it is part of Firefox or a closely bundled library.
>>
>> Yep, after a bit more research, that was my conclusion.
>>
>> The chromium build finished happily, so I've just started another
>> firefox build with MAKEOPTS=-j1.  
>
> Same error.  But at least it's at the end of the build log now where
> it's easy to find. :)
>
> I guess I'll wait for the next firefox ESR update and see if that one
> builds.

This is a know bug see https://bugs.gentoo.org/633790

allan

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-09, Grant Edwards  wrote:
> On 2017-10-09, R0b0t1  wrote:
>
>> In this case the namespace of the missing declaration is inside
>> Mozilla's, e.g. it is part of Firefox or a closely bundled library.
>
> Yep, after a bit more research, that was my conclusion.
>
> The chromium build finished happily, so I've just started another
> firefox build with MAKEOPTS=-j1.  

Same error.  But at least it's at the end of the build log now where
it's easy to find. :)

I guess I'll wait for the next firefox ESR update and see if that one
builds.

-- 
Grant

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-09, R0b0t1  wrote:

> In this case the namespace of the missing declaration is inside
> Mozilla's, e.g. it is part of Firefox or a closely bundled library.

Yep, after a bit more research, that was my conclusion.

The chromium build finished happily, so I've just started another
firefox build with MAKEOPTS=-j1.  

The USE flag settings for firefox appear to be the same as my other
systems where it builds without error.

Weird.

-- 
Grant

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[R0b0t1]

On Sun, Oct 8, 2017 at 4:53 PM, Grant Edwards  wrote:
> On 2017-10-08, R0b0t1  wrote:
>
>> Usually what happens is it will be corrupted in RAM after being
>> verified on disk, and faulty results will be saved to disk from RAM. A
>> user on the forums recently had this issue compiling dev-lang/vala,
>> and I have had related issues.
>
> I've had failing RAM corrupt files and cause compile failures (and
> various other odd problems). But, the exact symptoms tend to be pretty
> random.  The chances are infinitesmal that a HW problem would corrupt
> the download (or the compile itself) in an identical manner a second
> time.
>

Right, redownloading or rerunning the compilation usually fixes such
issues. At the same time, I have seen people hit bad areas of RAM
repeatedly and have it look like other errors.

>> As for what the error means: definitions are missing, which from an
>> end-user perspective is not really a fixable issue.
>
> Sometimes there are external library version/use-flag requirements
> that don't make it into an ebuild file correctly.  But, all the other
> cases I've run into like that yielded plenty of Google hits on the
> error messages.
>

In this case the namespace of the missing declaration is inside
Mozilla's, e.g. it is part of Firefox or a closely bundled library.

Cheers,
R0b0t1

Re: [gentoo-user] Error while starting Docker daemon

[Mick]

On Sunday, 8 October 2017 20:07:09 BST Neil Bothwick wrote:
> On Sun, 08 Oct 2017 19:10:48 +0100, Mick wrote:
> > From what I see above you are running btrfs.  It may be worth compiling
> > in your kernel this module you have left out, because I've read
> > somewhere it prevents fs corruption (Rich seems to know a lot about
> > BTRFS, so I leave it to him to confirm its usefulness):
> > 
> > # CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
> 
> That module is not intended for normal use, and is marked as DANGEROUS.
> At best it will slow your system dramatically...

Thanks guys, and my apologies to the OP for the bum steer!  :-)

-- 
Regards,
Mick

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

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-08, R0b0t1  wrote:

> Usually what happens is it will be corrupted in RAM after being
> verified on disk, and faulty results will be saved to disk from RAM. A
> user on the forums recently had this issue compiling dev-lang/vala,
> and I have had related issues.

I've had failing RAM corrupt files and cause compile failures (and 
various other odd problems). But, the exact symptoms tend to be pretty
random.  The chances are infinitesmal that a HW problem would corrupt
the download (or the compile itself) in an identical manner a second
time.

> As for what the error means: definitions are missing, which from an
> end-user perspective is not really a fixable issue.

Sometimes there are external library version/use-flag requirements
that don't make it into an ebuild file correctly.  But, all the other
cases I've run into like that yielded plenty of Google hits on the
error messages.

> I would rerun the compilation with -j1 if you have not already done
> so.

I'm going to try that as soon as chromium finishes building.

> If other people can build the package then portage may be munging the
> files in some way, but these issues are hard to diagnose.

-- 
Grant

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[R0b0t1]

On Sun, Oct 8, 2017 at 1:54 PM, Grant Edwards  wrote:
> On 2017-10-08, Mick  wrote:
>> This won't harm, although I would expect portage would complain and
>> not run the emerge if downloads were corrupted somehow.
>
> True, but I couldn't think of anything else to try.  I'm building
> chromium now -- it may be time to give up on firefox.  It's been
> bahaving badly on several of my systems for a while now (burning 100%
> cpu and using up huge amounts of RAM for minutes at a time while
> apparently doing nothing).
>

Usually what happens is it will be corrupted in RAM after being
verified on disk, and faulty results will be saved to disk from RAM. A
user on the forums recently had this issue compiling dev-lang/vala,
and I have had related issues.

As for what the error means: definitions are missing, which from an
end-user perspective is not really a fixable issue. I would rerun the
compilation with -j1 if you have not already done so. If other people
can build the package then portage may be munging the files in some
way, but these issues are hard to diagnose.

Cheers,
 R0b0t1

Re: [gentoo-user] Error while starting Docker daemon

[Neil Bothwick]

On Sun, 08 Oct 2017 19:10:48 +0100, Mick wrote:

> From what I see above you are running btrfs.  It may be worth compiling
> in your kernel this module you have left out, because I've read
> somewhere it prevents fs corruption (Rich seems to know a lot about
> BTRFS, so I leave it to him to confirm its usefulness):
> 
> # CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set

That module is not intended for normal use, and is marked as DANGEROUS.
At best it will slow your system dramatically...


-- 
Neil Bothwick

I used to live in the real world, but I got evicted.


pgphmejjoa5NI.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Error while starting Docker daemon

[Rich Freeman]

On Sun, Oct 8, 2017 at 11:10 AM, Mick  wrote:
>
> From what I see above you are running btrfs.  It may be worth compiling in
> your kernel this module you have left out, because I've read somewhere it
> prevents fs corruption (Rich seems to know a lot about BTRFS, so I leave it to
> him to confirm its usefulness):
>
> # CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
>

I wouldn't look much further than the config docs on this one:

Btrfs with integrity check tool compiled in (DANGEROUS)
...Enabling this functionality is not intended for normal use.  In
most cases, unless you are a btrfs developer who needs to verify the
integrity of (super)-block write requests during the run of a
regression test, say N.

It looks like it is intended only for regression testing.  I didn't
dig too deep into the docs, but it probably turns on some assertions
and probably doesn't have much in the way of recovery if they are
triggered.  Granted, if they trigger you probably have issues anyway,
but they might not be as severe as whatever happens when this is
turned on.  Of course, in theory it shouldn't do anything other than
waste RAM/CPU, since assertions aren't supposed to be triggered.

So, no, you don't want this on a real system.

-- 
Rich

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-08, Mick  wrote:
> On Sunday, 8 October 2017 18:02:43 BST Grant Edwards wrote:
>
>> I was afraid it might be failing RAM, but a second attempt failed in
>> exactly the same way.  I guess I'll delete the ebuild files and the
>> source tarball to force a download and then try again.

Same error.

> This won't harm, although I would expect portage would complain and
> not run the emerge if downloads were corrupted somehow.

True, but I couldn't think of anything else to try.  I'm building
chromium now -- it may be time to give up on firefox.  It's been
bahaving badly on several of my systems for a while now (burning 100%
cpu and using up huge amounts of RAM for minutes at a time while
apparently doing nothing).

-- 
Grant

Re: [gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Mick]

On Sunday, 8 October 2017 18:02:43 BST Grant Edwards wrote:

> I was afraid it might be failing RAM, but a second attempt failed in
> exactly the same way.  I guess I'll delete the ebuild files and the
> source tarball to force a download and then try again.

This won't harm, although I would expect portage would complain and not run 
the emerge if downloads were corrupted somehow.
-- 
Regards,
Mick

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

Re: [gentoo-user] Error while starting Docker daemon

[Mick]

On Sunday, 8 October 2017 12:20:00 BST Hubert Hauser wrote:
> On 07/10/17 18:50, Mick wrote:
> > On Saturday, 7 October 2017 17:23:33 BST Hubert Hauser wrote:
> >> I am using Gentoo as Host OS for Docker containers.
> >> I have compiled
> >> kernel using instructions on page
> >> https://wiki.gentoo.org/wiki/Docker#Kernel and I have installed Docker
> >> from Gentoo repository.
> >> 
> >> Host system informations:
> >> pecan@tux ~ $ uname -a
> >> Linux tux 4.12.12-gentoo #8 SMP Sat Oct 7 13:58:47 CEST 2017 x86_64
> >> 
> >> Intel(R) Core(TM) i5-6300HQ CPU @ 2.30GHz GenuineIntel GNU/Linux
> >> 
> >> Docker version:
> >> pecan@tux ~ $ docker version
> >> 
> >> Client:
> >>  Version:  17.03.2-ce
> >>  API version:  1.27
> >>  Go version:   go1.9.1
> >>  Git commit:   f5ec1e2
> >>  Built:Sat Oct  7 14:50:59 2017
> >>  OS/Arch:  linux/amd64
> >> 
> >> Cannot connect to the Docker daemon at unix:///var/run/docker.sock.
> >> 
> >> Is the docker daemon running?
> >> 
> >> Look at "Cannot connect to the Docker daemon at
> >> unix:///var/run/docker.sock. Is the docker daemon running?". The same
> >> 
> >> message appears if I try get docker system-wide informations:
> >> pecan@tux ~ $ docker info
> >> Cannot connect to the Docker daemon at unix:///var/run/docker.sock.
> >> 
> >> Is the docker daemon running?
> > 
> > It seems you have not yet started docker.
> 
> I can't start it because failure occurs when starting Docker daemon.
> 
> On 07/10/17 18:50, Mick wrote:
> >> The same error appears if I try run the same command as sudo, so this
> >> error applies to daemon. I tried to check if there a mistake in Docker
> >> daemon privileges.
> >> 
> >> pecan@tux ~ $ sudo docker info
> >> Cannot connect to the Docker daemon at unix:///var/run/docker.sock.
> >> 
> >> Is the docker daemon running?
> >> 
> >> Based on the message I am able to say that maybe Docker daemon not
> >> 
> >> running. I checked daemon status to make sure:
> >> pecan@tux ~ $ sudo service docker status
> >> 
> >>  * status: crashed
> > 
> > Did you try starting it from the CLI?  Any useful messages there?
> 
> Yes.
> 
> The result of command sudo dockerd:
> https://paste.pound-python.org/show/AyjLQEBGABpjo57E9WMa/
> and of sudo dockerd -s overlay2:
> https://paste.pound-python.org/show/ulyqb7D363I51JqkvrEk/.
> 
> You can also look at attachments dockerd.txt (sudo dockerd) and
> dockerd-overlay2.txt (sudo dockerd -s overlay2).
> 
> I must run dockerd without connecting into VPN.
> 
> I've reset iptables and ip6tables rules to defaults:
> 
> pecan@tux ~ $ sudo iptables -L
> Chain INPUT (policy ACCEPT)
> target prot opt source   destination
> 
> Chain FORWARD (policy ACCEPT)
> target prot opt source   destination
> DOCKER-ISOLATION  all  --  anywhere anywhere   
> DOCKER all  --  anywhere anywhere   
> ACCEPT all  --  anywhere anywhere ctstate
> RELATED,ESTABLISHED
> ACCEPT all  --  anywhere anywhere   
> ACCEPT all  --  anywhere anywhere   
> 
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination
> 
> Chain DOCKER (1 references)
> target prot opt source   destination
> 
> Chain DOCKER-ISOLATION (1 references)
> target prot opt source   destination
> RETURN all  --  anywhere anywhere
> 
> (tensorflow) pecan@tux ~ $ sudo ip6tables -L
> Chain INPUT (policy ACCEPT)
> target prot opt source   destination
> 
> Chain FORWARD (policy ACCEPT)
> target prot opt source   destination
> 
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination
> 
> Here's my Docker logs:
> 
> (tensorflow) pecan@tux ~ $ sudo cat /var/log/docker-err.log
> time="2017-10-07T14:54:24.561887891+02:00" level=info
> msg="libcontainerd: new containerd process, pid: 994"
> Error starting daemon: error initializing graphdriver: prerequisites for
> driver not satisfied (wrong filesystem?)
> time="2017-10-07T14:56:44.682987498+02:00" level=info
> msg="libcontainerd: new containerd process, pid: 4983"
> Error starting daemon: error initializing graphdriver: prerequisites for
> driver not satisfied (wrong filesystem?)
> time="2017-10-07T17:00:16.938724808+02:00" level=info
> msg="libcontainerd: new containerd process, pid: 7254"
> Error starting daemon: error initializing graphdriver: prerequisites for
> driver not satisfied (wrong filesystem?)
> time="2017-10-07T17:03:58.151814419+02:00" level=info
> msg="libcontainerd: new containerd process, pid: 7857"
> Error starting daemon: error initializing graphdriver: prerequisites for
> driver not satisfied (wrong filesystem?)
> time="2017-10-07T17:05:09.492506131+02:00" level=info
> msg="libcontainerd: new 

[gentoo-user] Re: emerge firefox-52.4.0 compile failure

[Grant Edwards]

On 2017-10-08, Mick  wrote:
> On Sunday, 8 October 2017 03:51:41 BST Grant Edwards wrote:
>> When I did my usual update today firefox 52.4.0 failed to build.
>> There are thousands of compiler warnings in the build log, but the
>> only thing I can find that looks like an error is this:

[...]

>> Google provides zero hits for any of those three errors.

> Your compiler is barfing at something, but I'm no coder to know what
> this might be.

Yes, thanks, those are g++ compiler error messages.  I could track
down and fix the problem in the source code, but since it's a "stable"
system, and firefox builds fine on other systems, I should have to do
that.

> In a Gentoo context, I'd start by checking you have installed and 
> switched to sys-devel/gcc-5.4.0-r3

Yep, I'm using gcc-5.4.0-r3.  There were 20+ other packages that got
built in that same upgrade, and they all went fine.

> which is the latest stable version and at least here compiled and
> installed firefox-52.4.0 on 4 PCs without a problem.

As have I.

I was afraid it might be failing RAM, but a second attempt failed in
exactly the same way.  I guess I'll delete the ebuild files and the
source tarball to force a download and then try again.

-- 
Grant

Re: [gentoo-user] Borg 1.1 is out, when can we expect it in the repos?

[Viktar Patotski]

Hi,

The proper to get it done is to submit an upgrade request to
https://bugs.gentoo.org/ . And then even probably provide ebuild for
maintainers to pick it up.

Best regards,
Viktar

On Sun, Oct 8, 2017 at 7:36 PM, azarus  wrote:

> Hi,
>
> there's a new release of Borg (app-backup/borgbackup) out, and I was
> wondering when it'd arrive in the Gentoo repos. I've tested it a bit on
> my Gentoo boxes (manually edited an ebuild for that) and it runs
> perfectly fine.
>
> Thanks for the information!
>
> Best regards,
> --
> azarus
> email: aza...@posteo.net
> xmpp:  aza...@azarus.ch
> PGP:   3A79D6CFD2567CF9
>
>

[gentoo-user] Borg 1.1 is out, when can we expect it in the repos?

[azarus]

Hi,

there's a new release of Borg (app-backup/borgbackup) out, and I was
wondering when it'd arrive in the Gentoo repos. I've tested it a bit on
my Gentoo boxes (manually edited an ebuild for that) and it runs
perfectly fine.

Thanks for the information!

Best regards,
-- 
azarus
email: aza...@posteo.net
xmpp:  aza...@azarus.ch
PGP:   3A79D6CFD2567CF9

Re: [gentoo-user] Failed to emerge dev-libs/cudnn-6.0

[Neil Bothwick]

On Sun, 8 Oct 2017 12:35:38 +0200, Hubert Hauser wrote:

> >>> Verifying ebuild manifests  
> 
> >>> Emerging (1 of 1) dev-libs/cudnn-6.0::gentoo  
> 
> !!! dev-libs/cudnn-6.0 has fetch restriction turned on.
> !!! This probably means that this ebuild's files must be downloaded
> !!! manually.  See the comments in the ebuild for more information.
> 
>  * Fetch failed for 'dev-libs/cudnn-6.0', Log file:
>  *  '/var/log/portage/build/dev-libs/cudnn-6.0:20171008-103145.log'
>  * The following files cannot be fetched for cudnn:
>  *    cudnn-8.0-linux-x64-v6.0.tgz

Like it says, the files cannot be downloaded by portage. This is usually
because you have to accept some sort of licence agreement before
downloading. You need to download the file specified, probably from
https://developer.nvidia.com/cuDNN and place it in $DISTDIR
(/usr/portage/distfiles by default) then run the emerge command again.



-- 
Neil Bothwick

Top Oxymorons Number 21: "Now, then ..."


pgpNQ8yDXRRUm.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] type keyboard problem

[Bill Kenworthy]

On 08/10/17 16:20, Andrew Savchenko wrote:
> Hi,
> 
> On Fri, 6 Oct 2017 08:31:27 +0800 Bill Kenworthy wrote:
>> Hi all, I have a laptop keyboard problem - it fails to reconnect the
>> keyboard on opening after closing.
>>
>> MS Surface pro 4 with type keyboard.
>>
>> The keyboard connects correctly on bootup or resume from hibernate (when
>> open).
>>
>> Close keyboard (removes power), open keyboard and it no longer works.
>> Requires a reboot (or hibernate/resume) for it it to work again.
>>
>> On opening the keyboard, the kernel detects it, it shows up in lsusb.
>>
>> Oct  6 05:57:15 bunyip kernel: usb 1-7: Product: Surface Type Cover
>> Oct  6 05:57:15 bunyip kernel: input: Microsoft Surface Type Cover
>> Keyboard as
>> /devices/pci:00/:00:14.0/usb1/1-7/1-7:1.0/0003:045E:07E8.0003/input/input29
>> Oct  6 05:57:15 bunyip kernel: input: Microsoft Surface Type Cover
>> Consumer Control as
>> /devices/pci:00/:00:14.0/usb1/1-7/1-7:1.0/0003:045E:07E8.0003/input/input31
>> Oct  6 05:57:15 bunyip kernel: input: Microsoft Surface Type Cover
>> Touchpad as
>> /devices/pci:00/:00:14.0/usb1/1-7/1-7:1.0/0003:045E:07E8.0003/input/input33
>> Oct  6 05:57:15 bunyip kernel: hid-multitouch 0003:045E:07E8.0003:
>> input,hiddev96,hidraw0: USB HID v1.11 Keyboard [Microsoft Surface Type
>> Cover] on usb-:00:14.0-7/input0
>>
>> It looks like it changes input when reopening but the event framework
>> fails to re-enumerate it.
>>
>> Ive tried restarting udev but no luck.
> 
> Try to update your kernel to the latest one, preferably to vanilla
> one.
> 
> Also try udevadm trigger.
> 
> Best regards,
> Andrew Savchenko
> 

Thanks Andrew, it used to work on older kernels - something 4.9 and before.

The culprit turns out to to be the i2c-hid kernel module - removing and
modprobing it again fixes the problem.  Its probably a bug as the
keyboard is usb-hid so I don't know why i2c-hid is involved.  A udev
rule triggered when the keyboard opens takes care of it for now.

BillK

[gentoo-user] Failed to emerge dev-libs/cudnn-6.0

[Hubert Hauser]

The commands sudo -i emerge -av dev-libs/cudnn results an error:

(tensorflow) pecan@tux ~ $ sudo -i emerge -av dev-libs/cudnn

 * IMPORTANT: 2 news items need reading for repository 'gentoo'.
 * Use eselect news read to view new items.


These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N F  ~] dev-libs/cudnn-6.0:0/6::gentoo  196,421 KiB

Total: 1 package (1 new), Size of downloads: 196,421 KiB
Fetch Restriction: 1 package (1 unsatisfied)

Fetch instructions for dev-libs/cudnn-6.0:
 * The following files cannot be fetched for cudnn:
 *    cudnn-8.0-linux-x64-v6.0.tgz

Would you like to merge these packages? [Yes/No] Yes

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) dev-libs/cudnn-6.0::gentoo

!!! dev-libs/cudnn-6.0 has fetch restriction turned on.
!!! This probably means that this ebuild's files must be downloaded
!!! manually.  See the comments in the ebuild for more information.

 * Fetch failed for 'dev-libs/cudnn-6.0', Log file:
 *  '/var/log/portage/build/dev-libs/cudnn-6.0:20171008-103145.log'
 * The following files cannot be fetched for cudnn:
 *    cudnn-8.0-linux-x64-v6.0.tgz

>>> Failed to emerge dev-libs/cudnn-6.0, Log file:

>>>  '/var/log/portage/build/dev-libs/cudnn-6.0:20171008-103145.log'

 * Messages for package dev-libs/cudnn-6.0:

 * The following files cannot be fetched for cudnn:
 *    cudnn-8.0-linux-x64-v6.0.tgz

 * Messages for package dev-libs/cudnn-6.0:

 * Fetch failed for 'dev-libs/cudnn-6.0', Log file:
 *  '/var/log/portage/build/dev-libs/cudnn-6.0:20171008-103145.log'
 * The following files cannot be fetched for cudnn:
 *    cudnn-8.0-linux-x64-v6.0.tgz

/var/log/portage/build/dev-libs/cudnn-6.0:20171008-103145.log file:

!!! dev-libs/cudnn-6.0 has fetch restriction turned on.
!!! This probably means that this ebuild's files must be downloaded
!!! manually.  See the comments in the ebuild for more information.

 * Fetch failed for 'dev-libs/cudnn-6.0', Log file:
 * 
'/var/log/portage/build/dev-libs/cudnn-6.0:20171008-103145.log'
 * Package:    dev-libs/cudnn-6.0
 * Repository: gentoo
 * Maintainer: s...@gentoo.org
 * USE:    abi_x86_64 amd64 elibc_glibc
kernel_linux userland_GNU
 * FEATURES:   preserve-libs sandbox userpriv usersandbox
 * The following files cannot be fetched for cudnn:
 *    cudnn-8.0-linux-x64-v6.0.tgz

Can anyone help me?

[gentoo-user] Compilation failed: qtwidgets-5.9.2

[tuxic]

Hi,

compilation of qtwidgets failed.
Is there a dependency currently missing in the ebuild?


x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--as-needed -Wl,--no-undefined 
-fuse-ld=gold -Wl,--enable-new-dtags -shared -o libqgtk3.so .obj/main.o 
.obj/qgtk3dialoghelpers.o .obj/qgtk3menu.o .obj/qgtk3theme.o 
.obj/moc_qgtk3dialoghelpers.o .obj/moc_qgtk3menu.o  -lQt5ThemeSupport -lQt5Gui 
-lQt5Core -lGL -lpthread -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 
-lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 
-lXext -lX11 -lm
.obj/qgtk3theme.o:qgtk3theme.cpp:vtable for QGtk3Theme: error: undefined 
reference to 'QGnomeTheme::createPlatformMenuBar() const'
.obj/qgtk3theme.o:qgtk3theme.cpp:vtable for QGtk3Theme: error: undefined 
reference to 'QGnomeTheme::createPlatformSystemTrayIcon() const'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/../../../../lib64/libQt5ThemeSupport.a(qgenericunixthemes.o):function
 ResourceHelper::clear(): error: undefined reference to 'operator delete(void*, 
unsigned long)'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/../../../../lib64/libQt5ThemeSupport.a(qgenericunixthemes.o):function
 ResourceHelper::clear(): error: undefined reference to 'operator delete(void*, 
unsigned long)'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/../../../../lib64/libQt5ThemeSupport.a(qgenericunixthemes.o):function
 
QtMetaTypePrivate::IteratorOwnerCommon::destroy(void**):
 error: undefined reference to 'operator delete(void*, unsigned long)'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.4/../../../../lib64/libQt5ThemeSupport.a(qgenericunixthemes.o):function
 QGnomeThemePrivate::~QGnomeThemePrivate(): error: undefined reference to 
'operator delete(void*, unsigned long)'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:138: ../../../../plugins/platformthemes/libqgtk3.so] 
Error 1
make[1]: Leaving directory 
'/var/tmp/portage/dev-qt/qtwidgets-5.9.2/work/qtbase-opensource-src-5.9.2/src/plugins/platformthemes/gtk3'
make: *** [Makefile:45: sub-gtk3-make_first] Error 2
 * ERROR: dev-qt/qtwidgets-5.9.2::gentoo failed (compile phase):
 *   emake failed
 *
 * If you need support, post the output of `emerge --info 
'=dev-qt/qtwidgets-5.9.2::gentoo'`,
 * the complete build log and the output of `emerge -pqv 
'=dev-qt/qtwidgets-5.9.2::gentoo'`.
 * The complete build log is located at 
'/var/tmp/portage/dev-qt/qtwidgets-5.9.2/temp/build.log'.
 * The ebuild environment file is located at 
'/var/tmp/portage/dev-qt/qtwidgets-5.9.2/temp/environment'.
 * Working directory: 
'/var/tmp/portage/dev-qt/qtwidgets-5.9.2/work/qtbase-opensource-src-5.9.2/src/plugins/platformthemes'
 * S: '/var/tmp/portage/dev-qt/qtwidgets-5.9.2/work/qtbase-opensource-src-5.9.2'

Cheers
Meino

Re: [gentoo-user] emerge firefox-52.4.0 compile failure

[Mick]

On Sunday, 8 October 2017 03:51:41 BST Grant Edwards wrote:
> When I did my usual update today firefox 52.4.0 failed to build.
> There are thousands of compiler warnings in the build log, but the
> only thing I can find that looks like an error is this:
> 
> /usr/bin/x86_64-pc-linux-gnu-g++ [...]
> /var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/ff/gfx/th
> ebes/Unified_cpp_gfx_thebes0.cpp [...]
> In file included from
> /var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/ff/gfx/th
> ebes/Unified_cpp_gfx_thebes0.cpp:65:0:
> /var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/gfx/thebe
> s/gfxFont.cpp:2625:29: error: 'mozilla::gfx::ShapedTextFlags' has not been
> declared
> /var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/gfx/thebe
> s/gfxFont.cpp:2626:24: error: 'RoundingFlags' has not been declared
> /var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/gfx/thebe
> s/gfxFont.cpp:2618:1: error: template-id 'GetShapedWord<>' for
> 'gfxShapedWord* gfxFont::GetShapedWord(gfxFont::DrawTarget*, const
> uint8_t*, uint32_t, uint32_t, gfxFont::Script, bool, int32_t, int, int,
> gfxTextPerfMetrics*)' does not match any template declaration [...]
> make[4]: ***
> [/var/tmp/portage/www-client/firefox-52.4.0/work/firefox-52.4.0esr/config/r
> ules.mk:951: Unified_cpp_gfx_thebes0.o] Error 1 make[4]: *** Waiting for
> unfinished jobs
> 
> Google provides zero hits for any of those three errors.
> 
> Does this look familiar to anybody?
> 
> --
> Grant

Your compiler is barfing at something, but I'm no coder to know what this 
might be.  In a Gentoo context, I'd start by checking you have installed and 
switched to sys-devel/gcc-5.4.0-r3 which is the latest stable version and at 
least here compiled and installed firefox-52.4.0 on 4 PCs without a problem.

-- 
Regards,
Mick

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

Re: [gentoo-user] type keyboard problem

[Andrew Savchenko]

Hi,

On Fri, 6 Oct 2017 08:31:27 +0800 Bill Kenworthy wrote:
> Hi all, I have a laptop keyboard problem - it fails to reconnect the
> keyboard on opening after closing.
> 
> MS Surface pro 4 with type keyboard.
> 
> The keyboard connects correctly on bootup or resume from hibernate (when
> open).
> 
> Close keyboard (removes power), open keyboard and it no longer works.
> Requires a reboot (or hibernate/resume) for it it to work again.
> 
> On opening the keyboard, the kernel detects it, it shows up in lsusb.
> 
> Oct  6 05:57:15 bunyip kernel: usb 1-7: Product: Surface Type Cover
> Oct  6 05:57:15 bunyip kernel: input: Microsoft Surface Type Cover
> Keyboard as
> /devices/pci:00/:00:14.0/usb1/1-7/1-7:1.0/0003:045E:07E8.0003/input/input29
> Oct  6 05:57:15 bunyip kernel: input: Microsoft Surface Type Cover
> Consumer Control as
> /devices/pci:00/:00:14.0/usb1/1-7/1-7:1.0/0003:045E:07E8.0003/input/input31
> Oct  6 05:57:15 bunyip kernel: input: Microsoft Surface Type Cover
> Touchpad as
> /devices/pci:00/:00:14.0/usb1/1-7/1-7:1.0/0003:045E:07E8.0003/input/input33
> Oct  6 05:57:15 bunyip kernel: hid-multitouch 0003:045E:07E8.0003:
> input,hiddev96,hidraw0: USB HID v1.11 Keyboard [Microsoft Surface Type
> Cover] on usb-:00:14.0-7/input0
> 
> It looks like it changes input when reopening but the event framework
> fails to re-enumerate it.
> 
> Ive tried restarting udev but no luck.

Try to update your kernel to the latest one, preferably to vanilla
one.

Also try udevadm trigger.

Best regards,
Andrew Savchenko


pgpN3ElF63trz.pgp
Description: PGP signature