purritobin-0.1.2 - new package + dependencies

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

purritobin-0.1.2 - new package + dependencies

Aisha Tammy
Hey All,
 I am adding a new package with its 2 dependencies, so a total
of 3 new packages.

Tested on amd64 and arm64, currently hosted at https://bsd.ac .
None of the code is platform specific so should be working on all.

comments? OK?

Aisha

purritobin-0.1.2.tar.gz (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: purritobin-0.1.2 - new package + dependencies

Aisha Tammy
Updated to latest 0.1.3 and attached.

On 4/30/20 8:05 AM, Aisha Tammy wrote:

> Hey All,
>  I am adding a new package with its 2 dependencies, so a total
> of 3 new packages.
>
> Tested on amd64 and arm64, currently hosted at https://bsd.ac .
> None of the code is platform specific so should be working on all.
>
> comments? OK?
>
> Aisha
>

purritobin-0.1.3.tar.gz (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: purritobin-0.1.2 - new package + dependencies

Aisha Tammy
fixed bug in Makefile of usockets, which did not have correct LIB DEPENDS

attached new tar.gz

OK ?

Aisha

On 4/30/20 2:44 PM, Aisha Tammy wrote:

> Updated to latest 0.1.3 and attached.
>
> On 4/30/20 8:05 AM, Aisha Tammy wrote:
>> Hey All,
>>  I am adding a new package with its 2 dependencies, so a total
>> of 3 new packages.
>>
>> Tested on amd64 and arm64, currently hosted at https://bsd.ac .
>> None of the code is platform specific so should be working on all.
>>
>> comments? OK?
>>
>> Aisha
>>

purritobin-0.1.3.tar.gz (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: purritobin-0.1.2 - new package + dependencies

Thomas Frohwein-2
On Thu, Apr 30, 2020 at 11:16:06PM -0400, Aisha Tammy wrote:
> fixed bug in Makefile of usockets, which did not have correct LIB DEPENDS
>
> attached new tar.gz
>
> OK ?

This looks like an interesting port, but with the release approaching,
it may be best to take time after 6.7 is out. Especially as upstream is
currently issuing a new release every day [1]. Probably best to let this
mature a little more. It also helps to attract interest in a new port by
describing a bit more what it does when you propose it; its use case,
where it may fill a need not currently met by other ports etc...

Reply | Threaded
Open this post in threaded view
|

Re: purritobin-0.1.2 - new package + dependencies

Aisha Tammy
Dear Thomas,

On 5/1/20 1:08 PM, Thomas Frohwein wrote:
> On Thu, Apr 30, 2020 at 11:16:06PM -0400, Aisha Tammy wrote:
>> fixed bug in Makefile of usockets, which did not have correct LIB DEPENDS
>>
>> attached new tar.gz
>>
>> OK ?
> This looks like an interesting port, but with the release approaching,
> it may be best to take time after 6.7 is out. Especially as upstream is
> currently issuing a new release every day [1]. Probably best to let this

Of course, I totally agree. I'm in no hurry to get this in just now.
I'm just sending it out so that it can stay in my mail box and I
don't forget about it in my git mess.

> mature a little more. It also helps to attract interest in a new port by
> describing a bit more what it does when you propose it; its use case,
> where it may fill a need not currently met by other ports etc...

Thanks a lot, I will add all this to the port DESCR and attach it with the
bug fixes mentioned by Brian Callahan (thanks Brian).

Aisha

Reply | Threaded
Open this post in threaded view
|

Re: purritobin-0.1.2 - new package + dependencies

Stuart Henderson
On 2020/05/01 14:06, Aisha Tammy wrote:

> Dear Thomas,
>
> On 5/1/20 1:08 PM, Thomas Frohwein wrote:
> > On Thu, Apr 30, 2020 at 11:16:06PM -0400, Aisha Tammy wrote:
> >> fixed bug in Makefile of usockets, which did not have correct LIB DEPENDS
> >>
> >> attached new tar.gz
> >>
> >> OK ?
> > This looks like an interesting port, but with the release approaching,
> > it may be best to take time after 6.7 is out. Especially as upstream is
> > currently issuing a new release every day [1]. Probably best to let this
>
> Of course, I totally agree. I'm in no hurry to get this in just now.
> I'm just sending it out so that it can stay in my mail box and I
> don't forget about it in my git mess.

btw you're more likely to find it in your git mess, than committers are likely
to find it in a couple of weeks of ports@ backlog after we're done with release.

Reply | Threaded
Open this post in threaded view
|

Re: purritobin-0.1.2 - new package + dependencies

Aisha Tammy
On 5/2/20 8:19 AM, Stuart Henderson wrote:

> On 2020/05/01 14:06, Aisha Tammy wrote:
>> Dear Thomas,
>>
>> On 5/1/20 1:08 PM, Thomas Frohwein wrote:
>>> On Thu, Apr 30, 2020 at 11:16:06PM -0400, Aisha Tammy wrote:
>>>> fixed bug in Makefile of usockets, which did not have correct LIB DEPENDS
>>>>
>>>> attached new tar.gz
>>>>
>>>> OK ?
>>> This looks like an interesting port, but with the release approaching,
>>> it may be best to take time after 6.7 is out. Especially as upstream is
>>> currently issuing a new release every day [1]. Probably best to let this
>>
>> Of course, I totally agree. I'm in no hurry to get this in just now.
>> I'm just sending it out so that it can stay in my mail box and I
>> don't forget about it in my git mess.
>
> btw you're more likely to find it in your git mess, than committers are likely
> to find it in a couple of weeks of ports@ backlog after we're done with release.
>
lol that is quite true.  
Thankfully thunderbird allows me to set reminders on mails
that should be revisited, which unfortunately I haven't figured out yet in GIT

what if i bribe the devs with some bananas and some treats, they might be likely
to add this sooner then. /food for thought (pun intended)

Cheers,
Aisha

Reply | Threaded
Open this post in threaded view
|

Re: purritobin-0.1.2 - new package + dependencies

Aisha Tammy-5
In reply to this post by Stuart Henderson
Hi,

  I've attached the port again, with a few more fixes.

Would love to see this added.



A few words about this port:

  It is a minimalistic pastebin client which allows you to also

paste encrypted texts and has a simple javascript decryptor frontend.

It is asynchronous and allows you to limit the paste size and a

location where the pastes are stored.

It uses unveil and pledge to make sure that only the necessary

folders and permissions are used.



Really hope this can be added and would love to get any advice about

how to improve this port :)



Aisha

purritobin-0.2.1.tar.gz (1K) Download Attachment
uwebsockets-0.17.6.tar.gz (1K) Download Attachment
usockets-0.4.0.tar.gz (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: purritobin-0.1.2 - new package + dependencies

Brian Callahan-6
Hi Aisha --

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, May 31, 2020 10:03 PM, Aisha Tammy <[hidden email]> wrote:

> Hi,
>
> I've attached the port again, with a few more fixes.
>
> Would love to see this added.
>
> A few words about this port:
>
> It is a minimalistic pastebin client which allows you to also
>
> paste encrypted texts and has a simple javascript decryptor frontend.
>
> It is asynchronous and allows you to limit the paste size and a
>
> location where the pastes are stored.
>
> It uses unveil and pledge to make sure that only the necessary
>
> folders and permissions are used.
>
> Really hope this can be added and would love to get any advice about
>
> how to improve this port :)
>
> Aisha
Thanks for the ports. I've attached improved versions of the ports
that address what I'll talk about in this email. I'll take each
separately.

usockets:
* I see that it compiles with -std=c11, so we need to have a
  COMPILER=base-clang ports-gcc line.
* The Makefile has some -O3 lines, so those go. It also has some -flto
  lines. I don't believe all our archs can support -flto at the moment
  so I removed them too.
* I am not sure why you create and install a shared version of this
  library. It seems like upstream intends for this to be statically
  linked into executables. Indeed, you don't even use the shared
  version of the library in PurritoBin, so I think it can go.
* Your patch to the Makefile causes everything to be recompiled at
  fake time.
* Not related to your port, but too bad that we are stuck using libuv
  (it can use kqueue but it uses extensions from FreeBSD that we don't
  have).

uwebsockets:
* Upstream claims this is a web server so I moved the category to www.
  Devel is quite full. Otherwise this port is quite straightforward.

purritobin:
* Since you're using the static version of usocket, we can simplify
  your depends lists.

~Brian


usockets.tgz (2K) Download Attachment
uwebsockets.tgz (1K) Download Attachment
purritobin.tgz (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: purritobin-0.1.2 - new package + dependencies

Aisha Tammy-5
On 6/1/20 6:13 PM, Brian Callahan wrote:

> Hi Aisha --
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Sunday, May 31, 2020 10:03 PM, Aisha Tammy <[hidden email]> wrote:
>
>> Hi,
>>
>> I've attached the port again, with a few more fixes.
>>
>> Would love to see this added.
>>
>> A few words about this port:
>>
>> It is a minimalistic pastebin client which allows you to also
>>
>> paste encrypted texts and has a simple javascript decryptor frontend.
>>
>> It is asynchronous and allows you to limit the paste size and a
>>
>> location where the pastes are stored.
>>
>> It uses unveil and pledge to make sure that only the necessary
>>
>> folders and permissions are used.
>>
>> Really hope this can be added and would love to get any advice about
>>
>> how to improve this port :)
>>
>> Aisha
>
> Thanks for the ports. I've attached improved versions of the ports
> that address what I'll talk about in this email. I'll take each
> separately.
>
> usockets:
> * I see that it compiles with -std=c11, so we need to have a
>   COMPILER=base-clang ports-gcc line.
> * The Makefile has some -O3 lines, so those go. It also has some -flto
>   lines. I don't believe all our archs can support -flto at the moment
>   so I removed them too.
> * I am not sure why you create and install a shared version of this
>   library. It seems like upstream intends for this to be statically
>   linked into executables. Indeed, you don't even use the shared
>   version of the library in PurritoBin, so I think it can go.
> * Your patch to the Makefile causes everything to be recompiled at
>   fake time.
> * Not related to your port, but too bad that we are stuck using libuv
>   (it can use kqueue but it uses extensions from FreeBSD that we don't
>   have).
>
OMG thank you so much.
I really appreciate all your help :)
I'm still new to the whole C/C++ packaging and linking and everything
so I just gave all the options possible.

Yea, I had to look around for using EVFILT_USER not being present :(
before I had to start using libuv.
Someone had tried to port it at some point but I don't think
it went anywhere.

> uwebsockets:
> * Upstream claims this is a web server so I moved the category to www.
>   Devel is quite full. Otherwise this port is quite straightforward.
>
> purritobin:
> * Since you're using the static version of usocket, we can simplify
>   your depends lists.
>
Thanks again for all of this.

Aisha

> ~Brian
>

Reply | Threaded
Open this post in threaded view
|

Re: purritobin-0.1.2 - new package + dependencies

Stuart Henderson
In reply to this post by Brian Callahan-6
On 2020/06/01 22:13, Brian Callahan wrote:

> Hi Aisha --
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Sunday, May 31, 2020 10:03 PM, Aisha Tammy <[hidden email]> wrote:
>
> > Hi,
> >
> > I've attached the port again, with a few more fixes.
> >
> > Would love to see this added.
> >
> > A few words about this port:
> >
> > It is a minimalistic pastebin client which allows you to also
> >
> > paste encrypted texts and has a simple javascript decryptor frontend.
> >
> > It is asynchronous and allows you to limit the paste size and a
> >
> > location where the pastes are stored.
> >
> > It uses unveil and pledge to make sure that only the necessary
> >
> > folders and permissions are used.
> >
> > Really hope this can be added and would love to get any advice about
> >
> > how to improve this port :)
> >
> > Aisha
>
> Thanks for the ports. I've attached improved versions of the ports
> that address what I'll talk about in this email. I'll take each
> separately.
>
> usockets:
> * I see that it compiles with -std=c11, so we need to have a
>   COMPILER=base-clang ports-gcc line.
> * The Makefile has some -O3 lines, so those go. It also has some -flto
>   lines. I don't believe all our archs can support -flto at the moment
>   so I removed them too.
> * I am not sure why you create and install a shared version of this
>   library. It seems like upstream intends for this to be statically
>   linked into executables. Indeed, you don't even use the shared
>   version of the library in PurritoBin, so I think it can go.
> * Your patch to the Makefile causes everything to be recompiled at
>   fake time.
> * Not related to your port, but too bad that we are stuck using libuv
>   (it can use kqueue but it uses extensions from FreeBSD that we don't
>   have).
>
> uwebsockets:
> * Upstream claims this is a web server so I moved the category to www.
>   Devel is quite full. Otherwise this port is quite straightforward.
>
> purritobin:
> * Since you're using the static version of usocket, we can simplify
>   your depends lists.
>
> ~Brian
>




purritobin
- Makefile:
  - add "uses pledge()" above wantlib as done in other ports
- pkg/DESCR:
  - trailing blank line
  - s/writted/written

All these static libraries mean that things won't get updated
automatically when a library is updated. Say you install purritobin
and there is a later security fix to usockets; purritobin won't be
updated unless you manually force it (e.g. by bumping REVISION).
The normal way of handling this with almost everything else in ports
is to use shared libraries.

Reply | Threaded
Open this post in threaded view
|

Re: purritobin-0.1.2 - new package + dependencies

Aisha Tammy-5
On 6/2/20 8:50 AM, Stuart Henderson wrote:

> On 2020/06/01 22:13, Brian Callahan wrote:
>> Hi Aisha --
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Sunday, May 31, 2020 10:03 PM, Aisha Tammy <[hidden email]> wrote:
>>
>>> Hi,
>>>
>>> I've attached the port again, with a few more fixes.
>>>
>>> Would love to see this added.
>>>
>>> A few words about this port:
>>>
>>> It is a minimalistic pastebin client which allows you to also
>>>
>>> paste encrypted texts and has a simple javascript decryptor frontend.
>>>
>>> It is asynchronous and allows you to limit the paste size and a
>>>
>>> location where the pastes are stored.
>>>
>>> It uses unveil and pledge to make sure that only the necessary
>>>
>>> folders and permissions are used.
>>>
>>> Really hope this can be added and would love to get any advice about
>>>
>>> how to improve this port :)
>>>
>>> Aisha
>>
>> Thanks for the ports. I've attached improved versions of the ports
>> that address what I'll talk about in this email. I'll take each
>> separately.
>>
>> usockets:
>> * I see that it compiles with -std=c11, so we need to have a
>>   COMPILER=base-clang ports-gcc line.
>> * The Makefile has some -O3 lines, so those go. It also has some -flto
>>   lines. I don't believe all our archs can support -flto at the moment
>>   so I removed them too.
>> * I am not sure why you create and install a shared version of this
>>   library. It seems like upstream intends for this to be statically
>>   linked into executables. Indeed, you don't even use the shared
>>   version of the library in PurritoBin, so I think it can go.
>> * Your patch to the Makefile causes everything to be recompiled at
>>   fake time.
>> * Not related to your port, but too bad that we are stuck using libuv
>>   (it can use kqueue but it uses extensions from FreeBSD that we don't
>>   have).
>>
>> uwebsockets:
>> * Upstream claims this is a web server so I moved the category to www.
>>   Devel is quite full. Otherwise this port is quite straightforward.
>>
>> purritobin:
>> * Since you're using the static version of usocket, we can simplify
>>   your depends lists.
>>
>> ~Brian
>>
>
>
>
>
> purritobin
> - Makefile:
>   - add "uses pledge()" above wantlib as done in other ports
will do thanks!

> - pkg/DESCR:
>   - trailing blank line
>   - s/writted/written
will fix thanks!

>
> All these static libraries mean that things won't get updated
> automatically when a library is updated. Say you install purritobin
> and there is a later security fix to usockets; purritobin won't be
> updated unless you manually force it (e.g. by bumping REVISION).
> The normal way of handling this with almost everything else in ports
> is to use shared libraries.
>
I totally agree but upstream has mandated that this library is to be used
static only and with -flto -O3 (which Brian has removed stating unsupported archs, thanks brian!).
Upstream have also rejected my patch to add shared libraries :( and is adamant
on using both the above flags (which was a separate issue that was raised, to
remove the flags and make them optional depending on distribution)

Does ports not handle such an automated revision bump for static libraries
that get updated? (am just asking, I don't know the intricacies and details
of shared/static library things)

I am not sure how to resolve this conflict...


an aside: why was -O3 removed, upstream has it present and wants it to be there?


Aisha

Reply | Threaded
Open this post in threaded view
|

Re: purritobin-0.1.2 - new package + dependencies

Aisha Tammy-5
In reply to this post by Stuart Henderson
On 6/2/20 8:50 AM, Stuart Henderson wrote:

> On 2020/06/01 22:13, Brian Callahan wrote:
>> Hi Aisha --
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Sunday, May 31, 2020 10:03 PM, Aisha Tammy <[hidden email]> wrote:
>>
>>> Hi,
>>>
>>> I've attached the port again, with a few more fixes.
>>>
>>> Would love to see this added.
>>>
>>> A few words about this port:
>>>
>>> It is a minimalistic pastebin client which allows you to also
>>>
>>> paste encrypted texts and has a simple javascript decryptor frontend.
>>>
>>> It is asynchronous and allows you to limit the paste size and a
>>>
>>> location where the pastes are stored.
>>>
>>> It uses unveil and pledge to make sure that only the necessary
>>>
>>> folders and permissions are used.
>>>
>>> Really hope this can be added and would love to get any advice about
>>>
>>> how to improve this port :)
>>>
>>> Aisha
>>
>> Thanks for the ports. I've attached improved versions of the ports
>> that address what I'll talk about in this email. I'll take each
>> separately.
>>
>> usockets:
>> * I see that it compiles with -std=c11, so we need to have a
>>   COMPILER=base-clang ports-gcc line.
>> * The Makefile has some -O3 lines, so those go. It also has some -flto
>>   lines. I don't believe all our archs can support -flto at the moment
>>   so I removed them too.
>> * I am not sure why you create and install a shared version of this
>>   library. It seems like upstream intends for this to be statically
>>   linked into executables. Indeed, you don't even use the shared
>>   version of the library in PurritoBin, so I think it can go.
>> * Your patch to the Makefile causes everything to be recompiled at
>>   fake time.
>> * Not related to your port, but too bad that we are stuck using libuv
>>   (it can use kqueue but it uses extensions from FreeBSD that we don't
>>   have).
>>
>> uwebsockets:
>> * Upstream claims this is a web server so I moved the category to www.
>>   Devel is quite full. Otherwise this port is quite straightforward.
>>
>> purritobin:
>> * Since you're using the static version of usocket, we can simplify
>>   your depends lists.
>>
>> ~Brian
>>
>
>
>
>
> purritobin
> - Makefile:
>   - add "uses pledge()" above wantlib as done in other ports
> - pkg/DESCR:
>   - trailing blank line
>   - s/writted/written
>
I've attached with the suggested fixes and those from Brian.

again, thank you Brian!

> All these static libraries mean that things won't get updated
> automatically when a library is updated. Say you install purritobin
> and there is a later security fix to usockets; purritobin won't be
> updated unless you manually force it (e.g. by bumping REVISION).
> The normal way of handling this with almost everything else in ports
> is to use shared libraries.
>

am not sure if there is a good fix for this (?!)


Aisha


uwebsockets.tgz (1K) Download Attachment
usockets.tgz (2K) Download Attachment
purritobin.tgz (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: purritobin-0.1.2 - new package + dependencies

Stuart Henderson
In reply to this post by Aisha Tammy-5
On 2020/06/02 15:55, Aisha Tammy wrote:
> > All these static libraries mean that things won't get updated
> > automatically when a library is updated. Say you install purritobin
> > and there is a later security fix to usockets; purritobin won't be
> > updated unless you manually force it (e.g. by bumping REVISION).
> > The normal way of handling this with almost everything else in ports
> > is to use shared libraries.
> >
> I totally agree but upstream has mandated that this library is to be used
> static only and with -flto -O3 (which Brian has removed stating unsupported archs, thanks brian!).

that could just be changed in the port like you did before (but then
actually make use of it). I don't think we honestly care about the
difference upstream talks about in the ticket (160k req/sec with
shared libs, to 215k req/sec with static+lto, on some unspecified OS).
https://github.com/uNetworking/uSockets/issues/99#issuecomment-627384325

Packagers for at least some other OS will want this too if they're
going to include it in their package systems.

> Upstream have also rejected my patch to add shared libraries :( and is adamant
> on using both the above flags (which was a separate issue that was raised, to
> remove the flags and make them optional depending on distribution)
>
> Does ports not handle such an automated revision bump for static libraries
> that get updated? (am just asking, I don't know the intricacies and details
> of shared/static library things)

If there was a shared library as well you could list it as a "fake" WANTLIB
entry (it would show as "extra" so we add a comment to say what's going on)
and then it would at least get updated if the shared library version number
(.so.X.Y) changes though that doesn't force it for every update either.
Really with static libs you need to bump all the downstream users or
set a tight dependency on the particular version number.

> I am not sure how to resolve this conflict...
>
>
> an aside: why was -O3 removed, upstream has it present and wants it to be there?

Higher opt levels increase risk of hitting compiler bugs (maybe only
on certain architectures). If the code implements anything which is
undefined behaviour that can cause problems with optimisers too,
especially at higher opt levels.

Ports policy is to respect what is set by the user / ports infrastructure,
usually -O2, but sometimes it's necessary to change that on certain arches.

Reply | Threaded
Open this post in threaded view
|

Re: purritobin-0.1.2 - new package + dependencies

Aisha Tammy-5
Based on your comments, I've changed it back to using the shared
library, though I am still building a static library as well.

Thanks a lot for all your help!

comments?

PS: yes, uwebsockets did go from 0.17.6 to 18.1.0

Aisha

On 6/3/20 11:14 AM, Stuart Henderson wrote:

> On 2020/06/02 15:55, Aisha Tammy wrote:
>>> All these static libraries mean that things won't get updated
>>> automatically when a library is updated. Say you install purritobin
>>> and there is a later security fix to usockets; purritobin won't be
>>> updated unless you manually force it (e.g. by bumping REVISION).
>>> The normal way of handling this with almost everything else in ports
>>> is to use shared libraries.
>>>
>> I totally agree but upstream has mandated that this library is to be used
>> static only and with -flto -O3 (which Brian has removed stating unsupported archs, thanks brian!).
>
> that could just be changed in the port like you did before (but then
> actually make use of it). I don't think we honestly care about the
> difference upstream talks about in the ticket (160k req/sec with
> shared libs, to 215k req/sec with static+lto, on some unspecified OS).
> https://github.com/uNetworking/uSockets/issues/99#issuecomment-627384325
>
> Packagers for at least some other OS will want this too if they're
> going to include it in their package systems.
>
>> Upstream have also rejected my patch to add shared libraries :( and is adamant
>> on using both the above flags (which was a separate issue that was raised, to
>> remove the flags and make them optional depending on distribution)
>>
>> Does ports not handle such an automated revision bump for static libraries
>> that get updated? (am just asking, I don't know the intricacies and details
>> of shared/static library things)
>
> If there was a shared library as well you could list it as a "fake" WANTLIB
> entry (it would show as "extra" so we add a comment to say what's going on)
> and then it would at least get updated if the shared library version number
> (.so.X.Y) changes though that doesn't force it for every update either.
> Really with static libs you need to bump all the downstream users or
> set a tight dependency on the particular version number.
>
>> I am not sure how to resolve this conflict...
>>
>>
>> an aside: why was -O3 removed, upstream has it present and wants it to be there?
>
> Higher opt levels increase risk of hitting compiler bugs (maybe only
> on certain architectures). If the code implements anything which is
> undefined behaviour that can cause problems with optimisers too,
> especially at higher opt levels.
>
> Ports policy is to respect what is set by the user / ports infrastructure,
> usually -O2, but sometimes it's necessary to change that on certain arches.
>


purritobin-0.2.1.tgz (1K) Download Attachment
uwebsockets-18.1.0.tgz (1K) Download Attachment
usockets-0.4.0.tgz (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: purritobin-0.1.2 - new package + dependencies

Brian Callahan-6
Hi Aisha --

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, June 8, 2020 9:07 AM, Aisha Tammy <[hidden email]> wrote:

> Based on your comments, I've changed it back to using the shared
> library, though I am still building a static library as well.
>
> Thanks a lot for all your help!
>
> comments?
>
> PS: yes, uwebsockets did go from 0.17.6 to 18.1.0
>
> Aisha
>
> On 6/3/20 11:14 AM, Stuart Henderson wrote:
>
> > On 2020/06/02 15:55, Aisha Tammy wrote:
> >
> > > > All these static libraries mean that things won't get updated
> > > > automatically when a library is updated. Say you install purritobin
> > > > and there is a later security fix to usockets; purritobin won't be
> > > > updated unless you manually force it (e.g. by bumping REVISION).
> > > > The normal way of handling this with almost everything else in ports
> > > > is to use shared libraries.
> > >
> > > I totally agree but upstream has mandated that this library is to be used
> > > static only and with -flto -O3 (which Brian has removed stating unsupported archs, thanks brian!).
> >
> > that could just be changed in the port like you did before (but then
> > actually make use of it). I don't think we honestly care about the
> > difference upstream talks about in the ticket (160k req/sec with
> > shared libs, to 215k req/sec with static+lto, on some unspecified OS).
> > https://github.com/uNetworking/uSockets/issues/99#issuecomment-627384325
> > Packagers for at least some other OS will want this too if they're
> > going to include it in their package systems.
> >
> > > Upstream have also rejected my patch to add shared libraries :( and is adamant
> > > on using both the above flags (which was a separate issue that was raised, to
> > > remove the flags and make them optional depending on distribution)
> > > Does ports not handle such an automated revision bump for static libraries
> > > that get updated? (am just asking, I don't know the intricacies and details
> > > of shared/static library things)
> >
> > If there was a shared library as well you could list it as a "fake" WANTLIB
> > entry (it would show as "extra" so we add a comment to say what's going on)
> > and then it would at least get updated if the shared library version number
> > (.so.X.Y) changes though that doesn't force it for every update either.
> > Really with static libs you need to bump all the downstream users or
> > set a tight dependency on the particular version number.
> >
> > > I am not sure how to resolve this conflict...
> > > an aside: why was -O3 removed, upstream has it present and wants it to be there?
> >
> > Higher opt levels increase risk of hitting compiler bugs (maybe only
> > on certain architectures). If the code implements anything which is
> > undefined behaviour that can cause problems with optimisers too,
> > especially at higher opt levels.
> > Ports policy is to respect what is set by the user / ports infrastructure,
> > usually -O2, but sometimes it's necessary to change that on certain arches.
I made just tiny tweaks to usockets and purritobin; just WANTLIB and BDEP/LDEP fixes.

Maybe it would be nice to upstream the usockets shared library building?

~Brian

purritobin.tgz (1K) Download Attachment
usockets.tgz (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: purritobin-0.1.2 - new package + dependencies

Stuart Henderson
On 2020/06/12 21:34, Brian Callahan wrote:
> Maybe it would be nice to upstream the usockets shared library building?

upstream say WONTFIX, they are more interested in performance than
something which can be used in OS packaging.

https://github.com/uNetworking/uSockets/issues/99#issuecomment-627384325

Reply | Threaded
Open this post in threaded view
|

Re: purritobin-0.1.2 - new package + dependencies

Brian Callahan-6

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, June 12, 2020 5:48 PM, Stuart Henderson <[hidden email]> wrote:

> On 2020/06/12 21:34, Brian Callahan wrote:
>
> > Maybe it would be nice to upstream the usockets shared library building?
>
> upstream say WONTFIX, they are more interested in performance than
> something which can be used in OS packaging.
>
> https://github.com/uNetworking/uSockets/issues/99#issuecomment-627384325

Ah, missed that thanks.
In that case, we can certainly support a single patch for it.

~Brian

Reply | Threaded
Open this post in threaded view
|

Re: purritobin-0.1.2 - new package + dependencies

Aisha Tammy-5
On 6/12/20 5:49 PM, Brian Callahan wrote:

>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, June 12, 2020 5:48 PM, Stuart Henderson <[hidden email]> wrote:
>
>> On 2020/06/12 21:34, Brian Callahan wrote:
>>
>>> Maybe it would be nice to upstream the usockets shared library building?
>>
>> upstream say WONTFIX, they are more interested in performance than
>> something which can be used in OS packaging.
>>
>> https://github.com/uNetworking/uSockets/issues/99#issuecomment-627384325
>
> Ah, missed that thanks.
> In that case, we can certainly support a single patch for it.
>
> ~Brian
>
Yes, an unfortunate scenario.

I've added them again with the two from Brian and the uwebsockets
updated to 18.3.0

Thanks a lot!

Aisha



uwebsockets.tgz (1K) Download Attachment
usockets.tgz (2K) Download Attachment
purritobin.tgz (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: purritobin-0.1.2 - new package + dependencies

Aisha Tammy-5
On 6/13/20 4:48 PM, Aisha Tammy wrote:

> On 6/12/20 5:49 PM, Brian Callahan wrote:
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Friday, June 12, 2020 5:48 PM, Stuart Henderson <[hidden email]> wrote:
>>
>>> On 2020/06/12 21:34, Brian Callahan wrote:
>>>
>>>> Maybe it would be nice to upstream the usockets shared library building?
>>>
>>> upstream say WONTFIX, they are more interested in performance than
>>> something which can be used in OS packaging.
>>>
>>> https://github.com/uNetworking/uSockets/issues/99#issuecomment-627384325
>>
>> Ah, missed that thanks.
>> In that case, we can certainly support a single patch for it.
>>
>> ~Brian
>>
> Yes, an unfortunate scenario.
>
> I've added them again with the two from Brian and the uwebsockets
> updated to 18.3.0
>
> Thanks a lot!
>
> Aisha
>
>
Another bump.
Also updated uwebsockets to 18.4.0

Aisha

uwebsockets.tgz (1K) Download Attachment
usockets.tgz (2K) Download Attachment
purritobin.tgz (1K) Download Attachment
12