Created attachment 148099 [details] typo3-lts-6.2.5.patch - Update to 6.2.5 - https://typo3.org/news/article/typo3-cms-4536-6111-and-625-released/ Generated with FreeBSD Port Tools 1.02 (mode: update, diff: suffix)
If you had run this in poudriere with stage-qa checks, you would have seen the @dirrm* lines in the plist need to be removed, so you need to update the patch. But while on the topic, why is this pkg-plist autogenerated? how many lines does it end up being? (check in $WRKDIR to see generated plist). autogen is highly frowned on, it's usually accepted with hugh plists or very hard to create when static plists. I don't know if this fits the bill.
P.S. please provide poudriere logs with future patches, if at all possible.
- I neither use poudriere, nor do I have ressources to do so - The pkg-plist has ~12k lines and ~1.2MB. Please see also PR190341
PS: See also www/typo3, I also want to switch to auto generated as my patches always were rejected as they were too big
(In reply to Helmut Ritter from comment #3) > - I neither use poudriere, nor do I have ressources to do so > - The pkg-plist has ~12k lines and ~1.2MB. Please see also PR190341 I don't think you are understanding me. You cannot have "@dirrm" lines in pkg-plist anymore, so I'm expecting a patch. Likewise, removing these lines means pkg-plist will be considerably shorter. Other approaches to shortening pkg-plist involves the use of PORTDOCS and PORTEXAMPLES definitions. So I would want to see the output of "make makeplist" somewhere to see what this pkg-plist really looks like and how long it really is, especially after removing @dirrm lines, PORTDOCS lines, and PORTEXAMPLES lines (should they exist) To be clear: At least one new submission is expected to fix your autogen logic. From there, we can discuss if autogen is justified.
(In reply to Helmut Ritter from comment #3) > - I neither use poudriere, nor do I have ressources to do so If that's true, that significantly impacts your ability to submit good patches and you're shifting QA work to committers. As a volunteer committer with limited time and no obligation to take any PR, I cherry pick poudriere-tested PRs from the pile. I expect other committers do the same because they don't want to be stuck doing QA on ports.
John, I'm maintaining this port to make a small contribution to FreeBSD. I even do not use Typo3 at all. So if you want me to drop maintainership or if you completely want to remove Typo3 from the ports tree just do so. If not please point a spare time freebsd user (me) to an appropriate location so I can continue to contribute my part to the FreeBSD project. Best Regards, Helmut
(In reply to Helmut Ritter from comment #7) > So if you want me to drop maintainership or if you completely want to remove > Typo3 from the ports tree just do so. I don't want to tell you to do anything. But you also should not expect that shifting QA of the port you volunteered to maintain will make it attractive. Speaking for myself, I really don't care at all when ports are removed from the tree. Some users think it's the biggest sin in the world ("it was *building*, how dare you remove it?!") Maybe nobody cares about this port at all. I have no idea what the port even does so I don't have an opinion on that. I just wanted to point out that there's no kind of "prime directive" to save ports at any cost. > If not please point a spare time freebsd user (me) to an appropriate > location so I can continue to contribute my part to the FreeBSD project. I don't know what this is asking. This whole thing started when I asked if you could (optionally) provide a poudriere laptop and you said you had no resources. Unless your freebsd is a 5G VM or a atom-cpu laptop, I would be surprised if you truly can't use it. You said you didn't want to provide the logs. You aren't required to, so really that's the end of the story. I'm not going to take the PR though. I've got a 150 others to choose from where a big percentage of the submitters do provide test logs. All I was doing is "triage" which is where I say, "hey, this PR is probably ready to be committed" and move it to "patch-ready" status so that the person committing it is highly confident that not much work, if any, is needed on that PR. Without running this though poudriere myself, or using other factors like reputation from previous work or educated guess from the patch itself, I can't don't that. Anyway -- no need to do anything. Somebody else may come by doing triage and think differently, or may just take the PR and commit it. That's their prerogative.
(In reply to John Marino from comment #8) > (In reply to Helmut Ritter from comment #7) > > If not please point a spare time freebsd user (me) to an appropriate > > location so I can continue to contribute my part to the FreeBSD project. > > I don't know what this is asking. > > > This whole thing started when I asked if you could (optionally) provide a > poudriere laptop and you said you had no resources. Unless your freebsd is > a 5G VM or a atom-cpu laptop, I would be surprised if you truly can't use > it. Actually I use a VM with a single CPU with 256MB of RAM. I never heard about poudriere before so I had to google it. I'm no sysadmin, I even don't remember when and how I inherited the maintainership of Typo3. So the resources I'm talking about is time to install poudriere, read a handbook, set up the system, and so on - to maintain one single port that copies over the source tarball to /usr/local/www and adjusts some permissions. For a port that I even do not use at all. > You said you didn't want to provide the logs. You aren't required to, > so really that's the end of the story. Quote where I did so. To the contrary I asked you what I can do to support you (apart from poudiere logs) and you refused the answer. THAT might be the end of the story. So to get back on-topic, is there anything that I can provide to help committers apart from poudriere? Would the output of porttools help?
(In reply to Helmut Ritter from comment #9) > Actually I use a VM with a single CPU with 256MB of RAM. I never heard about > poudriere before so I had to google it. I'm no sysadmin, I even don't > remember when and how I inherited the maintainership of Typo3. 5G reference the virtual disk size but 256M RAM is probably too low. Unless the VM is seriously beefy (e.g. 40G hard disk, 768M or 1G RAM) then yes, your actual resources are probably too low. > So the resources I'm talking about is time to install poudriere, this takes less 1 minute even to build from source > read a handbook, set up the system, and so on - *this* is the problem. Adequate (IMO) how-to guides don't exist. Riggs@ was going to write one, I need to see where he is on that. > to maintain one single port that copies over the source tarball to /usr/local/www and adjusts some > permissions. For a port that I even do not use at all. > > > You said you didn't want to provide the logs. You aren't required to, > > so really that's the end of the story. > > Quote where I did so. JRM: "P.S. please provide poudriere logs with future patches, if at all possible." You: "I neither use poudriere, nor do I have ressources to do so" I think reasonable minds interpret that response as "I don't want to" or at least, "I can't". > To the contrary I asked you what I can do to support you (apart from > poudiere logs) and you refused the answer. THAT might be the end of the > story. Because there is nothing equivalent to poudriere. Not redports, not tinderbox, not local building, not DEVEOPER_MODE=yes > So to get back on-topic, is there anything that I can provide to help > committers apart from poudriere? Would the output of porttools help? No. A slight improvement would be the outputs of # make check-plist # make stage-qa # portlint That's better than nothing. It's probably good enough for a port that just copies files instead of building.
The update to 6.2.6 should have been to this PR, not a new one. *** This bug has been marked as a duplicate of bug 194710 ***