Creating identities after keytocard

How do I add a new identity to the key once it has been moved to the yubikey (keytocard)?
I have two yubikeys and would like to add a new identity. The guide has adding identities after creating the sub keys but nothing explicitly (that i could find) about adding identities after the fact.
I am assuming I will need to start here as if I was renewing sub keys or rotating keys except I adduid instead?

I tried it on a spare key.
It works for one key, I wasn't able to try it for a second duplicate key.
After generating a key on the card (or on disk then keytocard) you can just:
gpg --edit-key @.***
gpg>     adduid
....
gpg> save
If you are following the procedure for duplicate keys, I believe you will
be out of luck as you wouldn't be able to add a second UID to the card.
When I added a new UID to my key I tried using some spare keys and couldn't
find a way.
I ended up rebuilding the key from scratch, adding comments to say what
fingerprint key replaced/replaces which key, and signing each key before
moving the key to card.
On Mon, 25 Jul 2022 at 03:38, Matthieu Robineau @.***>
wrote:

How do I add a new identity to the key once it has been moved to the
yubikey (keytocard)?
I have two yubikeys and would like to add a new identity. The guide has
adding identities after creating the sub keys but nothing explicitly (that
i could find) about adding identities after the fact.
I am assuming I will need to start here
https://github.com/drduh/YubiKey-Guide#setup-environment as if I was
renewing sub keys or rotating keys except I adduid instead?
—
Reply to this email directly, view it on GitHub
https://github.com/drduh/YubiKey-Guide/issues/337, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABU6FGIOLHEF2JP3NJY6IATVVX4ZFANCNFSM54QVJ4YA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

--
Ian Stanley
@.***

@iandstanley Thanks for your reply. Are you saying that I can't add new UIDs using the master key backup and then keytocard the master key (as if it was a new key setup) to each yubikey?
And secondly, is there a drawback to manually doing the gpg --edit-key on each card separately to add the UID?

If you are using the master key backup (the backup you made before you
keytocard) then effectively you are just rewinding the process back. You
should be able to keytocard twice to your two yubikeys (remembering to:
save after adding the uid &  quit after the first keytocard & save after
the second keytocard // or alternately restore the backup after the first
keytocard).
This should give you two yubikeys that both have the new uid.

I  /THINK/ that gnupg places the UIDs directly into the private key and/or
the public key and not in the subkeys on the card.  I suspect both as you
can recreate the stub from the public key WITH the yubikey using the fetch
subcommand. (I did wonder if just adding the key to the stub private key
and the public key would be sufficient as we have to re-export the public
key anyway ... but I am less familiar with the internals of the gnupg
program and exactly what it puts in what file on the disk)
You cannot run gpg  --edit-key on each card separately as the key stub
appears to keep the uids (I tested this and gnugp refuses to add it to with
the second key inserted as it was already on the stub). If you restored a
backup prior to the adduid before you ran keytocard the second time then I
guess it should be possible.
The whole process can be a bit messy with restoring backups between each
execution step.

As mentioned in the docs you will get the issue of switching duplicate
yubikeys as gnupg keeps a track of the last yubikey it ran keytocard on ...
making a note of it in the stub. You must force gpg-connect-agent to learn
which yubikey is inserted to prevent it from asking for the other yubikey
by serial number. See my script switch-to-backup-yubikey in the repo or the
relevant section of the guide. This will be required to be run each time
you switch between keys (for whatever reason)
On Tue, 26 Jul 2022 at 21:45, Matthieu Robineau @.***>
wrote:

@iandstanley https://github.com/iandstanley Thanks for your reply. Are
you saying that I can't add new UIDs using the master key backup and then
keytocard the master key (as if it was a new key setup) to each yubikey?
And secondly, is there a drawback to manually doing the gpg --edit-key on
each card separately to add the UID?
—
Reply to this email directly, view it on GitHub
https://github.com/drduh/YubiKey-Guide/issues/337#issuecomment-1195962870,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABU6FGMO44UFB2XQ2F3KJ5TVWBE6NANCNFSM54QVJ4YA
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Ian Stanley
@.***

Just to add a +1 to Ian's advice and hopefully give you a bit more confidence in the process, I had exactly this problem when my old GitHub email address leaked (I had dumbly started using -s on commits without realising the implications).
I jumped through the hoops of creating a replacement and let GitHub generate a "privacy enabled" email address, and then faced the problem of adding the new identities to my "built-alike" pair of YubiKeys.
I restored the backup snapshot taken immediately prior to my original key-to-card, added the new identities, took an updated backup snapshot, and did key-to-card on the first YubiKey.
I did a bit of testing to convince myself that everything was where it should be on the first YubiKey.
Then I restored the just-taken backup, and did key-to-card on the second YubiKey.
A bit more testing to assure myself that both YubiKeys were still "built-alike" and … job done!
I think the biggest hole you can dig for yourself with YubiKeys is either not taking a backup before the key-to-card process, or losing your backup. If anything, I think I'm more paranoid about making sure my encrypted backup is backed-up a few times, and that all the copies can make the round trip of restore + decryption.

Would there be a difference between using the master key backup to add the UID versus calling adduid on each yubikey (aside from the backup keeping the new UID)?
I don't know enough about GPG to know if this would change the secret key or public key in any meaningful way. As in, if both have the same new UID and I export the public keys to upload to github for example, would both yubikeys generate the same public key?

Can't say - but that's because I don't really understand the question.
This is a guess. If I'm wrong then, hopefully, other people who really do understand this stuff will chime in and correct me.
My understanding is that only the private keys live on the YubiKey, with the public keys living in ~/.gpg. The identities must be bonded into both. I think that's what you see when you run gpg -k and gpg -K.
I have never tried adduid directly "on" a YubiKey. I wouldn't even know where to start. But, assuming it was possible, it seems to me that all it would achieve is associating the new identity with the private keys on the YubiKey, leaving the older public keys untouched. That might be fixable but...
As noted before, I started by restoring the backup snapshot of my temporary GPG directory. Then, according to the notes I made at the time (January 2022), for each identity I wanted to add, it was:
$ KEYID=«yourKeyIDhere»
$ gpg --expert --edit-key $KEYID
…

gpg> adduid
Real name: «something»
Email address: «something@something»
Comment: «something»
You selected this USER-ID:
    "something (something) <something@something>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
…

gpg> trust
…
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
…
gpg> save
$

Next, I exported everything. I don't know whether every command below was totally necessary but I am always over-cautious when I really have no idea what I'm doing:
$ gpg --export --armor $KEYID > $KEYID.gpg.public.key
$ gpg --export-secret-keys --armor $KEYID > $KEYID.gpg.master.key
$ gpg --export-secret-subkeys --armor $KEYID > $KEYID.gpg.sub.key
$ gpg --output $KEYID.gpg.revocation-cert.asc --gen-revoke $KEYID

Then I took a revised backup snapshot.
As a way of proving that the revised backup snapshot was viable, I deleted everything, restored the snapshot, and ran gpg -k and gpg -K to convince myself that the identities I had just added were actually "there".
And then it was:

First YubiKey
$ gpg --edit-key $KEYID
gpg> key 1
gpg> keytocard
Your selection? 1
gpg> key 1
gpg> key 2
gpg> keytocard
Your selection? 2
gpg> key 2
gpg> key 3
gpg> keytocard
Your selection? 3
gpg> key 3
gpg> save
$

Some testing with the new key.

Restore backup again.

Second YubiKey - as for first YubiKey.

At this point I must've stopped taking notes (got lazy because I was on the home stretch - the things ye come to regret, huh?).
But I think I needed to upload the updated public key ($KEYID.gpg.public.key) to the key-server, and run around importing the updated public key on the various hosts where I actually use the YubiKeys.
The various steps above come with some faffing-about as you are prompted for passphrases and PINs but I guess you can cope with those as they arise.
Whether any of this answers your question or helps…

Oh and don’t do it late at night when you are tired - learnt that the hard way when I managed to create a key and mistype the passphrase not only the twice when I created the key but also twice when I ran key to card to two Yubikeys. That hurt my head trying to figure that one out.
As far as creating keys and backups go I create my keys on a pristine install of TailsOS with a protected partition. Once created I then get TailsOS to duplicate itself to two other usb drives. I also make a couple of encrypted archives on different media that I can store offsite.
After that I use one of them to keytocard my primary Yubikey, then I boot again off my primary TailsOS and re image the usb that I keytocard off before repeating the whole process again.
You always want multiple encrypted copies on different media of your original generated keys made before you do anything with a Yubikey as it is too easy to make mistakes when using more than one Yubikey and do things in the wrong order or using the wrong drive or backup.
Be careful, methodical and precise and even the difficult can be overcome.

On 27 Jul 2022, at 03:01, Phill @.***> wrote:

Can't say - but that's because I don't really understand the question.
This is a guess. If I'm wrong then, hopefully, other people who really do understand this stuff will chime in and correct me.
My understanding is that only the private keys live on the YubiKey, with the public keys living in ~/.gpg. The identities must be bonded into both. I think that's what you see when you run gpg -k and gpg -K.
I have never tried adduid directly "on" a YubiKey. I wouldn't even know where to start. But, assuming it was possible, it seems to me that all it would achieve is associating the new identity with the private keys on the YubiKey, leaving the older public keys untouched. That might be fixable but...
As noted before, I started by restoring the backup snapshot of my temporary GPG directory. Then, according to the notes I made at the time (January 2022), for each identity I wanted to add, it was:
$ KEYID=«yourKeyIDhere»
$ gpg --expert --edit-key $KEYID
…
gpg> adduid
Real name: «something»
Email address: @.»
Comment: «something»
You selected this USER-ID:
"something (something) @.>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
…
gpg> trust
…
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
…
gpg> save
$
Next, I exported everything. I don't know whether every command below was totally necessary but I am always over-cautious when I really have no idea what I'm doing:
$ gpg --export --armor $KEYID > $KEYID.gpg.public.key
$ gpg --export-secret-keys --armor $KEYID > $KEYID.gpg.master.key
$ gpg --export-secret-subkeys --armor $KEYID > $KEYID.gpg.sub.key
$ gpg --output $KEYID.gpg.revocation-cert.asc --gen-revoke $KEYID
Then I took a revised backup snapshot.
As a way of proving that the revised backup snapshot was viable, I deleted everything, restored the snapshot, and ran gpg -k and gpg -K to convince myself that the identities I had just added were actually "there".
And then it was:
First YubiKey
$ gpg --edit-key $KEYID
gpg> key 1
gpg> keytocard
Your selection? 1
gpg> key 1
gpg> key 2
gpg> keytocard
Your selection? 2
gpg> key 2
gpg> key 3
gpg> keytocard
Your selection? 3
gpg> key 3
gpg> save
$
Some testing with the new key.
Restore backup again.
Second YubiKey - as for first YubiKey.
At this point I must've stopped taking notes (got lazy because I was on the home stretch - the things ye come to regret, huh?).
But I think I needed to upload the updated public key ($KEYID.gpg.public.key) to the key-server, and run around importing the updated public key on the various hosts where I actually use the YubiKeys.
The various steps above come with some faffing-about as you are prompted for passphrases and PINs but I guess you can cope with those as they arise.
Whether any of this answers your question or helps…
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.

As an aside because we are talking about backups
Did you know that the email address used for a GPG key doesn’t have to be a valid email address. By that I mean the domain name doesn’t have to be a valid domain name. You can enter an “email address” of @.*** without a TLD. I have a separate key for encrypting backups. I create my backups and encrypt them both to my main GPG key associated with my email address AND ALSO the fake email address (say @.***) that way I have two ways to restore my backups particularly useful if I have to replace my key for some reason and don’t think to keep a copy of the old key around for restoring backups.
Did you guys know that GNUPG ships with a version of gnu tar that uses GPG (see man gpgtar).
If you need to go the other way and make sure that you can only decrypt a backup on the device it was made on then you can create a GPG key and store it on a TPM using the keytotpm subcommand in —edit-key. This can be useful in some instances.

On 27 Jul 2022, at 03:01, Phill @.***> wrote:

Can't say - but that's because I don't really understand the question.
This is a guess. If I'm wrong then, hopefully, other people who really do understand this stuff will chime in and correct me.
My understanding is that only the private keys live on the YubiKey, with the public keys living in ~/.gpg. The identities must be bonded into both. I think that's what you see when you run gpg -k and gpg -K.
I have never tried adduid directly "on" a YubiKey. I wouldn't even know where to start. But, assuming it was possible, it seems to me that all it would achieve is associating the new identity with the private keys on the YubiKey, leaving the older public keys untouched. That might be fixable but...
As noted before, I started by restoring the backup snapshot of my temporary GPG directory. Then, according to the notes I made at the time (January 2022), for each identity I wanted to add, it was:
$ KEYID=«yourKeyIDhere»
$ gpg --expert --edit-key $KEYID
…
gpg> adduid
Real name: «something»
Email address: @.»
Comment: «something»
You selected this USER-ID:
"something (something) @.>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
…
gpg> trust
…
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
…
gpg> save
$
Next, I exported everything. I don't know whether every command below was totally necessary but I am always over-cautious when I really have no idea what I'm doing:
$ gpg --export --armor $KEYID > $KEYID.gpg.public.key
$ gpg --export-secret-keys --armor $KEYID > $KEYID.gpg.master.key
$ gpg --export-secret-subkeys --armor $KEYID > $KEYID.gpg.sub.key
$ gpg --output $KEYID.gpg.revocation-cert.asc --gen-revoke $KEYID
Then I took a revised backup snapshot.
As a way of proving that the revised backup snapshot was viable, I deleted everything, restored the snapshot, and ran gpg -k and gpg -K to convince myself that the identities I had just added were actually "there".
And then it was:
First YubiKey
$ gpg --edit-key $KEYID
gpg> key 1
gpg> keytocard
Your selection? 1
gpg> key 1
gpg> key 2
gpg> keytocard
Your selection? 2
gpg> key 2
gpg> key 3
gpg> keytocard
Your selection? 3
gpg> key 3
gpg> save
$
Some testing with the new key.
Restore backup again.
Second YubiKey - as for first YubiKey.
At this point I must've stopped taking notes (got lazy because I was on the home stretch - the things ye come to regret, huh?).
But I think I needed to upload the updated public key ($KEYID.gpg.public.key) to the key-server, and run around importing the updated public key on the various hosts where I actually use the YubiKeys.
The various steps above come with some faffing-about as you are prompted for passphrases and PINs but I guess you can cope with those as they arise.
Whether any of this answers your question or helps…
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.

Thanks for the responses all. I will close this ticket as answered.


Fix unbalanced bold for /clr option

@sebgod : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Doesn't work with dollar sign $

I tried vue and v-dollar, both of them didn't work.
AutoImport({
    dts: './src/auto-imports.d.ts',
    imports: [
      'vue',
      {
        'vue': [
          ['unref', '$'],
        ],
      },
    ],
  }),

AutoImport({
    dts: './src/auto-imports.d.ts',
    imports: [
      'vue',
      {
        'v-dollar': [
          '$',
        ],
      },
    ],
  }),

Fixed in latest version


Sometimes subtitles are missing in streaming

I tried in several fansubs and animes, sometimes there's a subtitle problem, i don't know if it's not loading cause lack of my internet speed or server issues but i want to report it.
*I'm using the appimage version 4.2

i solved the problem, it's about dependencies i ignored :)


Configuring account creation

When trying to create an an account in our new CDLT installation, we are greeted by the login screen:

When trying to press the button, we are redirected to lescommunes.org but get an error:

Presumably, this makes sense since our new deployment isn't authorized to authenticate with lescommunes.org. Would be correct to assume that we must configure an OIDC provider for the app the work?
This should probably be expanded in the deployment instructions.

Hi Matan
I sent you the password by email, and added your server in the list of valid redirection URL.
I also added a sentence about valid URLs in the deployment instructions: https://github.com/chemins-de-la-transition/semapps/commit/38ef6ef50626dfe2a89d39e162d567abb87b1089

Thanks @srosset81, it works now. FWIW the sentence added to the docs still seems confusing, because it seems to imply something needs to be done in the semapps deployment, when in fact it needs to be done on the end of the OIDC provider.


Added assertIs type assertion

Just added an assertion to validate the type of an expression.

Can one of the admins verify this patch? (see README)

This looks useful to me. If there are no objections and noone beats me too it, I'll merge it in a couple days.

Pushed manually. Thanks @someth2say!


Isue with Makefile

Hi there,
any many greetings from the Open Source Ventilator project!
I have tried to integrate available code with UnixHostDuino but get this error:
 make: *** No rule to make target 'OpenSoftwareVentilator.ino', needed by 'OpenSoftwareVentilator.o'.  Stop.
Code:
https://github.com/covid-supplies/Open-Source-Ventilator/blob/master/Dockerfile

Hi,
The first problem is that your Makefile contains
APP_NAME := OpenSoftwareVentilato

instead of
APP_NAME := OpenSourceVentilator

But even if you fix that typo, UnixHostDuino will not work for your project, because UnixHostDuino is not meant to support all (many?) Arduino programs. There are a lot of hardware dependent code that won't compile on a Unix machine. One of the first things that I hit was SPI.h, which pulls in hardware dependent parameters like F_CPU, SPIF, SPE, MSTR, SREG, SPSR, noInterrupts()`, and so on. I don't even know what most of those parameters are.
If you are looking to build for continuous integration, you might find one of my other projects helpful, https://github.com/bxparks/AUniter, but I'm not sure if that will meet your needs.

I'm going to close this if you have no further questions.


test: add e2e tests for wallet pages

Adds E2E tests for the wallet pages and include some minor changes.
Changes

Prefixed wallet routes with /wallet
Fixed failing E2E tests for messages after latest UI changes

What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Refactor
[ ] Performance
[x] Tests
[ ] Build
[ ] Documentation
[ ] Code style update
[ ] Continuous Integration
[ ] Other, please describe:

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Does this PR release a new version?

[ ] Yes
[x] No

If yes, please describe the impact and migration path for existing applications:
The PR fulfills these requirements:

[ ] It's submitted to the develop branch, not the master branch
[x] All tests are passing
[ ] New/updated tests are included

If adding a new feature, the PR's description includes:

[ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Codecov Report

Merging #26 into master will not change coverage.
The diff coverage is 0%.

@@          Coverage Diff           @@
##           master     #26   +/-   ##
======================================
  Coverage    36.9%   36.9%
======================================
  Files           6       6
  Lines          84      84
  Branches        3       3
======================================
  Hits           31      31
  Misses         53      53

Impacted Files
Coverage Δ

src/router.ts
0% <0%> (ø)
: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 55690e7...26bd395. Read the comment docs.


Update create-linked-servers-sql-server-database-engine.md to clarify…

… that contained database users cannot be used as local logins as this does not appear to be documented elsewhere.

Thanks @martinbherbener for contributing to our product documentation!
It could take from a few business days to a few weeks to confirm your change internally. We'll contact you if we need further information, and you'll receive an email message each time we "@mention" you in a comment.

@WilliamDAssafMSFT
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Thanks @martinbherbener for taking the time to submit this PR! Good catch. Your commit will be merged and this article update is in flight. After the updated article is published, GitHub will list you as an article contributor.
Thanks again for this feedback, your suggestions help improve our documentation.
#sign-off


Allow resizing String's from GDExtension

This adds a new function to gdextension_interface.h to allow us to implement String::resize() in godot-cpp per issue https://github.com/godotengine/godot-cpp/issues/1141
This is added to gdextension_inteface.h rather than ClassDB, because we don't want scripting to have access to it. String::resize() only makes sense if you can access String::ptrw() and directly modify the data at the pointer, which would be impossible from GDScript.
This originally came up when trying to compile the text_server_adv module in Godot as a GDExtension. See: https://github.com/godotengine/godot/pull/77532

This is added to gdextension_inteface.h rather than ClassDB, because we don't want scripting to have access to it.

Why? It's exposed for the Arrays, what's the difference, String have writable [] operator exposed, which is the same as ptrw() ?

Why? It's exposed for the Arrays, what's the difference, String have writable [] operator exposed, which is the same as ptrw() ?

Ah, that's a good point!
When I get a chance, I'll make a new PR that exposes it normally...

I've open PR https://github.com/godotengine/godot/pull/79177 which exposes String.resize() the normal way.
Given that String.resize() takes the desired array size of the string (ie. including the null terminator), I'm now less sure that we really want this exposed to GDScript, at least without some additional changes to make it more user-friendly. (Some possible options listed over on the other PR.)

As discussed in #79177 this seems to be the better way to handle this, assuming it doesn't suffer from the same mutability issues

Discussed at the GDExtension meeting, and we think it makes sense to add this, however, it would be good to add some additional warnings in the documentation about this being a potentially dangerous operation.

it would be good to add some additional warnings in the documentation about this being a potentially dangerous operation.

Do you mean the online documentation? Or is there something you still want to add to the class references (and therefore need to update this PR)?

Do you mean the online documentation?

We were talking about the docs in the comments in gdextension_interface.h. I've already done a push since the meeting that adds this:
 * Warning: This is an error-prone operation - only use it if there's no other
 * efficient way to accomplish your goal.

Thanks!


Dockerhub image latest-tensorflow and sklearn

Rasa NLU version: latest-tensorflow and 0.13.7-spacy (both pulled from Docker hub on 15 November 2018)
Operating system: Ubuntu 18.04
Content of model configuration file: default for latest-tensorflow and 0.13.7-spacy
Issue: I'm trying to test latest-tensorflow. When training and sending requests to the container 0.13.7-spacy it responds like it should. If I change my code such that it communicates with latest-tensorflow it fails on training. The response is:
{'error': 'Not all required packages are installed. To use this pipeline, you need to install the missing dependencies. Please install sklearn'}
I've done some further research, which might be useful: The Docker on Github clearly installs alt_requirements/requirements_tensorflow_sklearn.txt including sklearn. According to: https://github.com/RasaHQ/rasa_nlu/issues/1315 it might be caused by missing scipy package. scipy is not included in requirements_tensorflow_sklearn.txt or requirements_bar. It is included for requirements_spacy_sklearn.txt.

#1534


Backport #6971 to release-2.17

storage: Removed SelectSorted method; Simplified interface; Added requirement for remote read to sort response.
This is technically BREAKING CHANGE, but it was like this from the beginning: I just notice that we rely in
Prometheus on remote read being sorted. This is because we use selected data from remote reads in MergeSeriesSet
which rely on sorting.
I found during work on https://github.com/prometheus/prometheus/pull/5882 that
we do so many repetitions because of this, for not good reason. I think
I found a good balance between convenience and readability with just one method.
Smaller the interface = better.
Also I don't know what TestSelectSorted was testing, but now it's testing sorting.
Signed-off-by: Bartlomiej Plotka<EMAIL_ADDRESS>

The goal is to fix #6967

/prombench v2.17.0-rc.3

Ooof, that's quite a change… @roidelapluie I guess you have already thought carefully about the tradeoff here to pull thin into the 2.17 release.
@bwplotka you should do the actual code review. I have nothing to object here, I just don't feel qualify to vet the risk.

Ooof, that's quite a change… @roidelapluie I guess you have already thought carefully about the tradeoff here to pull thin into the 2.17 release.
@bwplotka you should do the actual code review. I have nothing to object here, I just don't feel qualify to vet the risk.

So, in short I'd better have this in 2.17.0 than changing the behavior in between 2.17.0 and a 2.17.1. It looks like this is a pretty important regression for remote read users.

So, I think that this regression in 2.16.0 is really big and that's why I want it.

#6971 is a refactoring, it shouldn't be changing any logic.

#6971 is a refactoring, it shouldn't be changing any logic.

I changes sorting on remote read, as per the commit comment.

The commit description is incorrect, it doesn't change that.

What exactly is the bug that this is supposed to be fixing?

What exactly is the bug that this is supposed to be fixing?

#6967

What exactly is the bug that this is supposed to be fixing?

See https://github.com/prometheus/prometheus/issues/6967#issuecomment-600197799 for the details

I don't thing we changed anything. Sorry for misleading commit comment. We only assured that on API level by commenting proto method. ):
Sorry for confusion and thanks Julien for the work.

This is when we iterate on PR description but never change commit description ):

Hm, ok so actually I fixed something by this? Still cannot see the exact place that is fixing the issue. Can you point to exact code line?

https://github.com/prometheus/prometheus/blob/release-2.16/storage/remote/read.go#L127-L134
look at that Select method: when SelectSorted was added, SelectSorted was not added to that file
so when you call Select Sorted on remote read, we do not remove the external labels


go cross references are missing

Since the last run of the uniprot parser, the go_cross_references are missing. There probably was a change in the uniprot data format.
Original issue by @bmesuere on Wed Sep 17 2014 at 10:02.
Closed by @ninewise on Tue Jan 20 2015 at 15:15.

I searched around in the uniprot_sprot.xml file, I suppose the followwing means the type is now "GO" in stead of "Go"?
 $ cat uniprot_sprot.xml | grep 'dbReference' | grep 'type="Go"' | head
 $ cat uniprot_sprot.xml | grep 'dbReference' | grep 'type="GO"' | head
  <dbReference id="GO:0033644" type="GO">
  <dbReference id="GO:0016021" type="GO">
  <dbReference id="GO:0005737" type="GO">
  <dbReference id="GO:0030659" type="GO">
  <dbReference id="GO:0005829" type="GO">
  <dbReference id="GO:0005576" type="GO">
  <dbReference id="GO:0005634" type="GO">
  <dbReference id="GO:0051219" type="GO">
  <dbReference id="GO:0005515" type="GO">
  <dbReference id="GO:0019901" type="GO">

I'll change this for now, kindly let me know if there are not the actual go_cross_references.
Original comment by @ninewise on Wed Oct 29 2014 at 22:12.

yes indeed. For example, at http://www.uniprot.org/uniprot/H0F9I0, you can see the GO terms under the function header.
Original comment by @bmesuere on Thu Oct 30 2014 at 09:57.


Wait for jobs to complete

Any chance you will implement waiting for jobs as commented here? It would be really useful.

We are using Helm and utilize its hooks functionality (
https://github.com/helm/helm/blob/master/docs/charts_hooks.md)  for jobs
that need to be run before pods.
But this functionality seems like to be easy to add. So, we'll  implement
it some time soon.
On Tue, Jun 4, 2019, 23:06 Guido García<EMAIL_ADDRESS>wrote:

Any chance you will implement waiting for jobs as commented here
https://github.com/Opsfleet/depends-on/blob/master/src/depends-on.go#L58?
It would be really useful.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Opsfleet/depends-on/issues/3?email_source=notifications&email_token=AAWJGWGZQNALAHMAIV65PA3PY3DL3A5CNFSM4HTBATSKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GXTYSAA,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWJGWBWCWAAX6OUFS6KAK3PY3DL3ANCNFSM4HTBATSA
.


Merge dev into master (Nov. & Dec. 2016)

It has been about two months, so this is probably overdue. The rover can now drive using joystick control from the web ui.
List of changes:

Added DriveProcess.
Added USBServer which forwards rover messages to USB serial devices
VESC serial communication implementation with cython ( you will have to compile the cython stuff for your own computer to use the USB server)
Added a simple test facility.

Should we add compiled library objects for the cython VESC library? Currently in order to run the USB server, you have to run the cython script to compile the library, which isn't very obvious or intuitive. This means adding binary files to the git repo however, which might be annoying later.


Add capturing checks publisher, make publishChecks withChecksName aware

Addresses #54

Is there a way to shift this code into the checks-api-tests.jar to neaten up the production jar?

Is there a way to shift this code into the checks-api-tests.jar to neaten up the production jar?

Do we have any other places that need it?

Is there a way to shift this code into the checks-api-tests.jar to neaten up the production jar?

There's a few plugins that ship jars for this under the classifier 'tests' jcasc used to, and some of the pipeline ones do, search the bom for the tests classifier: https://github.com/jenkinsci/bom

Is there a way to shift this code into the checks-api-tests.jar to neaten up the production jar?

Yes, just move the code to the tests folder and add an inclusion to the pom, see example. Custom assertions are already picked up by the test jar.

Is there a way to shift this code into the checks-api-tests.jar to neaten up the production jar?

Do we have any other places that need it?

It's only needed in tests, but it will be useful for testing in the consumers (I'm adding some details to consumers-guide.md) such as junit, where I originally added this. I was going to add support to withChecks to some of the other consumers but realised it would be a lot easier with this!

New mystery - why is the Windows build hanging between reporting integration test results and running the run-revapi step...

New mystery - why is the Windows build hanging between reporting integration test results and running the run-revapi step...

Not a big deal, there are always some problems with the windows build on our community ci (due to resources and so on); normally I only take a look at the github builds and the linux build on the community server.

oops, just found that after fetching the master. Shouldn't we put the CapturingChecksPublisher in the test packages instead of creating a new test package under API package?


Remove request queue

What this PR does / why we need it:
The PR removes the virtctl and REST API endpoints for add/removeInterface. Hotplug/unplug of an interface should be done by updating the VM spec template.
To hotplug - an interface and network should be added to the VM spec template.
To unplug the exiting interface should be marked with Absent state.
NOTE: Hotplug/unplug is supported for interfaces with bridge binding only.  Adding an interface with any other binding will be applied only after VM restart.
Updating an existing interface is not supported as well, any update will be applied only after a VM restart.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
The PR is rebased on top of https://github.com/kubevirt/kubevirt/pull/9896.
Release note:

Hoyplug/unplug interfaces should be done by updating the VM spec template. virtctl and REST API endpoints were removed.

/test pull-kubevirt-e2e-k8s-1.26-sig-network-multus-v4
/test pull-kubevirt-e2e-k8s-1.26-sig-network
/test pull-kubevirt-build
/test pull-kubevirt-build-arm64
/test pull-kubevirt-generate
/test pull-kubevirt-manifests
/test pull-kubevirt-unit-test

/test pull-kubevirt-e2e-k8s-1.26-sig-network-multus-v4
/test pull-kubevirt-e2e-k8s-1.26-sig-network
/test pull-kubevirt-build
/test pull-kubevirt-build-arm64
/test pull-kubevirt-generate
/test pull-kubevirt-manifests
/test pull-kubevirt-unit-test

rebase

/test pull-kubevirt-e2e-k8s-1.26-sig-network-multus-v4
/test pull-kubevirt-e2e-k8s-1.26-sig-network
/test pull-kubevirt-build
/test pull-kubevirt-build-arm64
/test pull-kubevirt-generate
/test pull-kubevirt-manifests
/test pull-kubevirt-unit-test

/test pull-kubevirt-e2e-k8s-1.26-sig-network-multus-v4
/test pull-kubevirt-e2e-k8s-1.26-sig-network

It looks very simple and neat. Thanks!
My only overall suggestion is consider adding unit tests to the VM controller logic. You could extract the logic to the network file and leave in the controller method only the call to it and the patching.

We should have a separate PR extracting the networking logic.

/test pull-kubevirt-e2e-k8s-1.26-sig-network-multus-v4
/test pull-kubevirt-e2e-k8s-1.26-sig-network

/test pull-kubevirt-e2e-k8s-1.26-sig-network-multus-v4
/test pull-kubevirt-e2e-k8s-1.26-sig-network

/test pull-kubevirt-e2e-k8s-1.26-sig-network-multus-v4

/assign

Raising
/approve


Number of Parameters

Hi, what is the total number of parameters in your models?

Hi, the params are listed as follows.

imTED+Faster RCNN+ViT-S: 30.3M
imTED+Faster RCNN+ViT-B: 123M
imTED+Faster RCNN+ViT-L: 346M
imTED+Mask RCNN+ViT-S: 32.9M
imTED+Mask RCNN+ViT-B: 125M
imTED+Mask RCNN+ViT-L: 349M

Closed due to inactivity. Feel free to reopen it if necessary.


Contributing to the "development" branch

Update readme.md and contributing.md file to mention that all PR has to be made on the DEVELOPMENT branch of the repo. This is a very important thing so this point should be highlighted and should be noticed easily by the reader.

please assign this task to me.....


[BUG] SR-IOV filter button overlaps the filter list in vGPU devices page

Version
v1.3.0
Describe the bug

The Parent SR-IOV filter button overlaps the filter list in vGpu devices page; we should investigate the issue is specific or it affects other buttons in the UI.
To Reproduce
Steps to reproduce the behavior:

Go to Advanced -> vGPU devices tab
Click on 'Filter By Parent SR-IOV' filter on top -right side of the page.

Expected behavior

The filter's list should be displayed correctly
Additional context
Add any other context about the problem here.

@torchiaf I checked this on v1.4.0-rc2 and still see an overlap.
Am I checking this correctly  ?

@a110605  can you please check my above comment ?

checked this in v1.4.0-rc4 and still see the overlap. @a110605  @torchiaf  can you please check this ?

@rrajendran17 I'm testing the 1.4 version. Updates ASAP.

Thanks @torchiaf.you can use <IP_ADDRESS> if you want.It has v1.4.0-rc4 installed.

@torchiaf  @a110605 I am moving it to "Implement" for now.Please feel free to move it back to "Ready to Testing" if you feel its fixed already.

Hi @rrajendran17, the filter option position in your screenshot is correct.
You can carefully compare the screenshots in this issue description.
The filter options should OVERLAY on the Filter by parent SR-IOV GPU box.
See the screenshot in fixed PR: https://github.com/harvester/dashboard/pull/1033
cc @torchiaf

@a110605 Thanks for the clarification,as it works as expected closing this.


[BUG]: Unable to access RelationalQueryBuilder type

What version of drizzle-orm are you using?
0.28.6
What version of drizzle-kit are you using?
No response
Describe the Bug
Attempting to import RelationalQueryBuilder to do generic relational querying. It appears that (at least for pg-core, possibly for other drivers as well) that the query-builders/query.d.ts declaration file isn't exported in that folders' barrel file and therefore cannot be imported.
Have also attempted to import from the file relatively but as is usually the case doing this most tsconfigs won't be setup to support it and ran into issues.
Expected behavior
No response
Environment & setup
No response

I've seen that in many cases the internal types might not be needed. Can you share an example where these types would help you construct a generic type that wouldn't be possible without them?

I have a function that builds out standard queries across each of my tables with specific filters and (more crucially) external authorization logic applied to relational queries. I'm building this so that the query can be used by either a client directly or within a transaction hence I do not have the exact executing client instance until the time when the function is called.
For the parameters of the generic function I have managed to rebuild the type of the real findFirst and findMany parameters manually however this then completely divorces these types from the actual function params making them either a) not usable in a call to the real function due to inherent overrides of findFirst and findMany from different client types from or b) not type safe (if forcing use with real function with say any).
Trying to call these again gives a type error due to the inferred override from the union of different client types. For example here is an example of the query factory function with relevant types:
import {
  DBQueryConfig,
  ExtractTablesWithRelations,
  KnownKeysOnly,
  Table,
  TablesRelationalConfig,
} from 'drizzle-orm';
import { PgDatabase } from 'drizzle-orm/pg-core';

export type FindFirstArgs<
  T extends Table,
  FS extends Record<string, unknown> = Record<string, never>,
  S extends TablesRelationalConfig = ExtractTablesWithRelations<FS>,
> = KnownKeysOnly<
  any,
  Omit<DBQueryConfig<'many', true, S, S[T['_']['name']]>, 'limit'>
>;

export type FindManyArgs<
  T extends Table,
  FS extends Record<string, unknown> = Record<string, never>,
  S extends TablesRelationalConfig = ExtractTablesWithRelations<FS>,
> = KnownKeysOnly<any, DBQueryConfig<'many', true, S, S[T['_']['name']]>>;

export const createModelPgFindFirstQuery = <
  C extends PgDatabase<any, Exclude<FS, Record<string, never>>>,
  T extends Table,
  AM extends Record<string, any>,
  FM extends Record<string, any>,
  FS extends Record<string, unknown> = Record<string, never>,
>(
  tableRef: keyof C['query'],
  authzFn: (args: FindFirstArgs<T, FS>, meta?: AM) => Promise<boolean>,
  argsFilter?: (args: FindFirstArgs<T, FS>, meta?: FM) => FindFirstArgs<T, FS>,
) => {
  return async (
    dbClient: C,
    queryArgs: FindFirstArgs<T, FS>,
    authzMeta?: AM,
    filterMeta?: FM,
  ) => {
    // ... Apply filter
    const queryRef = dbClient.query[tableRef] as C['query'][typeof tableRef];
    const data = await queryRef.findFirst(queryArgs);
    // ... Authz logic
  };
};

There is also the situation where I want to return a PgRelationalQuery (which I don't need at the moment but will almost certainly need in the near future) I run into the dreaded The inferred typeof 'X' cannot be named without a reference to 'Y'. This is likely not portable. A type annotation is necessary. because the reference file is not exported.
Essentially while it may be possible to work around this for some cases it makes it unnecessarily difficult and in other cases I don't see how this is possible.
Is there an issue with having these types exposed? It appears that all other internal types in this folder are already exposed and it doesn't look like there are name conflicts.

Is there an issue with having these types exposed?

I don't think so, I'm just trying to understand the issue and use-case and maybe offer a workaround.
I'll look into this later in the day and let you know.

Do the clients (or transaction objects) that you plan to pass to the resulting function have a different schema? I believe, you could start by not having the function be generic over the client as a first step in simplifying this. If you are interested, open a help thread in the discord server to discuss more and see if we can come up with a workaround.
If you assume the schema won't change, you can have the following factory function (No internal types needed, only TS magic):
import { AnyPgTable } from "drizzle-orm/pg-core";
import { db } from "./pg/pg";
import type * as schema from "./pg/schema";
import { eq } from "drizzle-orm";
import { users } from "./mysql/schema";

type ExtractTables<T extends Record<string, any>> = {
	[K in keyof T as T[K] extends AnyPgTable
		? K
		: never]: T[K] extends AnyPgTable ? T[K] : never;
};

type DB = typeof db;

type Schema = typeof schema;

type TableName = keyof DB["query"];

type SchemaTables = ExtractTables<Schema>;

type FindFirstArg<T extends keyof SchemaTables> = Parameters<
	DB["query"][T]["findFirst"]
>[0];

export const createModelPgFindFirstQuery = <
	ttable extends TableName,
	AM extends Record<string, any>,
	FM extends Record<string, any>,
>(
	tableRef: ttable,
	_authzFn: (args: FindFirstArg<ttable>, meta?: AM) => Promise<boolean>,
	_argsFilter?: (
		args: FindFirstArg<ttable>,
		meta?: FM,
	) => FindFirstArg<ttable>,
) => {
	return async (
		dbClient: DB,
		queryArgs?: FindFirstArg<ttable>,
		_authzMeta?: AM,
		_filterMeta?: FM,
	) => {
		// ... Apply filter
		const queryRef = dbClient.query[tableRef];
		const data = await queryRef.findFirst(queryArgs);
		// ... Authz logic
		return data;
	};
};

const getFirstUser = createModelPgFindFirstQuery(
	"users",
	() => new Promise((resolve) => resolve(true)),
);

const firstUser = await getFirstUser(db, {
	where: eq(users.id, 1),
	with: { posts: true },
});

console.log(firstUser);

This is kinda working but not really, I just had time to look at it briefly. It doesn't infer the post array on the final type, but it gets it in the runtime.

I was thinking I could make it happen, so I came up with the following:
import { db } from "./pg/pg";
import * as schema from "./pg/schema";
import { BuildQueryResult, ExtractTablesWithRelations, eq } from "drizzle-orm";

type DB = typeof db;

type Schema = typeof schema;

type TableNames = keyof DB["query"];

type FindFirstArg<T extends TableNames> = Parameters<
	DB["query"][T]["findFirst"]
>[0];

type TablesWithRelations = ExtractTablesWithRelations<Schema>;

type TableWithRelations<TTableName extends keyof TablesWithRelations> =
	TablesWithRelations[TTableName];

export const createModelPgFindFirstQuery = <
	TTableName extends TableNames,
	AM extends Record<string, any>,
	FM extends Record<string, any>,
>(
	tableRef: TTableName,
	_authzFn: (args: FindFirstArg<TTableName>, meta?: AM) => Promise<boolean>,
	_argsFilter?: (
		args: FindFirstArg<TTableName>,
		meta?: FM,
	) => FindFirstArg<TTableName>,
) => {
	return async <QueryArgs extends FindFirstArg<TTableName>>(
		dbClient: DB,
		queryArgs?: QueryArgs,
		_authzMeta?: AM,
		_filterMeta?: FM,
	): Promise<
		BuildQueryResult<
			TablesWithRelations,
			TableWithRelations<TTableName>,
			QueryArgs extends undefined ? true : QueryArgs
		>
	> => {
		// ... Apply filter
		const queryRef = dbClient.query[tableRef];
		const data = await queryRef.findFirst(queryArgs);
		// ... Authz logic
		return data as any;
	};
};

const getFirstUser = createModelPgFindFirstQuery(
	"users",
	() => new Promise((resolve) => resolve(true)),
);

const firstUser = await getFirstUser(db, {
	where: eq(schema.users.id, 1),
	columns: { name: true },
	with: { posts: true },
});

console.log(firstUser);

Completely type safe from top to bottom. I only had to use as any once due to how complicated this type is.

Thank you for taking at look at this. Unfortunately both of these rely on you having the actual DB type that you are going to use to execute the query which from my reply I won't have.
Just to clarify this code is an abstraction layer that will be placed in an internal library and may be executed against any schema from any of our services which are not only different schemas but also run on different machines. This way we can standardise operations such as resource authorization and handling of soft deletes (or other filters) easily and consistently across all projects. I have successfully managed to solve this for mutations and the standard select queries but would really really like to use the relational queries if possible as it makes front end querying and filtering so much simpler and more versatile.
I could in theory infer the type from the uninstantiated PgDatabase type via query, tableName, findFirst such as you have done above for the FindFirstArgs type but as I mentioned in my response this causes a The inferred typeof 'X' cannot be named without a reference to 'Y'. This is likely not portable. A type annotation is necessary. error as the type that you are inferring is not exported and so TS considers it 'not portable'.
If you believe this is not a supported use case let me know and I'll patch package, but in general I feel that all types (unless completely obscure or entirely derivable) should be exported to enable developers to make the most of a package.

Very interesting, I actually brought this topic to the drizzle team recently. I think this is something they's like to improve on.

Have you looked at this lately? I think in the last couple versions they fixed this?


Spin-Density calculate

Hi there
help please
how can I calculate spin density of  unstricted dft calculation and visualized it or plot it ?
Thank you

You can dump the density in cube format, and use visualization tools like vmd, jmol to view the density. In the example folder, you can find an example for writing cube format, in tools/05-cubegen.py

thanks sunqm


AQCU-868: Add ability to optionally exclude plotting max and min instantaneous

Coverage decreased (-0.02%) to 88.829% when pulling c8659d556c16ef354e27f75f9d7b715ca9a3b117 on zmoore-usgs:feature/no-min-max into 1c5fd4abc76b469c580a4b2f4bb771acccafce79 on USGS-R:master.

Coverage decreased (-0.02%) to 88.829% when pulling c8659d556c16ef354e27f75f9d7b715ca9a3b117 on zmoore-usgs:feature/no-min-max into 1c5fd4abc76b469c580a4b2f4bb771acccafce79 on USGS-R:master.


build fixes and updates:

actually use cmake TEST_BIG_ENDIAN result: replace the
__BYTE_ORDER == __LITTLE_ENDIAN check in the source with
!defined(WORDS_BIGENDIAN).
refresh strtok_r.h from the CC0 licensed PDClib library
at https://github.com/DevSolar/pdclib.git
add strtok_r() check to cmake and adjust sources for it.
makefile adjustments.

I had a WIP branch that made unsf a library that could be used. Idea was to have it used by libwildmidi... but I'm not sure it's a great idea.

I had a WIP branch that made unsf a library that could be used. Idea was to have it used by libwildmidi... but I'm not sure it's a great idea.

It already is a library, albeit with FIXMEs -- how different a library is your branch? (I don't see any such one here.)

Hmmm... either I merged it in or I am thinking of another project. :man_shrugging:
FIXMEs might be my doing hahaha


Create a plugin for syncing state across tabs

Is your feature request related to a problem? Please describe.
I'm currently using simpler-state in an enterprise project and I need to sync the tabs. For example, when a user logs out, I want him/her to be logged out on all tabs automatically.
Describe the solution you'd like
I want every tab to receive an update when anything changes in the state
Describe alternatives you've considered
Something like redux sync state

This is an interesting use-case. This can be something that could be built complementary to the persistence plug-in. But since even Redux Sync State uses a third-party BroadcastChannel (because official API is not yet widely standard on browsers), adding that 3rd party lib would in itself be 4x the size of simpler-state!  This could be a good candidate for an "external" (not bundled) plug-in.

Kindly guide me on how I can implement it. I don't mind publishing this as the first external plugin for simpler-state

@arnelenero

My rough idea is:

Use persistence plug-in on each entity that you wish synchronized
Your tab sync plug-in will then implement an override for the set method (see https://simpler-state.js.org/recipe-plugins.html)
In the override, you will have to use the BroadcastChannel (I haven't used that before, TBH) to send a message that the persisted (localStorage) value of your entity has changed (no need to send the actual value, since this is available on localStorage—just the "key" used for persistence will do).
Your tab sync plug-in will also need to implement an override for the init method, so that you can set a listener on the BroadcastChannel. Whenever the listener detects a message that the entity has changed on a different tab, it will need to get the new value from localStorage, then invoke the entity.set to sync this tab.

Something like that I think should work.


Emulationstation fails after exiting any game for second time

Everything works as expected. I launch any game on any platform and when I quit the game I goes back to emulationstation. But second time I launch another game or the same when I quit retroarch finishes but emulationstation hungs and after a few seconds closes.

My mistake... something with previous settings was messing around... Forget about it.