Re: Help implementing a py-pyside2 port?
I will look into a better example. The documentation is nearly nonexistent, and that is clearly a problem. I will try to bump it up on my priority list. -Marcus > On Aug 18, 2018, at 5:11 PM, Perry E. Metzger wrote: > > On Sat, 18 Aug 2018 14:58:58 -0700 Marcus Calhoun-Lopez > wrote: >> I can offer what help I can. >> Do you have a specific concern yet? >> >> Just from a very cursory look at PySide2, the port >> py37-qscintilla-qt5 might provide a starting point. > > The qscintilla Portfiles are some of the most complicated ones I've > ever seen. I don't understand them very well. Are there any other > Python + Qt5 ports out there? Alternatively, is there any > documentation on the qt5 portgroup? > > Perry > > >> >> -Marcus >> >>> On Aug 18, 2018, at 11:22 AM, Perry E. Metzger >>> wrote: >>> >>> I'm interested in creating a port for PySide2 (the official Python >>> bindings for Qt5) but I don't really have much experience >>> packaging things for Qt. Would anyone be willing to advise me? >>> >>> -- >>> Perry E. Metzgerpmetz...@macports.org >> > > > > -- > Perry E. Metzger pmetz...@macports.org
Re: Help implementing a py-pyside2 port?
On Sat, 18 Aug 2018 14:58:58 -0700 Marcus Calhoun-Lopez wrote: > I can offer what help I can. > Do you have a specific concern yet? > > Just from a very cursory look at PySide2, the port > py37-qscintilla-qt5 might provide a starting point. The qscintilla Portfiles are some of the most complicated ones I've ever seen. I don't understand them very well. Are there any other Python + Qt5 ports out there? Alternatively, is there any documentation on the qt5 portgroup? Perry > > -Marcus > > > On Aug 18, 2018, at 11:22 AM, Perry E. Metzger > > wrote: > > > > I'm interested in creating a port for PySide2 (the official Python > > bindings for Qt5) but I don't really have much experience > > packaging things for Qt. Would anyone be willing to advise me? > > > > -- > > Perry E. Metzgerpmetz...@macports.org > -- Perry E. Metzgerpmetz...@macports.org
Re: Help implementing a py-pyside2 port?
I can offer what help I can. Do you have a specific concern yet? Just from a very cursory look at PySide2, the port py37-qscintilla-qt5 might provide a starting point. -Marcus > On Aug 18, 2018, at 11:22 AM, Perry E. Metzger wrote: > > I'm interested in creating a port for PySide2 (the official Python > bindings for Qt5) but I don't really have much experience packaging > things for Qt. Would anyone be willing to advise me? > > -- > Perry E. Metzger pmetz...@macports.org
Re: "size" documentation
On 2018-08-18 09:53, Jan Stary wrote: > On Aug 17 22:06:13, c...@macports.org wrote: >> I think the idea of the size keyword is to start to use it to display >> download progress bars for servers that do not send a Content-Length >> HTTP header (or do not have an equivalent of such a header due to the >> used protocol). > > How many of the total number of ports have their distfiles served > by such servers? Would it be simpler to just not display a progress bar > in those cases, as opposed to introducing another keyword? Yes, that is the current implementation. Specifying "size" is simple and might have a use case in the future. > If the idea is to help display a progress bar (please make it in color), > why is it a 'checksum'? We already have much beter checksums. Well, adding it at any other place would add more complexity and confusion. The file size is a checksum. > curl it the one doing the download. If it can display a progress bar, > it will. If not, please leave it like that. > >> This is currently not implemented. > > Reminds me of 'platforms'. Patches are still welcome... Rainer
Help implementing a py-pyside2 port?
I'm interested in creating a port for PySide2 (the official Python bindings for Qt5) but I don't really have much experience packaging things for Qt. Would anyone be willing to advise me? -- Perry E. Metzgerpmetz...@macports.org
Re: squash and merge, license documentation, "size" documentation
Hi, On 18 August 2018 at 12:47, Perry E. Metzger wrote: > On Fri, 17 Aug 2018 22:15:38 -0700 Eitan Adler wrote: >> On Fri, 17 Aug 2018 at 06:44, Perry E. Metzger wrote: >> > >> > As many of you are aware, I merge a significant fraction of the >> > pull requests these days. A few requests to make it easier, these >> > three things on their own represent a surprising fraction of the >> > communication I need to have with contributors: >> ... >> >> As an FYI, unless the contributor disabled the option, you can push >> the branch of the PR. This way you could avoid some of the back and >> forth. > > It's a heck of a lot more work to do that, and I often have fairly > little time for this, sadly. It's much easier to tell someone (for > example) to add the size field than it would be for me to check out > the repo, edit, and push. > > What I was hoping was that "port lint" would catch more of these > things (bad license names, missing fields, etc.) so that people would > know on their own that there was something wrong. Having a human > detect these things isn't optimal anyway. I totally agree with Perry on this. The difference between fixing someone's PR vs. just accepting it is enormous. Accepting a PR can be done by a single click on a mobile phone while going for a walk :), while fixing it requires lots of steps for which I always need a copy-and-paste cheat-sheet with quite some commands. Fixing one or two is not a big deal, but fixing thousand of them (which is probably not an overestimation of how many Perry merged) adds up. We definitely need automatic way for feedback to users submitting PRS to make sure that: - proper checksums are included (could be done with lint) - only valid licences are listed (could be done with lint) - maintainers are listed with both email & github handles - create a warning in case multiple commits touch the same file(s) (with explanation that this could be a valid case) - create a warning if commit message doesn't pass some super basic checks (MP bot could also say thank you after PR gets merged - not sure if this is a good idea, but ... :) :) :) Mojca
Re: squash and merge, license documentation, "size" documentation
On Fri, 17 Aug 2018 22:15:38 -0700 Eitan Adler wrote: > On Fri, 17 Aug 2018 at 06:44, Perry E. Metzger > wrote: > > > > As many of you are aware, I merge a significant fraction of the > > pull requests these days. A few requests to make it easier, these > > three things on their own represent a surprising fraction of the > > communication I need to have with contributors: > ... > > As an FYI, unless the contributor disabled the option, you can push > the branch of the PR. This way you could avoid some of the back and > forth. It's a heck of a lot more work to do that, and I often have fairly little time for this, sadly. It's much easier to tell someone (for example) to add the size field than it would be for me to check out the repo, edit, and push. What I was hoping was that "port lint" would catch more of these things (bad license names, missing fields, etc.) so that people would know on their own that there was something wrong. Having a human detect these things isn't optimal anyway. Perry -- Perry E. Metzgerpe...@piermont.com
Re: the size checksum
On Aug 18 08:37:07, jon...@hep.phy.cam.ac.uk wrote: > This is being discussed in another thread. Guess you did not see that.. Yes; sorry for not reading ahead. > > On 18 Aug 2018, at 8:16 am, Jan Starý wrote: > > > > Hi all, > > > > beside sha25 and rmd160, some ports use a 'size' field in the checksums. > > Why was it added? The fact that the distfile has the prescribed sha256 > > and the prescribed rmd160 makes it almost certain (as certain as crypto > > checksums can be) it is the intended file. The fact that it has a prescribed > > size IMHO adds nothing to that certainty. Or does it? > > > >Jan > > >
Re: "size" documentation
On Aug 17 10:19:17, m...@macports.org wrote: > > On Aug 17, 2018, at 7:44 AM, Perry E. Metzger wrote: > > 3. There's no real documentation of the "size" parameter to > > checksums, and I'm constantly asking people to add the size. Note > > that I don't think "size" is a reasonable thing to require given that > > finding two files of the same size with the same SHA-2 hash is > > probably worth a doctoral dissertation at this point, but if we are > > going to require it (why do we require it?), it should be documented, > > and port lint should complain that it isn't there, and doing > > port -v checksums should spit it out if it isn't there. > > The size is also useful for giving user feedback > on the download time remaining. On Aug 17 22:06:13, c...@macports.org wrote: > I think the idea of the size keyword is to start to use it to display > download progress bars for servers that do not send a Content-Length > HTTP header (or do not have an equivalent of such a header due to the > used protocol). How many of the total number of ports have their distfiles served by such servers? Would it be simpler to just not display a progress bar in those cases, as opposed to introducing another keyword? If the idea is to help display a progress bar (please make it in color), why is it a 'checksum'? We already have much beter checksums. curl it the one doing the download. If it can display a progress bar, it will. If not, please leave it like that. > This is currently not implemented. Reminds me of 'platforms'. Jan
Re: the size checksum
This is being discussed in another thread. Guess you did not see that.. > On 18 Aug 2018, at 8:16 am, Jan Starý wrote: > > Hi all, > > beside sha25 and rmd160, some ports use a 'size' field in the checksums. > Why was it added? The fact that the distfile has the prescribed sha256 > and the prescribed rmd160 makes it almost certain (as certain as crypto > checksums can be) it is the intended file. The fact that it has a prescribed > size IMHO adds nothing to that certainty. Or does it? > >Jan >
the size checksum
Hi all, beside sha25 and rmd160, some ports use a 'size' field in the checksums. Why was it added? The fact that the distfile has the prescribed sha256 and the prescribed rmd160 makes it almost certain (as certain as crypto checksums can be) it is the intended file. The fact that it has a prescribed size IMHO adds nothing to that certainty. Or does it? Jan
