[Bug 273122] lang/python311: backport netlink support
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273122 --- Comment #2 from Mina Galić --- i would've done that, if it applied. The only branch it applies on is 3.12, and we don't currently have a port for that. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 273122] lang/python311: backport netlink support
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273122
--- Comment #3 from Charlie Li ---
You need to redo the existing ${PATCHDIR} patches on top of your stuff accepted
upstream.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 272600] devel/py-rpds-py: "FileNotFoundError: [Errno 2] No such file or directory: 'maturin'" in build phase for non-default Python
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272600 Po-Chuan Hsieh changed: What|Removed |Added Status|New |Closed Flags|maintainer-feedback?(sunpoe | |t...@freebsd.org) | Assignee|sunp...@freebsd.org |k...@freebsd.org Resolution|--- |FIXED --- Comment #4 from Po-Chuan Hsieh --- @kai, I could confirm the issue is fixed. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 273122] lang/python311: backport netlink support
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273122
--- Comment #4 from Mina Galić ---
it makes no sense to use
https://github.com/python/cpython/commit/eaa3bd080ef2299cbe614c348e3b8fdfacb66b48
in ${PATCH_SITES}/${PATCHFILES}
as GitHub says:
> This commit does not belong to any branch on this repository, and may belong
> to a fork outside of the repository.
I don't wanna use a mystery commit on a mystery fork just because it's on
GitHub.
that fork is mine, but it could go away any time: if I forget that there's
anything relevant in that fork, i could go on a cleaning spree and delete that
fork. and what do we do then?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 273122] lang/python311: backport netlink support
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273122
Joseph Mingrone changed:
What|Removed |Added
CC||j...@freebsd.org
--- Comment #5 from Joseph Mingrone ---
(In reply to Charlie Li from comment #3)
Charlie, I'm not following what you are asking. Could you clarify?
Comment #1
Mina's changes were only committed to upstream's main branch, but she wants to
apply the same changes to these releases. Defining
${PATCH_SITES}/${PATCHFILES} isn't going to work, because the commit won't
apply against any of python 3.8, 3.9, 3.10, or 3.11.
Comment #3
I'm unclear why you are asking for the patches to be made on top of something
accepted in upstream's main branch. Are we misunderstanding you?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 273122] lang/python311: backport netlink support
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273122
--- Comment #6 from Charlie Li ---
(In reply to Mina Galić from comment #4)
It's not a mystery if you comment the URL of the upstream issue in the
${PATCHFILES} line. The commit also lists the original issue. If you are that
worried, create some backport issues upstream but immediately close them, that
way the commits stay even after any branch deletion.
(In reply to Joseph Mingrone from comment #5)
They do work by using the "ghost" commits.
(In reply to Joseph Mingrone from comment #5)
${PATCH_SITES}/${PATCHFILES} are applied before ${PATCHDIR} so the order
matters. Since what was accepted upstream, then backported, touches files that
${PATCHDIR} does, ${PATCHDIR} patches need to be regenerated. And since this
was accepted upstream, even just in trunk, they tacitly recommended that we
carry it ourselves for the backports, so ${PATCH_SITES}/${PATCHFILES} they go.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 273122] lang/python311: backport netlink support
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273122 --- Comment #7 from Joseph Mingrone --- (In reply to Charlie Li from comment #6) I get what you are asking for now, but are all these hoops to jump through necessary. Mina's proposed changes overlap by one line in one file (configure)? Can't she just combine the changes into one configure patch? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 273122] lang/python311: backport netlink support
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273122 Daniel Engberg changed: What|Removed |Added CC||dii...@freebsd.org --- Comment #8 from Daniel Engberg --- (In reply to Charlie Li from comment #6) Why should you abuse GitHub's garbage collection or rather non/slow garbage collection/ghost feature and also upstreams repo? If there's concern about keeping track why not include the backport in a single patch file, add a comment of origin within the patch and name it like patch-git-01- and commit? Done and everyone is happy? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 273122] lang/python311: backport netlink support
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273122
--- Comment #9 from Charlie Li ---
We've done this with at least earlier iterations of graphics/mesa{,-devel}, and
it all works as intended. It's not just about keeping track, but ensuring that
everything is applied in the correct order, and that any local patches are
based on the original source plus items they accepted whether in the same
branch or trunk. Combining upstream patches with our local patches, sometimes
resulting in the same local patch file (names) in ${PATCHDIR}, is just a bad
idea.
(In reply to Joseph Mingrone from comment #7)
This is necessary when considering maintenance, semantics and mechanics.
(In reply to Daniel Engberg from comment #8)
Python upstream brought this upon themselves. In many other software projects,
this would be a bug fix, not a new feature. If anyone there cares enough, they
can read the last couple comments in the original issue, maybe see this
exchange, and understand/remind themselves that asking distributions to carry
arbitrary stuff they accepted as local patches comes at a cost. Don't forget
that some other upstreams don't bother to backport anything, not even bug or
build fixes, forcing downstreams like us to carry stuff.
The single patch file doesn't address the ordering. ${PATCHDIR} really isn't
meant for something like this.
--
You are receiving this mail because:
You are the assignee for the bug.
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/pyt...@freebsd.org.html Port| Current version | New version +-+ devel/py-nbconvert | 7.7.3 | 7.7.4 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by:portscout!
[Bug 273145] x11-toolkits/py-tkinter: make stage fails after recent strip addition (py27)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273145 Po-Chuan Hsieh changed: What|Removed |Added Assignee|python@FreeBSD.org |sunp...@freebsd.org CC|sunp...@freebsd.org | Resolution|--- |FIXED Status|Open|Closed --- Comment #3 from Po-Chuan Hsieh --- Fixed in ports 734819cc2bd010dd18a7dc0a422c33246ddd630a. Thanks. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 273122] lang/python311: backport netlink support
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273122 --- Comment #10 from Mina Galić --- (In reply to Charlie Li from comment #9) > Python upstream brought this upon themselves. In many other software > projects, this would be a bug fix, not a new feature. If anyone there cares > enough … if i create four pull requests that i know will be rejected, what does that look like? how likely is it then, after doing something like that, that my next legitimate patch will be accepted? upstream has explained their process. I don't agree with it, but shitting on it will not help future collaboration. If you don't want to merge these patches, that's fine. We'll close these bugs, and I'll wait for 3.13. -- You are receiving this mail because: You are the assignee for the bug.
