elyra-pipeline describe command: list component source dependencies

What changes were proposed in this pull request?
This PR extends the elyra-pipeline describe command by listing (custom) component sources that the pipeline requires.
Example outputs:
$ elyra-pipeline describe io-test.pipeline
...

Name: io-test
Description: test pipeline components
Type: kfp
Version: 5
Nodes: 3
File Dependencies:
    None Listed
Component Dependencies:
    - /Users/patti/elyra_dev/workspace/examples/pipelines/run-pipelines-on-kubeflow-pipelines/components/download-file.yaml
    - /Users/patti/elyra_dev/workspace/examples/pipelines/run-pipelines-on-kubeflow-pipelines/components/count-rows.yaml
    - /Users/patti/elyra_dev/workspace/examples/pipelines/run-pipelines-on-kubeflow-pipelines/components/truncate-file.yaml

JSON formatted:
$ elyra-pipeline describe io-test.pipeline --json

────────────────────────────────────────────────────────────────
 Elyra Pipeline details
────────────────────────────────────────────────────────────────

{
    "name": "io-test",
    "description": "test pipeline components",
    "type": "kfp",
    "version": 5,
    "nodes": 3,
    "component_dependencies": [
        "/Users/patti/elyra_dev/workspace/examples/pipelines/run-pipelines-on-kubeflow-pipelines/components/download-file.yaml",
        "/Users/patti/elyra_dev/workspace/examples/pipelines/run-pipelines-on-kubeflow-pipelines/components/count-rows.yaml",
        "/Users/patti/elyra_dev/workspace/examples/pipelines/run-pipelines-on-kubeflow-pipelines/components/truncate-file.yaml"
    ]
}

Generic pipeline (no custom components used):
$ elyra-pipeline describe generic.pipeline

Name: generic
Description: None
Type: generic
Version: 5
Nodes: 1
File Dependencies:
    None Listed
Component Dependencies:
    None Listed

How was this pull request tested?
Manual testing (generic pipeline, runtime specific kfp pipeline) + updated regression tests.

Developer's Certificate of Origin 1.1
   By making a contribution to this project, I certify that:

   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the Apache License 2.0; or

   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated
       in the file; or

   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.

   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.

hold for merge prior to 3.2.1 release


valgrind does not work (sorry!)

So...I tried running valgrind today on one of my programs. This is the result.
valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      strlen
valgrind:  in an object with soname matching:   ld-linux-x86-64.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2
valgrind:
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.  The package you need
valgrind:  to install for fix (1) is called
valgrind:
valgrind:    On Debian, Ubuntu:                 libc6-dbg
valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
valgrind:
valgrind:  Cannot continue -- exiting now.  Sorry.
This error seems to trigger no matter what I try: /bin/ls, /bin/true/, /bin/cd, etc.
Would creating a package for libc6 fix this, perhaps? If so, I'll gladly make it because I really would like to see valgrind working.

Also happens to me while going through the Learn C The Hard Way book.
valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      strlen
valgrind:  in an object with soname matching:   ld-linux-x86-64.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2
valgrind:
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.  The package you need
valgrind:  to install for fix (1) is called
valgrind:
valgrind:    On Debian, Ubuntu:                 libc6-dbg
valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
valgrind:
valgrind:  Cannot continue -- exiting now.  Sorry.

Manual install also does not work.
$ make install
make  install-recursive
make[1]: Entering directory `/home/codio/workspace/valgrind-3.10.1'
Making install in include
make[2]: Entering directory `/home/codio/workspace/valgrind-3.10.1/include'
make[3]: Entering directory `/home/codio/workspace/valgrind-3.10.1/include'
make[3]: Nothing to be done for `install-exec-am'.
 /bin/mkdir -p '/usr/local/include/valgrind'
/bin/mkdir: cannot create directory `/usr/local/include/valgrind': Permission denied
make[3]: *** [install-nobase_pkgincludeHEADERS] Error 1
make[3]: Leaving directory `/home/codio/workspace/valgrind-3.10.1/include'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/home/codio/workspace/valgrind-3.10.1/include'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/codio/workspace/valgrind-3.10.1'
make: *** [install] Error 2


mysql主从切换后，haproxy配置咨询

What version of MoHA are you using?
最新版
Does this issue reproduce with the latest release?
N/A
What operating system and processor architecture are you using?
N/A
What did you do?

What did you expect to see?
N/A
What did you see instead?
N/A
咨询一下，我的理解，当mysql发生主从切换后，agent会把最新的MySQL主从角色与ip地址对应关系写入etcd。haproxy会将写流量转发到最新的mysql主库ip地址去。我的疑惑是，haproxy通过什么机制感知到etcd里的信息变化，并且将变化准确快速地同步到haproxy的配置里去的呢？

haproxy 如何感知后端主从变化，请dbproxy有开源吗


Link to Debate authors in Land Debate not functioning

The automatic linking of debate facilitators in Land Debate is not working. It is not possible to add debate facilitators. When typing the name, no names appear.  This was working fine and stopped working for no apparent reason. It will negatively affect our credibility if not fixed immediately.

The error was "The view users is no longer eligible for the Facilitators field."
https://landportal.info/admin/reports/event/58616
The hot-fix solution was a change, using the admin UI, of ENTITY SELECTION.mode, from Views to Simple option.
https://landportal.info/admin/structure/types/manage/debate/fields/field_facilitators/field-settings
Maybe this link could help
https://www.drupal.org/node/2476457

this is fixed and rebaked in the landportal base module.
recently a debate was created and facilitators added without issues


ACD torrented files. Sometimes when I backup my incoming torrent folder, incomplete files on the cloud are overwritten by complete files (good) and sometimes they aren't (bad)

ACD torrented files. Sometimes when I backup my incoming torrent folder, incomplete files on the cloud are overwritten by complete files (good) and sometimes they aren't (bad)
I'm just using a basic rclony copy "source" "remote:destination"
Is there a different command that will make this do what I want?
I know I could use a flag to make files ALWAYS overwrite, but the problem is that sometimes after I backup a file, especially a large video file, I delete it from my harddrive, because say, I don't think I'm likely to need it, but I rarely might. After this happens my torrent program often replaces the file, with the same name, with a <1kb file (this happens because I've left the torrent paused instead of deleting it entirely).
Is there any flag to do what I want?  I had thought the default copy command was working fine, why? because well when the file is updated to a newer local last modified date it usually ends up making the overwrite happen. I just recently ran into an example where it didn't though. It's difficult to tell when there's been a failure though without redownloading the file from ACD and finding it to be broken.
Ideally rclone would compare actual filesize and date, and only overwrite newer AND larger files. The problem is I'm not sure rclone can even see "actual" filesize for non-pre-allocated torrents where the file in windows explorer says filesize:2gb size on disk:1kb
This isn't really a bug, so I am not sure it belongs here, but I do not know who else to ask for a solution. Maybe a collection of flags can be used to achieve what I want, but I am not sure if that's true.
P.S. Where can I email log files? I've got a log file of me trying to upload with rclone copy a valid file to overwrite an invalid file, the invalid file is in theory a file that was uploaded a long time earlier, modified much earlier, created earlier on my harddrive, and the file on ACD is full mostly of random bits because it was just allocated from an incomplete torrent I'd just started, whereas the new file is completely downloaded and functional. note: I wrote this post using rclone v1.33 but I made sure to update to rclone v1.35 when attempting to generate a log of the problem I'm having (although I doubt this issue is addressed in the patches). windows7 64bit.
I've got an example where I backed up with rclone a 20% complete torrent, today, just now, with the torrent NOT pre-allocating all the space. Then I let the torrent finish and tried to back up again.
In the other example the copy on ACD has been there through dozens of rclone copy backup attempts, and for some reason still has an incomplete copy, I recently deleted the file from my computer, redownloaded the torrent entirely and generated this.
P.P.S. I've looked at one of the log files and there's nothing to say about it really, it just says that the files are the same size so no transfer will be made, EVEN THOUGH one file is many months newer than the other file. I need flags that will NOT ignore size NOR ignore date. This is supposed to be the default rclone copy behavior I thought?
Literally the only relevant part of my log file is"
Sizes identical
2017/02/19 06:37:23 FILENAME: Unchanged skipping
"
Yet the file on ACD is listed as from november and the file I'm trying to upload is from today. Does this mean ACD cannot use modification time data at all in anyway? I am aware ACD doesn't store the correct date modified time from the file you upload, but the website does display a date uploaded time. Could not this date uploaded time be used in place of date modified time of the file? This would be all I need. If the file on my computer has been changed since my last backup, then yes, I do want it replaced usually.
Ideally what solves all my problems is: if the file is newer AND it's the same size, DO overwrite. If the file is older and the same size DO NOT overwrite. If the file is newer AND it's NOT the same size DO NOT overwrite. This would work for all my cases. I cannot see this as a flag choice though?
If there is no way to use ACD's date uploaded from it's website/app.... then maybe there's a way to check ACTUAL filesize? if there's no way to use actual-filesize, nor any way to use ACD uploaded date, I guess I should start using checksum? even though that would be very slow it would detect changes in completed torrents from partial ones. That would kind of suck though since either size or date information would work, if it were able to be used. Here's an imgur of what I mean by "actual" filesize. http://imgur.com/HBw9LYZ
P.P.P.S. -u, --update
sounds like it does what I want! --update --ignore-size I think will do everything I want 100%! Wow, how'd I never know about --update before! Let me go test that theory before I close the issue.
P.P.P.P.S. Okay, --update does do the uploads I want. However it seems that --update will always ignore size! because it didn't mention the sizes being identical, and it did the upload anyways. So then, this is still an issue, there seems to be no way to do a --update command that only updates if your source file is newer AND filesizes are different. I wouldn't want to use this I'd probably prefer --update --ignore-size which is the default behavior but someone else might want to compare size in a --update command. Additionally this doesn't solve the issue of "actual" filesizes but those might be impossible for rclone to access in anyway. I know this is not very well written, but I am going to leave this issue open. Sorry if it was annoying to read. Feel free to close the issue, or even delete it. It does seem though there is room to upgrade --update. Let me know if you want my -vv's but there's no errors in them, nothing interesting. I'd also prefer not to post them here for privacy reasons, but I would be willing to email them to you if you are interested to see them.
P.P.P.P.P.S. It might also be nice to make it possible to use --update and --checksum at the same time, only waste time doing checksum's on files that are newer, this would be useful because currently --update doesn't check size at all (although allowing --update to check size might be the easier fix).

Not a fix, but maybe you shouldn't upload incomplete torrents that are still downloading or not finished?

This was not the case for my testing files, but the scenario this happens for in the wild is torrents that are unpopular/discontinued/notwellseeded meaning it might take weeks or months or even never finish. This has also been a concern of mine for a long time, but you're right, just manually checking such details would also have solved the problem, that's what I always tried to do, but I made mistakes very rarely.
--update flat out just solves the problem though, because when the torrent finishes it'll be a newer file on my harddrive than my last backup and it'll upload it. The only reason I didn't close my own issue is that --update does not work as stated in the documentation, in that --update does not check size (maybe it's not supposed to but documentation says it does).

--update flat out just solves the problem though, because when the torrent finishes it'll be a newer file on my harddrive than my last backup and it'll upload it. The only reason I didn't close my own issue is that --update does not work as stated in the documentation, in that --update does not check size (maybe it's not supposed to but documentation says it does).

Glad update solves the problem.
I just had a look at the source, and update does work exactly as the docs state

-u, --update
This forces rclone to skip any files which exist on the destination
and have a modified time that is newer than the source file.
If an existing destination file has a modification time equal (within
the computed modify window precision) to the source file’s, it will be
updated if the sizes are different.

So the size is only checked if the times are equal.
I was following rsync when I wrote that flag, and here is what rsync's man page states

-u, --update
This forces rsync to skip any files which exist on the
destination and have a modified time that is newer than the
source file.  (If an existing destination file has a
modification time equal to the source file’s, it will be
updated if the sizes are different.)

As for the original problem I would probably try to solve the problem
a different way, having an incoming directory and move the things out
of the incoming directory when satisfied.  You can use
--track-renames to make sure the move means it doesn't need to be
uploaded again.

Ahh, my bad.

This was answered and ACD is dead.


Can't get xml content

I'm testing the library, but I can't get the content of my xml.
I get instead:
{
  Declaration: {
    attributes: { _version: '1.0', _encoding: 'utf-8', _standalone: 'no' },
    raw: 'version="1.0"encoding="utf-8"standalone="no"'
  }
}

My code is:
const fs = require('fs')
const path = require('path')
const { toObject } = require('node-xml-to-js')

fs.readFile(
  path.join(__dirname, '/xml_files/1e60fe25-57bc-4373-9317-5bcd0ce44660.xml'), 'utf8', (err, data) => {
    if (err) {
      console.error(err)
      return
    }

    let User = toObject(data)
    console.log(User)
  },
)

could you send the data from the XML file?

I just updated the library and repo. Could you redownload the lib and try again?


Fix typos

Yesterday I translated this guideline into German in order to discuss it at work.
Thereby I noticed some typos in the English original, which this PR fixes. For example, missing closing brackets or inconsistent usage of bolding (omitting question marks).
I'm sad, that so many projects still not offer HTTPS (visited every non-HTTPS and looked at HTTPS Everywhere add-on to check). For those, who do, I updated the URL.

:+1:

Awesome, thanks so much @Ryuno-Ki!


kdiff3: Update to version 1.10.1

KDE doesn't release with fixed filenames, thus the checkver regex needs to be updated to match also the latest file name.

[x] I have read the Contributing Guide.

/verify


Dashboard unavailable after ESPHome version change

Operating environment/Installation (Hass.io/Docker/pip/etc.):

ESPHome in Docker behind SWAG (https://hub.docker.com/r/linuxserver/swag) reverse proxy.
docker-compose entry:
esphome:
    #image: esphome/esphome:1.18.0
    image: esphome/esphome:1.19.2
    container_name: esphome
    networks:
      - ha_network
    environment:
      - ESPHOME_DASHBOARD_USE_PING=true
    volumes:
        - /docker/esphome/config:/config
    ports:
      - 6052:6052
    restart: unless-stopped

ESP (ESP32/ESP8266, Board/Sonoff):

ESP32 / ESP8266
ESPHome version (latest production, beta, dev branch)

latest
Affected component:

Description of problem:
Upgraded Docker image from 1.18.0 to 1.19.0 then 1.19.1 and then 1.19.2. Each time I tried restarting the Docker container but the dashboard UI elements were unresponsive in Safari and Firefox but worked in Chrome.
I have tried restarting browsers, clearing caches etc but the dashboard remains unresponsive.
All elements are grey, none of the usual link elements respond when clicked.
Safari:

Chrome:

If I roll back to 1.18.0 everything works in Safari again:

Problem-relevant YAML-configuration entries:
PASTE YAML FILE HERE

Logs (if applicable):

PASTE DEBUG LOG HERE

Additional information and things you've tried:

What version of Safari? And can you test Firefox?

Safari: Version 13.1.3 (15609.4.1)

I only have Safari 14.1.1 (166<IP_ADDRESS>.4) locally  on a Mac but am unable to reproduce it.
I ran it this way:
docker run --rm -p 6052:6052 -e ESPHOME_DASHBOARD_USE_PING=true -v "${PWD}":/config -it esphome/esphome

In Safari, can you go to develop -> Show JavaScript console and refresh the page. Do you see any errors?

Related: https://github.com/esphome/issues/issues/2174
Maybe interesting snippet:

everything works if i go to the ip:port of esphome 192.168.1.xx:6052, it just doesn't work in a frame within home assistant

ok... so I left a small bit of info out of the original issue. I run the swag (https://hub.docker.com/r/linuxserver/swag) reverse proxy for esphome dashboard and homeassistant (takes care of my LetsEncrypt SSL certs). If I connect direct to the docker instance on port 6052 it all works.

What version of Safari? And can you test Firefox?

Worked in Firefox via the SSL reverse proxy

I only have Safari 14.1.1 (166<IP_ADDRESS>.4) locally on a Mac but am unable to reproduce it.
I ran it this way as per the docs:
docker run --rm -p 6052:6052 -e ESPHOME_DASHBOARD_USE_PING=true -v "${PWD}":/config -it esphome/esphome

In Safari, can you go to develop -> Show JavaScript console and refresh the page. Do you see any errors?

The only error I see in the Javascript console is this:

i have the same issue, https://github.com/esphome/issues/issues/2174
running safari Version 13.1.2 (136<IP_ADDRESS>.5)
javascript console i get 1 error and two warnings
[Warning] The main 'lit-element' module entrypoint is deprecated. Please update your imports to use the 'lit' package: 'lit' and 'lit/decorators.ts' or import from 'lit-element/lit-element.ts'. (app.bcb38ac1.js, line 849)
[Warning] The main 'lit-element' module entrypoint is deprecated. Please update your imports to use the 'lit' package: 'lit' and 'lit/decorators.ts' or import from 'lit-element/lit-element.ts'. (entrypoint.0d3c68f7.js, line 4171)
[Error] Failed to load resource: the server responded with a status of 401 (Unauthorized) (index-7c27abab.js, line 0)

@erikpendragon there is no authorization on the dashboard so maybe you also forgot to mention that you're running something custom in front of it?

i have nginx setup as per the add-on instructions with duckdns
domain: '!secret dns_domain'
certfile: fullchain.pem
keyfile: privkey.pem
hsts: max-age=31536000; includeSubDomains
cloudflare: false
customize:
active: false
default: nginx_proxy_default*.conf
servers: nginx_proxy/*.conf

@erikpendragon there is no authorization on the dashboard so maybe you also forgot to mention that you're running something custom in front of it?

I run Authelia with SWAG. Authelia provides the authentication for the reverse proxy. It worked fine during the 1.18.0 to 1.19.2 upgrade using Chrome and Firefox, it is only Safari that is causing issues.

 Another "small bit" you forgot to mention.
I am going to take a break from this issue as I feel like I am being sent on a goose chase.

 Another "small bit" you forgot to mention.
I am going to take a break from this issue as I feel like I am being sent on a goose chase.

Nobody has sent you anywhere or on any wild goose chase. I raised the issue in a rush and inadvertently missed these details. It worked in Chrome and Firefox with the nginx reverse proxy / Authelia just not Safari. Enjoy life. Cya.

mine worked fine before 1.19.x+ as well

Here is the fix https://github.com/home-assistant/frontend/pull/3259
Feel free to open a PR.

Here is how to fix it home-assistant/frontend#3259
Feel free to open a PR.

i am not sure how this fixes it, it looks to be a code change to the front end. am i expected to pull this myself and request it to be merged back in corrected? how does this issue become a fix?

It's been raised here as well: https://github.com/esphome/issues/issues/2174

I have same problem since couple of versions ago.
How to fix it? The link above doesn't really tell how to fix.

I changed to Firefox and it’s working again.

Yes, Chrome works also but it should work in Safari as well as it did before.

Agree

Was this fixed or just closed?


updating local-pyspark notebook

Issue #, if available:
Description of changes:
Adding example for running PySpark locally
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Available here:
https://github.com/aws/amazon-sagemaker-examples/tree/main/sagemaker_processing/local_pyspark


Staffing Request

Add Staffing Request form

Resolved in https://github.com/adh-partnership/frontend/pull/275


Support worker node taints

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/test eks-anywhere-e2e-presubmit

/test eks-anywhere-e2e-presubmit

Description of changes: We tried adding taints in capi spec for worker nodes, but that did not work and nodes came up without any taints. So we choose this approach of manually adding taints on worker nodes after the nodes were up. This was not the case for control plane nodes. They came up with taints when we added taints in capi spec.

Do we know exactly why it didn't work? Is it a bug in CAPI? did it fail for both docker and vsphere? I would like to get more info on this to see if there is something we can contribute upstream
This approach has a small flaw and is that nodes will come up first without taints, so there is a period of time in between the node creation and the tainting where workloads can be assigned to them when they shouldn't.

This does not work with vsphere. There is this issue open with capi which might take care of this problem.
https://github.com/kubernetes-sigs/cluster-api/issues/493

superseded by https://github.com/aws/eks-anywhere/pull/977


cyclonedds: 0.10.3-1 in 'humble/distribution.yaml' [bloom]

Increasing version of package(s) in repository cyclonedds to 0.10.3-1:

upstream repository: https://github.com/eclipse-cyclonedds/cyclonedds.git
release repository: https://github.com/ros2-gbp/cyclonedds-release.git
distro file: humble/distribution.yaml
bloom version: 0.11.2
previous version for package: 0.9.1-1

Thanks, this is great to get updated!


How to link a program against tcmalloc_minimal with mingw-w64?

On linux I just compile and link my program like this: g++ -O2 -o test main.cpp -ltcmalloc_minimal and it works, which I know since it prints messages like this:

tcmalloc: large alloc<PHONE_NUMBER> bytes == 0x21e0000 @

Now I am trying to accomplish the same thing using minw-w64 cross-compilation.

x86_64-w64-mingw32-g++ -O2 -o test.exe main.cpp -ltcmalloc_minimal

And when I start the test.exe > out.txt 2>&1 on windows, I do not get any messages from tcmalloc and program starts just fine even if I remove libtcmalloc_minimal.dll. Dependency walker also does not show anything about tcmalloc.
I use the cross-build environment from Arch linux, which works wonderfull and provides the mingw-w64-gperftools package, which also seems to build and install fine (I get the libtcmalloc_minimal-4.dll, libtcmalloc_minimal.a libtcmalloc_minimal.dll.a).
I also tried using extra parameters:

x86_64-w64-mingw32-g++ -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free  -o test.exe main.cpp -ltcmalloc_minimal

Does not help. Could not find anything that would work in internet either.
How do I link a program against tcmalloc using mingw?
Here is the source that I am compiling:
main.cpp:
#include <vector>
#include <iostream>
#include <numeric>
int main()
{
  std::vector<double> vec;
  vec.resize(1024L*1024L*1024L,10.0);
  std::cout<<long(std::accumulate(vec.begin(),vec.end(),0.0))<<std::endl;
  return 0;
}

Try pulling some tcmalloc-specific symbol. Adding this to ldflags  -Wl,--require-defined=tc_malloc may do the trick. If you're linking to .dll, you way want to try -Wl,--no-as-needed.

@alk Thank you for your answer!
Building with
x86_64-w64-mingw32-g++ -O2 -o test.exe main.cpp -Wl,--no-as-needed -ltcmalloc_minimal

Does not seem to change anything, tcmalloc_minimal is ignored.
If I build with
x86_64-w64-mingw32-g++ -O2 -o test.exe main.cpp -Wl,--require-defined=tc_malloc -ltcmalloc_minimal

or
x86_64-w64-mingw32-g++ -O2 -o test.exe main.cpp  -Wl,--require-defined=tc_malloc -Wl,--no-as-needed -ltcmalloc_minimal

it starts complaining if libtcmalloc_minimal.dll is missing, which is good, but when I provide the dll, the program freezes and the does not seem to do anything - no cpu usage, only 1.2 MB of RAM.

I also tried using gdb to debug the program, but it does not even seem get to the main():

C:>gdb test.exe
GNU gdb (GDB) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from test.exe...done.
(gdb) break main
Breakpoint 1 at 0x4015c3: file main.cpp, line 7.
(gdb) next
The program is not being run.
(gdb) start
Temporary breakpoint 2 at 0x4015c3: file main.cpp, line 7.
Starting program: C:\test.exe
[New Thread 5732.0xe88]
[New Thread 5732.0x57c]
[New Thread 5732.0xc80]
[New Thread 5732.0x318]
[Thread 5732.0x57c exited with code 0]
[Thread 5732.0x318 exited with code 0]
[Thread 5732.0xc80 exited with code 0]

I am having the same issue, is tcmalloc expected to work with mingw-w64?

Yes, mingw-w64 is supposed to work. I am testing it myself periodically (with mingw64 as shipped by Debian).

@alk what are the compiler/linker arguments that you use?

So I just downloaded .tar.gz of gperftools 2.5, unpacked and did:
$ ./configure --host=x86_64-w64-mingw32
$ make -j8
(There is warning that somehow behaves as error on patching code so I needed to change int to unsigned here https://github.com/gperftools/gperftools/blob/master/src/windows/mini_disassembler_types.h#L191)
then
$ x86_64-w64-mingw32-g++ -O2 -Wall -o malloc_bench.exe benchmark/run_benchmark.c benchmark/malloc_bench.cc -Wl,--require-defined=tc_malloc -L.libs -ltcmalloc_minimal
then copy libtcmalloc_minimal-4.dll, libstdc++-6.dll and libgcc_s_seh-1.dll to current directory and then
$ wine64 ./malloc_bench.exe
works

@alk The exactly same steps does not work in ArchLinux, must be something with ArchLinux  environment. Just one diference is that I need to copy libwinpthread-1.dll too, this make me think that the thread model used by mingw-w64 by default on archlinux is not the same as yours, maybe thats the cause. Also the gcc version:
$ x86_64-w64-mingw32-g++ --version
x86_64-w64-mingw32-g++ (GCC) 6.3.1 20170109

thread model: posix I think is a potential problem. Interestingly, on debian there are two sets of mingw compilers one with win32 and another with posix. I'll see if I can do something quickly about that.

Yes, mingw with pthreads as a c++11 threading option is a problem. We currently cause tcmalloc to use that pthread for stuff such as pthread_key_{create,get,set,delete} (instead of tiny implementations on top of win32 api). And that stuff apparently doesn't work when used early or perhaps it depends on malloc in a way that we cannot support. I am not sure how to even debug that.
Ideally, we won't be using pthread even if mingw supports it. But the issue is we're using types such us pthread_t or pthread_key_t and win32 layer needs to define those types. Which is not possible if mingw insists on it's own definitions.
Right solution I think would be to have custom types perftools_pthread_t and perftools_phread_key_t in addition to existing perftools_XXX functions, so that win32 layer can define those to use native win32 threads without overlapping with mingw types.
If you can contribute that change I'll gladly take it. For now using mingw with win32 c++ threads is the only option that works.


Having Comments as Child Nodes in container breaks DOM Driver

If the HTML container contains comments as children element DOM Driver would error.
It works if it matches exactly the container.
Code to reproduce the issue:
https://esnextb.in/?gist=026302a35432e86020e13104b034d0f0
<div id="app">
  <!-- boom! -->
</div>

function main() {
  const sinks = {
    DOM: xs.periodic(1000).map(i =>
      // this breaks
      h('h1', '' + i + ' seconds elapsed')

      // this works
      // h('div', { props: { id: 'app' }}, [ h('h1', '' + i + ' seconds elapsed') ])
    )
  };
  return sinks;
}

Expected behavior:
It replaces the container and just runs normally
Actual behavior:
Errors out :(
Versions of packages used:
{
  "dependencies": {
    "xstream": "10.2.0",
    "@cycle/run": "3.0.0",
    "@cycle/dom": "16.0.0"
  }
}

{
  "dependencies": {
    "xstream": "10.3.0",
    "@cycle/run": "3.0.0",
    "@cycle/dom": "16.0.0"
  }
}

https://www.webpackbin.com/bins/-KfkKF7Q9Oq58Uou9yeD

sorry, updated the gist, title and package

only happens if it's comments but not if it's a normal element

Okay, thanks for the hint. I'll mark it should since a comment isn't a showstopper.

I sent a PR to snabbdom, pending on that for this issue to be fixed.

thanks @staltz  :D

This was merged and solved in snabbdom v0.6.8, and we'll soon release a Cycle DOM version with it.


build: use Ubuntu Focal for depends, ci and gitian releases

Ubuntu Bionic will go end-of-life in April 2023, so everything that relies on it needs to be updated. This encompasses the:

continuous integration processes
gitian release system
supported OS for the depends system

This PR combines and enhances prior work done by @xanimo in #3133 and #3185 into an end-to-end upgrade to Ubuntu Focal for all these items, at once, because these turn out to all be interdependent on each other after extensive testing. Most of the prerequisites that came from the earlier PRs have already been merged separately, with the only remaining open requirement being #3204: that PR blocks this one as we need a portable set of check tooling to be able to compare binaries across host OS's. The commits from that PR are included in this one - this will need a rebase once that is merged. Commits that belong to this PR are 58553dba1525b71e9fa363af9afe20ca514e2de4 and onward.
what this does

wrap functions with an explicit glibc version selector for linux builds to ensure that the binary remains usable on systems with old glibc (this is enabled with the --enable-glibc-back-compat configure flag):

clock_gettime, exp, log and pow for all target Linux architectures
fcntl and fcntl64 for 32-bit Linux architectures (i686-pc-linux-gnu and arm-linux-gnuabihf targets)

update the clang and cctools packages in depends to respectively versions 6.0.1 and 921 while retaining minimum SDK compatibility. This is needed to be able to compile with our current macOS SDK on focal.
Upgrade the CI to use Ubuntu Focal and gcc 9 for all targets
Upgrade gitian scripts to use Ubuntu Focal and gcc 9 for all descriptors
Update the documentation of requirements for the depends system

what needs to be done now

[x] Wait until #3204 is merged or cross-platform binary checking is attained in any other way

---- once that is done ----

[x] Review, and apologies for the big change (will get a lot smaller after the previous item is checked)
[x] A gitian comparison to ensure that the release build is still deterministic
[x] Tests that binaries from the gitian builds are capable of sync on as old platforms as possible. Think: 32-bit armhf RPi, 32-bit intel with WinXP, Ubuntu Trusty, Centos 7, MacOS Mavericks/Yosemite... and so on.

acknowledgements
This work is the final outcome of months of work and reworking the approach between @xanimo and myself. I couldn't have done this alone. Thank you, @xanimo ❤

Concept and code ACK after rebase. Let's move to the gitian step.

Good catch on the -mlinker-version. Re: pip, I'd say adding precompiled .whl sounds sensible.

I'd rather get pip install working in offline builds if we can -- it's safer! -- but can live with the .whl if we're careful. Maybe we should build and host it ourselves?

In hindsight, I'm not quite sure we need the -mlinker-version yet. I understand it'll usher in a more "modern" linker and cleaner compilation process but we're not even at clang 8.0.0 yet as referenced in that link.
Anyway, wondering if there are any additional steps needed that I can help out on/status update?

(Note I'm in the process of reviewing this, hopefully by EOW 24 Apr, but I'm trying to be meticulous so taking time.)

I have fixed the 2 issues I found myself and have pushed them on top - but these should be squashed. Please let me know if 7665bf6 and be2a61f are okay, then I rebase+squash these before a final gitian check

These look good but are untested from me. Outside of that am wondering if you'd like to bump CodeQL to focal as well? Just noticing it's hanging atm and will never complete and since it fits within the purview of this PR it couldn't hurt.

Will re-review with these two commits and certainly gitian check once we're ready to do so. (which i'm guessing is in the next day or so)..

Disregard CodeQL comment although if you'd like to cherry-pick or have me open a PR or if you want to do it let me know:
https://github.com/xanimo/dogecoin/actions/runs/4900179242
and local test:
https://github.com/xanimo/dogecoin/actions/runs/4900214623

re-on this.

Will try to get my hands on some older platforms to test binaries. In the meantime here is output from last nights build using your gitian-build.sh script with docker:
a3bfc6aea038793f15ef1928350f74d316b4b4cc4a4209607304551551ba14b8  dogecoin-1.14.7-osx-unsigned.dmg
f28aee147818440a23a40caea5a57e82db8620f8e23cf79245285892bf9281c4  dogecoin-1.14.7-osx-unsigned.tar.gz
e934cefbebd9e08802fe827a4cbcd45e4ce656f1840d6a9a6f61c4fabb539af0  dogecoin-1.14.7-osx64.tar.gz
394a46e8fd125a4bcefb3cf6223705b74b10c9c8379d1ca7b5ac2cd86bc329c6  dogecoin-1.14.7-win-unsigned.tar.gz
defe10e5a66f39ef33f33b1dbe1c0b5cd29c7bede0b3981e7bbc7f1a4738502c  dogecoin-1.14.7-win32-debug.zip
2d31c31910c0279fe5ba49a3f1f7dcffa9d8c032125f1ba32900d1d8633267fb  dogecoin-1.14.7-win32-setup-unsigned.exe
bd96ceaad8bd5ebe591b43e1f54c79e4f132c518e23c1d24c0ffa9f57c60aedf  dogecoin-1.14.7-win32.zip
8b6a0909446d83a95c285458bcce8414eb66f3a49e0e6066cb6a28a4e6310c36  dogecoin-1.14.7-win64-debug.zip
1c2719f3d2065b4a735d5b6fc359cd38d448ce4499ecb4bf7eb4ebb1b303584d  dogecoin-1.14.7-win64-setup-unsigned.exe
9616b5f82813c9e258e8bdcc01dd07fce06155a2d062a2a0063ad80db77f747f  dogecoin-1.14.7-win64.zip
c87712433744b4f63c9ce2e1c123c252829371e1ebbd9d6e2191bf9ea64dbafe  dogecoin-1.14.7-aarch64-linux-gnu-debug.tar.gz
705f6d56991d04b3bda1202b54e09889813bebdb374ddf1556ec77fc23d9b899  dogecoin-1.14.7-aarch64-linux-gnu.tar.gz
bc5372b1df4299ed778e3b1bddb621e1a444e25e5b656f821b18ba09a7ac8bb7  dogecoin-1.14.7-arm-linux-gnueabihf-debug.tar.gz
e40c63694b1e72fe2df517703ec8ee59f5787e150b3c356146ec4d39895f0255  dogecoin-1.14.7-arm-linux-gnueabihf.tar.gz
14b0ab0eed791e6ee47af34d447a90c6de2097da8635b19d78fced627f03eb56  dogecoin-1.14.7-i686-pc-linux-gnu-debug.tar.gz
4859b560a5edede1ca6dd355d3a71db2df46713add5f8d8eb0f33de0be8d324d  dogecoin-1.14.7-i686-pc-linux-gnu.tar.gz
814acead867d2bd36450c31ca7fca9daf118a4c1e54e29ba0af622e7febcfa4c  dogecoin-1.14.7-x86_64-linux-gnu-debug.tar.gz
d387c010e03f122147aba9aa7ec6d9c3c569462b3d65fbc387aa7adeb659699f  dogecoin-1.14.7-x86_64-linux-gnu.tar.gz

Working on gitian build, slow going (overnight runs)...  New (but with updates) Focal install, getting a lot of (not at same point) download failures in the gitian-build.sh process.  (Not a hard error or anything.)  Wiggling resources around to see if it gets past it.

Finally.  Apologies for the delay.
`    394a46e8fd125a4bcefb3cf6223705b74b10c9c8379d1ca7b5ac2cd86bc329c6  dogecoin-1.14.7-win-unsigned.tar.gz
defe10e5a66f39ef33f33b1dbe1c0b5cd29c7bede0b3981e7bbc7f1a4738502c  dogecoin-1.14.7-win32-debug.zip
2d31c31910c0279fe5ba49a3f1f7dcffa9d8c032125f1ba32900d1d8633267fb  dogecoin-1.14.7-win32-setup-unsigned.exe
bd96ceaad8bd5ebe591b43e1f54c79e4f132c518e23c1d24c0ffa9f57c60aedf  dogecoin-1.14.7-win32.zip
8b6a0909446d83a95c285458bcce8414eb66f3a49e0e6066cb6a28a4e6310c36  dogecoin-1.14.7-win64-debug.zip
1c2719f3d2065b4a735d5b6fc359cd38d448ce4499ecb4bf7eb4ebb1b303584d  dogecoin-1.14.7-win64-setup-unsigned.exe
9616b5f82813c9e258e8bdcc01dd07fce06155a2d062a2a0063ad80db77f747f  dogecoin-1.14.7-win64.zip
a3bfc6aea038793f15ef1928350f74d316b4b4cc4a4209607304551551ba14b8  dogecoin-1.14.7-osx-unsigned.dmg
f28aee147818440a23a40caea5a57e82db8620f8e23cf79245285892bf9281c4  dogecoin-1.14.7-osx-unsigned.tar.gz
e934cefbebd9e08802fe827a4cbcd45e4ce656f1840d6a9a6f61c4fabb539af0  dogecoin-1.14.7-osx64.tar.gz

c87712433744b4f63c9ce2e1c123c252829371e1ebbd9d6e2191bf9ea64dbafe  dogecoin-1.14.7-aarch64-linux-gnu-debug.tar.gz
705f6d56991d04b3bda1202b54e09889813bebdb374ddf1556ec77fc23d9b899  dogecoin-1.14.7-aarch64-linux-gnu.tar.gz
bc5372b1df4299ed778e3b1bddb621e1a444e25e5b656f821b18ba09a7ac8bb7  dogecoin-1.14.7-arm-linux-gnueabihf-debug.tar.gz
e40c63694b1e72fe2df517703ec8ee59f5787e150b3c356146ec4d39895f0255  dogecoin-1.14.7-arm-linux-gnueabihf.tar.gz
14b0ab0eed791e6ee47af34d447a90c6de2097da8635b19d78fced627f03eb56  dogecoin-1.14.7-i686-pc-linux-gnu-debug.tar.gz
4859b560a5edede1ca6dd355d3a71db2df46713add5f8d8eb0f33de0be8d324d  dogecoin-1.14.7-i686-pc-linux-gnu.tar.gz
814acead867d2bd36450c31ca7fca9daf118a4c1e54e29ba0af622e7febcfa4c  dogecoin-1.14.7-x86_64-linux-gnu-debug.tar.gz
d387c010e03f122147aba9aa7ec6d9c3c569462b3d65fbc387aa7adeb659699f  dogecoin-1.14.7-x86_64-linux-gnu.tar.gz

`

Running test_dogecoin.exe from dogecoin-1.14.7-win32.zip generates this error on Windows XP Pro (Version 2002, Service Pack 3) with a Pentium 4 @ 2.80 GHz: "The procedure entry point if_nametoindex could not be located in the dynamic link library IPHLPAPI.DLL."
According to this discussion (https://github.com/libevent/libevent/pull/1111), if_nametoindex function is only supported from Windows Vista onwards.  We can probably remove this dependency to make core compatible with XP. I can dig deeper if needed.

Thanks, Ed! That's a good find.
To make sure that this is introduced with switching the gcc version and that this was not a regression from the libevent update in 1.14.6, could you let us know what happens when you run the test_dogecoin.exe that is included in the win32 zip from the 1.14.6 release?

Sure thing!  Getting the same error from 1.14.6 test_dogecoin.exe.

This would mean that 1.14.6 would throw the same error - if this gets confirmed per question above, then this is a separate regression (on 1.14.6) and I'd suggest to give Win32/XP some TLC after we merge this (because then we'd have a working CI)

Ok, agreed.  Sounds good!

BeagleBone Black (Ubuntu 16.04.7 LTS)
Architecture:          armv7l
Byte Order:            Little Endian
CPU(s):                1
On-line CPU(s) list:   0
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             1
Model name:            ARMv7 Processor rev 2 (v7l)
CPU max MHz:           1000.0000
CPU min MHz:           300.0000

ubuntu@arm:~$ ldd --version
ldd (Ubuntu GLIBC 2.23-0ubuntu11.3) 2.23
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

ubuntu@arm:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/5/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.12' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.12)

ubuntu@arm:~$ ./dogecoin/dogecoin-1.14.7/bin/test_dogecoin
./dogecoin/dogecoin-1.14.7/bin/test_dogecoin: relocation error: ./dogecoin/dogecoin-1.14.7/bin/test_dogecoin: symbol clock_gettime, version GLIBC_2.4 not defined in file libc.so.6 with link time reference

ubuntu@arm:~$ time ./dogecoin/dogecoin-1.14.6/bin/test_dogecoin
Running 252 test cases...

*** No errors detected

real	14m30.454s
user	10m55.684s
sys	3m28.836s
ubuntu@arm:~$

test_dogecoin from dogecoin-1.14.7-arm-linux-gnueabihf.tar.gz generated an error on this armv7 target, but 1.14.6 did not.

e1c688dfd2df9377b1228735e0f2f0e0e164e53e is v nice sir. booting up gitian vm and will start a build as soon as ed confirms the changes work on his older machines.

Thanks @patricklodder!  Built your changes for armv7 and test_dogecoin passes on the target.
ubuntu@arm:~/dogecoin$ time ./test_dogecoin
Running 253 test cases...

*** No errors detected

real	13m46.996s
user	10m15.776s
sys	3m20.888s
ubuntu@arm:~/dogecoin$ lscpu
Architecture:          armv7l
Byte Order:            Little Endian
CPU(s):                1
On-line CPU(s) list:   0
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             1
Model name:            ARMv7 Processor rev 2 (v7l)
CPU max MHz:           1000.0000
CPU min MHz:           300.0000
ubuntu@arm:~/dogecoin$

Failure for me on 64-bit x86 Linux (Ubuntu 22.04.2 LTS):
============================================================================
Testsuite summary for Dogecoin Core 1.14.7
============================================================================
# TOTAL: 2
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See src/test-suite.log
Please report to https://github.com/dogecoin/dogecoin/issues
============================================================================
make[4]: *** [Makefile:9960: test-suite.log] Error 1
make[4]: Leaving directory '/home/chromatic/dev/dogecoin/src'
make[3]: *** [Makefile:10068: check-TESTS] Error 2
make[3]: Leaving directory '/home/chromatic/dev/dogecoin/src'
make[2]: *** [Makefile:10173: check-am] Error 2
make[2]: Leaving directory '/home/chromatic/dev/dogecoin/src'
make[1]: *** [Makefile:9852: check-recursive] Error 1
make[1]: Leaving directory '/home/chromatic/dev/dogecoin/src'
make: *** [Makefile:694: check-recursive] Error 1

Contents of src/test-suite.log:
********* Start testing of URITests *********
Config: Using QtTest library 5.15.3, Qt 5.15.3 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 11.3.0), ubuntu 22.04
PASS   : URITests::initTestCase()
PASS   : URITests::uriTests()
PASS   : URITests::cleanupTestCase()
Totals: 3 passed, 0 failed, 0 skipped, 0 blacklisted, 0ms
********* Finished testing of URITests *********
********* Start testing of PaymentServerTests *********
Config: Using QtTest library 5.15.3, Qt 5.15.3 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 11.3.0), ubuntu 22.04
PASS   : PaymentServerTests::initTestCase()
FAIL!  : PaymentServerTests::paymentServerTests() Caught unhandled exception
   Loc: [qtestcase.cpp(1939)]
Totals: 1 passed, 1 failed, 0 skipped, 0 blacklisted, 24ms
********* Finished testing of PaymentServerTests *********
terminate called after throwing an instance of 'boost::filesystem::filesystem_error'
  what():  boost::filesystem::create_directory: File exists: "/home/chromatic/.dogecoin"
FAIL qt/test/test_dogecoin-qt (exit status: 134)

e28b7be2d835ed09e1bd11105a0df8591972918a31d141cb83d601aece96fc36  dogecoin-1.14.7-osx-unsigned.dmg
1016154956c80663f813fa279ee56796e8d9de3a9439d72aeae24c19b6c48fe4  dogecoin-1.14.7-osx-unsigned.tar.gz
adf08a3926939dd01802a7adacdf47c987b67c8b5a42ba4aa371150587554d46  dogecoin-1.14.7-osx64.tar.gz

79a7f345a5f6d4b2ebfed8b1247eb7d63300287a9fb1746d00557f85069b2232  dogecoin-1.14.7-win-unsigned.tar.gz
a64791c085a9a8e3e6f832e699fadd4a97139e4ee2510c2da54cc0d33edc1ca0  dogecoin-1.14.7-win32-debug.zip
69dc364611ee001623454bae81d9c9d2e55daacfba17c1f12ceebe18eb79e727  dogecoin-1.14.7-win32-setup-unsigned.exe
e0ebed4132e190d264f1b8d2952b39d63eadefa44763f25e14eaf22edf712985  dogecoin-1.14.7-win32.zip
65ceaf2df96c6bf4a2aa00e3daab3a0bb40d2671d9af1f8508fe53420cb058df  dogecoin-1.14.7-win64-debug.zip
2cdcfc497b327cf340b88528a09ac784b2961dff6c6ba7b360ee3cc4cba08e12  dogecoin-1.14.7-win64-setup-unsigned.exe
30b9604b0503703d9779cd295f3564cd8eb4b5508ad898c749717dc6c1422908  dogecoin-1.14.7-win64.zip

f22f79fe7e1ece3ee268e1999212b761f94194c155764a260e5a5794e521ef57  dogecoin-1.14.7-aarch64-linux-gnu-debug.tar.gz
05d3ae1662e15c8ffcfeb0ce6da3e10734ee5d91497ca08f2a84e11b7cfb457e  dogecoin-1.14.7-aarch64-linux-gnu.tar.gz
b03423ba9c70168b29452781c5e838b7c1152b78d04a4bc9a222f70f0b438635  dogecoin-1.14.7-arm-linux-gnueabihf-debug.tar.gz
eb4bb79bd3b0cd9f36050e74b995975910c4b5c1613b06a7f642c97d19424d02  dogecoin-1.14.7-arm-linux-gnueabihf.tar.gz
1d5b34a4e40ea28a6a7bd39a925599650c16a32038a31b9b245e5f38563588de  dogecoin-1.14.7-i686-pc-linux-gnu-debug.tar.gz
95ba2b5c3b427e4de902897184df800084346b5d633119888ff4a64738a77852  dogecoin-1.14.7-i686-pc-linux-gnu.tar.gz
be46009a2c1e29e8fbd2076dd188b82a5581f6a2a6a53d5fd5320f6106f27a76  dogecoin-1.14.7-x86_64-linux-gnu-debug.tar.gz
a56b84bfe3fbca99b8017b1dacea14fb0923d44a062b71cdaedf274e26357e51  dogecoin-1.14.7-x86_64-linux-gnu.tar.gz

6f7190189f109765e29f49557b57a105881d38c6b51493b6964a858be76e8a52  src/dogecoin-1.14.7.tar.gz

new test target link and binaries available to test:
https://gist.github.com/xanimo/dec5f0f1a91cbc6638eea482cf8890b8
@chromatic going to compile locally on my 64-bit jammy. will post results shortly.

Failure for me on 64-bit x86 Linux (Ubuntu 22.04.2 LTS):
============================================================================
Testsuite summary for Dogecoin Core 1.14.7
============================================================================
# TOTAL: 2
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See src/test-suite.log
Please report to https://github.com/dogecoin/dogecoin/issues
============================================================================
make[4]: *** [Makefile:9960: test-suite.log] Error 1
make[4]: Leaving directory '/home/chromatic/dev/dogecoin/src'
make[3]: *** [Makefile:10068: check-TESTS] Error 2
make[3]: Leaving directory '/home/chromatic/dev/dogecoin/src'
make[2]: *** [Makefile:10173: check-am] Error 2
make[2]: Leaving directory '/home/chromatic/dev/dogecoin/src'
make[1]: *** [Makefile:9852: check-recursive] Error 1
make[1]: Leaving directory '/home/chromatic/dev/dogecoin/src'
make: *** [Makefile:694: check-recursive] Error 1

Contents of src/test-suite.log:
********* Start testing of URITests *********
Config: Using QtTest library 5.15.3, Qt 5.15.3 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 11.3.0), ubuntu 22.04
PASS   : URITests::initTestCase()
PASS   : URITests::uriTests()
PASS   : URITests::cleanupTestCase()
Totals: 3 passed, 0 failed, 0 skipped, 0 blacklisted, 0ms
********* Finished testing of URITests *********
********* Start testing of PaymentServerTests *********
Config: Using QtTest library 5.15.3, Qt 5.15.3 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 11.3.0), ubuntu 22.04
PASS   : PaymentServerTests::initTestCase()
FAIL!  : PaymentServerTests::paymentServerTests() Caught unhandled exception
   Loc: [qtestcase.cpp(1939)]
Totals: 1 passed, 1 failed, 0 skipped, 0 blacklisted, 24ms
********* Finished testing of PaymentServerTests *********
terminate called after throwing an instance of 'boost::filesystem::filesystem_error'
  what():  boost::filesystem::create_directory: File exists: "/home/chromatic/.dogecoin"
FAIL qt/test/test_dogecoin-qt (exit status: 134)

running:
make -C depends HOST=x86_64-pc-linux-gnu
./autogen.sh
./configure --prefix=`pwd`/depends/x86_64-pc-linux-gnu --enable-reduce-exports --enable-glibc-back-compat --enable-zmq LDFLAGS="-static-libstdc++"
make check

yielded:
PASS: test/test_dogecoin
PASS: qt/test/test_dogecoin-qt
============================================================================
Testsuite summary for Dogecoin Core 1.14.7
============================================================================
# TOTAL: 2
# PASS:  2
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================

so can't repro either. perhaps you're using wrong gcc? mine is:
bluezr@bluezr:/mnt/source/repos/dogecoin$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.5.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-9-5Q4PKF/gcc-9-9.5.0/debian/tmp-nvptx/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
gcc version 9.5.0 (Ubuntu 9.5.0-1ubuntu1~22.04)

yeah i know it's beyond scope. i even had just run again with --with-gui=qt5 and get same results but haven't confirmed symbol-check, just wanted to see if i got the same results as @chromatic.

so just after initial attempt to build (for fun...) i'm getting resolution errors :'( and not sure if i should take any more time or space away from reviewers...
 => ERROR [3/7] RUN apt-get update &&     apt-get install -y curl git build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils libboost-system-dev libboost-filesystem-dev libboost-  9.5s
------
 > [3/7] RUN apt-get update &&     apt-get install -y curl git build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils libboost-system-dev libboost-filesystem-dev libboost-chrono-dev libboost-program-options-dev libboost-test-dev libboost-thread-dev libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler libqrencode-dev libdb5.3++-dev libdb5.3++ libdb5.3-dev libzmq3-dev libminiupnpc-dev:
#0 0.372 Ign:1 http://archive.ubuntu.com/ubuntu jammy InRelease
#0 0.372 Ign:2 http://security.ubuntu.com/ubuntu jammy-security InRelease
#0 0.372 Ign:3 http://archive.ubuntu.com/ubuntu jammy-updates InRelease
#0 0.372 Ign:4 http://archive.ubuntu.com/ubuntu jammy-backports InRelease
#0 1.374 Ign:2 http://security.ubuntu.com/ubuntu jammy-security InRelease
#0 1.374 Ign:1 http://archive.ubuntu.com/ubuntu jammy InRelease
#0 1.374 Ign:3 http://archive.ubuntu.com/ubuntu jammy-updates InRelease
#0 1.374 Ign:4 http://archive.ubuntu.com/ubuntu jammy-backports InRelease
#0 3.373 Ign:2 http://security.ubuntu.com/ubuntu jammy-security InRelease
#0 3.374 Ign:1 http://archive.ubuntu.com/ubuntu jammy InRelease
#0 3.374 Ign:3 http://archive.ubuntu.com/ubuntu jammy-updates InRelease
#0 3.374 Ign:4 http://archive.ubuntu.com/ubuntu jammy-backports InRelease
#0 7.382 Err:1 http://archive.ubuntu.com/ubuntu jammy InRelease
#0 7.382   Temporary failure resolving 'archive.ubuntu.com'
#0 7.382 Err:3 http://archive.ubuntu.com/ubuntu jammy-updates InRelease
#0 7.382   Temporary failure resolving 'archive.ubuntu.com'
#0 7.382 Err:2 http://security.ubuntu.com/ubuntu jammy-security InRelease
#0 7.382   Temporary failure resolving 'security.ubuntu.com'
#0 7.382 Err:4 http://archive.ubuntu.com/ubuntu jammy-backports InRelease
#0 7.382   Temporary failure resolving 'archive.ubuntu.com'

ok got it working with buildx build instead...(idk why :shrug:)
will share results as soon as it's done.

so that docker run failed:
#0 959.5 In file included from qt/paymentrequestplus.h:10,
#0 959.5                  from qt/walletmodel.h:8,
#0 959.5                  from qt/utilitydialog.h:11,
#0 959.5                  from qt/bitcoin.cpp:22:
#0 959.5 qt/paymentrequest.pb.h:17:2: error: #error This file was generated by an older version of protoc which is
#0 959.5    17 | #error This file was generated by an older version of protoc which is
#0 959.5       |  ^~~~~
#0 959.5 qt/paymentrequest.pb.h:18:2: error: #error incompatible with your Protocol Buffer headers. Please
#0 959.5    18 | #error incompatible with your Protocol Buffer headers.  Please
#0 959.5       |  ^~~~~
#0 959.5 qt/paymentrequest.pb.h:19:2: error: #error regenerate this file with a newer version of protoc.
#0 959.5    19 | #error regenerate this file with a newer version of protoc.
#0 959.5       |  ^~~~~
#0 961.6 In file included from qt/paymentrequestplus.h:10,
#0 961.6                  from qt/walletmodel.h:8,
#0 961.6                  from qt/utilitydialog.h:11,
#0 961.6                  from qt/bitcoin.cpp:22:
#0 961.6 qt/paymentrequest.pb.h: In member function 'void payments::Output::clear_amount()':
#0 961.6 qt/paymentrequest.pb.h:769:13: error: 'GOOGLE_ULONGLONG' was not declared in this scope; did you mean 'GOOGLE_DLOG'?
#0 961.6   769 |   amount_ = GOOGLE_ULONGLONG(0);
#0 961.6       |             ^~~~~~~~~~~~~~~~
#0 961.6       |             GOOGLE_DLOG
#0 961.6 qt/paymentrequest.pb.h: In member function 'void payments::PaymentDetails::clear_time()':
#0 961.6 qt/paymentrequest.pb.h:979:11: error: 'GOOGLE_ULONGLONG' was not declared in this scope; did you mean 'GOOGLE_DLOG'?
#0 961.6   979 |   time_ = GOOGLE_ULONGLONG(0);
#0 961.6       |           ^~~~~~~~~~~~~~~~
#0 961.6       |           GOOGLE_DLOG
#0 961.6 qt/paymentrequest.pb.h: In member function 'void payments::PaymentDetails::clear_expires()':
#0 961.6 qt/paymentrequest.pb.h:1003:14: error: 'GOOGLE_ULONGLONG' was not declared in this scope; did you mean 'GOOGLE_DLOG'?
#0 961.6  1003 |   expires_ = GOOGLE_ULONGLONG(0);
#0 961.6       |              ^~~~~~~~~~~~~~~~
#0 961.6       |              GOOGLE_DLOG
#0 961.7 In file included from qt/bitcoin.cpp:22:
#0 961.7 qt/utilitydialog.h: At global scope:
#0 961.7 qt/utilitydialog.h:72:57: warning: 'constexpr QFlags<T>::QFlags(QFlags<T>::Zero) [with Enum = Qt::WindowType; QFlags<T>::Zero = int QFlags<Qt::WindowType>::Private::*]' is deprecated: Use default constructor instead [-Wdeprecated-declarations]
#0 961.7    72 |     ShutdownWindow(QWidget *parent=0, Qt::WindowFlags f=0);
#0 961.7       |                                                         ^
#0 961.7 In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1299,
#0 961.7                  from /usr/include/x86_64-linux-gnu/qt5/QtGui/qtguiglobal.h:43,
#0 961.7                  from /usr/include/x86_64-linux-gnu/qt5/QtWidgets/qtwidgetsglobal.h:43,
#0 961.7                  from /usr/include/x86_64-linux-gnu/qt5/QtWidgets/qlabel.h:43,
#0 961.7                  from /usr/include/x86_64-linux-gnu/qt5/QtWidgets/QLabel:1,
#0 961.7                  from qt/bitcoingui.h:15,
#0 961.7                  from qt/bitcoin.cpp:10:
#0 961.7 /usr/include/x86_64-linux-gnu/qt5/QtCore/qflags.h:123:80: note: declared here
#0 961.7   123 |     QT_DEPRECATED_X("Use default constructor instead") Q_DECL_CONSTEXPR inline QFlags(Zero) noexcept : i(0) {}
#0 961.7       |                                                                                ^~~~~~
#0 962.8 qt/bitcoin.cpp: In member function 'void BitcoinApplication::createSplashScreen(const NetworkStyle*)':
#0 962.8 qt/bitcoin.cpp:391:60: warning: 'constexpr QFlags<T>::QFlags(QFlags<T>::Zero) [with Enum = Qt::WindowType; QFlags<T>::Zero = int QFlags<Qt::WindowType>::Private::*]' is deprecated: Use default constructor instead [-Wdeprecated-declarations]
#0 962.8   391 |     SplashScreen *splash = new SplashScreen(0, networkStyle);
#0 962.8       |                                                            ^
#0 962.8 In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1299,
#0 962.8                  from /usr/include/x86_64-linux-gnu/qt5/QtGui/qtguiglobal.h:43,
#0 962.8                  from /usr/include/x86_64-linux-gnu/qt5/QtWidgets/qtwidgetsglobal.h:43,
#0 962.8                  from /usr/include/x86_64-linux-gnu/qt5/QtWidgets/qlabel.h:43,
#0 962.8                  from /usr/include/x86_64-linux-gnu/qt5/QtWidgets/QLabel:1,
#0 962.8                  from qt/bitcoingui.h:15,
#0 962.8                  from qt/bitcoin.cpp:10:
#0 962.8 /usr/include/x86_64-linux-gnu/qt5/QtCore/qflags.h:123:80: note: declared here
#0 962.8   123 |     QT_DEPRECATED_X("Use default constructor instead") Q_DECL_CONSTEXPR inline QFlags(Zero) noexcept : i(0) {}

i'd still posit that this is out of scope for this pr.

i got the same error building f4495189400a2859e1d8f0738a582d31137cbcd9 so i don't think this is a regression concerning this pull request and is most likely the default jammy gcc (11.3.0) fwiw. :shrug:

retested f449518 after running make distclean and that passed and then ended up copying Dockerfile to /tmp as awesomedockerfile and running your commands @patricklodder for 1.14.7-focal and that passed.

if anyone wants to audit the contents of build images

The 1.14.7-dev image is copying A LOT of data still on step 11 - unclean depends/? (shouldn't matter for this build tho)

yeh it's unclean depends/ dir. doh! 🤦

if anyone wants to audit the contents of build images

The 1.14.7-dev image is copying A LOT of data still on step 11 - unclean depends/? (shouldn't matter for this build tho)

yeh it's unclean depends/ dir. doh! facepalm

updated image without depends build cache:
https://hub.docker.com/layers/xanimo/dogecoin/f4495189/images/sha256-afedfe0d97d35c6ef8123a5b505f23bb878600006f02ba6f0d2359027c8a4ca0?context=explore

I can reproduce my test error on 1.14.7-dev as well, so it's something specific to my environment and not this PR. I'll debug, but don't let it block further progress here.

new test target link and binaries available to test: https://gist.github.com/xanimo/dec5f0f1a91cbc6638eea482cf8890b8

arm-linux-gnueabihf
ubuntu@arm:~/dogecoin/dogecoin-1.14.7/bin$ time ./test_dogecoin
Running 253 test cases...

*** No errors detected

real    14m19.197s
user    10m31.040s
sys     3m31.264s
ubuntu@arm:~/dogecoin/dogecoin-1.14.7/bin$ lscpu
Architecture:          armv7l
Byte Order:            Little Endian
CPU(s):                1
On-line CPU(s) list:   0
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             1
Model name:            ARMv7 Processor rev 2 (v7l)
CPU max MHz:           1000.0000
CPU min MHz:           300.0000
ubuntu@arm:~/dogecoin/dogecoin-1.14.7/bin$

Re-verified https://github.com/dogecoin/dogecoin/issues/3276 on Windows XP with win32 binary.

:facepalm:
I fixed my error; my .dogecoin directory was not mounted properly. All tests pass for me on 64-bit x86 Linux (Ubuntu 22.04). I'll work on gitian over the weekend.

My results match @xanimo 's:
e28b7be2d835ed09e1bd11105a0df8591972918a31d141cb83d601aece96fc36  dogecoin-1.14.7-osx-unsigned.dmg
1016154956c80663f813fa279ee56796e8d9de3a9439d72aeae24c19b6c48fe4  dogecoin-1.14.7-osx-unsigned.tar.gz
adf08a3926939dd01802a7adacdf47c987b67c8b5a42ba4aa371150587554d46  dogecoin-1.14.7-osx64.tar.gz

79a7f345a5f6d4b2ebfed8b1247eb7d63300287a9fb1746d00557f85069b2232  dogecoin-1.14.7-win-unsigned.tar.gz
a64791c085a9a8e3e6f832e699fadd4a97139e4ee2510c2da54cc0d33edc1ca0  dogecoin-1.14.7-win32-debug.zip
69dc364611ee001623454bae81d9c9d2e55daacfba17c1f12ceebe18eb79e727  dogecoin-1.14.7-win32-setup-unsigned.exe
e0ebed4132e190d264f1b8d2952b39d63eadefa44763f25e14eaf22edf712985  dogecoin-1.14.7-win32.zip
65ceaf2df96c6bf4a2aa00e3daab3a0bb40d2671d9af1f8508fe53420cb058df  dogecoin-1.14.7-win64-debug.zip
2cdcfc497b327cf340b88528a09ac784b2961dff6c6ba7b360ee3cc4cba08e12  dogecoin-1.14.7-win64-setup-unsigned.exe
30b9604b0503703d9779cd295f3564cd8eb4b5508ad898c749717dc6c1422908  dogecoin-1.14.7-win64.zip

f22f79fe7e1ece3ee268e1999212b761f94194c155764a260e5a5794e521ef57  dogecoin-1.14.7-aarch64-linux-gnu-debug.tar.gz
05d3ae1662e15c8ffcfeb0ce6da3e10734ee5d91497ca08f2a84e11b7cfb457e  dogecoin-1.14.7-aarch64-linux-gnu.tar.gz
1d5b34a4e40ea28a6a7bd39a925599650c16a32038a31b9b245e5f38563588de  dogecoin-1.14.7-i686-pc-linux-gnu-debug.tar.gz
b03423ba9c70168b29452781c5e838b7c1152b78d04a4bc9a222f70f0b438635  dogecoin-1.14.7-arm-linux-gnueabihf-debug.tar.gz
eb4bb79bd3b0cd9f36050e74b995975910c4b5c1613b06a7f642c97d19424d02  dogecoin-1.14.7-arm-linux-gnueabihf.tar.gz
95ba2b5c3b427e4de902897184df800084346b5d633119888ff4a64738a77852  dogecoin-1.14.7-i686-pc-linux-gnu.tar.gz
be46009a2c1e29e8fbd2076dd188b82a5581f6a2a6a53d5fd5320f6106f27a76  dogecoin-1.14.7-x86_64-linux-gnu-debug.tar.gz
a56b84bfe3fbca99b8017b1dacea14fb0923d44a062b71cdaedf274e26357e51  dogecoin-1.14.7-x86_64-linux-gnu.tar.gz

6f7190189f109765e29f49557b57a105881d38c6b51493b6964a858be76e8a52  src/dogecoin-1.14.7.tar.gz

61592c4cc346f46573a75e16f646f210c89d1c9fff498dc2685d39ab1e4da3c8  dogecoin-win-1.14-res.yml
4da0927ea5e8ba722237eaa8e0e2c842c37438bc626bdff6b7f956fe17554173  dogecoin-osx-1.14-res.yml
a2cfc7289e2df8ef80204e8e5cfe1564f32d215d34c714c5413414815468bd92  dogecoin-linux-1.14-res.yml

ACK, all tests pass on 64-bit x86 Linux and Gitian signatures match, so we are finally good to go on this with the 24 hour countdown.
Thanks to everyone who worked on this in part or in the whole. This unblocks a lot of other development for 1.14.7.

would also like to give thanks to all who helped on this <3<3

And just to be complete, all match:
`e28b7be2d835ed09e1bd11105a0df8591972918a31d141cb83d601aece96fc36  dogecoin-1.14.7-osx-unsigned.dmg
1016154956c80663f813fa279ee56796e8d9de3a9439d72aeae24c19b6c48fe4  dogecoin-1.14.7-osx-unsigned.tar.gz
adf08a3926939dd01802a7adacdf47c987b67c8b5a42ba4aa371150587554d46  dogecoin-1.14.7-osx64.tar.gz
79a7f345a5f6d4b2ebfed8b1247eb7d63300287a9fb1746d00557f85069b2232  dogecoin-1.14.7-win-unsigned.tar.gz
a64791c085a9a8e3e6f832e699fadd4a97139e4ee2510c2da54cc0d33edc1ca0  dogecoin-1.14.7-win32-debug.zip
69dc364611ee001623454bae81d9c9d2e55daacfba17c1f12ceebe18eb79e727  dogecoin-1.14.7-win32-setup-unsigned.exe
e0ebed4132e190d264f1b8d2952b39d63eadefa44763f25e14eaf22edf712985  dogecoin-1.14.7-win32.zip
65ceaf2df96c6bf4a2aa00e3daab3a0bb40d2671d9af1f8508fe53420cb058df  dogecoin-1.14.7-win64-debug.zip
2cdcfc497b327cf340b88528a09ac784b2961dff6c6ba7b360ee3cc4cba08e12  dogecoin-1.14.7-win64-setup-unsigned.exe
30b9604b0503703d9779cd295f3564cd8eb4b5508ad898c749717dc6c1422908  dogecoin-1.14.7-win64.zip
f22f79fe7e1ece3ee268e1999212b761f94194c155764a260e5a5794e521ef57  dogecoin-1.14.7-aarch64-linux-gnu-debug.tar.gz
05d3ae1662e15c8ffcfeb0ce6da3e10734ee5d91497ca08f2a84e11b7cfb457e  dogecoin-1.14.7-aarch64-linux-gnu.tar.gz
b03423ba9c70168b29452781c5e838b7c1152b78d04a4bc9a222f70f0b438635  dogecoin-1.14.7-arm-linux-gnueabihf-debug.tar.gz
eb4bb79bd3b0cd9f36050e74b995975910c4b5c1613b06a7f642c97d19424d02  dogecoin-1.14.7-arm-linux-gnueabihf.tar.gz
1d5b34a4e40ea28a6a7bd39a925599650c16a32038a31b9b245e5f38563588de  dogecoin-1.14.7-i686-pc-linux-gnu-debug.tar.gz
95ba2b5c3b427e4de902897184df800084346b5d633119888ff4a64738a77852  dogecoin-1.14.7-i686-pc-linux-gnu.tar.gz
be46009a2c1e29e8fbd2076dd188b82a5581f6a2a6a53d5fd5320f6106f27a76  dogecoin-1.14.7-x86_64-linux-gnu-debug.tar.gz
a56b84bfe3fbca99b8017b1dacea14fb0923d44a062b71cdaedf274e26357e51  dogecoin-1.14.7-x86_64-linux-gnu.tar.gz
6f7190189f109765e29f49557b57a105881d38c6b51493b6964a858be76e8a52  src/dogecoin-1.14.7.tar.gz
`


Not able to clone ABAPGitServer

I am not able to clone abapgitserver in SAP.
It gives me the following error:
Cannot make changes to ZAGS_BRANCH_NAME
Can you please tell me what is causing this error?

Are you installing abapGitServer? Or trying to clone a repository hosted on abapGitServer?
Can you add a screenshot of the actual error?

is your user registered as a developer on the SAP system, plus do you have authorization to create database tables in SE11?

User is a developer, but not sure if it has authorization to create database in SE11, Is there a way to find it wou, sorry, i am asking you these questions as I am new to SAP.

And also can tcodes be saved in this ABAPGitserver?

Try: Goto SE11 and try creating it
new to SAP: SAP has versioning built in, so a git server is not required for doing ABAP development, I guess very few people use ABAP along with Git
tcodes: abapGitServer is a generic git server it can store anything, it is up to the client to send the files to the server, and abapGit supports transactions, http://larshp.github.io/abapGit/ref-supported.html

Thank you so much for the information.
Can you tell me how to run the transaction given in this link http://larshp.github.io/abapGit/ref-supported.html

@Rachanasuresh1994 suggest asking your local senior ABAP developer. Please spend some time learning ABAP, then come back here in 5 years if you still need a git server/client


Google Ad Error

I got to the end of step 4, and am seeing this:
Error Error Domain=com.google.GIDSignIn Code=-4 "(null)"
2019-03-18 22:15:52.750922-0700 FriendlyChatSwift[51767:742091] *** Terminating app due to uncaught exception 'GADInvalidInitializationException', reason: 'The Google Mobile Ads SDK was initialized incorrectly. Google AdMob publishers should follow instructions here: https://googlemobileadssdk.page.link/admob-ios-update-plist to include the AppMeasurement framework, set the -ObjC linker flag, and set GADApplicationIdentifier with a valid App ID. Google Ad Manager publishers should follow instructions here: https://googlemobileadssdk.page.link/ad-manager-ios-update-plist'

That's a bug in our codelab. In the meantime, you can work around it by adding the key-value pair in the documentation linked above to your Info.plist file.
<key>GADIsAdManagerApp</key>
<true/>

@ulukaya see b/128700718

Thanks @morganchen12

https://github.com/firebase/friendlychat-ios/commit/c8bbd3b6f4bf27f22a1cfc002e76c2e64a1fd6ef

Thanks @morganchen12


Using jwt-decode beta with node10 module resolution

Checklist

[X] I have looked into the Readme and have not found a suitable solution or answer.
[X] I have searched the issues and have not found a suitable solution or answer.
[X] I have searched the Auth0 Community forums and have not found a suitable solution or answer.
[X] I agree to the terms within the Auth0 Code of Conduct.

Description
When we use jwt-decode's beta in a project that uses node10 for the module strategy, it allowas for the following imports:
import { jwtDecode } from 'jwt-decode';
import { jwtDecode as jwtDecode2 } from 'jwt-decode/build/cjs/index';
import { jwtDecode as jwtDecode3 } from 'jwt-decode/build/esm/index';

Even though this could be considered normal, I wonder if we can improve this for the situation where node10 is used as a module resolution strategy.
Reproduction

mkdir typescript-project
cd typescript-project
npm i typescript
npx tsc --init
touch index.ts

Update index.ts to add
import { jwtDecode } from 'jwt-decode';
import { jwtDecode as jwtDecode2 } from 'jwt-decode/build/cjs/index';
import { jwtDecode as jwtDecode3 } from 'jwt-decode/build/esm/index';

You will see it allows for these imports, unless you set moduleResolution to node16.
Additional context
No response
jwt-decode version
latest beta
Which browsers have you tested in?
Chrome

@jonkoops, just cc'ing you FYI as you were heavily involved in setting this up. I wonder if we can avoid this by not having individual types for both ESM and CJS, as they are identical anyway.
That would ensure we can only do
import { jwtDecode } from 'jwt-decode';
import { jwtDecode as jwtDecode2 } from 'jwt-decode/build/types/index';

which might make more sense.
Will have a look.

According to https://github.com/arethetypeswrong/arethetypeswrong.github.io/blob/main/docs/problems/FalseESM.md, we should not have a single type declarations file. We have been here before and we went with two different type declarations files for the exact same reason.
I assume there isn't much we can do about this but leave it as is.

Since we don't support any version of Node.js before 18 I don't think this will be an issue. Even though the user could set the node10 module resolution strategy, that code will not run properly in Node.js 16 and up.
The reason for this is that starting with Node.js 16 (AFAIK), it will respect the "exports" field in the package file, which will prevent this kind of access. As per the Node.js documentation:

The "exports" provides a modern alternative to "main" allowing multiple entry points to be defined, conditional entry resolution support between environments, and preventing any other entry points besides those defined in "exports".

So from what I can tell the node10 preset only exists to provide compatibility with historical versions of Node.js that might have these sort of 'illegal' imports going on. Which is fine, as long as they run on older versions that do not respect the "exports" field.

I wonder if we can avoid this by not having individual types for both ESM and CJS, as they are identical anyway.

Like you mentioned, this will then break the node16 resolution strategy, as it needs to have distinct types. I think we should keep them to keep things compatible going forward.
@frederikprijck somewhat related to this, perhaps we should make a clean break and simply roll with the "exports" field only? So essentially remove the "main", "module" and "types" fields. They might still be used, but it could also be the case that most have a modern enough bundler to make things work.
I feel more comfortable shipping without them, rather than pushing them, knowing they might be incorrect. Also adding them back in a quick patch release if we do get issue reports is rather trivial.

Since we don't support any version of Node.js before 18 I don't think this will be an issue. Even though the user could set the node10 module resolution strategy, that code will not run properly in Node.js 16 and up.

Based on my tests, if you run tsc --init, it omits moduleResolution and defaults to 10.

Yeah having tested this in a project that gets created using tsc --init, we get the following error when we omit main, module and types properties in the package.json

So as long as node16 isnt the default, I think we should keep it.

We shipped node-auth0 with the same config and havent had any issues yet.

If this is battle tested then I feel a little more comfortable shipping like this, it's mostly there to guarantee backwards compatibility. This might be something to re-consider in the future when the platform as a whole has moved on, but if it helps prevent real issues for users let's keep it this way.
To answer your original question, I kind of have to agree that there is no real way of providing a better experience for users of node10. These kind of imports are entirely valid in those versions of Node.js, although the TypeScript compiler perhaps should do a better job at warning users of this potential pitfall.
Should we close this issue then? Considering there is very little we can do.

@frederikprijck I found a relevant issue on the TypeScript project that might be relevant for this discussion:  https://github.com/microsoft/TypeScript/issues/55104

Thanks for sharing.
Not sure it's related, as it does work in node10, it just allows for all kinds of imports and IDE's get confused.
That said, happy to close this yes, thanks for the input!


chore: updates near-* dependencies to 0.27 release

@race-of-sloths

@akorchyn Thank you for your contribution! Your pull request is now a part of the Race of Sloths!

Current status: waiting for scoring
We're waiting for maintainer to score this pull request with @race-of-sloths score [0,1,2,3,5,8,13] command. Alternatively, autoscoring [1,2] will be applied for this pull request
What is the Race of Sloths

Race of Sloths is a friendly competition where you can participate in challenges and compete with other open-source contributors within your normal workflow
For contributors:

Tag @race-of-sloths inside your pull requests
Wait for the maintainer to review and score your pull request
Check out your position in the Leaderboard
Keep weekly and monthly streaks to reach higher positions
Boast your contributions with a dynamic picture of your Profile

For maintainers:

Score pull requests that participate in the Race of Sloths and receive a reward
Engage contributors with fair scoring and fast responses so they keep their streaks
Promote the Race to the point where the Race starts promoting you
Grow the community of your contributors

Feel free to check our website for additional details!

Bot commands

For contributors

Include a PR: @race-of-sloths include to enter the Race with your PR

For maintainers:

Invite contributor @race-of-sloths invite to invite the contributor to participate in a race or include it, if it's already a runner.
Assign points: @race-of-sloths score [1/2/3/5/8/13] to award points based on your assessment.
Reject this PR: @race-of-sloths exclude to send this PR back to the drawing board.
Exclude repo: @race-of-sloths pause to stop bot activity in this repo until @race-of-sloths unpause command is called

this looks like a spot where a self-referential struct is moved https://github.com/near/near-sdk-rs/blob/master/near-sdk/src/environment/env.rs?plain=1#L102

checked that this doesn't block #1253 in any way with #1255

@race-of-sloths score 5

This looks like a spot where a self-referential struct is moved https://github.com/near/near-sdk-rs/blob/master/near-sdk/src/environment/env.rs?plain=1#L102

I am not sure that I understand what you imply by that :(

@akorchyn looks like some glitch, as first commit probably didn't have workflows update. I'll try rerunning Test core job, but you must have perm to rerun too.

It's not a glitch actually. You specify required job names in repo settings. But as rust toolchain is part of the name, that's why it doesn't match. I don't have enough rights
@frol can you update job config

@akorchyn cancel the running jobs, then try closing/reopening the pr.
In #1253 the first pushed commit changed the workflows and they were picked up correctly, not requiring stuff from pr's base branch

Or maybe even closing, adding some whitespace change (so that's its a new commit, unknown to gh), and opening a new pr from another branch. I don't know, why gh wants to make everything so painful, but this pr https://github.com/near/near-sdk-rs/pull/1231/files seemingly had a similar change and i don't remember anyone having to edit repo config to merge it.

I tried squash and open new PR here: https://github.com/near/near-sdk-rs/pull/1258
Seems to be like it doesn't work that way :(


Default CORSIKA simulation config class

This PR introduces a class with default CORSIKA simulation config. It is far from complete, missing many parameters still. Also, it is not actually used yet in the code. However, I would like to get first feedback before I move forward with this implementation.
For the record, including it in the code should be fairly simple and harmless, by adding one line to the snippet below to complement any dictionary from the user with the default dictionary returned by this new class.
https://github.com/gammasim/simtools/blob/7cfbe595c005bbdaa2f39ffb1b23e2698d83b250/simtools/simulator.py#L192-L205

@orelgueta - maybe you can explain again the motivation of not using configuration files. These are values you don't expect to change ever? And all of them will still be configurable, these are 'just' defaults?

@orelgueta - maybe you can explain again the motivation of not using configuration files. These are values you don't expect to change ever? And all of them will still be configurable, these are 'just' defaults?

Yes, these are just defaults, but they are expected to be used often. Putting it in a configuration file would probably lead to very cumbersome and long files. It is easier and shorter to do it in dictionaries and code. We can revisit this point once this class is complete though. Maybe I am wrong and we could switch to files later.

Oh and I think I answered everything. Maybe take a second look and we resolve the question about the particle names before we merge?

All good, please merge!


position: 'topcenter' from the example doesn't work

It seems that in the current version when calling new L.Control.GeoSearch the argument position: 'topcenter' doesn't seem to work (javascript error). This is unfortunate because I think the topcenter position (which I saw working in an earlier version) was the nicest positioning option.

I would also like to be able to use the topcenter position. Also, is there an option that makes the search bar always visible, instead of on hover?

Any update on this issue?

The topcenter is indeed an old option. I think the old style should come back and make the option configurable.
This plugin needs some refactoring. But at the moment I'm a little short in time.

Thanks for the update. I guess I liked the way it visually showed before, but I'm seeing more and more examples with other apps/web sites where you need to click something like a search button to have the search area appear. It's just new/different.  The one potential issue is that we tend to put several buttons on the left-hand side, to match leaflet's default positioning, but we can end up running out of space on small screens. Thanks again for your quick reply!!

Fixed this in the next branch. Release v2.0.0 be released before the end of this year. Currently usable trough:
npm install leaflet-geosearch@next --save


(sync) Prevent document content being lost in case of disconnects

Quoted from discord @Frando:
So I'm thinking about downlaod improvements etc. So far we came up with two short-term ideas, implemented in #1480

Include the content status (available/missing) for entries sent to a peer during set reconciliation
When finishing a content download for a document entry, notifiy immediate swarm neighbors about this (through a new scoped-to-neighbors gossip mode)
With this we'll inform the downloader about these Provider peers for a hash, and start a download immediately. All good and much faster content resolving without delays than what we do atm.

However! Take this scenario:

Alice publishes a new entry in a doc. Entry is broadcast to all joined peers.
Alice goes offline immediately after publishing, and before any peer has downloaded the content.
Now Bob and Claire have Alices's entry, but not the blob. All as expected.
Now Alice comes online again the next day. But! Neither Bob nor Claire would try to download the missing content from Alice, because there would be no news from her (no new entry published, so no gossip message, and no updates in set reconciliation because sets are already synced).

I think we really need to solve this, at least somehow. Otherwise we will easily have bug reports about "lost content" that never gets synced.
Ideas?

Closing as stale


Mistake in docs

Hi,
under this section "Rendering and Layout Management" you write:
FlowLayour.render
but when you install the Flow Layout package, it's actually
BlazeLayout.render

Thanks. I'm in the middle of the Release.
Will change now.

Will update this soon.


Mocking framework

Hi,
hope find you well with this cold call.
I am an author of mocking framework for Kotlin
I see you are using mockito-kotlin.
I just want you to be aware that there is solution that fully supports Kotlin and ask to try it in your new/current projects.
I can help you if you answer to this issue.
Thanks and please star it

Thanks @olekiyp , already stared, it's cool, will try it.


tooltip on md-tab not working

Bug, feature request, or proposal:
bug
What is the expected behavior?
tooltips should be shown on md-tabs
What is the current behavior?
tooltips are not shown
What are the steps to reproduce?
see plunkr: http://plnkr.co/edit/ij8DMEKht4QTvQt1ANLN?p=preview

tab 2 and tab 3 have both tooltips which are not shown
general tooltips work (see on the bottom of the plunkr a working tooltip)

What is the use-case or motivation for changing an existing behavior?
Providing information about tabs would be nice, especially when tabs are set as disabled, a reason why it is disabled should be somehow shown to the customer.
There is already a discussion about that on angularjs and old material, so we don't have to discuss the reasons again: https://github.com/angular/material/issues/1667
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
material 1.0.0 beta 10
Is there anything else we should know?
if it is intended, what would be a good way to make the user know that this tab is disabled because of reasons (except doing nasty stuff like <md-tab label="tab2 (not enabled feature)">...</md-tab>

Actually you can add tooltips to tab headers if you use the alternate tab label syntax involving ng-template: demo.
However they don't work if the tab is disabled.

Marking as resolved are you should use the ng-template method as referenced above.

@benelliott thanks for the plunkr and the workaround. As you mentioned there is still the problem with not working for disabled (which is actually my use case, where i want to tell the customer WHY it is disabled)
@josephperrott this issue is not resolved, please reopen.

@emreavsar it would be due to this,
https://github.com/angular/material2/blob/3571f68a2de0833ee4741af8a0eb24d1da174f38/src/lib/tabs/_tabs-common.scss#L25-L28
IMO, it seems strange to me that the "disabled" functionality of the tabs hinges on pointer-events: none. You cannot override that CSS, because the tabs start working again, despite looking disabled.
I think the template logic surrounding matRippleDisabled  and (click) should check for whether the tab is disabled
https://github.com/angular/material2/blob/3571f68a2de0833ee4741af8a0eb24d1da174f38/src/lib/tabs/tab-group.html#L6-L24
@josephperrott will you reconsider reopening this for the purpose of moving the disabled logic out of the CSS and into the MatTabGroup class?

Reopened, it definitely merits a look.

Correct me if I'm wrong but #7364 has not yet fixed this issue.
See the updated plunkr here: http://plnkr.co/edit/n4TksZD9NkM0UPHwJtZA
same behaviour.

@emreavsar you still need to take into account @benelliott's suggestion. The fix in #7364 was just to allow the tooltip to work on disabled tabs.
http://plnkr.co/edit/AnswASZc5SpvFKwcrCMu?p=preview

i see and i gave you my ❤


Allow CDF scans with schema evolution

Please describe why this is necessary.
TableChanges today asserts that the schema for the entire range be the same. This condition can be relaxed to allow new nullable columns to be added to the start schema, or toggling the nullability for an existing field to true.
Describe the functionality you are proposing.
Schema enforcement at TableChanges construction and during log replay must accept data with a schema that is missing a nullable field and must fill that nullable field in when producing rows.
Additional context
No response

We should also ignore changes in schema metadata -- at least, the user-provided ones that Delta spec doesn't have any opinion about. I'm less clear whether we should tolerate changes in column mapping table properties?


1.1.3 - Could not get devices in getAllRingsDevices()

ring.0	2021-01-15 23:52:38.022	error	(8184) Error: Error setHistory(): Error: Could noch get Hisotry for xxxxxxxx in getHistory(id).Error: Could not get Doorbell for xxxxxxxx in getAllRingsDeviceObject(id). Error: Could not get all doorb
ring.0	2021-01-15 23:52:38.021	error	(8184) Error: Error setHealth(): Error: Could not get Health for xxxxxxxx in getHealthSummarie(id). Error: Could not get Doorbell for xxxxxxxx in getAllRingsDeviceObject(id). Error: Could not get all
ring.0	2021-01-15 23:52:38.021	error	(8184) Error: Error setInfo(): Error: Could not get Doorbell for xxxxxxxx in etAllRingsDevice(id). Error: Could not get devices in getAllRingsDevices(). Error: Could not get all doorbell devices in ge
ring.0	2021-01-15 23:52:38.020	info	(8184) Starting Ring Device for Id xxxxxxxx
ring.0	2021-01-15 23:52:21.827	error	(8184) Error: Could not get devices in getAllRingsDevices(). Error: Could not get all doorbell devices in getAllRingsDeviceObjects(). Error: Could not get ring instance in method getRing(). TypeError:
ring.0	2021-01-15 23:51:21.827	error	--- property '_parentOrParents' closes the circle
ring.0	2021-01-15 23:51:21.827	error	| index 0 -> object with constructor 'SwitchMapSubscriber'
ring.0	2021-01-15 23:51:21.827	error	| property '_subscriptions' -> object with constructor 'Array'
ring.0	2021-01-15 23:51:21.827	error	--> starting at object with constructor 'Subscriber'
ring.0	2021-01-15 23:51:21.827	error	(8184) Error: Error setHistory(): Error: Could noch get Hisotry for xxxxxxxx in getHistory(id).Error: Could not get Doorbell for xxxxxxxx in getAllRingsDeviceObject(id). Error: Could not get all door
ring.0	2021-01-15 23:51:21.827	error	--- property '_parentOrParents' closes the circle
ring.0	2021-01-15 23:51:21.827	error	| index 0 -> object with constructor 'SwitchMapSubscriber'
ring.0	2021-01-15 23:51:21.827	error	| property '_subscriptions' -> object with constructor 'Array'
ring.0	2021-01-15 23:51:21.827	error	--> starting at object with constructor 'Subscriber'
ring.0	2021-01-15 23:51:21.827	error	(8184) Error: Error setHealth(): Error: Could not get Health for xxxxxxxx in getHealthSummarie(id). Error: Could not get Doorbell for xxxxxxxx in getAllRingsDeviceObject(id). Error: Could not get all
ring.0	2021-01-15 23:51:21.827	error	--- property '_parentOrParents' closes the circle
ring.0	2021-01-15 23:51:21.827	error	| index 0 -> object with constructor 'SwitchMapSubscriber'
ring.0	2021-01-15 23:51:21.827	error	| property '_subscriptions' -> object with constructor 'Array'
ring.0	2021-01-15 23:51:21.827	error	--> starting at object with constructor 'Subscriber'
ring.0	2021-01-15 23:51:21.827	error	(8184) Error: Error setInfo(): Error: Could not get Doorbell for xxxxxxxx in etAllRingsDevice(id). Error: Could not get devices in getAllRingsDevices(). Error: Could not get all doorbell devices in g
ring.0	2021-01-15 23:51:21.826	info	(8184) Starting Ring Device for Id xxxxxxxx
Ring:    1.1.3
Admin:  4.1.11
Node.js  v12.20.1
NPM     6.14.11

Update 1.1.5
A new token is needed
In my case it was necessary to delete the instance and create it again.
After that it worked

Update 1.1.5
A new token is needed
In my case it was necessary to delete the instance and create it again.
After that it worked


Add Http module in common directory

Adding new Http module to reduce the amount of code needed when making Roblox endpoint calls in CoreScripts. The module wraps all http API calls in pcalls, which is where most of the code redundancy comes from. Each call will decode the json into a lua table, and I have added an optional returnRaw parameter if you need the raw json.
This has been updated and added to the new Common directory. This will not conflict with the Xbox app http module (we may want to reorganize that project to reduce future conflicts). Module has been added to Common as it has use on both the server and the client.
After this is approved, we can start migrating existing calls to use this module.

Will leave open for review and feedback, but will need to update directory path when @spotco makes his changes to allow modules to be loaded on the server, as we'll want this on both the client and server.

Request has been updated to reflect new module directories.

Looks good to me


Sphinx

This looks like fantastic Python code, I've never seen better!
Would it be possible to show the documentation in the Sphinx format? This would be even more awesome! I can't recommend it more!

Please forward this @eccles

Hey @MichelHollands , thanks for the compliment 😄
We have API documentation for the platform in Sphinx that can be found here:
https://jitsuin-archivist.readthedocs.io/en/latest/index.html
And the source can be found here:
https://github.com/jitsuin-inc/archivist-docs
We are also working on many improvements to these at the moment including instructions for the SDK so watch this space and any suggestions welcome!
Let me know if this answers your issue or if we can help with anything more specific 🙂

fixed


Nested dialog changes DialogOptions of its parent

Things to check

[X] I have searched the existing issues for this bug
[X] To rule out a caching problem I made sure the bug also happens in an incognito tab

Bug type
Component
Component name
MudDialog
What happened?
I am opening 2 dialogs, each with dfferent options which I set in dialog components. 2nd dialog is nested inside the 1st one
1st dialog options look like this
MudDialog.SetOptions(new DialogOptions() { FullScreen = true, CloseButton = true, FullWidth = true });
2nd dialog options
MudDialog.SetOptions(new DialogOptions(){ MaxWidth = MaxWidth.Medium});
After the 2nd dialog is opened, all of its parent dialog options are set to the options of the 2nd dialog or forgotten.
The options do not have to be set in dialog component to replicate this bug.
Expected behavior
Each dialog should have seperate options which do not influence its parent dialog.
Reproduction link
https://try.mudblazor.com/snippet/wumSvYRlTRTgpbjz
Reproduction steps
1.Click on button Dialog 1
2.Fullscreen dialog opens
3.Click on button Dialog 2
4.New dialog opens with different options and Dialog 1 changes or forgets its original options
Relevant log output
No response
Version (bug)
7.15.0
Version (working)
6.19.1
What browsers are you seeing the problem on?
Chrome
On which operating systems are you experiencing the issue?
Windows
Pull Request

[ ] I would like to do a Pull Request

Code of Conduct

[X] I agree to follow this project's Code of Conduct

When I passed the DialogOptions of Dialog 1 to ShowAsync method the bug does not happen. It seems to occur only when options are set using SetOptions().
So I changed it from
MudDialog.SetOptions(new DialogOptions() { FullScreen = true, CloseButton = true, FullWidth = true });
to
var options = new DialogOptions() { FullScreen = true, CloseButton = true, FullWidth = true };

var dialog = await dialogService.ShowAsync<Dialog1>("", options);

and now works as expected


Double events when registering in parent boot

When registering an event in a parent's boot method. It is triggered twice if the parent was booted first in the same process.
For instance, with a Page model that has a Product child and a created event registered in Page::boot():
Product::create() // triggers the created event once as expected

(another process)
Page::create() // triggers the created event once as expected
Product::create() // triggers the created event twice (not expected)

I believe this was introduced in #26.

@kbond Do you have an observer on the Page model and the Product model? Because then in your second example the expected behavior is that it calls an observer method three times, two times in the parent observer and one in the child, per https://github.com/tightenco/parental/blob/master/tests/Features/ParentsObserveChildrenTest.php#L15

No observers at all. Just static::created(function () {}) in Page::boot()

@kbond I think I misunderstood. When you say // triggers the created event twice (not expected) do you mean it triggers it a second time or it triggers twice after the first one triggered? Reading back over your comment I'm thinking you meant the former. If that's the case, then that's the expected behavior. Parent models will observe child events (but not the other way around)

I added PR with a failing test (#40) to better demonstrate the problem.

Should be fixed in the aforementioned PR


Issue with training baseline model

Hi,
I followed all the preprocessing steps and installed the required packages.
However, I am facing an error in training a baseline model with this code.
I am using exactly the same command as here. I believe it has something to do with the use of extra_train_data. Would be helpful if you had any suggestion for how to resolve this.
Grad overflow on iteration 0
Using dynamic loss scale of 65536
Traceback (most recent call last):
  File "train.py", line 579, in <module>
    sys.exit(main(sys.argv[1:]))
  File "train.py", line 574, in main
    train(opt, shared, m, optim, train_data, val_data, extra_train, extra_val, unlabeled)
  File "train.py", line 410, in train
    train_perf, extra_train_perf, loss, num_ex = train_epoch(opt, shared, m, optim, train_data, i, train_idx, extra, extra_idx, unlabeled, unlabeled_idx)
  File "train.py", line 216, in train_epoch
    batch_ex_idx, batch_l, source_l, target_l, label, res_map) = data[batch_order[i]]
  File "/net/nfs.corp/alexandria/chaitanyam/consistency/data.py", line 264, in __getitem__
    batch_l, source_l, target_l, label) = self.batches[idx]
IndexError: list index out of range

Thanks for your help!

Hi just wondering if you found a solution for that?

Hey, sorry for the late response. The issues panel is not actively monitored. For any further question, please email me directly.
It seems the issue was due to a later commit that was supposed to fix a similar issue. I have just reverted the change and did a quick run from scratch. It should be good now.