F25 is still on openssl-1.0.2j and from the one person who replied on freenode #fedora, there don't seem to be any plans to upgrade. The ABI checker site has check on 1.0.2k and claims: Backward

Well, I expected such a reply but hoped to be surprised. It's a tough call as a distro maintainer. I wonder if maintainers for other major distros would generally have the same concerns about lack of

I am aware of such tools which do version matching and slap a list of CVEs at you without knowing anything else about the software. It would be more useful if these software really looked at a given

No. The issue is that there are other non-security fixes that are roughly being ignored. And we often get a lot of the "why aren't you on version XYZ of OpenSSL" type questions. Doesn't matter if

I believe this is already covered in the current policy. (lifted from policy) No recipe upgrades unless: The new version contains a security patch or other critical bugfix that is too difficult to

And when the upstream didn't break the ABI, we did with seemingly safe change of

I think we can contexualize it based upon amount of work, openssl has violated ABI within same major release in past see 1.0.2f -> 1.0.2g For complete

Randy, you are starting with a wrong assumption: that people listed in maintainers.inc are real maintainers - real in the sense that they follow upstream development, take care of regular runtime

Andreas Müller <schnitzeltony@...> wrote: There's 3 of us from Togán Labs who'll be able to help out manning the stand. I know I can do all day Saturday and up to about 4pm on Sunday and

We have made exceptions in the past for exactly the reasons you outline. Unfortunately I know at least for OpenSSL when we have done so on at least one occasion we have been bitten by compatibility

If upstream claims j->k release to just have CVE changesets may be its not a problem, however if there are more fixes that comes along with CVEs then we need to understand closely what these fixes are

Nobody? Andreas

Yocto seems to have a policy not to update packages once a release is generally available. I think that rule should be broken for certain packages that have been reviewed and tested properly. See:

I did write up the specifics of the implementation details into the main commit message for the change. For layer maintainers, the key piece were these points: * Recipes may fail with missing

Thanks, Richard! Will there be some sort of write-up detailing any work required for other layers to adapt to this change? Thanks. -- Denys

Agreed, that's even better. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no

I tend to agree with the expanded "package", I keep reading "PS" as any number of random things ... including "professional services". Cheers, Bruce -- "Thou shalt not follow the NULL pointer, for

PACKAGE_SCRIPTS_DEPENDS maps better to what they are intended to be used for, I think. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br

Looking at this description, it is not at all clear to me why the variable is named PACKAGE_WRITE_DEPENDS. From the description, the things listed in it are dependencies of do_rootfs, not

I agree with stripping out the task piece, I was planning to work something out with that. We could do with this cleanup in other places too. Not all have the form -native (we have some -cross) and I