Re: Epiphany requires gnupg and does not accept gnupg21?

[David Evans]

On 10/8/16 7:03 PM, David Evans wrote:
> On 10/8/16 5:29 PM, Lawrence Velázquez wrote:
>>> On Oct 8, 2016, at 3:33 PM, Johannes Kastl  wrote:
>>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Dear all,
>>>
>>> while trying to upgrade my gimp2 port today, I stumbled upon
>>> epiphany throwing this error:
>>>
 sudo port install epiphany --->  Computing dependencies for
 epiphany Error: Unable to execute port: Can't install gnupg
 because conflicting ports are active: gnupg21
>>>
>>> Is this a known issue?
>>
>> That would be gcr, not epiphany.
>>
>>  % port echo depends:gnupg and rdepof:epiphany
>>  gcr
>>
>> gnupg and gnupg21 conflict so that users don't run into unexpected
>> behavior switching back and forth [1]. I'm not really sure what the best
>> way of remedying this is.
>>
>> [1]: https://trac.macports.org/ticket/45856#comment:3
>>
>> vq
>>
> 
> As Larry says, the gnupg dependency is coming from gcr, and, at first glance, 
> that doesn't seem correct to
> me.  gcr provides ui widgets to display/handle gnupg generated records as 
> well as opengpg, etc, but libgcrypt and
> p11-kit should be sufficient to do this and I don't see any dependency on 
> gnupg in configure.ac.   This just
> may be a hold over from old times.  Will investigate further and see if the 
> gnupg dependency can just go away.
> 
> Dave
>

I've confirmed that gcr's dependency on gnupg is unnecessary -- works fine 
without it.  Removed in r153722.
Let me know if you have any further problems upgrading gimp2.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm / clang and thread_local storage problems

[Stephen J. Butler]

FYI, it's in the Xcode 8 release notes:

https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Introduction.html

I did a quick test file and it seems to compile with Apple clang. No clue
on compatibility issues though.

On Sat, Oct 8, 2016 at 11:06 PM, Ryan Schmidt 
wrote:

>
> > On Oct 8, 2016, at 10:59 PM, Ken Cunningham <
> ken.cunningham.web...@gmail.com> wrote:
> >
> > I've run into this again tonight.
> >
> > I'm using, at this moment, clang-3.7 / llvm-3.7 with macports-created
> libc++ and libc++abi.
> >
> >
> > Every once in a while, a port I'm trying to create or build will error
> out due to this:
> >
> > error: thread-local storage is not supported for the current target
> >
> > /opt/local/var/macports/build/_opt_myports_devel_glbinding/
> glbinding/work/build/source/glbinding/include/glbinding/glbinding_features.h:240:36:
> note: expanded from macro 'GLBINDING_THREAD_LOCAL'
> > #define GLBINDING_THREAD_LOCAL __thread
> >   ^
> >
> > In this case, I'm trying to create this port  cginternals/glbinding> which is a dev library for openGL.
> >
> >
> > As I understand it, thread_local storage is a feature of cxx11 that
> should be - but apparently isn't - supported by clang / llvm.
> >
> > This page  says it is
> enabled in clang-3.3, if your c++ runtime provides __cxa_thread_atexit,
> like libc++abi 3.6 or later.
> > I have   libcxxabi @3.7.0_1+universal (active) platform='darwin 10'
> archs='i386 x86_64'
> >
> > there's a thread on stackoverflow about it:
> >
> >  apple-clang-disallow-c11-thread-local-when-official-clang-supports>
> >
> > which has this quote:
> >
> > For Xcode 7.x and earlier, here is an answer from 2014 from an Apple
> engineer on the Apple Developer Forum:
> >
> > We don't support the thread_local implementation from the open-source
> Clang because we believe we can provide a higher-performance implementation
> for our platforms using various features in the dynamic linker. Such an
> implementation would be ABI-incompatible with the implementation in the
> open-source Clang, so we won't support thread_local until we get an
> implementation we can live with for the foreseeable future.
> >
> > There are many smart people on this list who know a lot more about this
> kind of thing than I ever will.
> >
> > Anyone offer any insight into this issue?
>
> Thanks for finding and sharing that information. It sounds like you could
> get TLS by using MacPorts clang instead of Xcode clang, but that it will be
> incompatible with whatever TLS implementation Apple eventually creates.
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm / clang and thread_local storage problems

[Ryan Schmidt]

> On Oct 8, 2016, at 10:59 PM, Ken Cunningham  
> wrote:
> 
> I've run into this again tonight.
> 
> I'm using, at this moment, clang-3.7 / llvm-3.7 with macports-created libc++ 
> and libc++abi.
> 
> 
> Every once in a while, a port I'm trying to create or build will error out 
> due to this:
> 
> error: thread-local storage is not supported for the current target
> 
> /opt/local/var/macports/build/_opt_myports_devel_glbinding/glbinding/work/build/source/glbinding/include/glbinding/glbinding_features.h:240:36:
>  note: expanded from macro 'GLBINDING_THREAD_LOCAL'
> #define GLBINDING_THREAD_LOCAL __thread
>   ^
> 
> In this case, I'm trying to create this port 
>  which is a dev library for openGL.
> 
> 
> As I understand it, thread_local storage is a feature of cxx11 that should be 
> - but apparently isn't - supported by clang / llvm.
> 
> This page  says it is enabled in 
> clang-3.3, if your c++ runtime provides __cxa_thread_atexit, like libc++abi 
> 3.6 or later.
> I have   libcxxabi @3.7.0_1+universal (active) platform='darwin 10' 
> archs='i386 x86_64'
> 
> there's a thread on stackoverflow about it:
> 
> 
> 
> which has this quote:
> 
> For Xcode 7.x and earlier, here is an answer from 2014 from an Apple engineer 
> on the Apple Developer Forum:
> 
> We don't support the thread_local implementation from the open-source Clang 
> because we believe we can provide a higher-performance implementation for our 
> platforms using various features in the dynamic linker. Such an 
> implementation would be ABI-incompatible with the implementation in the 
> open-source Clang, so we won't support thread_local until we get an 
> implementation we can live with for the foreseeable future.
> 
> There are many smart people on this list who know a lot more about this kind 
> of thing than I ever will.
> 
> Anyone offer any insight into this issue?

Thanks for finding and sharing that information. It sounds like you could get 
TLS by using MacPorts clang instead of Xcode clang, but that it will be 
incompatible with whatever TLS implementation Apple eventually creates.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

llvm / clang and thread_local storage problems

[Ken Cunningham]

I've run into this again tonight.

I'm using, at this moment, clang-3.7 / llvm-3.7 with macports-created libc++ 
and libc++abi.


Every once in a while, a port I'm trying to create or build will error out due 
to this:

error: thread-local storage is not supported for the current target

/opt/local/var/macports/build/_opt_myports_devel_glbinding/glbinding/work/build/source/glbinding/include/glbinding/glbinding_features.h:240:36:
 note: expanded from macro 'GLBINDING_THREAD_LOCAL'
#define GLBINDING_THREAD_LOCAL __thread
   ^

In this case, I'm trying to create this port 
 which is a dev library for openGL.


As I understand it, thread_local storage is a feature of cxx11 that should be - 
but apparently isn't - supported by clang / llvm.

This page  says it is enabled in 
clang-3.3, if your c++ runtime provides __cxa_thread_atexit, like libc++abi 3.6 
or later.
I have   libcxxabi @3.7.0_1+universal (active) platform='darwin 10' archs='i386 
x86_64'

there's a thread on stackoverflow about it:



which has this quote:

For Xcode 7.x and earlier, here is an answer from 2014 from an Apple engineer 
on the Apple Developer Forum:

We don't support the thread_local implementation from the open-source Clang 
because we believe we can provide a higher-performance implementation for our 
platforms using various features in the dynamic linker. Such an implementation 
would be ABI-incompatible with the implementation in the open-source Clang, so 
we won't support thread_local until we get an implementation we can live with 
for the foreseeable future.

There are many smart people on this list who know a lot more about this kind of 
thing than I ever will.

Anyone offer any insight into this issue?

best,

Ken


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Epiphany requires gnupg and does not accept gnupg21?

[David Evans]

On 10/8/16 5:29 PM, Lawrence Velázquez wrote:
>> On Oct 8, 2016, at 3:33 PM, Johannes Kastl  wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Dear all,
>>
>> while trying to upgrade my gimp2 port today, I stumbled upon
>> epiphany throwing this error:
>>
>>> sudo port install epiphany --->  Computing dependencies for
>>> epiphany Error: Unable to execute port: Can't install gnupg
>>> because conflicting ports are active: gnupg21
>>
>> Is this a known issue?
> 
> That would be gcr, not epiphany.
> 
>   % port echo depends:gnupg and rdepof:epiphany
>   gcr
> 
> gnupg and gnupg21 conflict so that users don't run into unexpected
> behavior switching back and forth [1]. I'm not really sure what the best
> way of remedying this is.
> 
> [1]: https://trac.macports.org/ticket/45856#comment:3
> 
> vq
> 

As Larry says, the gnupg dependency is coming from gcr, and, at first glance, 
that doesn't seem correct to
me.  gcr provides ui widgets to display/handle gnupg generated records as well 
as opengpg, etc, but libgcrypt and
p11-kit should be sufficient to do this and I don't see any dependency on gnupg 
in configure.ac.   This just
may be a hold over from old times.  Will investigate further and see if the 
gnupg dependency can just go away.

Dave
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Ryan Schmidt]

Please, everyone, stop. We are keeping our Trac issue tracker; this has been 
decided. We will not use GitHub issues at this time because it does not have 
the features we need. We will move our code to GitHub because it has been 
requested by many users over the years and will help attract new developers. We 
have already moved our web site news feed to GitHub Pages and may make use of 
other GitHub infrastructure over time. macOS forge was being shut down, so it 
was necessary for us to move anyway, and this gave us the incentive to make the 
jump to git and GitHub. We have not yet defined, any we are attempting in 
conversations on this mailing list to figure out, how we will work with GitHub. 
We will not deliberately introduce obstacles that make contributions difficult. 
We will automate cross-linking between GitHub pull requests and Trac tickets. 
Thank you.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Epiphany requires gnupg and does not accept gnupg21?

[Lawrence Velázquez]

> On Oct 8, 2016, at 3:33 PM, Johannes Kastl  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Dear all,
> 
> while trying to upgrade my gimp2 port today, I stumbled upon
> epiphany throwing this error:
> 
>> sudo port install epiphany --->  Computing dependencies for
>> epiphany Error: Unable to execute port: Can't install gnupg
>> because conflicting ports are active: gnupg21
> 
> Is this a known issue?

That would be gcr, not epiphany.

% port echo depends:gnupg and rdepof:epiphany
gcr

gnupg and gnupg21 conflict so that users don't run into unexpected
behavior switching back and forth [1]. I'm not really sure what the best
way of remedying this is.

[1]: https://trac.macports.org/ticket/45856#comment:3

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Brandon Allbery]

On Sat, Oct 8, 2016 at 7:48 PM, Marcel Bischoff 
wrote:

> I understand that. Many long-running projects are using their own Git
> infrastructure with Trac, Redmine and others. What I don't understand is
> why moving to GitHub at all when the tooling is clearly insufficient for
> the project. The added exposure? The hope to attract new developers? If
> the needs of the "people who actually do the work" are paramount, GitHub
> is probably not adding much to improve ingrained workflows but rather
> slow them down.
>

I prefer to let someone more official address this, but suffice it to say
it wasn't entirely the MacPorts folks' idea.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Marcel Bischoff]

On 16/10/08, Brandon Allbery wrote:

On Sat, Oct 8, 2016 at 4:12 PM, Marcel Bischoff 
wrote:


I for one don't understand why one would carry around all that baggage
anyhow. Why not leave the old Trac as is and start fresh with a simple,
reduced issue tracker



When the simple reduced tracker is, as already said, too simple. It is in
fact the very "Only if it was really, really awful. But then they would have
changed it a long time ago." you already mentioned: yes, it's simple for
you the end user, but it doesn't do what the people who actually do the
work need it to do (and this is true across many projects, some of which
have had to build their own additional tooling to interface with Github and
try to add all the functionality it doesn't provide).


I understand that. Many long-running projects are using their own Git
infrastructure with Trac, Redmine and others. What I don't understand is
why moving to GitHub at all when the tooling is clearly insufficient for
the project. The added exposure? The hope to attract new developers? If
the needs of the "people who actually do the work" are paramount, GitHub
is probably not adding much to improve ingrained workflows but rather
slow them down.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Brandon Allbery]

On Sat, Oct 8, 2016 at 4:27 PM, Chris Jones 
wrote:

> What concerns me is the statement that in this migration to github, github
> and trac are kept completely separate, with no automatic linkage, but still
> contributors are expected to use both.


What I heard was that, due to time constraints, it will initially be kept
separate while people figured out what tooling was needed and the best way
to proceed. (Also note that they're already looking at Trac/Github
integration plugins, and something useful may turn out to be easy to add to
improve Trac integration. Possibly something like catching new GHI tickets,
copying them into Trac, and closing the GHI ticket with a link to the Trac
ticket.) But it will probably happen at some point, because GHI is pretty
much the minimum they can get away with and provides no sane way to work
with something more capable aside from a handful of hooks that don't even
provide the ability to remap ticket references. :/

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Brandon Allbery]

On Sat, Oct 8, 2016 at 4:12 PM, Marcel Bischoff 
wrote:

> I for one don't understand why one would carry around all that baggage
> anyhow. Why not leave the old Trac as is and start fresh with a simple,
> reduced issue tracker
>

When the simple reduced tracker is, as already said, too simple. It is in
fact the very "Only if it was really, really awful. But then they would have
changed it a long time ago." you already mentioned: yes, it's simple for
you the end user, but it doesn't do what the people who actually do the
work need it to do (and this is true across many projects, some of which
have had to build their own additional tooling to interface with Github and
try to add all the functionality it doesn't provide).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Marcel Bischoff]

On 16/10/08, Chris Jones wrote:




On 8 Oct 2016, at 11:29 am, Ryan Schmidt  wrote:



On Oct 7, 2016, at 2:18 PM, Christopher Jones  wrote:



On 7 Oct 2016, at 8:12 pm, Ryan Schmidt  wrote:



On Oct 7, 2016, at 1:40 PM, Lawrence Velázquez  wrote:

On Oct 7, 2016, at 2:09 PM, Chris Jones  wrote:

Currently, once they find out about svn, and trac


We will still use Trac for issue tracking, although I believe someone is
looking into integrating GitHub sign in.


Rainer and Clemens looked into this and got it up and running on our test 
installation.



So what exactly does this mean ?


It means you will log in to our Trac installation using your GitHub 
credentials, instead of via Mac OS Forge credentials as it is now.



Because, honestly, once the migration to GitHub is done unless comments sent to 
a github pull request are automatically sync’ed to trac, and vice versa, I do 
not see how trac can be maintained as a via system for discussing the pull 
requests (and frankly I din’t really see why you would want to).


There will be no syncing of anything between GitHub pull requests and Trac 
tickets because they are different entities. Trac tickets are where bug reports 
and other issues will be filed. Currently, if someone has a fix for an issue, 
they would attach a patch to the Trac ticket; in future, they will instead open 
a GitHub pull request and paste a link to the pull request into the ticket (or 
paste a link to the Trac ticket into the pull request; I'm not sure if we've 
decided that detail yet).


At my work we use gitlab and Jira in a similar way, but there is automatic 
links between the two, in that if i quote a jira id in a git lab merge request, 
links between the two is produced automatically. Having to do this by hand 
strikes me as potentially error prone and a little cumbersome.


And as Rainer said, there may be some simple changes for which it is sufficient 
to just submit a pull request, without opening a corresponding Trac ticket. We 
haven't defined what those situations would be yet.


I would hope that for a simple updates to a port, that isn't addressing
a bug report, then no trac ticket will required. The pull request
really should be enough in this case, and if any discussion on the
update is required it can occur in the pull request. If during the
course of that discussion it transpires the update needs more work,
then fine a trac ticket could be opened at that point. But  would hope
for most it would simply not be necessary, and if it where a
requirement to always do this i think that would be an unnecessary
overhead.


This is how I feel as well. Having Trac running in parrallel to GitHub
feels like overhead that's just there because it's there. I understand
the need to use advanced functionality and having worked with any one
piece of technology for a decade, people are not going to change away
it. Only if it was really, really awful. But then they would have
changed it a long time ago. It's force of habit. When looking for
alternatives you compare them to your ingrained habits — that is not
going to work. Any major deviation will always feel not quite right.

I for one don't understand why one would carry around all that baggage
anyhow. Why not leave the old Trac as is and start fresh with a simple,
reduced issue tracker? Splitting discussion and code on two platforms
will create overhead. Unnecessary overhead I may add. Code and
discussion should go hand in hand.

I see this happening in the future: a first-time contributor opens a
pull request with a new port (not an update to an existing one),
describing everthing of value in the pull request itself. The
contributor will not open a Trac ticket because he has just opened the
pull request which is self-explanatory and doesn't want to enter all
that information a second time. The pull request gets ignored or
rejected because the contributor did not open a proper Trac ticket. The
contributor has a bad experience, decides to devote his time to a less
bureocratic project and quietly leaves.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Joshua Root]

On 2016-10-9 06:10 , Marcel Bischoff wrote:

On 16/10/08, Ryan Schmidt wrote:



On Oct 8, 2016, at 8:30 AM, Marcel Bischoff 
wrote:

I see where you're coming from. However, your approach is contrary to
how the majority of issues are handled on services like GitHub. If the
ticket is too old, stale, not applicable any more or simply does not
receive any answer for weeks/months, it will usually be closed with a
note stating that. This helps keep the number of issues/tickets down to
a manageable level and avoids tickets being active for 11 years.


Well, we're not hosting issues on GitHub; we're hosting them on Trac.
And I don't want to close tickets that have not been dealt with.


It should be easy to just tag those issues as "abandoned" and close
them, so you can comfortably find them again at any point.


For something like a port submission that has never reached a working 
state, it might be reasonable to close the ticket with a resolution that 
indicates that work stalled and appears unlikely to resume. Or if 
there's a report of a bug that we can't reproduce, and we've asked the 
reporter for more info, and that info has not been provided, then that 
would be reasonable to close as well ("worksforme"). And certainly if a 
bug is no longer applicable, that's synonymous with "fixed".


But the idea that a valid, unfixed ticket can be "too old" makes no 
sense to me. Closing such a ticket without doing anything to resolve it 
doesn't mean you're actually more productive or responsive or whatever. 
(No doubt it makes certain stats look good.)


- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Epiphany requires gnupg and does not accept gnupg21?

[Johannes Kastl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear all,

while trying to upgrade my gimp2 port today, I stumbled upon
epiphany throwing this error:

> sudo port install epiphany --->  Computing dependencies for
> epiphany Error: Unable to execute port: Can't install gnupg
> because conflicting ports are active: gnupg21

Is this a known issue?

Kind Regards,
Johannes

MacPorts 2.3.4
OSX 10.10.5
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/

iEYEARECAAYFAlf5SgYACgkQzi3gQ/xETbI3FwCggL0OPKN5HHAGE8uNJXcs0lHd
SvYAoIshPiYQ0E7Iy/L5VTGGVucM3Eer
=ZUzE
-END PGP SIGNATURE-

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Marcel Bischoff]

On 16/10/08, Ryan Schmidt wrote:



On Oct 8, 2016, at 8:30 AM, Marcel Bischoff  wrote:

On 16/10/08, Ryan Schmidt wrote:




Requests for new ports could still be valid after years. This list could
be helpful for newcomers that want to create new ports.


Totally agree - but I'd close everything over six months old or something like that for 
optics. People can still search to "closed" tickets if they want.


It seems counterproductive to me to close a ticket if you're not addressing the 
issue. Just because nobody has done anything with a ticket for 6 months or 2 
years or whatever period of time doesn't necessarily mean that the issue is no 
longer valid, just that nobody has had time to deal with it yet.

When I go searching for tickets, I don't typically search for closed
tickets, because I assume that closed tickets are closed because
they've been dealt with. If we change that rule now, it will mean that
I either don't find tickets that might have been relevant to whatever
I'm searching for, or that I have to remember to search for closed
tickets and spend a lot of time sifting through tickets that have
already been dealt with.


I see where you're coming from. However, your approach is contrary to
how the majority of issues are handled on services like GitHub. If the
ticket is too old, stale, not applicable any more or simply does not
receive any answer for weeks/months, it will usually be closed with a
note stating that. This helps keep the number of issues/tickets down to
a manageable level and avoids tickets being active for 11 years.


Well, we're not hosting issues on GitHub; we're hosting them on Trac. And I 
don't want to close tickets that have not been dealt with.


It should be easy to just tag those issues as "abandoned" and close
them, so you can comfortably find them again at any point.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Chris Jones]

> On 8 Oct 2016, at 11:29 am, Ryan Schmidt  wrote:
> 
> 
>> On Oct 7, 2016, at 2:18 PM, Christopher Jones  
>> wrote:
>> 
>> 
>>> On 7 Oct 2016, at 8:12 pm, Ryan Schmidt  wrote:
>>> 
>>> 
> On Oct 7, 2016, at 1:40 PM, Lawrence Velázquez  
> wrote:
> 
> On Oct 7, 2016, at 2:09 PM, Chris Jones  wrote:
> 
> Currently, once they find out about svn, and trac
 
 We will still use Trac for issue tracking, although I believe someone is
 looking into integrating GitHub sign in.
>>> 
>>> Rainer and Clemens looked into this and got it up and running on our test 
>>> installation.
>>> 
>> 
>> So what exactly does this mean ?
> 
> It means you will log in to our Trac installation using your GitHub 
> credentials, instead of via Mac OS Forge credentials as it is now.
> 
> 
>> Because, honestly, once the migration to GitHub is done unless comments sent 
>> to a github pull request are automatically sync’ed to trac, and vice versa, 
>> I do not see how trac can be maintained as a via system for discussing the 
>> pull requests (and frankly I din’t really see why you would want to).
> 
> There will be no syncing of anything between GitHub pull requests and Trac 
> tickets because they are different entities. Trac tickets are where bug 
> reports and other issues will be filed. Currently, if someone has a fix for 
> an issue, they would attach a patch to the Trac ticket; in future, they will 
> instead open a GitHub pull request and paste a link to the pull request into 
> the ticket (or paste a link to the Trac ticket into the pull request; I'm not 
> sure if we've decided that detail yet).

At my work we use gitlab and Jira in a similar way, but there is automatic 
links between the two, in that if i quote a jira id in a git lab merge request, 
links between the two is produced automatically. Having to do this by hand 
strikes me as potentially error prone and a little cumbersome.

> And as Rainer said, there may be some simple changes for which it is 
> sufficient to just submit a pull request, without opening a corresponding 
> Trac ticket. We haven't defined what those situations would be yet.

I would hope that for a simple updates to a port, that isn't addressing a bug 
report, then no trac ticket will required. The pull request really should be 
enough in this case, and if any discussion on the update is required it can 
occur in the pull request. If during the course of that discussion it 
transpires the update needs more work, then fine a trac ticket could be opened 
at that point. But  would hope for most it would simply not be necessary, and 
if it where a requirement to always do this i think that would be an 
unnecessary overhead.

Cheers Chris


> 
> 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [153697] trunk/dports/sysutils/bacula

[Aljaž Srebrnič]

> On 08 ott 2016, at 15:46, Ryan Schmidt  wrote:
> 
> I suppose it's possible someone managed to install it in a secondary 
> non-standard prefix, if they also had the dependencies installed in the 
> standard prefix.

Yeah, that is indeed possible. I commited r153706 with a fixed patch and 
revbump.
--
Aljaž Srebrnič a.k.a g5pw
My public key:  https://g5pw.me/key
Key fingerprint = 2109 8131 60CA 01AF 75EC  01BF E140 E1EE A54E E677

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: CMake issue: binary (needed during build) links againts /opt/local/lib/foo.dylib

[Mojca Miklavec]

On 8 October 2016 at 12:09, Clemens Lang wrote:
> - On 4 Oct, 2016, at 00:51, Mojca Miklavec wrote:
>
>>-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=FALSE
>
> I think this flag only affects installation (i.e. what happens on
> make install), so you may want to check its effect once you have the
> destroot phase working.

I managed to get to the destroot with the previous version (the
problem is that sources get deleted from CTAN once a new version is
out; only recently the sources appeared on GitHub which will simplify
things in the future; I might have the old sources still available
somewhere, but I don't plan to put too much effort unless/until the
main problems get fixed upstream).

The build system is to complex to give me motivation to look into too
much details (most likely some weird variant of web2c).

>> The command "otool -L cfg" reports
>>@rpath/libMiKTeX209-core.1.dylib
>
> That looks correct, but really depends on what "cfg"'s rpath is.

"cfg" is a binary. I'm not sure whether it gets installed, but it
does, then the path is definitely wrong.

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [153697] trunk/dports/sysutils/bacula

[Ryan Schmidt]

> On Oct 8, 2016, at 8:43 AM, Aljaž Srebrnič  wrote:
> 
>> On 08 ott 2016, at 11:40, Ryan Schmidt  wrote:
>> 
>> /opt/local should not be hardcoded.
> 
> Of course. Should I revbump it just to be sure? It wouldn’t build in a 
> non-standard prefix anyway.

I suppose it's possible someone managed to install it in a secondary 
non-standard prefix, if they also had the dependencies installed in the 
standard prefix.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Ryan Schmidt]

On Oct 8, 2016, at 7:57 AM, Davide Liessi  wrote:
> 
> Il sabato 8 ottobre 2016, Ryan Schmidt  ha scritto:
>> in future, they will instead open a GitHub pull request and paste a link to 
>> the pull request into the ticket (or paste a link to the Trac ticket into 
>> the pull request; I'm not sure if we've decided that detail yet).
>  
> I think the ideal would be to do both things (i.e. cross-link in both 
> directions).

Yes, we certainly want things cross-linked, it's just a matter of whether that 
will be done automatically. I imagine it will be, I just don't know right this 
second whether it will matter which link the user creates, and which one will 
be automatically added.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [153697] trunk/dports/sysutils/bacula

[Aljaž Srebrnič]

> On 08 ott 2016, at 11:40, Ryan Schmidt  wrote:
> 
> /opt/local should not be hardcoded.

Of course. Should I revbump it just to be sure? It wouldn’t build in a 
non-standard prefix anyway.

--
Aljaž Srebrnič a.k.a g5pw
My public key:  https://g5pw.me/key
Key fingerprint = 2109 8131 60CA 01AF 75EC  01BF E140 E1EE A54E E677

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Lawrence Velázquez]

On Oct 8, 2016, at 6:34 AM, Ryan Schmidt  wrote:

> It seems counterproductive to me to close a ticket if you're not addressing 
> the issue. Just because nobody has done anything with a ticket for 6 months 
> or 2 years or whatever period of time doesn't necessarily mean that the issue 
> is no longer valid, just that nobody has had time to deal with it yet.

It would be nice if there were a third state between "open" and "closed" for 
this.

(Then again, "it would be nice" if tickets just fixed themselves, so….)

> When I go searching for tickets, I don't typically search for closed tickets, 
> because I assume that closed tickets are closed because they've been dealt 
> with. If we change that rule now, it will mean that I either don't find 
> tickets that might have been relevant to whatever I'm searching for, or that 
> I have to remember to search for closed tickets and spend a lot of time 
> sifting through tickets that have already been dealt with.

This would be difficult even with a "lack-of-interest" keyword, now that you 
mention it. Today we can search for tickets that are (!closed AND [other 
conditions]). If we start closing stale tickets, one would have to search for 
tickets that are (!closed OR (closed AND keyword ~ lack-of-interest)) AND 
whatever other conditions you care about.

vq
Sent from my iPhone
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Ryan Schmidt]

> On Oct 7, 2016, at 7:07 PM, Bradley Giesbrecht  wrote:
> 
>> On Oct 7, 2016, at 4:02 PM, Rainer Müller  wrote:
>> 
>> On 2016-10-07 20:58, Christopher Jones wrote:
>>> 
 On 7 Oct 2016, at 7:40 pm, Lawrence Velázquez 
 wrote:
 
> On Oct 7, 2016, at 2:09 PM, Chris Jones
>  wrote:
> 
> Currently, once they find out about svn, and trac
 
 We will still use Trac for issue tracking, although I believe
 someone is looking into integrating GitHub sign in.
>> 
>> Trac will stay. Clemens and I already wrote new modules for the
>> trac-github plugin [1] in order to allow both login with GitHub as main
>> authentication provider, migrating old tickets from mail addresses to
>> the GitHub accounts and all permissions in Trac will be based on team
>> memberships on GitHub.
>> 
>> The only downside is that references to tickets will have to become full
>> URLs to Trac, because GitHub claims the #12345 syntax for their own
>> issue tracker and pull requests. Commits which contain such an URL will
>> automatically be linked from the corresponding ticket.
> 
> See comment below, we use #12345 syntax in with our Redmine issue tracker.

The problem is that when you write "#12345" in a git commit message, the GitHub 
repository browser web interface will link that to GitHub issue or pull request 
#12345; you cannot prevent that. Therefore, we must not use that syntax, except 
when we really mean to refer to a GitHub pull request, and must instead use the 
full Trac URL to tickets when we are referring to Trac tickets.


>>> Personally I think we have to migrate away from trac as well. Pull
>>> requests in GitHub will largely replace what happens in trac for
>>> submission of patches and the discussion of them. If we stick with
>>> trac for issues then for me it will be an utter mess.
>> 
>> Pull requests can be used in addition to tickets. For simple port
>> updates, there will be no need to open a ticket.
>> 
>> We evaluated several options, including issue trackers provided by
>> GitHub, GitLab, BitBucket, JIRA, and also others and finally came to the
>> conclusion that Trac is still the best option at hand.
>> 
>> Especially with hosting our own installation, we will finally be able to
>> make more modifications and use custom plugins, that we never got
>> deployed at Mac OS Forge (for example [2]).
> 
> 
> Redmine is outstanding in my opinion.
> 
> There is a Redmine github plugin [1] allowing Redmine installation to receive 
> Github post-receive notifications.

> [1] https://github.com/koppen/redmine_github_hook

Just as there is a trac-github plugin which we're going to use.


> Redmine parses commit messages for configurable strings and can change issue 
> status and add commit references to issue.

Rainer and Clemens are working on doing that for our new Trac install as well.


> Redmine can work with Subversion, Darcs, Mercurial, Bazaar, Git, and others.

Trac works with Git and Subversion; I don't know if it works with others but I 
don't care because we don't use others.


> Oh, and Redmine is a quick and easy rails install away.

I assume Trac wasn't hard to install, but in any case, we've got it installed 
already.


We are staying with Trac for now; evaluations of other systems and discussions 
of their respective merits have concluded. Staying with Trac is the easiest 
option, given all the other work we still have to do to convert to GitHub. We 
can always revisit it later, should the capabilities of other systems change 
for the better.



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Ryan Schmidt]

> On Oct 7, 2016, at 3:25 PM, Marcel Bischoff  wrote:
> 
> On 16/10/07, Brandon Allbery wrote:
>> On Fri, Oct 7, 2016 at 2:38 PM, Daniel J. Luke  wrote:
>> 
>>> the cool kids also aren't writing 'tcl' these days ...
>> 
>> 
>> ...but the way they write anything else, they might as well be writing
>> fortran...
> 
> Let me just chime in here and say that those kinds of attitudes are
> exactly what I mean when I write "exclusive". It's good and fine to have
> certain standards but dismissing the majority of possible contributors
> for not meeting your personal interpretation of How Things Should Be(tm)
> is surely not helping getting MacPorts more traction. A major effort
> should be to make it as easy and straight-forward for new developers to
> contribute in a way that is considered acceptable.

I have no intention of dismissing any contributors in advance. I'll judge each 
contribution on its merits.

I agree we need to make it easier to contribute. It's going to be a long 
process of redesigning web sites, rewriting documentation, etc.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: CMake issue: binary (needed during build) links againts /opt/local/lib/foo.dylib

[Clemens Lang]

Hi Mojca,

- On 4 Oct, 2016, at 00:51, Mojca Miklavec mo...@macports.org wrote:

>-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=FALSE

I think this flag only affects installation (i.e. what happens on
make install), so you may want to check its effect once you have the
destroot phase working.


> The command "otool -L cfg" reports
>@rpath/libMiKTeX209-core.1.dylib

That looks correct, but really depends on what "cfg"'s rpath is.

-- 
Clemens Lang
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [153697] trunk/dports/sysutils/bacula

[Ryan Schmidt]

> On Oct 8, 2016, at 3:34 AM, g...@macports.org wrote:
> 
> Revision
> 153697
> Author
> g...@macports.org
> Date
> 2016-10-08 01:34:05 -0700 (Sat, 08 Oct 2016)
> Log Message
> 
> Fix QT4 detection, remove maintainer
> 
> Remove maintainer as per his request
> (
> https://lists.macosforge.org/pipermail/macports-dev/2016-October/033950.html
> )
> Add patch to fix QT4 detection
> substitute patchfiles with patchfiles-append since the +console_bat variant 
> can
> be active with either of the +mysql* and +postgres* variants, and setting the
> patchfiles again would clobber the first patch
> Closes #49203

> Added: trunk/dports/sysutils/bacula/files/patch-configure-qt4.diff (0 => 
> 153697)
> --- trunk/dports/sysutils/bacula/files/patch-configure-qt4.diff   
> (rev 0)
> +++ trunk/dports/sysutils/bacula/files/patch-configure-qt4.diff   
> 2016-10-08 08:34:05 UTC (rev 153697)
> @@ -0,0 +1,14 @@
> +--- configure.org2016-04-19 18:47:42.0 +0200
>  configure2016-04-19 18:49:24.0 +0200
> +@@ -21792,6 +21792,10 @@
> + 
> + BAT_DIR=
> + if test x$support_bat = xyes; then
> ++   # by MacPorts patch
> ++   export QMAKE='/opt/local/libexec/qt4/bin/qmake'
> ++   export PKG_CONFIG_PATH='/opt/local/libexec/qt4/lib/pkgconfig'
> ++   # by MacPorts patch end

/opt/local should not be hardcoded.



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Bacula Ticket 49203

[Aljaž Srebrnič]

> On 07 ott 2016, at 15:31, Oschwald Robert  wrote:
> 
> Hi all,
> 
> 6 months ago, I supplied patches to fix 
> https://trac.macports.org/ticket/49203 
> .
> None of the committers applied the fixes, therefore may someone please apply 
> them?
> 
> Also, please remove me as maintainer from Bacula port file, as it is of no 
> fun for me anymore to maintain ports which do not get committed for a long 
> time.

Hello Robert!
I went ahead and committed your patch (with small modifications) in r153697. I 
also removed you from the maintainer list. I’m really sorry you feel that way, 
I can assure you it’s frustrating for us too sometimes (having a *big* backlog 
of tickets is no fun at all). This will be hopefully solved in the future.

Thank you for your contributions,
Aljaž

--
Aljaž Srebrnič a.k.a g5pw
My public key:  https://g5pw.me/key
Key fingerprint = 2109 8131 60CA 01AF 75EC  01BF E140 E1EE A54E E677



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [153663] trunk/dports/kde/kmymoney4-devel/Portfile

[Ryan Schmidt]

> On Oct 6, 2016, at 8:52 PM, m...@macports.org wrote:
> 
> Revision
> 153663
> Author
> m...@macports.org
> Date
> 2016-10-06 18:52:09 -0700 (Thu, 06 Oct 2016)
> Log Message
> 
> kmymoney4-devel: increase version suffix, as that seems to be needed for the 
> port to pick up the previously added patch file

No, that's not the case.


> Modified Paths
> 
>   • trunk/dports/kde/kmymoney4-devel/Portfile
> Diff
> 
> Modified: trunk/dports/kde/kmymoney4-devel/Portfile (153662 => 153663)
> 
> --- trunk/dports/kde/kmymoney4-devel/Portfile 2016-10-07 01:37:24 UTC (rev 
> 153662)
> +++ trunk/dports/kde/kmymoney4-devel/Portfile 2016-10-07 01:52:09 UTC (rev 
> 153663)
> @@ -11,7 +11,7 @@
>  git.branch  59e9ed1cb826e8af06e3fa7c973b55ba00eab05b
>  
>  namekmymoney4-devel
> -version 4.8-20161005
> +version 4.8-20161007

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Davide Liessi]

2016-10-08 3:32 GMT+02:00 Lawrence Velázquez :
> I think this would be fine, since only a few people are likely to fetch a 
> pull request branch, and anyone who does just has to be aware that the branch 
> can be force-updated at any time.

I was about to write the same.

I would also like to propose that pull requests should always be
merged using the "Rebase and merge" option, in order to keep the
master branch as linear as possible (see
https://help.github.com/articles/merging-a-pull-request/ and
https://help.github.com/articles/about-pull-request-merges/#rebase-and-merge-your-pull-request-commits).

Davide
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev