Re: powerpc64 system-clang-8 based context: x11-toolkits/qt5-declarative fails to build in poudriere: /usr/local/lib/qt5/bin/qlalr segmentation faults in std::type_info::~type_info() () from /usr/loca
On 2019-May-24, at 11:25, Mark Linimon wrote: > On Thu, May 23, 2019 at 10:33:35PM -0700, Mark Millard via freebsd-toolchain > wrote: >> That is no matter what the system compiler is for powerpc64. >> >> This lead to the below mixing of libstdc++.so.6 and libc++/libcxxrt . . . > > Yeah. This is probably my fault. > > We've baked the assumption into ports that "powerpc64 implies gcc in base". > You're the first person to color outside the lines I think :-) > > I'm going to start an internal discussion about what the "real" fix is. > I consider what we've done in some places to not be the "real" fix because > they assume _either_ llvm _or_ gcc in base. This would fix your specific > problem but not the general problem of someone installing both and then > switching back and forth for testing. Plus qt5 is outside the range of gcc 4.2.1 to cover, so for it a usable "gcc in base" would mean base/gcc or some such substitution. But base/gcc does not imply any version of libstdc++ is in use either: same problem as system-clang-8-based if something like lang/gcc8 is used for qt5. Even if libstdc++ was (hypothetically) used, the vintage from base/gcc or devel/*-gcc sorts of materials would not generally match lang/gcc8 or whatever compiler:c++11-lib and the like might default to. For the likes of qt5, care must be taken that, for example, devel/icu and its: /usr/local/lib/libicui18n.so.64 /usr/local/lib/libicuuc.so.64 vs. qt5: they must use the same c++ library and vintage. Then there are things that really could use gcc 4.2.1 from base: mixed libstdc++ vintages could result, even if some port lang/gcc* toolchain is used. Definitely a messy context. The failing behavior (program crash very early when starting) was not obviously tied to c++ library mixes being involved. It would be handy if some stage of building/installing/running caught the presence of such a bad combination and was explicit about it. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
net/rtg committer needed
Hi, net/rtg no longer runs on modern perl. The maintainer made a patch almost a year ago, but it's been stalled on some flavour stuff. I've modified the patch to remove the offending flavour bits, but haven't heard back from the maintainer in almost a month, even tried poking him out of band. The orginal patch is here: https://reviews.freebsd.org/D17637 And I've uploaded my fixed patch to the bug report on bugzilla here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227376 Works on 12.0, and the maintainer's original patch before it got kicked out is working on both 11.x and 12.0 Is there a commiter that could take a look at this and see if we can get it back to working? Thanks, Andrew Fengler ScaleEngine Inc. Email: andrew.feng...@scaleengine.com Phone: (800) 224-0095 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Policy on closing bugs
On 24/05/2019 12:26, Kubilay Kocak wrote: On 24/05/2019 9:30 pm, Grzegorz Junka wrote: On 24/05/2019 11:12, Kubilay Kocak wrote: On 24/05/2019 8:07 pm, Grzegorz Junka wrote: Hey, Is there any policy/document when a bug can be closed? For example, is it OK to close a bug that is fixed upstream but not yet in ports? Thanks GrzegorzJ Hi Grzegorz, Bugs are closed after they are "resolved". Resolved means a resolution has "occurred", but more precisely, the "thing reported" has been resolved. Resolved doesn't necessary mean "fixed" (see below) What resolution is appropriate/set depends on the context of the issue, usually the specific nature of the request/proposal. Is there a specific bug you're referring to? I can speak to that case specifically if so. For example however, if the bug was a "bug report for the port/package", fixed upstream hasn't fixed the port, so not usually, no, that wouldn't be considered sufficient to be "resolved" and closed. Usually commits upstream are backported to the ports, and they are closed when those are committed. There can't be policies for this perse, as its completely context/request dependent. Resolutions can take place either by way of: 1) A change is made: a commit, usually, but could be a wiki update, or a DNS update for infrastructure changes, etc. 2) One of the 'non-change' resolutions: not accepted, unable to reproduce, feedback timeout, etc Nothing about the above is special or different than most other issue trackers (generally speaking). Regarding states, we have New, Open, In Progress, Closed New: Not touched/Untriaged Open: Initially Triaged (classified) In Progress: Has a real (person) Assignee, action has started Closed: Change(s) Made, OR "Non-Change" resolution set. There's nothing special/different about these either, except that we like to have a real person assigned before in progress, and before close. Happy to answer any more questions regarding issue tracking, etc anytime Hi Kubilay, Thank you for a detailed response. Yes, this is related to a particular defect. I didn't mention it because I didn't want to be picky and seen as causing troubles :) Also wasn't sure what's OK and what's not. Here is the defect: My pleasure. I understand the desire not to want "cause trouble", but it's also important that everyone feel comfortable asking questions, and understand/clarify how things works (or should work, ideally). We need to see more of it, not less. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238086 I appreciate Yuri's contributions to the community and my intention isn't to bring this up for judgment. Even though as a FreeBSD user I might feel a bit ignored and shuffled under the carpet after the defect has been closed, my intention was more to find out if maybe a new state "Postponed" could be added for a defect in a state like this one? GrzegorzJ So there's a few issues involved, that are worth making very distinct: - A FreeBSD port/package and its users are affected - Upstream has apparently fixed the issue, but there's not much detail about how, where, when, etc - The bugs resolution type We'll run through those individually so its hopefully more clear how they might interact/overlap with each other: 1) If a port/package is broken in some way, we want to fix it, and as maintainers, we have signed up to do that. This is not controversial. For users, its not always (I would argue in most cases), possible or easy for them to distinguish between a port problem, and a software problem, and who (freebsd or upstream) should be primarily responsible to a) get the initial bug report b) fix it in the first instance. I personally don't believe users should be expected to know or do this, but its great if/when they can. There are arguments on both sides of the (unfortunate) upstream/downstream divide, about users reporting bugs to the "wrong place". Sometimes downstreams hack software to make it work or do things differently in their distribution/OS, and sometimes these things break, and upstreams get the report. Sometimes upstreams break things, and downstreams get the reports. It's a difficult problem to solve completely and permanently, so ultimately it's the relationship between downstreams/upstreams that is the most important thing to cultivate. Having said that, at least in the former case, I don't think its too much of a burden for us to receive reports and close them (where appropriate) as "wont fix / not accepted" after commenting that the report should go upstream. The question as to what and when is appropriate is very case dependent, but the minimum (in my opinion) is that it should be explicitly clear to the reporter and documented what the complete rationale, analysis is to resolving in that manner. 2) If an upstream has fixed an issue, all else being equal, we ought to be motivated to identify the specific upstream
Re: Policy on closing bugs
On 24/05/2019 12:48, Kubilay Kocak wrote: On 24/05/2019 10:45 pm, Grzegorz Junka wrote: On 24/05/2019 12:34, Kubilay Kocak wrote: On 24/05/2019 9:52 pm, Grzegorz Junka wrote: On 24/05/2019 11:30, Grzegorz Junka wrote: On 24/05/2019 11:12, Kubilay Kocak wrote: On 24/05/2019 8:07 pm, Grzegorz Junka wrote: Hey, Is there any policy/document when a bug can be closed? For example, is it OK to close a bug that is fixed upstream but not yet in ports? Thanks GrzegorzJ Hi Grzegorz, Bugs are closed after they are "resolved". Resolved means a resolution has "occurred", but more precisely, the "thing reported" has been resolved. Resolved doesn't necessary mean "fixed" (see below) What resolution is appropriate/set depends on the context of the issue, usually the specific nature of the request/proposal. Is there a specific bug you're referring to? I can speak to that case specifically if so. For example however, if the bug was a "bug report for the port/package", fixed upstream hasn't fixed the port, so not usually, no, that wouldn't be considered sufficient to be "resolved" and closed. Usually commits upstream are backported to the ports, and they are closed when those are committed. There can't be policies for this perse, as its completely context/request dependent. Resolutions can take place either by way of: 1) A change is made: a commit, usually, but could be a wiki update, or a DNS update for infrastructure changes, etc. 2) One of the 'non-change' resolutions: not accepted, unable to reproduce, feedback timeout, etc Nothing about the above is special or different than most other issue trackers (generally speaking). Regarding states, we have New, Open, In Progress, Closed New: Not touched/Untriaged Open: Initially Triaged (classified) In Progress: Has a real (person) Assignee, action has started Closed: Change(s) Made, OR "Non-Change" resolution set. There's nothing special/different about these either, except that we like to have a real person assigned before in progress, and before close. Happy to answer any more questions regarding issue tracking, etc anytime Hi Kubilay, Thank you for a detailed response. Yes, this is related to a particular defect. I didn't mention it because I didn't want to be picky and seen as causing troubles :) Also wasn't sure what's OK and what's not. Here is the defect: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238086 I appreciate Yuri's contributions to the community and my intention isn't to bring this up for judgment. Even though as a FreeBSD user I might feel a bit ignored and shuffled under the carpet after the defect has been closed, my intention was more to find out if maybe a new state "Postponed" could be added for a defect in a state like this one? A very similar story with: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238088 It's not scheduled to be removed per se yet. The removal is under discussion with no clear path agreed as far as I know. I understand that a maintainer doesn't want to spend time working on a port that will likely undergo significant changes or removal but is closing the defect the right thing to do? And again, a "Postponed" state seems to me to be more appropriate? GrzegorzJ The better resolution for this is again probably: Not Accepted (as WONTFIX), though I can understand why "Overcome by Events" was selected (wont be fixed *because* of a separate overruling issue). From a reading of the associated bug (215036), it reads fairly clearly that the 0.x branch is not supported (security wise, in particular), and no further work will be done on it. That the port has been deprecated (DEPRECATED/EXPIRY_DATE) is evidence of that decision. Agreed in principle, but the port hasn't yet been marked as DEPRECATED/EXPIRATION_DATE. Unless it was done in the last few days (I synced my ports 18 May). ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" Indeed it has: https://svnweb.freebsd.org/changeset/ports/502453 The same day, 6 minutes after your comment about it not having an EXPIRATION_DATE :) All right, I did see the commit but I thought the commit message is the actual change. I should have tried to dig deeper. Sorry about that. I guess this one is sorted then :) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Policy on closing bugs
On 24/05/2019 10:45 pm, Grzegorz Junka wrote: On 24/05/2019 12:34, Kubilay Kocak wrote: On 24/05/2019 9:52 pm, Grzegorz Junka wrote: On 24/05/2019 11:30, Grzegorz Junka wrote: On 24/05/2019 11:12, Kubilay Kocak wrote: On 24/05/2019 8:07 pm, Grzegorz Junka wrote: Hey, Is there any policy/document when a bug can be closed? For example, is it OK to close a bug that is fixed upstream but not yet in ports? Thanks GrzegorzJ Hi Grzegorz, Bugs are closed after they are "resolved". Resolved means a resolution has "occurred", but more precisely, the "thing reported" has been resolved. Resolved doesn't necessary mean "fixed" (see below) What resolution is appropriate/set depends on the context of the issue, usually the specific nature of the request/proposal. Is there a specific bug you're referring to? I can speak to that case specifically if so. For example however, if the bug was a "bug report for the port/package", fixed upstream hasn't fixed the port, so not usually, no, that wouldn't be considered sufficient to be "resolved" and closed. Usually commits upstream are backported to the ports, and they are closed when those are committed. There can't be policies for this perse, as its completely context/request dependent. Resolutions can take place either by way of: 1) A change is made: a commit, usually, but could be a wiki update, or a DNS update for infrastructure changes, etc. 2) One of the 'non-change' resolutions: not accepted, unable to reproduce, feedback timeout, etc Nothing about the above is special or different than most other issue trackers (generally speaking). Regarding states, we have New, Open, In Progress, Closed New: Not touched/Untriaged Open: Initially Triaged (classified) In Progress: Has a real (person) Assignee, action has started Closed: Change(s) Made, OR "Non-Change" resolution set. There's nothing special/different about these either, except that we like to have a real person assigned before in progress, and before close. Happy to answer any more questions regarding issue tracking, etc anytime Hi Kubilay, Thank you for a detailed response. Yes, this is related to a particular defect. I didn't mention it because I didn't want to be picky and seen as causing troubles :) Also wasn't sure what's OK and what's not. Here is the defect: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238086 I appreciate Yuri's contributions to the community and my intention isn't to bring this up for judgment. Even though as a FreeBSD user I might feel a bit ignored and shuffled under the carpet after the defect has been closed, my intention was more to find out if maybe a new state "Postponed" could be added for a defect in a state like this one? A very similar story with: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238088 It's not scheduled to be removed per se yet. The removal is under discussion with no clear path agreed as far as I know. I understand that a maintainer doesn't want to spend time working on a port that will likely undergo significant changes or removal but is closing the defect the right thing to do? And again, a "Postponed" state seems to me to be more appropriate? GrzegorzJ The better resolution for this is again probably: Not Accepted (as WONTFIX), though I can understand why "Overcome by Events" was selected (wont be fixed *because* of a separate overruling issue). From a reading of the associated bug (215036), it reads fairly clearly that the 0.x branch is not supported (security wise, in particular), and no further work will be done on it. That the port has been deprecated (DEPRECATED/EXPIRY_DATE) is evidence of that decision. Agreed in principle, but the port hasn't yet been marked as DEPRECATED/EXPIRATION_DATE. Unless it was done in the last few days (I synced my ports 18 May). ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" Indeed it has: https://svnweb.freebsd.org/changeset/ports/502453 The same day, 6 minutes after your comment about it not having an EXPIRATION_DATE :) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Policy on closing bugs
On 24/05/2019 12:34, Kubilay Kocak wrote: On 24/05/2019 9:52 pm, Grzegorz Junka wrote: On 24/05/2019 11:30, Grzegorz Junka wrote: On 24/05/2019 11:12, Kubilay Kocak wrote: On 24/05/2019 8:07 pm, Grzegorz Junka wrote: Hey, Is there any policy/document when a bug can be closed? For example, is it OK to close a bug that is fixed upstream but not yet in ports? Thanks GrzegorzJ Hi Grzegorz, Bugs are closed after they are "resolved". Resolved means a resolution has "occurred", but more precisely, the "thing reported" has been resolved. Resolved doesn't necessary mean "fixed" (see below) What resolution is appropriate/set depends on the context of the issue, usually the specific nature of the request/proposal. Is there a specific bug you're referring to? I can speak to that case specifically if so. For example however, if the bug was a "bug report for the port/package", fixed upstream hasn't fixed the port, so not usually, no, that wouldn't be considered sufficient to be "resolved" and closed. Usually commits upstream are backported to the ports, and they are closed when those are committed. There can't be policies for this perse, as its completely context/request dependent. Resolutions can take place either by way of: 1) A change is made: a commit, usually, but could be a wiki update, or a DNS update for infrastructure changes, etc. 2) One of the 'non-change' resolutions: not accepted, unable to reproduce, feedback timeout, etc Nothing about the above is special or different than most other issue trackers (generally speaking). Regarding states, we have New, Open, In Progress, Closed New: Not touched/Untriaged Open: Initially Triaged (classified) In Progress: Has a real (person) Assignee, action has started Closed: Change(s) Made, OR "Non-Change" resolution set. There's nothing special/different about these either, except that we like to have a real person assigned before in progress, and before close. Happy to answer any more questions regarding issue tracking, etc anytime Hi Kubilay, Thank you for a detailed response. Yes, this is related to a particular defect. I didn't mention it because I didn't want to be picky and seen as causing troubles :) Also wasn't sure what's OK and what's not. Here is the defect: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238086 I appreciate Yuri's contributions to the community and my intention isn't to bring this up for judgment. Even though as a FreeBSD user I might feel a bit ignored and shuffled under the carpet after the defect has been closed, my intention was more to find out if maybe a new state "Postponed" could be added for a defect in a state like this one? A very similar story with: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238088 It's not scheduled to be removed per se yet. The removal is under discussion with no clear path agreed as far as I know. I understand that a maintainer doesn't want to spend time working on a port that will likely undergo significant changes or removal but is closing the defect the right thing to do? And again, a "Postponed" state seems to me to be more appropriate? GrzegorzJ The better resolution for this is again probably: Not Accepted (as WONTFIX), though I can understand why "Overcome by Events" was selected (wont be fixed *because* of a separate overruling issue). From a reading of the associated bug (215036), it reads fairly clearly that the 0.x branch is not supported (security wise, in particular), and no further work will be done on it. That the port has been deprecated (DEPRECATED/EXPIRY_DATE) is evidence of that decision. Agreed in principle, but the port hasn't yet been marked as DEPRECATED/EXPIRATION_DATE. Unless it was done in the last few days (I synced my ports 18 May). ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Policy on closing bugs
On 24/05/2019 9:52 pm, Grzegorz Junka wrote: On 24/05/2019 11:30, Grzegorz Junka wrote: On 24/05/2019 11:12, Kubilay Kocak wrote: On 24/05/2019 8:07 pm, Grzegorz Junka wrote: Hey, Is there any policy/document when a bug can be closed? For example, is it OK to close a bug that is fixed upstream but not yet in ports? Thanks GrzegorzJ Hi Grzegorz, Bugs are closed after they are "resolved". Resolved means a resolution has "occurred", but more precisely, the "thing reported" has been resolved. Resolved doesn't necessary mean "fixed" (see below) What resolution is appropriate/set depends on the context of the issue, usually the specific nature of the request/proposal. Is there a specific bug you're referring to? I can speak to that case specifically if so. For example however, if the bug was a "bug report for the port/package", fixed upstream hasn't fixed the port, so not usually, no, that wouldn't be considered sufficient to be "resolved" and closed. Usually commits upstream are backported to the ports, and they are closed when those are committed. There can't be policies for this perse, as its completely context/request dependent. Resolutions can take place either by way of: 1) A change is made: a commit, usually, but could be a wiki update, or a DNS update for infrastructure changes, etc. 2) One of the 'non-change' resolutions: not accepted, unable to reproduce, feedback timeout, etc Nothing about the above is special or different than most other issue trackers (generally speaking). Regarding states, we have New, Open, In Progress, Closed New: Not touched/Untriaged Open: Initially Triaged (classified) In Progress: Has a real (person) Assignee, action has started Closed: Change(s) Made, OR "Non-Change" resolution set. There's nothing special/different about these either, except that we like to have a real person assigned before in progress, and before close. Happy to answer any more questions regarding issue tracking, etc anytime Hi Kubilay, Thank you for a detailed response. Yes, this is related to a particular defect. I didn't mention it because I didn't want to be picky and seen as causing troubles :) Also wasn't sure what's OK and what's not. Here is the defect: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238086 I appreciate Yuri's contributions to the community and my intention isn't to bring this up for judgment. Even though as a FreeBSD user I might feel a bit ignored and shuffled under the carpet after the defect has been closed, my intention was more to find out if maybe a new state "Postponed" could be added for a defect in a state like this one? A very similar story with: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238088 It's not scheduled to be removed per se yet. The removal is under discussion with no clear path agreed as far as I know. I understand that a maintainer doesn't want to spend time working on a port that will likely undergo significant changes or removal but is closing the defect the right thing to do? And again, a "Postponed" state seems to me to be more appropriate? GrzegorzJ The better resolution for this is again probably: Not Accepted (as WONTFIX), though I can understand why "Overcome by Events" was selected (wont be fixed *because* of a separate overruling issue). From a reading of the associated bug (215036), it reads fairly clearly that the 0.x branch is not supported (security wise, in particular), and no further work will be done on it. That the port has been deprecated (DEPRECATED/EXPIRY_DATE) is evidence of that decision. ./koobs ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Policy on closing bugs
On 24/05/2019 9:30 pm, Grzegorz Junka wrote: On 24/05/2019 11:12, Kubilay Kocak wrote: On 24/05/2019 8:07 pm, Grzegorz Junka wrote: Hey, Is there any policy/document when a bug can be closed? For example, is it OK to close a bug that is fixed upstream but not yet in ports? Thanks GrzegorzJ Hi Grzegorz, Bugs are closed after they are "resolved". Resolved means a resolution has "occurred", but more precisely, the "thing reported" has been resolved. Resolved doesn't necessary mean "fixed" (see below) What resolution is appropriate/set depends on the context of the issue, usually the specific nature of the request/proposal. Is there a specific bug you're referring to? I can speak to that case specifically if so. For example however, if the bug was a "bug report for the port/package", fixed upstream hasn't fixed the port, so not usually, no, that wouldn't be considered sufficient to be "resolved" and closed. Usually commits upstream are backported to the ports, and they are closed when those are committed. There can't be policies for this perse, as its completely context/request dependent. Resolutions can take place either by way of: 1) A change is made: a commit, usually, but could be a wiki update, or a DNS update for infrastructure changes, etc. 2) One of the 'non-change' resolutions: not accepted, unable to reproduce, feedback timeout, etc Nothing about the above is special or different than most other issue trackers (generally speaking). Regarding states, we have New, Open, In Progress, Closed New: Not touched/Untriaged Open: Initially Triaged (classified) In Progress: Has a real (person) Assignee, action has started Closed: Change(s) Made, OR "Non-Change" resolution set. There's nothing special/different about these either, except that we like to have a real person assigned before in progress, and before close. Happy to answer any more questions regarding issue tracking, etc anytime Hi Kubilay, Thank you for a detailed response. Yes, this is related to a particular defect. I didn't mention it because I didn't want to be picky and seen as causing troubles :) Also wasn't sure what's OK and what's not. Here is the defect: My pleasure. I understand the desire not to want "cause trouble", but it's also important that everyone feel comfortable asking questions, and understand/clarify how things works (or should work, ideally). We need to see more of it, not less. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238086 I appreciate Yuri's contributions to the community and my intention isn't to bring this up for judgment. Even though as a FreeBSD user I might feel a bit ignored and shuffled under the carpet after the defect has been closed, my intention was more to find out if maybe a new state "Postponed" could be added for a defect in a state like this one? GrzegorzJ So there's a few issues involved, that are worth making very distinct: - A FreeBSD port/package and its users are affected - Upstream has apparently fixed the issue, but there's not much detail about how, where, when, etc - The bugs resolution type We'll run through those individually so its hopefully more clear how they might interact/overlap with each other: 1) If a port/package is broken in some way, we want to fix it, and as maintainers, we have signed up to do that. This is not controversial. For users, its not always (I would argue in most cases), possible or easy for them to distinguish between a port problem, and a software problem, and who (freebsd or upstream) should be primarily responsible to a) get the initial bug report b) fix it in the first instance. I personally don't believe users should be expected to know or do this, but its great if/when they can. There are arguments on both sides of the (unfortunate) upstream/downstream divide, about users reporting bugs to the "wrong place". Sometimes downstreams hack software to make it work or do things differently in their distribution/OS, and sometimes these things break, and upstreams get the report. Sometimes upstreams break things, and downstreams get the reports. It's a difficult problem to solve completely and permanently, so ultimately it's the relationship between downstreams/upstreams that is the most important thing to cultivate. Having said that, at least in the former case, I don't think its too much of a burden for us to receive reports and close them (where appropriate) as "wont fix / not accepted" after commenting that the report should go upstream. The question as to what and when is appropriate is very case dependent, but the minimum (in my opinion) is that it should be explicitly clear to the reporter and documented what the complete rationale, analysis is to resolving in that manner. 2) If an upstream has fixed an issue, all else being equal, we ought to be motivated to identify the specific upstream fix/commit/pr/issue, and look to include it in the port, if
Re: Policy on closing bugs
On 24/05/2019 11:30, Grzegorz Junka wrote: On 24/05/2019 11:12, Kubilay Kocak wrote: On 24/05/2019 8:07 pm, Grzegorz Junka wrote: Hey, Is there any policy/document when a bug can be closed? For example, is it OK to close a bug that is fixed upstream but not yet in ports? Thanks GrzegorzJ Hi Grzegorz, Bugs are closed after they are "resolved". Resolved means a resolution has "occurred", but more precisely, the "thing reported" has been resolved. Resolved doesn't necessary mean "fixed" (see below) What resolution is appropriate/set depends on the context of the issue, usually the specific nature of the request/proposal. Is there a specific bug you're referring to? I can speak to that case specifically if so. For example however, if the bug was a "bug report for the port/package", fixed upstream hasn't fixed the port, so not usually, no, that wouldn't be considered sufficient to be "resolved" and closed. Usually commits upstream are backported to the ports, and they are closed when those are committed. There can't be policies for this perse, as its completely context/request dependent. Resolutions can take place either by way of: 1) A change is made: a commit, usually, but could be a wiki update, or a DNS update for infrastructure changes, etc. 2) One of the 'non-change' resolutions: not accepted, unable to reproduce, feedback timeout, etc Nothing about the above is special or different than most other issue trackers (generally speaking). Regarding states, we have New, Open, In Progress, Closed New: Not touched/Untriaged Open: Initially Triaged (classified) In Progress: Has a real (person) Assignee, action has started Closed: Change(s) Made, OR "Non-Change" resolution set. There's nothing special/different about these either, except that we like to have a real person assigned before in progress, and before close. Happy to answer any more questions regarding issue tracking, etc anytime Hi Kubilay, Thank you for a detailed response. Yes, this is related to a particular defect. I didn't mention it because I didn't want to be picky and seen as causing troubles :) Also wasn't sure what's OK and what's not. Here is the defect: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238086 I appreciate Yuri's contributions to the community and my intention isn't to bring this up for judgment. Even though as a FreeBSD user I might feel a bit ignored and shuffled under the carpet after the defect has been closed, my intention was more to find out if maybe a new state "Postponed" could be added for a defect in a state like this one? A very similar story with: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238088 It's not scheduled to be removed per se yet. The removal is under discussion with no clear path agreed as far as I know. I understand that a maintainer doesn't want to spend time working on a port that will likely undergo significant changes or removal but is closing the defect the right thing to do? And again, a "Postponed" state seems to me to be more appropriate? GrzegorzJ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Policy on closing bugs
On 24/05/2019 11:12, Kubilay Kocak wrote: On 24/05/2019 8:07 pm, Grzegorz Junka wrote: Hey, Is there any policy/document when a bug can be closed? For example, is it OK to close a bug that is fixed upstream but not yet in ports? Thanks GrzegorzJ Hi Grzegorz, Bugs are closed after they are "resolved". Resolved means a resolution has "occurred", but more precisely, the "thing reported" has been resolved. Resolved doesn't necessary mean "fixed" (see below) What resolution is appropriate/set depends on the context of the issue, usually the specific nature of the request/proposal. Is there a specific bug you're referring to? I can speak to that case specifically if so. For example however, if the bug was a "bug report for the port/package", fixed upstream hasn't fixed the port, so not usually, no, that wouldn't be considered sufficient to be "resolved" and closed. Usually commits upstream are backported to the ports, and they are closed when those are committed. There can't be policies for this perse, as its completely context/request dependent. Resolutions can take place either by way of: 1) A change is made: a commit, usually, but could be a wiki update, or a DNS update for infrastructure changes, etc. 2) One of the 'non-change' resolutions: not accepted, unable to reproduce, feedback timeout, etc Nothing about the above is special or different than most other issue trackers (generally speaking). Regarding states, we have New, Open, In Progress, Closed New: Not touched/Untriaged Open: Initially Triaged (classified) In Progress: Has a real (person) Assignee, action has started Closed: Change(s) Made, OR "Non-Change" resolution set. There's nothing special/different about these either, except that we like to have a real person assigned before in progress, and before close. Happy to answer any more questions regarding issue tracking, etc anytime Hi Kubilay, Thank you for a detailed response. Yes, this is related to a particular defect. I didn't mention it because I didn't want to be picky and seen as causing troubles :) Also wasn't sure what's OK and what's not. Here is the defect: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238086 I appreciate Yuri's contributions to the community and my intention isn't to bring this up for judgment. Even though as a FreeBSD user I might feel a bit ignored and shuffled under the carpet after the defect has been closed, my intention was more to find out if maybe a new state "Postponed" could be added for a defect in a state like this one? GrzegorzJ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Policy on closing bugs
On 24/05/2019 8:07 pm, Grzegorz Junka wrote: Hey, Is there any policy/document when a bug can be closed? For example, is it OK to close a bug that is fixed upstream but not yet in ports? Thanks GrzegorzJ Hi Grzegorz, Bugs are closed after they are "resolved". Resolved means a resolution has "occurred", but more precisely, the "thing reported" has been resolved. Resolved doesn't necessary mean "fixed" (see below) What resolution is appropriate/set depends on the context of the issue, usually the specific nature of the request/proposal. Is there a specific bug you're referring to? I can speak to that case specifically if so. For example however, if the bug was a "bug report for the port/package", fixed upstream hasn't fixed the port, so not usually, no, that wouldn't be considered sufficient to be "resolved" and closed. Usually commits upstream are backported to the ports, and they are closed when those are committed. There can't be policies for this perse, as its completely context/request dependent. Resolutions can take place either by way of: 1) A change is made: a commit, usually, but could be a wiki update, or a DNS update for infrastructure changes, etc. 2) One of the 'non-change' resolutions: not accepted, unable to reproduce, feedback timeout, etc Nothing about the above is special or different than most other issue trackers (generally speaking). Regarding states, we have New, Open, In Progress, Closed New: Not touched/Untriaged Open: Initially Triaged (classified) In Progress: Has a real (person) Assignee, action has started Closed: Change(s) Made, OR "Non-Change" resolution set. There's nothing special/different about these either, except that we like to have a real person assigned before in progress, and before close. Happy to answer any more questions regarding issue tracking, etc anytime -- Regards, Kubilay Bugmeister ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Policy on closing bugs
On 24/05/2019 10:53, Jan Bramkamp wrote: On 24.05.19 12:07, Grzegorz Junka wrote: Hey, Is there any policy/document when a bug can be closed? For example, is it OK to close a bug that is fixed upstream but not yet in ports? Thanks GrzegorzJ I don't know of any official policy, but as a user (and port maintainer) I would prefer an update to the FreeBSD PR stating that the bug has been fixed upstream. Closing the PR should wait until the fix made it into the port. As a port maintainer and user would you like to see an official guideline/policy about defect states and when to transition between them? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Policy on closing bugs
On 24.05.19 12:07, Grzegorz Junka wrote: Hey, Is there any policy/document when a bug can be closed? For example, is it OK to close a bug that is fixed upstream but not yet in ports? Thanks GrzegorzJ I don't know of any official policy, but as a user (and port maintainer) I would prefer an update to the FreeBSD PR stating that the bug has been fixed upstream. Closing the PR should wait until the fix made it into the port. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: powerpc64 graphics/mesa-dri build failure in poudriere, system clang's /usr/bin/cc got assert failure: "Target supports vector op, but scalar requires expansion?"
Ralf Wenk writes: > On 2019-05-23, at 12:31 -0700, Mark Millard wrote: > >> On 2019-May-23, at 11:47, Jan Beich wrote: >> >> > Mark Millard writes: >> > >> >> Unfortunately poudiere bulk tar archives of failures do not >> >> catch the /tmp/* material from: >> >> >> >> cc: error: unable to execute command: Abort trap (core dumped) >> >> cc: error: clang frontend command failed due to signal (use -v to see >> >> invocation) >> >> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on >> >> LLVM 8.0.0) >> >> Target: powerpc64-unknown-freebsd13.0 >> >> Thread model: posix >> >> InstalledDir: /usr/bin >> > >> > Do you have the build log? Maybe it's possible to reproduce simply by >> > adding >> > -target powerpc64-unknown-freebsd13.0 while cross-building that particular >> > file >> > using otherwise the same command line options as native build. >> >> I have expanded the poudriere bulk's tar of the failure and rerun the >> command from there. The problem reproduced: >> >> # ls -lTdt /tmp/nir_constant_expressions-9b094e.* >> -rw-r--r-- 1 root wheel11069 May 23 12:08:35 2019 >> /tmp/nir_constant_expressions-9b094e.sh >> -rw-r--r-- 1 root wheel 1951892 May 23 12:08:35 2019 >> /tmp/nir_constant_expressions-9b094e.c >> >> >> So I gzip'd the .c and created: >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238082 >> >> with the two files as 2 attachments. > > This looks familiar to me. Is the kernel you are using at r348115 or newer? > > r348115 triggers such kind of "unable to execute" compiler errors on my > system. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238084 Bug 238082 unlike bug 238084 can be reproduced even on amd64 just by running the generated files. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Policy on closing bugs
Hey, Is there any policy/document when a bug can be closed? For example, is it OK to close a bug that is fixed upstream but not yet in ports? Thanks GrzegorzJ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
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/po...@freebsd.org.html Port| Current version | New version +-+ databases/jasperreports | 5.5.2 | 6.8.1 +-+ 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 Thanks. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: powerpc64 graphics/mesa-dri build failure in poudriere, system clang's /usr/bin/cc got assert failure: "Target supports vector op, but scalar requires expansion?"
On 2019-May-24, at 00:10, Ralf Wenk wrote: > On 2019-05-23, at 12:31 -0700, Mark Millard wrote: >> On 2019-May-23, at 11:47, Jan Beich wrote: >> >>> Mark Millard writes: >>> Unfortunately poudiere bulk tar archives of failures do not catch the /tmp/* material from: cc: error: unable to execute command: Abort trap (core dumped) cc: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM 8.0.0) Target: powerpc64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin >>> >>> Do you have the build log? Maybe it's possible to reproduce simply by adding >>> -target powerpc64-unknown-freebsd13.0 while cross-building that particular >>> file >>> using otherwise the same command line options as native build. >> >> I have expanded the poudriere bulk's tar of the failure and rerun the >> command from there. The problem reproduced: >> >> # ls -lTdt /tmp/nir_constant_expressions-9b094e.* >> -rw-r--r-- 1 root wheel11069 May 23 12:08:35 2019 >> /tmp/nir_constant_expressions-9b094e.sh >> -rw-r--r-- 1 root wheel 1951892 May 23 12:08:35 2019 >> /tmp/nir_constant_expressions-9b094e.c >> >> >> So I gzip'd the .c and created: >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238082 >> >> with the two files as 2 attachments. > > This looks familiar to me. Is the kernel you are using at r348115 or newer? No, based on head -r347549 : # uname -apKU FreeBSD FBSDG5L 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r347549M: Wed May 22 15:14:43 PDT 2019 markmi@FBSDG5L:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1300025 1300025 > r348115 triggers such kind of "unable to execute" compiler errors on my > system. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238084 I've had no troubles with buildworld or buildkernel. "Unable to execute" is very generic, meaning little more than did-not-finish for whatever reason. In my case it did not finish because: assert(!TLI.isOperationLegalOrCustom(N->getOpcode(), WideVecVT) && "Target supports vector op, but scalar requires expansion?"); failed the test and assert called abort, whihc in turn sent a SIGABRT to the process. Nothing about this suggests a kernel issue. It is more likely a error in handling code generation related to powerpc64 vector operations. I used the core file produced to get the backtrace via gdb: Core was generated by `/usr/bin/cc -cc1 -triple powerpc64-unknown-freebsd13.0 -emit-obj -disable-free -'. Program terminated with signal SIGABRT, Aborted. #0 .__sys_thr_kill () at thr_kill.S:3 3 RSYSCALL(thr_kill) (gdb) bt #0 .__sys_thr_kill () at thr_kill.S:3 #1 0x133072d0 in __raise (s=330578472) at /usr/src/lib/libc/gen/raise.c:52 #2 0x132c7898 in abort () at /usr/src/lib/libc/stdlib/abort.c:79 #3 0x132f6c64 in __assert (func=, file=, line=, failedexpr=) at /usr/src/lib/libc/gen/assert.c:51 #4 0x130f7c18 in WidenVectorResult () at /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp:2531 #5 0x12ad91f0 in run () at /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp:281 #6 0x12adfa5c in LegalizeTypes () at /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp:1115 #7 0x1297ebb4 in CodeGenAndEmitDAG () at /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:776 #8 0x1297e114 in SelectBasicBlock () at /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:669 #9 0x1297cbc4 in SelectAllBasicBlocks () at /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1784 #10 0x in ?? () But I build with debug symbols generally, even for optimized builds. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: powerpc64 graphics/mesa-dri build failure in poudriere, system clang's /usr/bin/cc got assert failure: "Target supports vector op, but scalar requires expansion?"
On 2019-05-23, at 12:31 -0700, Mark Millard wrote: > On 2019-May-23, at 11:47, Jan Beich wrote: > > > Mark Millard writes: > > > >> Unfortunately poudiere bulk tar archives of failures do not > >> catch the /tmp/* material from: > >> > >> cc: error: unable to execute command: Abort trap (core dumped) > >> cc: error: clang frontend command failed due to signal (use -v to see > >> invocation) > >> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM > >> 8.0.0) > >> Target: powerpc64-unknown-freebsd13.0 > >> Thread model: posix > >> InstalledDir: /usr/bin > > > > Do you have the build log? Maybe it's possible to reproduce simply by adding > > -target powerpc64-unknown-freebsd13.0 while cross-building that particular > > file > > using otherwise the same command line options as native build. > > I have expanded the poudriere bulk's tar of the failure and rerun the > command from there. The problem reproduced: > > # ls -lTdt /tmp/nir_constant_expressions-9b094e.* > -rw-r--r-- 1 root wheel11069 May 23 12:08:35 2019 > /tmp/nir_constant_expressions-9b094e.sh > -rw-r--r-- 1 root wheel 1951892 May 23 12:08:35 2019 > /tmp/nir_constant_expressions-9b094e.c > > > So I gzip'd the .c and created: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238082 > > with the two files as 2 attachments. This looks familiar to me. Is the kernel you are using at r348115 or newer? r348115 triggers such kind of "unable to execute" compiler errors on my system. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238084 Ralf ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
INDEX now builds successfully on 11.x
___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
