[bug] "runner": "cross" in tauri.conf.json did not work when packaging linux AppImage.

Describe the bug
I tried to write a github ci/cd action for a tauri app. And I use "runner": "cross" in tauri.conf.json. The binary compilation is ok in the docker container, but I find the linux AppImage packaging is not running in the docker container but in the host, so it always failed with ERROR: Could not find dependency, see https://github.com/linuxdeploy/linuxdeploy/issues/203 for more details.

Reproduction

create a demo tauri app via yarn create tauri-app
install cross via cargo install cross
config "runner": "cross" in tauri.conf.json
add Cross.toml in src-tauri as the following contents.[target.i686-unknown-linux-gnu]
image = "liudonghua123/cross:i686-unknown-linux-gnu-tauri"
[target.x86_64-unknown-linux-gnu]
image = "liudonghua123/cross:x86_64-unknown-linux-gnu-tauri"

execute yarn tauri build -t x86_64-unknown-linux-gnu -v and yarn tauri build -t i686-unknown-linux-gnu -v

Expected behavior
Both the compilation and packaging are executed in the docker container, not the host environment.
Platform and versions
liudonghua@DESKTOP-DELL:/mnt/d/code/rust/hoppscotch-app$ npm run tauri info

> tauri
> tauri "info"

Environment
  › OS: Ubuntu 22.04 X64
  › Node.js: 18.2.0
  › npm: 8.9.0
  › pnpm: 7.1.7
  › yarn: 1.22.18
  › rustup: 1.24.3
  › rustc: 1.61.0
  › cargo: 1.61.0
  › Rust toolchain: stable-x86_64-unknown-linux-gnu

Packages
  › @tauri-apps/cli [NPM]: 1.0.0-rc.13
  › @tauri-apps/api [NPM]: 1.0.0-rc.6
  › tauri [RUST]: 1.0.0-rc.14,
  › tauri-build [RUST]: 1.0.0-rc.12,
  › tao [RUST]: 0.9.1,
  › wry [RUST]: 0.17.0,

App
  › build-type: bundle
  › CSP: default-src blob: data: filesystem: ws: wss: http: https: tauri: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'
  › distDir: dist
  › devPath: dist

App directory structure
  ├─ .git
  ├─ .github
  ├─ dist
  ├─ hoppscotch
  ├─ node_modules
  └─ src-tauri
npm notice
npm notice New minor version of npm available! 8.9.0 -> 8.12.0
npm notice Changelog: https://github.com/npm/cli/releases/tag/v8.12.0
npm notice Run npm install -g<EMAIL_ADDRESS>to update!
npm notice
liudonghua@DESKTOP-DELL:/mnt/d/code/rust/hoppscotch-app$

Stack trace
No response
Additional context
No response

"runner": "cross" just configures our CLI to use cross instead of cargo to compile the Rust code and generate the executable. The bundling phase is still executed in the host machine. You'll need to setup a docker and run our CLI there if you want to run the entire process in the container.

@lucasfernog Hi, how can I separate the packaging phase from tauri build?


The most obvious solution would be to rename it to Color.  Downside is that it implies Color to be an object, when it's actually a namespace.  I would consider having Color be an actual object with components and such, but I'm not to fond of wrapping core Allegro objects (ALLEGRO_COLOR, in this case) because that implies that the core structs should be replaced with class objects, which I don't think is true.

Theoretically, this dilemma resolved.
We're going to go with Color as a class.  The color constants (pink, lightcyan, etc.) will be renamed to camel case and added to the Color class as static constants.
This PR was merged to start the process.  For the remaining constants that need to be moved, I've opened a new issue for that here.


Add config to allow annotations and block default values

Add config for deny_default_annotation_blocker.
If allow_snippet_annotations & deny_default_annotation_blocker are true, use default block values.
Fixes #580

Pushed up some changes based on the feedback above, please check once more :)

Just a quick question. Is there a case where we will be using all four different combinations of allow_snippet_annotations and deny_default_annotation_blocker. It seems like we are adding conditions which are not needed and just increases complexity.

@phillebaba
We only want annotation-value-word-blocklist to apply when both are true, in other words, we want to be able to use allow_snippet_annotations without the blocklist. And if allow_snippet_annotations is false, then we won't need annotation-value-word-blocklist.
We could make it so that annotation-value-word-blocklist applies when only deny_default_annotation_blocker is true, but then it could be applied without allow_snippet_annotations. Which would be unnecessary?
Short answer; Yes, we want this possibility.
Hope this explains some more

We have decided to be more opinionated. Instead of creating a new variable we will just fix the current if statment to actually use the block list when allow_snippet_annotations is true.
We will fix this in a new pr.


onSnapToItem not fired

My device is Android Galaxy note 4

Hi @FrancisShi,
We can't help you without seeing your code and knowing which version of the plugin you're using...

@FrancisShi I've made a lot of refactoring regarding callback handling recently.
I recommend you to try version 2.3.0 and see if this solves your issue.

+1
And i'm using 2.4.0


Describe component methods

In Chapter 4 section 2, component methods should be described in more detail. Possibly link to the Empolis article on this topic.

Done


Copy specs from knative/eventing

Changes
As part of https://github.com/knative/specs/issues/4 copying over specs files from knative/eventing

/kind

Fixes #

Release Note

Docs

/assign @vaikas

All files from https://github.com/knative/eventing/tree/main/docs/spec moved over as is. Links in data-plane.md were changed to point to new location.

Thanks for the feedback @vaikas. In response to your comments:

I ran a link checker and fixed all the broken link. There were 2 existing broken links which I couldn't fix.
I did some searching and looks we don't have a good automated solution for link checking. There was one used in docs but that was disabled and removed. So going forward I will do thing manually until we arrive at a good long term solution.

FILE: /tmp/specs/eventing/README.md
[✓] https://github.com/knative/eventing/blob/main/pkg/apis/eventing/v1beta1
[✓] https://github.com/knative/eventing/blob/main/test/e2e
[✓] motivation.md
[✓] overview.md
[✓] interfaces.md
[✓] spec.md
[✓] channel.md
[✓] sources.md
[✓] https://knative.dev/docs/serving/spec/knative-api-specification-1.0/#error-signalling
[✓] https://www.knative.dev/docs/eventing/#architecture
10 links checked.
FILE: /tmp/specs/eventing/broker.md
[✓] ./spec.md#eventingduckv1deliveryspec
[✓] https://github.com/cloudevents/spec/blob/v0.3/http-transport-binding.md
[✓] https://github.com/cloudevents/spec/blob/v1.0/http-protocol-binding.md
[✓] https://github.com/cloudevents/spec/blob/master/extensions/distributed-tracing.md
[✓] https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/semantic_conventions/messaging.md
[✓] #exceptions
6 links checked.
FILE: /tmp/specs/eventing/channel.md
[✓] https://www.ietf.org/rfc/rfc2119.txt
[✓] https://github.com/knative/eventing/blob/main/pkg/apis/duck/v1beta1/channelable_types.go
[✓] https://github.com/knative/eventing/blob/main/pkg/apis/duck/v1/channelable_types.go
[✓] https://github.com/knative/eventing/blob/main/pkg/apis/duck/v1beta1/subscribable_types.go
[✓] https://github.com/knative/eventing/blob/main/pkg/apis/duck/v1/subscribable_types.go
[✓] https://github.com/knative/eventing/blob/main/pkg/apis/duck/v1/delivery_types.go
[✓] https://github.com/knative/pkg/blob/main/apis/duck/v1/addressable_types.go
[✓] https://github.com/knative/pkg/blob/main/apis/duck/v1/status_types.go
[✓] https://github.com/cloudevents/spec/blob/v0.3/http-transport-binding.md
[✓] https://github.com/cloudevents/spec/blob/v1.0/http-protocol-binding.md
[✓] https://github.com/cloudevents/spec/blob/v1.0/http-protocol-binding.md#3-http-message-mapping
[✓] #input
[✓] https://w3c.github.io/trace-context/
[✓] https://github.com/knative/eventing/blob/main/config/config-tracing.yaml
[✓] https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/semantic_conventions/messaging.md
15 links checked.
FILE: /tmp/specs/eventing/data-plane.md
[✓] ./interfaces.md#addressable
[✓] ./interfaces.md#callable
[✓] https://github.com/cloudevents/spec/blob/v1.0/http-protocol-binding.md
[✓] https://github.com/cloudevents/spec/blob/v0.3/http-transport-binding.md
[✓] https://github.com/cloudevents/spec/blob/v1.0/http-protocol-binding.md#12-relation-to-http
[✓] ./interfaces.md#control-plane
[✓] https://github.com/cloudevents/spec/blob/master/http-protocol-binding.md#3-http-message-mapping
[✓] https://github.com/knative/eventing/blob/main/docs/delivery/README.md
[✓] https://github.com/cloudevents/spec/blob/v1.0/extensions/distributed-tracing.md
[✓] sources.md#source-event-delivery
[✓] channel.md#data-plane
[✓] broker.md
12 links checked.
FILE: /tmp/specs/eventing/helper.md
[✓] spec.md
[✓] #kind-trigger
[✓] #kind-broker
[✓] #kind-channel
[✓] #kind-subscription
[✓] spec.md#kind-trigger
[✓] spec.md#kind-broker
[✓] spec.md#kind-channel
[✓] interfaces.md#addressable
[✓] spec.md#kind-subscription
10 links checked.
FILE: /tmp/specs/eventing/interfaces.md
[✓] motivation.md
[✓] overview.md
[✓] spec.md
3 links checked.
FILE: /tmp/specs/eventing/motivation.md
[✓] https://github.com/cloudevents/spec
[✓] https://github.com/knative/serving
[✓] https://github.com/knative/build
[✓] overview.md
[✓] interfaces.md
[✓] spec.md
6 links checked.
FILE: /tmp/specs/eventing/overview.md
[✓] spec.md#kind-trigger
[✓] spec.md#kind-broker
[✓] spec.md#kind-subscription
[✓] spec.md#kind-channel
[✓] interfaces.md#addressable
[✓] interfaces.md#callable
[✓] interfaces.md
[✓] images/broker-trigger-overview.svg
[✓] images/resource-types-overview.svg
[✓] motivation.md
[✓] spec.md
11 links checked.
FILE: /tmp/specs/eventing/sources.md
[✓] https://cloudevents.io
[✓] ./interfaces.md#addressable
[✓] #source-crds
[✓]
[✓] #source-custom-objects
[✓] https://pkg.go.dev/github.com/knative/pkg/apis/duck/v1#Source
[✓] https://pkg.go.dev/github.com/knative/pkg/apis/duck/v1#SourceStatus
[✓] https://pkg.go.dev/github.com/knative/pkg/apis/#Condition
[✓] https://github.com/cloudevents/spec/blob/v1.0-rc1/spec.md#type
[✓] https://github.com/cloudevents/spec/blob/v1.0-rc1/spec.md#dataschema
[✓] https://github.com/knative/eventing/blob/main/config/200-source-observer-clusterrole.yaml
[✓] https://pkg.go.dev/github.com/knative/pkg/apis/duck/v1?tab=doc#Destination
[✓] https://pkg.go.dev/github.com/knative/pkg/apis/duck/v1#CloudEventOverrides
[✓] https://pkg.go.dev/github.com/knative/pkg/apis/duck/v1#Status
[✓] https://pkg.go.dev/knative.dev/pkg/apis#URL
[✓] https://pkg.go.dev/knative.dev/eventing/pkg/apis/eventing/v1beta1#EventType
[✓] https://knative.dev/docs/eventing/event-registry/
[✓] https://github.com/cloudevents/spec/blob/v0.3/http-transport-binding.md
[✓] https://github.com/cloudevents/spec/blob/v1.0/http-protocol-binding.md
[✓] https://github.com/knative/eventing/blob/main/docs/delivery/README.md
20 links checked.
FILE: /tmp/specs/eventing/spec.md
[✓] interfaces.md
[✓] overview.md
[✓] motivation.md
[✓] #kind-trigger
[✓] #kind-broker
[✓] #kind-channel
[✓] #kind-subscription
[✓] https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#objectmeta-v1-meta
[✓] #triggerfilter
[✓] #duckv1.destination
[✓] #apis.condition
[✓] #apis.url
[✓] #duckv1.kreference
[✓] #eventingduckv1.deliveryspec
[✓] #duckv1.addressable
[✖] duckv1.addressable
[✓] #ChannelTemplateSpec
[✓] #subscriberstatus
[✓] #corev1.ObjectReference
[✓] #duckv1.Destination
[✓] #eventingduckv1.DeliverySpec
[✓] #SubscriptionStatusPhysicalSubscription
[✓] interfaces.md#addressable
[✓] https://golang.org/pkg/net/url/#URL
[✓] https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
[✓] https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
[✖] https://kubernetes.io/docs/concepts/oFURLverview/working-with-objects/names/#names
[✓] https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties
28 links checked.
[✖] duckv1.addressable → Status: 400
[✖] https://kubernetes.io/docs/concepts/oFURLverview/working-with-objects/names/#names → Status: 404
ERROR: 2 dead links found!

On the eventing side I have https://github.com/knative/eventing/pull/5057 ready

Ready to merge @vaikas

/lgtm
/approve
Thanks!

/assign @tayarani

/unhold

/approve


Improve tag sort operations

Given the feedback from https://github.com/emilianoeloi/gitlab-ci-dashboard/pull/62, an improved version.
Cc: @emilianoeloi , @marek-ganko

Codecov Report

Merging #63 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master      #63   +/-   ##
=======================================
  Coverage   60.66%   60.66%
=======================================
  Files          13       13
  Lines         361      361
  Branches       74       74
=======================================
  Hits          219      219
  Misses        119      119
  Partials       23       23

Impacted Files
Coverage Δ

src/utils.js
88.46% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

Hi @necosta. I agreed with all of @marek-ganko's notes. I even started working on that same improvements once I accepted your PR, but I realized that your work is getting better, so I'll wait for your adjustments.

Obrigado, @necosta. Thanks @marek-ganko

<EMAIL_ADDRESS>


Add dither amplitude and period to cmd_states

Add dither amplitude and period to cmd_states

I need dither parameters for higher-fidelity checking in starcheck (I don't want to "penalize" observations with 20 arcsec dither).  Since we don't get dither parameters from HISTORY files and we don't have a some kind of new continuity file standard set up in products yet, I thought this might be a quick way to go.  We are already using command states for values for the thermal models within starcheck so there is some support for using content from the database to review flight products.
I considered using timelines to just fetch and read dither from previous backstop files, but I couldn't immediately decide if that method would be as robust as just adding the columns I wanted to cmd_states.

OK looks good.  Just double check that the conversion from cmd parameters to our units is correct.

Do we need buy in from anybody else?  As I understand it, this will change the default returned columns from get_cmd_states, which should be fine unless somebody is doing their own text parsing of that and also using the default list of columns.

Yes we need to put this through the LR change process.

And of course there will be many changes to the actual states.

And yes, I assumed LR, but I didn't know about just drawing ACIS attention to this PR.

Yup.  Probably an email and include Matt as well.

Given our move to use of dynamic command states, I think this can just be closed unmerged.

:tada: :rocket:


LLVM needs additional maintainers (mainly for updates)

Note: I'll edit this post to keep it up-to-date.
We do have LLVM maintainers that improve the Nix expressions, handle PRs, etc. but we do severely lack maintainers to package new LLVM versions. Adding new LLVM versions is currently handled by me but I neither have enough time nor motivation to handle LLVM (which is also why I often (have to) take some shortcuts, e.g.: https://github.com/NixOS/nixpkgs/pull/162423/files). I'm basically only doing that work because Chromium requires bleeding-edge LLVM versions to compile (it's currently already difficult to compile Chromium with LLVM 14 even tough there isn't even a RC for LLVM 15 out - Google simply chooses to pick Git commits from the main branch...).
The most relevant tasks that need help are:

Keeping llvmPackages_git up-to-date (this is mostly important to enable us to quickly package new LLVM versions as soon as the first RC is out without having to put in too much work at once). This requires most of the time. It currently requires resolving a lot of merge conflicts due to our GNU install dirs patches (it wasn't really difficult so far and didn't require knowing the code but it takes a fair bit of time as there are a lot of those patches and often a few other build failures that require fixing).

llvmPackages_git is currently severely out-of-date and it would probably be best to replace it with the content of llvmPackages_14 first (rm -r pkgs/development/compilers/llvm/git/ && cp -r pkgs/development/compilers/llvm/14/ pkgs/development/compilers/llvm/git but one needs to check the Git log first)

Packaging new LLVM versions as soon as the first RC is out (that's pretty simple/straightforward as it's basically just copying llvmPackages_git and switching to the right version, e.g.: https://github.com/NixOS/nixpkgs/pull/162104 (I prefer doing it in two commits but one could also diff it against llvmPackages_git)).

LLVM recently switched to a bi-weekly release schedule (vs. just 1-2 additional releases per major version) so this will also require more time/effort. But we might not even want to package every bi-weekly release (especially since our staging workflow is probably to slow for that and it should cause quite a few rebuilds if llvmPackages_latest points to it).

Updating llvmPackages_latest a super easy change (just one line) but testing is challenging (a full nixpkgs-review might be doable but one needs to exclude the transient dependencies from Mesa - using Hydra might be easier).

This work is already behind: https://github.com/NixOS/nixpkgs/pull/165701.

And of course we could also really need testers/maintainers for other platforms (AArch64, Darwin, etc.).
Remove old LLVM versions from Nixpkgs. We currently package everything from version 5 (released in 2017) up to version 14 (i.e., 10 different versions - and that number is likely growing).

LLVM is one of currently five release critical packages and some notable packages that depend on recent versions are:

Chromium (often even requires RCs - currently it would require an unreleased LLVM version for PGO and some build flags)
Mesa (uses llvmPackages_latest and is responsible for most of the rebuilds)
Rust (already depends on llvmPackages_14)

And for documentation:

We currently have two update scripts

pkgs/development/compilers/llvm/update.sh
pkgs/development/compilers/llvm/update-git.py

I'll try to answer questions / help during the transition but tbh I don't know that much about LLVM (just enough to update it without too much breakage).
cc existing LLVM maintainers: @lovek323 @7c6f434c @dtzWill @primeos
And (AFAIK) @sternenseemann and @Ericson2314 do most of the Nix expression maintenance (refactorings/improvements/cleanups/cross-fixes/etc.)

Maybe we should try making the experience of bumping llvmPackages_git better as a first step and try to keep it up to date. Ideally, then, adding the latest version is just copying a bunch of files and selecting a tag instead of a commit. An idea I have would be to have some kind of script which bumps llvmPackages_git, tries to build chromium and then creates a PR for it. Having a machine that does this weekly or so would be awesome (I'm unsure if we could get @ryantm's nixpkgs-update to do it, but I think even if we could, the machine would surely die or timeout the nixpkgs-review of the change).
It would be lovely if we could delete older LLVM version or alternatively consolidate the expressions for different versions, but I'm afraid that that's not attainable without a lot of work. We are partially responsible for this as well, since we force divergence in the expressions by upstreaming stuff that makes packaging in nixpkgs easier :)
I'm happy to be a more official LLVM maintainer, but unsure how much actual time I can contribute, as a lot of it already goes into Haskell.

Maybe we should try making the experience of bumping llvmPackages_git better as a first step and try to keep it up to date.

Yes, +1. Unfortunately, I'm not sure if that's really possible though. For me the main annoyance was the addition of the GNU install dirs patches. Those regularly cause conflicts and then I have to copy them over to Git, resolve the conflicts, copy the results back, etc. At least for me that required most of the time in the past and is currently keeping me from giving it another go (llvmPackages_git is already so outdated that there are likely a lot of conflicts - the required changes for the last major bump can be seen here: https://github.com/NixOS/nixpkgs/pull/154465/files).

It would be lovely if we could delete older LLVM version

That's also an additional task that I missed. We have quite a lot of old versions... :o

I'm happy to be a more official LLVM maintainer

IMO it still makes perfect sense to add you and @Ericson2314 to the maintainer list (you don't even have to put in more work - you're already maintaining LLVM and it would simply reflect the current state of things).
As I've written before (https://github.com/NixOS/nixpkgs/pull/154465#issuecomment-1010330966):

AFAIK you're currently doing by far most of the work anyway and usually end up reviewing other PRs as well.

Feel free to submit a PR at any time ;)
Btw @lovek323 @7c6f434c @dtzWill: What's your current status? IIRC I haven't seen your handles on LLVM PRs/issues often anymore but I could be wrong. Are you still interested in maintaining LLVM?

Also: Maybe we want to make a “formal” llvm team.

+1, SGTM.

I was actually doing something with LLVM packaging long ago. Nowadays I just sometimes merge additions that seem very safe and pretty clean but forgotten in the PR flood.

I'm not sure how much time I can devote to this as well – the git conflict resolution seems like it may require deeper knowledge than I currently have. Could you put some steps down that I could try to follow to see if I have the expertise to do it?

Thank you very much for starting this discussion.  I agree the importance of LLVM and packaging it /well/ and dutifully is not reflected in the attention we (collectively) are giving it.  As you say, this is critical, and also important to me.

I'm basically only doing that work because Chromium requires bleeding-edge LLVM versions to compile (it's currently already difficult to compile Chromium with LLVM 14 even tough there isn't even a RC for LLVM 15 out - Google simply chooses to pick Git commits from the main branch...).

Sigh re:chromium being so intensely aggressive chasing latest LLVM.  Thank you for your efforts on this front!

Keeping llvmPackages_git up-to-date (this is mostly important to enable us to quickly package new LLVM versions as soon as the first RC is out without having to put in too much work at once). This requires most of the time. It currently requires resolving a lot of merge conflicts due to our GNU install dirs patches

The GNU install dirs patches are difficult, I agree.  The git stuff isn't so bad (although this last instance was rough) I think they're the biggest pain point re:getting things building (vetting/testing aside for now).  Hopefully the rest of what we need can be upstreamed soon, or is that not likely? Can we push on this? Or are there other options/approaches we can take? If that's not in the cards, how about we work on documenting what they do and why they're needed (or what to check to ensure things are as-expected) so that it's easier to port them with confidence?
They seem to have something to do with ensuring our outputs each have what they "should", but that isn't always clear when diffing outputs across versions-- as LLVM changes what it installs where or adds/removes files, or changes its build system code so a better understanding would be useful, IMHO.

LLVM recently switched to a bi-weekly release schedule (vs. just 1-2 additional releases per major version) so this will also require more time/effort. But we might not even want to package every bi-weekly release (especially since our staging workflow is probably to slow for that and it should cause quite a few rebuilds if llvmPackages_latest points to it).

Updating llvmPackages_latest a super easy change (just one line) but testing is challenging (a full nixpkgs-review might be doable but one needs to exclude the transient dependencies from Mesa - using Hydra might be easier).

This work is already behind:

These can (and ideally they would--if we moved to latest as soon as was safe) be related issues-- if llvmPackages_latest is what's receiving the bi-weekly releases, I don't think any of us individual maintainers have the bandwidth/compute to keep up.  I don't, anyway.  A hydra job(set), maybe rigged to some update bot helper,  would be appropriate I think (although not my resources to allocate), especially for testing other platforms (+cross, (+musl, +static? :innocent:)).  Back when I helped update this more regularly, that's basically what I was doing on my own hydra instance + builders (which I no longer have).
I don't know if we can test for it, but Mesa has had (subtle) breakages from LLVM updates before (IIRC some AMGPU thing manifesting as a rendering issue for users?), not that we need more pressure on us about this :innocent: .  (Unfortunately I think we'll just need our unstable users to help us catch those things, I think)

@dtzWill: What's your current status? IIRC I haven't seen your handles on LLVM PRs/issues often anymore but I could be wrong. Are you still interested in maintaining LLVM?

Apologies for not maintaining things more actively, I do use LLVM bits quite actively so I at least am good for kicking the tires.  See my recent PR's unbreaking LLVM 14 bits after the quick bump (speaking of which LLDB still needs fixing, I have some WIP bits on PR's for this...).  And FWIW a recent PR adding MLIR + flang (little rough).  I also maintain the 'lit' package although TBH that's quite simple to keep up-to-date :).

Also: Maybe we want to make a “formal” llvm team.

If there's an LLVM team I'd like to be part of it.  I was away for a few years and I'm unfortunately incredibly busy for the next month or two, but this is important to me in what's likely a long-term way :).  I'll see what I can do, but I can't lead the charge.

the git conflict resolution seems like it may require deeper knowledge than I currently have. Could you put some steps down that I could try to follow to see if I have the expertise to do it?

It's not really difficult but requires (advanced?) VCS/Git knowledge. Unfortunately it'll probably take quite a bit of text to explain and I don't have a good link :o The way I do it (using Git) is basically: Checkout the old LLVM revision, import the Nixpkgs patches, rebase against the new LLVM revision (that way Git will perform the 3-way-merge for me and I just have to resolve the conflicts (and I use merge.conflictStyle = "diff3" in my ~/.gitconfig (s. man git-config) so that I always have all of the context to resolve the conflits). And if you keep up with Nixpkgs changes (i.e. keep the imported LLVM patches in sync) you only have to rebase next time. Anyway, that's just how I do it - there could be good or even better alternatives.

The GNU install dirs patches are difficult, I agree. The git stuff isn't so bad (although this last instance was rough) I think they're the biggest pain point re:getting things building (vetting/testing aside for now).

Yeah, it's just tedious work that takes time and I don't have the motivation for it anymore (it's important but I lack time for it and only need LLVM for Chromium).

Can we push on this?

AFAIK it's progressing slowly but I stopped following the progress (IIRC quite a few patches have been merged though). Anyway, it's progressing but not nearly as fast as I was hoping when they were added to Nixpkgs...

Or are there other options/approaches we can take? If that's not in the cards, how about we work on documenting what they do and why they're needed (or what to check to ensure things are as-expected) so that it's easier to port them with confidence?

@Ericson2314 could you give us a brief update on the current status/progress/plan of those GNU install dir patches?
re:Documentation: Most of the relevant information if probably linked here + in the commit message(s): https://github.com/NixOS/nixpkgs/pull/111487 (although we'd need something up-to-date... regarding the progress, Phabricator links, etc.).

If there's an LLVM team I'd like to be part of it.

Cool :) I think it'd be good/important to create such a team.

+1 for documentation.

Also +1 for that. IIRC we currently have basically no LLVM documentation at all :o

I'm currently trying to build llvm_15 for work (the new js-backend for GHC requires it) and running into a lot of patch issues which I do not understand where they come from, why they are needed or how to proceed. Honestly any documentation would be incredibly helpful. The same issues happen with llvm_latest after updating with either script as well.

Yeah, packaging newer LLVM releases or updating llvm_latest is basically a PITA atm (time consuming).
Another PITA is that PRs often don't update pkgs/development/compilers/llvm/git/ as well (which would be the most important thing to target...). Ideally, packaging a new LLVM release should require few changes other than cp -R pkgs/development/compilers/llvm/git pkgs/development/compilers/llvm/$n but in reality it requires digging through the Git history and applying missing patches first...

@primeos I just landed a few more things upstream. The version 15 fork is going to happen soon I heard, so trying to shrink the patches a bit more before that.

Hi Nixpkgs folks, I'd like to nominate myself and join the maintenance of LLVM related packages! I'm using NixOS now, and I can help with reviewing PRs & testing packages & upstream contacts. I'm working on the LLVM project (committer) and very happy to have such an elegant package management tool Nix! It would be nice if I could help a little bit :)

Could we have a team and mentioned (subscribed) LLVM-related topics (?
We have a series GitHub teams at the llvm-project, and github notifies me if the PR/issue are related to this topic. (https://github.com/llvm/llvm-project/issues/60066#issuecomment-1384223958 for example)

Could we have a team and mentioned (subscribed) LLVM-related topics (?

We can quite easily make a nixpkgs maintainer team #211401, creating a GH team in the NixOS org could be a second step if we feel it helps.

We do have LLVM maintainers that improve the Nix expressions, handle PRs, etc. but we do severely lack maintainers to package new LLVM versions.

Well, I recently joined as a maintainer. I just found this issue, though I don't have the ability to commit I do have time and skills. I pretty much got started since LLVM 17. Do we need more than just one more maintainer?

I made @NixOS/llvm.

Well, I recently joined as a maintainer. I just found this issue, though I don't have the ability to commit I do have time and skills. I pretty much got started since LLVM 17. Do we need more than just one more maintainer? I can also create an LLVM team on GitHub since it seems there's a good number of us.

@RossComputerGuy I would like to contribute to this.
I'm still a bit new to Nix and NixOS but I've been working on a lot of toolchain related stuff with Nix lately, like custom derivations for stdenv, binutils, mold, LLVM, GCC, etc. (mostly for targeting RISC-V).
I also have some experience with the LLVM build system internals. Although it's a bit out of date now (mainly because I started using NixOS!), I worked on https://github.com/llvmup/toolchains which is a cmake superbuild project which is intended to make it easier to build and package LLVM toolchain components.
Please let me know how I can help.

@silvanshade You can join the NixOS Matrix and then join the compilers team chat. That will be the best place to communicate without clogging up this issue.


Selective tracing

Also, looks like 2 out of 3 of changes in #488 do not apply here anymore

Also, looks like 2 out of 3 of changes in #488 do not apply here anymore

I guess I'm a bit confused about the change set. I thought that all user functions need to be wrapped into tracer code and all exposed public functions should trace user functions, since we don't know which functions they will use. Why do we no longer need to wrap each function into traceAs?

So traceAs is a re-tracing mechanism it copies over the trace from one function to the other, it is used in places like map to trace the continuation of the chain that is internally used, ideally you want to use it to trace effects as the caller rather then exposing the internal (similar to zio's ZIOFn)
The functions that need tracing are definitely not all, basically, we only need traces on those functions that will appear as a continuation on the fiber, the old plugin was adding traces to everything.
This change-set uses hints defined as tags in the methods that says what should contain a trace, the downside is for example T.chain(myMethod) will be traced pointing to T.chain(***here***myMethod) rather than at the definition site of myMethod it's basically tracing usage instead of definition.
The above is not a problem in my view as traces are really used only in case of errors and it is enough to detect the usage-site of things especially because you use the constructors directly, e.g: T.chain(myFn) is a thing I see a use for but T.effectAsync(myFn) most of the time doesn't make sense as you want to inline myFn like T.effectAsync((cb) => {...}) meaning the definition and usage site are the same.

I guess I'm a bit confused about the change set. I thought that all user functions need to be wrapped into tracer code and all exposed public functions should trace user functions, since we don't know which functions they will use. Why do we no longer need to wrap each function into traceAs?

So traceAs is a re-tracing mechanism it copies over the trace from one function to the other, it is used in places like map to trace the continuation of the chain that is internally used, ideally you want to use it to trace effects as the caller rather then exposing the internal (similar to zio's ZIOFn)
The functions that need tracing are definitely not all, basically, we only need traces on those functions that will appear as a continuation on the fiber, the old plugin was adding traces to everything.
This change-set uses hints defined as tags in the methods that says what should contain a trace, the downside is for example T.chain(myMethod) will be traced pointing to T.chain(***here***myMethod) rather than at the definition site of myMethod it's basically tracing usage instead of definition.
The above is not a problem in my view as traces are really used only in case of errors and it is enough to detect the usage-site of things especially because you use the constructors directly, e.g: T.chain(myFn) is a thing I see a use for but T.effectAsync(myFn) most of the time doesn't make sense as you want to inline myFn like T.effectAsync((cb) => {...}) meaning the definition and usage site are the same.


Improve PlatformIO generator to handle spaces in paths

This PR mainly fixes #834 by placing path arguments to the Nanopb generator in the CMD array separately to avoid possible issues if paths contain spaces
Other minor improvements

I think this does not result in any functional difference, but it is cleaner so I'll merge it.


password reset

For users who are registered via e-mail, we should provide resetting their password.

We should also verify the email on registration by sending an activation link.

This feature is already present in Django, see:

http://garmoncheg.blogspot.cz/2012/07/django-resetting-passwords-with.html
https://docs.djangoproject.com/en/1.9/topics/auth/default/#django.contrib.auth.views.password_reset


Waveshare connector doesn't fit the servo wire

The connectors do not fit together. If this is expected it would be good to extend the instruction to trim the connector.

Highly likely I am confused -- unfamiliar with all this. Going off of the dynamixel quickstart example. https://www.youtube.com/watch?v=JRRZW_l1V-U
Screenshots for each step would be great.

I ended up clipping off the outter edge but can't seem to keep motors powered.

@MichaelrMentele you'll need male-female jumper wires to connect these

I used extra wires to connect it this way.


GUI: it seems the GUI is considering OP_RETURN outputs from coinbase tx as incoming payments

To be confirmed but from what @kloaec is showing me on a call it seems the witness commitment output from the coinbase tx are listed in the home page as incoming payments.

try to reproduce it on regtest, they first coins op_return appear in GUI in my side:

what i hit instead, is that halvings seems coming quickly and the coinbase came to 0 sats after few thousands blocks:

so i guess the real issue is @kloaec is a greedy regminer :smile:

Ok, thanks for testing.


STM32L496AG mcu flash can not be erase, write

Describe the bug
I want to access STM32L496AG16P mcu flash memory. The following is my code. Device binding is ok but erase get fail.
Does anybody know why it happen? And how to solve this?
To Reproduce

flash_device =
device_get_binding(DT_CHOSEN_ZEPHYR_FLASH_CONTROLLER_LABEL);
if (flash_device) {
APP_UART_SendString("\n\rflash device ok");
} else {
APP_UART_SendString("\n\rflash device fail");
}
addr=0x080f0000;
ret = flash_erase(flash_device, addr, len);
if (ret == 0) {
    APP_UART_SendString("\n\rflash ers ok");
}else {
    APP_UART_SendString("\n\rflash ers fail");
}
for (i=0;i<len; i++) {
    wr_buf[i]=(uint8_t)(i%0x100);
}
ret = flash_write(flash_device, addr, wr_buf, len);
if (ret == 0) {
    APP_UART_SendString("\n\rflash write ok");
}else {
    APP_UART_SendString("\n\rflash write fail");
}

<prj.conf>
CONFIG_FLASH=y
uart print result:
flash device ok
flash ers fail
Expected behavior
mcu flash rom erase, write should be working, but it is not working now.
Environment (please complete the following information):
Hardware:STM32L496AG16P
Linux Ubuntu 20.04.3 LTS
Zephyr SDK,-0.13.0
Zephyr SHA1 ID:bb85a55

@glin00 Can you have another test using samples/drivers/flash_shell ?


Demonstrate canceling a cookie

This is better than nothing but the more long term solution is in #10


Filtering many_many realtions does not work

Hi,
this is a great component, which really does rise the value of silverstripe-cms.
Sadly I can not get it working with a many_many relation.
I tried your FILTER_MANY_MANY_RELATION-example code, but no dropdown provided. The screenshots does not belong to the codesnippet.
Can you provide a full-example for a many_many-relation?
thanks in advance

Hi @tiefseh , thank you for raising this issue. Can you please add some more details so I can look into this? I would keen on having the following information:

SilverStripe framework version you are using
Code snippets of your ORM setup (model1, model2 and their many many relationship definition)
Code snippet of your CMS fields setup where you're using the RichFilter header

Thanks.

Hi @tiefseh , thank you for raising this issue. Can you please add some more details so I can look into this? I would keen on having the following information:

SilverStripe framework version you are using
Code snippets of your ORM setup (model1, model2 and their many many relationship definition)
Code snippet of your CMS fields setup where you're using the RichFilter header

Thanks.

Closing this as this issue has become stale (more feedback was needed)


Markdown Support

This is more a "want to have" - but it would be incredible if with HTML templates there was the ability to auto-parse Markdown. For example if I have
<p> {{ dog }} </p>
in my template and dog contains a String which is in Markdown then the output in the template would be translated into HTML. Right now I'm planning to string together GRMustache with MMMarkdown via a Formatter or Rendering Object. Is that the best way to solve this issue?

Hello @davecom. GRMustache will not have built-in support for markdown.
The simplest solution is to prepare your input, feed your templates with HTML generated by markdown, and use triple-mustache tags {{{ dog }}} to avoid escaping of this HTML.
A more involved solution could use, as you say, filters ({{ markdown(dog) }}) that return rendering objects (in order to explicitly manage the HTML content type) but I must first advise the simplest solution above.

Thanks for the reply and thanks for making a great library.


Couple of possible mistakes in the 1st flowchart on the page

On the right most side, pointers to couple of boxes ("Container Instances" and "App Service") should not be Yes.
Architecturally, shouldn't it be connected by "No"?
Isn't this the right way to do:

Microservice architecture? ->No-> App Service
Needs full fledged orchestration? ->No->Container instances

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 510808e8-db5d-6b07-9a04-6edb743a2dfc
Version Independent ID: 20d098aa-ef31-cb26-d677-765cfc9a7164
Content: Choosing an Azure compute service - Azure Architecture Center
Content Source: docs/guide/technology-choices/compute-decision-tree.md
Service: architecture-center
Sub-service: guide
GitHub Login: @doodlemania2
Microsoft Alias: pnp

Thanks for reporting - this issue is under review. This is a Microsoft Internal DevOps Bug ID # 405348

Thank you for your detailed feedback.  We are looking into the issue, and we will respond when we have more information.

Diagram has already been updated. Thank you.


Add --all flag for listing all projects, active and inactive

Before submitting the PR, please go through the sections below and fill in what you can. If there are any items that are irrelevant for the current PR, remove the row. If a relevant option is missing, please add it as an item and add a PR comment informing that the new option should be included into this template.

All relevant items should be ticked before the PR is merged

Currently Deleted and Archived projects are included when running dds ls or  dds project ls
Here we limit it to only including the active ones and adding a flag called --all to indicate that the dds should list all of them.
Works with https://github.com/ScilifelabDataCentre/dds_web/pull/1302

[ ] Add a summary of the changes and the related issue
[ ] Add motivation and context regarding why the change is needed
[ ] List / describe any dependencies or other changes required for this change
[ ] Fixes DDS-1306

Type of change

[ ] Documentation
[ ] Workflow
[ ] Security Alert fix
[ ] Bug fix (non-breaking)
[ ] New feature (non-breaking)
[ ] Breaking change (breaking, will cause existing functionality to not work as expected)
[ ] Tests (only)

Checklist:
General

[ ] Changelog: New row added. Not needed when PR includes only tests.
[ ] Code change

[ ] Self-review of code done
[ ] Comments added, particularly in hard-to-understand areas
[ ] Documentation is updated

Repository / Releases

[ ] Blocking PRs have been merged
[ ] Rebase / update of branch done
[ ] Product Owner / Scrum Master

[ ] The version is updated (PR to master branch)
[ ] I am bumping the major version (e.g. 1.x.x to 2.x.x)

[ ] I have made the corresponding changes to the API version

Checks

[ ] Formatting: Black & Prettier checks pass
[ ] CodeQL passes
[ ] Tests

[ ] I have added tests for the new code
[ ] The tests pass

Accidentally wrote this comment in the API PR but: https://github.com/ScilifelabDataCentre/dds_web/pull/1302#discussion_r994687329

@valyo Also rebase / merge dev into this branch

of course


Add daobeam theme

Pull Request Template
Discord username (optional)
If you're in our Discord server, we'd like to give you the Contributor Discord Role, pleaes include your username.
Note: It must be labelled like so: username#4747 (make sure to include the #XXXX).
Name of theme
daobeam
How Has This Been Tested?
this theme has been my daily driver for ~3 months. Lots of docker/kubernetes usage, and numerous logging/scripting activities.
Have you run the python script? python3 ./scripts/gen_theme_previews.py <folder-name-eg-standard>
Notes
We cannot accept pull request that include custom background images because:

of licensing restrictions
we are trying to keep the binary size of the repo as small as possible (just the yaml files)

If your theme has an intended custom background image, include a comment in the yaml with a link to where people should download it.

@shayneo thanks for contributing your theme


Android Gradle error with react-native 0.68.0

Hi! 👋
Firstly, thanks for your work on this project! 🙂
Today I used patch-package to patch<EMAIL_ADDRESS>for the project I'm working on.

In the latest version of react-native, a newer Gradle version is used that is incompatible with the build.gradle file used by react-native-securerandom (https://docs.gradle.org/current/userguide/upgrading_version_6.html#sec:configuration_removal).
The library should probably be updated to the latest react-native version, however here is the diff that solved my problem:
diff --git a/node_modules/react-native-securerandom/android/build.gradle b/node_modules/react-native-securerandom/android/build.gradle
index e21cdf0..21d7519 100644
--- a/node_modules/react-native-securerandom/android/build.gradle
+++ b/node_modules/react-native-securerandom/android/build.gradle
@@ -16,7 +16,7 @@ buildscript {
 }

 apply plugin: 'com.android.library'
-apply plugin: 'maven'
+apply plugin: 'maven-publish'

 def safeExtGet(prop, fallback) {
     rootProject.ext.has(prop) ? rootProject.ext.get(prop) : fallback
@@ -87,17 +87,17 @@ def configureReactNativePom(def pom) {

 afterEvaluate { project ->

-    task androidJavadoc(type: Javadoc) {
-        source = android.sourceSets.main.java.srcDirs
-        classpath += files(android.bootClasspath)
-        classpath += files(project.getConfigurations().getByName('compile').asList())
-        include '**/*.java'
-    }
+    // task androidJavadoc(type: Javadoc) {
+    //     source = android.sourceSets.main.java.srcDirs
+    //     classpath += files(android.bootClasspath)
+    //     classpath += files(project.getConfigurations().getByName('compile').asList())
+    //     include '**/*.java'
+    // }

-    task androidJavadocJar(type: Jar, dependsOn: androidJavadoc) {
-        classifier = 'javadoc'
-        from androidJavadoc.destinationDir
-    }
+    // task androidJavadocJar(type: Jar, dependsOn: androidJavadoc) {
+    //     classifier = 'javadoc'
+    //     from androidJavadoc.destinationDir
+    // }

     task androidSourcesJar(type: Jar) {
         classifier = 'sources'
@@ -114,16 +114,16 @@ afterEvaluate { project ->

     artifacts {
         archives androidSourcesJar
-        archives androidJavadocJar
+        // archives androidJavadocJar
     }

     task installArchives(type: Upload) {
         configuration = configurations.archives
-        repositories.mavenDeployer {
-            // Deploy to react-native-event-bridge/maven, ready to publish to npm
-            repository url: "file://${projectDir}/../android/maven"
+        // repositories.mavenDeployer {
+        //     // Deploy to react-native-event-bridge/maven, ready to publish to npm
+        //     repository url: "file://${projectDir}/../android/maven"

-            configureReactNativePom pom
-        }
+        //     configureReactNativePom pom
+        // }
     }
 }

This issue body was partially generated by patch-package.

On RN 0.68.0, changed maven to maven publish in android/build.gradle. But still has the error.
error Failed to install the app. Make sure you have the Android development environment set up: https://reactnative.dev/docs/environment-setup.
Error: Command failed: ./gradlew app:installDebug -PreactNativeDevServerPort=8081

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/macair/Documents/code/js/xyz_app6/node_modules/react-native-securerandom/android/build.gradle' line: 93

* What went wrong:
A problem occurred configuring project ':react-native-securerandom'.
> Configuration with name 'compile' not found.

Here is the line: 93:
 ` classpath += files(project.getConfigurations().getByName('compile').asList())`

Hi mfellner, I am having the similar problem. do you have the list of changes you have made with the android/build.gradle? Many thanks. The gradle used is 7.0.x

Is this library still maintained? Also experiencing this issue.

I updated this package's build.gradle to use gradle 7.0.0 (https://github.com/HwangTaehyun/react-native-securerandom)
Also, It didn't seem to be maintained, so I re-deployed it. (react-native-awesome-secure-random)

I'm glad people have found this library useful but to be truthful I haven't used or worked on it in a while, and don't plan to.
@HwangTaehyun would you be interested in being added as a maintainer here?

Oh, hi @robhogan! I've recently been interested and would like to be a maintainer of this project!

Oh, hi @robhogan! I've recently been interested and would like to be a maintainer of this project!

Welcome on board :)

Thanks @HwangTaehyun, Gradle 7 is now supported since merge of pull #40. @robhogan, are we able to get this published please, I'd love to upgrade my app to gradle 7

thanks @HwangTaehyun for the update, waiting for a new release now, until then
yarn add ssh://git@github.com:robhogan/react-native-securerandom.git is our friend

I would also like to request a new release.

Apologies folks, I've only just seen these release requests. I'll prepare a changelog and publish tomorrow. At a glance it looks like it's safest to assume the Gradle updates are breaking (for users on very old RN versions) so I'm inclined to publish as v2. @HwangTaehyun, sound good to you?

On second look, I don't think any of these changes are breaking, so I've released as 1.0.1. Thanks everyone, closing!


Allow dynamic repository credentials for authenticated Binderhub instances.

This PR is related to issue #1154
Proposed change
Make it possible to fill repo provider / git credentials for a forge (e.g. gitlab instance) dynamically using the currently logged-in user information. This would help set up binderhub instances for use with private repositories for organizations that run a forge (e.g. gitlab instance).
Scope
This change is meant for authenticated Binderhubs (e.g. an instance of BinderHub that is authenticated against a Gitlab instance and whose main purpose is to build repositories hosted in that instance). It does not address building private repositories from an anonymous Binderhub instance (which would probably entail UI changes and/or a complex authentication workflow?).
In that use case, an auth-aware RepoProvider could assume that auth information is available.
Issues

The example RepoProvider (AuthGitLabProvider) in issue #1154 makes a blocking http call in the initializer to retrieve auth info -- this should be made asynchronous, but I'm not sure how.

It should be possible to fill default traitlets config attributes (e.g. default_git_credentials) using dynamic credentials, after retrieving those credentials asynchronously. How can that be implemented?

The RepoProviders should probably made aware of the auth info in order to be able to fetch private repositories, but are RepoProviders the right place to implement authorization / access controls ? If not, would a pre_build_hook as suggested in #1117 help?

Testing this PR locally

Install this branch of Binderhub locally using minikube as per the CONTRIBUTING instructions

Start minikube (e.g. run minikube start --memory 8192) and note the minikube IP (run minikube ip)

Register for an account at gitlab.com (user will be called user1)

Create a private project

Create an application on gitlab.com ("settings" on your user profile) for authentication purposes (e.g. bhubtest).

In the redirect URL field, use http://<minikube ip>:30123/hub/oauth_callback (note that the minikube IP may change when minikube restarts, usually alternating between two values. If so, put both in the redirect_uri field to ease testing).
Give the application the api and read_repository scopes.
Note the values of Application ID and Application Secret.
Note: it would be nice to restrict the scope to read_api now that gitlab offers this...

Install the requests package (used by the example repo provider) e.g. pip install requests

change the file testing/minikube/binderhub_auth_config.py so that it looks like this

import json
from urllib.parse import urlparse
import os
import requests
from traitlets import default

from binderhub.repoproviders import GitLabRepoProvider

here = os.path.abspath(os.path.dirname(__file__))
load_subconfig(os.path.join(here, 'binderhub_config.py'))

c.BinderHub.base_url = '/'
c.BinderHub.auth_enabled = True
# configuration for authentication
hub_url = urlparse(c.BinderHub.hub_url)
c.HubOAuth.hub_host = '{}://{}'.format(hub_url.scheme, hub_url.netloc)
c.HubOAuth.api_token = c.BinderHub.hub_api_token
c.HubOAuth.api_url = c.BinderHub.hub_url + '/hub/api/'
c.HubOAuth.base_url = c.BinderHub.base_url
c.HubOAuth.hub_prefix = c.BinderHub.base_url + 'hub/'
c.HubOAuth.oauth_redirect_uri = 'http://<IP_ADDRESS>:8585/oauth_callback'
c.HubOAuth.oauth_client_id = '<client ID from the newly-created gitlab application>'

class AuthGitLabProvider(GitLabRepoProvider):
    def __init__(self, *args, handler, **kwargs):
        super().__init__(*args, **kwargs)
        self.handler = handler
        ud = self.get_user_data(self.handler.get_current_user()['name'])
        self.access_token = ud['auth_state']['access_token']

    def get_user_data(self, username):
        r = requests.get(c.HubOAuth.api_url + f'/users/{username}',
            headers={
             'Authorization': 'token %s' % c.HubOAuth.api_token,
            }
        )
        r.raise_for_status()
        return r.json()

    @default('git_credentials')
    def _default_git_credentials(self):
        if self.access_token:
            return r'username=oauth2\npassword={token}'.format(token=self.access_token)
        return ""

c.BinderHub.repo_providers = {'gl': AuthGitLabProvider}

change the file testing/minikube/jupyterhub-helm-auth-config.yaml so that it looks like this

cull:
  users: false
hub:
  services:
    binder:
      oauth_no_confirm: true
      oauth_redirect_uri: "http://<IP_ADDRESS>:8585/oauth_callback"
      # gitlab application id
      oauth_client_id: <newly-created Gitlab app ID>

custom:
  binderauth_enabled: true

singleuser:
  # to make notebook servers aware of hub
  cmd: jupyterhub-singleuser

auth:
  type: gitlab
  gitlab:
    callbackUrl: http://<minikube IP>:30123/hub/oauth_callback
    # retrieved from the GitLab UI (see above)
    clientId: "<newly-created Gitlab app ID>"
    clientSecret: "<newly-created Gitlab app secret>"
  state:
    enabled: true
    cryptoKey: "<output of `openssl rand -hex 32`>"

Install jupyterhub by running ./testing/minikube/install-hub --auth

Run binderhub: python3 -m binderhub -f testing/minikube/binderhub_auth_config.py

Access http://<IP_ADDRESS>:8585 using your browser. You will be prompted to login using gitlab.com

Authorize the application, you should end up at the familiar BinderHub UI (phew!)

Try building your private repository: in the provider dropdown, select gitlab.com and enter the "namespace" (user1/project) for your private project. Check that it builds and launches

Register a new gitlab user (user2), create a new private project for user2.

Check that user2 can build its own private project, but not user1's

(Note that whenever the minikube IP changes due to a restart, the file testing/minikube/jupyterhub-helm-auth-config.yaml should be updated accordingly and ./testing/minikube/install-hub --auth should be run again)

Thanks for opening this! I'm not sure passing the handler to the repoprovider is the right implementation, but having a concrete use case is very helpful. Some thoughts:

when deploying binderhub in an authenticated context, the Handler object should have the authenticated user model available as self.current_user. This should already have the info fetched by get_user_data(self, username). If it doesn't, that's something I think we can fix in HubAuth on the jupyterhub side without needing to re-identify the user a second time
if we are talking about standardizing on the auth info provided by HubAuth, we can pass user=self.current_user to RepoProviders instead of the Handler itself.
I believe passing the user model to the repo provider solves the need to make the request async in this particular case, but if we need a new async API to load info, I think we can add it.

Hi @minrk,
Thanks for your reply!
Regarding the Handler's current, at least in the configuration described above, it does not seem to contain all info fetched by get_user_data (crucially, the auth_state attribute seems to be missing).
Regarding the other points, yes, at least for this use case limiting ourselves to passing the user info to the RepoProvider would be enough.

Hi @minrk,
Thanks for your reply!
Regarding the Handler's current, at least in the configuration described above, it does not seem to contain all info fetched by get_user_data (crucially, the auth_state attribute seems to be missing).
Regarding the other points, yes, at least for this use case limiting ourselves to passing the user info to the RepoProvider would be enough.

This pull request has been mentioned on Jupyter Community Forum. There might be relevant details there:
https://discourse.jupyter.org/t/a-question-about-binderhub-authentication-and-privacy/7758/2

Hi!
That would be definitely a great feature !

when deploying binderhub in an authenticated context, the Handler object should have the authenticated user model available as self.current_user. This should already have the info fetched by get_user_data(self, username). If it doesn't, that's something I think we can fix in HubAuth on the jupyterhub side without needing to re-identify the user a second time

self.current_user is only exposing basic information (not incl. auth_state) about the user because it makes use of get_current_user_token or get_current_user_cookie, right ?
Since it requires the requester to be a hub admin to get the user auth_state, we can't get this info from token or cookie.
I would propose to fetch the user model once and only when auth_enabled is True, and pass a user_model kwarg to repo providers (defaulting to None when auth_enabled is False). This proposition is here!
Maybe we could/should define a trait in the base binderhub.RepoProvider class.
Then, you could just write your configuration as follow:
from binderhub.repoproviders import GitLabRepoProvider
from traitlets import default

class AuthGitLabProvider(GitLabRepoProvider):
    def __init__(self, *args, user_model, **kwargs):
        self.access_token = user_model['auth_state']['access_token']
        super().__init__(*args, **kwargs)

    @default('git_credentials')
    def _default_git_credentials(self):
        if self.access_token:
            return r'username=oauth2\npassword={token}'.format(token=self.access_token)
        return ""

c.BinderHub.repo_providers = {'gl': AuthGitLabProvider}

@rprimet @minrk Do you think it's a good way to do ?

@adriendelsalle that looks good to me!

I would be happy to open a PR on your fork if you add me as a collaborator on it!

OK I just did, but I'm not sure if it would be valuable (what's the workflow?), maybe opening a PR on the main repo referencing this one would be better? Sorry for the naive question :-)

This pull request has been mentioned on Jupyter Community Forum. There might be relevant details there:
https://discourse.jupyter.org/t/private-gitlab-access-for-binderhub/504/9

Any chances, that we can get this merged?

Seems that I messed something up while trying to sync with the current master. Yet https://github.com/jupyterhub/binderhub/compare/master...rprimet:dynamic_credentials_for_repoproviders still seems to show the correct diff so I'm puzzled as to why...

Seems that I messed something up while trying to sync with the current master. Yet master...rprimet:dynamic_credentials_for_repoproviders still seems to show the correct diff so I'm puzzled as to why...

Did you rebased or merged ? only rebase :).
This should be fixed now, I pushed on your fork.

@adriendelsalle great thanks!

Is there anything else (e.g. tests) to do on this PR?

When will this be merged and available? I have a use case where users would want to share only with other people authorized on their repo.

Hey @minrk, could you please take a look at this again? :)


Error when build prod

When run npm run build --prod --environment prod i have this error:
[ERROR in : Unexpected value 'SatNativeDateModule in /xxx/xxx/xxx/xxxx/node_modules/saturn-datepicker/datetime/index.d.ts' imported by the module 'AppModule in /xxx/xxx/xxx/xxxx/src/app/app.module.ts'. Please add a @NgModule annotation.](url)
Can you help me?

Yeah. Use source code instead (two folders from /src). I know about this problem. I'm waiting for angular 6 and while ng-packagr will work with it.

Ok, copy datetime y datepicker folder to src, right?
Import SatNativeDateModule from this directory?
Thks for your support!

Yep


pr-dev: some fixes

Codecov Report

Merging #43 into dev will decrease coverage by 0.14%.
The diff coverage is 89.65%.

@@            Coverage Diff             @@
##              dev      #43      +/-   ##
==========================================
- Coverage   76.88%   76.73%   -0.15%
==========================================
  Files          22       22
  Lines         558      563       +5
==========================================
+ Hits          429      432       +3
- Misses        129      131       +2

Impacted Files
Coverage Δ

peon/src/comandline/comandline.py
0.00% <0.00%> (ø)

...ject/file/function_def/expression/returned_expr.py
94.44% <92.00%> (-5.56%)
:arrow_down:

peon/src/lint/report/report.py
90.47% <100.00%> (+1.00%)
:arrow_up:

Continue to review full report at Codecov.

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


Set voltageChart min y-value to 2V

As mentioned in #13  , voltages on meshtastic devices are typically 3.2-4.2V .  The range on the voltageChart y-axis from 0V to 5V reduced its usefulness as changes within the normal operating range of devices were more difficult to detect.
This patch changes the y-axis range to 2V to 5V. This will improve the resolution for the areas users care about.
Note that this change is more conservative than requested in #13  , as it attempts to take into account less typical voltage. A very drained battery might get around 2V, and 5V might be reported for a USB connection.
fixes #13

Sounds reasonable. Thanks!


Keep this object references to declaration

Pass the declaration object to function, which is passed from rework-plugin-function.
It includes source file path and url position information. Those are helper to rebase the path.

Merged and released as v1.1.0. Thanks!


LP v3.4.15 "lp user RussianRonin clear" issue

Whenever I clear my own perms for testing stuff, I still have access to all my perms until I reconnect to the server.
I use "/lp user RussianRonin clear" in game and I can still use all my owner perms unless I DC.
Same thing happens when I switchprimarygroup to owner. I need to reconnect to actually get my permissions.
Am I missing something here? Shouldn't it take effect immediately? Is there some caching mechanism in place?
I search for issues regarding to this and couldn't find any FAQ's or anything.
Please let me know if you need any other info.
List of other plugins:

Do you use luckperms.autoop?
Because this permission needs you to change the server/world, to apply.

I do and that must be the issue. Thanks for the quick response. Good to know.


Chore/test optimisations

coverage: 57.843% (+2.3%) from 55.592%
when pulling 82ac87aa3b76a6826484cb6832aeac6822e032dd on chore/test-optimisations
into 2fee4e842edd3904949091422a5f30182de8f43e on main.


Annotations reverse vertically and horizontally

All annotations are reverse vertically and horizontally in the viewer with vue-pdf (circles, squares, highlights, ...) but with pdfjs (https://mozilla.github.io/pdf.js/web/viewer.html) my pdf is ok.

No if you annotate a file and directly save it like that with "Preview" on macOSX, annotations are reverse vertically and horizontally, but just with use of vue-pdf. It is ok with https://mozilla.github.io/pdf.js/web/viewer.html.
I try another PDF editor : Xodo on my android phone, and it is the same problem with vue-pdf but it is ok with https://mozilla.github.io/pdf.js/web/viewer.html.
An idea ?

this issue requires further investigations, no idea at the moment.

I found the problem : I was no fixed height and width declared in style props. My pdf component is within a  element from Vuetify. The viewer was setted according to dimensions of parent element. I suppose pdf component is setted during dialog opening and doesn't wait the end of dialog opening transition to get the final width and height of viewport.


Fix linux extension + simplify rebuild condition

I merged and pulled these changes, and now the rustc task doesn't rebuild when lib.rs has been modified.

Let me take a look


Pre flight controller

After the process handler initialises we want to run some pre-flight checks before we start processing.

[ ] validate any settings parsed into the pre flight controller.
[x] run getinfo to check the daemon is responsive and get the daemons reported block height.
[x] run getblockcount to get the network block height
[x] create getblockcount RPC client method
[x] create getWalletInfo RPC client method
[ ] make sure the daemon is within x blocks of the network
[x] check the wallet is unlocked
[ ] return success or failure to the process handler and any data required.
[ ] data parsed back: balance
[ ] unit test coverage.

Elegantt data. What's this?

➤ Matt commented:
I propose we remove the validation from this ticket as we don't have to validate anything (everything comes from a config which is checked when we start the server)


Adui-7096/fix: fix description style in headers

Proposed Changes
https://coveord.atlassian.net/browse/ADUI-7096
With the new typekit, the style of the description in headers was too heavy.
Before:

After:

Potential Breaking Changes
None :thinking:
Acceptance Criteria

[ ] The proposed changes are covered by unit tests
[X] The potential breaking changes are clearly identified
[ ] README.md is adjusted to reflect the proposed changes (if relevant)

Looks good!
Why you will merge this branch to next? Is it part of a rebranding phase 2?

Yes, it's going in Next branch for a while, since we need to fix all the issues in admin-ui first :see_no_evil:
And i'm not sure if it's a phase 2 but it's for the new design of the admin :smile:
https://www.figma.com/file/JbXRfSOwdEuq3VJGpUyyiJ/Brand-Library?node-id=1%3A64


Section.find fails error loading data

Exception thrown and sensor not updated/loaded

Since when did you notice this? I did not check my logs in a while. Sometime after noon on October 2nd?
I had a rather high CPU usage for a few days and bdraco looked at a callgrind with these standing out:

</usr/local/lib/python3.11/site-packages/xbox/webapi/api/provider/people/init.py>
/config/custom_components/myenergy/sensor.py
and hassio updating addons

Yes I noticed the same high CPU and also temporarly disabled myenergy. I see now it's caused by a new website design... so I'll need to redo part of the reverse engineering.

should be fixed as of R2.0


Offline cameras showing as "On" in Home app

Describe The Bug:
On v0.5.37-alpha.1, my offline Wyzw cameras are showing as "On" in the Home app. On v0.5.36, my cameras would appear as "No Response" which is the expected behavior.
To Reproduce:
Upgrade to v0.5.37-alpha.1 and experience the issue. Downgrade and the issue is no longer present.
Expected behavior:
Inactive cameras should be listed as "No Response".
Logs:
N/A

Plugin Config:
            "name": "Wyze",
            "username": "XXX",
            "password": "XXX",
            "keyId": "XXX",
            "apiKey": "XXX",
            "mfaCode": "215739",
            "refreshInterval": 60000,
            "entryExitDelay": 30,
            "showAdvancedOptions": false,
            "logging": "none",
            "excludeMacAddress": false,
            "excludedeviceType": false,
            "platform": "WyzeSmartHome"

Screenshots:
N/A
Environment:

Plugin Version: v0.5.37-alpha.1
Homebridge Version: v1.6.1
Node.js Version: v18.17.1
NPM Version: 9.8.0
Operating System: Ubuntu 22.04.3 LTS

Good call. I will add this back.

Good call. I will add this back.

Thanks, please let me know once an update has been published.

Update has been published, but could break something else.

Just updated to alpha3 and it still does not behave as it's supposed to. Turning the cameras off via the Home app force a Homebridge restart. After Homebridge restarts, the offline cameras show as "On". Here are my logs:
[10/6/2023, 6:40:03 PM] [Wyze] Error: DeviceIsOffline
    at WyzeAPI._performRequest (/var/lib/homebridge/node_modules/homebridge-wyze-smart-home/src/wyze-api/src/index.js:130:13)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at WyzeAPI.request (/var/lib/homebridge/node_modules/homebridge-wyze-smart-home/src/wyze-api/src/index.js:79:14)
    at WyzeAPI.runAction (/var/lib/homebridge/node_modules/homebridge-wyze-smart-home/src/wyze-api/src/index.js:274:20)
    at WyzeAPI.cameraPrivacy (/var/lib/homebridge/node_modules/homebridge-wyze-smart-home/src/wyze-api/src/index.js:783:56)
[10/6/2023, 6:40:03 PM] [Wyze] Error, refreshing access token and trying again
[10/6/2023, 6:40:03 PM] [Wyze] /var/lib/homebridge/persist/wyze-bcaf8973-0f75-5341-abfd-8ea75d25cd96.json
[10/6/2023, 6:40:04 PM] [Wyze] Error, logLevel in and trying again
[10/6/2023, 6:40:04 PM] [Wyze] /var/lib/homebridge/persist/wyze-bcaf8973-0f75-5341-abfd-8ea75d25cd96.json
[10/6/2023, 6:40:04 PM] Error: DeviceIsOffline
    at WyzeAPI._performRequest (/var/lib/homebridge/node_modules/homebridge-wyze-smart-home/src/wyze-api/src/index.js:130:13)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at WyzeAPI.runAction (/var/lib/homebridge/node_modules/homebridge-wyze-smart-home/src/wyze-api/src/index.js:274:20)
    at WyzeAPI.cameraPrivacy (/var/lib/homebridge/node_modules/homebridge-wyze-smart-home/src/wyze-api/src/index.js:783:56)
[10/6/2023, 6:40:04 PM] Got SIGTERM, shutting down Homebridge...

https://github.com/jfarmer08/homebridge-wyze-smart-home/releases/tag/v0.5.37-alpha.3

I will look at this again.

https://github.com/jfarmer08/homebridge-wyze-smart-home/releases/tag/v0.5.37-alpha.4

Alpha.4 still has the issue.

Just updated to alpha.5 and the statuses are now correct, although when I try to activate an "Off" camera from the Home app, it still reboots Homebridge.

So odd, I dont have that issue, but i will keep looking. A lot has changed in the last few releases.

Here are my Homebridge logs when I try and turn on a camera which is offline:
[10/28/2023, 8:42:12 AM] [Wyze] Error: DeviceIsOffline
    at WyzeAPI._performRequest (/var/lib/homebridge/node_modules/homebridge-wyze-smart-home/src/wyze-api/src/index.js:131:13)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at WyzeAPI.request (/var/lib/homebridge/node_modules/homebridge-wyze-smart-home/src/wyze-api/src/index.js:80:14)
    at WyzeAPI.runAction (/var/lib/homebridge/node_modules/homebridge-wyze-smart-home/src/wyze-api/src/index.js:275:20)
    at WyzeAPI.cameraPrivacy (/var/lib/homebridge/node_modules/homebridge-wyze-smart-home/src/wyze-api/src/index.js:787:56)
[10/28/2023, 8:42:12 AM] [Wyze] Error, refreshing access token and trying again
[10/28/2023, 8:42:13 AM] [Wyze] Error, logLevel in and trying again
[10/28/2023, 8:42:13 AM] Error: DeviceIsOffline
    at WyzeAPI._performRequest (/var/lib/homebridge/node_modules/homebridge-wyze-smart-home/src/wyze-api/src/index.js:131:13)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at WyzeAPI.runAction (/var/lib/homebridge/node_modules/homebridge-wyze-smart-home/src/wyze-api/src/index.js:275:20)
    at WyzeAPI.cameraPrivacy (/var/lib/homebridge/node_modules/homebridge-wyze-smart-home/src/wyze-api/src/index.js:787:56)
[10/28/2023, 8:42:13 AM] Got SIGTERM, shutting down Homebridge...

@danfratamico  Can you check to make sure your camera is online before you try to turn it on?

@danfratamico Can you check to make sure your camera is online before you try to turn it on?

This is the reason for this submission. The cameras that are causing Homebridge to restart are Offline in the Wyze app. Matter of fact, they are in a box in my storage unit. Turning them On in the Home app should not cause Homebridge to restart. Maybe there is a way you can code the plugin to do nothing if the you receive a device offline reply from the Wyze API?

https://github.com/jfarmer08/homebridge-wyze-smart-home/releases/tag/v0.5.37-alpha.6

https://github.com/jfarmer08/homebridge-wyze-smart-home/releases/tag/v0.5.37-alpha.6

This update did the trick. No more Homebridge restarts, thanks!


Changed actors graphql, so include the data needed for the new list

Changed actors graphql

https://github.com/Energinet-DataHub/team-titans/issues/215

Codecov Report

Merging #1937 (40d2e75) into main (ca30e91) will increase coverage by 10.67%.
Report is 25 commits behind head on main.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             main    #1937       +/-   ##
===========================================
+ Coverage   15.99%   26.66%   +10.67%
===========================================
  Files          73       87       +14
  Lines        1757     2059      +302
  Branches      186        0      -186
===========================================
+ Hits          281      549      +268
- Misses       1466     1495       +29
- Partials       10       15        +5

see 23 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Debugging with Visual Studio causes very slow mouse response

This isn't really a bug per se, but when I try to debug this in visual studio, my mouse becomes very unresponsive until I hit a breakpoint and wait for a moment.

Yeah, I experience this sometimes too, which sucks. It is almost certainly because the message pump is suddenly left waiting for the workspacer process to response to an in-flight event, but it halts on a breakpoint, which lags mouse events for a while.
Not sure what the fix is for this, but it is annoying enough that I should really look into it.


Added Instances components

Components added:

InstancesTable
InstancesTableRow

This PR add 2 components related to instances, whose purpose is to render the informations about the users instances.

/deploy-staging

/undeploy-staging

/deploy-staging

/deploy-staging

/deploy-staging

/rebase


General Vision for CrankShaft

Write out the mission of CrankShaft to guide how we build everything - readme has most of it but lets condense/distill it.

Wrote MISSION.md


Split initialization results in duplicate declarations

When some variable subcripts are ready from a data file but other are initialized from a constant, usually as a shortcut override, SDEverywhere generates two declarations for the same array variable. For instance, in this model:
DimA: A1, A2 ~~|
DimB: B1, B2 ~~|

h[A1, DimB] = GET DIRECT DATA('e_data.csv', ',', 'A', 'B2') ~~|
h[A2, DimB] = 0 ~~|
i[DimA, DimB] = h[DimA, DimB] ~~|

INITIAL TIME = 1990 ~~|
FINAL TIME = 2050 ~~|
TIME STEP = 1 ~~|
SAVEPER = TIME STEP ~~|

h is initialized both from direct data as a lookup and from a constant. SDEverywhere generates two declarations:
Lookup* _h[2][2];
double _h[2][2];

All subscript range elements need to be set to a variable of the same type to collapse the C decl to a single declaration of a single type. To do this, convert constant elements to lookups over the entire x axis. A new test case along the lines shown above was added to directdata.mdl.
The h[A2, DimB] = 0 equation starts out as two separated const variables. A new function at the very end of the analysis stage checks for const vars with the same var name as data vars. The var type is changed to data and lookup points are added. Because the separated array vars now all have type "data", they result in a single lookup array decl.
In EquationGen, the present of the lookup points triggers special code generation, resulting in this code in initLookups:
for (size_t i = 0; i < 2; i++) {
  _h[1][i] = __new_lookup(2, /*copy=*/true, (double[]){ -1e+308, 0.0, 1e+308, 0.0 });;
}


self-hosting copy and instructions

in ' use Solid' self-hosting needs to be targetted at non developers and should not take a click away in order to be explained. Don't lead to GitHub page (too much developer-oriented). self host is an important part and text is very dev heavy, need an explanation

We initially decided Jackson would write this part once his Pod Server is ready to be used, but now that that's been postponed to some point in the future, it might indeed be good to add instructions for node-solid-server.


removeUrlParams

Codecov Report

Merging #31 into master will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #31   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           11        12    +1
  Lines          113       128   +15
  Branches        24        27    +3
=========================================
+ Hits           113       128   +15

Impacted Files
Coverage Δ

src/getUrlQuery.ts
100.00% <100.00%> (ø)

src/removeUrlParams.ts
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Is there a way to disable typeName being sent in every query?

Does urql support a addTypename: false type configuration like Apollo? Or maybe this can be achieved by setting cache to false?

No, there's no way to disable this. Like with Apollo the cache won't function correctly when this is disabled.
We might alter this in the future, or you'll even be able to customise it once "exchanges" (our version of Apollo's links but with more central power to affect the query pipeline) become available. I forgot whether the caching exchange performs this query transpilation for us right now, but this might be customisable in the future (if not in v0.3, then in v0.4)


Bump Typescript dependency.

Compiled ts-is-defined code is breaking certain builds because they cant find ts-tiny-invariant, I think because the Typescript version is old.
Related github issue: https://github.com/apollographql/apollo-server/issues/5505

Published this to npm.


No runs older than 24 hours found [CLI]

Description
Hi, I'm trying to clean up synced runs using the command line wandb sync --clean. I have old runs that have synced to the web app and finished more than 24 hours ago. However, I'm getting the message "No runs older than 24 hours found". Any ideas?
Wandb features
wandb sync --clean
How to reproduce

Saved wandb runs in custom folder, (setting dir keyword in wandb.init).
Navigate to folder containing wandb run-... folders.
Execute command wandb sync --clean ${pwd}
Error message is produced.

Environment

OS: Red Hat Enterprise Linux Server release 7.9
Environment: n/a
Python Version: 3.8.2

FYI, needed to navigate to parent directory and perform wandb sync --clean.


[flutter_tool] Make BotDetector context free

Description
Remove references to the context from the bot detector. Also move the bot detector out of utils.dart.
Tests
I added the following tests:
Fixed up bot_detector_test.dart
Breaking Change
Did any tests fail when you ran them? Please read [Handling breaking changes].

[x] No, no existing tests failed, so this is not a breaking change.

@jonahwilliams ping


build GTK icon caches for some packages

Motivation for this change

maia-icon-theme: 2016-09-16 -> 2018-02-24
paper-icon-theme: build GTK icon cache for Paper-Mono-Dark
efl: build GTK icon cache
gnome-themes-extra: build GTK icon cache
mate-icon-theme-faenza: build GTK icon cache
mate-themes: build GTK icon cache

Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Fits CONTRIBUTING.md.

@GrahamcOfBorg build maia-icon-theme paper-icon-theme enlightenment.efl gnome3.gnome-themes-extra mate.mate-icon-theme-faenza mate.mate-themes

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: maia-icon-theme, paper-icon-theme, enlightenment.efl, gnome3.gnome-themes-extra, mate.mate-icon-theme-faenza, mate.mate-themes
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on aarch64-linux (full log)
Attempted: gnome-themes-extra, maia-icon-theme, paper-icon-theme
Partial log (click to expand)
/nix/store/539p3diwgsf5bmzzpqgfwlnpsg43hjzy-gnome-themes-extra-3.28
/nix/store/94sg1q1sybg9q5035fil4g83ry9477qz-maia-icon-theme-2018-02-24
/nix/store/xg4cy1d92i4a18g8avlvk4yqg0k49wgi-paper-icon-theme-2018-06-24

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: gnome-themes-extra, maia-icon-theme, paper-icon-theme
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on aarch64-linux (full log)
Attempted: maia-icon-theme, paper-icon-theme, enlightenment.efl, gnome3.gnome-themes-extra, mate.mate-icon-theme-faenza, mate.mate-themes
Partial log (click to expand)
/nix/store/68pygvajxf0mnyll92cbznx4z91035c8-efl-1.21.1/bin/eo_debug: interpreter directive changed from "/bin/sh" to "/nix/store/017xymp5i03qzigafnfx7sgf6602gmzq-bash-4.4-p23/bin/sh"
/nix/store/68pygvajxf0mnyll92cbznx4z91035c8-efl-1.21.1/bin/eina-bench-cmp: interpreter directive changed from "/usr/bin/env python2" to "/nix/store/hwvbbmqyshry7q5r6qb612i12z8pgva9-python-2.7.15/bin/python2"
/nix/store/68pygvajxf0mnyll92cbznx4z91035c8-efl-1.21.1/lib/evas/utils/evas_generic_pdf_loader.libreoffice: interpreter directive changed from "/bin/sh" to "/nix/store/017xymp5i03qzigafnfx7sgf6602gmzq-bash-4.4-p23/bin/sh"
checking for references to /build in /nix/store/68pygvajxf0mnyll92cbznx4z91035c8-efl-1.21.1...
/nix/store/94sg1q1sybg9q5035fil4g83ry9477qz-maia-icon-theme-2018-02-24
/nix/store/xg4cy1d92i4a18g8avlvk4yqg0k49wgi-paper-icon-theme-2018-06-24
/nix/store/68pygvajxf0mnyll92cbznx4z91035c8-efl-1.21.1
/nix/store/539p3diwgsf5bmzzpqgfwlnpsg43hjzy-gnome-themes-extra-3.28
/nix/store/i60xil4bf5bfnfyqq25adzbp3myfm36d-mate-icon-theme-faenza-1.20.0
/nix/store/yx45v35k9awi90whhwz5x36ih51vribl-mate-themes-3.22.18

Success on x86_64-linux (full log)
Attempted: maia-icon-theme, paper-icon-theme, enlightenment.efl, gnome3.gnome-themes-extra, mate.mate-icon-theme-faenza, mate.mate-themes
Partial log (click to expand)
glibPreFixupPhase
hicolorPreFixupPhase
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/6ajyyvi3a61m3qqbvb8vlklpwcq773fa-maia-icon-theme-2018-02-24
strip is /nix/store/dxf1m7dhc4qb655bdljc1fsd74v1nag3-binutils-2.30/bin/strip
patching script interpreter paths in /nix/store/6ajyyvi3a61m3qqbvb8vlklpwcq773fa-maia-icon-theme-2018-02-24
checking for references to /build in /nix/store/6ajyyvi3a61m3qqbvb8vlklpwcq773fa-maia-icon-theme-2018-02-24...
gtk-update-icon-cache: Cache file created successfully.
gtk-update-icon-cache: Cache file created successfully.
postPatchMkspecs

Success on x86_64-linux (full log)
Attempted: gnome-themes-extra, maia-icon-theme, paper-icon-theme
Partial log (click to expand)
glibPreFixupPhase
hicolorPreFixupPhase
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/6ajyyvi3a61m3qqbvb8vlklpwcq773fa-maia-icon-theme-2018-02-24
strip is /nix/store/dxf1m7dhc4qb655bdljc1fsd74v1nag3-binutils-2.30/bin/strip
patching script interpreter paths in /nix/store/6ajyyvi3a61m3qqbvb8vlklpwcq773fa-maia-icon-theme-2018-02-24
checking for references to /build in /nix/store/6ajyyvi3a61m3qqbvb8vlklpwcq773fa-maia-icon-theme-2018-02-24...
gtk-update-icon-cache: Cache file created successfully.
gtk-update-icon-cache: Cache file created successfully.
postPatchMkspecs

Should we do this? Icon cache is supposed to be global state, see the discussion in https://github.com/NixOS/nixpkgs/pull/45058

Should we do this? Icon cache is supposed to be global state

@jtojnar I am not sure. But I am getting warnings with xfce4-appearance-settings with the icon themes that do not have a cache:

Currently for most icon theme packages the icon cache is created when the package is built. The exception is the hicolor icon theme, whose cache is built by nixpkgs/nixos/modules/config/system-path.nix. Some icon themes though  are missing a cache. The goal of this PR is to provide the cache for some of them.
As far as I know no other infra-structure is currently provided to build the icon caches.

This solution is commented on https://github.com/NixOS/nixpkgs/pull/27458, for instance.

As I think we concluded in the other PR, we actually want to build the icon cache both per-theme and globally, so this is also desirable.

I wonder if we could package this step up into a hook that could be added to buildInputs? That's probably a separate refactoring, though.

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: gnome-themes-extra, maia-icon-theme, paper-icon-theme
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Attempted: gnome-themes-extra, maia-icon-theme, paper-icon-theme
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/pzd4x2lbrzrv6kz7ydbg334c2vafq7sx-maia-icon-theme-2018-02-24
strip is /nix/store/vcc4svb8gy29g4pam2zja6llkbcwsyiq-binutils-2.30/bin/strip
patching script interpreter paths in /nix/store/pzd4x2lbrzrv6kz7ydbg334c2vafq7sx-maia-icon-theme-2018-02-24
checking for references to /build in /nix/store/pzd4x2lbrzrv6kz7ydbg334c2vafq7sx-maia-icon-theme-2018-02-24...
gtk-update-icon-cache: Cache file created successfully.
gtk-update-icon-cache: Cache file created successfully.
postPatchMkspecs
/nix/store/8r0gwk3m8f6sp14jyrawz8hdfl90ib8s-gnome-themes-extra-3.28
/nix/store/pzd4x2lbrzrv6kz7ydbg334c2vafq7sx-maia-icon-theme-2018-02-24
/nix/store/bnqbxylrxhwyghslrfhlp6iwlzk4rk5i-paper-icon-theme-2018-06-24

Success on aarch64-linux (full log)
Attempted: gnome-themes-extra, maia-icon-theme, paper-icon-theme
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/qg7bx0gz93pp44cs99prinrsh97msq68-gnome-themes-extra-3.28
shrinking /nix/store/qg7bx0gz93pp44cs99prinrsh97msq68-gnome-themes-extra-3.28/lib/gtk-2.0/2.10.0/engines/libadwaita.so
strip is /nix/store/p9akxn2sfy4wkhqdqa3li97pc6jaz3r1-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/qg7bx0gz93pp44cs99prinrsh97msq68-gnome-themes-extra-3.28/lib
patching script interpreter paths in /nix/store/qg7bx0gz93pp44cs99prinrsh97msq68-gnome-themes-extra-3.28
checking for references to /build in /nix/store/qg7bx0gz93pp44cs99prinrsh97msq68-gnome-themes-extra-3.28...
gtk-update-icon-cache: Cache file created successfully.
/nix/store/qg7bx0gz93pp44cs99prinrsh97msq68-gnome-themes-extra-3.28
/nix/store/sl4k4yy6mqz393vxnwyv31vxgjj6mf1r-maia-icon-theme-2018-02-24
/nix/store/4g31ny958anrknx264j51wcz79zcfbwa-paper-icon-theme-2018-06-24

Success on aarch64-linux (full log)
Attempted: maia-icon-theme, paper-icon-theme, enlightenment.efl, gnome3.gnome-themes-extra, mate.mate-icon-theme-faenza, mate.mate-themes
Partial log (click to expand)
/nix/store/j89hy89cbw1iqhrn5n65smb8shg2lnsl-efl-1.21.1/bin/eo_debug: interpreter directive changed from "/bin/sh" to "/nix/store/dsyc1z7ck08ga7l0b1jcxx35wj69qcii-bash-4.4-p23/bin/sh"
/nix/store/j89hy89cbw1iqhrn5n65smb8shg2lnsl-efl-1.21.1/bin/eina-bench-cmp: interpreter directive changed from "/usr/bin/env python2" to "/nix/store/74b1xd5srd6ja54xwznvbrd5hcfl6k1n-python-2.7.15/bin/python2"
/nix/store/j89hy89cbw1iqhrn5n65smb8shg2lnsl-efl-1.21.1/lib/evas/utils/evas_generic_pdf_loader.libreoffice: interpreter directive changed from "/bin/sh" to "/nix/store/dsyc1z7ck08ga7l0b1jcxx35wj69qcii-bash-4.4-p23/bin/sh"
checking for references to /build in /nix/store/j89hy89cbw1iqhrn5n65smb8shg2lnsl-efl-1.21.1...
/nix/store/sl4k4yy6mqz393vxnwyv31vxgjj6mf1r-maia-icon-theme-2018-02-24
/nix/store/4g31ny958anrknx264j51wcz79zcfbwa-paper-icon-theme-2018-06-24
/nix/store/j89hy89cbw1iqhrn5n65smb8shg2lnsl-efl-1.21.1
/nix/store/jpxca60yiwyfcma0fvyb7xm7a4c3d97i-gnome-themes-extra-3.28
/nix/store/bkfn0fc87yv66yd56bk9ic6ii91z13r9-mate-icon-theme-faenza-1.20.0
/nix/store/vxhnnrszy3yq4l0kj7ldpq15fm7zxjhl-mate-themes-3.22.18


Read Stata version 118 files closes #9882

closes #9882
This extends the Stata reader to handle version 118 (stata 14) format files.
It correctly handles the test file posted by @makmanalp.  I don't have stata14 now to generate additional test files, but I'm not sure that it's necessary.
There is one point I'm not sure about, relating to the way that strls are indexed by a weird composite of a short and a 6 byte integer.  The stata docs aren't clear on how this 8 byte composite should (or shouldn't) be byteswapped when the file and local endianness don't match.  We currently byteswap it in this case (inheriting from our dta117 code) but I'm not sure that this is correct.
I can confirm that it works when the file and local machine are both little endian, which covers the most common situation.
I haven't looked at the writer much, it seems to always write version 114 files.

I think you should create a class for each version
(which have a hierarchy) - introspect the file and dispatch to the class for processing
should be simpler to maintain

Having separate classes would work with read_stata but people also need to be able to create the class directly through init.  If someone inits the class with StataReader('myfile.dta') I don't see how we can control which subclass gets created.

easy, StataReader is just a holder of the work class, which is instantiated at run-time. e.g. something like
class StataReader(...):

    def __init__(self, file....):

           if file_is_117:
                 self.data = V117(....)
           elif file_is_118:
                 self.data = V118(....)
           else:
                 raise ValueError("cannot parse this file")

you would simply change the impl and call methods on the worker class, while the external API would remain the same. The big advantage would be that this would leave all of the existing classes parsed the same; adding something new should be straightforward and minimal changes.

I still don't get it.  StataReader is either used as an iterator, or the user calls the read or data methods to obtain some or all of the data as a DataFrame.  StataReader also has some additional methods and attributes like variable_labels whose implementation depends on the file version.  If there were subclasses for different dta versions it seems to me that we would need to monkey patch the subclass methods into the base class (since the caller will obtain an instance of the base class not the correct subclass that matches the data file format).  Also complicating matters is the fact that we have to read partway through the file before we know what the version is.

just trying to make it easier / more extensibile. It seems that every time this stata format changes this needs a big rewrite.

I agree that it is sort of a mess.  But the pieces that are version-specific are intertwined with code that works for all versions.  The format changes are substantial as well, so to some degree the complexity is unavoidable.

There is one point I'm not sure about, relating to the way that strls are indexed by a weird composite of a short and a 6 byte integer. The stata docs aren't clear on how this 8 byte composite should (or shouldn't) be byteswapped when the file and local endianness don't match. We currently byteswap it in this case (inheriting from our dta117 code) but I'm not sure that this is correct.

I don't think Stata runs on any big endian platforms, so the only tests that matter here are

Round trip on either
Generate on BE, read on LE
Generate on LE, read on BE

Nice work! Unfortunately, I don't have access to a big-endian computer :(

Is there a minimum Stata version that is supported?  Some of the format info seems to be for very old, untested versions.  This could be cleaned up.

@kshedden I put a couple of examples of some code sharing that I think can be done (rather than inheriting from base classes, you can do it this way as well). To reduce the future maitenance burden.

couple of minor comments. looks good though. after fix, pls squash. ping when green.

@jreback -- this should be all set to go now.

@kshedden thanks! great effort on this!

I think this can still use an update in the documentation? (where they mention which versions read_stata supports) And maybe also a whatsnew note?
@kshedden can you do that in another PR?

Ah, I see @jreback  already did the whatsnew :-)
But the docs can still use an update.

yes, @kshedden made add a note (or section) on compatiblity (e.g. what versions are supported) in io.rst

:cake: Thanks to all involved - this makes my life way easier!


dropdown menu

profile settings language dropdown menu white on google chrome

Just adding a screenshot to help clarify the issue.

👍
will fix in next release

There is a pre-release, if you want to test it

sure


[beta] Phone view not rendering on initial load of challenge.

Challenge use-the-css-transform-scale-property-to-change-the-size-of-an-element has an issue.
User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.
No image in the phone view upon initial load when not following the map linearly.  (I selected a lesson based on what I could use a refresher on.  I know the surrounding material.)

    ```

I'm confirming this for the D3 challenges.

This is fixed in beta


ADIv5: Fix a bunch of mistakes in ArmProbe::write

write has a number of mistakes, some of which are obvious at a glance, others got uncovered while trying #2171

start_extra_count can be 4 if aligned and should be <= len
end_extra_count and inbetween_count could underflow for short buffers
write_32 can return an error even if it gets an empty buffer (i.e. its data is too short and written entirely by the above write_8, and address ends up unaligned)
branch handling end_extra_count tried to write start_extra_count number of bytes

Reset this to draft, I want to add tests


Display Message When Report Approver Clicks Link in Report Approval Email But the Report is Already Approved

When there is more than one report approver in a report approval step, one of the report approvers may approve the report.  When another report approver clicks the link in the email, a blank screen is displayed.  The report approver is left wondering what happened to the report.
After a report is approved, if another report approver clicks on the report link in the email, a message should be displayed notifying the second report approver that the report has been approved.  The message should also display the name of the report approver who approved the report, the date and time the report was approved.
A message should also be displayed if another report approver rejected the report.  The message should state the report was rejected and returned to the report author by , and the date and the time the report was rejected.
Reference item 110

https://github.com/NCI-Agency/anet/issues/263 fixes this issue


creating a routine that returns the 3 types of image in the library when selecting one pickture

I needed to use the Image type and the File type of return in my app, but wanted that the user only picks the image once, so I created a method that return the tree methods of your library at once, only works when is choosing one pickture.

You can obtain the same result by using the method ImagePickerWeb.getImageAsFile() and creating your own method in your code.
class ImageAllTypes {
  ImageAllTypes(this.imageAsFile, this.imageAsImage, this.imageAsRaw);

  final Image? imageAsImage;
  final html.File? imageAsFile;
  final Uint8List? imageAsRaw;
}

Future<ImageAllTypes> getAllTypesOfImage() async {
  final file = await ImagePicker.getImageAsFile();
  final raw = await file?.asBytes();
  final image = raw != null
    ? Image.memory(await file.asBytes(), semanticLabel: file.name)
    : null;
  return ImageAllTypes(file, image, raw);
}

As you can see this kind of use case can be easily circumvented hence it is not needed to merge some new code for it. I will close this merge request as it would only cause to have some more code to maintain in the future while not needed.

Thanks for the Advice. I circumvented the code, and it Works just fine, just implementing the method asBites() in my code