This is an upstream decision to drop that module. It was replaced by configuration options at:
https://github.com/OpenSC/OpenSC/commit/d1cf65754b9326c09213f151b7ee2f19f4037730#diff-0c902b5507a77653d4597dfeb4e4f80cR440

And that means? 

I'm afraid that endusers need more than some diff from git.

That means that this is the documentation that upstream added in that topic.

I believe adding the following line in your opensc.conf would simulate the onepin behaviour.

create_slots_for_pins = "user"

I was too quick to close it. It seems it is a regression in 0.13.0. What I describe above can be used as a hack to patch the issue, but is not a good solution as normal PKCS #11 applications, may have issues with that module. 

I re-open it, but I'm not sure that moving back to opensc-onepin is the right solution to the underlying problem (onepin is a hack for an NSS assumption on PKCS #11).

This regression was fixed in 0.14.0.

Meaning that it wont be available in F19 nor F20 at all?

Probably not. 0.14.0 has so many changes that wouldn't qualify as a bug fix release.

*** Bug 1165250 has been marked as a duplicate of this bug. ***

Nikos, have you tried that workaround you suggested?

No. Note, that this is the suggested method for 0.13 by upstream.

I have and it doesn't work. I also know, that upstream has its own problems. We wouldn't be writing comments here otherwise.

We cannot drop crucial functionality used by millions of people, from released distribution (in this case there are two releases). Fedora's case that drops you out of security updates if you try to avoid broken releases and waste time by doing own solution for packaging problems.

How the hell this was pushed into production in the first place? Dropping a plugin file name from SPEC file does not happen without noticing. :(

I understand and I have brought that up to upstream, but note that we don't have the resources to replace upstream by a local devel team for opensc (or most other packages). If upstream decides to drop some important functionality, even if we disagree we can't take another path (fork is hardly an option). Said that you can always join the opensc maintainers or provide a fix for the issue.

Nobody expects you to do development here. But you could make calls wether to pick or drop some upstream releases.

You justify, that this bug cannot be fixed with 0.14 changes backported to f19/f20 0.13 - "because it requires quite many changes". You could have justifed not include 0.13 into f19 in first place, with the very same excuse.

Now we have two broken stable release, second one is going to be supported next six months and today f21 is not yet released.

Someone noted that having parallel (with name opensc14) installation would have soname conflict, so that's not a solution either.

Yes, I could maintain opensc package. I would do no good if I'm not in veto power to pull off stupid decisions ending up into stable release.

There are quite many people here working with these packages and actually using smartcard hardware daily basis and developing stuff with it. Makes one wonder - what is your motivation/token/hardware with opensc? I guess I'm not alone with that question, maybe that's nothing that could have spotted this issue from happening?

I was not maintainer when this change was made but this not the point. Whether it was stupid or not it is on the eye of the beholder. If the features brought in were more than the features brought out, then it was a good decision.

So you're not using any smart card token. Why you're maintaining hardware related packages if you don't have any related hardware?

There are probably 1 against 1000-5000 or so users that use those "features brought in" - and now the rest are moving or have moved to another distro.

Any change of putting things into perspective? Like dropping maintainership and letting someone with real intrest to do it. This area is fscking difficult as it is already, without additional loose screws on it.

The opensc is extremely hard to maintain because the number of various hardware tokens it supports is huge. Basically Fedora does not have any other option than to believe upstream in their choices. If they made a mistake that's unfortunate but we have to live with that.

You use pretty harsh words but what if we updated to 0.14 in F19 and F20 and there was some similar issue but for another hardware token? Although the update could stay in testing for a long time the issue could be found only after getting into stable.

Did I mention that I kind of pisses people off when putting a lot working hours on something when someone else flushes it all into toilet? I'm not alone here.

(In reply to Juha Tuomala from comment #15)
> So you're not using any smart card token. Why you're maintaining hardware
> related packages if you don't have any related hardware?
> 
> There are probably 1 against 1000-5000 or so users that use those "features
> brought in" - and now the rest are moving or have moved to another distro.
> 
> Any change of putting things into perspective? Like dropping maintainership
> and letting someone with real intrest to do it. This area is fscking
> difficult as it is already, without additional loose screws on it.

Just because I don't use your token it doesn't mean I don't use tokens. If you want to rant about something just go to a pub. This is not the place for that.

Juha, using bad words will not move your cause to any better position. It will just make people to ignore them.

(In reply to Tomas Mraz from comment #16)
> The opensc is extremely hard to maintain because the number of various
> hardware tokens it supports is huge. Basically Fedora does not have any
> other option than to believe upstream in their choices. If they made a
> mistake that's unfortunate but we have to live with that.

Yes. Germany alone has 80 million people, Estonia has 1,4 million population and very active userspace. Finland has 5,4 population and 510k active cards. Plus ten or so other EU countries. Do the math.

All of them use it mostly in web - and use either opensc-pkcs11.so browser plugin or its onepine version. And they use that to get those two certificates from card. Whoever DROPPED THAT DAMN FILE from spec, prooved that he knows *nothing* what's going on. 

I just was told today that most what happens on opensc these days is features interested and driven by hobbyists (tens of) writing their own blank cards. And these  changes break goverment issued tokens used by millions of people. There is some perspective to consider. Luckily they all don't use Fedora. :)

> You use pretty harsh words 

No shit. And for reason.

> but what if we updated to 0.14 in F19 and F20 and
> there was some similar issue but for another hardware token? Although the
> update could stay in testing for a long time the issue could be found only
> after getting into stable.

I would like to hear/see what are the real issues with 0.14 on F20. I have it on my desktop as we speak and it works even with qdigidoc-3.9 - that 0.12 didn't. And it works with Estonian *and* Finnish issued 2048-bit cards. (see bug: 1165735)

If there is no *real* detailed comments what it would break, IMO you should push that 0.14 into F20. I don't see how this could go any worse anymore.

(In reply to Tomas Mraz from comment #19)
> Juha, using bad words will not move your cause to any better position. It
> will just make people to ignore them.

You imply that things were actively getting better very since when f19 with broken 0.13 was released?

I wish I had opened my mouth earlier.

Rex, what was the conclusion - that you set up COPR test builds? Or did I misunderstood?

Per Juha's requests for 0.14 builds for f19/f20, and discussion on freenode #fedora-devel yesterday, I offered to create a copr for additional testing/feedback,
https://copr.fedoraproject.org/coprs/rdieter/opensc/

New version from comment 23 fixes this issue.