Re: rxvt-unicode: fix ECB_MEMORY_FENCE
On Wed, Aug 29, 2012 at 02:17:47AM -0600, David Coppa wrote: > > Remove stupid hack and sync with devel/libev. > > OK? This should be using devel/libev not an internal copy. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: rxvt-unicode: fix ECB_MEMORY_FENCE
On Wed, Aug 29, 2012 at 3:11 PM, Brad Smith wrote: > On Wed, Aug 29, 2012 at 02:17:47AM -0600, David Coppa wrote: >> >> Remove stupid hack and sync with devel/libev. >> >> OK? > > This should be using devel/libev not an internal copy. You're saying I should hack urxvt to use the external libev from devel/libev? I could give a try, but I fear it would be invasive...
Re: rxvt-unicode: fix ECB_MEMORY_FENCE
On Wed, Aug 29, 2012 at 03:17:07PM +0200, David Coppa wrote: > On Wed, Aug 29, 2012 at 3:11 PM, Brad Smith wrote: > > On Wed, Aug 29, 2012 at 02:17:47AM -0600, David Coppa wrote: > >> > >> Remove stupid hack and sync with devel/libev. > >> > >> OK? > > > > This should be using devel/libev not an internal copy. > > You're saying I should hack urxvt to use the external libev from devel/libev? > I could give a try, but I fear it would be invasive... That's fine. This is far from the first time ports have been modified to use external copies of libraries because upstream didn't do things properly. Since this is still a maintained and active project the port maintainer can work with the authors upstream to have them add a proper autoocnf option to allow building with a system copy of libev. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: rxvt-unicode: fix ECB_MEMORY_FENCE
On Wed, Aug 29, 2012 at 3:30 PM, Brad Smith wrote: > On Wed, Aug 29, 2012 at 03:17:07PM +0200, David Coppa wrote: >> On Wed, Aug 29, 2012 at 3:11 PM, Brad Smith wrote: >> > On Wed, Aug 29, 2012 at 02:17:47AM -0600, David Coppa wrote: >> >> >> >> Remove stupid hack and sync with devel/libev. >> >> >> >> OK? >> > >> > This should be using devel/libev not an internal copy. >> >> You're saying I should hack urxvt to use the external libev from devel/libev? >> I could give a try, but I fear it would be invasive... > > That's fine. This is far from the first time ports have been modified to use > external copies of libraries because upstream didn't do things properly. Since > this is still a maintained and active project the port maintainer can work > with > the authors upstream to have them add a proper autoocnf option to allow > building > with a system copy of libev. https://bugzilla.redhat.com/show_bug.cgi?id=672396
Re: rxvt-unicode: fix ECB_MEMORY_FENCE
On Wed, Aug 29, 2012 at 03:36:14PM +0200, David Coppa wrote: > On Wed, Aug 29, 2012 at 3:30 PM, Brad Smith wrote: > > On Wed, Aug 29, 2012 at 03:17:07PM +0200, David Coppa wrote: > >> On Wed, Aug 29, 2012 at 3:11 PM, Brad Smith wrote: > >> > On Wed, Aug 29, 2012 at 02:17:47AM -0600, David Coppa wrote: > >> >> > >> >> Remove stupid hack and sync with devel/libev. > >> >> > >> >> OK? > >> > > >> > This should be using devel/libev not an internal copy. > >> > >> You're saying I should hack urxvt to use the external libev from > >> devel/libev? > >> I could give a try, but I fear it would be invasive... > > > > That's fine. This is far from the first time ports have been modified to use > > external copies of libraries because upstream didn't do things properly. > > Since > > this is still a maintained and active project the port maintainer can work > > with > > the authors upstream to have them add a proper autoocnf option to allow > > building > > with a system copy of libev. > > https://bugzilla.redhat.com/show_bug.cgi?id=672396 Incredibly stupid, especially when the projects with the incompatible internal copies are from the author of the library. Taking that into consideration I'm OK with the diff until a sane and more ideal solution can be implemented. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: rxvt-unicode: fix ECB_MEMORY_FENCE
On Wed, Aug 29, 2012 at 4:22 PM, Brad Smith wrote: > Incredibly stupid, especially when the projects with the incompatible internal > copies are from the author of the library. yes I know :( > Taking that into consideration I'm OK with the diff until a sane and more > ideal > solution can be implemented.