Mirrors

2019-02-21 Thread Jay Patel
Hello All,

there's a firefox-62 on
http://ftp.ee.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0/
which works perfectly but not seen on
http://nycdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0/

also several problems installing MATE desktop from NYCDN repo as packages
gets truncated.
is this expected behavior?

Regards,
-- 
Jay Patel
*https://www.unitedbsd.com/ *


*usually found @ https://riot.im/app/#/room/#bsd:matrix.org
*


Re: dhcpcd failure

2019-02-21 Thread John Nemeth
On Feb 21,  4:30pm, Roy Marples wrote:
} On 21/02/2019 16:18, triaxx wrote:
} > 
} > 3    2019/01/16 5:55:46 PM    info    udhcpd[1154]: sending OFFER 
to 
} > 255.255.255.255 with 192.168.0.11
} > 
} > 
} > 16:13:56.468169 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto 
} > UDP (17), length 576)
} >      192.168.0.1.bootps > 192.168.0.11.bootpc: [udp sum ok] BOOTP/DHCP, 
} > Reply, length 548, xid 0x66ec8de4, Flags [none] (0x)
} >        Your-IP 192.168.0.11
} >        Server-IP 192.168.0.1
} >        Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown)
} >        Vendor-rfc1048 Extensions
} >          Magic Cookie 0x63825363
} >          DHCP-Message Option 53, length 1: Offer
} >          Server-ID Option 54, length 4: 192.168.0.1
} >          Lease-Time Option 51, length 4: 86400
} >          Subnet-Mask Option 1, length 4: 255.255.255.0
} >          Default-Gateway Option 3, length 4: 192.168.0.1
} >          Domain-Name-Server Option 6, length 4: 192.168.0.1
} >          Domain-Name Option 15, length 11: "atlas.local"

 Can you do the tcpdump with "-e" to show the ethernet header.
I'm wondering if it's sending to the layer 2 broadcast address of
ff:ff:ff:ff:ff:ff?

} What cisco says it's doing and what it's actually doing are different.
} It's claiming sending offer of 192.168.0.11 to 255.255.255.255 (which is 
} correct) but in reality it's unicasting to 192.168.0.11.
} 
} I don't see how any DHCP client can work with that.

 Yet, clearly it does, so there must be something else going
on that we haven't figured out yet.

} You might try getting dhcpcd to send the broadcast option using the -J 
} flag. That's non standard though and I doubt it will fix the issue.
} 
}-- End of excerpt from Roy Marples


Re: dhcpcd failure

2019-02-21 Thread triaxx




Le 2019-02-21 17:52, Roy Marples a écrit :

On 21/02/2019 16:45, triaxx wrote:

As least cisco respects -J but it doesn't fix the problem.

16:40:06.514754 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], 
proto UDP (17), length 576)
     192.168.0.1.bootps > 255.255.255.255.bootpc: [udp sum ok] 
BOOTP/DHCP, Reply, length 548, xid 0xe090f980, Flags [Broadcast] 
(0x8000)

   Your-IP 192.168.0.11
   Server-IP 192.168.0.1
   Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown)
   Vendor-rfc1048 Extensions
     Magic Cookie 0x63825363
     DHCP-Message Option 53, length 1: Offer
     Server-ID Option 54, length 4: 192.168.0.1
     Lease-Time Option 51, length 4: 86400
     Subnet-Mask Option 1, length 4: 255.255.255.0
     Default-Gateway Option 3, length 4: 192.168.0.1
     Domain-Name-Server Option 6, length 4: 192.168.0.1
     Domain-Name Option 15, length 11: "atlas.local"
     END Option 255, length 0
     PAD Option 0, length 0, occurs 261


So it's now broadcast which is good.
Does dhcpcd not see that?

Roy


No, it does not.



Re: dhcpcd failure

2019-02-21 Thread Roy Marples

On 21/02/2019 17:02, triaxx wrote:



Le 2019-02-21 17:52, Roy Marples a écrit :

On 21/02/2019 16:45, triaxx wrote:

As least cisco respects -J but it doesn't fix the problem.

16:40:06.514754 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], 
proto UDP (17), length 576)
 192.168.0.1.bootps > 255.255.255.255.bootpc: [udp sum ok] 
BOOTP/DHCP, Reply, length 548, xid 0xe090f980, Flags [Broadcast] 
(0x8000)

   Your-IP 192.168.0.11
   Server-IP 192.168.0.1
   Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown)
   Vendor-rfc1048 Extensions
 Magic Cookie 0x63825363
 DHCP-Message Option 53, length 1: Offer
 Server-ID Option 54, length 4: 192.168.0.1
 Lease-Time Option 51, length 4: 86400
 Subnet-Mask Option 1, length 4: 255.255.255.0
 Default-Gateway Option 3, length 4: 192.168.0.1
 Domain-Name-Server Option 6, length 4: 192.168.0.1
 Domain-Name Option 15, length 11: "atlas.local"
 END Option 255, length 0
 PAD Option 0, length 0, occurs 261


So it's now broadcast which is good.
Does dhcpcd not see that?

Roy

> No, it does not.


Does it log anything about a reply with the debug flag set? -d


Re: dhcpcd failure

2019-02-21 Thread Roy Marples

On 21/02/2019 16:45, triaxx wrote:

As least cisco respects -J but it doesn't fix the problem.

16:40:06.514754 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto 
UDP (17), length 576)
     192.168.0.1.bootps > 255.255.255.255.bootpc: [udp sum ok] 
BOOTP/DHCP, Reply, length 548, xid 0xe090f980, Flags [Broadcast] (0x8000)

   Your-IP 192.168.0.11
   Server-IP 192.168.0.1
   Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown)
   Vendor-rfc1048 Extensions
     Magic Cookie 0x63825363
     DHCP-Message Option 53, length 1: Offer
     Server-ID Option 54, length 4: 192.168.0.1
     Lease-Time Option 51, length 4: 86400
     Subnet-Mask Option 1, length 4: 255.255.255.0
     Default-Gateway Option 3, length 4: 192.168.0.1
     Domain-Name-Server Option 6, length 4: 192.168.0.1
     Domain-Name Option 15, length 11: "atlas.local"
     END Option 255, length 0
     PAD Option 0, length 0, occurs 261


So it's now broadcast which is good.
Does dhcpcd not see that?

Roy


Re: dhcpcd failure

2019-02-21 Thread triaxx




Le 2019-02-21 17:30, Roy Marples a écrit :

On 21/02/2019 16:18, triaxx wrote:


3    2019/01/16 5:55:46 PM    info    udhcpd[1154]: sending OFFER to 
255.255.255.255 with 192.168.0.11



16:13:56.468169 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], 
proto UDP (17), length 576)
     192.168.0.1.bootps > 192.168.0.11.bootpc: [udp sum ok] 
BOOTP/DHCP, Reply, length 548, xid 0x66ec8de4, Flags [none] (0x)

   Your-IP 192.168.0.11
   Server-IP 192.168.0.1
   Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown)
   Vendor-rfc1048 Extensions
     Magic Cookie 0x63825363
     DHCP-Message Option 53, length 1: Offer
     Server-ID Option 54, length 4: 192.168.0.1
     Lease-Time Option 51, length 4: 86400
     Subnet-Mask Option 1, length 4: 255.255.255.0
     Default-Gateway Option 3, length 4: 192.168.0.1
     Domain-Name-Server Option 6, length 4: 192.168.0.1
     Domain-Name Option 15, length 11: "atlas.local"


What cisco says it's doing and what it's actually doing are different.
It's claiming sending offer of 192.168.0.11 to 255.255.255.255 (which
is correct) but in reality it's unicasting to 192.168.0.11.

I don't see how any DHCP client can work with that.
You might try getting dhcpcd to send the broadcast option using the -J
flag. That's non standard though and I doubt it will fix the issue.

Roy


As least cisco respects -J but it doesn't fix the problem.

16:40:06.514754 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto 
UDP (17), length 576)
192.168.0.1.bootps > 255.255.255.255.bootpc: [udp sum ok] 
BOOTP/DHCP, Reply, length 548, xid 0xe090f980, Flags [Broadcast] 
(0x8000)

  Your-IP 192.168.0.11
  Server-IP 192.168.0.1
  Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown)
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 192.168.0.1
Lease-Time Option 51, length 4: 86400
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 192.168.0.1
Domain-Name-Server Option 6, length 4: 192.168.0.1
Domain-Name Option 15, length 11: "atlas.local"
END Option 255, length 0
PAD Option 0, length 0, occurs 261



Re: dhcpcd failure

2019-02-21 Thread triaxx

Le 2019-02-21 17:07, Roy Marples a écrit :

On 21/02/2019 14:58, triaxx wrote:

Le 2019-01-18 17:54, Andy Ruhl a écrit :

On Fri, Jan 18, 2019 at 2:09 AM Roy Marples  wrote:


Hi Fred

On 18/01/2019 06:05, triaxx wrote:
> I experienced a dhcpcd that cannot connect to a Cisco gateway through a
> fresh NetBSD 8.0. I tried dhclient which succeed.
>
> I didn't see relevant diff between MAIN and netbsd-8.
>
> I would like to send a PR but I'm interesting to know what informations
> could be relevant/helping.

You could try editing /etc/dhcpcd.conf and commenting out duid and 
using

clientid. If that still fails, try commenting out both.

If either work, complain to Cisco about their lack of RFC 
compliance.

Regardless, let me know the outcome please.


If it really is a Cisco compliance issue, I'd like to see a wireshark
of the failing request and the successful one for my own amusement.
This command seems to work on my mac, I'm guessing it will be similar
on NetBSD except the interface name:

tshark -i en0 -f "udp port 67 or 68" -w dhcp.pcap

Andy


tcpdump is like the observer of the Schrödinger's cat, it interfere in 
measurement.


If I run tcpdump -i re0 "udp port 67 or 68" -w dhcpcd.pcap when 
running service -v dhcpcd restart, it works fine...


Then, I can just provide the packet trace when the request succeed:

14:56:43.981194 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: 
BOOTP/DHCP, Request from 80:ee:73:c1:cd:36 (oui Unknown), length 318
14:56:44.019208 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: 
BOOTP/DHCP, Reply, length 548
14:56:44.019338 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: 
BOOTP/DHCP, Request from 80:ee:73:c1:cd:36 (oui Unknown), length 325
14:56:44.079055 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: 
BOOTP/DHCP, Reply, length 548
14:56:53.955162 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: 
BOOTP/DHCP, Request from 80:ee:73:c1:cd:36 (oui Unknown), length 319
14:56:53.988890 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: 
BOOTP/DHCP, Reply, length 548


Looks to me like the DHCP client is broadcasting for a lease (ie it
doesn't have an IP address) but the DHCP server thinks it has an IP
address and is unicasting to something that doesn't exist?

Can you add more - to see if the client is giving any hints if it
has an ip address?

Roy


I hope -vv is sufficient...

When it failed (with tcpdump in non promiscuous mode):

1	2019/01/16 5:48:05 PM	info	udhcpd[1154]: sending OFFER to 
255.255.255.255 with 192.168.0.11
2	2019/01/16 5:48:05 PM	info	udhcpd[1154]: received DISCOVER from 
80:EE:73:C1:CD:36
3	2019/01/16 5:47:57 PM	info	udhcpd[1154]: sending OFFER to 
255.255.255.255 with 192.168.0.11
4	2019/01/16 5:47:57 PM	info	udhcpd[1154]: received DISCOVER from 
80:EE:73:C1:CD:36




16:06:03.322149 IP (tos 0x0, ttl 64, id 39057, offset 0, flags [none], 
proto UDP (17), length 343)
0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, 
Request from 80:ee:73:c1:cd:36 (oui Unknown), length 315, xid 
0x7e4dd14c, Flags [none] (0x)

  Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown)
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
NOAUTO Option 116, length 1: Y
MSZ Option 57, length 2: 1472
	Vendor-Class Option 60, length 36: 
"dhcpcd-7.0.6:NetBSD-8.0:amd64:x86_64"

Hostname Option 12, length 6: "zealot"
T145 Option 145, length 1: 1
Parameter-Request Option 55, length 13:
	  Subnet-Mask, Classless-Static-Route, Static-Route, 
Default-Gateway

  Domain-Name-Server, Hostname, Domain-Name, MTU
  BR, Lease-Time, RN, RB
  Option 119
16:06:07.213394 IP (tos 0x0, ttl 64, id 14364, offset 0, flags [none], 
proto UDP (17), length 343)
0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, 
Request from 80:ee:73:c1:cd:36 (oui Unknown), length 315, xid 
0x7e4dd14c, secs 3, Flags [none] (0x)

  Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown)
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
NOAUTO Option 116, length 1: Y
MSZ Option 57, length 2: 1472
	Vendor-Class Option 60, length 36: 
"dhcpcd-7.0.6:NetBSD-8.0:amd64:x86_64"

Hostname Option 12, length 6: "zealot"
T145 Option 145, length 1: 1
Parameter-Request Option 55, length 13:
	  Subnet-Mask, Classless-Static-Route, Static-Route, 
Default-Gateway

  Domain-Name-Server, Hostname, Domain-Name, MTU
  BR, Lease-Time, RN, RB
  Option 119


When it succeed (with tcpdump in promiscuous mode):

1	2019/01/16 5:55:46 PM	info	udhcpd[1154]: sending ACK to 
255.255.255.255
2	2019/01/16 5:55:46 PM	info	udhcpd[1154]: received REQUEST from 
80:EE:73:C1:CD:36
3	2019/01/16 5:55:46 PM	info	udhcpd[1154]: sending OFFER to 
255.255.255.255 with 

Re: dhcpcd failure

2019-02-21 Thread Roy Marples

On 21/02/2019 16:18, triaxx wrote:


3    2019/01/16 5:55:46 PM    info    udhcpd[1154]: sending OFFER to 
255.255.255.255 with 192.168.0.11



16:13:56.468169 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto 
UDP (17), length 576)
     192.168.0.1.bootps > 192.168.0.11.bootpc: [udp sum ok] BOOTP/DHCP, 
Reply, length 548, xid 0x66ec8de4, Flags [none] (0x)

   Your-IP 192.168.0.11
   Server-IP 192.168.0.1
   Client-Ethernet-Address 80:ee:73:c1:cd:36 (oui Unknown)
   Vendor-rfc1048 Extensions
     Magic Cookie 0x63825363
     DHCP-Message Option 53, length 1: Offer
     Server-ID Option 54, length 4: 192.168.0.1
     Lease-Time Option 51, length 4: 86400
     Subnet-Mask Option 1, length 4: 255.255.255.0
     Default-Gateway Option 3, length 4: 192.168.0.1
     Domain-Name-Server Option 6, length 4: 192.168.0.1
     Domain-Name Option 15, length 11: "atlas.local"


What cisco says it's doing and what it's actually doing are different.
It's claiming sending offer of 192.168.0.11 to 255.255.255.255 (which is 
correct) but in reality it's unicasting to 192.168.0.11.


I don't see how any DHCP client can work with that.
You might try getting dhcpcd to send the broadcast option using the -J 
flag. That's non standard though and I doubt it will fix the issue.


Roy


Re: dhcpcd failure

2019-02-21 Thread Roy Marples

On 21/02/2019 14:58, triaxx wrote:

Le 2019-01-18 17:54, Andy Ruhl a écrit :

On Fri, Jan 18, 2019 at 2:09 AM Roy Marples  wrote:


Hi Fred

On 18/01/2019 06:05, triaxx wrote:
> I experienced a dhcpcd that cannot connect to a Cisco gateway 
through a

> fresh NetBSD 8.0. I tried dhclient which succeed.
>
> I didn't see relevant diff between MAIN and netbsd-8.
>
> I would like to send a PR but I'm interesting to know what 
informations

> could be relevant/helping.

You could try editing /etc/dhcpcd.conf and commenting out duid and using
clientid. If that still fails, try commenting out both.

If either work, complain to Cisco about their lack of RFC compliance.
Regardless, let me know the outcome please.


If it really is a Cisco compliance issue, I'd like to see a wireshark
of the failing request and the successful one for my own amusement.
This command seems to work on my mac, I'm guessing it will be similar
on NetBSD except the interface name:

tshark -i en0 -f "udp port 67 or 68" -w dhcp.pcap

Andy


tcpdump is like the observer of the Schrödinger's cat, it interfere in 
measurement.


If I run tcpdump -i re0 "udp port 67 or 68" -w dhcpcd.pcap when running 
service -v dhcpcd restart, it works fine...


Then, I can just provide the packet trace when the request succeed:

14:56:43.981194 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, 
Request from 80:ee:73:c1:cd:36 (oui Unknown), length 318
14:56:44.019208 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: BOOTP/DHCP, 
Reply, length 548
14:56:44.019338 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, 
Request from 80:ee:73:c1:cd:36 (oui Unknown), length 325
14:56:44.079055 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: BOOTP/DHCP, 
Reply, length 548
14:56:53.955162 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, 
Request from 80:ee:73:c1:cd:36 (oui Unknown), length 319
14:56:53.988890 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: BOOTP/DHCP, 
Reply, length 548


Looks to me like the DHCP client is broadcasting for a lease (ie it 
doesn't have an IP address) but the DHCP server thinks it has an IP 
address and is unicasting to something that doesn't exist?


Can you add more - to see if the client is giving any hints if it 
has an ip address?


Roy


Re: dhcpcd failure

2019-02-21 Thread triaxx

Le 2019-02-21 16:11, ignat...@cs.uni-bonn.de a écrit :

On Thu, Feb 21, 2019 at 03:58:33PM +0100, triaxx wrote:


tcpdump is like the observer of the Schrödinger's cat, it interfere in
measurement.

If I run tcpdump -i re0 "udp port 67 or 68" -w dhcpcd.pcap when 
running

service -v dhcpcd restart, it works fine...


If you don't want it to interfere - there's the option "-p"
("Don't put the interface into promiscuous mode.")

-is


This is what I need even if tcpdump -r is now extremely slow.

Thanks \o/



Re: dhcpcd failure

2019-02-21 Thread ignatios
On Thu, Feb 21, 2019 at 03:58:33PM +0100, triaxx wrote:

> tcpdump is like the observer of the Schrödinger's cat, it interfere in
> measurement.
> 
> If I run tcpdump -i re0 "udp port 67 or 68" -w dhcpcd.pcap when running
> service -v dhcpcd restart, it works fine...

If you don't want it to interfere - there's the option "-p"
("Don't put the interface into promiscuous mode.")

-is


Re: dhcpcd failure

2019-02-21 Thread triaxx

Le 2019-01-18 17:54, Andy Ruhl a écrit :

On Fri, Jan 18, 2019 at 2:09 AM Roy Marples  wrote:


Hi Fred

On 18/01/2019 06:05, triaxx wrote:
> I experienced a dhcpcd that cannot connect to a Cisco gateway through a
> fresh NetBSD 8.0. I tried dhclient which succeed.
>
> I didn't see relevant diff between MAIN and netbsd-8.
>
> I would like to send a PR but I'm interesting to know what informations
> could be relevant/helping.

You could try editing /etc/dhcpcd.conf and commenting out duid and 
using

clientid. If that still fails, try commenting out both.

If either work, complain to Cisco about their lack of RFC compliance.
Regardless, let me know the outcome please.


If it really is a Cisco compliance issue, I'd like to see a wireshark
of the failing request and the successful one for my own amusement.
This command seems to work on my mac, I'm guessing it will be similar
on NetBSD except the interface name:

tshark -i en0 -f "udp port 67 or 68" -w dhcp.pcap

Andy


tcpdump is like the observer of the Schrödinger's cat, it interfere in 
measurement.


If I run tcpdump -i re0 "udp port 67 or 68" -w dhcpcd.pcap when running 
service -v dhcpcd restart, it works fine...


Then, I can just provide the packet trace when the request succeed:

14:56:43.981194 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, 
Request from 80:ee:73:c1:cd:36 (oui Unknown), length 318
14:56:44.019208 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: BOOTP/DHCP, 
Reply, length 548
14:56:44.019338 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, 
Request from 80:ee:73:c1:cd:36 (oui Unknown), length 325
14:56:44.079055 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: BOOTP/DHCP, 
Reply, length 548
14:56:53.955162 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, 
Request from 80:ee:73:c1:cd:36 (oui Unknown), length 319
14:56:53.988890 IP 192.168.0.1.bootps > 192.168.0.11.bootpc: BOOTP/DHCP, 
Reply, length 548




Re: pkgsrc lang/go111 error

2019-02-21 Thread Benny Siegert
There is something wrong with your go14 package. Try deleting that and
installing it from source.

In general, it sounds like your binary package repository is for the wrong
architecture. Can you share your pkgin config and "uname -a" output?

Benny
Jay Patel  schrieb am Do. 21. Feb. 2019 um 09:27:

> hi all
> i am getting error on pkgsrc lang/go111 which is needed for pkglint
> and also pkgin install pkglint gives "download error: pkglint-5.6.10nb1
> size does not match pkg_summary"
> i did "make clean clean-depends" also but still throws me same error.
>
> sudo make install
> => Bootstrap dependency digest>=20010302: found digest-20180917
> ===> Checking for vulnerabilities in go111-1.11.5
> => Checksum SHA1 OK for go1.11.5.src.tar.gz
> => Checksum RMD160 OK for go1.11.5.src.tar.gz
> => Checksum SHA512 OK for go1.11.5.src.tar.gz
> ===> Installing dependencies for go111-1.11.5
> => Tool dependency bsdtar-[0-9]*: found bsdtar-3.3.2
> WARNING: [depends.mk] Unknown object format for installed package
> go14-1.4.3nb7
> => Build dependency go14-1.4*: found go14-1.4.3nb7
> => Build dependency cwrappers>=20150314: found cwrappers-20180325
> => Full dependency bash-[0-9]*: found bash-4.4.019
> => Full dependency perl>=5.0: found perl-5.28.1
> ===> Overriding tools for go111-1.11.5
> ===> Extracting for go111-1.11.5
> ===> Patching for go111-1.11.5
> => Applying pkgsrc patches for go111-1.11.5
> No such line 530 in input file, ignoring
> ===> Creating toolchain wrappers for go111-1.11.5
> ===> Configuring for go111-1.11.5
> => Replacing bash interpreter in doc/articles/wiki/test.bash
> doc/codewalk/run lib/time/update.bash misc/arm/a misc/benchcmp
> misc/cgo/fortran/test.bash misc/cgo/testgodefs/test.bash
> misc/cgo/testplugin/test.bash misc/nacl/go_nacl_386_exec
> misc/nacl/go_nacl_amd64p32_exec misc/nacl/go_nacl_arm_exec
> misc/wasm/go_js_wasm_exec src/all.bash src/androidtest.bash
> src/bootstrap.bash src/buildall.bash src/clean.bash src/cmd/go/mkalldocs.sh
> src/cmd/vendor/github.com/google/pprof/test.sh src/cmd/vendor/
> github.com/google/pprof/internal/binutils/testdata/build_mac.sh
> src/cmd/vendor/golang.org/x/sys/unix/mkall.sh src/cmd/vendor/
> golang.org/x/sys/unix/mkerrors.sh src/internal/trace/mkcanned.bash
> src/iostest.bash src/make.bash src/naclmake.bash src/nacltest.bash
> src/race.bash src/run.bash src/runtime/mknacl.sh src/syscall/mkall.sh
> src/syscall/mkerrors.sh src/syscall/mksysnum_plan9.sh.
> WARNING: [replace-interpreter] Skipping non-existent file "src/cmd/vendor/
> github.com/google/pprof/test.sh".
> => Replacing Perl interpreter in src/cmd/vendor/golang.org/x/sys/unix/*.pl
> src/net/http/cgi/testdata/test.cgi src/regexp/syntax/make_perl_groups.pl
> src/syscall/*.pl test/errchk.
> ===> Building for go111-1.11.5
> cd /home/jay/usr/pkgsrc/lang/go111/work/go/src && env
> GOROOT_BOOTSTRAP=/usr/pkg/go14 GOROOT_FINAL=/usr/pkg/go111
> /usr/pkg/bin/bash ./make.bash
> Building Go cmd/dist using /usr/pkg/go14.
> ./make.bash: line 166: 17930 Segmentation fault  (core dumped)
> GOROOT="$GOROOT_BOOTSTRAP" GOOS="" GOARCH="" "$GOROOT_BOOTSTRAP/bin/go"
> build -o cmd/dist/dist ./cmd/dist
> *** Error code 139
>
> Stop.
>
> Regards,
>
> --
> Jay Patel
> *https://www.unitedbsd.com/ *
>
>
> *usually found @ https://riot.im/app/#/room/#bsd:matrix.org
> *
>
>
>
>


pkgsrc lang/go111 error

2019-02-21 Thread Jay Patel
hi all
i am getting error on pkgsrc lang/go111 which is needed for pkglint
and also pkgin install pkglint gives "download error: pkglint-5.6.10nb1
size does not match pkg_summary"
i did "make clean clean-depends" also but still throws me same error.

sudo make install
=> Bootstrap dependency digest>=20010302: found digest-20180917
===> Checking for vulnerabilities in go111-1.11.5
=> Checksum SHA1 OK for go1.11.5.src.tar.gz
=> Checksum RMD160 OK for go1.11.5.src.tar.gz
=> Checksum SHA512 OK for go1.11.5.src.tar.gz
===> Installing dependencies for go111-1.11.5
=> Tool dependency bsdtar-[0-9]*: found bsdtar-3.3.2
WARNING: [depends.mk] Unknown object format for installed package
go14-1.4.3nb7
=> Build dependency go14-1.4*: found go14-1.4.3nb7
=> Build dependency cwrappers>=20150314: found cwrappers-20180325
=> Full dependency bash-[0-9]*: found bash-4.4.019
=> Full dependency perl>=5.0: found perl-5.28.1
===> Overriding tools for go111-1.11.5
===> Extracting for go111-1.11.5
===> Patching for go111-1.11.5
=> Applying pkgsrc patches for go111-1.11.5
No such line 530 in input file, ignoring
===> Creating toolchain wrappers for go111-1.11.5
===> Configuring for go111-1.11.5
=> Replacing bash interpreter in doc/articles/wiki/test.bash
doc/codewalk/run lib/time/update.bash misc/arm/a misc/benchcmp
misc/cgo/fortran/test.bash misc/cgo/testgodefs/test.bash
misc/cgo/testplugin/test.bash misc/nacl/go_nacl_386_exec
misc/nacl/go_nacl_amd64p32_exec misc/nacl/go_nacl_arm_exec
misc/wasm/go_js_wasm_exec src/all.bash src/androidtest.bash
src/bootstrap.bash src/buildall.bash src/clean.bash src/cmd/go/mkalldocs.sh
src/cmd/vendor/github.com/google/pprof/test.sh src/cmd/vendor/
github.com/google/pprof/internal/binutils/testdata/build_mac.sh
src/cmd/vendor/golang.org/x/sys/unix/mkall.sh src/cmd/vendor/
golang.org/x/sys/unix/mkerrors.sh src/internal/trace/mkcanned.bash
src/iostest.bash src/make.bash src/naclmake.bash src/nacltest.bash
src/race.bash src/run.bash src/runtime/mknacl.sh src/syscall/mkall.sh
src/syscall/mkerrors.sh src/syscall/mksysnum_plan9.sh.
WARNING: [replace-interpreter] Skipping non-existent file "src/cmd/vendor/
github.com/google/pprof/test.sh".
=> Replacing Perl interpreter in src/cmd/vendor/golang.org/x/sys/unix/*.pl
src/net/http/cgi/testdata/test.cgi src/regexp/syntax/make_perl_groups.pl
src/syscall/*.pl test/errchk.
===> Building for go111-1.11.5
cd /home/jay/usr/pkgsrc/lang/go111/work/go/src && env
GOROOT_BOOTSTRAP=/usr/pkg/go14 GOROOT_FINAL=/usr/pkg/go111
/usr/pkg/bin/bash ./make.bash
Building Go cmd/dist using /usr/pkg/go14.
./make.bash: line 166: 17930 Segmentation fault  (core dumped)
GOROOT="$GOROOT_BOOTSTRAP" GOOS="" GOARCH="" "$GOROOT_BOOTSTRAP/bin/go"
build -o cmd/dist/dist ./cmd/dist
*** Error code 139

Stop.

Regards,
-- 
Jay Patel
*https://www.unitedbsd.com/ *


*usually found @ https://riot.im/app/#/room/#bsd:matrix.org
*