| Summary: | =dev-lang/erlang-23.2.1 stabilization | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sergei Trofimovich (RETIRED) <slyfox> |
| Component: | Stabilization | Assignee: | Sergei Trofimovich (RETIRED) <slyfox> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | arkamar, proxy-maint |
| Priority: | Normal | Keywords: | STABLEREQ |
| Version: | unspecified | Flags: | nattka:
sanity-check+
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: |
dev-lang/erlang-23.2.1
|
Runtime testing required: | No |
Duplicate of bug 765796 right? (which we can’t yet move forward with) No, it should not be directly related. I personally don't plan to backport security fixes to older erlang branches. That means removal (or masking) of vulnerable erlang versions would require porting all revdeps to newer version. I think we only have rabbitmq-server left (bug #755236). We are not there yet. But rabbitmq-server should not block stabilization of newer erlang versions if they are ready. (In reply to Sergei Trofimovich from comment #2) > No, it should not be directly related. > > I personally don't plan to backport security fixes to older erlang branches. > That means removal (or masking) of vulnerable erlang versions would require > porting all revdeps to newer version. I think we only have rabbitmq-server > left (bug #755236). We are not there yet. > > But rabbitmq-server should not block stabilization of newer erlang versions > if they are ready. We usually do stabilisation in the same bug, but cleanup would then be blocked on sorting out revdeps. But I'll just block the bug on this one ppc64 done amd64 done x86 done sparc done ppc done all arches done |
In tree for 30 days. Let's stabilize =dev-lang/erlang-23.2.1 for: amd64 ppc ppc64 sparc x86