text:
[tokio] migrate to 0.2.0-alpha.6

Migrate to using tokio 0.2.0-alpha.6.

:umbrella: The latest upstream changes (presumably 89323bf9cc762b03579be91a41eb6f45230c0e03) made this pull request unmergeable. Please resolve the merge conflicts.

futures-semaphore changes LGTM; thanks for taking care of this!

:umbrella: The latest upstream changes (presumably 7472d35547f08dba6a4e74faca2f6e9181241fd5) made this pull request unmergeable. Please resolve the merge conflicts.

@bors-libra r=bothra90

:pushpin: Commit 8e72180 has been approved by bothra90

:hourglass: Testing commit 8e721803bc34de22288a583cf949615ae3ce6520 with merge c5f8309fad27c0226d788aa50cc38abddf40e5f3...

:broken_heart: Test failed - checks-circle_commit_workflow

@bors-libra r=bothra90

:pushpin: Commit 0fb1fb1 has been approved by bothra90

:hourglass: Testing commit 0fb1fb1a32bd1aa0a65a491e2b469bfc89cde8fe with merge 81cd8a0510b2fad2b483ea2f950a8fad8b2bf9e1...

:sunny: Test successful - checks-circle_commit_workflow
Approved by: bothra90
Pushing 81cd8a0510b2fad2b483ea2f950a8fad8b2bf9e1 to master...

authors: bmwill bors-libra phlip9

repo: libra/libra


text:
[cost-synthesis & test-generation] Update creation of identifiers and fix bit rot

Previously we could create invalid identifiers which would cause the
generation to crash. We now make sure that all strings and identifiers
conform to the identifier specification in types.
Also generated modules were previously not representing empty type
parameter info previously. This fixes this as well.
Note that the test generator every one in a while creates some invalid modules due to "NEGATIVE_STACK_SIZE_WITHIN_BLOCK` but this doesn't seem to be coming from the module generation so I'm not going to try and fix this for now.

@bors-libra r=shazqadeer

:pushpin: Commit 26a1b55 has been approved by shazqadeer

:hourglass: Testing commit 26a1b55782e6884f81f80f2f2cf73ac280f7fdd8 with merge 37bc1503d482906aba7497def7eaa53265494000...

:sunny: Test successful - checks-circle_commit_workflow
Approved by: shazqadeer
Pushing 37bc1503d482906aba7497def7eaa53265494000 to master...

source: gharchive/pull-request

authors: bors-libra tzakian

license_type: permissive

license_source: github-api


text:
Added device: Logitech MX Master 3s

Tested and working with all buttons, dpi etc..
output of sudo ratbagd --verbose:
Initializing libratbag
ratbag debug: New device: SYNA7DB5:01 06CB:7DB7
ratbag debug: Using data directory '/usr/local/share/libratbag'
ratbag debug: No data file found for 06cb:7db7
ratbag debug: New device: MX Master 3S
ratbag debug: Using data directory '/usr/local/share/libratbag'
ratbag debug: device assigned driver hidpp20
ratbag debug: hidraw info: bus 0x05 vendor 0x46d product 0xffffb034
ratbag debug: MX Master 3S is device '/dev/hidraw1'.
ratbag debug: Parsing HID report descriptor
ratbag debug: Parsing HID report descriptor
ratbag debug: - HID report ID 02
ratbag debug: - HID report ID 11
ratbag debug: hidpp: device supports long reports

ratbag raw: hidpp write:  xxxx
ratbag raw: hidpp read:  xxxx

ratbag debug: 'MX Master 3S' is using protocol v4.5
ratbag raw: 'MX Master 3S' has 36 features
ratbag raw: Init feature HIDPP_PAGE_ROOT (0x0000)
ratbag raw: hidpp write:  11 02 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x0000 is at 0x00
ratbag raw: Init feature HIDPP_PAGE_FEATURE_SET (0x0001)
ratbag raw: hidpp write:  11 02 00 08 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x0001 is at 0x01
ratbag raw: Init feature HIDPP_PAGE_DEVICE_INFO (0x0003)
ratbag raw: hidpp write:  11 02 00 08 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 02 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x0003 is at 0x02
ratbag raw: unknown feature 0x0003
ratbag raw: Init feature HIDPP_PAGE_DEVICE_NAME (0x0005)
ratbag raw: hidpp write:  11 02 00 08 00 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x0005 is at 0x03
ratbag raw: unknown feature 0x0005
ratbag raw: Init feature HIDPP_PAGE_WIRELESS_DEVICE_STATUS (0x1d4b)
ratbag raw: hidpp write:  11 02 00 08 1d 4b 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x1d4b is at 0x04
ratbag raw: unknown feature 0x1d4b
ratbag raw: Init feature HIDPP_PAGE_RESET (0x0020)
ratbag raw: hidpp write:  11 02 00 08 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x0020 is at 0x05
ratbag raw: unknown feature 0x0020
ratbag raw: Init feature 0x21 (0x0021)
ratbag raw: hidpp write:  11 02 00 08 00 21 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 06 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x0021 is at 0x06
ratbag raw: unknown feature 0x0021
ratbag raw: Init feature  0x7 (0x0007)
ratbag raw: hidpp write:  11 02 00 08 00 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x0007 is at 0x07
ratbag raw: unknown feature 0x0007
ratbag raw: Init feature 0x1004 (0x1004)
ratbag raw: hidpp write:  11 02 00 08 10 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 08 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x1004 is at 0x08
ratbag raw: unknown feature 0x1004
ratbag raw: Init feature HIDPP_PAGE_SPECIAL_KEYS_BUTTONS (0x1b04)
ratbag raw: hidpp write:  11 02 00 08 1b 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 09 00 05 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x1b04 is at 0x09
ratbag debug: device has programmable keys/buttons
ratbag raw: hidpp write:  11 02 09 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 08 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag debug: device has 8 buttons
ratbag raw: hidpp write:  11 02 09 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 18 00 50 00 38 01 00 01 01 04 00 00 00 00 00 00 00
ratbag raw: hidpp write:  11 02 09 28 00 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 28 00 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: control 0: cid: 'Left' (80) tid: 'Left Click' (56) flags: 0x01 pos: 0 group: 1 gmask: 0x01 raw_XY: no
      reporting: raw_xy: no persist: no divert: no remapped: 'None' (0)
ratbag raw: hidpp write:  11 02 09 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 18 00 51 00 39 01 00 01 01 04 00 00 00 00 00 00 00
ratbag raw: hidpp write:  11 02 09 28 00 51 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 28 00 51 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: control 1: cid: 'Right' (81) tid: 'Right Click' (57) flags: 0x01 pos: 0 group: 1 gmask: 0x01 raw_XY: no
      reporting: raw_xy: no persist: no divert: no remapped: 'None' (0)
ratbag raw: hidpp write:  11 02 09 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 18 00 52 00 3a 31 00 02 03 05 00 00 00 00 00 00 00
ratbag raw: hidpp write:  11 02 09 28 00 52 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 28 00 52 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: control 2: cid: 'Middle' (82) tid: 'Middle Click' (58) flags: 0x31 pos: 0 group: 2 gmask: 0x03 raw_XY: yes
      reporting: raw_xy: no persist: no divert: no remapped: 'None' (0)
ratbag raw: hidpp write:  11 02 09 18 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 18 00 53 00 3c 31 00 02 03 05 00 00 00 00 00 00 00
ratbag raw: hidpp write:  11 02 09 28 00 53 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 28 00 53 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: control 3: cid: 'Back' (83) tid: 'Back Click' (60) flags: 0x31 pos: 0 group: 2 gmask: 0x03 raw_XY: yes
      reporting: raw_xy: no persist: no divert: no remapped: 'None' (0)
ratbag raw: hidpp write:  11 02 09 18 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 18 00 56 00 3e 31 00 02 03 05 00 00 00 00 00 00 00
ratbag raw: hidpp write:  11 02 09 28 00 56 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 28 00 56 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: control 4: cid: 'Forward' (86) tid: 'Forward Click' (62) flags: 0x31 pos: 0 group: 2 gmask: 0x03 raw_XY: yes
      reporting: raw_xy: no persist: no divert: no remapped: 'None' (0)
ratbag raw: hidpp write:  11 02 09 18 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 18 00 c3 00 a9 31 00 02 03 05 00 00 00 00 00 00 00
ratbag raw: hidpp write:  11 02 09 28 00 c3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 28 00 c3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: control 5: cid: 'AppSwitchGesture' (195) tid: 'Gesture Button' (169) flags: 0x31 pos: 0 group: 2 gmask: 0x03 raw_XY: yes
      reporting: raw_xy: no persist: no divert: no remapped: 'None' (0)
ratbag raw: hidpp write:  11 02 09 18 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 18 00 c4 00 9d 31 00 02 03 05 00 00 00 00 00 00 00
ratbag raw: hidpp write:  11 02 09 28 00 c4 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 28 00 c4 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: control 6: cid: 'SmartShift' (196) tid: 'SmartShift' (157) flags: 0x31 pos: 0 group: 2 gmask: 0x03 raw_XY: yes
      reporting: raw_xy: no persist: no divert: no remapped: 'None' (0)
ratbag raw: hidpp write:  11 02 09 18 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 18 00 d7 00 b4 a0 00 03 00 03 00 00 00 00 00 00 00
ratbag raw: hidpp write:  11 02 09 28 00 d7 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 28 00 d7 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: control 7: cid: 'UNKNOWN' (215) tid: 'UNKNOWN' (180) flags: 0xa0 pos: 0 group: 3 gmask: 0x00 raw_XY: yes
      reporting: raw_xy: no persist: no divert: no remapped: 'None' (0)
ratbag raw: num_control 8
ratbag raw: Init feature 0x1814 (0x1814)
ratbag raw: hidpp write:  11 02 00 08 18 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 0a 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x1814 is at 0x0a
ratbag raw: unknown feature 0x1814
ratbag raw: Init feature 0x1815 (0x1815)
ratbag raw: hidpp write:  11 02 00 08 18 15 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 0b 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x1815 is at 0x0b
ratbag raw: unknown feature 0x1815
ratbag raw: Init feature 0x2250 (0x2250)
ratbag raw: hidpp write:  11 02 00 08 22 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 0c 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x2250 is at 0x0c
ratbag raw: unknown feature 0x2250
ratbag raw: Init feature HIDPP_PAGE_ADJUSTABLE_DPI (0x2201)
ratbag raw: hidpp write:  11 02 00 08 22 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 0d 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x2201 is at 0x0d
ratbag debug: device has adjustable dpi
ratbag raw: hidpp write:  11 02 0d 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 0d 08 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp write:  11 02 0d 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 0d 18 00 00 c8 e0 32 1f 40 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp write:  11 02 0d 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 0d 28 00 03 e8 03 e8 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: sensor 0: current dpi: 1000 (default: 1000) min: 200 max: 8000 steps: 50
ratbag debug: device is at 1000 dpi (variable between 200 and 8000).
ratbag raw: Init feature 0x2110 (0x2110)
ratbag raw: hidpp write:  11 02 00 08 21 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x2110 is at 0x0e
ratbag raw: unknown feature 0x2110
ratbag raw: Init feature 0x2121 (0x2121)
ratbag raw: hidpp write:  11 02 00 08 21 21 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 0f 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x2121 is at 0x0f
ratbag raw: unknown feature 0x2121
ratbag raw: Init feature 0x2150 (0x2150)
ratbag raw: hidpp write:  11 02 00 08 21 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x2150 is at 0x10
ratbag raw: unknown feature 0x2150
ratbag raw: Init feature 0x2251 (0x2251)
ratbag raw: hidpp write:  11 02 00 08 22 51 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x2251 is at 0x11
ratbag raw: unknown feature 0x2251
ratbag raw: Init feature 0xc3 (0x00c3)
ratbag raw: hidpp write:  11 02 00 08 00 c3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x00c3 is at 0x12
ratbag raw: unknown feature 0x00c3
ratbag raw: Init feature 0x1802 (0x1802)
ratbag raw: hidpp write:  11 02 00 08 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 13 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x1802 is at 0x13
ratbag raw: Init feature 0x1803 (0x1803)
ratbag raw: hidpp write:  11 02 00 08 18 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 14 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x1803 is at 0x14
ratbag raw: Init feature 0x1806 (0x1806)
ratbag raw: hidpp write:  11 02 00 08 18 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 15 70 08 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x1806 is at 0x15
ratbag raw: Init feature 0x1816 (0x1816)
ratbag raw: hidpp write:  11 02 00 08 18 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 16 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x1816 is at 0x16
ratbag raw: Init feature 0x1805 (0x1805)
ratbag raw: hidpp write:  11 02 00 08 18 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 17 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x1805 is at 0x17
ratbag raw: Init feature 0x1830 (0x1830)
ratbag raw: hidpp write:  11 02 00 08 18 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 18 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x1830 is at 0x18
ratbag raw: Init feature 0x1891 (0x1891)
ratbag raw: hidpp write:  11 02 00 08 18 91 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 19 68 07 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x1891 is at 0x19
ratbag raw: Init feature 0x18a1 (0x18a1)
ratbag raw: hidpp write:  11 02 00 08 18 a1 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 1a 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x18a1 is at 0x1a
ratbag raw: Init feature 0x1e00 (0x1e00)
ratbag raw: hidpp write:  11 02 00 08 1e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 1b 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x1e00 is at 0x1b
ratbag raw: Init feature 0x1e02 (0x1e02)
ratbag raw: hidpp write:  11 02 00 08 1e 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 1c 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x1e02 is at 0x1c
ratbag raw: Init feature 0x1602 (0x1602)
ratbag raw: hidpp write:  11 02 00 08 16 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x1602 is at 0x1d
ratbag raw: unknown feature 0x1602
ratbag raw: Init feature 0x1eb0 (0x1eb0)
ratbag raw: hidpp write:  11 02 00 08 1e b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 1e 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x1eb0 is at 0x1e
ratbag raw: Init feature 0x1861 (0x1861)
ratbag raw: hidpp write:  11 02 00 08 18 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 1f 70 01 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x1861 is at 0x1f
ratbag raw: Init feature 0x9300 (0x9300)
ratbag raw: hidpp write:  11 02 00 08 93 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 20 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x9300 is at 0x20
ratbag raw: Init feature 0x9001 (0x9001)
ratbag raw: hidpp write:  11 02 00 08 90 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 21 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x9001 is at 0x21
ratbag raw: Init feature 0x1e22 (0x1e22)
ratbag raw: hidpp write:  11 02 00 08 1e 22 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 22 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x1e22 is at 0x22
ratbag raw: Init feature 0x9205 (0x9205)
ratbag raw: hidpp write:  11 02 00 08 92 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 00 08 23 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: feature 0x9205 is at 0x23
ratbag raw: hidpp write:  11 02 0d 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 0d 08 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp write:  11 02 0d 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 0d 18 00 00 c8 e0 32 1f 40 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp write:  11 02 0d 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 0d 28 00 03 e8 03 e8 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: sensor 0: current dpi: 1000 (default: 1000) min: 200 max: 8000 steps: 50
ratbag debug: device is at 1000 dpi (variable between 200 and 8000).
ratbag raw: hidpp write:  11 02 09 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 08 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag debug: device has 8 buttons
ratbag raw: hidpp write:  11 02 09 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 18 00 50 00 38 01 00 01 01 04 00 00 00 00 00 00 00
ratbag raw: hidpp write:  11 02 09 28 00 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 28 00 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: control 0: cid: 'Left' (80) tid: 'Left Click' (56) flags: 0x01 pos: 0 group: 1 gmask: 0x01 raw_XY: no
      reporting: raw_xy: no persist: no divert: no remapped: 'None' (0)
ratbag raw: hidpp write:  11 02 09 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 18 00 51 00 39 01 00 01 01 04 00 00 00 00 00 00 00
ratbag raw: hidpp write:  11 02 09 28 00 51 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 28 00 51 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: control 1: cid: 'Right' (81) tid: 'Right Click' (57) flags: 0x01 pos: 0 group: 1 gmask: 0x01 raw_XY: no
      reporting: raw_xy: no persist: no divert: no remapped: 'None' (0)
ratbag raw: hidpp write:  11 02 09 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 18 00 52 00 3a 31 00 02 03 05 00 00 00 00 00 00 00
ratbag raw: hidpp write:  11 02 09 28 00 52 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 28 00 52 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: control 2: cid: 'Middle' (82) tid: 'Middle Click' (58) flags: 0x31 pos: 0 group: 2 gmask: 0x03 raw_XY: yes
      reporting: raw_xy: no persist: no divert: no remapped: 'None' (0)
ratbag raw: hidpp write:  11 02 09 18 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 18 00 53 00 3c 31 00 02 03 05 00 00 00 00 00 00 00
ratbag raw: hidpp write:  11 02 09 28 00 53 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 28 00 53 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: control 3: cid: 'Back' (83) tid: 'Back Click' (60) flags: 0x31 pos: 0 group: 2 gmask: 0x03 raw_XY: yes
      reporting: raw_xy: no persist: no divert: no remapped: 'None' (0)
ratbag raw: hidpp write:  11 02 09 18 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 18 00 56 00 3e 31 00 02 03 05 00 00 00 00 00 00 00
ratbag raw: hidpp write:  11 02 09 28 00 56 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 28 00 56 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: control 4: cid: 'Forward' (86) tid: 'Forward Click' (62) flags: 0x31 pos: 0 group: 2 gmask: 0x03 raw_XY: yes
      reporting: raw_xy: no persist: no divert: no remapped: 'None' (0)
ratbag raw: hidpp write:  11 02 09 18 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 18 00 c3 00 a9 31 00 02 03 05 00 00 00 00 00 00 00
ratbag raw: hidpp write:  11 02 09 28 00 c3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 28 00 c3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: control 5: cid: 'AppSwitchGesture' (195) tid: 'Gesture Button' (169) flags: 0x31 pos: 0 group: 2 gmask: 0x03 raw_XY: yes
      reporting: raw_xy: no persist: no divert: no remapped: 'None' (0)
ratbag raw: hidpp write:  11 02 09 18 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 18 00 c4 00 9d 31 00 02 03 05 00 00 00 00 00 00 00
ratbag raw: hidpp write:  11 02 09 28 00 c4 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 28 00 c4 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: control 6: cid: 'SmartShift' (196) tid: 'SmartShift' (157) flags: 0x31 pos: 0 group: 2 gmask: 0x03 raw_XY: yes
      reporting: raw_xy: no persist: no divert: no remapped: 'None' (0)
ratbag raw: hidpp write:  11 02 09 18 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 18 00 d7 00 b4 a0 00 03 00 03 00 00 00 00 00 00 00
ratbag raw: hidpp write:  11 02 09 28 00 d7 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: hidpp read:   11 02 09 28 00 d7 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ratbag raw: control 7: cid: 'UNKNOWN' (215) tid: 'UNKNOWN' (180) flags: 0xa0 pos: 0 group: 3 gmask: 0x00 raw_XY: yes
      reporting: raw_xy: no persist: no divert: no remapped: 'None' (0)
ratbag raw: num_control 8
ratbag raw:  - button0: Left (50) ../src/driver-hidpp20.c:106
ratbag raw:  - button1: Right (51) ../src/driver-hidpp20.c:106
ratbag raw:  - button2: Middle (52) ../src/driver-hidpp20.c:106
ratbag raw:  - button3: Back (53) ../src/driver-hidpp20.c:106
ratbag raw:  - button4: Forward (56) ../src/driver-hidpp20.c:106
ratbag raw:  - button5: AppSwitchGesture (c3) ../src/driver-hidpp20.c:106
ratbag raw:  - button6: SmartShift (c4) ../src/driver-hidpp20.c:106
ratbag raw:  - button7: UNKNOWN (d7) ../src/driver-hidpp20.c:106
ratbag debug: driver match found: Logitech HID++2.0
hidraw1: "MX Master 3S", 1 profiles
DBus server ready

God, so this is why some repos don't accept pull requests from the master branch - GitHub doesn't let me push new commits there, but it let me update your branch to the upstream's master, which for some reason also closed the PR automatically.
@NL-TCH, would you please make a new branch and make the same pull request from there?
Locally you would have to clone your repository, then just do git switch --create feat_logitech_mx_master_3s and git push.

@staticssleever668 fwiw, I've bumped you up to maintainer now, in case that helps next time. Also, there's this action which may let us prevent merges from forked master branches (haven't tried it though).

Hi nltech, could you reopen the request to add mx3s for staticssleever668?

@kodein1
I remade the pull request myself in #1382, however we will now have to wait until another maintainer approves it.

however we will now have to wait until another maintainer approves it.

@staticssleever668: I'm pretty sure you have the permissions to merge anyway, right? For things like that, waiting for two reviews is a bit pointless, let alone our lack of reviewers... anyway, I found that checkbox and unticked it, formal review approval is no longer required.

Hi all, no matter what I try, I am unable to get it to work on my machine.
I am using the bolt receiver.
Here is my output:
ratbag debug: No data file found for 046d:4023
ratbag debug: New device: Logitech Wireless Mouse PID:4038
ratbag debug: Using data directory '/usr/local/share/libratbag'
ratbag debug: No data file found for 046d:4038
ratbag debug: New device: Logitech USB Receiver
ratbag debug: Using data directory '/usr/local/share/libratbag'
ratbag debug: 046d:c548 is a Logitech receiver, not a device. Ignoring...
ratbag debug: New device: Logitech USB Receiver
ratbag debug: Using data directory '/usr/local/share/libratbag'
ratbag debug: 046d:c548 is a Logitech receiver, not a device. Ignoring...
ratbag debug: New device: Logitech USB Receiver
ratbag debug: Using data directory '/usr/local/share/libratbag'
ratbag debug: 046d:c548 is a Logitech receiver, not a device. Ignoring...
ratbag debug: New device: Logitech USB Receiver
ratbag debug: Using data directory '/usr/local/share/libratbag'
ratbag debug: 046d:c548 is a Logitech receiver, not a device. Ignoring...
DBus server ready

So I added usb:046d:4038 to the data file, and now I am getting this error:
ratbag debug: New device: Logitech Wireless Mouse PID:4038
ratbag debug: Using data directory '/usr/local/share/libratbag'
ratbag debug: device assigned driver hidpp20
ratbag debug: hidraw info: bus 0x03 vendor 0x46d product 0xffffc534
ratbag debug: hidraw info: bus 0x03 vendor 0x46d product 0x4023
ratbag debug: hidraw info: bus 0x03 vendor 0x46d product 0x4038
ratbag debug: Logitech Wireless Mouse PID:4038 is device '/dev/hidraw8'.
ratbag debug: Parsing HID report descriptor
ratbag debug: Parsing HID report descriptor
ratbag debug: - HID report ID 02
ratbag debug: - HID report ID 10
ratbag debug: - HID report ID 11
ratbag debug: - HID report ID 20
ratbag debug: - HID report ID 21
ratbag debug: hidpp: device supports short reports
ratbag debug: hidpp: device supports long reports
ratbag raw: hidpp write:  10 ff 00 18 00 00 00
ratbag raw: hidpp read:   10 02 8f 00 18 09 00
ratbag debug:     HID++ error from the device (2): ERR_UNSUPPORTED (09)
...

Is it even suppose to work with the bolt receiver or only with bluetooth?

repo: libratbag/libratbag

license: MIT


text:
Fix crash on hidpp10 device initialization failure

Should fix #936, #942.

@ksv1986 can you rebase against master for the CI?

Done


text:
Bump crypto crates

{aes, aes-ctr}: 0.3 -> 0.6
sha-1: 0.8 -> 0.9
hmac: 0.7 -> 0.10
{pbkdf2, block-modes}: 0.3 -> 0.7
In those crates were some breaking changes, but I think I figured it out and everything works as before.

Bad typo in my branch name ... anyway

Yeah, I encountered that when pulling it, didn't matter though.

repo: librespot-org/librespot


text:
Patch 2

주어에 따라 조사가 달라지지 않도록 수정
띄어쓰기를 바르게 고치기
파브리케이터 용어집에 따라 Audit을 "어딧"에서 "검토"로 수정

@homu r+
:+1:

@homu r+
:+1:

:pushpin: Commit 29c44eb has been approved by revi

:pushpin: Commit 29c44eb has been approved by revi

:zap: Test exempted - status

:zap: Test exempted - status

authors: homu hwangjy9 revi

license_source: bigquery


text:
macOS ImageIO corrupts .ico, .cur when using IMG_Load()

Steps to reproduce:

Build on macOS with the ImageIO backend
Load test/sample.ico, test/sample.cur on macOS using IMG_Load()

Expected result: they load successfully and draw as a copy of the reference
Actual result: https://github.com/libsdl-org/SDL_image/issues/248#issuecomment-1133183528, https://github.com/libsdl-org/SDL_image/issues/248#issuecomment-1133188304
Workaround: Use IMG_Load_RW() or IMG_LoadTyped_RW() instead.

As with #256, I'm only opening this so I have something to refer to in a commit: I don't think it's a release blocker.
I suspect that what is happening here is that the version of IMG_Load() in IMG_ImageIO.m thinks it can load these files, but its interpretation of them is not the same as ours.

source: gharchive/issue

license: Zlib


text:
android build error with ndk r14b

I modified the default android-configure shell script, because the original shell cannot write files into an existing directory
#!/bin/sh
export TOOLCHAIN=$PWD/android-toolchain
rm -rf $TOOLCHAIN
$1/build/tools/make-standalone-toolchain.sh \
    --toolchain=arm-linux-androideabi-4.9 \
    --arch=arm \
    --install-dir=$TOOLCHAIN \
    --platform=android-21 \
    --force
export PATH=$TOOLCHAIN/bin:$PATH
export AR=arm-linux-androideabi-ar
export CC=arm-linux-androideabi-gcc
export CXX=arm-linux-androideabi-g++
export LINK=arm-linux-androideabi-g++
export PLATFORM=android
if [[ $2 == 'gyp' ]]
  then
    ./gyp_uv.py -Dtarget_arch=arm -DOS=android -f make-android
fi

then when I run the shell script
source ./android-configure $NDK_PATH gyp && make -C out
and make command failed that
make: *** No rule to make target `/home/mark/libuv-1.12.0/out/Debug/obj.target/libuv/src/unix/pthread-barrier.csrc/unix/procfs-exepath.o', needed by `/home/mark/libuv-1.12.0/out/Debug/obj.target/libuv.a'.  Stop.
make: Leaving directory `/home/mark/libuv-1.12.0/out'

/home/mark is the HOME directory  and I compile libuv on Ubunutu 16.04
the obj file is dependent by libuv.a which does not built yet.
I compile the libuv with version of 1.12.0 and NDK 14.1.3816874

I compile libuv successfully with version of 1.11.0 and obtain a static library libuv.a

src/unix/procfs-exepath.c is a new file. Does adding it around here help?

In libuv.target.mk the line $(obj).target/$(TARGET)/src/unix/pthread-barrier.csrc/unix/procfs-exepath.o  maybe a mistake. I shall be
$(obj).target/$(TARGET)/src/unix/pthread-barrier.o
$(obj).target/$(TARGET)/src/unix/procfs-exepath.o

I sugguest that the libuv.target.mk generated by gyp has made a mistake

authors: cjihrig fanzhengchen

repo: libuv/libuv


text:
zos: don't error when killing a zombie process

On z/OS, EPERM is returned if the process being killed is a zombie. However, this shouldn't be treated as an error in uv_kill() since it's already terminated, so return 0 instead.

Draft: https://github.ibm.com/open-z/libuv/pull/16
Upstream: https://github.com/libuv/libuv/pull/3620

This seems consistent with the errata section of the relevant standard noting that some known implementations are not entirely standards compliant in this manner https://pubs.opengroup.org/onlinepubs/9699919799/functions/kill.html despite claiming standards compliance at https://www.ibm.com/docs/en/zos/2.1.0?topic=functions-kill-send-signal-process

CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/2248/


text:
Failure in the build task: Type '(string | RegExp)[]' is not assignable to type 'Rules'

Error reported in the latest CI job, looks the build task fails because of type mismatches with the latest webpack:
https://github.com/licg9999/transpile-webpack-plugin/actions/runs/4927111373/jobs/8803615556

Closed by: https://github.com/licg9999/transpile-webpack-plugin/pull/42


text:
error reporting & errors running BasicTerm_SE default (simulated) data

Hi,
On BasicTerm_SE using default (simulated) data:
Point ids such as 581, 956 are failing because they are future NB, age 20 at sale, but that's in almost 3 years.
Even though mortality before sale doesn't affect calculations, there are mortality table lookups which cause failure (mort_table.xlsx starts at age 18; lookups for age 17 fail).
I think this is a relatively easy fix to the basic term logic.
Maybe more visibility about errors would be useful, e.g. an error count, which can be included with result_pv, which is missing results in cases such as this?

Thanks for the report. I'll take closer look at it this weekend.

I added is_active(t) and made pols_death check it before reading mortality rates. https://github.com/lifelib-dev/lifelib/commit/f5fe26c2577488683481c376900f18e95b1e2575
I'm not entirely sure about the error visibility in result_pv. result_pv should throw error if something goes wrong in projection for the selected model point, right?

Thanks for that fix!
You're right about result_pv for a selected model point, but this aggregate for the Projection is missing values:
(before the fix)

Here, it isn't obvious that there are missing values due to errors.

Oh, correct! So no danger here and closing, thanks!

authors: declann fumitoh

repo: lifelib-dev/lifelib


text:
Add remill and gap portfiles

Add remill and gap ports.
remill port allows to specify features cxx-common-llvm-14 or system-llvm to build with local install llvm or uses cxx-common provided LLVM.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.2 out of 3 committers have signed the CLA.:white_check_mark: xlauko:white_check_mark: ekilmer:x: lkorencYou have signed the CLA already but the status is still pending? Let us recheck it.

authors: CLAassistant xlauko

repo: lifting-bits/cxx-common


text:
Lightning renderer is broken inside ipywidgets.Output

Hello, @ellisonbg and I are working on creating an Altair ipython widget to interact with the vegalite spec that gets passed to the lightning renderer. However, @ellisonbg found that the lightning renderer is broken inside ipywidgets.Output
Probably the easiest way to get a repro would be to install latest Altair and comment out the create_render_view method here: https://github.com/ellisonbg/altair/blob/master/altair/view.py
Then, from this notebook: https://github.com/ellisonbg/altair/blob/master/notebooks/WidgetView.ipynb
add this cell: view.create_render_view(v1, shelves=('x','y','color','size'))
@ellisonbg might have better repro steps?
Issue is here: https://github.com/ellisonbg/altair/issues/82
@freeman-lab suggested opening an issue here for him and @mathisonian to take a look. Thanks!

This may take some digging around, but I think that using a unique
id= on the top level element may help some of these issues.
On Mon, Nov 2, 2015 at 5:48 PM, Alejandro Guerrero Gonzalez <
notifications@github.com> wrote:

Hello, @ellisonbg https://github.com/ellisonbg and I are working on
creating an Altair ipython widget to interact with the vegalite spec that
gets passed to the lightning renderer. However, @ellisonbg
https://github.com/ellisonbg found that the lightning renderer is
broken inside ipywidgets.Output
Probably the easiest way to get a repro would be to install latest Altair
and comment out the create_render_view method here:
https://github.com/ellisonbg/altair/blob/master/altair/view.py
Then, from this notebook:
https://github.com/ellisonbg/altair/blob/master/notebooks/WidgetView.ipynb
add this cell: view.create_render_view(v1,
shelves=('x','y','color','size'))
@ellisonbg https://github.com/ellisonbg might have better repro steps?
Issue is here: ellisonbg/altair#82
https://github.com/ellisonbg/altair/issues/82
@freeman-lab https://github.com/freeman-lab suggested opening an issue
here for him and @mathisonian https://github.com/mathisonian to take a
look. Thanks!
—
Reply to this email directly or view it on GitHub
https://github.com/lightning-viz/lightning-python/issues/36.

--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com

Friendly ping :) Have you had a chance to take a look at this?
Thanks!

Hi,
We want to release a product that relies on the lightning renderer and this could block our shipping of it. We are anxiously waiting for some reply :) I am willing to work on it as long as I can get some guidance.
cc. @ellisonbg @sangeethashekar
Thanks!
Alejandro

hey @aggFTW, sorry for the delay, I've been pulled away on other projects. It will be a couple days before I can really dig into it, but here is what I would recommend:
When using lightning in the "headless" mode the template that renders the visualization is kept here: https://github.com/lightning-viz/lightning-python/blob/master/lightning/lib/template.html.
I would recommend testing the change using lightning in local mode first and if this works we can apply the same change to the server. You can pass additional parameters to the template by adding to the fields dictionary here: https://github.com/lightning-viz/lightning-python/blob/master/lightning/visualization.py#L151-L160

Hey @aggFTW, coming back to this - could you help me reproduce?
I'm following these steps:

comment out this function in altair https://github.com/ellisonbg/altair/blob/master/altair/view.py#L102-L115
use this notebook and add cell use_renderer('lightning')
add cell view.create_render_view(v1, shelves=('x','y','color','size'))
render view is displayed
click "render", nothing happens - no js errors or updates on the screen

I'm not sure what else I need to do to see the errors

authors: aggFTW ellisonbg mathisonian

repo: lightning-viz/lightning-python

license: mit


text:
Proposal for option disable TLS for REST RPC endpoint.

Background
Requiring clients to use https vice allowing http introduces a barrier for new clients.  Furthermore, using self-signed certificates (default) or CA issued certificates adds an additional layer of complexity for clients.  There is already the option for originating IP-restricted access, and required macaroons sent in the headers already provide authentication.
Your environment
Applies to multiple evironments.
Expected behaviour
An option in the lnd.conf, and/or command line to disable https.
Actual behaviour
No way to disable TLS.
lnd uses a proxy for HTTP to gRPC, and TLS can be disabled by a change:
https://github.com/lightningnetwork/lnd/blob/bdf3f4d7753ce950bd14ed56ad96c12097f1b4c9/lnd.go#L541
Change that line to:
listener, err := net.Listen("tcp", restEndpoint)
to disable tls.

It's likely the case that services shouldn't directly expose the REST endpoint to the public interface. Instead, it was meant to serve as components in a backend service to drive an application.

Furthermore, using self-signed certificates (default) or CA issued certificates adds an additional layer of complexity for clients

Everything on the web should be using TLS. One can either use the default certs of lnd (which shouldn't be an issue if just hitting a backend service as you already need the macaroons), or they can go the existing CA route (Let's Encrypt, or the like).

I guess the macaroons could be susceptible to copying by man-in-the-middle without TLS. Is this a weakness in that authentication approach?

Yep, which is why it's important to use TLS when connecting to the endpoint. It's the nature of the approach as it's a bearer API credential. The macaroons we have right now are pretty basic, but applications will be able to precisely tune the capabilities of the macaroon in order to mitigate the damage possible due to a compromise of the credential.

Other REST APIs use a secret key to sign requests when working over HTTP.

A naive implementation of that would still be subject to replay attacks.

A naive implementation of that would still be subject to replay attacks.

Right, so it's up to the server to make sure the implementation is sound :)  I think even "got-robbed-blind" MtGox had a proper secure REST API.  Maybe they should have also thought about other aspects.
So, maybe this issue - the inclusion of HTTP endpoint - would require a re-working of the macaroon authentication, and a full rework of the REST API so that it's not just a gRPC proxy.
The level of effort vs reward may be a bit low compared to some other issues right now.

Fixed by https://github.com/lightningnetwork/lnd/pull/4648 by allowing to disable TLS on non-public interfaces (to work behind a reverse proxy that then encrypts with TLS).

authors: Horndev Roasbeef guggero

repo: lightningnetwork/lnd


text:
Unable to close channel and send coins to btc wallet

Background
Hi, I've tried to close channel with flag --force but got an error "error": "unable to close channel: rpc error: code = Unknown desc = unable to find arbitrator"
I read before that this issue may casued by not synced node, but at this time it fully synced and active, also send coins causes error
[lncli] rpc error: code = Unknown desc = transaction output is dust, but as I can see when I calls wallet balance I can see that
"total_balance": "4483374",
"confirmed_balance": "4483374",
"unconfirmed_balance": "0"
Can you pls help with this, I am new in this so I could have missed something
Enviorment
Version: 0.5.1-beta commit=v0.5.1-beta-721-g81783a60dc87f275d415be2e55c8f03688cd63ae,
ubuntu 16.04
Bitcoin Core version v0.17.0.0-ge1ed37edaedc85b8c3468bd9a726046344036243 (release build)
Steps to reproduce
Channel was innactive for one month, also node was down
Here's netstat if needed
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:28332           0.0.0.0:*               LISTEN      15468/bitcoind
tcp        0      0 0.0.0.0:8333            0.0.0.0:*               LISTEN      15468/bitcoind
tcp        0      0 0.0.0.0:28333           0.0.0.0:*               LISTEN      15468/bitcoind
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -
tcp6       0      0 :::8332                 :::*                    LISTEN      15468/bitcoind
tcp6       0      0 :::8333                 :::*                    LISTEN      15468/bitcoind
tcp6       0      0 :::8180                 :::*                    LISTEN      19748/lnd
tcp6       0      0 :::22                   :::*                    LISTEN      -
tcp6       0      0 :::10009                :::*                    LISTEN      19748/lnd
tcp6       0      0 :::9735                 :::*                    LISTEN      19748/lnd
As you can see node of btc and lnd are active

Can you please post the output of lncli listchannels for the channel you are trying to close? It looks like your channel.db file doesn't know about the channel (judging from the error message).

@guggero here is the output
{
"channels": [
{
"active": false,
"remote_pubkey": "3021c5f5f57322740e4ee6936452add19dc7ea7ccf90635f95119ab82a62ae268",
"channel_point": "3cd818c64bb6dcb7f08f2f3e1b094f642a9074b92ecf3c30bd9fa24f980c4128:1",
"chan_id": "640300596543029249",
"capacity": "4500000",
"local_balance": "4477924",
"remote_balance": "0",
"commit_fee": "22076",
"commit_weight": "600",
"fee_per_kw": "30493",
"unsettled_balance": "0",
"total_satoshis_sent": "0",
"total_satoshis_received": "0",
"num_updates": "4",
"pending_htlcs": [
],
"csv_delay": 540,
"private": false,
"initiator": true
}
]
}

Thanks, @Taratay!
Ok, it looks like that funding TX is still unspent, so you should be able to close the channel.
Can you please try the following steps and see if you can force-close after that?

Shut down lnd
Make a backup of your .lnd folder (just in case)
Upgrade lnd to the latest version (0.8.0)
Wait for the node to perform database migrations and be synced
Try force-closing again

@guggero Thanks for reply, okay I will try that.

I got  trouble when installing update of lnd
Here is output
GO111MODULE=on go build -v -tags="dev" -o lnd-debug -ldflags "-X github.com/lightningnetwork/lnd/build.Commit=v0.8.0-beta-67-g1a0ab538d53c5be57cbbf80b0e48e5a207de9749" github.com/lightningnetwork/lnd/cmd/lnd
go: disabling cache (/home/btcuser/.cache/go-build) due to initialization failure: open /home/btcuser/.cache/go-build/log.txt: permission denied
github.com/jessevdk/go-flags
github.com/btcsuite/btcd/btcec
github.com/btcsuite/btcd/chaincfg/chainhash
github.com/btcsuite/btcd/wire
github.com/btcsuite/btcd/chaincfg
github.com/btcsuite/btclog
github.com/btcsuite/btcutil/base58
github.com/btcsuite/btcutil/bech32
golang.org/x/crypto/ripemd160
github.com/btcsuite/btcutil
github.com/btcsuite/btcd/database
github.com/btcsuite/btcd/txscript
github.com/btcsuite/btcd/blockchain
github.com/btcsuite/btcd/connmgr
github.com/btcsuite/btcd/btcjson
github.com/btcsuite/go-socks/socks
github.com/btcsuite/websocket
github.com/btcsuite/btcd/rpcclient
github.com/aead/siphash
github.com/kkdai/bstream
github.com/btcsuite/btcutil/gcs
github.com/btcsuite/btcutil/gcs/builder
github.com/btcsuite/btcutil/hdkeychain
github.com/btcsuite/btcwallet/internal/zero
github.com/btcsuite/golangcrypto/poly1305
github.com/btcsuite/golangcrypto/salsa20/salsa
github.com/btcsuite/golangcrypto/nacl/secretbox
github.com/btcsuite/golangcrypto/pbkdf2
github.com/btcsuite/golangcrypto/scrypt
github.com/btcsuite/btcwallet/snacl
github.com/btcsuite/btcwallet/walletdb
github.com/btcsuite/btcwallet/walletdb/migration
github.com/btcsuite/btcwallet/waddrmgr
github.com/btcsuite/btcwallet/wtxmgr
github.com/lightninglabs/gozmq
github.com/btcsuite/btcd/addrmgr
github.com/davecgh/go-spew/spew
github.com/btcsuite/btcd/peer
github.com/lightninglabs/neutrino/cache
github.com/lightninglabs/neutrino/cache/lru
github.com/lightninglabs/neutrino/filterdb
github.com/lightninglabs/neutrino/headerfs
github.com/lightninglabs/neutrino/headerlist
github.com/lightninglabs/neutrino
github.com/btcsuite/btcwallet/chain
github.com/btcsuite/btcwallet/internal/legacy/rename
github.com/btcsuite/btcwallet/internal/legacy/keystore
github.com/btcsuite/golangcrypto/ssh/terminal
github.com/btcsuite/btcwallet/internal/prompt
github.com/btcsuite/btcwallet/internal/helpers
github.com/btcsuite/btcwallet/wallet/internal/txsizes
github.com/btcsuite/btcwallet/wallet/txrules
github.com/btcsuite/btcwallet/wallet/txauthor
github.com/btcsuite/btcwallet/wallet
github.com/coreos/bbolt
github.com/go-errors/errors
golang.org/x/net/internal/timeseries
golang.org/x/net/trace
google.golang.org/grpc/backoff
google.golang.org/grpc/grpclog
google.golang.org/grpc/connectivity
github.com/golang/protobuf/proto
google.golang.org/grpc/credentials/internal
google.golang.org/grpc/internal
google.golang.org/grpc/credentials
google.golang.org/grpc/metadata
google.golang.org/grpc/serviceconfig
google.golang.org/grpc/resolver
google.golang.org/grpc/balancer
google.golang.org/grpc/balancer/base
google.golang.org/grpc/internal/grpcrand
google.golang.org/grpc/balancer/roundrobin
google.golang.org/grpc/codes
google.golang.org/grpc/encoding
google.golang.org/grpc/encoding/proto
google.golang.org/grpc/internal/backoff
google.golang.org/grpc/internal/balancerload
github.com/golang/protobuf/ptypes/any
github.com/golang/protobuf/ptypes/duration
github.com/golang/protobuf/ptypes/timestamp
github.com/golang/protobuf/ptypes
google.golang.org/grpc/binarylog/grpc_binarylog_v1
google.golang.org/genproto/googleapis/rpc/status
google.golang.org/grpc/status
google.golang.org/grpc/internal/binarylog
golang.org/x/sys/unix
google.golang.org/grpc/internal/channelz
google.golang.org/grpc/internal/envconfig
google.golang.org/grpc/internal/grpcsync
google.golang.org/grpc/internal/resolver/dns
google.golang.org/grpc/internal/resolver/passthrough
golang.org/x/text/transform
golang.org/x/text/unicode/bidi
golang.org/x/text/secure/bidirule
golang.org/x/text/unicode/norm
golang.org/x/net/idna
golang.org/x/net/http/httpguts
golang.org/x/net/http2/hpack
golang.org/x/net/http2
google.golang.org/grpc/internal/syscall
google.golang.org/grpc/keepalive
google.golang.org/grpc/peer
google.golang.org/grpc/stats
google.golang.org/grpc/tap
google.golang.org/grpc/internal/transport
google.golang.org/grpc/naming
google.golang.org/grpc
github.com/golang/protobuf/ptypes/struct
github.com/golang/protobuf/jsonpb
github.com/golang/protobuf/protoc-gen-go/descriptor
github.com/golang/protobuf/protoc-gen-go/generator/internal/remap
github.com/golang/protobuf/protoc-gen-go/plugin
github.com/golang/protobuf/protoc-gen-go/generator
github.com/golang/protobuf/ptypes/wrappers
github.com/grpc-ecosystem/grpc-gateway/internal
github.com/grpc-ecosystem/grpc-gateway/utilities
google.golang.org/genproto/protobuf/field_mask
github.com/grpc-ecosystem/grpc-gateway/runtime
golang.org/x/sys/cpu
github.com/aead/chacha20/chacha
github.com/aead/chacha20
github.com/lightningnetwork/lightning-onion
github.com/jrick/logrotate/rotator
github.com/lightningnetwork/lnd/build
github.com/lightningnetwork/lnd/keychain
github.com/lightningnetwork/lnd/input
github.com/lightningnetwork/lnd/lntypes
github.com/miekg/dns/vendor/golang.org/x/crypto/ed25519/internal/edwards25519
github.com/miekg/dns/vendor/golang.org/x/crypto/ed25519
github.com/miekg/dns/vendor/golang.org/x/net/bpf
github.com/miekg/dns/vendor/golang.org/x/net/internal/iana
github.com/miekg/dns/vendor/golang.org/x/net/internal/socket
github.com/miekg/dns/vendor/golang.org/x/net/ipv4
github.com/miekg/dns/vendor/golang.org/x/net/ipv6
github.com/miekg/dns
golang.org/x/net/internal/socks
golang.org/x/net/proxy
github.com/lightningnetwork/lnd/tor
github.com/lightningnetwork/lnd/lnwire
github.com/lightningnetwork/lnd/tlv
github.com/lightningnetwork/lnd/record
github.com/lightningnetwork/lnd/routing/route
github.com/lightningnetwork/lnd/routing/route
routing/route/route.go:242:34: undefined: sphinx.PaymentPath
routing/route/route.go:243:11: undefined: sphinx.PaymentPath
routing/route/route.go:266:15: undefined: sphinx.HopPayload
routing/route/route.go:282:19: undefined: sphinx.NewHopPayload
routing/route/route.go:300:19: undefined: sphinx.NewHopPayload
routing/route/route.go:306:13: undefined: sphinx.OnionHop
github.com/lightningnetwork/lnd/shachain
github.com/lightningnetwork/lnd/zpay32
github.com/ltcsuite/ltcd/chaincfg/chainhash
golang.org/x/crypto/pbkdf2
golang.org/x/crypto/scrypt
github.com/ltcsuite/ltcd/wire
github.com/ltcsuite/ltcd/chaincfg
github.com/btcsuite/btcutil/txsort
github.com/btcsuite/btcd/integration/rpctest
github.com/lightningnetwork/lnd/lnwallet/chanvalidate
github.com/btcsuite/fastsha256
github.com/lightningnetwork/lnd/ticker
github.com/lightningnetwork/lnd/queue
github.com/lightningnetwork/lnd/htlcswitch/hodl
github.com/lightningnetwork/lnd/htlcswitch/hop
github.com/lightningnetwork/lnd/htlcswitch/hop
htlcswitch/hop/iterator.go:82:26: r.processedPacket.Payload undefined (type *sphinx.ProcessedPacket has no field or method Payload)     htlcswitch/hop/iterator.go:85:7: undefined: sphinx.PayloadLegacy
htlcswitch/hop/iterator.go:112:22: r.processedPacket.Payload undefined (type *sphinx.ProcessedPacket has no field or method Payload)    htlcswitch/hop/iterator.go:112:39: undefined: sphinx.PayloadLegacy
htlcswitch/hop/iterator.go:116:26: r.processedPacket.Payload undefined (type *sphinx.ProcessedPacket has no field or method Payload)    github.com/lightningnetwork/lnd/lntest/wait
github.com/lightningnetwork/lnd/multimutex
golang.org/x/crypto/internal/subtle
golang.org/x/crypto/internal/chacha20
golang.org/x/crypto/poly1305
golang.org/x/crypto/chacha20poly1305
golang.org/x/crypto/hkdf
github.com/lightningnetwork/lnd/brontide
github.com/lightningnetwork/lnd/buffer
github.com/lightningnetwork/lnd/chanacceptor
github.com/lightningnetwork/lnd/subscribe
github.com/lightningnetwork/lnd/peernotifier
golang.org/x/time/rate
github.com/lightningnetwork/lnd/watchtower/blob
golang.org/x/net/context
google.golang.org/genproto/googleapis/api/annotations
github.com/juju/loggo
github.com/rogpeppe/fastuuid
golang.org/x/crypto/curve25519
golang.org/x/crypto/salsa20/salsa
golang.org/x/crypto/nacl/secretbox
golang.org/x/crypto/nacl/box
gopkg.in/errgo.v1
gopkg.in/macaroon.v2
gopkg.in/macaroon-bakery.v2/bakery/checkers
gopkg.in/macaroon-bakery.v2/bakery/internal/macaroonpb
gopkg.in/macaroon-bakery.v2/bakery
github.com/lightningnetwork/lnd/lnrpc
github.com/lightningnetwork/lnd/lnrpc/autopilotrpc
github.com/lightningnetwork/lnd/lnrpc/chainrpc
github.com/lightningnetwork/lnd/lnrpc/signrpc
github.com/lightningnetwork/lnd/lnrpc/walletrpc
github.com/lightningnetwork/lnd/lnrpc/watchtowerrpc
github.com/btcsuite/btcwallet/walletdb/bdb
github.com/lightningnetwork/lnd/macaroons
golang.org/x/crypto/blake2b
gitlab.com/NebulousLabs/fastrand
gitlab.com/NebulousLabs/go-upnp/goupnp/httpu
gitlab.com/NebulousLabs/go-upnp/goupnp/scpd
gitlab.com/NebulousLabs/go-upnp/goupnp/soap
gitlab.com/NebulousLabs/go-upnp/goupnp/ssdp
golang.org/x/net/html/atom
golang.org/x/net/html
golang.org/x/text/encoding/internal/identifier
golang.org/x/text/encoding
golang.org/x/text/encoding/internal
golang.org/x/text/encoding/charmap
golang.org/x/text/encoding/japanese
golang.org/x/text/encoding/korean
golang.org/x/text/encoding/simplifiedchinese
golang.org/x/text/encoding/traditionalchinese
golang.org/x/text/internal/utf8internal
golang.org/x/text/runes
golang.org/x/text/encoding/unicode
golang.org/x/text/internal/tag
golang.org/x/text/internal/language
golang.org/x/text/internal/language/compact
golang.org/x/text/language
golang.org/x/text/encoding/htmlindex
golang.org/x/net/html/charset
gitlab.com/NebulousLabs/go-upnp/goupnp
gitlab.com/NebulousLabs/go-upnp/goupnp/dcps/internetgateway1
github.com/NebulousLabs/go-upnp
github.com/jackpal/gateway
github.com/jackpal/go-nat-pmp
github.com/lightningnetwork/lnd/nat
github.com/lightningnetwork/lnd/pool
github.com/lightningnetwork/lnd/signal
git.schwanenlied.me/yawning/bsaes.git/ghash
git.schwanenlied.me/yawning/bsaes.git/internal/modes
git.schwanenlied.me/yawning/bsaes.git/ct32
git.schwanenlied.me/yawning/bsaes.git/ct64
github.com/Yawning/aez
github.com/lightningnetwork/lnd/aezeed
github.com/tv42/zbase32
golang.org/x/crypto/salsa20
Makefile:91: recipe for target 'build' failed
make: *** [build] Error 2

You probably have an old version of go. You need 1.13.x.
But it's probably easier to just download a binary from https://github.com/lightningnetwork/lnd/releases

@guggero Yep, I had updated go version and lnd updated without any problems, after updating I tried to close channel again but got same error, as I can see form lnd log, it filters blocks. I belive while process is incomplete I wont be able to do anything with channel and balance, am I right?)

You have to wait until you see both these flags in getinfo to be true:
        "synced_to_chain": true,
        "synced_to_graph": true,

Then you should be able to try to force-close it.
What is the exact command you use to force-close the channel?

@guggero thanks for reply, the command to close is "lncli closechannel --force 3cd818c64bb6dcb7f08f2f3e1b094f642a9074b92ecf3c30bd9fa24f980c4128 1"
At this moment I can see that
"synced_to_chain": true,
"synced_to_graph": false,
How to check synced_to_graph state?

Also strange thing I cant list channels, from log I can see that command was applied
2019-10-28 13:42:07.223 [DBG] RPCS: [listchannels] fetched 1 channels from DB
but no console output, could be a sync issue?

The command looks ok, that should work...
Do you have any peers connected? What's the current output of getinfo?
And you still get the unable to find arbitrator error when trying to force close?
Feel free to ping me in the community Slack if you don't want to post this info here.

@guggero here is output
{
"version": "0.8.0-beta commit=v0.8.0-beta-67-g1a0ab538d53c5be57cbbf80b0e48e5a207de9749",
"identity_pubkey": "023af745b54d21cec273dc55f231d08d04491ce800e6290d9bfc63c90ecb7a7f40",
"alias": "Blitzhub.IO",
"color": "#0c77c3",
"num_pending_channels": 0,
"num_active_channels": 0,
"num_inactive_channels": 1,
"num_peers": 0,
"block_height": 601383,
"block_hash": "0000000000000000000e1b81c7e35c8e10a36f43e0d5335a47d39d09b26e7475",
"best_header_timestamp": 1572270212,
"synced_to_chain": true,
"synced_to_graph": false,
"testnet": false,
"chains": [
{
"chain": "bitcoin",
"network": "mainnet"
}
],
"uris": [
"023af745b54d21cec273dc55f231d08d04491ce800e6290d9bfc63c90ecb7a7f40@172.104.22.19:9735"
]
}
Close channel not showing anything as well

Also found logs when tried force close
2019-10-28 13:05:18.818 [INF] HSWC: Removing channel link with ChannelID(28410c984fa29fbd303ccf2eb974902a644f091b3e2f8ff0b7dcb64bc618d83d)
2019-10-28 13:05:18.818 [INF] CNCT: Attempting to force close ChannelPoint(3cd818c64bb6dcb7f08f2f3e1b094f642a9074b92ecf3c30bd9fa24f980c4128:1)

Can you please increase the log level to debug and post everything you see after Attempting to force close ChannelPoint?

@guggero tried again looks like it in process
lncli closechannel --force 3cd818c64bb6dcb7f08f2f3e1b094f642a9074b92ecf3c30bd9fa24f980c4128 1
gives me
[lncli] rpc error: code = Unknown desc = channel is already in the process of being force closed
listchannel working, I set debug, at this time I am unable to send coins to btc wallet, command, trying
"lncli sendcoins --addr 3HvU...Xi6NU --amt 20"
returns
2019-10-28 14:34:46.159 [DBG] LNWL: Returning 4799 sat/kw for conf target of 6
2019-10-28 14:34:46.159 [INF] RPCS: [sendcoins] addr=3HvUmDKEZ5jNj3D2uASzu8tiktNfzXi6NU, amt=0.0000002 BTC, sat/kw=4799, sweep_all=false
2019-10-28 14:34:46.180 [ERR] RPCS: [/lnrpc.Lightning/SendCoins]: transaction output is dust

Does walletbalance still show "confirmed_balance": "4483374",?
And of course you can't send 20 satoshis to an address. That is too small for an on-chain transaction and is considered dust. So you have to specify an --amt that is larger than ~300 Satoshis.

@guggero Yes it worked!!!!) Thanks for help! Yes I can see closed channel in pending, also I sent 800 satoshi and I can see transaction on blockchain, now balance is unconfirmed, so as I can understand its awating block validation, so after this I will be able to send again after this?)

You're welcome.
Exactly, you will need 3 confirmations and then you can send again. But as I said, the pending channel will take much longer because of the time lock (I think the output of pendingchannels will tell you how many blocks are remaining).

Can this be closed now?

authors: Taratay guggero wpaulino


text:
chanrestore: assume height hint for unconfirmed channels in SCBs

This is an attempt at fixing #3444 and #3539. This issue also came up in #2468.
The chainWatcher will take the height hint to register spend notifications from ShortChanID, which will be 0 for unconfirmed channels. As a fall back, it then takes the FundingBroadcastHeight of the channel. But this value is also 0 in case of a channel shell restored from an SCB.
So for unconfirmed channels in SCBs we have no idea what height hint to use. We can't use 0 because of a restriction in chainntnfs introduced in #3405.
This PR tries to use the block height of the earliest confirmed channel in the backup passed to it as a height hint. If there is no unconfirmed channel, it falls back to a static block height which corresponds to the launch date of SCBs in lnd.
Maybe there is a more elegant way to solve this, suggestions are very welcome.

Yes, I think approach 2 should also be implemented. I'll create that PR next.
But I still think we need this workaround for people that need to rely on an SCB that they created before 0.9 or whenever we release that fix. Would you agree?

Revisiting this, what's wrong with the first option? The SCBs stay the same, we just populate them slightly differently. Once everyone upgrades, then they're now covered for those new SCBs. Even if we go with the second option, those that have SCBs (older ones) that don't set the broadcast height properly will still have rescanning issues.

Setting the broadcast height in the ShortChannelID would certainly be the easiest fix since no version change in the SCBs would be needed. I just wasn't sure about the impact of that change since I don't know where the ShortChannelID is used for identifying purposes. I thought the change would perhaps break things in other places so option 2 would be "safer" from that point of view.
I can implement option 1 as a separate PR and then we can discuss the impact there.
But you're saying, we still need and want this PR, right?

Even if we go with the second option, those that have SCBs (older ones) that don't set the broadcast height properly will still have rescanning issues.

We can detect that an old version is being used on startup and upgrade it, but that still won't work for nodes that haven't upgraded.

But you're saying, we still need and want this PR, right?

Seems fine to me to proceed with it for now as neither of the options we've discussed will handle older SCBs.

But I still think we need this workaround for people that need to rely on an SCB that they created before 0.9 or whenever we release that fix. Would you agree?

Yes, which seems to be #3719. We could even package this in an earlier minor release since it doesn't create any new SCBs, but instead interprets the existing ones in a slightly different way during recovery.

Going to merge this into #3719 and consolidate.

authors: Roasbeef guggero wpaulino


text:
Remove Ship.io

Apparently, it was bad timing to add Ship.io the other day.
https://ship.io/ship-io-is-shutting-down/

Thanks!

authors: larsbrinkhoff ligurio

repo: ligurio/Continuous-Integration-services

license: unlicense


text:
Issuing alias commands in shell doesn't work

For example I have several git command aliases that I can't use:
alias g="git status"
g% == no bueno. :'-(

yep, bash aliases don't work. You'll need to define functions
def g = %git 'status

=)

authors: lihaoyi nsullins

repo: lihaoyi/Ammonite


text:
Deserialization fails when keys with default value are missing on JS, works on JVM

My unit tests are failing on the javascript side when attempting to deserialize a sealed case class. This doesn't happen on the JVM. The exception I am getting (pulled from Chrome):
$c_Lupickle_Invalid$Data {s$1: null, e$1: null, stackTrace$1: null, data$3: $c_Lupickle_Js$Obj, msg$3: "Key Missing: caller"…}data$3: $c_Lupickle_Js$Obje$1: nullmsg$3: "Key Missing: caller"s$1: [..]
If i change all variables with defaults to something else it works fine.
I am using ScalaJs 0.6.4 and uPickle 0.3.4

Can you provide a complete, standalone repro?

I've actually been trying to do that for the last couple hours with no success. I seem to get completely random results from uPickle at times. One compile it works fine, another it doesn't. Sometimes cleaning it makes it happy, sometimes it has no effect. Sometimes making a simple change to a class changes the outcome, even reverting that change can keep uPickle happy.
It's the strangest thing, sometimes uPickle will serialize with defaults, sometimes it doesn't. I honestly can't determine the source of the behavior.
I restructured my project into a multi project in sbt and so far knock on wood it'll keep being happy.
I'm sorry I couldn't be more helpful. this one has me puzzled

I'm closing this. I can't duplicate it and falling back to manual readers/writers isn't too awful and provides a good deal of stability for what im doing.
I have to wonder, is there an easy way when writing a Writer[T] to bring in the "$type" field?

This is still an issue with uPickle 0.4.3. Unfortunately it is very difficult to reproduce and appears to be a build-time issue (happens consistently for a given build, but builds with seemingly unrelated differences result in this behavior appearing and disappearing).
If I can get a useful repro together (something that repros >25% of the time) should this be re-opened or should I submit a new issue?

@maanaben let's put it in a new issue

authors: lihaoyi maanaben tannerezell

repo: lihaoyi/upickle-pprint


text:
fix some typos and stuff

nbd

lgtmthx

authors: SethTisue lihaoyi

repo: lihaoyi/utest


text:
日历选择不支持多选

不支持多选

v0.8.1 已支持


text:
Unlocking cosmic with fingerprint does not prompt for keyring password

I am using cosmic on NixOS unstable. When I unlock with a password after forcing fingerprint auth to fail, then it successfully unlocks gnome-keyring. If I use my fingerprint to unlock, then it does not prompt to unlock gnome-keyring (like gnome would) and I cannot unlock it from seahorse. I am not sure if this is a nixos-cosmic issue or a cosmic one.

Manually starting gnome-keyring has this error.
[nwright@nwright-framework:~]$ gnome-keyring-daemon --replace --foreground --components=secrets
discover_other_daemon: 0** Message: 11:35:05.914: Replacing daemon, using directory: /run/user/1001/keyring
GNOME_KEYRING_CONTROL=/run/user/1001/keyring

** (gnome-keyring-daemon:5017): WARNING **: 11:35:28.397: couldn't create system prompt: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.gnome.keyring.SystemPrompter exited with status 1

Well I'd rather start-cosmic do this upstream, but I've pushed f929074895ac91f3d657e642a0d3d38dec682bfd to work around it in nixos-cosmic which fixes basically anything systemd- or dbus- activated (e.g. portals, gkr, etc)
Can you try again and see if that fixes it?

Closing since it should be resolved. Feel free to reopen if you're still having issues!

Apologies for the churn here. I'm not sure where I messed up my testing (maybe logging out isn't enough?) but nonetheless rebooting my machine caused the the behavior to regress again, which shows that I was wrong about XAUTHORITY. Reverting my local workaround to again update the dbus environment with --all and rebooting still works. I'm not sure what variable it actually responsible, or if it's something else entirely. How can I best help with this?

I was very skeptical XAUTHORITY would matter. Can you share env from terminal and systemctl --user show-environment?

This is still an issue on my Framework laptop. Any other information I can provide?

@ChanceHarrison  Yes, unable to unlock after logging in with fingerprint and I get the same error.

authors: NateWright lilyinstarlight

repo: lilyinstarlight/nixos-cosmic


text:
can not get the pod logs forr the k3s when set http_proxy

Description
Can not get the pod logs because of the env http_proxy=192.168.5.2:8080
The install script from https://get.k3s.io/  will create an env file.
I try to set the env in lima.yaml
env:
    no_proxy: 192.168.5.2,192.168.5.15,127.0.0.1,localhost

But, it's overridden by the env from the host.
Why override the env define from lima.yaml? I think it's should have high-level priority
if *y.PropagateProxyEnv {
		for _, name := range append(lowerVars, upperVars...) {
			if value, ok := os.LookupEnv(name); ok {
				if _, ok := env[name]; ok && value != env[name] {
					logrus.Infof("Overriding %q value %q with %q from limactl process environment",
						name, env[name], value)
				}
				env[name] = value
			}
		}
	}

Why override the env define from lima.yaml? I think it's should have high-level priority

It was intentional that the process environment would override the lima.yaml settings. Maybe that was a mistake, but it would be a breaking change to modify that now.
I need to think about this a bit more, but maybe appending 192.168.5.2,192.168.5.15,127.0.0.1,localhost to whatever value the user specifies for noproxy would be the right thing, as these should never be proxied, regardless of what else the user wants to exclude.

before resolving it, my solution such as:
provision:
- mode: system
  script: |
    #!/bin/sh
    # curl -sfL https://get.k3s.io | sh -
    export no_proxy="192.168.5.2,192.168.5.15,127.0.0.1,localhost"
    curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=v1.22.15+k3s1 sh -

authors: jandubois saltbo

repo: lima-vm/lima


text:
limactl shell does not consider potential ssh shell aliases

Description
This issue is somewhere between a bug report and a feature request.
lima shell always invokes the ssh executable instead of whichever ssh command the user may have defined in their own shell (e.g. via a shell alias):
https://github.com/lima-vm/lima/blob/8cc56933cef9808e2b62981f231adb8dd56a5246/cmd/limactl/shell.go#L129
My concern with this approach is that the potential of terminal emulators with advanced shell integrations over SSH, such as kitty, cannot be fully utilized with limactl.
For example, I alias ssh to kitty +kitten ssh.
To be able to benefit from SSH integrations provided by my terminal emulator, I currently need to export the SSH config of my VMs using limactl show-ssh then use plain SSH commands.
I can think about three ways to approach this:

Run ssh commands through the active shell instead of directly (e.g. /bin/bash -c ssh).
Potential problem: we need to use the actual user's shell instead of a hardcoded default value.

If LIMA_SHELL is set, use that value.
Potential problem: the user might legitimately want to use different shells inside and outside the VM.

Introduce an optional LIMASHELL_SSH setting, and use that if defined. (my favourite)

Potential problem: we need to use the actual user's shell instead of a hardcoded default value.

I guess $SHELL -c ssh should work

@AkihiroSuda Indeed that would work, good point.
I just submitted an implementation of option 3 in #1132, which works like a charm and is non-intrusive for the user.
Let me know what you think about it.
If you prefer option 1, I'm happy to re-visit my proposal.

Thanks, I'd prefer 1 (with $SHELL), as I'd prefer to avoid adding new env vars if avoidable.
@jandubois @afbjorklund PTAL, WDYT?

Initially I thought it was asking for a limactl ssh alias, which is something I sometimes type myself due to muscle memory from docker-machine and podman-machine...

It is probably OK to use shell instead of exec, should be rather minimal overhead (like lima)

Oops, saw the PR first before looking at this issue. Yes, I prefer $SHELL -c ssh as well.

authors: AkihiroSuda afbjorklund antoineco jandubois


text:
Command: fold

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/1197359-command-fold?utm_campaign=plugin&utm_content=tracker%2F282001&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F282001&utm_medium=issues&utm_source=github).

Migrated to limetext/lime-backend#32.

authors: erbridge quarnster

repo: limetext/lime


text:
Add the SCAN commands (and their related ZSCAN...)

Hello @twidi :)

I would love to review your PR on this subject ;)

authors: clemfromspace twidi

repo: limpyd/redis-limpyd

license: WTFPL


text:
Sample feedback and Sequence diagram

Now, I'm trying to use this service and I think this could be helpful to handle user-feedback.
It would be better if the two below were added.

Function to generate example feedback on its own before connecting Jira.

This is because it could be helpful to users easily test it before using it in earnest.
I believe "easy/simple" is powerful.
Here's an example. These are on the Settings tab.

Sequence diagram for the main functions or Overall system architecture.

This is to better understand this service.

Thanks for your feedback :) Let us improve documentation and give some testable experience for better Jira integration.

@rivkode

With this 'feedback request' button, you can get simple curl to create sample feedback.
It might be helpful for your situation.

It would be helpful !
Thank you for your help :)

authors: YoungjaeKim h4l-yup rivkode

repo: line/abc-user-feedback


text:
如何重至 listener:FileDownloadListener

@Q1: hashCode不一样的listener就直接忽略了 我想每次new FileDownloadQueueSet(fileDownloadListener) 都能以新的 listener为准，该怎么做呢。
或者 有没有api是清除老的 FileDownloadListener～
@Q2: pauseAll() 然后再开始队列并行下载 之前已经下载的进度全部都从0开始了

I. 我想每次new FileDownloadQueueSet(fileDownloadListener) 都能以新的 listener为准，该怎么做呢?
这个，你直接传入新的listener不就行了，我没有get到问题点。
II. 然后再开始队列并行下载 之前已经下载的进度全部都从0开始了
每个任务是会自动断点续传的。。如果你说是一个队列，那已经下载完成的会直接返回完成。
如果你的意思是单个任务无法自动断点续传，你先留意下你是否使用的是最新的FileDownloader版本，然后通过日志看看为什么无法断点续传，是服务端返回不支持呢，还是所有资源都是chunked资源。

@Jacksgong 是我有一个页面 每次进来都会调一边这个 FileDownloader.setup(this);         FileDownloader.getImpl().setMaxNetworkThreadCount(5);         mediaDownloadBinder = new MediaDownloadBinder();         List<MediaTask> mediaTasks = MediaTaskManager.getImpl().getMediaTasks();         final FileDownloadQueueSet queueSet = new FileDownloadQueueSet(fileDownloadListener);         baseDownloadTasks = new ArrayList<>();         for (int i = 0; i < mediaTasks.size(); i++) {             BaseDownloadTask baseDownloadTask = FileDownloader.getImpl().create(mediaTasks.get(i).getUrl()).setTag(i + 1);             baseDownloadTasks.add(baseDownloadTask);         }         queueSet.setAutoRetryTimes(1);         queueSet.downloadTogether(baseDownloadTasks);         queueSet.start();
问题所在就是只有第一次注册的fileDownloadListener有作用 后面注册的并不是覆盖之前的 所以就导致进来没有callback的回调 但是调用pauseAll()倒是可以恢复我当前的callback，然后调用pauseAll() 之后你说的下载完成的会直接返回完成这个没错 但是还有一些任务是下载了一些进度的 这个时候再开始下载就是直接进度跳到0开始了

但是还有一些任务是下载了一些进度的 这个时候再开始下载就是直接进度跳到0开始了
先留意下你是否使用的是最新的FileDownloader版本，然后通过日志看看为什么无法断点续传，是服务端返回不支持呢，还是所有资源都是chunked资源。
只有第一次注册的fileDownloadListener有作用 后面注册的并不是覆盖之前的
我大概知道你的一次，你是这个页面推出以后，依然没有推出下载；然后下次进入这个页面的时候，又重新创建了一个QueueSet启动对吧。 --- 这个做法是错误的
每个任务本身只会存一个callback；如果你重新创建一个QueueSet启动，对于FileDownloader来说，只是重新又来了一批要处理的任务，如果其中有相同任务正在处理，新的启动会收到warn而直接结束。如果其中相同的任务之前已经完成了，会直接回调完成。
**解决方法: ** 如果你本身任务监听与页面是解耦的，那你自己管理监听器，可以参考这里

嗯嗯 ，其实我是故意没有退出下载的。
正常情况下断点下载是可以的 只有调用了pauseAll()然后再继续下载才会出现从0开始的进度。

authors: Jacksgong junchenChow

repo: lingochamp/FileDownloader


text:
Repair license header settings

Describe the bug
License headers are not checked in frontend/src directory. Furthermore the license header's content isn't checked against the configured settings (like inception year)
Expected behavior

The license headers for files in frontend/src directory are checked.
The license header's content is checked.

Fix
Already fixed using the following snippet:
<!-- LICENSE -->
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>license-maven-plugin</artifactId>
                <version>2.0.0</version>
                <configuration>
                    <licenseName>apache_v2</licenseName>
                    <licenseFile>${project.basedir}/LICENSE</licenseFile>
                    <inceptionYear>${project.inceptionYear}</inceptionYear>
                    <projectName>${project.artifactId}</projectName>
                    <copyrightOwners>linked-planet GmbH</copyrightOwners>
                    <failOnMissingHeader>true</failOnMissingHeader>
                    <failOnNotUptodateHeader>true</failOnNotUptodateHeader>
                    <roots>
                        <root>src</root>
                        <root>target/generated-sources</root>
                        <root>frontend/src</root>
                    </roots>
                    <excludes>
                        <exclude>**/*.min.js</exclude>
                        <exclude>**/*.js</exclude>
                        <exclude>**/plugin*.properties</exclude>
                        <exclude>**/version*.properties</exclude>
                        <exclude>**/log4j.properties</exclude>
                        <exclude>**/kaptKotlin/**/*</exclude>
                    </excludes>
                    <excludedScopes>provided,test</excludedScopes>
                </configuration>
                <executions>
                    <execution>
                        <id>license-check-file-header</id>
                        <phase>validate</phase>
                        <goals>
                            <goal>check-file-header</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

@weickmanna That already happened in some of my files as well. You can manually fix the position of the license header and it will be accepted that way by the plugin.

repo: linked-planet/atlassian-plugin-kotlin


text:
[question] Stable state of master branch and "helix" feature?

Can we using ambry in production environment by compiling from source in master branch? (is master branch supposed to be stable?)
Similar question for using ambry with Helix.
We are running ambry + Helix on Rancher in own test environment and it's good so far.

Hello @ohze - Ambry's master branch is stable to use. However, if you find any critical bugs, please report them and we will fix them quickly.
Ambry with helix is also stable to use. If you have specific questions (or bugs), you can reach out to @pnarayanan.

authors: ohze vgkholla

repo: linkedin/ambry


text:
LinkedIn REST API Getting Started Tutorial link not found

https://developer.linkedin.com/documents/quick-start-guide link not found

this is a duplicate of previous issue

repo: linkedin/api-get-started


text:
[Reference PR] Coral-Schema: Upgrade Avro to 1.10 and modify makeNullable logic

This PR is based on #307 by @i-ony with the following modifications:

Combine the commits and rebase for simplicity
Remove unnecessary changes to build.gradle of other modules and dependencies.gradle, we just need to add avroCompatHelper dependency and force Coral-Schema to use Avro 1.10 by the following config in Coral-Schema's build.gradle:

configurations.all {
  resolutionStrategy {
    force 'org.apache.avro:avro:1.10.2'
  }
}

Modify makeNullable method to take a boolean parameter nullAsSecond, if it's true, will construct schemas like [long, null]. Previously, makeNullable can only construct [null, long] with null as the first option.
Modify MergeHiveSchemaWithAvro.struct, MergeHiveSchemaWithAvro.list, MergeHiveSchemaWithAvro.map and MergeHiveSchemaWithAvro.primitive methods which call SchemaUtilities.makeNullable to construct nullable schema with the same order as partner by the following code:

SchemaUtilities.makeNullable(result, SchemaUtilities.isNullSecond(partner));

so that if partner is [long, null], the return result is also [long, null] rather than [null, long]

Similar to 4, in SchemaUtilities.getUnionFieldSchema method, if leftSchema and rightSchema are both nullable, we construct final schema with the same order as left schema (it's just one of the options, we need further discussion to determine the behavior):

return makeNullable(getUnionFieldSchema(makeNonNullable(leftSchema), makeNonNullable(rightSchema), strictMode),
          isNullSecond(leftSchema));

Tested on the affected production view, which can be translated with change 4 and 5.
FYI @wmoustafa @aastha25

@aastha25 thanks for your review, this PR is a reference PR for next i-test, so I just focused on the logic and didn't spend much time on the coding style/unit tests, which should be handled by the formal Avro upgrade PR. If we are fine with the logic, we can proceed with the i-test.

Thanks for the clarification @ljfgem . The logic looks good to me and we can use it for reference at this stage. We can come back to reviews before actually checking in.
could you just help answer this comment https://github.com/linkedin/coral/pull/313#discussion_r989323304

Closing it given the formal PR #314 has been opened.

repo: linkedin/coral


text:
Distribute custom elements

The output of svg-to-custom-element generate plugin (introduced in PR#320) is custom element js files based on the svg files fed by svg-generate plugin. This PR makes relevant changes to enable users to distribute these custom elements to a given output path. And as proposed by @ramitha, it introduces generatedMetadata field in iconrc as a way to share data b/w generate and distribute at run time. Moreover, this PR removes id from svg object inside custom element definition.
Distribute command:
icon-magic distribute <input-path> -o <output-path> -t svg --outputAsCustomElement -c <color-scheme>
eg,
icon-magic distribute out/mercado/logos-bugs/premium-badge -o ../li-web-icons/src/custom-elements/logos-bugs -t svg --outputAsCustomElement -c light mixed

yea, its been failing for quite a while (probably since Dec 21, 2021 https://github.com/linkedin/icon-magic/runs/4601555441?check_suite_focus=true).

repo: linkedin/icon-magic


text:
Make maxInitialResultHolderCapacity for group-by executor configurable

This capacity will be used for both inital capacity and array based key holder threshold.
In most cases, array based key holder implementation is way faster than map based.

Codecov Report

Merging #1915 into master will increase coverage by 0.19%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1915      +/-   ##
==========================================
+ Coverage   69.32%   69.51%   +0.19%
==========================================
  Files         830      830
  Lines       40163    40173      +10
  Branches     5390     5391       +1
==========================================
+ Hits        27844    27928      +84
+ Misses      10453    10374      -79
- Partials     1866     1871       +5

Impacted Files
Coverage Δ

...pinot/core/plan/maker/InstancePlanMakerImplV2.java
91.66% <100%> (+0.49%)
:arrow_up:

...in/pinot/core/plan/AggregationGroupByPlanNode.java
60% <100%> (+2.1%)
:arrow_up:

...ore/operator/query/AggregationGroupByOperator.java
88.46% <100%> (+0.46%)
:arrow_up:

...ry/aggregation/groupby/DefaultGroupByExecutor.java
93.61% <100%> (+0.06%)
:arrow_up:

...tion/groupby/DictionaryBasedGroupKeyGenerator.java
97.57% <100%> (ø)
:arrow_up:

...kedin/pinot/core/query/reduce/EqualComparison.java
55.55% <0%> (-11.12%)
:arrow_down:

...pinot/core/operator/docidsets/OrBlockDocIdSet.java
84.9% <0%> (-9.44%)
:arrow_down:

...y/aggregation/function/AvgAggregationFunction.java
92% <0%> (-4%)
:arrow_down:

...nsport/netty/PooledNettyClientResourceManager.java
87.23% <0%> (-2.13%)
:arrow_down:

...src/main/java/com/linkedin/pinot/common/Utils.java
59.57% <0%> (-2.13%)
:arrow_down:

... and 20 more

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 651899f...ef3702a. Read the comment docs.

authors: Jackie-Jiang codecov-io

repo: linkedin/pinot


text:
Added test for M3-1650 Add volume pricing to volume creation drawer

Purpose
Added test for M3-1650 Add volume pricing to volume creation drawer.
To Test
yarn && yarn start new shell yarn selenium new shell yarn e2e:modified

Coverage remained the same at 28.067% when pulling a4c555dba4c858ee3ac0ce1c75de6f269d551477 on nwisnewski:M3-1781-add-volume-pricing-to-create-drawer into 03897aa3f837125138a32e5325a96ff53e4a1e91 on linode:develop.

authors: coveralls nwisnewski

repo: linode/manager


text:
M3-4059 [LKE]: Kubernetes Detail Summary

Description

Restructured Kubernetes cluster Summary Panel (KubeSummaryPanel component). Added Total Storage, Kubeconfig download, and icons to it.
Updated getTotalClusterMemoryCPUAndStorage() to calculate Total Storage; revised kubeUtils tests accordingly.
Made necessary changes to ExtendedCluster and kubernetesClusterFactory for Total Storage purposes.

Note: The Tags functionality for clusters is not yet in place, but will be added to the Summary panel once it is.
Type of Change

Non breaking change ('update', 'change')

Tests

yarn test kubeUtils.test.ts

Note to Reviewers
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration.

The "Provisioning" view from the designs & the associated endpoint polling will be added in a separate PR


text:
"ReactHotLoader" occurrences in published package

At the end of each file in the package version from npm a larger definition regarding the ReactHotLoader is contained.
When I include this package I have 20 instances of that including the path C:\Users\LWTech Gaming\Code Projects\react-console-emulator\src in my bundle.
Probably this is a configuration error in webpack step?

Whoops, this does indeed appear to be an error, as that should not be going downstream. I'll look into fixing this ASAP - if you know the fix and want to hurry it along, do by all means share!

Thx for looking into it!
For now I patched it out which saved 10KB in the minified bundle ;)
I had a look at the config before I opened the issue, but I couldn't directly see what's wrong as I didn't fully understand the publishing workflow.
You already have the HotLoader only in the Production plugins, so I would have assumed that should work properly.

Fixed in v5.0.1. Thanks for flagging!

Thx, perfect!

Btw. using the plugin for https://github.com/Sebobo/Shel.Neos.Terminal. Works really well :)

Wow, this looks super awesome! Thanks for using my little tool for this! 😊

authors: Sebobo linuswillner

repo: linuswillner/react-console-emulator


text:
New 'pull_production' rake task fails for me

The new 'pull_production' rake task fails for me.  Trying to run it does this:
pg_dump: saving database definition
pg_dump: dumping contents of table projects
pg_dump: [archiver (db)] query failed: SSL SYSCALL error: Connection timed out
pg_dump: [archiver (db)] query was: COPY public.projects .... TO stdout;
pg_restore: connecting to database for restore
Password:
pg_restore: [archiver (db)] connection to database "development" failed: fe_sendauth: no password supplied
Password:
psql: FATAL:  password authentication failed for user "dwheeler"
FATAL:  password authentication failed for user "dwheeler"

I had tried this earlier and never got this approach to work for me.  There aren't many users of this rake task (!), so I think the quick solution is to just restore in addition the rake task that actually works for me:
desc 'Copy database from production into development (requires access privs)'
task :pull_database do
  puts 'Getting database'
  # This fails, probably because we use Unix sockets with local db:
  # sh 'rake db:drop &&
  #     heroku pg:pull DATABASE_URL development --app production-bestpractices'
  sh 'heroku pg:backups capture --app production-bestpractices && \
      curl -o db/latest.dump `heroku pg:backups public-url \
        --app production-bestpractices` && \
      rake db:reset && \
      pg_restore --verbose --clean --no-acl --no-owner -U `whoami` \
        -d development db/latest.dump'
  puts 'You may need to run "rake db:migrate".'
end

Before doing that, please spend a minute trying to get pg:pull working. The issue, I believe, is that you aren't using a default password on your local postgres. See: https://github.com/heroku/heroku-pg-extras/issues/42#issuecomment-47258173
Alternatively, try running the the following:
PGUSER=some_user PGPASSWORD=some_password heroku pg:pull

Okay, makes sense.  I ran:
sudo -u postgres createdb `whoami`

and am trying again.  It take a long time to pull, which is odd because the database doesn't really have a lot of data.  (Granted, all the old versions take some real space.. but not THAT much space.)

Huh.  Now the "psql" command works just fine, but the download still fails:
.... crypto_certificate_verification_justification, crypto_verification_private_status, crypto_verification_private_justification, hardened_site_status, hardened_site_justification, installation_common_status, installation_common_justification, build_reproducible_status, build_reproducible_justification) TO stdout;
pg_restore: connecting to database for restore
Password:
pg_restore: [archiver (db)] connection to database "development" failed: fe_sendauth: no password supplied
Password:
psql: FATAL:  password authentication failed for user "dwheeler"
FATAL:  password authentication failed for user "dwheeler"
psql failed. exit status 512, output: ""
/usr/local/heroku/lib/heroku/command/pg.rb:793:in `exec_sql_on_uri'
/usr/local/heroku/lib/heroku/helpers/pg_dump_restore.rb:114:in `exec_sql_on_uri'
/usr/local/heroku/lib/heroku/helpers/pg_dump_restore.rb:95:in `verify_extensions_match'
/usr/local/heroku/lib/heroku/helpers/pg_dump_restore.rb:28:in `verify'
/usr/local/heroku/lib/heroku/helpers/pg_dump_restore.rb:16:in `execute'
/usr/local/heroku/lib/heroku/command/pg.rb:411:in `block in pull'
/usr/local/heroku/lib/heroku/helpers/heroku_postgresql.rb:77:in `maybe_tunnel'
/usr/local/heroku/lib/heroku/command/pg.rb:406:in `pull'
/usr/local/heroku/lib/heroku/command.rb:212:in `run'
/usr/local/heroku/lib/heroku/cli.rb:33:in `start'
/usr/local/heroku/bin/heroku:25:in `<main>'
 !    Heroku client internal error.
 !    Search for help at: https://help.heroku.com
 !    Or report a bug at: https://github.com/heroku/heroku/issues/new

    Error:       psql failed. exit status 512, output: "" (RuntimeError)
    Command:     heroku pg:pull DATABASE_URL development --app production-bestpractices
    Version:     heroku-toolbelt/3.42.45 (x86_64-linux) ruby/2.3.0

http://stackoverflow.com/questions/7667193/heroku-dbpull-failing-due-to-lack-of-password-when-i-havent-specified-a-passwo
--
Dan Kohn mailto:dankohn@linux.com
Senior Advisor, Core Infrastructure Initiative
tel:+1-415-233-1000
On Wed, May 4, 2016 at 6:43 PM, David A. Wheeler notifications@github.com
wrote:

Huh. Now the "psql" command works just fine, but the download still fails:
.... crypto_certificate_verification_justification, crypto_verification_private_status, crypto_verification_private_justification, hardened_site_status, hardened_site_justification, installation_common_status, installation_common_justification, build_reproducible_status, build_reproducible_justification) TO stdout;
pg_restore: connecting to database for restore
Password:
pg_restore: [archiver (db)] connection to database "development" failed: fe_sendauth: no password supplied
Password:
psql: FATAL:  password authentication failed for user "dwheeler"
FATAL:  password authentication failed for user "dwheeler"
psql failed. exit status 512, output: ""
/usr/local/heroku/lib/heroku/command/pg.rb:793:in exec_sql_on_uri' /usr/local/heroku/lib/heroku/helpers/pg_dump_restore.rb:114:in exec_sql_on_uri'
/usr/local/heroku/lib/heroku/helpers/pg_dump_restore.rb:95:in verify_extensions_match' /usr/local/heroku/lib/heroku/helpers/pg_dump_restore.rb:28:in verify'
/usr/local/heroku/lib/heroku/helpers/pg_dump_restore.rb:16:in execute' /usr/local/heroku/lib/heroku/command/pg.rb:411:in block in pull'
/usr/local/heroku/lib/heroku/helpers/heroku_postgresql.rb:77:in maybe_tunnel' /usr/local/heroku/lib/heroku/command/pg.rb:406:in pull'
/usr/local/heroku/lib/heroku/command.rb:212:in run' /usr/local/heroku/lib/heroku/cli.rb:33:in start'
/usr/local/heroku/bin/heroku:25:in `'
!    Heroku client internal error.
!    Search for help at: https://help.heroku.com
!    Or report a bug at: https://github.com/heroku/heroku/issues/new
Error:       psql failed. exit status 512, output: "" (RuntimeError)
Command:     heroku pg:pull DATABASE_URL development --app production-bestpractices
Version:     heroku-toolbelt/3.42.45 (x86_64-linux) ruby/2.3.0

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/linuxfoundation/cii-best-practices-badge/issues/320#issuecomment-217025867

Did you try these options?

A reinstall of my local environment fixed it long ago. There was probably some weird local corruption. This seems to have been specific to my situation a long time back, so I'm closing this.

authors: dankohn david-a-wheeler


text:
cpu_watcher：统计抢占时间功能添加

添加统计抢占调度时间的功能。

@zhangzihengya review一下

有冲突要解决一下哈

authors: helight vvzxy

repo: linuxkerneltravel/lmp