text:
Fatal error browsing for DACP services \ {"code":-3008

Hi.. Happy new year to you and thx for developing on this project.
Hope I‘m not raising a duplicate to another issue, but encountered this tonight when trying to setup my apple tv 4gen for homebridge.
Was able to successfully pair the apple tv but then it always would end in error saying Apple TV is down.
Thx for looking into it!
[2018-1-3 00:47:08] [DACP]
[2018-1-3 00:49:08] [DACP] Starting DACP browser...
[2018-1-3 00:49:08] [DACP] Fatal error browsing for DACP services:
[2018-1-3 00:49:08] [DACP]
[2018-1-3 00:49:08] [DACP]   Error: {"code":-3008,"errno":-3008,"syscall":"getaddrinfo"}
[2018-1-3 00:49:08] [DACP]
[2018-1-3 00:49:08] [DACP] Restarting MDNS browser for DACP in 120 seconds

Just a me too. Error 3008 in a docker container with host networking.

I've updated homebridge-dacp to use the bonjour package instead of the previously used mdns package. Since I plan to release 0.8.0 next week I'm looking for early feedback if this also solves the docker issues you all have been seeing.
Could you please verify by:

uninstalling any previous version you have
installing the latest code from github: npm install -g github:grover/homebridge-dacp (You might need sudo)

and running it again? Feedback appreciated.

Hey thanks for the update. I installed from GitHub, and when start homebridge I get the same error, followed by a type error.
[2018-2-18 15:45:26] [DACP] Starting DACP browser...
[2018-2-18 15:45:26] Homebridge is running on port 51004.
[2018-2-18 15:45:26] [DACP] Fatal error browsing for DACP services:
[2018-2-18 15:45:26] [DACP]
[2018-2-18 15:45:26] [DACP]   Error: {"code":-3008,"errno":-3008,"syscall":"getaddrinfo"}
[2018-2-18 15:45:26] [DACP]
[2018-2-18 15:45:26] [DACP] Restarting MDNS browser for DACP in 120 seconds.
[2018-2-18 15:45:26] [DACP]
[2018-2-18 15:45:26] [DACP] The accessory Apple TV is down.
[2018-2-18 15:45:26] [DACP] Fatal error while talking to Apple TV:
[2018-2-18 15:45:26] [DACP]
[2018-2-18 15:45:26] [DACP]   Error: TypeError: Cannot read property 'host' of undefined
    at DacpClient._withConnection (/homebridge/node_modules/homebridge-dacp/src/dacp/DacpClient.js:205:67)
    at DacpClient.disconnect (/homebridge/node_modules/homebridge-dacp/src/dacp/DacpClient.js:48:23)
    at DacpAccessory.accessoryDown (/homebridge/node_modules/homebridge-dacp/src/DacpAccessory.js:165:22)
    at _accessories.forEach.accessory (/homebridge/node_modules/homebridge-dacp/src/index.js:116:17)
    at Array.forEach (<anonymous>)
    at DacpPlatform._onDacpBrowserError (/homebridge/node_modules/homebridge-dacp/src/index.js:115:23)
    at emitOne (events.js:116:13)
    at DacpBrowser.emit (events.js:211:7)
    at Browser._browser.on.error (/homebridge/node_modules/homebridge-dacp/src/dacp/DacpBrowser.js:37:12)
    at emitTwo (events.js:126:13)
    at Browser.emit (events.js:214:7)
    at on_resolver_done (/homebridge/node_modules/mdns/lib/browser.js:28:14)
    at next (/homebridge/node_modules/mdns/lib/browser.js:100:7)
    at /homebridge/node_modules/mdns/lib/resolver_sequence_tasks.js:160:11
    at getaddrinfo_complete (/homebridge/node_modules/mdns/lib/resolver_sequence_tasks.js:112:7)
    at GetAddrInfoReqWrap.oncomplete (/homebridge/node_modules/mdns/lib/resolver_sequence_tasks.js:120:9)
[2018-2-18 15:45:26] [DACP]
(node:2312) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 2): TypeError: Cannot read property 'host' of undefined
(node:2312) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Also I think the 3008 error is coming from src/dacp/DacpBrowser.js, but the code still seems to reference mdns (unless the lib was changed somewhere higher up the chain haha).
    const ResolverSequence = [
      mdns.rst.DNSServiceResolve(),
      'DNSServiceGetAddrInfo' in mdns.dns_sd ? mdns.rst.DNSServiceGetAddrInfo() : mdns.rst.getaddrinfo({ families: [0] }),
      mdns.rst.makeAddressesUnique()
    ];

    this._browser = mdns.createBrowser(
      mdns.tcp(ServiceName),
      { resolverSequence: ResolverSequence });

You're still using the old version. Please use the latest code from github - see the instructions above. If needed, please uninstall the old version first using npm uninstall -g homebridge-dacp.

Thanks! I actually did do that, and have the same results.. I confirmed I have the latest version by confirming the new example and changelog entries are present in the installed version. Is there another branch?
The code I was referencing is not from my machine, its still live on GitHub https://github.com/grover/homebridge-dacp/blob/master/src/dacp/DacpBrowser.js
Sorry if I've missed something..

Turns out I missed to push the change. Please try again. Sorry.

Alright got the new version installed. Definitely using bonjour instead of the mdns package now, but sadly it looks like bonjour still makes a call to getaddrinfo.
[2018-2-18 16:29:13] [DACP] Starting DACP browser...
[2018-2-18 16:29:14] Homebridge is running on port 51004.
[2018-2-18 16:29:14] [DACP] The accessory Apple TV is announced.
[2018-2-18 16:29:14] [DACP] Attempting to reconnect to Apple TV in 0.1 seconds.
[2018-2-18 16:29:14] [DACP] Connecting to Apple TV (Living.local:3689)
[2018-2-18 16:29:14] [DACP] Creating status connection to Living.local:3689
[2018-2-18 16:29:15] [DACP] Fatal error while talking to Apple TV:
[2018-2-18 16:29:15] [DACP]
[2018-2-18 16:29:15] [DACP]   Error: { error:
   { Error: getaddrinfo ENOTFOUND living.local living.local:3689
    at errnoException (dns.js:50:10)
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:92:26)
     code: 'ENOTFOUND',
     errno: 'ENOTFOUND',
     syscall: 'getaddrinfo',
     hostname: 'living.local',
     host: 'living.local',
     port: '3689' },
  response: undefined,
  options:
   { encoding: null,
     url: URL {
        href: 'http://living.local:3689/login?pairing-guid=0xD726D61018D31EDF',
        origin: 'http://living.local:3689',
        protocol: 'http:',
        username: '',
        password: '',
        host: 'living.local:3689',
        hostname: 'living.local',
        port: '3689',
        pathname: '/login',
        search: '?pairing-guid=0xD726D61018D31EDF',
        searchParams: URLSearchParams { 'pairing-guid' => '0xD726D61018D31EDF' },
        hash: '' },
     headers:
      { Accept: '*/*',
        'Viewer-Only-Client': '1',
        'Client-DAAP-Version': '3.12',
        'Client-ATV-Sharing-Version': '1.2',
        'Client-iTunes-Sharing-Version': '3.10',
        'User-Agent': 'TVRemote/186 CFNetwork/808.1.4 Darwin/16.1.0' },

nt:
      Agent {
        domain: null,
        _events: [Object],
        _eventsCount: 1,
        _maxListeners: undefined,
        defaultPort: 80,
        protocol: 'http:',
        options: [Object],
        requests: {},
        sockets: [Object],
        freeSockets: {},
        keepAliveMsecs: 1000,
        keepAlive: true,
        maxSockets: 1,
        maxFreeSockets: 1 } } }
[2018-2-18 16:29:15] [DACP]
[2018-2-18 16:29:15] [DACP] Attempting to reconnect to Apple TV in 0.2 seconds.
[2018-2-18 16:29:15] [DACP] [Apple TV] Connection to DACP server failed: { error:
   { Error: getaddrinfo ENOTFOUND living.local living.local:3689
    at errnoException (dns.js:50:10)
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:92:26)
     code: 'ENOTFOUND',
     errno: 'ENOTFOUND',
     syscall: 'getaddrinfo',
     hostname: 'living.local',
     host: 'living.local',
     port: '3689' },
  response: undefined,
  options:
   { encoding: null,
     url: URL {
        href: 'http://living.local:3689/login?pairing-guid=0xD726D61018D31EDF',
        origin: 'http://living.local:3689',
        protocol: 'http:',
        username: '',
        password: '',
        host: 'living.local:3689',
        hostname: 'living.local',
        port: '3689',
        pathname: '/login',
        search: '?pairing-guid=0xD726D61018D31EDF',
        searchParams: URLSearchParams { 'pairing-guid' => '0xD726D61018D31EDF' },
        hash: '' },
     headers:
      { Accept: '*/*',
        'Viewer-Only-Client': '1',
        'Client-DAAP-Version': '3.12',
        'Client-ATV-Sharing-Version': '1.2',
        'Client-iTunes-Sharing-Version': '3.10',
        'User-Agent': 'TVRemote/186 CFNetwork/808.1.4 Darwin/16.1.0' },

nt:
      Agent {
        domain: null,
        _events: [Object],
        _eventsCount: 1,
        _maxListeners: undefined,
        defaultPort: 80,
        protocol: 'http:',
        options: [Object],
        requests: {},
        sockets: [Object],
        freeSockets: {},
        keepAliveMsecs: 1000,
        keepAlive: true,
        maxSockets: 1,
        maxFreeSockets: 1 } } }
(node:3633) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): IllegalStateError: Backoff in progress.
(node:3633) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
[2018-2-18 16:29:15] [DACP] Connecting to Apple TV (Living.local:3689)
[2018-2-18 16:29:15] [DACP] Creating status connection to Living.local:3689
[2018-2-18 16:29:16] [DACP] Fatal error while talking to Apple TV:
[2018-2-18 16:29:16] [DACP]
[2018-2-18 16:29:16] [DACP]   Error: { error:
   { Error: getaddrinfo ENOTFOUND living.local living.local:3689
    at errnoException (dns.js:50:10)
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:92:26)
     code: 'ENOTFOUND',
     errno: 'ENOTFOUND',
     syscall: 'getaddrinfo',
     hostname: 'living.local',
     host: 'living.local',
     port: '3689' },
  response: undefined,
  options:
   { encoding: null,
     url: URL {
        href: 'http://living.local:3689/login?pairing-guid=0xD726D61018D31EDF',
        origin: 'http://living.local:3689',
        protocol: 'http:',
        username: '',
        password: '',
        host: 'living.local:3689',
        hostname: 'living.local',
        port: '3689',
        pathname: '/login',
        search: '?pairing-guid=0xD726D61018D31EDF',
        searchParams: URLSearchParams { 'pairing-guid' => '0xD726D61018D31EDF' },
        hash: '' },
     headers:
      { Accept: '*/*',
        'Viewer-Only-Client': '1',
        'Client-DAAP-Version': '3.12',
        'Client-ATV-Sharing-Version': '1.2',
        'Client-iTunes-Sharing-Version': '3.10',
        'User-Agent': 'TVRemote/186 CFNetwork/808.1.4 Darwin/16.1.0' },

nt:
      Agent {
        domain: null,
        _events: [Object],
        _eventsCount: 1,
        _maxListeners: undefined,
        defaultPort: 80,
        protocol: 'http:',
        options: [Object],
        requests: {},
        sockets: [Object],
        freeSockets: {},
        keepAliveMsecs: 1000,
        keepAlive: true,
        maxSockets: 1,
        maxFreeSockets: 1 } } }
[2018-2-18 16:29:16] [DACP]
[2018-2-18 16:29:16] [DACP] Attempting to reconnect to Apple TV in 0.4 seconds.

I assume you're running homebridge in a container as the others?
What happens if you ping living.local inside the container/in a terminal on the system that's running homebridge?

That's the issue! I can't believe I didn't think to check that.
I looked into it more and it seems like the Alpine OS does not support search domains (like local). Ugh. I had only tried to ping the IP before (which works fine as you can see below).
/homebridge # ping Living.local
ping: bad address 'Living.local'
/homebridge # ping 10.0.1.3
PING 10.0.1.3 (10.0.1.3): 56 data bytes
64 bytes from 10.0.1.3: seq=0 ttl=64 time=3.016 ms
/homebridge # nslookup google.com
Name:      google.com
Address 1: 216.58.193.78 sea15s07-in-f78.1e100.net
Address 2: 2607:f8b0:400a:800::200e sea15s07-in-x0e.1e100.net
/homebridge # nslookup Living.local
nslookup: can't resolve '(null)': Name does not resolve
nslookup: can't resolve 'Living.local': Name does not resolve

https://github.com/gliderlabs/docker-alpine/blob/master/docs/caveats.md
Would it be possible to have an optional setting for manual IP?

Ha! We're getting closer - at least for Alpine Linux. The name resolution of .local domains is not run through regular DNS, but rather through Avahi with the help of nsswitch.conf. Alpine however doesn't have this facility and the configuration is removed. As such Alpine will never be able to resolve .local domains at all.
I guess I'll have to include an IP option to resolve the Apple TV and hope that the DACP port doesn't change randomly.
Thanks @quacktacular, this is clearer now.

Just to add: The proper solution would be to enable resolution of .local domains through Avahi inside the container, but I can't help with that as I have no experience with Alpine.

I've just pushed another update with some changes from @oznu - specifically the use-referer feature was added. @quacktacular could you enable that in your config.json and try again? I'm a bit curious as @oznu also reported pairing issues that you didn't seem to have.

Hey @grover I only had a couple minutes to test this morning, but it looks like the control portion is working. Only tried the modified play plays control in Home so far.
I did not try to re-pair (using a pairing code generated from the mDNS version) this morning, but I did last night. It didn’t work with Bomjour. Asked for my pairing code onscreen the Apple TV and got stuck there.
Can try more after work.

Hey @grover Thx very much for trying to get a fix here. Highly appreciate it.
Any ETA if you're going to push 0.8 also up to NPM? Would make it a bit easier to update HomeBridge on the Synology... If too much trouble, never mind.. will try to install it manually as well and report back asap.. thx!

It's not a question of trouble, but rather: Does the version already what it should do? As such there's only one remaining issue and that's getting feedback if this is working.
Apparently the bonjour stuff does help a bit, but breaks the pairing... :(

If someone could try to pair again with the latest version and capture a tcpdump of all udp and tcp traffic in their docker container, that would help me tremendously to figure out the pairing problem with bonjour.

@grover confirmed the pairing issue is still present. Here's a tcpdump during the pairing request. Lots of garbage from other services though haha (they are running on other machines).
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on docker0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:45:20.735101 IP 172.17.0.7.40376 > 172.17.255.255.21028: UDP, length 335
17:45:23.661207 IP 172.17.0.5.43934 > 46.166.138.147.1198: UDP, length 165
17:45:23.887430 IP 46.166.138.147.1198 > 172.17.0.5.43934: UDP, length 197
17:45:24.760175 IP 172.17.0.6.9000 > 172.17.0.1.36544: Flags [.], ack 2218030938, win 237, options [nop,nop,TS val 251072905 ecr 543328446], length 0
17:45:24.760239 IP 172.17.0.1.36544 > 172.17.0.6.9000: Flags [.], ack 1, win 502, options [nop,nop,TS val 543508670 ecr 165278260], length 0
17:45:24.760248 IP 172.17.0.6.9000 > 172.17.0.1.34386: Flags [.], ack 3901500255, win 237, options [nop,nop,TS val 251072905 ecr 543328446], length 0
17:45:24.760253 IP 172.17.0.1.34386 > 172.17.0.6.9000: Flags [.], ack 1, win 1444, options [nop,nop,TS val 543508670 ecr 165278260], length 0
17:45:24.760257 IP 172.17.0.6.9000 > 172.17.0.1.38468: Flags [.], ack 1074640020, win 237, options [nop,nop,TS val 251072905 ecr 543328446], length 0
17:45:24.760272 IP 172.17.0.1.38468 > 172.17.0.6.9000: Flags [.], ack 1, win 393, options [nop,nop,TS val 543508670 ecr 165278260], length 0
17:45:24.760276 IP 172.17.0.6.9000 > 172.17.0.1.49364: Flags [.], ack 715626401, win 237, options [nop,nop,TS val 251060688 ecr 543316229], length 0
17:45:28.818573 IP 172.17.0.5.43934 > 46.166.138.147.1198: UDP, length 165
17:45:28.856011 ARP, Request who-has 172.17.0.1 tell 172.17.0.5, length 28
17:45:28.856030 ARP, Reply 172.17.0.1 is-at 02:42:e6:7a:d7:89 (oui Unknown), length 28
17:45:29.043915 IP 46.166.138.147.1198 > 172.17.0.5.43934: UDP, length 197
17:45:29.880109 ARP, Request who-has 172.17.0.6 tell 172.17.0.1, length 28
17:45:29.880243 ARP, Request who-has 172.17.0.1 tell 172.17.0.6, length 28
17:45:29.880256 ARP, Reply 172.17.0.1 is-at 02:42:e6:7a:d7:89 (oui Unknown), length 28
17:45:29.880259 ARP, Reply 172.17.0.6 is-at 02:42:ac:11:00:02 (oui Unknown), length 28
17:45:34.719807 IP 172.17.0.7.22020 > 77.72.169.210.3478: UDP, length 44
17:45:34.822001 IP 172.17.0.7.22020 > 77.72.169.210.3478: UDP, length 44
17:45:34.876159 IP 77.72.169.210.3478 > 172.17.0.7.22020: UDP, length 56
17:45:34.977890 IP 77.72.169.210.3478 > 172.17.0.7.22020: UDP, length 56
17:45:38.071260 IP 172.17.0.5.43934 > 46.166.138.147.1198: UDP, length 69
17:45:39.296124 IP 46.166.138.147.1198 > 172.17.0.5.43934: UDP, length 69
17:45:39.826822 IP 172.17.0.7.45624 > espresso.somedomain.net.49511: Flags [P.], seq 923093481:923093510, ack 3680403766, win 24576, length 29
17:45:39.843965 IP espresso.somedomain.net.49511 > 172.17.0.7.45624: Flags [.], ack 29, win 856, length 0
17:45:39.864531 ARP, Request who-has 172.17.0.1 tell 172.17.0.7, length 28
17:45:39.864563 ARP, Reply 172.17.0.1 is-at 02:42:e6:7a:d7:89 (oui Unknown), length 28
17:45:40.124156 ARP, Request who-has 172.17.0.7 tell 172.17.0.1, length 28
17:45:40.124437 ARP, Reply 172.17.0.7 is-at 02:42:ac:11:00:07 (oui Unknown), length 28
17:45:40.890315 IP 172.17.0.7.50712 > S0106b88d125b2dcd.vc.blagh.net.22000: Flags [P.], seq 658721566:658721595, ack 268932247, win 18508, options [nop,nop,TS val 309447799 ecr 2105287221], length 29
17:45:40.919008 IP S0106b88d125b2dcd.vc.blagh.net.22000 > 172.17.0.7.50712: Flags [.], ack 29, win 32767, options [nop,nop,TS val 2105328834 ecr 309447799], length 0
17:45:41.193596 IP 46.166.138.147.1198 > 172.17.0.5.43934: UDP, length 117
17:45:41.199457 IP 172.17.0.5.43934 > 46.166.138.147.1198: UDP, length 117
17:45:41.365187 IP 46.166.138.147.1198 > 172.17.0.5.43934: UDP, length 101
17:45:41.479593 IP 46.166.138.147.1198 > 172.17.0.5.43934: UDP, length 165
17:45:41.483460 IP 172.17.0.5.43934 > 46.166.138.147.1198: UDP, length 101
17:45:41.656652 IP 172.17.0.5.43934 > 46.166.138.147.1198: UDP, length 101
17:45:41.809726 IP 172.17.0.5.43934 > 46.166.138.147.1198: UDP, length 165
17:45:41.823014 IP 46.166.138.147.1198 > 172.17.0.5.43934: UDP, length 101
17:45:41.824109 IP 172.17.0.5.43934 > 46.166.138.147.1198: UDP, length 101
17:45:46.263957 ARP, Request who-has 172.17.0.5 tell 172.17.0.1, length 28
17:45:46.264509 ARP, Reply 172.17.0.5 is-at 02:42:ac:11:00:05 (oui Unknown), length 28
17:45:47.944451 IP syncthing.colintaylor.tech.443 > 172.17.0.7.45216: Flags [P.], seq 2409384327:2409384368, ack 3000950274, win 490, options [nop,nop,TS val 3503815760 ecr 210864341], length 41
17:45:47.947571 IP 172.17.0.7.45216 > syncthing.colintaylor.tech.443: Flags [P.], seq 1:42, ack 41, win 253, options [nop,nop,TS val 210924342 ecr 3503815760], length 41
17:45:48.011103 IP syncthing.colintaylor.tech.443 > 172.17.0.7.45216: Flags [.], ack 42, win 490, options [nop,nop,TS val 3503815826 ecr 210924342], length 0
17:45:50.735800 IP 172.17.0.7.40376 > 172.17.255.255.21028: UDP, length 335
17:45:51.140313 IP 172.17.0.5.43934 > 46.166.138.147.1198: UDP, length 69
17:45:51.277351 IP 46.166.138.147.1198 > 172.17.0.5.43934: UDP, length 69
17:45:58.881372 IP 172.17.0.7.22020 > 77.72.169.210.3478: UDP, length 44
17:45:58.987925 IP 172.17.0.7.22020 > 77.72.169.210.3478: UDP, length 44
17:45:59.037938 IP 77.72.169.210.3478 > 172.17.0.7.22020: UDP, length 56
17:45:59.145096 IP 77.72.169.210.3478 > 172.17.0.7.22020: UDP, length 56
17:46:01.330143 IP 46.166.138.147.1198 > 172.17.0.5.43934: UDP, length 69
17:46:01.335461 IP 172.17.0.5.43934 > 46.166.138.147.1198: UDP, length 69
17:46:02.376874 IP 172.17.0.7.41805 > google-public-dns-a.google.com.53: 31838+ AAAA? discovery-v6.syncthing.net. (44)
17:46:02.377883 IP 172.17.0.7.38813 > google-public-dns-a.google.com.53: 60835+ A? discovery-v6.syncthing.net. (44)
17:46:02.405062 IP google-public-dns-a.google.com.53 > 172.17.0.7.38813: 60835 0/1/0 (108)
17:46:02.409920 IP google-public-dns-a.google.com.53 > 172.17.0.7.41805: 31838 2/0/0 AAAA 2001:bc8:4700:2000::515, AAAA 2001:bc8:4400:2200::c39 (100)
17:46:03.504432 IP 172.17.0.5.43934 > 46.166.138.147.1198: UDP, length 165
17:46:11.363930 IP 46.166.138.147.1198 > 172.17.0.5.43934: UDP, length 69
17:46:13.472278 IP 172.17.0.5.43934 > 46.166.138.147.1198: UDP, length 69
17:46:13.912143 IP 172.17.0.6.9000 > 172.17.0.1.42396: Flags [.], ack 784783575, win 237, options [nop,nop,TS val 251122057 ecr 543377598], length 0
17:46:13.912218 IP 172.17.0.6.9000 > 172.17.0.1.41502: Flags [.], ack 1563994147, win 237, options [nop,nop,TS val 251122057 ecr 543377598], length 0
17:46:13.912428 IP 172.17.0.1.41502 > 172.17.0.6.9000: Flags [.], ack 1, win 237, options [nop,nop,TS val 543557823 ecr 184787267], length 0
17:46:13.912435 IP 172.17.0.6.9000 > 172.17.0.1.41712: Flags [.], ack 4148534688, win 237, options [nop,nop,TS val 251122057 ecr 543377598], length 0
17:46:13.912449 IP 172.17.0.1.42396 > 172.17.0.6.9000: Flags [.], ack 1, win 1444, options [nop,nop,TS val 543557823 ecr 250573404], length 0
17:46:13.912450 IP 172.17.0.1.41712 > 172.17.0.6.9000: Flags [.], ack 1, win 237, options [nop,nop,TS val 543557823 ecr 184787267], length 0
17:46:13.912455 IP 172.17.0.6.9000 > 172.17.0.1.41534: Flags [.], ack 1357819971, win 237, options [nop,nop,TS val 251122057 ecr 543377598], length 0
17:46:16.472194 ARP, Request who-has 172.17.0.5 tell 172.17.0.1, length 28
17:46:16.473053 ARP, Reply 172.17.0.5 is-at 02:42:ac:11:00:05 (oui Unknown), length 28
^C
71 packets captured
77 packets received by filter
6 packets dropped by kernel

Hi @grover,
If you can't get Bonjour working correctly without to much effort, then perhaps this solution will work (based on your master branch before you swapped to use bonjour):
https://github.com/oznu/homebridge-dacp/commit/ed998cd670707e24cf8587096d8cf64ee366895a

It keeps the mdns library in place.
Removes the mdns resolver sequence entries that were causing failures when nss_mdns was not enabled.
Use a pure javascript implementation to resolve the IP address from the .local domain just before connecting.
No need for the use-referer flag since the above library is doing a real mdns dns query and listening for the response (just like nss_mdns would be doing otherwise), so you should be able to safely transition all users onto it.

@grover @oznu the build above is working perfectly so far :)

@oznu Nice! There's just too many MDNS implementations for JS. Let me ponder over this a bit as I really wanted to get rid of the mdns library in the first place. Installing it takes ages on the lower end raspberry pis.

I've applied the branch @oznu gave in a slightly different manner adding IPv6 support for those few that are IPv6 only.
This keeps the MDNS library around for now, but I'll plan to get rid of it in a release or two.
If you could verify it again?

Works for me.

Also pairing? If so, then I'll release this version.

Pairing works for me as well. Nice work!

Hi
Thnx all for putting in all your efforts and skills. Pairing works for me now as well.. which is great. However in the Home App on iOS the Remote appears as "Not supported". Can't do anything with it.

Please see Apps and Features.

I think I have a similar problem with mdns as of today. DACP plugin v0.9.1, Homebridge v0.4.38, node v9.9.0:

[2018-4-11 23:52:35] [DACP] Failed to resolve service Peisestue.local. using IPv4 MDNS lookups.
[2018-4-11 23:52:35] [DACP] Specific error: Error: Could not resolve Peisestue.local - Query Timed Out
at Timeout.setTimeout (/usr/local/lib/node_modules/homebridge-dacp/node_modules/mdns-resolver/src/index.ts:19:14)
at ontimeout (timers.js:466:11)
at tryOnTimeout (timers.js:304:5)
at Timer.listOnTimeout (timers.js:267:5)
[2018-4-11 23:52:36] [DACP] Failed to resolve service Peisestue.local. using IPv4 MDNS lookups.
[2018-4-11 23:52:36] [DACP] Specific error: Error: Could not resolve Peisestue.local - Query Timed Out
at Timeout.setTimeout (/usr/local/lib/node_modules/homebridge-dacp/node_modules/mdns-resolver/src/index.ts:19:14)
at ontimeout (timers.js:466:11)
at tryOnTimeout (timers.js:304:5)
at Timer.listOnTimeout (timers.js:267:5)
[2018-4-11 23:52:38] [DACP] Failed to resolve service Peisestue.local. using IPv4 and IPv6 MDNS lookups.
[2018-4-11 23:52:38] [DACP] Discarding service.
[2018-4-11 23:52:38] [DACP] Specific error: Error: Could not resolve Peisestue.local - Query Timed Out
at Timeout.setTimeout (/usr/local/lib/node_modules/homebridge-dacp/node_modules/mdns-resolver/src/index.ts:19:14)
at ontimeout (timers.js:466:11)
at tryOnTimeout (timers.js:304:5)
at Timer.listOnTimeout (timers.js:267:5)
[2018-4-11 23:52:39] [DACP] Failed to resolve service Peisestue.local. using IPv4 and IPv6 MDNS lookups.
[2018-4-11 23:52:39] [DACP] Discarding service.
[2018-4-11 23:52:39] [DACP] Specific error: Error: Could not resolve Peisestue.local - Query Timed Out
at Timeout.setTimeout (/usr/local/lib/node_modules/homebridge-dacp/node_modules/mdns-resolver/src/index.ts:19:14)
at ontimeout (timers.js:466:11)
at tryOnTimeout (timers.js:304:5)
at Timer.listOnTimeout (timers.js:267:5)

authors: AntoGi bohtho grover oznu quacktacular

repo: grover/homebridge-dacp


text:
Override use of http_proxy env. variable

Hello, we have an dotnet core application which has two clients, one for HTTP requests and other for gRPC. We need to proxy requests from both clients where each of protocols (HTTP vs. HTTP/2) needs to go through different proxy (we are using linkerd proxy as a service mesh and it is not able to process two different protocols on the same port). We are using C# gRPC v. 1.6.1 in docker container based on microsoft/aspnetcore:2.0 image.
I know that we can use http_proxy env. variable to set the proxy for gRPC (https://github.com/grpc/grpc/blob/master/doc/environment_variables.md). It works, but there is an issue: all other third-party libraries which uses HTTP (for example OpenID) accept the same http_proxy env. var. and use it as a proxy. Therefore, we are not able to proxy HTTP and HTTP/2 in the same time, each through different proxy address.
I didn't find any functionality how to set gRPC proxy through C# API. Is there any? I found opened issue #12815 about it. They also refer to System.Net.WebRequest.DefaultWebProxy which I tried to set and I need to confirm that it does not effect HTTP/2 communication.
I see two possible solutions now:

Implement API feature to set gRPC proxy and to ignore value in http_proxy env. var.
Maybe easier to implement: Prefer value in grpc_proxy environment variable (or any other which is more suitable) over http_proxy one.

This is really a show stopper for us. Would it be possible to take a look at it, please? Thank you.

I can use Environment.SetEnvironmentVariable("no_proxy", <http_proxy_host>); in client's current process. So it solves the issue.

source: gharchive/issue

repo: grpc/grpc

license_type: permissive

license_source: github-api


text:
gRPC C++ does not build under MacOS

What version of gRPC and what language are you using?
1.26.0-dev C++
What operating system (Linux, Windows,...) and version?
MacOS 10.14.6 (Mojave)
What runtime / compiler are you using (e.g. python version or version of gcc)
gcc Apple LLVM version 10.0.1
What did you do?
$ git clone -b $(curl -L https://grpc.io/release) https://github.com/grpc/grpc
$ cd grpc
$ git submodule update --init
$ LIBTOOL=glibtool LIBTOOLIZE=glibtoolize make
What did you expect to see?
No errors
What did you see instead?
In file included from src/compiler/cpp_generator.cc:21:
In file included from ./src/compiler/cpp_generator.h:29:
In file included from ./src/compiler/config.h:22:
In file included from ./src/compiler/config_protobuf.h:22:
include/grpcpp/impl/codegen/config_protobuf.h:30:10: fatal error:
'google/protobuf/message.h' file not found
#include <google/protobuf/message.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
Anything else we should know about your project / environment?
protobuf has NOT been installed yet.
From the documentation:
"If you compile gRPC from source, as described below, the Makefile will automatically try compiling the protoc in third_party if you cloned the repository recursively and it detects that you do not already have 'protoc' compiler installed."
Apparently this is not happening.

Also:
$ cd grpc/third_party/protobuf
$ sudo make install   # 'make' should have been run by core grpc
This does not work:
make: *** No rule to make target `install'.  Stop.

There's insufficient information from this to make a useful informed diagnostic. Could you share more of your log? Also, try adding V=1 to the make invocation, so we can see what's going on.

Here's the step that's failing, using V=1 (is this enough)?
mkdir -p dirname /Users/dhait/CLionProjects/grpc/objs/opt/src/compiler/cpp_generator.o
c++ -std=c++11 -stdlib=libc++ -Wnon-virtual-dtor   -Ithird_party/googletest/googletest/include -Ithird_party/googletest/googlemock/include -Ithird_party/boringssl/include -Ithird_party/address_sorting/include -g -Wall -Wextra -Werror -Wno-long-long -Wno-unused-parameter -DOSATOMIC_USE_INLINED=1 -Wno-deprecated-declarations -Ithird_party/nanopb -DPB_FIELD_32BIT -O2 -Wframe-larger-than=16384 -fPIC -I. -Iinclude -I/Users/dhait/CLionProjects/grpc/gens -I/usr/local/include -DNDEBUG -DINSTALL_PREFIX="/usr/local"   -I/usr/local/include -DCARES_STATICLIB -I/usr/local/include -pthread -I/usr/local/include -MMD -MF /Users/dhait/CLionProjects/grpc/objs/opt/src/compiler/cpp_generator.dep -c -o /Users/dhait/CLionProjects/grpc/objs/opt/src/compiler/cpp_generator.o src/compiler/cpp_generator.cc
In file included from src/compiler/cpp_generator.cc:21:
In file included from ./src/compiler/cpp_generator.h:29:
In file included from ./src/compiler/config.h:22:
include/grpcpp/impl/codegen/config_protobuf.h:25:10: fatal error:
'google/protobuf/stubs/common.h' file not found
#include <google/protobuf/stubs/common.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
make: *** [/Users/dhait/CLionProjects/grpc/objs/opt/src/compiler/cpp_generator.o] Error 1

So this seems to indicate that the Makefile found a version of protobuf on your system, but it's mis-installed for some reasons.
I would recommend either purging your system from that version of protobuf, or trying to install the latest version cleanly.

Also, you can try with LIBTOOL=glibtool LIBTOOLIZE=glibtoolize HAS_SYSTEM_PROTOBUF=false make from a clean repository to try and force it to use the builtin version.

I did have a previous install of protobuf, but I removed all the protobuf files from /usr/local/bin (including protoc), /usr/local/include/google, and /usr/local/lib.  So something must still be causing make to think that protobuf is still there.  Adding HAS_SYSTEM_PROTOBUF allows it to build cleanly.
I would be curious if this is a bug, or perhaps the HAS_SYSTEM_PROTOBUF flag should be more prominently documented.
Thank you for your help.

authors: dhait nicolasnoble


text:
Error: Could not locate the bindings file. Tried:

Am trying to compile node example,but am getting below error.
Error: Could not locate the bindings file. Tried:
Thankyou you.

Can you be more specific about what you did to get that failure?

Thank you for replaying.
Actually i am trying to run grpc  node examples,when i try to run that examples am getting above error.
The secenerios is:
sudo node greeter_server.js
/home/prasanna/prasanna/RPC/grpc/node_modules/bindings/bindings.js:91
throw err
^
Error: Could not locate the bindings file. Tried:
→ /home/prasanna/prasanna/RPC/grpc/build/grpc_node.node
→ /home/prasanna/prasanna/RPC/grpc/build/Debug/grpc_node.node
→ /home/prasanna/prasanna/RPC/grpc/build/Release/grpc_node.node
→ /home/prasanna/prasanna/RPC/grpc/out/Debug/grpc_node.node
→ /home/prasanna/prasanna/RPC/grpc/Debug/grpc_node.node
→ /home/prasanna/prasanna/RPC/grpc/out/Release/grpc_node.node
→ /home/prasanna/prasanna/RPC/grpc/Release/grpc_node.node
→ /home/prasanna/prasanna/RPC/grpc/build/default/grpc_node.node
→ /home/prasanna/prasanna/RPC/grpc/compiled/5.4.1/linux/ia32/grpc_node.node
at bindings (/home/prasanna/prasanna/RPC/grpc/node_modules/bindings/bindings.js:88:9)
at Object. (/home/prasanna/prasanna/RPC/grpc/src/node/src/client.js:54:31)
at Module._compile (module.js:397:26)
at Object.Module._extensions..js (module.js:404:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Module.require (module.js:353:17)
at require (internal/module.js:12:17)
at Object. (/home/prasanna/prasanna/RPC/grpc/src/node/index.js:48:14)
at Module._compile (module.js:397:26)

You should run npm install first.

yes i did that one,and  i installed all dependency library by using npm install.

The example has been modified in a way that may fix this problem. If you run npm install in the examples/node directory, it should install everything properly.

@harishabr please let us know if that hasn't solved your issue so we can re-open accordingly.

authors: harishabr murgatroid99 nicolasnoble


text:
tests.py.test._later_test.LaterTest.test_simple_delay (opt,python,macos)

https://grpc-testing.appspot.com/job/gRPC_pull_requests/7188/config=opt,language=python,platform=macos/console
The BUILDPONY might be on someone else's desk, but the BUILDPONY is omnipresent.
Filed this issue despite it being on a PR as it's a pure Python test as far as I can tell, and the relevant change only touched C code.

Still see this happening on master: https://grpc-testing.appspot.com/job/gRPC_master/16208/config=opt,language=python,platform=macos/console
Running       _later_test.LaterTest.test_simple_delay
FAILURE       _later_test.LaterTest.test_simple_delay
4 tests finished:
	3 successful
	1 unsuccessful
	0 skipped
	0 expected failures
	0 unexpected successes
Interrupted Tests:
	[]

Errors/Failures:
_later_test.LaterTest.test_simple_delay
traceback:
Traceback (most recent call last):
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py", line 331, in run
    testMethod()
  File "/jenkins/workspace/gRPC_master/config/opt/language/python/platform/macos/src/python/grpcio/tests/unit/framework/foundation/_later_test.py", line 57, in test_simple_delay
    self.assertFalse(computation_future.done())
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py", line 418, in assertFalse
    raise self.failureException(msg)
AssertionError: True is not false

stdout:

stderr:

Unexpected successes: []
Test failure
I0331 13:19:00.689925000 140735211819776 init.c:210] grpc_shutdown(void)

FAILED: py.test._later_test.LaterTest [ret=1, pid=11199]

Similar error but on LaterTest.test_cancel
https://grpc-testing.appspot.com/job/gRPC_master/16566/config=dbg,language=python,platform=linux/testReport/junit/(root)/tests/py_test__later_test_LaterTest/

Haven't seen in a while.

authors: soltanmm stanley-cheung


text:
Regain Sanity

#10977 broke pylint sanity check due to long lines

@ncteisen - Thanks!

source: gharchive/pull-request

authors: makdharma ncteisen


text:
Mark error code details as global

In the Ruby implementation, the code initializes a hash and then initializes a bunch of strings before assigning the hash to a constant.
In some cases, the string allocations trigger a GC event, which will clear the hash because nothing references it.
Further down the line, the hash is frozen, but it makes Ruby processes segfault when it's been collected by GC.
This PR marks it as global to hint the GC to leave it alone.
Thank you @fbogsany for pointing me in the right direction.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

I signed it!

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

jenkins: this is ok to test

@apolcyn I can't check the failures :-(
Also, I've already signed the CLA, but it's still tagged incorrectly.

test failures look like unrelated flakes.
But wondering what ruby version did you see this on? Were you able to manually trigger GC during that require statement? It's a small change and it looks right to me, but it would be nice to be able to verify.

@apolcyn We saw it on 2.3.3. I really wish there was a test I could add, but it happens super infrequently, and we'd basically need a hook between the moment the hash gets initialized and when the values get set. In other words, I don't know how to get this done and verify it without a hook in the C extension that would only be there for the sake of testing.

lgtm, but tests have gone stale, so waiting for a re-run

Looks much better. Want me to rebase master into this branch?

rebase isn't needed since there's no conflicts

:+1:

infrastructure failure on mac tests

authors: andremedeiros apolcyn grpc-jenkins grpc-testing


text:
Fix interop_matrix commands for csharp v1.2.5

The build destination has changed since v1.2.5,
commands are the same as csharp__master, but end with bin/Debug instead of bin/Debug/net45

****************************************************************

libgrpc.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences

Only influences interop matrix tests and those are not being tested per PR (and I've tested locally). Merging.

authors: grpc-testing jtattermusch


text:
run_tests: keep longer logs from individual test cases

we now have fewer failures, so we can afford to keep more error results
longer test outputs make all the needed info easily accessible in result store (right now the results are usually trimmed).

****************************************************************

libgrpc.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences


text:
Use dummy root node in watcher list

Extracted from https://github.com/grpc/grpc/pull/18021. This change is desirable in that PR because connectivity change notification is conditional in that PR. Adding a dummy root makes the node deletion easier.
Also, this makes grpc_connectivity_state_notify_on_state_change() simpler for the same reason.

I need more context here, since I haven't yet looked at #18021.  What do you mean by "connectivity change notification is conditional in that PR"?  And what does this representation have to do with that, given that there should be exactly the same functionality either way?
This approach seems strictly worse, since it isn't really any more efficient, but it does waste a few pointers' worth of memory for each channel.  (In fact, I could have sworn that this is the way this code used to be and that we changed it to avoid this recently, although I can't find the PR in which that happened, so I may be thinking of something else.)

We need to keep watching the LB channel until it's shut down. Also, if the LB channel changes from READY state to READY state, we should catch this change and restart the LB call because the LB channel may have been updated with some new balancer addresses.
It's said in our code that the parent LB policy will catch such connectivity change https://github.com/grpc/grpc/blob/master/src/core/ext/filters/client_channel/lb_policy/xds/xds.cc#L1244. But in reality, I don't think this is happening, because the state tracker will do nothing if the new state is the same with the old one.
I guess we have this false statement because our test is hiding this issue. In our test, the LB call is ended by the test before the LB channel updatehttps://github.com/grpc/grpc/blob/master/test/cpp/end2end/grpclb_end2end_test.cc#L1070. Then, the parent policy tries to restart an LB call because the previous one fails. The LB channel state change (from READY to READY) doesn't trigger the connectivity closure to run.
So, we need a way to let the tracker to process identical state update if the watcher wants that. The update will trigger the closure to run only if the watcher wants that, so we will remove the watcher from the watcher list conditionally. With this PR, it's easier to do that.
I think the code simplicity over weighs the additional memory in this case. But I don't have strong opinion about this.

It's said in our code that the parent LB policy will catch such connectivity change https://github.com/grpc/grpc/blob/master/src/core/ext/filters/client_channel/lb_policy/xds/xds.cc#L1244. But in reality, I don't think this is happening, because the state tracker will do nothing if the new state is the same with the old one.

I think you're right about that problem.  I've noticed that comment a couple of times recently myself, and it does look wrong, but I hadn't had time to look into it.
Looking into the history of this now, it looks like the code was originally added way back in #11159, when we first added support for LB policy updates (prior to that, we recreated the LB policy upon each new update from the resolver).  In that original code, we always started the connectivity watch from state INIT (which no longer exists; that state was originally added at my suggestion in #8666, but I subsequently realized that that was a bad idea, and it was removed in #12878), in which case the comment was true: we would always get a callback for state READY, because we always started the watch from a different state.  However, when the epoll1 polling engine was added, there wound up being a timing bug here, and we attempted to fix this in #11965 by starting the watch from the current state instead of from a fixed state.  Although we didn't notice at the time, I think this is when the code stopped providing the guarantee that it would always be invoked when the channel reached state READY.
I suspect that we could get back to the original behavior simply by starting the watch from IDLE state, which would ensure that we do get a callback when it changes to state READY.  If this turns out to trigger the epoll1 timing bug again (although it may not, since a lot has changed since #11965), then we can find a better way to fix that.
That having been said, let me take a step back and ask a more basic question: Do we actually need this connectivity state watch in the first place?  It seems like the original intent of doing this was to ensure that we restart the balancer call if the balancer address that the call is currently talking to is removed by the resolver.  But it's not immediately obvious to me why we need to do that.  If the old balancer is still working, then we can stay connected to it, even if it's no longer in the server list.  If it stops working, then the current balancer call will fail, and we will start a new one automatically, even without this watch.  So one possibility here would be to simply remove this watch.  (Also, note that even if we fix this code, it causes some unnecessary churn, because it restarts the balancer call unconditionally, not just when the address that the current call is talking to is removed from the list.  So this may be another good reason to eliminate it.)  So we should probably talk to the load balancing team to see whether this is something we actually need to do.

So, we need a way to let the tracker to process identical state update if the watcher wants that. The update will trigger the closure to run only if the watcher wants that, so we will remove the watcher from the watcher list conditionally. With this PR, it's easier to do that.

I don't think this is necessary; I think we can more easily solve this by simply starting the watch from a fixed state like IDLE.
It's not clear to me that this PR yields any benefits.  The new code doesn't seem any simpler to me, and there is some memory waste, so I think we should stick with the current implementation.

I suspect that we could get back to the original behavior simply by starting the watch from IDLE state, which would ensure that we do get a callback when it changes to state READY. If this turns out to trigger the epoll1 timing bug again (although it may not, since a lot has changed since #11965), then we can find a better way to fix that.

I actually tried starting the watch from IDLE, but then the notification closure would be run immediately after we start watching if the current channel state is READY. Then it enters a dead loop.

That having been said, let me take a step back and ask a more basic question: Do we actually need this connectivity state watch in the first place?

I think the intent of this watch is to restart the LB call if the LB channel is ready after being updated. That implies that we prefer contacting some new balancer even if the call to the old balancer is still working.
That's what the grpclb code has been doing (more accurately: has been thinking it's doing), although we need to talk with the grpclb folks to confirm that's still the expected behavior. Say if we do want that behavior, then we need to watch the LB channel with the ability to catch update from READY to READY.

It's not clear to me that this PR yields any benefits. The new code doesn't seem any simpler to me, and there is some memory waste, so I think we should stick with the current implementation.

I think the code is simpler because we don't need to worry about whether we are deleting the first node in the list. That's basically the reason why we have such sentinel in any linked list. It trades memory for simplicity.

I just realized that if we want to contact some new balancer after update, it means the current balancer address is not in the update because pick_first will stick to the already selected subchannel. And if the current balancer address is not in the update, it probably means it's unhealthy and the current LB call will end soon..

I think we've agreed in our offline discussion that we no longer need to try to restart the balancer call in this case, so we can just get rid of the code that motivated this change.

I think the code is simpler because we don't need to worry about whether we are deleting the first node in the list. That's basically the reason why we have such sentinel in any linked list. It trades memory for simplicity.

I think sentinels are messy.  Checking whether a value is null is not hard and is ultimately much more intuitive than a sentinel value, since the underlying representation is much more natural for C++.  I never write code that uses sentinels, and I've been known to rip them out whenever I'm touching existing code that uses them (one of my earliest PRs after joining grpc-team did this; see #7616).

authors: AspirinSJL markdroth


text:
Switch registered calls to a map and check the map before inserting

Fixes #21563 by changing the registration mechanism in grpc_channel_register_call . Note that this method is only used by the C++ binding; all the other language bindings do not use registered calls.
Longer term - we may want to consider removing grpc_channel_register_call from the core surface if only the C++ API is using it.

Not ready for review yet. Some ASAN issues etc.

Longer term - we may want to consider removing grpc_channel_register_call from the core surface if only the C++ API is using it.

In retrospect, I don't think this is actually a safe change. It will be fine for our code generation, but not if somebody else uses this surface API. Making a change like this should definitely be done after desurfacing the API.

I will rewrite this PR to use only additive API and will later write a grfc to desurface the existing grpc_channel_register_call

In retrospect, this is a legit use of the grpc_channel_register_call API which clearly says that method and host must remain "alive" for the duration of the server. Technically, that makes no sense: it should say "for the duration of the channel" so we can fix that as a typo without breaking the API.

@markdroth : this is ready for review. Thanks in advance and sorry for the confusing and contradictory comments above.

This is ready for re-review. Thanks!

@markdroth Ping since it's Tuesday.....

Thanks for the review! Looks like I need to do a quick rebase to catch the latest changes upstream and will merge once tests pass.

Is there a chance, that this will be backported to 1.28?


text:
[interop] Add grpc-java 1.59.0 to client_matrix.py

@sergiitk

Please run the adhoc test.

Successful adhoc test: http://sponge2/0c63acd2-3712-4b2c-b60b-b662d6368e11

Ooops, I thought I approved it.

authors: sergiitk temawi


text:
php: remove callable type hint from BaseStub->_simpleRequest()

The "callable" type hint in PHP appears to be broken in PHP 5.6.6. It feels unnecessary here, as the required code is generated.
See https://bugs.php.net/bug.php?id=61467&edit=1 for more info.
/cc @Phraxos

Can one of the admins verify this patch?

Can one of the admins verify this patch?

For background, we're getting:
Argument 3 passed to Grpc\BaseStub::_simpleRequest() must be callable, string given, called in /var/www/current/protobufs/httpobj/httpobj.php on line 455 and defined
/var/www/current/vendor/grpc/grpc/src/php/lib/Grpc/BaseStub.php:219
...
with a third argument of the form seen in examples/helloworld.php
return $this->_simpleRequest('/helloworld.Greeter/SayHello', $argument, '\helloworld\HelloReply::deserialise', <---------- [this third parameter]
$metadata, $options);

/cc @jtattermusch @jboeuf @stanley-cheung for review. Thank you! :smiley:

LGTM. Thanks for the contribution!

authors: grpc-jenkins parkr sayrer stanley-cheung


text:
[BUG] Validations fail for the following crons

Describe the bug
Running validations on the following crons return exceptions:

0 8 * ? 2-6 *
0 11-23/2 * * ? *
0 11-23/4 ? * 2-6 *
0 11-23/2 * * ? *
0 0 1 1-12/3 ? *

To Reproduce
Run AWSCronExpressionValidator.validate for any of the provided crons.
Expected behaviour
All provided crons should be valid
Additional context
I am using aws-cron-expression-validator: "1.0.11"

Maybe it is the number-number format?
2-6, 11-23/2, 11-23/4, 11-23/2and1-12/3` ?

Hi @dsalaza4,
Thank you for finding those problems and letting me know.
Except for the first one, I think you are right, it should be possible to precede a / with a range.  I think in your second example, the 11-23/2 in the Hour field means "every second hour between 11 and 23" (i.e. 11, 13, 15, 17, 19 & 23). I've updated the code and added your examples as test cases. If you could try the latest version, 1.1.2, that would be great please.
For the first example, 0 8 * ? 2-6 *, I think the validator is correctly identifying it as an invalid expression. I'm wondering if you have the third and fourth fields swapped around?
┌───────────── 0   Minute
│ ┌─────────── 8   Hour
│ │ ┌───────── *   Day-of-month
│ │ │ ┌─────── ?   Month
│ │ │ │  ┌──── 2-6 Day-of-week
│ │ │ │  │  ┌─ *   Year
0 8 * ? 2-6 *

The exception says Invalid combination of day-of-month '*' and day-of-week '2-6'. One must be a question mark (?), which I think matches the AWS notes; "You can't specify the Day-of-month and Day-of-week fields in the same cron expression. If you specify a value or a * (asterisk) in one of the fields, you must use a ? (question mark) in the other.". Perhaps you have the * in the Day-of-month field swapped with the ? in the Month field?
Many thanks,
Grum.

Hey @grumBit,
Thank you so much for such an amazing response!
The first cron was indeed incorrect.
I just tested all the provided cases again and everything went just fine.
Thank you!

Fantastic! Thanks @dsalaza4. Let me know if anything else crops up 😃

Hi  @dsalaza4,
It may not affect you, however, after fixing the bug you found, I found another one, which is fixed in v1.1.3. So, you might want to upgrade to it.
Cheers!

@grumBit Thank you so much for the heads up!

license: MIT


text:
Reduce fork overhead for improved performance

Eliminate the overhead of running two extra processes for every item checked by moving the cat and head functionality into the grep command. Quick unscientific tests seem to suggest a 2.5x-3.5x speedup.

@rorybrowne, thanks a lot for contribution, looks and performs much better now!
:+1:

authors: grundic rorybrowne

repo: grundic/zabbix-disk-performance

license: mit

license_source: bigquery


text:
Fail to handle files names with more than one dot (itaas.player.min.js)

My grunt task setup:
var compress = {
        options: {
            mode: 'gzip'
        }
    };
    compress[client] = {
        files: [
            {
                expand: true,
                cwd: '<%= config.release %>',
                src: ['**/*.+(js|css)'],
                dest: '<%= config.release %>',
                ext: '.gz'
            }
        ]
    };

I've configured to compress all js and css files. One of the folders have the following files:
itaas.players-2.1.4.min.css
itaas.players-2.1.4.min.js
However, compress generated only 1 file named: itaas.gz.
Looking at the output:
Created release/amazon/libs/players/itaas.gz (19912 bytes)
Created release/amazon/libs/players/itaas.gz (152282 bytes)

This happens for several files that have more than one dot in the name.

See dot http://gruntjs.com/configuring-tasks#files

dot = true doesn't work:
var compress = {
        options: {
            mode: 'gzip'
        }
    };
    compress[client] = {
        files: [
            {
                dot: true,
                expand: true,
                cwd: '<%= config.release %>',
                src: ['**/*.+(js|css)'],
                dest: '<%= config.release %>',
                ext: '.gz'
            }
        ]
    };

authors: JobaDiniz vladikoff

repo: gruntjs/grunt-contrib-compress


text:
GroupName is only supported in default VPC and EC2-classic

If you look at the description for GroupName field on DeleteSecurityGroup, it will indicate that you should only set it for EC2-classic or the default VPC, neither of which we are using with EKS. Setting this seems harmless but it actually causes an error if there is no Default VPC in the account:

ERROR: VPCIdNotSpecified: No default VPC for this user. GroupName is only supported for EC2-Classic and default VPC.
status code: 400, request id: 6b6221a7-f5ba-4700-b46a-56cb6d88e44d

https://docs.aws.amazon.com/sdk-for-go/api/service/ec2/#DeleteSecurityGroupInput

Build passed, so merging in!

repo: gruntwork-io/kubergrunt


text:
Add sunset notice to readme

adds sunset notice to readme
removes "maintained by gruntwork" badge

Just noticed the tests are failing to install the gruntwork-tooling. May be worth creating a separate issue to look into that.

authors: Etiene ina-stoyanova

repo: gruntwork-io/terraform-google-gke


text:
Can terratests be run against existing AWS resources created with terraform?

Are there any examples to accomplish testing  with terratest the AWS infrastructure that was created before and now is being updated? How can terratest know about the details of the existing infrastructure?

I don't think we have examples of it, but it would be more or less identical to the examples out there, such as the hello world example, except perhaps instead of calling terraform.InitAndApply, you'd only call terraform.Init, as the infra is already  deployed.

I'm new to terratest, but it seems to pick up the existing state file. And then go ahead and delete everything in it, and recreate, and then delete again.

Terratest runs the Terraform code you tell it to run! So if you pointed it at a Terraform module that had a backend configured with a state file, then it'll run against that state. If you want to override that, see the backend config options in terraform.Options.

Yeah, you would need to create and store multiple tfstate files if you want to test entire infra without affecting existing stack. You would also need to namespace the actual AWS resources to avoid collision.

authors: artisood brikis98 tonyszhang

repo: gruntwork-io/terratest


text:
Скласти інтро

Составить интро (введение), где в 2-4 предложениях описать, что ти делаешь, что нравится делать, что хочется делать лучше, что важно делать, и т.д.

you did it!!!!

repo: grwadl/homepage


text:
🛑 IM-Dashboard is down

In 7085a1c, IM-Dashboard (https://appsgrycap.i3m.upv.es:31443/im-dashboard/login) was down:

HTTP code: 0
Response time: 0 ms

Resolved: IM-Dashboard is back up in df66a90.

repo: grycap/status


text:
🛑 kinderundjugendtanz.at is down

In 882312c, kinderundjugendtanz.at (https://kinderundjugendtanz.at) was down:

HTTP code: 0
Response time: 0 ms

Resolved: kinderundjugendtanz.at is back up in 61f6d0e.


text:
🛑 volkstanz.st is down

In d6ac181, volkstanz.st (https://volkstanz.st) was down:

HTTP code: 0
Response time: 0 ms

Resolved: volkstanz.st is back up in 7f042f4.


text:
🛑 bretterhofer.at is down

In acc7bb1, bretterhofer.at (https://bretterhofer.at) was down:

HTTP code: 0
Response time: 0 ms

Resolved: bretterhofer.at is back up in 1e9ebde.


text:
🛑 kinderundjugendtanz.at is down

In 90c83b1, kinderundjugendtanz.at (https://kinderundjugendtanz.at) was down:

HTTP code: 0
Response time: 0 ms

Resolved: kinderundjugendtanz.at is back up in c1353f8.


text:
ベクトルタイルの404エラーをハンドリングできない

XMLHttpRequest でベクトルタイルを扱っています。
タイルが存在する場合にはレスポンスに Access-Control-Allow-Origin ヘッダが付与されているので、ドメインをまたぐリクエストであっても問題なくさばけています。
http://cyberjapandata.gsi.go.jp/xyz/experimental_anno/15/29108/12907.geojson
他方、タイルが存在しない場合には 404 エラーが返ってくるのですが、この場合 Access-Control-Allow-Origin ヘッダが付与されていません。受信側では javascript のコンテクストに伝達される以前に制約が掛けられてしまうのでアプリケーションでのエラーハンドリングができない状況です。
http://cyberjapandata.gsi.go.jp/xyz/experimental_anno/15/29106/12907.geojson
エラータイル表示をしたい場合や、すべてのタイルリクエストを受信してから処理実行、のような場合にちょっと困りそうです。なお、「実験」のための優先度の低い要望とお考えください。

ご連絡ありがとうございます。
404エラーの場合にもヘッダが付与されるように設定してみました。
ご確認いただけますと幸いです。

確認しました。
404エラーの場合でも XMLHttpRequest でエラーハンドリングができるようになりました。
ご対応ありがとうございます。
参考） 注記タイルを例に、地図上に Status Code と応答時間を表示するデモ
https://github.com/frogcat/gsi-vector-ping

authors: frogcat johofukyu

repo: gsi-cyberjapan/gsimaps


text:
Not picking up config?

Probably something I did wrong though I followed a guide.
// craco.config.js
const path = require("path")
module.exports = {
  output: {
    chunkFilename: '[id]CCCCCC.js',
    path: path.resolve(__dirname, 'dist')
  }
}

//package.json
  "scripts": {
    "build": "craco build",
  },

Then I tried to build it:
C:\dev\projects\myApp>npm run build

> myApp build C:\dev\projects\myApp
> craco build

  540.62 KB  build\static\js\main.97530591.chunk.js
  333.75 KB  build\static\js\2.4b6e91f0.chunk.js
  7.44 KB    build\static\css\main.0eb1ccc4.chunk.css
  775 B      build\static\js\runtime-main.9d14031a.js

But it still gets built into the build folder, not dist, and neither do chunks have CCCCCC in the name. I tried few other settings like filename, but also not picking up.

Hi @mraak.
Modifying paths is not supported by CRACO.
Thank you,
Patrick

If you still want to do it, I suggest you use override the webpack config manually using:
module.exports = {
    webpack: {
        configure: { /* Any webpack configuration options: https://webpack.js.org/configuration */ },
        configure: (webpackConfig, { env, paths }) => { return webpackConfig; }
    }
}

The following should work:
module.exports = {
    webpack: {
        configure: {
               output: {
                    chunkFilename: '[id]CCCCCC.js',
                    path: path.resolve(__dirname, 'dist')
                 }
        }
    }
}

More info at: https://github.com/gsoft-inc/craco/blob/master/packages/craco/README.md#configuration-overview

@patricklafrance So I guess I can't either prevent the splitting? The original intent was to use CRACO to build everything in only a single file - bundle.js or similar.

@patricklafrance The solution above is doing something but breaking the build. In any case what I wanted to override the config for was to prevent the splitting into chunks.
Tinkering with this now, making some progress, but do you happen to know exact config to prevent splitting?
module.exports = {
  webpack: {
    configure: {
      output: { filename: "static/js/[name]-build.js" },
      optimization: {
        runtimeChunk: false,
        splitChunks: {
          cacheGroups: {
            default: false,
          },
        },
      },
    },
  },
}

Hi @mraak
What is the error?
Does the error is related to craco or a bad webpack config?
If you need to use a different config base on the build /env, you can configure a different craco config file for dev or build script or you can leverage craco env utilities: https://github.com/gsoft-inc/craco/blob/master/packages/craco/README.md#when-whendev-whenprod-whentest

@patricklafrance
const path = require("path")
module.exports = {
  webpack: {
      configure: {
             output: {
                  chunkFilename: '[id]-ASDF.js',
                  path: path.resolve(__dirname, 'dist')
             }
      }
  }
}

So applying this output config results in the following.

First the build folder gets created and CRA starts building there
Then also the dist folder gets created
Then the build fails with the following error:
ENOENT: no such file or directory, open 'C:\dev\projects\myApp\build\0-ASDF.js'
It looks like build/static/js has no chunks and no webpack compiled js, these went into dist root

So obviously this output config only deals with the chunk compilation, not the whole CRA output.

Hi @mraak
I am not sure how to help you on this.
The goal of CRACO is to give you the ability to update the webpack config of CRA which seems to be fine at the point.
I guess you need to update some other pieces of the webpack config to make this work but I can't tell which one.
Patrick

Yep, agreed. It's the tweaking of config that has to be figured out.

module.exports = {

webpack: {

configure: {

  output: {

    path: path.resolve(__dirname, 'dist'),

    filename: '[name].js',

  },

},

},
}

@mraak
how to fix?

authors: bihongbin3027 mraak patricklafrance wangweijia

repo: gsoft-inc/craco


text:
Floating

How do you do something like floats in CSS?
http://jsfiddle.net/9LfM3/
How do you avoid overlap on an arbitrary number of items where they each desire to be as top as possible followed by as left as possible giving priority based on child order?

In new gss you can just use floats and bind to computed/intrinsic x/y of those elements.
To avoid overlap with GSS-positioned blocks, you can use cushions, which make the >= constants

authors: Inviz yeknomerif

repo: gss/engine


text:
Clean up travis script

cc @EPashkin @sdroege

:+1:

authors: GuillaumeGomez sdroege

repo: gtk-rs/cairo


text:
Replace once_cell with std

Currently, despite requiring 1.70, we are still depending on once_cell. It would be nice to completely remove that dependency and replace it with std where possible.

How would you replace once_cell::sync::Lazy? std::sync::LazyLock and std::cell::LazyCell are still unstable.

You could just use OnceCell for them, is just slightly less comfortable to use. Having said that, I would just wait till they are stabilized to reduce the work needed.

authors: A6GibKm AbuShawarib bilelmoussaoui

repo: gtk-rs/gtk-rs-core


text:
Feature Request and Some Bugs Nokia 303

https://github.com/user-attachments/assets/c225378c-9130-4189-9725-2659d7d4574f
My problem is like in the video:
I can't send photos,
it would be great if there was an Auto Refresh feature, it's tiring to check if the messages have arrived in long conversations.
If there is a solution for not receiving notifications, I would like to implement it...
Im using V3 MIDP 2.0

Phone OS version: RM-763

Now ı can send photo with uncheck native file picker

Gateway fixes the live chat.
Now ı just need notification

I ask to chatgpt, idk java coding. But maybe this helps:
To address the issues with the Nokia 303 not showing notifications, vibration not working, and the lack of an option to keep the app running in the background, you need to modify your Java ME code accordingly. Here’s how you can approach these issues:
1. Enable Notifications:

PushRegistry: To ensure your app can continue to run and receive notifications in the background, you can register your app with PushRegistry. This allows your app to be automatically started when certain events occur, like receiving a message or notification.

Notification Handling: Ensure that your app is properly handling notifications using the Alert class or custom UI elements to display notifications when they occur.

2. Enable Vibration:

Use the AlertType class to trigger device vibrations. Specifically, you can use AlertType.ALARM.playSound(Display.getDisplay(this)); or DeviceControl.startVibra(int duration) to make the device vibrate.

3. Keep App Running in the Background:

Background Processing: Use MIDlet.notifyPaused() to pause the app while it continues to run in the background. Also, make sure your app can handle resuming from the paused state by overriding startApp() to restore state if necessary.

Example Code Modifications
Here’s how you could modify parts of your code to incorporate these changes. Let's assume you're working with the DiscordMIDlet class, which is the entry point for your application:
Start App with PushRegistry
Add code to register for push notifications and start your app in the background:
import javax.microedition.io.PushRegistry;
import javax.microedition.midlet.*;

public class DiscordMIDlet extends MIDlet {
    private boolean started = false;
    private static State s;

    public DiscordMIDlet() {
        started = false;
    }

    public void startApp() {
        if (!started) {
            s = new State();
            s.midlet = this;
            s.disp = Display.getDisplay(this);

            // Check for any pending alarms or push notifications
            String[] connections = PushRegistry.listConnections(true);
            if (connections != null && connections.length > 0) {
                // Handle the push connection
            }

            boolean haveLoginRms = true;
            try {
                RecordStore.openRecordStore("login", false).closeRecordStore();
            } catch (Exception e) {
                haveLoginRms = false;
            }

            if (!haveLoginRms && getAppProperty("Token") == null) {
                s.disp.setCurrent(new LoginForm(s));
            } else {
                LoginSettings.load(s);
                s.login();
            }

            started = true;
        }
    }

    public void pauseApp() {
        // Keep app running in the background
        notifyPaused();
    }

    public void destroyApp(boolean unconditional) {}
}

Handle Vibration
To trigger vibration when a notification is received or when an alert is shown:
import javax.microedition.lcdui.Alert;
import javax.microedition.lcdui.AlertType;

public class NotificationHandler {

    public void showNotification(String message) {
        Alert alert = new Alert("Notification", message, null, AlertType.ALARM);
        alert.setTimeout(Alert.FOREVER);

        // Trigger vibration
        AlertType.ALARM.playSound(Display.getDisplay(midlet));

        Display.getDisplay(midlet).setCurrent(alert);
    }
}

Handle Background Operations
Ensure your app can handle being in the background and properly manage its state:
public void startApp() {
    if (getAppProperty("MIDlet-Background") != null) {
        // Code to resume from background
        restoreAppState();
    } else {
        // Normal start-up code
        initializeApp();
    }
}

public void pauseApp() {
    saveAppState();
    notifyPaused();  // Ensure the app continues running in the background
}

public void destroyApp(boolean unconditional) {
    saveAppState();
}

private void saveAppState() {
    // Save necessary app state before going into background or being destroyed
}

private void restoreAppState() {
    // Restore the app state when resuming from the background
}

Summary

Enable notifications using PushRegistry.
Enable vibration for alerts using AlertType.
Manage app background behavior using notifyPaused() and state management.

By implementing these changes, your app on the Nokia 303 should handle notifications, enable vibration, and allow background operation effectively.

Retro Discord İcon

Loading animation

I'm not sure if PushRegistry will work for this, but I have an idea for adding notification support to the app (sort of). On newer Symbian phones, it is possible to have system-level notifications via an extension API (Pigler). On some other phones, the app can stay running in the background, receiving messages via the gateway, and then show alert messages for notifications. I plan to add one or both of these notification systems at some point, but I'm working on other features right now.
I already have a loading animation implemented, which will be available in the next update (3.1 or 4.0).

a great project, I wish I knew java, I would like to help...
In 2024 on my “Nokia Asha 303, s40” there was no application to chat over the internet.
It was really water in the desert for me.
If you can fix the notification problem, I won't expect much more.
Thank you very much...

I don't know if I can run the app in the background on my nokia 303, but it would be sweet if it would at least vibrate and light up when I lock the screen with the app open.

Version 4.0 is releasing in a few days, which will include notification support. Vibration/light-up support may be added later.

authors: HamzaYslmn gtrxAC


text:
Enabled gosec linter

Description of the PR

Enable gosec linter for security checks
The setting will not break an existing issues.

gosec issues - some of them can be ignored
cmd/guacgql/cmd/server.go:98:13: G112: Potential Slowloris Attack because ReadHeaderTimeout is not configured in the http.Server (gosec)
server := &http.Server{Addr: fmt.Sprintf(":%d", flags.port)}
^
pkg/certifier/osv/osv_test.go:244:29: G601: Implicit memory aliasing in for loop. (gosec)
got := createAttestation(&test.args.packageNode, test.args.vulns, currentTime)
^
pkg/handler/processor/process/process_test.go:518:33: G601: Implicit memory aliasing in for loop. (gosec)
docTree, err := Process(ctx, &tt.doc)
^
pkg/handler/processor/process/process_test.go:596:29: G601: Implicit memory aliasing in for loop. (gosec)
if err := validateFormat(&tt.doc); (err != nil) != tt.wantErr {
^
pkg/assembler/backends/arangodb/backend.go:833:60: G404: Use of weak random number generator (math/rand instead of crypto/rand) (gosec)
time.Sleep(retryTime + (time.Microsecond * time.Duration(rand.Intn(10))))
^
pkg/handler/processor/dsse/dsse_test.go:143:28: G601: Implicit memory aliasing in for loop. (gosec)
actual, err := d.Unpack(&tt.doc)
^
pkg/handler/processor/dsse/dsse_test.go:171:28: G601: Implicit memory aliasing in for loop. (gosec)
err := d.ValidateSchema(&tt.doc)
^
pkg/handler/processor/scorecard/scorecard_test.go:56:28: G601: Implicit memory aliasing in for loop. (gosec)
actual, err := d.Unpack(&tt.doc)
^
pkg/handler/processor/scorecard/scorecard_test.go:103:28: G601: Implicit memory aliasing in for loop. (gosec)
err := d.ValidateSchema(&tt.doc)
^
pkg/collectsub/datasource/filesource/filesource_test.go:172:15: G306: Expect WriteFile permissions to be 0600 or less (gosec)
return path, os.WriteFile(path, content, 0644)
^
pkg/guacanalytics/patchPlanning_test.go:1224:32: G601: Implicit memory aliasing in for loop. (gosec)
foundIDs = append(foundIDs, &name.Id)
^
pkg/guacanalytics/patchPlanning_test.go:1578:50: G601: Implicit memory aliasing in for loop. (gosec)
pkgIDs, err := GetPackageIDs(ctx, gqlClient, &pkg, "", "", nil, false, false)
^
pkg/guacanalytics/patchPlanning_test.go:1694:13: G112: Potential Slowloris Attack because ReadHeaderTimeout is not configured in the http.Server (gosec)
server := &http.Server{Addr: fmt.Sprintf(":%d", 9090)}
^
pkg/handler/processor/spdx/spdx_test.go:62:28: G601: Implicit memory aliasing in for loop. (gosec)
actual, err := d.Unpack(&tt.doc)
^
pkg/handler/processor/spdx/spdx_test.go:127:28: G601: Implicit memory aliasing in for loop. (gosec)
err := d.ValidateSchema(&tt.doc)
^
pkg/handler/processor/deps_dev/deps_dev_test.go:54:31: G601: Implicit memory aliasing in for loop. (gosec)
if err := d.ValidateSchema(&tt.doc); (err != nil) != tt.expectErr {
^
pkg/handler/processor/deps_dev/deps_dev_test.go:92:28: G601: Implicit memory aliasing in for loop. (gosec)
actual, err := d.Unpack(&tt.doc)
^
pkg/ingestor/parser/spdx/parse_spdx.go:127:51: G601: Implicit memory aliasing in for loop. (gosec)
purl = asmhelpers.GuacPkgPurl(pac.PackageName, &pac.PackageVersion)
^
pkg/ingestor/parser/spdx/parse_spdx.go:193:97: G601: Implicit memory aliasing in for loop. (gosec)
purl := asmhelpers.GuacFilePurl(strings.ToLower(string(checksum.Algorithm)), checksum.Value, &file.FileName)
^
pkg/ingestor/parser/spdx/parse_spdx.go:401:15: G601: Implicit memory aliasing in for loop. (gosec)
l.Inline = &o.ExtractedText
^
pkg/ingestor/parser/spdx/parse_spdx_test.go:42:2: G101: Potential hardcoded credentials (gosec)
depPackageOfVersion := "sha256:a743268cd3c56f921f3fb706cc0425c8ab78119fd433e38bb7c5dcd5635b0d10"
^
pkg/assembler/backends/inmem/path.go:116:10: G602: Potentially accessing slice out of bounds (gosec)
now := queue[0]
^
pkg/assembler/backends/inmem/path.go:117:11: G602: Potentially accessing slice out of bounds (gosec)
queue = queue[1:]
^
pkg/assembler/backends/inmem/src.go:359:12: G601: Implicit memory aliasing in for loop. (gosec)
Tag:    &s.tag,
^
pkg/assembler/backends/inmem/src.go:360:12: G601: Implicit memory aliasing in for loop. (gosec)
Commit: &s.commit,
^
pkg/handler/processor/cyclonedx/cyclonedx_test.go:58:28: G601: Implicit memory aliasing in for loop. (gosec)
actual, err := d.Unpack(&tt.doc)
^
pkg/handler/processor/cyclonedx/cyclonedx_test.go:141:28: G601: Implicit memory aliasing in for loop. (gosec)
err := d.ValidateSchema(&tt.doc)
^
pkg/assembler/backends/ent/backend/certifyLegal.go:21:2: G505: Blocklisted import crypto/sha1: weak cryptographic primitive (gosec)
"crypto/sha1"
^
pkg/assembler/backends/ent/backend/certifyLegal.go:194:10: G401: Use of weak cryptographic primitive (gosec)
hash := sha1.New()
^
pkg/assembler/backends/ent/backend/package.go:21:2: G505: Blocklisted import crypto/sha1: weak cryptographic primitive (gosec)
"crypto/sha1"
^
pkg/assembler/backends/ent/backend/package.go:255:10: G401: Use of weak cryptographic primitive (gosec)
hash := sha1.New()
^
pkg/assembler/backends/ent/backend/pkgequal.go:21:2: G505: Blocklisted import crypto/sha1: weak cryptographic primitive (gosec)
"crypto/sha1"
^
pkg/assembler/backends/ent/backend/pkgequal.go:176:10: G401: Use of weak cryptographic primitive (gosec)
hash := sha1.New()
^
pkg/assembler/backends/ent/backend/slsa.go:21:2: G505: Blocklisted import crypto/sha1: weak cryptographic primitive (gosec)
"crypto/sha1"
^
pkg/assembler/backends/ent/backend/slsa.go:189:10: G401: Use of weak cryptographic primitive (gosec)
hash := sha1.New()
^
pkg/assembler/graphql/resolvers/certifyBad.resolvers_test.go:88:35: G601: Implicit memory aliasing in for loop. (gosec)
IngestCertifyBad(ctx, o.Sub, &o.Match, *o.CB).
^
pkg/assembler/graphql/resolvers/certifyBad.resolvers_test.go:216:36: G601: Implicit memory aliasing in for loop. (gosec)
IngestCertifyBads(ctx, o.Sub, &o.Match, o.CB).
^
pkg/assembler/graphql/resolvers/certifyGood.resolvers_test.go:85:36: G601: Implicit memory aliasing in for loop. (gosec)
IngestCertifyGood(ctx, o.Sub, &o.Match, *o.CG).
^
pkg/assembler/graphql/resolvers/certifyGood.resolvers_test.go:213:37: G601: Implicit memory aliasing in for loop. (gosec)
IngestCertifyGoods(ctx, o.Sub, &o.Match, o.CG).
^
pkg/assembler/graphql/resolvers/contact.resolvers_test.go:85:39: G601: Implicit memory aliasing in for loop. (gosec)
IngestPointOfContact(ctx, o.Sub, &o.Match, *o.HM).
^
pkg/assembler/graphql/resolvers/contact.resolvers_test.go:212:40: G601: Implicit memory aliasing in for loop. (gosec)
IngestPointOfContacts(ctx, o.Sub, &o.Match, o.PC).
^
pkg/assembler/graphql/resolvers/metadata.resolvers_test.go:221:40: G601: Implicit memory aliasing in for loop. (gosec)
IngestBulkHasMetadata(ctx, o.Sub, &o.Match, o.HM).
^
pkg/collectsub/client/client.go:68:80: G402: TLS InsecureSkipVerify may be true. (gosec)
creds = credentials.NewTLS(&tls.Config{RootCAs: sysPool, InsecureSkipVerify: opts.TlsSkipVerify})
^
pkg/assembler/clients/helpers/assembler.go:82:45: G601: Implicit memory aliasing in for loop. (gosec)
if err := ingestLicense(ctx, gqlclient, &v); err != nil {
^
pkg/ingestor/parser/open_vex/parser_open_vex.go:75:40: G601: Implicit memory aliasing in for loop. (gosec)
vi, err := c.generateVexIngest(vuln, &s, string(s.Status), openVex)
^
pkg/misc/depversion/depversion.go:229:12: G601: Implicit memory aliasing in for loop. (gosec)
Exact: &s,
^
pkg/handler/processor/jsonlines/jsonlines_test.go:111:28: G601: Implicit memory aliasing in for loop. (gosec)
actual, err := d.Unpack(&tt.doc)
^
pkg/handler/processor/jsonlines/jsonlines_test.go:139:28: G601: Implicit memory aliasing in for loop. (gosec)
err := d.ValidateSchema(&tt.doc)
^
pkg/ingestor/parser/cyclonedx/parser_cyclonedx.go:189:48: G601: Implicit memory aliasing in for loop. (gosec)
purl = asmhelpers.GuacPkgPurl(comp.Name, &comp.Version)
^
cmd/guacone/cmd/known.go:123:13: G601: Implicit memory aliasing in for loop. (gosec)
Value: &qualifier.Value,
				       ^

# PR Checklist

[x] All commits have a Developer Certificate of Origin (DCO) -- they are generated using -s flag to git commit.
[ ] All new changes are covered by tests
[ ] If GraphQL schema is changed, make generate has been run
[ ] If collectsub protobuf has been changed, make proto has been run
[ ] All CI checks are passing (tests and formatting)
[ ] All dependent PRs have already been merged

I'd want us to have a check where we can get a pass vs ignoring a bunch of the output, since that will become the norm. We should fix all these before enabling them so that we start from a clean stasrt.

authors: lumjjb naveensrinivasan

repo: guacsec/guac


text:
rspec --drb print summary twice

I have been working with guard and is great, but always when I run rspec --drb in guard with spork I have the result printed twice. I'm not sure if the error is in this gem, I decide post here because the error is fixed if I remove "--drb".
Gems version:
heber@heber:~/workspaces/personal/datanovo$ gem list | grep "guard\|rspec\|spork"
guard (2.10.2)
guard-compat (0.3.0)
guard-livereload (2.4.0)
guard-rails (0.7.0)
guard-rspec (4.4.2)
guard-spork (2.0.2)
rspec (2.99.0)
rspec-collection_matchers (1.1.2)
rspec-core (2.99.2)
rspec-expectations (2.99.2)
rspec-mocks (2.99.2)
rspec-rails (2.99.0)
spork (1.0.0rc4)
spork-rails (4.0.0)

Result:
[1] guard(main)>
16:59:06 - INFO - Run all
16:59:06 - INFO - Running all specs
Running tests with args ["--color", "--failure-exit-code", "2", "--format", "documentation", "--format", "Guard::RSpecFormatter", "--require", "/home/heber/.rvm/gems/ruby-2.1.2@datanovo/gems/guard-rspec-4.4.2/lib/guard/rspec_formatter.rb", "spec"]...
Run options:
  include {:focus=>true}
  exclude {:slow=>true}
Run options:
  include {:focus=>true}
  exclude {:slow=>true}

All examples were filtered out; ignoring {:focus=>true}

All examples were filtered out; ignoring {:focus=>true}

Guardfile:
# A sample Guardfile
# More info at https://github.com/guard/guard#readme

guard 'spork', :rspec_env => { 'RAILS_ENV' => 'test' } do
  watch('config/application.rb')
  watch('config/environment.rb')
  watch(%r{^config/environments/.*\.rb$})
  watch(%r{^config/initializers/.*\.rb$})
  watch('Gemfile.lock')
  watch('spec/spec_helper.rb') { :rspec }
  watch('test/test_helper.rb') { :test_unit }
  watch(%r{features/support/}) { :cucumber }
end

guard :rspec, cmd: 'rspec --drb' do
  watch('spec/spec_helper.rb')                        { "spec" }
  watch('config/routes.rb')                           { "spec/routing" }
  watch('app/controllers/application_controller.rb')  { "spec/controllers" }
  watch(%r{^spec/.+_spec\.rb$})
  watch(%r{^app/(.+)\.rb$})                           { |m| "spec/#{m[1]}_spec.rb" }
  watch(%r{^app/(.*)(\.erb|\.haml|\.slim)$})          { |m| "spec/#{m[1]}#{m[2]}_spec.rb" }
  watch(%r{^lib/(.+)\.rb$})                           { |m| "spec/lib/#{m[1]}_spec.rb" }
  watch(%r{^app/controllers/(.+)_(controller)\.rb$})  { |m| ["spec/routing/#{m[1]}_routing_spec.rb", "spec/#{m[2]}s/#{m[1]}_#{m[2]}_spec.rb", "spec/acceptance/#{m[1]}_spec.rb"] }
end

guard 'livereload' do
  watch(%r{app/views/.+\.(erb|haml|slim)$})
  watch(%r{app/helpers/.+\.rb})
  watch(%r{public/.+\.(css|js|html)})
  watch(%r{config/locales/.+\.yml})
  # Rails Assets Pipeline
  watch(%r{(app|vendor)(/assets/\w+/(.+\.(css|js|html))).*}) { |m| "/assets/#{m[3]}" }
end

.rspec File
--color
--format documentation

Thanks for your time, warmest regards.

Did you ever come to resolution on double printing?

authors: blueboxjesse woohoou

repo: guard/guard-spork


text:
Examples of how to interact with new/pre-existing tables with Hash and Sort keys

It would be nice to have some more examples showing of this behavior :smile:

There's nothing particular to the examples that requires them to have new tables.
The main reason for creating and dropping tables as part of the examples is that they're all executed as test cases as part of the build pipeline.
If there's anything that's still not clear, let me know and I'll try and elaborate.

I'm a bit confused as to how to use a table that has a hash and a sort key and one that has a GSI index. Can you please elaborate on this?
Thank you very much, this is an awesome library

The Table scaladoc has an example showing querying from a GSI.
While the Scanamo scaladoc has an example of getting with a hash and range key. I should probably move the latter over to the Table docs now, as that's the main approach I'm suggesting.

Thanks! That helps a lot :-)

Oops my fat fingers

I took a look at the Table example you provided. To make it more clearer that you are using a GSI, it would be great if you could state in a comment as to how the table is configured (primary key, GSI hash and sort key). What do you think?

Yes, I'll try and add something to the README (unless someone else gets round to a PR first).
I need to take a look at how to structure it better at some point too.

Sounds good. I'm also working on a full end to end example with Play framework to get a simple REST API hooked into DynamoDB via Scanamo. You can find it here
https://github.com/referentiallytransparent/play-framework-validation-example/tree/feature/crud/app/services/data/dynamodb
Still have to clean it up some more

Does https://github.com/guardian/scanamo/blob/00e4d4530acba3709e4a67c9010ea62874aaf3b0/README.md#using-indexes look like it explains things a bit more?

Absolutely, great job :+1:

authors: philwills referentiallytransparent

repo: guardian/scanamo


text:
Clipboard paste

Getting "event.clipboardData.types.contains is not a function" when attempting to paste. The same here http://guardian.github.io/scribe/. Chrome 43.0.2357.130,  45.0.2439.0 canary, Opera 30.0.1835.59, Safari 8.0.6. Works in Firefox though

I'm experiencing the same, using the NPM release with webpack.

@alexeygolev I've deployed 1.4.6 to the Github pages, can you retest?

@alexeygolev @cutandpastey @regiskuckaertz Regis pointed out that FF might not be Array-like so the fix may have broken FF. Can you check?
We might need to use a fixed data structure to reconcile the behaviours (at least I understand why the Lodash function was being used now).

@rrees it indeed did break in FF. Works in Chrome, Opera and Safari

@alexeygolev Okay, I have taken on your suggestion and this should now work for all browsers (release 1.4.8 or later).

@alexeygolev I think release 1.4.13 might be the definitive solution for this. Do you want re-test and confirm?

@rrees yep... works across the browsers...cheers

authors: alexeygolev hntrdglss rrees

repo: guardian/scribe


text:
Where to get other carla maps?

Now there is only a town01 map in Apollo. Does anyone know how to import other maps?
Another question is that the existing town01 map doesn't have traffic light information. How to add traffic light information to the map?
Thanks for help.

You change maps from opendrive to apollo map by lgsvl.

Now there is only a town01 map in Apollo. Does anyone know how to import other maps? Another question is that the existing town01 map doesn't have traffic light information. How to add traffic light information to the map? Thanks for help.

You can save OpenDrive format maps from CARLA. Refer to save_to_disk in https://carla.readthedocs.io/en/latest/python_api/. Then you need to convert OpenDrive formt to Apollo format.

So far, we have done a lot of work on map conversion, and supporting the signal lights. Town01 and town02 has been completed and will be updated soon. More maps will also be updated one by one.

Problem solved by Release 0.3.0, so this issue is closed.

authors: MingfeiCheng SEEKERXC dylanyd ldh2020


text:
🛑 Sefaz - São Paulo is down

In 9074eaf, Sefaz - São Paulo (https://onboardapi.guichepass.com.br/sefaz?code=3) was down:

HTTP code: 500
Response time: 208 ms

Resolved: Sefaz - São Paulo is back up in 0819bf5 after 52 minutes.

repo: guichevirtual/statuspage


text:
vhost keeps reconnecting after broker.shutdown()

Hi,
We have discovered an issue with the library.

Create an app with the broker.
Disconnect AMQP container from the Docker network, so the host becomes unavailable.
On the 'error' event shut down the broker, in our case on heartbeat error (common industry approach to shut down the app in similar cases).
Broker theoretically is shut down, but vhost keeps trying to reconnect.

Logs:
2021-06-28T11:23:19.647Z rascal:Vhost Handling connection error: Heartbeat timeout initially from connection: 420e4da1-3ab4-44ec-8071-ba68dde266bd, amqp://rabbit
2021-06-28T11:23:19.648Z rascal:Vhost Initialising vhost: amqp
2021-06-28T11:23:19.649Z rascal:tasks:createConnection Connecting to broker using url: amqp://rabbit
2021-06-28T11:23:19.653Z rascal:Subscription Handling channel error: Heartbeat timeout from amqp/MyQueue using channel: 5f1f5d4d-43db-457a-b35b-072387d544e9
2021-06-28T11:23:19.658Z rascal:SubscriberSession Removing channel: 5f1f5d4d-43db-457a-b35b-072387d544e9 from session
2021-06-28T11:23:19.676Z rascal:Broker Shutting down broker
2021-06-28T11:23:19.677Z rascal:Vhost Forwarning vhost: amqp about impending shutdown
2021-06-28T11:23:19.680Z rascal:Subscription Subscribing to queue: DecodedAzureMessagesQueue
2021-06-28T11:23:19.680Z rascal:Vhost Requested channel. Outstanding channel requests: 1
2021-06-28T11:23:19.681Z rascal:Vhost Ignoring create channel request. VHost is shutting down.
2021-06-28T11:23:19.682Z rascal:SubscriberSession No current subscriber session
2021-06-28T11:23:19.682Z rascal:Broker Waiting 10000ms for all subscriber channels to close
2021-06-28T11:23:19.770Z rascal:Vhost Will attempt reconnection in in 1248ms
2021-06-28T11:23:21.020Z rascal:Vhost Handling connection error: Failed to connect to: amqp://rabbit. Original message was: getaddrinfo ENOTFOUND rabbit initially from connection: 420e4da1-3ab4-44ec-8071-ba68dde266bd, amqp://rabbit
2021-06-28T11:23:21.023Z rascal:Vhost Initialising vhost: amqp
2021-06-28T11:23:21.023Z rascal:tasks:createConnection Connecting to broker using url: amqp://rabbit
2021-06-28T11:23:21.035Z rascal:Vhost Will attempt reconnection in in 2109ms
2021-06-28T11:23:23.147Z rascal:Vhost Handling connection error: Failed to connect to: amqp://rabbit. Original message was: getaddrinfo ENOTFOUND rabbit initially from connection: 420e4da1-3ab4-44ec-8071-ba68dde266bd, amqp://rabbit
2021-06-28T11:23:23.147Z rascal:Vhost Initialising vhost: amqp
2021-06-28T11:23:23.148Z rascal:tasks:createConnection Connecting to broker using url: amqp://rabbit
2021-06-28T11:23:23.158Z rascal:Vhost Will attempt reconnection in in 6188ms
2021-06-28T11:23:29.348Z rascal:Vhost Handling connection error: Failed to connect to: amqp://rabbit. Original message was: getaddrinfo ENOTFOUND rabbit initially from connection: 420e4da1-3ab4-44ec-8071-ba68dde266bd, amqp://rabbit
2021-06-28T11:23:29.348Z rascal:Vhost Initialising vhost: amqp
2021-06-28T11:23:29.349Z rascal:tasks:createConnection Connecting to broker using url: amqp://rabbit
2021-06-28T11:23:29.360Z rascal:Vhost Will attempt reconnection in in 13735ms
2021-06-28T11:23:29.683Z rascal:Vhost Shutting down vhost: amqp
2021-06-28T11:23:29.685Z rascal:Vhost Draining regular channel pool. { vhost: 'amqp', mode: 'regular', queue: 0, size: 0, available: 0, borrowed: 0, min: 1, max: 5 }
2021-06-28T11:23:29.687Z rascal:Vhost Drained regular channel pool. { vhost: 'amqp', mode: 'regular', queue: 0, size: 0, available: 0, borrowed: 0, min: 1, max: 5 }
2021-06-28T11:23:29.687Z rascal:Vhost Draining confirm channel pool. { vhost: 'amqp', mode: 'confirm', queue: 0, size: 0, available: 0, borrowed: 0, min: 1, max: 5 }
2021-06-28T11:23:29.688Z rascal:Vhost Drained confirm channel pool. { vhost: 'amqp', mode: 'confirm', queue: 0, size: 0, available: 0, borrowed: 0, min: 1, max: 5 }
2021-06-28T11:23:29.688Z rascal:Vhost Disconnecting from vhost: amqp
2021-06-28T11:23:29.688Z rascal:Broker Finished shutting down broker

\/ THIS SHOULD NOT HAPPEN \/
2021-06-28T11:23:43.064Z rascal:Vhost Handling connection error: Failed to connect to: amqp://rabbit. Original message was: getaddrinfo ENOTFOUND rabbit initially from connection: 420e4da1-3ab4-44ec-8071-ba68dde266bd, amqp://rabbit
2021-06-28T11:23:43.065Z rascal:Vhost Initialising vhost: amqp
2021-06-28T11:23:43.066Z rascal:tasks:createConnection Connecting to broker using url: amqp://rabbit
2021-06-28T11:23:43.079Z rascal:Vhost Will attempt reconnection in in 16329ms
2021-06-28T11:23:59.408Z rascal:Vhost Handling connection error: Failed to connect to: amqp://rabbit. Original message was: getaddrinfo ENOTFOUND rabbit initially from connection: 420e4da1-3ab4-44ec-8071-ba68dde266bd, amqp://rabbit
2021-06-28T11:23:59.409Z rascal:Vhost Initialising vhost: amqp
2021-06-28T11:23:59.409Z rascal:tasks:createConnection Connecting to broker using url: amqp://rabbit
2021-06-28T11:23:59.421Z rascal:Vhost Will attempt reconnection in in 43101ms

Thanks for reporting, and the clear steps to reproduce @murbanowicz. I'll look into it.

One thing that may help in the meantime - if you're not using Rascal's automatic connection recovery, you could disable it, then the Vhost shouldn't reconnect.

Hi @murbanowicz,
Sorry this is taking a while. I've managed to get Rascal to stop reconnecting after shutdown easily enough, but there's a secondary issue with the channel pool. The pool never completes draining and so blocks the shutdown for a new reason. I'm trying to find a workaround.

Think I've managed to figure this out. The channel pool was waiting indefinitely for a call to channel.close to yield. However, because the of the heartbeat error, the broker never replied, pool never finished draining. I've fixed in rascal this through use of a configurable destroy timeout, and volunteered to add to the timeout to the underly generic-pool library.

Fixed in 13.1.0. I'll push out a patch release if/when generic-pool-289 gets merged.

I highly appreciate your responsiveness and effort! Thanks!

repo: guidesmiths/rascal

license: isc


text:
Support alphanumeric entries

Is your feature request related to a problem? Please describe.
On desktop, it works when a regex pattern for alphanumeric is added as a prop but doesn't work for mobile. A client pointed it out and it took me way too long to find it since I was debugging on my laptop and not on an actual  mobile device
Describe the solution you'd like
A simple prop for the type of input, preferably an enum "numeric" | "alphanumeric" | "alpha"
Describe alternatives you've considered
I had a workaround to fix the issue however I noticed you have pending pull requests so I didn't bother creating another.

hey @iamevansobeng is that a duplicate of #56? If so, please check the reply I wrote there

Duplicate of #56 (most likely)

Duplicate of https://github.com/guilhermerodz/input-otp/issues/56 (most likely)

authors: guilhermerodz iamevansobeng

repo: guilhermerodz/input-otp


text:
What does it mean ? - Results score

Well as you can see, we have in "Francisco" I-LOC B-LOC What does it mean? What is the meaning of I-LOC and B-LOC? i don't know if the meaning of I-LOC is that tag was the correct tag, and B-LOC was the the predicted tag, or maybe another example Moscow B-LOC B-LOC.
Thank you!

Hi @rodmandi,
The first tag is the true tag (from the dummy dataset), the second tag is the prediction.
I assume you trained the model just on this dummy dataset, which would result in a crappy model (almost perfectly overfitted on the dummy dataset).
So in Francisco I-LOC B-LOC it means that the model made a mistake by predicting B-LOC instead of I-LOC.
Hope that helps

@rodmandi  Just to add more
In case you do not know this may help ... B-I-O is Begin Inside Outside Input data pattern.
Explanation from @guillaumegenthial blog
In the CoNLL2003 task, the entities are LOC, PER, ORG and MISC for locations, persons, orgnizations and miscellaneous. The no-entity tag is O. Because some entities (like New York) have multiple words, we use a tagging scheme to distinguish between the beginning (tag B-...), or the inside of an entity (tag I-...). Other tagging schemes exist (IOBES, etc). However, if we just pause for a sec and think about it in an abstract manner, we just need a system that assigns a class (a number corresponding to a tag) to each word in a sentence.
--> What is the meaning of I-LOC and B-LOC?
Word from sequence | TrueTag | PredictedTag

authors: bhushanbrb guillaumegenthial rodmandi


text:
can vad_max_speech_duration_s still be used if vad_filter=False?

I'm thinking the answer is no, but I would still like my segments to be cut up into smaller chunks than they currently are.
However, I'm in a situation where I'm using --vad_filter False at all times -- (at least, that was how the problem of 95%-missing transcription of song lyrics was solved) so I'm not sure if that option would still work or make sense or do anything.
I'd just like to tighten up the values a bit.  Lower min silence duration from 3000 to 2000, reduce vad_speech_pad_ms from 900 to 400, and set vad_max_speech_duration_s to about 10 seconds or so....
But i'm not sure if adding those options will do anything with the filter set to false.

These are parameters of the VAD filter, so they are only relevant when the VAD filter is enabled.
To cut segments into smaller chunks, you could enable word_timestamps and then you could rebuild your own segments since you get access to the timing of every words.

I think you expect these parameters to somehow change the segments length, but they do not. They only control the application of the VAD filter.

For this problem, demucs can be a very effective alternative. Part of the reason for the longer segments also has to do with the whisper model recognizing non-vocal parts as speech. Try using DEMUCS to separate the vocals from the music and then transcribe them. Chances are you'll get better results.

thanks! i was going to try with Spleeter... is one better than the other?

authors: ClaireCJS archive-r guillaumekln

repo: guillaumekln/faster-whisper