Error 403

Hello,
suddenly my librespot instance on libreelec stopped playing any songs.
[2023-06-20T05:24:59Z INFO  librespot] librespot 0.5.0-dev d07b2ce (Built on 2023-06-18, Build ID: e4T4YlCt, Profile: release)
*** WARNING *** The program 'librespot' uses the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/blog/projects/avahi-compat.html>
[2023-06-20T05:24:59Z INFO  librespot_playback::mixer::softmixer] Mixing with softvol and volume control: Log(60.0)
[2023-06-20T05:24:59Z INFO  librespot_playback::convert] Converting with ditherer: tpdf
[2023-06-20T05:24:59Z INFO  librespot_playback::audio_backend::alsa] Using AlsaSink with format: S16
[2023-06-20T05:24:59Z INFO  librespot_core::session] Connecting to AP "ap-gew4.spotify.com:4070"
[2023-06-20T05:24:59Z INFO  librespot_core::session] Authenticated as "11127372133" !
[2023-06-20T05:24:59Z INFO  librespot_core::session] Country: "CZ"
[2023-06-20T05:25:08Z INFO  librespot_core::spclient] Resolved "gew4-spclient.spotify.com:443" as spclient access point
[2023-06-20T05:25:08Z ERROR librespot_core::mercury] error 403 for uri hm://keymaster/token/authenticated?scope=playlist-read&client_id=65b708073fc0480ea92a077233ca87bd&device_id=78f3d06ba0952bdccb9e15230ae4f8c6891f6292
[2023-06-20T05:25:08Z ERROR librespot_connect::spirc] ContextError: Error { kind: Unavailable, error: Response(MercuryResponse { uri: "hm://keymaster/token/authenticated?scope=playlist-read&client_id=65b708073fc0480ea92a077233ca87bd&device_id=78f3d06ba0952bdccb9e15230ae4f8c6891f6292", status_code: 403, payload: [[123, 34, 99, 111, 100, 101, 34, 58, 52, 44, 34, 101, 114, 114, 111, 114, 68, 101, 115, 99, 114, 105, 112, 116, 105, 111, 110, 34, 58, 34, 73, 110, 118, 97, 108, 105, 100, 32, 114, 101, 113, 117, 101, 115, 116, 34, 125]] }) }
[2023-06-20T05:25:08Z ERROR librespot_core::mercury] error 403 for uri hm://keymaster/token/authenticated?scope=playlist-read&client_id=65b708073fc0480ea92a077233ca87bd&device_id=78f3d06ba0952bdccb9e15230ae4f8c6891f6292
[2023-06-20T05:25:08Z ERROR librespot_playback::player] Unable to load audio item: Error { kind: Unavailable, error: Response(MercuryResponse { uri: "hm://keymaster/token/authenticated?scope=playlist-read&client_id=65b708073fc0480ea92a077233ca87bd&device_id=78f3d06ba0952bdccb9e15230ae4f8c6891f6292", status_code: 403, payload: [[123, 34, 99, 111, 100, 101, 34, 58, 52, 44, 34, 101, 114, 114, 111, 114, 68, 101, 115, 99, 114, 105, 112, 116, 105, 111, 110, 34, 58, 34, 73, 110, 118, 97, 108, 105, 100, 32, 114, 101, 113, 117, 101, 115, 116, 34, 125]] }) }
[2023-06-20T05:25:08Z ERROR librespot_playback::player] Skipping to next track, unable to load track <SpotifyId("spotify:track:4vGFfCD9PvBuKDbTourDdW")>: ()
[2023-06-20T05:25:08Z ERROR librespot_core::mercury] error 403 for uri hm://keymaster/token/authenticated?scope=playlist-read&client_id=65b708073fc0480ea92a077233ca87bd&device_id=78f3d06ba0952bdccb9e15230ae4f8c6891f6292
[2023-06-20T05:25:08Z ERROR librespot_playback::player] Unable to load audio item: Error { kind: Unavailable, error: Response(MercuryResponse { uri: "hm://keymaster/token/authenticated?scope=playlist-read&client_id=65b708073fc0480ea92a077233ca87bd&device_id=78f3d06ba0952bdccb9e15230ae4f8c6891f6292", status_code: 403, payload: [[123, 34, 99, 111, 100, 101, 34, 58, 52, 44, 34, 101, 114, 114, 111, 114, 68, 101, 115, 99, 114, 105, 112, 116, 105, 111, 110, 34, 58, 34, 73, 110, 118, 97, 108, 105, 100, 32, 114, 101, 113, 117, 101, 115, 116, 34, 125]] }) }

I think it is similar to #972 if it is not the same, but I have not found any way how to fix it yet...
~ # curl http://apresolve.spotify.com/
{"ap_list":["ap-gew4.spotify.com:4070","ap-gew4.spotify.com:443","ap-gew4.spotify.com:80","ap-gue1.spotify.com:4070","ap-gew1.spotify.com:443","ap-guc3.spotify.com:80"]}

It seems that libreelec jumped directly to development branch, version 0.4.2 works fine...

This is the main blocker for me to switch to dev in Raspotify if/when this PR is merged I plan on poking around the network code and seeing if I can figure out a fix. I might checkout librespot java and see what works for them and attempt to port it over? Up until this point though my knowledge and contributions have primarily been limited to the audio side of the code base. The author of most of the network stack isn't active in the project so I could use whatever help anyone can offer.
In the meantime the workaround is to disable zeroconf discovery and use your Spotify credentials to log librespot in manually.

Happens to me (in Austria) also since yesterday, never has happened before. Using current dev branch.

Happens to me (in Austria) also since yesterday, never has happened before. Using current dev branch.

I'm in the US, and discovery hasn't worked for me in dev for a year or more. I don't think the network bits in dev are complete? I think they're kinda in a transitional place between APIs? That was @roderickvd's baby but I'm not sure where he left off?

If I had to guess it may be that the 403 is because we're still using http://apresolve.spotify.com and those ap's are returning 403's because they are not local to us as far as Spotify is concerned but they may be local so some people including @roderickvd because when made the changes that broke discovery for all of us it still worked for him so he thought it was Ok.
I don't think that the dealer API has been implemented yet? That may fix discovery for everyone, idk though? All of that are just guesses. I'm not very familiar at all with the Spotify API's or the networking bits of librespot. My focus is generally on the audio side of things.

I might checkout librespot java and see what works for them and attempt to port it over?

Sure you can look at that. librespot-java is also pretty dormant, although I think last few weeks it has also seen a couple of issues and who knows commits on network problems. Seems like Spotify is changing things on their side.
Last time I reworked the network code, I took librespot-java as basis and updated that based on the latest official Spotify clients at that time, proxying the traffic and mimicking the requests. For example, this dev sends more extensive query strings (with client ID for example) than librespot-java does. Maybe stripping it down will fix things, I don't know, I'd actually recommend following the latest clients again and updating any code necessary.

I'm in the US, and discovery hasn't worked for me in dev for a year or more. I don't think the network bits in dev are complete? I think they're kinda in a transitional place between APIs? That was @roderickvd's baby but I'm not sure where he left off?

Except for the dealer (websockets-based messaging) that is not in, it should be fully functional and was ready for release pending wider testing.

If I had to guess it may be that the 403 is because we're still using http://apresolve.spotify.com and those ap's are returning 403's because they are not local to us as far as Spotify is concerned but they may be local so some people including @roderickvd because when he made the changes that broke discovery for all of us it still worked for him so he thought it was Ok.

I cannot think of any reason why the access point resolver should influence zeroconf discovery.
apresolve.spotify.com is what the official clients use for geographically load balanced DNS lookups.

I don't think that the dealer API has been implemented yet? That may fix discovery for everyone, idk though? All of that are just guesses. I'm not very familiar at all with the Spotify API's or the networking bits of librespot. My focus is generally on the audio side of things.

Also the dealer holds no relationship with zeroconf discovery. The dealer, simply put, replaces the current spirc messaging interface between the Spotify server and client. Which also has no relationship with zeroconf discovery.
Concerning zeroconf you may want to go through the commit log in librespot-discovery. I remember I did update some code there related to how the service is advertised. Not sure anymore.
I understand this may not seem helpful, though hopefully it will rule out some things or help focus any debugging efforts. Because that's what should happen really.

For example, this dev sends more extensive query strings (with client ID for example) than librespot-java does. Maybe stripping it down will fix things, I don't know, I'd actually recommend following the latest clients again and updating any code necessary.

I tried that no dice.

I cannot think of any reason why the access point resolver should influence zeroconf discovery.

That was just a guess. Basically me pulling stuff out of my butt,lol!!!

Concerning zeroconf you may want to go through the commit log in librespot-discovery. I remember I did update some code there related to how the service is advertised. Not sure anymore.

I guess I get to bisect,lol!!! Because discovery in stable works perfectly fine for me.

I understand this may not seem helpful, though hopefully it will rule out some things or help focus any debugging efforts. Because that's what should happen really.

No, it is very helpful. It narrows my target. Thanks.
After I figure this out my next step as far as discovery is to replace with-dns-sd with an option to use avahi on Linux via it's DBus interface. @Johannesd3 already did most of the work here: https://github.com/Johannesd3/dnssd-rs/blob/master/src/avahi.rs. But it doesn't really make much sense to work on that until the current issue is fixed.

When I start librespot with --username USERNAMEand enter my password, it works FWIW

Same. That's the only way it dev has worked for me in a long time.

To add to tracing down the issue, maybe dev is sending a client or device ID as part of the discovery request that is not correct. Or the HTTP worker / spclient is sending a header that does not correspond to the actual client or device ID.

To add to tracing down the issue, maybe dev is sending a client or device ID as part of the discovery request that is not correct. Or the HTTP worker / spclient is sending a header that does not correspond to the actual client or device ID.

I'll step though the discovery changes from stable (which works perfectly fine) to the current state of dev and see what broke what.

I just gave it a try and discovery is still working for me using dev:
2023-06-29T23:21:02Z INFO  librespot] librespot 0.5.0-dev e5d364b (Built on 2023-06-29, Build ID: EOO1uOaS, Profile: release)
[2023-06-29T23:22:02Z INFO  librespot_playback::mixer::softmixer] Mixing with softvol and volume control: Log(60.0)
[2023-06-29T23:22:02Z INFO  librespot_playback::convert] Converting with ditherer: tpdf
[2023-06-29T23:22:02Z INFO  librespot_playback::audio_backend::alsa] Using AlsaSink with format: S16
[2023-06-29T23:22:02Z INFO  librespot_core::session] Connecting to AP "ap-gew1.spotify.com:4070"
[2023-06-29T23:22:03Z INFO  librespot_core::session] Authenticated as "kingosticks4" !
[2023-06-29T23:22:03Z INFO  librespot_core::session] Country: "GB"
[2023-06-29T23:22:03Z INFO  librespot_core::spclient] Resolved "gew1-spclient.spotify.com:443" as spclient access point
[2023-06-29T23:22:03Z INFO  librespot_playback::player] Loading <The Brightest Days> with Spotify URI <spotify:track:3aBHjYg7xHAXu4Y5u19oqh>
[2023-06-29T23:22:03Z INFO  librespot_connect::spirc] Resolved 50 tracks from <"spotify:album:65EjKAFPc043WetlaXNFtW">
[2023-06-29T23:22:04Z INFO  librespot_playback::player] <The Brightest Days> (146948 ms) loaded

Also from Europe right?
So weird.

Yep, I'm in the UK. I can share the IP that my access point resolves to and someone who's having problems can try to hardcode that, to see if it makes any difference ?

And one thing which I'm not 100% clear on here (sorry if I missed it), for those having discovery problems, can you confirm that librespot-java's discovery does actually work instead? I can't see what would be different at this fundamental level, all we've done up to this point is a session login (working) and then ask for a token (broken). It's only later on that things start to diverge between the two implementations.

Happens to me (in Austria) also since yesterday, never has happened before. Using current dev branch.

By the way, I also tried from another Internet connection in Austria, and there it works! And if I've read correctly, it did use the same access points. Will investigate further ...

If possible can you double check that the same access point hostname definitely resolves to the same IP in both working and non-working cases? Presumably it was the same user account in both cases also?

I have no time now to look closer to the log, but it seems to me that librespot-java also ends with 403 here in Czechia...
2023-06-30 12:04:44,181 TRACE FileConfiguration:148 - Added new entry to configuration file: clientToken
2023-06-30 12:04:44,183 TRACE FileConfiguration:148 - Added new entry to configuration file: network.connectionTimeout
2023-06-30 12:04:44,183 TRACE FileConfiguration:148 - Added new entry to configuration file: proxy.ssl
2023-06-30 12:04:44,183 TRACE FileConfiguration:148 - Added new entry to configuration file: shell.onTrackSeeked
2023-06-30 12:04:44,183 TRACE FileConfiguration:148 - Added new entry to configuration file: shell.onStartedLoading
2023-06-30 12:04:44,184 TRACE FileConfiguration:148 - Added new entry to configuration file: shell.onConnectionDropped
2023-06-30 12:04:44,184 TRACE FileConfiguration:148 - Added new entry to configuration file: shell.onMetadataAvailable
2023-06-30 12:04:44,184 TRACE FileConfiguration:148 - Added new entry to configuration file: shell.onTrackChanged
2023-06-30 12:04:44,184 TRACE FileConfiguration:148 - Added new entry to configuration file: shell.onPlaybackFailed
2023-06-30 12:04:44,184 TRACE FileConfiguration:148 - Added new entry to configuration file: shell.onPanicState
2023-06-30 12:04:44,184 TRACE FileConfiguration:148 - Added new entry to configuration file: shell.onFinishedLoading
2023-06-30 12:04:44,185 TRACE FileConfiguration:148 - Added new entry to configuration file: shell.enabled
2023-06-30 12:04:44,185 TRACE FileConfiguration:148 - Added new entry to configuration file: shell.onPlaybackResumed
2023-06-30 12:04:44,185 TRACE FileConfiguration:148 - Added new entry to configuration file: shell.onConnectionEstablished
2023-06-30 12:04:44,185 TRACE FileConfiguration:148 - Added new entry to configuration file: shell.onPlaybackEnded
2023-06-30 12:04:44,185 TRACE FileConfiguration:148 - Added new entry to configuration file: shell.onContextChanged
2023-06-30 12:04:44,185 TRACE FileConfiguration:148 - Added new entry to configuration file: shell.executeWithBash
2023-06-30 12:04:44,185 TRACE FileConfiguration:148 - Added new entry to configuration file: shell.onPlaybackPaused
2023-06-30 12:04:44,185 TRACE FileConfiguration:148 - Added new entry to configuration file: shell.onInactiveSession
2023-06-30 12:04:44,185 TRACE FileConfiguration:148 - Added new entry to configuration file: shell.onVolumeChanged
2023-06-30 12:04:44,186 TRACE FileConfiguration:148 - Added new entry to configuration file: player.bypassSinkVolume
2023-06-30 12:04:44,186 TRACE FileConfiguration:148 - Added new entry to configuration file: player.localFilesPath
2023-06-30 12:04:44,186 TRACE FileConfiguration:148 - Added new entry to configuration file: player.outputClass
2023-06-30 12:04:44,201 INFO  Utils:104 - Cryptography restrictions removal not needed.
2023-06-30 12:04:44,229 INFO  ZeroconfServer:472 - Zeroconf HTTP server started successfully on port 53259!
2023-06-30 12:04:44,997 TRACE ZeroconfServer:536 - Handling request: GET /?action=getInfo HTTP/1.1, headers: {Keep-Alive=0, Connection=keep-alive, User-Agent=Spotify/121300661 Linux/0 (PC desktop), Host=<IP_ADDRESS>, Accept-Encoding=gzip, Content-Type=application/x-www-form-urlencoded}
2023-06-30 12:04:45,666 INFO  Zeroconf:500 - Announced Service{alias='librespot-java-player', service='spotify-connect', port=53259, text={VERSION=1.0, CPath=/, Stack=SP}, addresses=[/<IP_ADDRESS>], domain='.local', protocol='tcp', host='jules-ntb'}.
2023-06-30 12:04:50,343 TRACE ZeroconfServer:536 - Handling request: GET /?action=getInfo&version=2.7.1 HTTP/1.1, headers: {Keep-Alive=0, Connection=keep-alive, User-Agent=Spotify/121300661 Linux/0 (PC desktop), Host=<IP_ADDRESS>, Accept-Encoding=gzip, Content-Type=application/x-www-form-urlencoded}
2023-06-30 12:04:54,374 TRACE ZeroconfServer:536 - Handling request: GET /?action=getInfo&version=2.7.1 HTTP/1.1, headers: {Keep-Alive=0, Connection=keep-alive, User-Agent=Spotify/121300661 Linux/0 (PC desktop), Host=<IP_ADDRESS>, Accept-Encoding=gzip, Content-Type=application/x-www-form-urlencoded}
2023-06-30 12:04:54,390 TRACE ZeroconfServer:536 - Handling request: POST / HTTP/1.1, headers: {Keep-Alive=0, Connection=keep-alive, User-Agent=Spotify/121300661 Linux/0 (PC desktop), Host=<IP_ADDRESS>, Accept-Encoding=gzip, Content-Length=822, Content-Type=application/x-www-form-urlencoded}
2023-06-30 12:04:54,452 INFO  ZeroconfServer:345 - Accepted new user from jules-ntb. {deviceId: 95125d2c2a63cfc6f6d2aa267bfa8443d425b37b}
2023-06-30 12:04:54,515 DEBUG TimeProvider:90 - Loaded time offset from NTP: 0ms
2023-06-30 12:04:54,778 INFO  ApResolver:99 - Loaded aps into pool: {accesspoint=[ap-gew4.spotify.com:4070, ap-gew4.spotify.com:443, ap-gew4.spotify.com:80, ap-gew1.spotify.com:4070, ap-guc3.spotify.com:443, ap-gue1.spotify.com:80], dealer=[gew4-dealer.spotify.com:443, gew1-dealer.spotify.com:443, guc3-dealer.spotify.com:443, gue1-dealer.spotify.com:443], spclient=[gew4-spclient.spotify.com:443, gew1-spclient.spotify.com:443, guc3-spclient.spotify.com:443, gue1-spclient.spotify.com:443]}
2023-06-30 12:04:54,822 INFO  Session:140 - Created new session! {deviceId: 95125d2c2a63cfc6f6d2aa267bfa8443d425b37b, ap: ap-gew1.spotify.com:4070, proxy: false}
2023-06-30 12:04:55,330 INFO  Session:334 - Connected successfully!
2023-06-30 12:04:55,563 TRACE Session:1413 - Session.Receiver started
2023-06-30 12:04:55,576 INFO  CacheManager:95 - There are 0 cached entries.
2023-06-30 12:04:55,579 TRACE AsyncProcessor:52 - AsyncProcessor{dealer-worker} has started
2023-06-30 12:04:55,580 TRACE AsyncProcessor:52 - AsyncProcessor{event-service-sender} has started
2023-06-30 12:04:55,581 INFO  Session:1495 - Skipping SecretBlock
2023-06-30 12:04:55,581 INFO  Session:1467 - Received LicenseVersion: 0
2023-06-30 12:04:55,581 INFO  Session:1457 - Received CountryCode: CZ
2023-06-30 12:04:55,581 DEBUG TokenProvider:68 - Token expired or not suitable, requesting again. {scopes: [playlist-read], oldToken: null}
2023-06-30 12:04:55,587 TRACE MercuryClient:148 - Send Mercury request, seq: 1, uri: hm://keymaster/token/authenticated?scope=playlist-read&client_id=65b708073fc0480ea92a077233ca87bd&device_id=95125d2c2a63cfc6f6d2aa267bfa8443d425b37b, method: GET
2023-06-30 12:04:55,591 TRACE Session:784 - Parsed product info: {audiobook-onboarding-completed=0, remote-control=6, publish-activity=0, audio-preview-url-template=https://p.scdn.co/mp3-preview/{id}, incognito_mode_timeout=21600, ad-formats-preroll-video=0, type=premium, ab_recently_played_feature_time_filter_threshold=com.spotify.gaia=30,driving-mode=120,spotify%3Ainternal%3Astartpage=30, license-agreements=, publish-playlist=1, buffering-strategy=0, expiry=1, ab-desktop-hide-follow=0, ab-collection-hide-unavailable-albums=0, capper-profile=, payments-initial-campaign=default, profile-image-upload=1, enable-annotations=2, ab-ad-player-targeting=1, india-experience=0, video-wifi-initial-bitrate=800000, ab-mobile-running-onlymanualmode=only-manual, playlist-annotations-markup=0, prefetch-keys=1, allow-override-internal-prefs=0, prefetch-window-max=2, send-email=1, ad-formats-video-takeover=1, ab-collection-bookmark-model=1, pause-after=0, local-files-import=0, video-manifest-url=https://spclient.wg.spotify.com/manifests/v6/{type}/sources/{source_id}/options/supports_drm, ab-sugarpills-sanity-check=0, playlist-folders=1, arsenal_country=1, track-cap=0, audiobook-onboarding-dismissed=0, ab-mobile-running-tempo-detection=Control, is_email_verified=1, shows-collection=1, enable-annotations-read=0, addon-hifi=0, mobile-browse=0, payments-locked-state=0, employee-free-opt-in=0, shows-collection-jam=0, ab-browse-music-tuesday=1, offline=1, streaming=1, fb-info-confirmation=control, audio-quality=1, wanted-licenses=, lastfm-session=, ab-desktop-playlist-annotation-edit=1, ab-mobile-discover=0, widevine-license-url=https://spclient.wg.spotify.com/widevine-license/v1/video/license, key-caching-max-count=10000, hifi-eligible=0, ad-session-persistence=1, video-initial-bitrate=200000, ab-play-history=0, mobile-payment=0, payment-state=, key-caching-max-offline-seconds=1800, ugc-abuse-report-url=https://support.spotify.com/abuse/?uri={uri}, shuffle-algorithm=1, use-pl3=0, image-url=https://i.scdn.co/image/{file_id}, use-playlist-app=0, enable-autostart=1, metadata-link-lookup-modes=0, shuffle=0, instant-search=0, instant-search-expand-sidebar=0, use-playlist-uris=0, user-profile-show-invitation-codes=0, ab-ad-requester=1, nft-disabled=1, ab-collection-union=1, key-memory-cache-mode=1:15,300, libspotify=1, high-bitrate=1, head-file-caching=1, radio=1, key-caching-auto-offline=0, explicit-content=1, video-cdn-sampling=1, ab-android-push-notifications=1, unrestricted=1, use-fb-publish-backend=2, app-developer=0, buffering-strategy-parameters=0.8:0.2:0.0:0.0:0.0:0.0:1.0:10:10:2000:10000:10485760, enable-gapless=1, ab-playlist-extender=5, enable-crossfade=1, ad-persist-reward-time=0, network-operator-premium-activation=1, video-device-blacklisted=0, collection=1, fb-grant-permission-local-render=0, backend-advised-bitrate=1, autoplay=1, catalogue=premium, storage-size-config=10240,90,500,3, ads=0, head-files-url=https://heads-fa.scdn.co/head/{file_id}, ab-collection-followed-artists-only=0, browse-overview-enabled=1, on-demand=1, ap-resolve-pods=0, name=Spotify Premium, sidebar-navigation-enabled=0, loudness-levels=1:-5.0,0.0,3.0:-2.0, mobile-login=1, hifi-optin-intent=0, preferred-locale=en, license-acceptance-grace-days=30, prefetch-strategy=18, ugc-abuse-report=1, ab-watch-now=0, financial-product=pr:premium,tc:0, ab-collection-offline-mode=0, streaming-rules=, head-files=1, capping-bar-threshold=3601, ab-new-share-flow=0, video-keyframe-url=http://keyframes-fa.cdn.spotify.com/keyframes/v1/sources/{source_id}/keyframe/heights/{height}/timestamps/{timestamp_ms}.jpg, mobile=1, is_maybe_in_social_session=0, ab-mobile-startpage=0, ab-moments-experience=0, ab-mobile-social-feed=1, ab-test-group=976, player-license=premium}
2023-06-30 12:04:55,591 INFO  Session:1495 - Skipping UnknownData_AllZeros
2023-06-30 12:04:55,591 INFO  Session:1495 - Skipping LegacyWelcome
2023-06-30 12:04:55,592 TRACE MercuryClient:191 - Handling packet, cmd: MercuryEvent, seq:<PHONE_NUMBER>270327808, flags: 1, parts: 1
2023-06-30 12:04:55,594 DEBUG MercuryClient:226 - Couldn't dispatch Mercury event {seq:<PHONE_NUMBER>270327808, uri: hm://pusher/v1/connections/OTUxMjVkMmMyYTYzY2ZjNmY2ZDJhYTI2N2JmYTg0NDNkNDI1YjM3YitBUCt0Y3A6Ly9nZXcxLWFjY2Vzc3BvaW50LWMtcDR6Zi5nZXcxLnNwb3RpZnkubmV0OjUwMTErRUM2NDg0NEE2NkNCNTEyQkMwNEMzNTFGRDhBNTBFMUJCMDQyQzlFMDA1M0E0Mjk5OUQwNUQxRDg5MDhGQzNDQQ%3D%3D, code: 200, payload: []}
2023-06-30 12:04:55,652 DEBUG Session:1471 - Received 0x10: EF217D8324B2DA4B50052920D623A1FEBB1328CC
2023-06-30 12:04:55,726 TRACE MercuryClient:191 - Handling packet, cmd: MercuryReq, seq: 1, flags: 1, parts: 2
2023-06-30 12:04:55,729 ERROR ZeroconfServer:375 - Couldn't establish a new session.
xyz.gianlu.librespot.mercury.MercuryClient$MercuryException: status: 403
        at xyz.gianlu.librespot.mercury.MercuryClient.sendSync(MercuryClient.java:107) ~[librespot-player.jar:1.6.3]
        at xyz.gianlu.librespot.core.TokenProvider.getToken(TokenProvider.java:69) ~[librespot-player.jar:1.6.3]
        at xyz.gianlu.librespot.core.TokenProvider.get(TokenProvider.java:80) ~[librespot-player.jar:1.6.3]
        at xyz.gianlu.librespot.dealer.DealerClient.connect(DealerClient.java:78) ~[librespot-player.jar:1.6.3]
        at xyz.gianlu.librespot.core.Session.authenticate(Session.java:362) ~[librespot-player.jar:1.6.3]
        at xyz.gianlu.librespot.core.Session.access$600(Session.java:77) ~[librespot-player.jar:1.6.3]
        at xyz.gianlu.librespot.core.Session$Builder.create(Session.java:1057) ~[librespot-player.jar:1.6.3]
        at xyz.gianlu.librespot.ZeroconfServer.handleAddUser(ZeroconfServer.java:367) ~[librespot-player.jar:1.6.3]
        at xyz.gianlu.librespot.ZeroconfServer.access$200(ZeroconfServer.java:56) ~[librespot-player.jar:1.6.3]
        at xyz.gianlu.librespot.ZeroconfServer$HttpRunner.handleRequest(ZeroconfServer.java:499) ~[librespot-player.jar:1.6.3]
        at xyz.gianlu.librespot.ZeroconfServer$HttpRunner.handle(ZeroconfServer.java:574) ~[librespot-player.jar:1.6.3]
        at xyz.gianlu.librespot.ZeroconfServer$HttpRunner.lambda$run$1(ZeroconfServer.java:482) ~[librespot-player.jar:1.6.3]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
        at java.lang.Thread.run(Thread.java:829) [?:?]
2023-06-30 12:04:55,744 ERROR ZeroconfServer:501 - Failed handling addUser!
java.net.SocketException: Broken pipe (Write failed)
        at java.net.SocketOutputStream.socketWrite0(Native Method) ~[?:?]
        at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:110) ~[?:?]
        at java.net.SocketOutputStream.write(SocketOutputStream.java:138) ~[?:?]
        at xyz.gianlu.librespot.ZeroconfServer.handleAddUser(ZeroconfServer.java:382) ~[librespot-player.jar:1.6.3]
        at xyz.gianlu.librespot.ZeroconfServer.access$200(ZeroconfServer.java:56) ~[librespot-player.jar:1.6.3]
        at xyz.gianlu.librespot.ZeroconfServer$HttpRunner.handleRequest(ZeroconfServer.java:499) ~[librespot-player.jar:1.6.3]
        at xyz.gianlu.librespot.ZeroconfServer$HttpRunner.handle(ZeroconfServer.java:574) ~[librespot-player.jar:1.6.3]
        at xyz.gianlu.librespot.ZeroconfServer$HttpRunner.lambda$run$1(ZeroconfServer.java:482) ~[librespot-player.jar:1.6.3]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
        at java.lang.Thread.run(Thread.java:829) [?:?]
2023-06-30 12:04:56,015 INFO  Session:1422 - Skipping unknown command {cmd: 0x75, payload: 000000}
čen 30 12:05:25 jules-ntb systemd[1]: Stopping A spotify playing daemon...
čen 30 12:05:26 jules-ntb systemd[1]: librespot-java.service: Main process exited, code=exited, status=143/n/a
čen 30 12:05:26 jules-ntb systemd[1]: librespot-java.service: Failed with result 'exit-code'.
čen 30 12:05:26 jules-ntb systemd[1]: Stopped A spotify playing daemon.
čen 30 12:05:26 jules-ntb systemd[1]: librespot-java.service: Consumed 3.424s CPU time.

I wonder if https://github.com/librespot-org/librespot-java/issues/445#issuecomment-1006725762 holds the answer:

It is currently not possible to retrieve playlist-read tokens from Facebook/Spotify originated tokens (will return 403, like describe in https://github.com/librespot-org/librespot-java/issues/370). That scope is mandatory for initializing the mercury connection which we still rely on.

What type of devices are you using to connect to librespot with? When I tried it yesterday (working) I was running librespot on Linux and connecting from the Android app. I've just tried running librespot on Windows and connecting from the Windows app but now I see error 403 from hm://keymaster/token/authenticated. Annoyingly, for some reason the Android app can't see librespot running on my Windows box, which I really wanted to test. Maybe someone else will have more luck there.
The way login works on their Windows client has definitely changed from what I remember. You now have to do an OAuth login through your web browser which provides their app with an "Authorization Code" which it then exchanges for an access token. I am guessing it then uses that access token to create a Mercury session (usingauth type AUTHENTICATION_SPOTIFY_TOKEN??) from which to obtain stored credentials, those stored creds are then used with login5.spotify.com/v3/login - which seems to provide another access token that's used for everything interesting via spclient.wg.spotify.com.
So maybe there is something different with the credentials blob passed via discovery, depending on what client you use? And some blobs don't have permission (scope) to access keymaster. Can anyone else help test that theory?

You may be onto something here. From what I remember, the Windows client indeed uses a different keymaster ID. In dev I made changes to better mimicking that actual behavior and do the “right thing” per platform instead of using the same ID everywhere. And/or I think I am also sending the actual client ID gotten from discovery instead of a hardcoded one.
Finally I rarely used Spotify on Windows so probably haven’t properly tested it either.

In my case librespot runs on Linux and so do the players either via the web player in a browser or the Linux desktop client, which is AFAIK basically an electron app so basically the web client. I will check again but I don't remember having any luck from my Android phone either.
I also made sure to be signed in directly to Spotify and not Facebook or Google if that makes a difference.

I've had success getting the bearer access token using login5 instead of keymaster with https://github.com/kingosticks/librespot/tree/auth-token-from-login5. This is currently what the official Windows client does and is (something like) what we should move towards anyway. I'm not 100% sure if I have broken anything else with this hack, I was very surprised it just worked. I think this will also unblock https://github.com/librespot-org/librespot/pull/1098 which is nice.

@kingosticks That works for me as expected so far with the Linux desktop client. I think you're on the right track and big thanks for figuring this out.

I've had success getting the bearer access token using login5 instead of keymaster with https://github.com/kingosticks/librespot/tree/auth-token-from-login5.

Was it a problem to get a bearer token? For some reason I thought it just wasn't implemented

That's correct. I could have phrased that better. What I meant to say is I had success fixing playback by implementing login5 and obtaining an access token that way. Just as you had suggested doing in a previous issue somewhere - thanks for the tip.

I can confirm that @kingosticks branch is working for me on linux with linux and android clients too...

I can confirm that current dev works only when initiated from iOS client, but not when initiated from macOS desktop client. (So it has most certainly nothing to do with my internet connection.) I can also confirm that initiation from desktop macOS app now works with the branch from @kingosticks . Unfortunately, with this branch, playback from iOS client results in an error:
[2023-07-02T12:43:52Z INFO  librespot_core::spclient] Resolved "gew4-spclient.spotify.com:443" as spclient access point
[2023-07-02T12:43:52Z ERROR librespot_connect::spirc] ContextError: Error { kind: InvalidArgument, error: StatusCode(400) }
[2023-07-02T12:43:52Z ERROR librespot_playback::player] Unable to load audio item: Error { kind: InvalidArgument, error: StatusCode(400) }
[2023-07-02T12:43:52Z ERROR librespot_playback::player] Skipping to next track, unable to load track <SpotifyId("spotify:track:16weYq1yI3d7pyjkRLYlrY")>: ()
[2023-07-02T12:43:52Z ERROR librespot_playback::player] Unable to load audio item: Error { kind: InvalidArgument, error: StatusCode(400) }

Can you get a log with more debug. I don't have Apple devices.
I wonder if this is because spclient.request is now always sending a client-token header along with the auth token it got from login5. Perhaps some requests don't like that.

I had the same 403 problem, and it was also solved by using @kingosticks branch.
I now have librespot running on piCore (14.0) and Raspbian (11 Bullseye), connecting to with the windows and android spotify app, all working fine. Thanks kingosticks!

Thank you @kingosticks. Here is a more detailed log when using the iOS app:
[2023-07-03T19:11:59Z INFO  librespot_core::spclient] Resolved "gew4-spclient.spotify.com:443" as spclient access point
[2023-07-03T19:11:59Z DEBUG librespot_core::spclient] Client token unavailable or expired, requesting new token.
[2023-07-03T19:11:59Z DEBUG librespot_core::http_client] Requesting https://clienttoken.spotify.com/v1/clienttoken
[2023-07-03T19:11:59Z DEBUG librespot_playback::player] command=EmitSessionClientChangedEvent("58bd3<redacted>aaa033eb3", "iPhone", "Apple", "iPhone")
[2023-07-03T19:11:59Z DEBUG librespot_playback::player] command=EmitVolumeChangedEvent(58958)
[2023-07-03T19:11:59Z DEBUG librespot_playback::player] command=EmitAutoPlayChangedEvent(false)
[2023-07-03T19:11:59Z DEBUG librespot_playback::player] command=EmitFilterExplicitContentChangedEvent(false)
[2023-07-03T19:11:59Z DEBUG librespot_playback::player] command=EmitShuffleChangedEvent(false)
[2023-07-03T19:11:59Z DEBUG librespot_playback::player] command=EmitRepeatChangedEvent(false)
[2023-07-03T19:11:59Z DEBUG librespot_playback::player] command=SetAutoNormaliseAsAlbum(true)
[2023-07-03T19:11:59Z DEBUG librespot_playback::player] command=Load(SpotifyId("spotify:track:49ceentvDOPJFsRNrwYrfb"), false, 154071)
[2023-07-03T19:11:59Z DEBUG librespot_core::spclient] Client token unavailable or expired, requesting new token.
[2023-07-03T19:11:59Z DEBUG librespot_core::http_client] Requesting https://clienttoken.spotify.com/v1/clienttoken
[2023-07-03T19:11:59Z ERROR librespot_connect::spirc] ContextError: Error { kind: InvalidArgument, error: StatusCode(400) }
[2023-07-03T19:11:59Z TRACE librespot_connect::spirc] ==> kPlayStatusPause
[2023-07-03T19:11:59Z TRACE librespot_connect::spirc] Sending status to server: [kPlayStatusPause]
[2023-07-03T19:11:59Z ERROR librespot_playback::player] Unable to load audio item: Error { kind: InvalidArgument, error: StatusCode(400) }
[2023-07-03T19:11:59Z ERROR librespot_playback::player] Skipping to next track, unable to load track <SpotifyId("spotify:track:49ceentvDOPJFsRNrwYrfb")>: ()
[2023-07-03T19:11:59Z DEBUG librespot_connect::spirc] Marked <TrackRef { gid: Some([136, 77, 47, 10, 225, 144, 68, 201, 158, 81, 189, 104, 177, 182, 125, 153]), uri: None, queued: None, context: Some("NonPlayable"), special_fields: SpecialFields { unknown_fields: UnknownFields { fields: None }, cached_size: CachedSize { size: 0 } } }> at 3 as NonPlayable
[2023-07-03T19:11:59Z DEBUG librespot_playback::player] command=Preload(SpotifyId("spotify:track:2DI0lPhJcYHHO0DDv7VUxj"))
[2023-07-03T19:11:59Z DEBUG librespot_playback::player] Preloading track
[2023-07-03T19:11:59Z DEBUG librespot_core::spclient] Client token unavailable or expired, requesting new token.
[2023-07-03T19:11:59Z DEBUG librespot_core::http_client] Requesting https://clienttoken.spotify.com/v1/clienttoken
[2023-07-03T19:11:59Z ERROR librespot_playback::player] Unable to load audio item: Error { kind: InvalidArgument, error: StatusCode(400) }
[2023-07-03T19:11:59Z DEBUG librespot_playback::player] Unable to preload SpotifyId("spotify:track:2DI0lPhJcYHHO0DDv7VUxj")

Hi - will the @kingosticks's PR be merged? I don't know if the solution is optimal but for me it works :)

If he can make it a PR? Currently it’s in one of his branches but not yet a PR here.

I can't remember what state it is in. I'll take a look when I get time

I can confirm that @kingosticks branch fixes it for me. Any chance this get merged?

I'm away for the next week without a computer. Anyone who has the time is welcome to take the code and submit a PR. I can't remember what state I left it in.

I've create a pull request with the changes of @kingosticks , I am not an experiences github user, so I hope I did it right..
Thank you @kingosticks  for providing this solution.

Have you tested this change with an iOS client? Because it then broke for me on iPhone

No, but I can test it with an iPhone, I'll be back.

Please test the case when iPhone makes the first connection. So after (re)starting librespot.

I've rebooted the Raspberry Pi, connected to the spotify connect device in the iPhone spotify app, and it worked.
We played around a bit, skipped to the middle of the song, skipped to the next song, let it go to the next song automatically, and it all worked fine.

Okay, great. I only had a problem when the iOS client did the authentication, but that was some weeks or even months ago (I am currently not a Premium subscriber anymore, so I can't test). But if I remember correctly, when using with @kingosticks' change iOS client couldn't authenticate:

librespot (re)starts, macOS client authenticates, iOS also works then
librespot (re)starts, iOS tries authentication, doesn't work

If it works now, that would be great.


Handle and report invalid notify(err) argument. Fixes #110.

notify(err…) now catches and reports the case where err=null|undefined|0.
An error-level log is printed and Error is constructed and sent to Bugsnag
with the offending parameter. All of the arguments are captured and sent
in the report's metadata too, to help provide context for when this happens.

Some examples of this in use:
Log output

Dashboard


Improve help command

Description

Modifies UserGuide.md to reflect updated help command (closes #15)
Modifies help window to show a dropdown of brief instructions for each command in LingoGO! (closes #26)

Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Code quality improvements
[ ] CI workflow improvements

How to test

Click on the help button on the menu bar or press F1 to bring up the help window
Click on each of the dropdowns to make sure that each help message is visible
Check that the relevant parts of the User Guide related to the help command are edited

Checklist
None

Codecov Report

Merging #39 (13b8e3c) into master (ce4f2cf) will decrease coverage by 2.04%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master      #39      +/-   ##
============================================
- Coverage     72.15%   70.11%   -2.05%
  Complexity      399      399
============================================
  Files            70       72       +2
  Lines          1232     1268      +36
  Branches        125      128       +3
============================================
  Hits            889      889
- Misses          311      347      +36
  Partials         32       32

Impacted Files
Coverage Δ

...java/seedu/address/logic/commands/CommandEnum.java
0.00% <0.00%> (ø)

...main/java/seedu/address/ui/CommandHelpMessage.java
0.00% <0.00%> (ø)

src/main/java/seedu/address/ui/HelpWindow.java
0.00% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ce4f2cf...13b8e3c. Read the comment docs.


ztracy: add macos frameworks search path

Fixes ztracy build for macOS. Without this, compiling Tracy cpp client fails with fatal error: 'mach/mach_vm.h' file not found

Yes, I saw this and didn't know how to fix. Many thanks!


chore: update Poetry to 1.5.1 (last version supporting Python 3.7)

:tada: This PR is included in version 0.4.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Engine dependency change forced by dependency change to Watson nodes

Minimum requirement imposed by SDK for watson-developer-cloud is for
"node": ">=4.5.0"

I have signed the node-red CLA agreement, but this is still showing 'No CLA on record'

What version of node does the boilerplate end up with currently? I'd expect it to be the latest node 4.x version ... which would satisfy the 4.5 requirement.

I think currently its 4.7.2, so yes it will satisfy the 4.5 requirement.


Explicitly delimit EOM for logging

Desired behavior
The Console (i.e., logging) abstraction in libsdformat currently follows the semantics of something like std::cerr -- a simple text stream where the call sites conclude each call with a newline (sdferr << ... << "\n";).  Even if we switch to use the ignition-common console per #351, it still currently embodies the same abstraction.
However, in a lot of production code, log message telemetry is not just a dedicated console read by human eyes -- it is recorded in a structured form, sent over the network, and/or otherwise treated on a message basis rather a stream basis.
My request here is to change the Console to use the same semantics -- where there is a clear "end of message" demarcation.
Several C++ logging frameworks (e.g., log4cpp) do this by using the logger lifetime to conclude the message.  My patch file in https://github.com/RobotLocomotion/drake/pull/16348 shows an example of this.  The Console::ColorMsg function returns a short-lived stream by-value, instead of a long-lived stream by-reference.  When the statement ends, the temporary is destroyed, and in its destructor the message is posted.
Another technique is what spdlog does -- the user makes a single function call to log, passing both the format string and all of the arguments all at once.  This would be a more significant rewrite of the calling-code than the stream lifetime change, but would be a better choice in case the Console needed to be used from languages beyond just C++.
Alternatives considered
A different design would be to keep the streaming API unchanged, but to have the implementation monitor the character buffer insertions for newlines, and replace all newlines with EOM / log posting.  I am not a fan of that design, because it removes the ability for a single log message to have embedded newlines, which I've often found to be useful.
Additional context
For sdformat in particular, as I've explained in https://github.com/ignitionrobotics/sdformat/issues/334#issuecomment-683985626 the library should never be printing to any console anyway.  The calls to parse should have a structured way to report errors, and should be silent on cerr.  The current design and use of sdf::Error gets us most of the way there, but there are still a ton of places in the library code that stream to sdferr (or sdfwarn, etc.) instead of appending an sdf::Error.  If we fixed that problem instead, then we could delete the sdformat-specific Console class and this whole discussion here is moot (though would still apply to the ignition-common logging API design).

Thanks for the suggestions @jwnimmer-tri. This is definitely something we want to address. My initial thought is to go with the spdlog approach or actually add spdlog as a dependency. It's a lot of work, but it would be the most flexible to change in the long run.

actually add spdlog as a dependency

Agreed that would be a nice alternative to #351. And if it works well on SDFormat, we should consider moving all of Ignition to spdlog.

In the context of a more disruptive change like porting to spdlog, I'd like to underline my "Additional context" paragraph from the original posting.  A parsing library has no business printing to the console in the first place -- we should always use the Error struct instead, and the caller of the parser should be deciding how to display the errors or warnings.
For convenience, maybe the library could offer a "just keep it simple and display the errors to cerr anyway" sugar, but we don't need spdlog for that, we just need a "Dump a vector<Error> to std::cerr" herlp function.  The Error items are already intrinsically message-delimited (each one stands on its own).  Free-form text logging in a parsing library (even if message-delimited) should be an anti-goal; we always need to give the caller of the parser the ability to govern the output to the user.

A parsing library has no business printing to the console in the first place -- we should always use the Error struct instead, and the caller of the parser should be deciding how to display the errors or warnings.

I agree that we should use the Error struct in as many places as possible, but that struct, in its current form, is intended for errors only. We need some other mechanism to emit warning or informational messages. We could create other structs for such messages and instead of returning std::vector<Error>, we could return a Result type that can be queried for error, warning, and informational messages separately. This would require a major refactor and change of APIs though. IMO, it would be simpler to use spdlog or something similar.

Many uses of sdfwarn are communicating real problems, and there should be some mechanism for the user to notice them (e.g., when asking to parse in the strictest mode), other than watching the console output.
https://github.com/ignitionrobotics/sdformat/blob/53b9d8ef57f0971929ed92f21243a7c71daddd34/src/Model.cc#L186-L188
https://github.com/ignitionrobotics/sdformat/blob/53b9d8ef57f0971929ed92f21243a7c71daddd34/src/parser.cc#L1153-L1156
https://github.com/ignitionrobotics/sdformat/blob/53b9d8ef57f0971929ed92f21243a7c71daddd34/src/parser.cc#L1174-L1178
https://github.com/ignitionrobotics/sdformat/blob/53b9d8ef57f0971929ed92f21243a7c71daddd34/src/parser.cc#L1206-L1209
https://github.com/ignitionrobotics/sdformat/blob/53b9d8ef57f0971929ed92f21243a7c71daddd34/src/World.cc#L206-L208
https://github.com/ignitionrobotics/sdformat/blob/53b9d8ef57f0971929ed92f21243a7c71daddd34/src/World.cc#L288-L291
https://github.com/ignitionrobotics/sdformat/blob/53b9d8ef57f0971929ed92f21243a7c71daddd34/src/ParamPassing.cc#L326-L329
If the answer is that they should all be using the Error struct instead, with the option for the user to choose EnforcementPolicy::WARN to gloss over them, that's fine.  If that's the case, then there would be no more remaining uses of sdfwarn in the tree -- other than a few places when parsing SDFormat data declared to be version 1.6 or earlier.
There are no calls to sdfmsg in the sdf12 tree, other than tests.  (I have no objection to using it in tests.)
I think that calls to sdfdbg go into the log file only by default.  In which case, there is no problem keeping it as-is.  The information is not critical, and in any case doesn't spam the console.
In short, I don't buy this statement:

We need some other mechanism to emit warning or informational messages.

Can you link to any example in the code that's emitting an informational message to the console, but that should never actually be communicated to the calling code in a structured way beyond the console?  I couldn't find any.

If the answer is that they should all be using the Error struct instead, with the option for the user to choose EnforcementPolicy::WARN to gloss over them, that's fine. If that's the case, then there would be no more remaining uses of sdfwarn in the tree -- other than a few places when parsing SDFormat data declared to be version 1.6 or earlier.

If the user chooses EnforcementPolicy::WARN, is that idea to still print the warning messages to the console? If so, that would satisfy the need for a mechanism to emit warning messages. You're right about sdfmsg being only used in tests, so ignore the part about informational messages.

If the user chooses EnforcementPolicy::WARN, is that idea to still print the warning messages to the console?

Yes, I think so.
Users who want something more specific can parse and receive the std::vector<Error>& to do with as they wish.  If they don't ask for the errors back (e.g., by calling the simple readFile(filename), instead of the more detailed readFile(filename, errors)), then displaying the warnings and/or errors to the console by default at that point is fine by me.
I haven't tried to weave these specific ideas in the current API, so there are probably a few loose ends still to design.  I just have the one big-picture idea: it's fine if we have a Console class to help with streaming messages to the terminal, but it can only exist at the very outermost / highest layer of the parsing code.  The parsing code should to produce a structured list of errors (of varying severity).  If the user doesn't specify what to do with that list once the parsing is complete, then it's fine to just print it out.  The only problem with printing is having the lower-layer code do it outside of the caller's control.

We have started (#939 being the first PR) adding sdf::Error parameters to lower level parsing code that previously would print to the console.

Since we don't have a separate data structure for warnings, for now, the plan is to handle them by updating all sdfwarns to use enforcement policies. Then users can either get warnings on the console if enforcement policy is WARN, or in the Errors data structure if enforcement policy is ERR.

Per VC, remaining work is 2 PRs to be filed soon.


Google oidc sends redirect_uri with 'http' ignoring base_url

Google oidc provider sends redirect_uri with 'http' ignoring base_url
OVERWRITE_REDIRECT_URI doesn't help.

@korjavin You can change the scheme with environment variable FLASK_OIDC_SCHEME.
Set that to https and you should be good, I had the same issue today.

Madre mia.
It worked. I'd call this user-friendly.
Thank you!


Other Features Page

Get this page working. Accessed in the notebook from the More menu. There is already a placeholder page. See StraboSpot 1 for functionality. No forms asset used for this page.

fixed with commit 1cfdba6ca7a426fc1329bf9092221c15d7b4c4f6


Add a flag in the code generator to always use the candid name instead of an alias.

Please add a flag on the Code Generator so that you can always use the same names as represented on Candid and avoid using the attribute [CandidName].

Im just going to have it not include by default. I might add a flag later, but only if requested
Fixed in #44

Can we add a configuration flag so that the names are never changed? for example if candid says a field is named "id" it will be named "id" also in C#.


packet optimization

I think that we can increase the performance of multiogar immensely if we were to not have the packets be classes but rather have them be in an object that can be reused and to no longer use the buffer writer and buffer reader classes. Example new Packet.UpdateNodes(this, [], [], [], this.clientNodes) could be changed to Packet.BuildUpdateNodes(this, [], [], [], this.clientNodes) and Packet would be an object with many functions and helper functions but it would only be created once.

I don't think you can optimize performance in such way. And even mode performance it may decrease performance.
It's due to specific of memory management in languages with GC.
JIT compiller is smart enough to reuse memory for small object which is allocated and released for short time. So, actually it already works in suggested way.
But if you will hold object for a long time it will prevent GC to manage memory fast and efficiently. It will leads to memory leaks and longer time for memory allocation.
So, it's better for performance to create a lot of small objects for a short period of time, than allocate one big object and keep it forever.

you can run the server with profiling and see how much time is used for memory allocation.
new Packet.UpdateNodes takes for about 0.01 % of execution time.
Cell lookup and resolve collision takes for about 75% of execution time.
Cell sort takes for about 5 % of execution time.
WebSocket.send takes for about 20% of excecution time (inside WebSocket code).
So, there is nothing to optimize. new Packet very fast, and I don't think that you can make it faster.


Link to "Initial research on the wiki" in README.md is dead

https://github.com/rust-lang/rust/wiki/Lib-datetime redirects to https://github.com/rust-lang/rust

Oh, the wiki is now (somehow) dead. I assume the page is now https://github.com/rust-lang/rust-wiki-backup/blob/master/Lib-datetime.md, thank you for noticing that.


Add the hardware meet up to community events

https://www.meetup.com/edmontonunlimited/events/pcwlzsyfchbpb/
An example event, not really sure what to link to since they don't have a website, so just a past event should be good.
Second thursday of every month.

They also do not have a logo so this card might be kind of bland


Fix codestyle

I'd like to improve your project within hacktoberfest, but before to start resolving issues we need to fix codestyle. This project has eslint as linter, but there're problems:
80 problems (64 errors, 16 warnings)

I try to decrease the number of codestyle errors and warnings, current result is:
14 problems (2 errors, 12 warnings)

In the next pull request we should complete some plugins to resolve other codestyle error and warnings

@CapacitorSet Could you write about your plans abouth this PR? Do you plan to accept or close? :)

I've been discussing both the PR and the use of linting in a developer chat, @crisbal should be able to review your PR by today.

Thanks for the PR! Happy Coding


Start  arktos-network-controller for kube-up

What happened:
arktos-up already support arktos-network-controller, but kube-up still doesn't support. this should be fixed.
What you expected to happen:
kube-up support arktos-network-controller and default start it.
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
https://github.com/CentaurusInfra/arktos/pull/1190
https://github.com/CentaurusInfra/arktos/pull/1198
https://github.com/CentaurusInfra/arktos/pull/1199
Environment:

Arktos version (use kubectl version):
Cloud provider or hardware configuration:
OS (e.g: cat /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Network plugin and version (if this is a network-related bug):
Others:

fixed with PR #1298


Help rst man

Changes

fix #339  by updating the python script that generates the rst files

I still see some errors


kotel: error while marshaling: string field contains invalid UTF-8

With the kotel tracing plugin enabled, try producing a record where the record contains an invalid utf-8 sequence. It ends up dropping the span.
client.ProduceSync(ctx, &kgo.Record{
	Key:   []byte{0xe2, 0x28, 0xa1},
	Value: []byte{},
	Topic: topic,
})

traces export: rpc error: code = Internal desc = grpc: error while marshaling: string field contains invalid UTF-8

I'm happy to submit patches, just making the issue known.

Yes it was known on the original issue ;) https://github.com/twmb/franz-go/pull/294#issuecomment-1416350683
I think this can be resolved with one or two options:
// EscapedUTF8 replaces any invalid UTF-8 with the UTF-8 replacement character
// (more doc on why)
func EscapedUTF8() TracerOpt
// StrictUTF8 drops any tracing span that contains invalid UTF-8 (more doc why)
func StrictUTF8() TracerOpt

Actually, I think we should just always check utf.ValidString and, if not valid, always do the replacing. The options are more confusion.

I'm not sure using the replacement character is advised. Some keys are just straight binary.
Maybe if not valid utf-8 use some reasonable text encoding base64, hex, w/e so a user can reverse it?

That feels like something that might rather be option driven, HexEscapeKeys or something. I'd expect that a person using otel would also only use keys that are valid in open telemetry, rather than trying to directly log binary data in a utf8 text field. Is that not the case?

I don't think that is the case at all.
I may want to use otel but I use protobufs or avro binary formats for my keys+values.

Given that documentation, there is no clear canonical string form of a binary key, and we should just drop it. That seems to me that the default behavior should be:

either drop keys with invalid utf-8 by default, or use the utf-8 replacement character
add KeyEscaping(how KeyEscapeHow) option
Add HexEscape, HexEscapeInvalid, Utf8InvalidCharReplace options
?

I agree with drop if invalid on default. If absolutely necessary someone could take the topic+partition+offset info and go lookup the key in question.
For protobuf and avro there do exist canonical json representations that would meet the needs of the MessagingKafkaMessageKeyKey documentation (just as an example).
I think its good to provide an option to let users decide how they want to encode things if they need to but I don't think its necessary to have to carry around a bunch of different implementations.
In other otel libs like the http or sql libs I find myself customizing the spans based on the things they are instrumenting and having the options that let me customize it is great and they don't need to anticipate my wonky needs ahead of time, they just give me control in the places I need it.
So I wouldn't even phrase it like KeyEscaping, I think KeyFormatter would be better. I could pass an implementation that turns all my protobufs into their json forms, or just does hex escaping. You don't need to know or care.

// KeyFormatter specifies a formatting function to run on record keys before
// adding them to a span's attributes. This can be used to escape invalid
// utf-8 (if your keys may not be strictly text) or apply hex escaping, protobuf
// unmarshalling, etc.
func KeyFormatter(func([]byte) ([]byte, error))

// Utf8Formatter is a KeyFormatter that replaces all invalid UTF-8
// characters with utf8.RuneError, the UTF-8 replacement character.
func Utf8Formatter(key []byte) ([]byte, error) {
  if utf8.Valid(key) {
    return key
  }
  ...
}

Good idea on KeyFormatter.
So,

Drop invalid by default
Support KeyFormatter
Provide Utf8Formatter as a drop in replacement character fix

Let me know if you'd like to get to this today, otherwise I'll push a PR anytime between 2 hours from now and when I go to bed -- I think we're in agreement on how to proceed.

I can't pick it up til Monday, but I am willing to do it.
I wonder if KeyFormatter may need some additional context like the topic the thing is on? Maybe even passing the entire record?

Monday works -- I was aiming to close all issues today / tag a new release, but the plugin can be released separately.
I worry a bit about the whole record being overkill, do you anticipate much of a use for the other fields? Overall, it should be ok, though.
KeyFormatter(func(*kgo.Record) ([]byte, error)

If any error is returned, the key is not added as an attribute. Either way, both solutions are ok to me.

I could see key, topic, headers, and context being useful.
If using the schema registry topic + first few bytes of the key should be enough to figure out what the key type is.
context could be useful if I'm being cheeky and smuggling some extra information in it for the key formatter to use.
Headers if there is some identifying information being sent.

Sorry something came up today.

And more things came up. Sorry.

Thanks for looking at this. In case anyone's wondering, here's what the otel spec says about the key:
"If the key type is not string, it's string representation has to be supplied for the attribute. If the key has no unambiguous, canonical string form, don't include its value."
https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/messaging.md#apache-kafka

@twmb Awesome thanks for the change.


VERSION in init seems to be incorrect

Howdy, like the title says, looks like there was a spot missed in the 3.3 release (still claims to be 3.2.1)
https://github.com/jsocol/pystatsd/blob/1c90b9fdf322680e2625da659abc2aa5d79b5bff/statsd/__init__.py#L8

Fixed in v4 release


Bump dependencies from 1.3.8 to 1.3.9

This might fail because web3 needs to get bumped up in token/js and token-swap/js.  In each, client/util/send-and-confirm-transaction.js will need to correctly call sendAndConfirmTransaction with the new parameters:
  return realSendAndConfirmTransaction(connection, transaction, signers, {
    skipPreflight: true,
    commitment: 'recent',
  });

@joncinque I'm not aware of any incompatibilities between 1.3.8 and 1.3.9. I don't expect any issues with using an older web3

@jstarry I might have it wrong, but I wanted to flag it up in case an issue does come up

Looks good!  Maybe what I was seeing had to do with web3 updates then

Ok, thanks!


Pods are stuck with message Waiting to Find IP

I am running into a problem in Kubernetes where sometimes the pods are stuck in terminating or creating status whille the kubelet docker continuously giving the following error:
E0415 00:05:14.797122   30297 manager.go:1858] Failed to create pod infra container: RunContainerError; Skipping pod "nginx_default(ffafa7e4-029c-11e6-9a27-0286285ab4f0)"
E0415 00:05:14.797296   30297 pod_workers.go:138] Error syncing pod ffafa7e4-029c-11e6-9a27-0286285ab4f0, skipping: failed to "StartContainer" for "POD" with RunContainerError: "InspectContainer: Failed to find IP for d120f3d41e6baa3d84f569fcc32abd0794426a704a179c3a2a7ff630dd4f3f77"
E0415 00:05:14.986563   30297 generic.go:229] PLEG: Ignoring events for pod nginx/default: Failed to find IP for d120f3d41e6baa3d84f569fcc32abd0794426a704a179c3a2a7ff630dd4f3f77
I0415 00:05:15.006770   30297 rancher_docker.go:78] Waiting to find IP for d120f3d41e6baa3d84f569fcc32abd0794426a704a179c3a2a7ff630dd4f3f77
I0415 00:05:15.522705   30297 rancher_docker.go:78] Waiting to find IP for d120f3d41e6baa3d84f569fcc32abd0794426a704a179c3a2a7ff630dd4f3f77
I0415 00:05:16.009332   30297 rancher_docker.go:78] Waiting to find IP for d120f3d41e6baa3d84f569fcc32abd0794426a704a179c3a2a7ff630dd4f3f77
I0415 00:05:16.037606   30297 rancher_docker.go:78] Waiting to find IP for d120f3d41e6baa3d84f569fcc32abd0794426a704a179c3a2a7ff630dd4f3f77
I0415 00:05:16.539579   30297 rancher_docker.go:78] Waiting to find IP for d120f3d41e6baa3d84f569fcc32abd0794426a704a179c3a2a7ff630dd4f3f77
I0415 00:05:16.551580   30297 rancher_docker.go:78] Waiting to find IP for d120f3d41e6baa3d84f569fcc32abd0794426a704a179c3a2a7ff630dd4f3f77
I0415 00:05:17.053683   30297 rancher_docker.go:78] Waiting to find IP for d120f3d41e6baa3d84f569fcc32abd0794426a704a179c3a2a7ff630dd4f3f77
I0415 00:05:17.068038   30297 rancher_docker.go:78] Waiting to find IP for d120f3d41e6baa3d84f569fcc32abd0794426a704a179c3a2a7ff630dd4f3f77
I0415 00:05:17.568082   30297 rancher_docker.go:78] Waiting to find IP for d120f3d41e6baa3d84f569fcc32abd0794426a704a179c3a2a7ff630dd4f3f77
I0415 00:05:17.584320   30297 rancher_docker.go:78] Waiting to find IP for d120f3d41e6baa3d84f569fcc32abd0794426a704a179c3a2a7ff630dd4f3f77
I0415 00:05:18.080864   30297 rancher_docker.go:78] Waiting to find IP for d120f3d41e6baa3d84f569fcc32abd0794426a704a179c3a2a7ff630dd4f3f77

The mentioned ID is for the docker container:
d120f3d41e6b        gcr.io/google_containers/pause:2.0   "/pause"                 6 minutes ago       Up 6 minutes                                                       k8s_POD.cf58006d_nginx_default_ffafa7e4-029c-11e6-9a27-0286285ab4f0_9e19cf89

The problem is that i can't always reproduce the problem but i had this issue several times with different situations.
Rancher Version: 1.0.0
K8s is running on top of two 2G machines on digitalocean machine.

Running Rancher 1.0.1 + K8s on AWS and get the same error message

Running Rancher 1.0.1 + K8s on Ubuntu 16.04 and get the same error message if hostnetwork=true for a pod.

@liyimeng network-mode=Host bug was fixed in Rancher dev2: https://github.com/rancher/rancher/issues/4534
@AlmaasAre @galal-hussein in your case, was it the default network, or host network as well?

@alena1108 it was the default network.

Default
On Sat, 28 May 2016 at 01:51 Hussein Galal<EMAIL_ADDRESS>wrote:

@alena1108 https://github.com/alena1108 it was the default network.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rancher/rancher/issues/4419#issuecomment-222276299,
or mute the thread
https://github.com/notifications/unsubscribe/ABse1jRHDOGfATG-f8TGzLZBmkpeusSpks5qF4NogaJpZM4IH5o6
.

@AlmaasAre if the environment is still around, could you check one thing. In Rancher DB, see if you can find a container with external_id = docker container id:
select * from instance where external_id=<docker container id>

We back populate all the containers started either by docker natively, or via kubernetes, to Rancher. And these containers' external ids = docker container ids. When container starts in kubernetes, we also get the ip address assigned to the container by Rancher. This particular bug is caused by inability to locate container in Rancher based on docker container id.

Also if the container with the externalId = docker container id does exist, could you locate it using rancher API and see if the "primaryIpAddress" field is set.

Im sorry @alena1108 , i don't have the environment still up and running. But might check it out later. Thanks for answer :)

@AlmaasAre thank you, please update this bug if you hit it again.
@galal-hussein  ^^ :)

https://github.com/rancher/rancher/issues/5902

Closing as a duplicate of #5902


Rename BatchElementError

What
Rename BatchElementError, do not change any of its functionality or values.
Why
BatchElementError doesn't fully capture the conceptual basis under which it is used, and is in fact actively misleading, as it makes one believe the reason for the error is related to batching, but in actual fact, this is an error used for any problems with the input data to a method.
Thus far, this hasn't really mattered because all methods are batch, and all errors were to do with a batch element, however with the addition of singular conveniences, and more recently and starkly the Paging methods, the type is showing its misnaming more and more.
Acceptance Criteria

[ ] TODO, come up with name.
[ ] TODO Plan for all the breaking change impact.

Closing as (through off line discussion) we realized that the majority of these concerns have been mitigated by changes to the pager workflows, other refinements to the exception/error handling behavior, and being happy that surfacing the 'batch first concept' is inherently valuable.


Integration with web-based IDE

Codecov Report

Merging #196 into master will increase coverage by 0.02%.
The diff coverage is 98.27%.

@@            Coverage Diff             @@
##           master     #196      +/-   ##
==========================================
+ Coverage   98.42%   98.45%   +0.02%
==========================================
  Files          62       64       +2
  Lines        2349     2453     +104
==========================================
+ Hits         2312     2415     +103
- Misses         37       38       +1

Impacted Files
Coverage Δ

cli-commands/commands.js
100% <100%> (ø)
:arrow_up:

cli-commands/etherlime-ide/etherlime-ide.js
98.07% <98.07%> (ø)

cli-commands/etherlime-test/etherlime-test.js
100% <0%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cfb8d40...fb4805e. Read the comment docs.


Provide quick fix for suppress warnings

Currently Quick fix code actions for suppress warnings is not provided in the VS Code editor

Merged in NB-23: https://github.com/apache/netbeans/pull/7548

Merged in 23.0.0


Add word-break into ExperimentsTableConfigurator

Before:

After:

ref. #179

oh.. Thank you!! 🙇

self merge!


'escape_encoding' cofiguration not working

Hi I'm using the plates latest dev-master code with composer and I'm trying to change the option to make it work with the ISO-8859-1 charset (I know, but is an old production server and it will not change the charset :| ), but still renders the characters incorrectly:
$engine = League\Plates\Engine::create('./templates');
 $engine->addConfig(['escape_encoding' => 'ISO-8859-1']);

and on my .phtml template the headers:
<meta http-equiv="Content-Type" content="text/html">
<meta charset="iso-8859-1">

and I'm trying to render the template like this:
echo $engine->render("response", ['labelTransaccion' => 'Resultado de la transacción']);

However, I'm getting this result:

What I'm doing wrong?

Thanks @david-chaves i'll take a look at this and get back to you.

I forgot to to add the template code too:

       <?= $v($labelTransaccion) ?>

Hi, any updates on this?

@david-chaves I'm no longer working on the v4 alpha as is, it might be best to use v3 for now.


OSError: [Errno 22] Invalid argument: 'C:\Users\38561\samm\samm-python-terminal\samm-workspace\mask.memmap'

All images have been processed.
ERROR:root:Traceback (most recent call last):
File "C:\Users\38561\samm\samm-python-terminal\sam_server.py", line 272, in main
srv.infer_image(
File "C:\Users\38561\samm\samm-python-terminal\sam_server.py", line 188, in infer_image
memmap = np.memmap(os.path.join(self.workspace, "mask.memmap"), dtype='bool', mode='w+', shape=self.masks[0].shape)
File "C:\Users\38561\AppData\Roaming\Python\Python39\site-packages\numpy\core\memmap.py", line 228, in new
f_ctx = open(os_fspath(filename), ('r' if mode == 'c' else mode)+'b')
OSError: [Errno 22] Invalid argument: 'C:\Users\38561\samm\samm-python-terminal\samm-workspace\mask.memmap'
Everthing went well except the error message.

The error looks like something file lock related. The data transmission will need to be optimized using #10 . Currently, it will still work even with the error. I am going to write an ignore condition.

Thanks for your reply and your excellent work!


Refactor spoof tests

Closes #1331
Introduced changes

Checklist

[x] Linked relevant issue
[x] Updated relevant documentation
[x] Added relevant tests
[x] Performed self-review of the code
[x] Added changes to CHANGELOG.md

Please describe the introduced changes.


Support ocaml-variants switch

The version of an ocaml-variants package version, and the value of Sys.ocaml_version of the installed OCaml do not agree, making the installation of the custom ocaml-system package fail during the sandbox switch creation.
This PR disables this test, which (I think) was anyway not needed in our custom ocaml-system.
This PR needs to add a test for an ocaml-variants switch and a bit more testing, but I already open it to collect possible opinions on this.

Actually I think this is not the right way. I am working on something else.


ci: fix remove-docs workflow

Worked.
https://github.com/autowarefoundation/autoware.universe/runs/4487748273?check_suite_focus=true


BibRank: refactoring of refs linking

Originally by adeiana (@Osso) on 2014-03-26
Currently bibrank is separating the indexing in 2 phases.
First it fetches all the information for the records, then it does finds links.
This does not allow us to:

factor out the linking for a single reference. Currently there's 3 places that find links to references differently (bibformat, docextract and bibrank).
we can't give priority to the recid when looking for references in order to speed up the linking process. As we first search for all journals and repport numbers when we reach the recid lookup we already wasted a lot of time.

There is no PR for this issue, hence closing it as per the legacy code base freeze; it will be addressed in master code base differently.


Helper function to get recently updated partitions

Is your feature request related to a problem? Please describe.
Similar to https://github.com/MrPowers/mack/issues/130 , but for non-Spark projects
For streaming systems (or batch systems that run in high frequency) that write data into delta tables, it's a common problem to have lots of small files. In many cases, it's not practical to auto compact because of various reasons, for example

Auto compaction is not available in Delta lake before 3.1.0
Auto compaction might not be well supported outside Spark

One way to solve this is to have a separate process that perform optimization regularly on these delta tables. However it's not a good idea to optimize the entire table whenever without any constraint. A few example reasons:

While in theory optimize is a no-op if the partitions weren't updated, it still takes some overhead per partition to determine it's a no-op. This could add up quite significantly when you have lots of partitions.
If the optimize operation included z-order, subsequent z-order operations won't be no-op even if the partitions weren't updated

Describe the solution you'd like
A helper function to find out which partitions have been updated between some time period, for example
def get_updated_partitions(delta_table: DeltaTable, start_time: datetime.datetime, end_time: datetime.datetime, exclude_optimize_operations: bool) -> list[dict[str, str]]

The exclude_optimize_operations flag is necessary because optimization operations themselves are also update operations. If the operations are not excluded, they might cause a feedback loop since they will keep showing up in the output.
All the information needed for this features should be available in the transaction log.
Describe alternatives you've considered
Optimizing the entire table and accept the overhead
Not sure what's a good alternative once z-order is used however
Additional context
N/A
Willingness to contribute
Would you be willing to contribute an implementation of this feature?

[x] Yes. I can contribute this feature independently.
[ ] Yes. I would be willing to contribute this feature with guidance from the mack community.
[ ] No. I cannot contribute this feature at this time.

Thanks @huynguyent.  Assigned this one to you!  Looking forward to seeing what you can build!


Invalid string size

Error: Invalid string size 16777216 at position 0x47f10
Got this error when trying to convert the railroads online v1.0 .sav to .json
save file added
PV_main.zip

Thanks for the report, @illudedPerception. The gvas library will need to be updated to support the latest format changes.

Here's a bit more about what's going on:
The FrameNumberArray is an ArrayProperty containing TextPropertys. Inside of the array, there is a sequence of Text objects, most of which are the "None" type (0xff). However, starting at 0x74ef4, there is an AsNumber (0x04) type text object. This object is very suspicious, but doesn't immediately cause any parsing errors. When the parser tries to read the next object, it encounters a Base (0x00) type text object, which fails to parse because the string length is way too large to be a real string.

i will make a new empty save game and see if i still get the same error when tring to convert, there is a new function in the game where buying 10 rolling stock at once the game automatically assigns numbers to them maybe that is messing something up, though the save game works fine in game

A fix is up for review here: https://github.com/localcc/gvas/pull/123

same problem


Sass/Scss compilation -  Quick solution

This mixin will compile '@element' without any errors:
Wrapping the string into comments tags makes the scss compiler think its a scss comment. The scss will compile as valid. The trick is the output wil be un-commented.
(be carefull with mixin double and single quotes)
source: stackoverflow
scss mixin:
@mixin raw ($string) {
  $string: '*/#{$string}/*';
  /*#{$string}*/
}

use:
@include raw('
	@element "body" and (min-width: 480px) {
		$this {
			background: gold;
		}
	}
');

css output:
/**/@element "body" and (min-width: 480px) { $this {background: gold;} }/**/

Hey @Genenenenaam! I had copied this code into a demo on Codepen, but I just realized the pen was set to private. It's public now, so people can play with this and fork it, or copy/paste into their code pretty easily.
http://codepen.io/tomhodgins/pen/VKZZwA/?editors=0100
Thanks so much for sharing this code, it's something people have asked about in the past and I hadn't quite been able to figure out how to escape :D

@tomhodgins This should definitely be a "tip" on the README.

Hello and sorry for reopening this. I've been having issues with EQCSS in my project and narrowed down the issue to the sass preprocessor. Although the code is compiled properly, it's not working - pasting the eqcss queries directly on the compiled css works though.
Tried the raw mixin and getting the same issues. Any ideas?

Hi Nick!
Thanks for checking out EQCSS, and sorry you're having a conflict with the SASS compiler. I can't seem to find your comment on Github at all so I'll reply by email :)
Are you able to show me a sample of EQCSS code that SASS has output that doesn't work? I should be able to look at what it's outputting and be able to tell if there's a syntax problem present. Or a sample of SASS + EQCSS you're trying to compile so I can fiddle with it and see if I can convince SASS to output working code?
I'm not a SASS super user—I usually write my CSS by hand—but I'll take a peek and see what I can think of.
Alternatively to working around EQCSS syntax in SASS, what about keeping your EQCSS queries in a non-SASS-compiled stylesheet? I feel like it's more work to get SASS to output code you know you want than to just write what you want and forgo compiling it :D
Hope you're having a wonderful day,
Tommy

On Nov 29, 2016, at 5:56 AM, Nick Sot<EMAIL_ADDRESS>wrote:
Hello and sorry for reopening this. I've been having issues with EQCSS in my project and narrowed down the issue to the sass preprocessor. Although the code is compiled properly, it's not working - pasting the eqcss queries directly on the compiled css works though.
Tried the raw mixin and getting the same issues. Any ideas?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/eqcss/eqcss/issues/26#issuecomment-263539671, or mute the thread https://github.com/notifications/unsubscribe-auth/AA6U0e3h2LP1SdAa5tYKbS1Q5lW30eugks5rDATGgaJpZM4JUn5J.

Hello Tom,
thanks for your reply. I was struggling for hours to get it to work, and a minute after I posted the comment I found out what was wrong. Although I had used the mixin above, I had forgotten to comment out the initial code in another sass partial, so it was compiled twice.
Truth is, this should be definitely added to the docs. Even without the mixin, the code compiled properly to css, but was not working. Have no idea why. Keeping the code in vanilla CSS worked without issues.

Hi Nick!
I'm hoping to get some proper documentation created for EQCSS, currently there's no obvious spots to put this where people will find it :/ Would you expect to find this sort of documentation here on Github in the Wiki, on the website? What would be useful for a location for documentation? So far all of the stuff written about EQCSS has been in article form, spread across a number of different sites.
We also see questions about Stylus, Less, PostCSS, and using EQCSS with other tools like Angular, React, and Vue, and others. To some degree I'll be relying on users of those tools to help bridge the gaps in knowledge as I can't be an expert on every tool EQCSS can be used with. I can explain how to write EQCSS and describe precisely what EQCSS needs in order to work though.
One thing I'm hoping to do documentation-wise is write an actual spec proposal for the syntax EQCSS uses for container-style element queries. Once an actual proposal for a standardized syntax has been made I think a lot more tools like PostCSS and SASS would feel more comfortable adding their own support for element queries in their own tools, but without even so much as a written spec to propose I doubt any of those tools would do anything from their end to support EQCSS specifically.
Exciting things are coming, with a lot of typing left to do :)

On Nov 29, 2016, at 5:12 PM, Nick Sot<EMAIL_ADDRESS>wrote:
Hello Tom,
thanks for your reply. I was struggling for hours to get it to work, and a minute after I posted the comment I found out what was wrong. Although I had used the mixin above, I had forgotten to comment out the initial code in another sass partial, so it was compiled twice.
Truth is, this should be definitely added to the docs. Even without the mixin, the code compiled properly to css, but was not working. Have no idea why. Keeping the code in vanilla CSS worked without issues.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub https://github.com/eqcss/eqcss/issues/26#issuecomment-263716594, or mute the thread https://github.com/notifications/unsubscribe-auth/AA6U0ZP57wVNlODDHWT9Emoc0Pz7K11pks5rDKNSgaJpZM4JUn5J.

Good to hear that you are putting so much effort in the plugin - totally worth it though.
Concerning the documentation I would have it in all three places - Github, website and Wiki. I would add a separate section and name it something like 'Pre-processors support/compatibility' and add all pre-processors information below - LESS, SASS or whatever else.
D3.js allows documentation to be freely added by the community, so you might also consider this.

Hi @scooterlord, I've created a wiki page here on Github that links to @thejase's solution, as well as information for each preprocessor. As more users contribute knowledge like this we now have a spot to sort, store, and retrieve this information :D Thanks for the encouragement!

Keep it up buddy! Keep in mind that every time you give, to the community, you shall receive it one way or another. :)


Add api stripe checkout integration

Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the main branch of freeCodeCamp.
[x] All the files I changed are in the same world language, for example: only English changes, or only Chinese changes, etc.

Tested this locally with several test cards on the donate page and after completing a certification. The donations all show up on the Stripe's Test Data dashboard, and the redirect after donating on the donation page works as expected.
Everything LGTM :+1: :+1:

@scissorsneedfoodtoo could you give this a final approve if you're happy?  We lost your first review when we added some commits.

Thanks for your patience, and also thanks for catching those things @ojeytonwilliams.
I was having some trouble testing this because it occasionally it would say that the page at /donate/create-stripe-session didn't exist.
It may have been an issue with my cache or keys, though. After checking the keys and doing a hard refresh everything seems to be fine.

Ahmad and I ran into that too, when testing it out. You need all the donation keys to be present for that page to get created. There's a warning, but it's not obvious (we missed it).

Awesome, thanks for confirming that. Good to know it wasn't just me. I remember having trouble until I added the Stripe and PayPal keys back in. They were already present, but I might have accidentally changed one in the .env file without noticing.


[Feature request] make the dev vault part of the repo

Is your feature request related to a problem? Please describe.
I think the vault I use for local development should be part of the repository
Describe the solution you'd like
Additional context
This will make easier to reference examples in the documentation

Done on #315


[Request] Markdown support for the Blog Description under General Settings

Line breaks are especially annoying and hard to do when you don't have markdown's double newline.
I'd personally write this if I had a bit more work with node, but I'm mostly a Java/PHP guy.

The blog description is used for the meta description which is why there is no formatting and the text field has a character limit.
If you would like to have a full "about us" type description then I would suggest building it into your theme templates or creating a separate page. Alternatively if you would like to suggest it as a feature please use our wishlist so that we can track which ideas have traction.


Add endpoint: mobility/countries

Task
Add end point: /mobility/countries
Should return an array of objects like:
{    country: 'col',    provider: 'acme',    series: 'santiblanko' }
How to do it

Add endpoint /v1/mobility/countries to ./api/swagger/swagger.yml
Traverse directory structure in ./public/mobility

Background
Providers of mobility data for whole countries drop CSV files into an sftp server. UNICEF syncs with these servers, aggregates the data by various shapefiles, and stores in the directory structure below.

More background
https://medium.com/@mikefabrikant/unicef-challenge-iii-store-mobility-in-a-database-6d8b0cd46c34

NOTE: this issue was used for a workshop demonstration. Not a real issue here. The actual issue (with corresponding commit history) is #47.


Footer and pagination fix in create and share dialogs

Acceptance

Check that Create Map dialog displays correctly, with a uniform background color.
Check that pagination in Share dialog is aligned with other elements in the footer

Acceptance done following the next steps:

[ ] Login with staging user (dialogfixes2-admin)
[ ] Click in a map "Share with colleagues" option -> check the pagination was correctly aligned in the footer section.
[ ] Click in "Create map" option in a dataset -> check that the modal has a uniform background color.

Acceptance 🆗


TLT-2H new GPRS protocol

Dear.
There are an new protocol for TLT-2H/2HU/2HS/2N with support to GPRS commands and 2-way communication.
https://www.dropbox.com/s/zzcqp2py07pppb7/Communication Protocol.pdf?dl=0
Best Regards
Henrique

Hello guys, how to configure this tracker to work in 2-way keep link?


iwconfig - no wireless extensions

hey im using kali and windows 10 subsystem. but i have any problems to start the monitor-mode.
if i try "iwconfig" it says no wireless extensions...
rootz@Rootkit-Surf:~$ iwconfig
eth0      no wireless extensions.
lo        no wireless extensions.
wifi0     no wireless extensions.
wifi1     no wireless extensions.
wifi2     no wireless extensions.
the output of ifconfig is...
rootz@Rootkit-Surf:~$ ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 1500
inet <IP_ADDRESS>  netmask <IP_ADDRESS>        inet6 ::1  prefixlen 128  scopeid 0x0
loop  (Local Loopback)        RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0        TX packets 0  bytes 0 (0.0 B)        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
wifi0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
inet6 2a02:810a:900:3080:2077:8457:db9:9ce6  prefixlen 64  scopeid 0x0
inet6 2a02:810a:900:3080:a49b:a075:ea28:4d99  prefixlen 128  scopeid 0x0
inet6 fe80::2077:8457:db9:9ce6  prefixlen 64  scopeid 0x0
unspec C4-9D-ED-8B-48-37-00-00-00-00-00-00-00-00-00-00  (UNSPEC)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
wifi2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
inet6 fe80::18d7:3266:7aa:a01  prefixlen 64  scopeid 0x0
unspec C6-9D-ED-8B-4C-36-00-00-00-00-00-00-00-00-00-00  (UNSPEC)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

what should i do to fix that problem?

No template but #1104

how do it


Miri complains about undefined behavior when using index_mut instead of square brackets to access disjoined array elements

This code:
use std::ops::IndexMut as _;

fn main() {
    let mut array = [0, 1];
    {
        let a = unsafe { &mut *((&mut array[0]) as *mut i32) };
        let b = unsafe { &mut *((&mut array[1]) as *mut i32) };
        std::mem::swap(a, b);
    }

    {
        let a = unsafe { &mut *(array.index_mut(0) as *mut i32) };
        let b = unsafe { &mut *(array.index_mut(1) as *mut i32) };
        std::mem::swap(a, b);
    }
}

has Miri report an invalid retag at the second std::mem::swap even though the first and second code block look like they should be equivalent at least semantically. Error message:
error: Undefined Behavior: trying to retag from <2686> for SharedReadWrite permission at alloc1403[0x0], but that tag does not exist in the borrow stack for this location
  --> src/main.rs:14:24
   |
14 |         std::mem::swap(a, b);
   |                        ^
   |                        |
   |                        trying to retag from <2686> for SharedReadWrite permission at alloc1403[0x0], but that tag does not exist in the borrow stack for this location
   |                        this error occurs as part of two-phase retag at alloc1403[0x0..0x4]
   |
   = help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
   = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
help: <2686> was created by a Unique retag at offsets [0x0..0x4]
  --> src/main.rs:12:26
   |
12 |         let a = unsafe { &mut *(array.index_mut(0) as *mut i32) };
   |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: <2686> was later invalidated at offsets [0x0..0x8] by a Unique function-entry retag inside this call
  --> src/main.rs:13:33
   |
13 |         let b = unsafe { &mut *(array.index_mut(1) as *mut i32) };
   |                                 ^^^^^^^^^^^^^^^^^^
   = note: BACKTRACE (of the first span):
   = note: inside `main` at src/main.rs:14:24: 14:25

Is this a Miri bug, or somehow intentional?

This is a known weakness of Stacked Borrows, but is intentional: index_mut receives &mut self, which claims exclusive access to the entire array. The issue is tracked at https://github.com/rust-lang/unsafe-code-guidelines/issues/133. The intended way to write such code in Stacked Borrows is to convert to a raw pointer once and then obtain both a and b from that raw pointer.
Tree Borrows handles such situations better than Stacked Borrows. Can you check whether -Zmiri-tree-borrows makes the code work?
(For the time being it is preferable to make your code work with both Stacked Borrows and Tree Borrows; we are considering both of these models to evaluate their trade-off: Tree Borrows sacrifices some optimizations to make this code legal.)

At the MIR level for arrays and slices [] with usize indexes doesn't desugar to .index_mut(). Just like + on integers and floats doesn't desugar to .add().

Yeah, primitive indexing is special. Tree Borrows doesn't fundamentally fix that specialness, it just makes the index_mut call with its &mut self much less likely to cause trouble.
Closing as an instance of https://github.com/rust-lang/unsafe-code-guidelines/issues/133.

Right, I had heard about that and was wondering if it was related. So the first inner block in main in the issue description works by accident? Or is primitive indexing being special in this way a feature?

As far as I am concerned it is not a feature but just a fact we have to learn to live with. E.g. * on references and raw pointers is also very different from a deref/deref_mut call. I don't think fixing that is realistic.


count all the subgraphs

I am working on save to file method, and I need the total number of subgraphs that are generated at the end. Right now what I have is a global variable int count = 0 and I called it inside theshowTree() method, it returns 78 which is the total number of leaves in the tree. But I only need the bottom level that has the subgraph.

I'll implement it. The ESUTree has a getLeaves() method. If called on the last tree in the treeList, it will return a list of leaf nodes. Then it's just asking the list for its size


Web: mouse treated as touch on iPadOS

Currently if you are using external mouse through assistive touch on iPadOS, the mouse is still treated as touch. It seems that this issue was fixed via https://bugs.webkit.org/show_bug.cgi?id=202789 but didn't land in iOS/iPadOS yet.

To test if what kind of pointer type a point device is treated by the OS, please try https://people.igalia.com/clopez/wkbug/pointer-events/test.html

Maybe the new adaptive cursor on iPadOS 13.4 fixed this issue?

@GalacticLion7 yes I tested on the new iPadOS and it's already fixed, we should reevaluate this issue.


Update the Svelte 5 examples to use the new snippets and event props

In Svelte Summit Fall 2023 a few days ago, Rich Harris announced a few new Svelte 5 changes:

Slots are going away and being replaced with "snippets", a new way to create reusable markup.
Event dispatching and the on: directive is being replaced with regular callback props.
It's now recommended to use classes to encapsulate state instead of objects with getters and setters.

Component Party still uses the old examples, and they should be updated to reflect the new announcements.
I'm happy to write them myself if need be.

Your contribution is welcome !

@TheOnlyTails we still seem to be missing a snippets example

The site doesn't really have any example where snippets are applicable.

As slots are deprecated in v5 then perhaps snippets would sit under slots? But I see your point, removing Svelte slots in favour of snippets in the 'slots' section of the website might be a bit confusing!!

In the slots examples, I did showcase the use of {@render} to insert the children prop, but there is no appropriate place to showcase snippet definition.


Dry-run building on latest commit.

Checklist

[X] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[X] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[X] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

Dry-run was successful.

Actually, I can reuse this PR for the final release.


⚠ Bofrost.lu has degraded performance

In 769770d, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1721 ms

Resolved: Bofrost.lu performance has improved in d05eee0 after 13 minutes.


~OMG JUST WOW~ToDaY'S 06.12.2024~XBOX Gift Card Codes ☄Free Xbox Gift Card Codes ~ 2024 #128~

Hey there, Xbox fans!  We've got something special in store for you - introducing the Xbox Gift Card Generator 2024! That's right, we're bringing you the latest and greatest way to score free Xbox gift cards and elevate your gaming adventures.With the Xbox Gift Card Generator, you can say goodbye to spending your hard-earned cash on game purchases.
👉 👉CLICK HERE TO FREE GENERATOR
👉 👉CLICK HERE TO FREE GENERATOR
Our innovative tool allows you to generate free Xbox gift card codes, giving you access to a world of thrilling games, add-ons, and more, without breaking the bank.
But wait, there's more! We're not just stopping at the Xbox Gift Card Generator - we're also hosting epic Xbox Gift Card Giveaways! Get ready to participate in exciting contests and sweepstakes for a chance to win free Xbox gift cards and unlock a treasure trove of gaming goodness.
And that's not all - we understand the value of in-game currency, which is why we've introduced the Xbox Money Generator. Say hello to a hassle-free way of earning free Xbox money to power up your gaming experience. Whether it's purchasing in-game items or expanding your gaming library, the Xbox Money Generator has got you covered.
For those of you looking for the ultimate gaming treat, the Xbox Free Gift Card is here to make your day. Yes, you heard that right - free gift cards for the Xbox community! It's our way of showing appreciation to our dedicated gamers and making sure you have all the resources you need to conquer new gaming challenges.
Redeeming your Xbox gift cards has never been easier, thanks to the Xbox Gift Card Redeem feature.
Simply enter your gift card code and unlock a world of gaming possibilities. Whether you're a seasoned gamer or new to the Xbox universe, the Xbox Gift Card Redeem feature is designed to make your gaming journey seamless and enjoyable.
So, what are you waiting for? Dive into the excitement of the Xbox Gift Card Generator 2024 and elevate your gaming experience like never before. With free gift cards, giveaways, and a money generator at your fingertips, the possibilities are endless. Get ready to level up and unleash the full potential of your gaming adventures with Xbox!

👉 👉CLICK HERE TO FREE GENERATOR
👉 👉CLICK HERE TO FREE GENERATOR

👉 👉CLICK HERE TO FREE GENERATOR
👉 👉CLICK HERE TO FREE GENERATOR


[es output] improve support for template_file

From what i understand, when using template_file in the es output, the file has to be mounted beforehand in the fluentd container.
What would be the correct way to do it ?
Wouldn't it be possible to put the template inline in the output spec and have the operator generate a secret that is mounted automatically in the fluentd pod ?

Any recommendations please ?

Any recommendations please ?

Thanks @pepov !
Going to try this right now.

Worked like a charm ❤
I guess the same mecanism is supported for ilm ?
Thank you very much !

It depends on which field are you thinking of, but I'm afraid no:
https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/outputs/elasticsearch/

I was thinking about ilm_policy field, looks like it is supported.
Not the same mecanism as for index templates but as long as there's a way to do it it's fine.


Fix dependencies for Debian package generation and modify README.

Fix Debian package dependencies in the CMake file. The generated debian package may now depends on either ZMQ v2 or ZMQ v3. Tested on Ubuntu 14.04.
Modify README to add missing protobuf-compiler package in Ubuntu dependencies.

Thank you!