Hi Nathan,

I’m not affiliated with the cargo-depgraph project.  You should probably
send the patch directly to Jonas.

Best,
Robin

On 2022-09-20 15:03:29, Nathan Wilcox wrote:
> This patch adds a `--workspace-only` option which constrains the graph
> to only workspace crates. This is useful for understanding
> intra-workspace dependencies.
> 
> ---

Good catch!  I didn’t check the compatibility because the changes seemed
pretty unsuspicious …  Currently, the versioning policy is to sync only
the major and minor version, so we can easily release a v3.7.1 version
that fixes backwards compatibility.  I’ll have a look at it in the next
days.

/Robin

On 2022-04-30 15:20:15, Daniel Müller wrote:
> Great stuff, thanks for the quick turnaround Robin! I noticed that the
> https://git.ireas.org/ repositories (mentioned below) are outdated.
> Should we reference the ones on sourcehut instead? Can we delete them to
> prevent confusion?

You’re right, I noticed that too.  I forgot to update my mail generation
script.  Will do so before the next release.  I want to keep the
git.ireas.org repositories as a backup, and I have a cron script that
automatically pulls in changes.  Maybe I forgot to add this repository
to that script – I will have a look at that.

/Robin

nitrokey-sys-rs v3.7.0 has been released.  It is available as a signed tag in
the nitrokey-sys-rs Git repository:
	https://git.ireas.org/nitrokey-sys-rs/tag/?h=v3.7.0
Or on crates.io:
	https://crates.io/crates/nitrokey-sys/3.7.0

This release mainly pulls in the upstream v3.7 release – thanks to
Daniel Mueller for the patch!

Changelog
---------

- Update to libnitrokey 3.7, causing all following changes.
- New functions:

Thanks!  Applied and released as v3.7.0.

Hi René,

thanks for the patches!  You don’t have to resend them, I’ll have a look
at them later today or tomorrow.

Best,
Robin

Thanks for the report!  That is definitely a valid use case.  Probably I
just did not handle type parameters in the macro rules.  I’ll have a
look at it and see whether this can be fixed easily.

/Robin

On 2022-02-27 19:04:12, Daniel Müller wrote:
> So strictly speaking we could now rip out synchronization from
> nitrokey-test, right? I think we may want to try that and see where things
> blow up before landing these changes. I am somewhat skeptical that all of
> the device commands have no device-side state that could get screwed up (not
> to speak of race conditions exposed by more frequent connects/logouts).

No.  We could change synchronization in nitrokey-test to work per device
instead of per test, but even that might cause some issues because some
tests try to access devices that were not passed by nitrokey-test.  We
could probably rework these tests or add a flag for tests that cannot
run in parallel.

Regarding the device state, I think it is the application’s

On 2022-02-27 18:55:06, Daniel Müller wrote:
> Can you please clarify what purpose the Manager serves at this point? I was
> under the impression that it has become obsolete now, but I may be missing
> something.
> Even if the Manager is somehow still needed, why do we need to synchronize
> accessses to it if all methods work on shared references anyway?

As this is a rather large refactoring process, I want to do things step
by step.  I agree that we probably don’t need the Manager anymore, or at
least not as a singleton, but I’d rather not remove it before the rest
of the API is done.  For example, we might need the Manager to
initialize the backends.

On 2022-02-27 18:40:28, Daniel Müller wrote:
> > @@ -19,6 +20,46 @@ use crate::error::{self, Error};
> >   use crate::otp;
> >   use crate::Version;
> > +lazy_static! {
> > +    static ref BACKEND: sync::Mutex<Backend> = sync::Mutex::new(Backend::new());
> > +}
> 
> FYI, I think once_cell is the new defacto crate for one time initialization
> of statics, and at least in the past efforts were on the way to get similar
> APIs into std.

Good point, I’ll look into that.