Re: New project members: jonesc

[Marko Käning]

Welcome, Chris!
 B-D
  Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Github user repos?

[Marko Käning]

Dear Ryan,

please delete my user repo https://github.com/macports/macports-user-mk

I don’t need it and didn’t use is since ages.

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

Re: How to handle MacPorts' handles in the future (including the email address connected to it)??

[Marko Käning]

Hi Ryan,

On 02 Nov 2016, at 23:49 , Ryan Schmidt  wrote:
> I'm confused about why you're confused or what you're talking about.

:)


> We've always provided @macports.org email forwarding for committers. You tell 
> us what handle you want, we set it up to forward to whatever email address 
> you want. We had that for 10 years on macOS forge and we now moved that same 
> system to our new server. Is it not working for you for some reason?

What I mean is that I do receive the emails being sent to you via my macports
handle mk, but I can’t send emails through smtp.macports.org or something like
that. I’d like to be able to send emails as well, not just receive them. What
am I missing here - in case the requested is also possible since 10 years?

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

Re: Pull Requests for Work in Progress (WIP)

[Marko Käning]

On 04 Nov 2016, at 02:19 , Arno Hautala  wrote:
> But, it occurs to me that one of the goals of moving
> to GitHub is greater collaboration and that is facilitated by inline
> comments on the pull request. Plus, a completed pull request is one
> comment away from a work in progress anyway.

+1


> The alternative to WiP pull requests is posting multiple comparison
> URLs to reference different lines of code that must be opened in
> different windows. Plus, those references will break as soon as any
> changes are made to the branch.

Exactly, I don’t think this is the way to go.

But let’s those decide who would have to deal (or not) with those red “WIP” 
badges in GitHub PR interface every now and then...

Well, if it is too much red noise in the PR interface then one would have to 
have these discussions directly on the contributors’ private forks of the 
macports-ports.
Downside there: If one decides to kill one of these repos all their comments to 
the relevant code are gone. So, that’s perhaps an argument more for keeping WIP 
PRs?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Pull Requests for Work in Progress (WIP)

[Marko Käning]

Hi Rainer,

On 03 Nov 2016, at 18:57 , Sterling Smith  wrote:
> On Nov 3, 2016, at 10:47AM, Rainer Müller  wrote:
> 
>> On 2016-11-03 17:49, Sterling Smith wrote:
>>> The main question of procedure is: Should the main macports repo be
>>> used for proposing review of work in progress via pull requests?  If
>>> not, what is the proposed method?
>> 
>> I propose you put your changes on a branch, add the compare URL to a
>> ticket or send an email to macports-dev.
>> 
>> In the case you referred to, this would be:
>> 
>> https://github.com/mkae/macports-ports/compare/master...mkae:qtcurve_upgrade-for-Qt5
>> 
> The downside (as I see it) of using the compare URL, as opposed to a full 
> pull request, is that line by line comments are not available.

I think this is _downside_ enough to NOT use the approach suggested by you, 
because loosing the reviewing features (comments directly in the code) doesn’t 
make reviewers’ work easier, does it!

Besides there is even a clearly visible RED "Work-In-Progress" label available 
in the PR interface, which Mojca had spotted eventually.

But, hey, who am I to oppose such a decision if the core team of committers 
doesn’t think it’s a good idea?
Perhaps we should initiate a poll among the top 10 or even 20 committers, who 
are carrying the major load of reviewing/committing for MacPorts’ ports repo???

Greets,
Marko

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

Re: Proposal for a MacPorts'ish commit message template

[Marko Käning]

Hi Larry,

On 04 Nov 2016, at 18:34 , Lawrence Velázquez  wrote:

> It doesn't really do anything differently w.r.t. wrapping, but it
> highlights subject-line overflow in an alarming red color.

that’s a nice feature. Will have to test whether that works as documented
in our WorkingWithGit wiki page...


> Not a waste of time! Can't know what the water is like without dipping
> your toe in. We appreciate your enthusiasm :)

Well, I respect the work you guys have been done and are doing for MacPorts
and I appreciate that you do the same for those who try to support this
operation to the best of their knowledge.

:)

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

Re: Proposal for a MacPorts'ish commit message template

[Marko Käning]

On 02 Nov 2016, at 23:33 , Ryan Schmidt  wrote:

> ...my initial reaction to your template (and my initial reaction when I saw 
> it mentioned previously) was "TL;DR”.

I got it now. :)


>> vim does that with syntax highlighting automatically nowadays when it
>> notices you are writing a commit message. If you need an indication on
>> your line width, may I suggest you configure your editor appropriately?
> 
> Can we document in the WorkingWithGit page how to do that? I have no idea.

I thought exactly the same, Ryan! ;-)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Marko Käning]

On 02 Nov 2016, at 01:03 , Lawrence Velázquez  wrote:
> To be honest, this template adds so much comment noise that I can't
> imagine ever using it.

That’s fine ok, your decision. :)


>> --- ~/.git-commit-template ---
>> #  Please enter the commit message for your changes. Lines starting
>> #  with '#' will be ignored, and an empty message aborts the commit.
>> #
>> #   -> The title MUST not be longer than 50 characters. 
> 
> I don't think we should dictate a hard limit on this. Sometimes it's
> hard to say anything meaningful in 50 characters, especially since we
> prepend port names to the subject line. Anything less than 60 chars is
> generally good enough.

Please, check out our own WorkingWithGit wiki page. That’s exactly the
source of information I used to set up the commit template suggestion.
I just included our publicly available commit rules for the committers. 


>> #   -> You MUST wrap all further lines at 72 characters.
>> #
>> #  For more information on how to write commit messages see MacPorts'
>> #  wiki at https://trac.macports.org/wiki/WorkingWithGit#commitmessages
>> #
>> # ==[ Subject: One meaningful line ONLY!  ]==|
>> 
>> # ==[ Blank: Follow the Subject with a blank line, do NOT remove ]=|
>> 
>> # ==[ Details: Describe what changed and explain why it changed]===|
> 
> This is all informative exactly once.

Yes.


> As Clemens already noted, these aren't the supported keywords.

I am aware of that!


>> I have fantasised a little here what concerns the (perhaps upcoming)
>> BUILDBOT feature.
> 
> I wouldn't hold my breath on this.

I am not. I know that this won’t have priority and will only be implemented
if someone really sees a benefit in test-building stuff on an individual
builder.


> We have the wiki and guide for documentation. This template is not the
> place for documentation.

Well, actually, I do see your point. But what good is it if even you didn’t
know the rules about the maximum number of chars in a line? ;-) Having said
that I also think that you’ll mostly have a hard time to bring a conscience
message including the port name into just 50 characters!


>> But perhaps all this is overkill?!
> 
> In case it's not obvious, I think this is serious overkill.

You made very obvious to me.

I do know now what not to do in the future: trying to come up with such kind
of suggestions - while not being a professional software developer and just
some guy who tries to support a collaborative initiative like MacPorts to the
best of his (admittedly) limited knowledge.

Moving on to the next response...
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Marko Käning]

Hi,

On 02 Nov 2016, at 00:08 , Clemens Lang  wrote:
> Developers are free to use your template if they want to. We don't want
> to mandate using it though (since we couldn't enforce it anyway).

yeah, I am aware of that.


> vim does that with syntax highlighting automatically nowadays when it
> notices you are writing a commit message. If you need an indication on
> your line width, may I suggest you configure your editor appropriately?

Oh, I’d be using vim as well, good to know that it does support git.
I didn’t know that vim would be able to treat commit message line formatting
for the first and the 3r+ lines differently with 50 and 72 chars respectively.


>> # --[ Links to issues on MacPorts' trac ]--|
>> #ISSUE:  
>> #RESOLVES:   
>> #BLOCKED BY: 
> 
> You could have taken the time to actually adjust this to what MacPorts'
> Trac instance accepts. See
> https://trac.edgewall.org/wiki/CommitTicketUpdater
> for the description of the plugins that does this for us and
> https://github.com/macports/trac.macports.org/blob/master/conf/trac.ini#L251
> for the configuration we use.

Yes, I could have, indeed, but I thought it was clear from my post that I was
trying to start a discussion about it and that I didn’t intend to deliver a
ready-made template with everything already prepared. Especially not because
I knew you weren’t fond of the whole idea anyways. How right I was I see from
the responses in this thread. ;-)


>> # --[ Links to other pull requests at GitHub ]—|
>> #PR:  
>> #
>> ##EXAMPLE:
>> # PR:  #123
> 
> Could use the documented keywords GitHub accepts to handle pull requests
> (you can close pull requests from commit messages!)

I could have done this too, yes. But I didn’t know about this GitHub
functionality up to now.


> Additionally, I don't like the upper case keywords.

Well, this was a trigger for a discussion about the topic of a template which
potentially could make the committer’s life easier... But I understood in the
meantime that I could have just used my spare time much better for other
things than trying to care about such silly things like a commit template.
I thought what KDE has is a good starting point and I believed MacPorts devs
would see value in it. I have now been taught that I wasted my time and yours.
Fine with me.

Moving on to the next response...
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Proposal for a MacPorts'ish commit message template

[Marko Käning]

On 01 Nov 2016, at 23:56 , Sterling Smith  wrote:

> Remind me, would using this template still give the commented git status 
> (which is the default)?

Yes, make a change and test it like this:

 $ git commit -a -t ~/.git-commit-template

The status gets appended at the bottom.

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

Proposal for a MacPorts'ish commit message template

[Marko Käning]

Hi MacPorts’ GitHubians,

I know that many of you weren't in favour of a commit message template,
but I propose one anyway, which I derived from KDE’s neat one, as I find
it on the console quite handy to know when 50 or 72 characters are
reached in a line:



--- ~/.git-commit-template ---
#  Please enter the commit message for your changes. Lines starting
#  with '#' will be ignored, and an empty message aborts the commit.
#
#   -> The title MUST not be longer than 50 characters. 
#
#   -> You MUST wrap all further lines at 72 characters.
#
#  For more information on how to write commit messages see MacPorts'
#  wiki at https://trac.macports.org/wiki/WorkingWithGit#commitmessages
#
# ==[ Subject: One meaningful line ONLY!  ]==|

# ==[ Blank: Follow the Subject with a blank line, do NOT remove ]=|

# ==[ Details: Describe what changed and explain why it changed]===|

# ==[ Fields: Uncomment and edit where applicable ]|

# --[ Links to issues on MacPorts' trac ]--|
#ISSUE:  
#RESOLVES:   
#BLOCKED BY: 
#
##EXAMPLE:
# ISSUE: https://trac.macports.org/ticket/98765
#
##NOTE: Don't use '#'-notation, since it's a Pull Request ID on GitHub!
#
# --[ Links to other pull requests at GitHub ]—|
#PR:  
#
##EXAMPLE:
# PR:  #123
#
#
# --[ FUTURE FEATURE TO IGNORE/TRIGGER BUILDS ON SPECIFIC BUILDBOTS ]--|
#BUILDBOT: < ignore | list_of_buildbots >
#
##EXAMPLE:
# BUILDBOT: ignore
# BUILDBOT: ports-10.9_x86_64 ports-10.12_x86_64
#
##NOTE: This isn't yet implemented at MacPorts' GitHub!
#
##NOTE: See relevant issue: https://trac.macports.org/ticket/52769
---



I have fantasised a little here what concerns the (perhaps upcoming)
BUILDBOT feature.

The links section is also just serving as an example, but it might be a
good idea to define some useful keywords there as well.

I also introduced a pull request section, which might be nice to have
for proper documentation, who knows.

But perhaps all this is overkill?!

Suggestions are welcome.

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

Re: Github user repos?

[Marko Käning]

The question I already posted in the “GitHub migration complete” thread was 
whether I can simply remove my git repo altogether?


On 01 Nov 2016, at 09:52 , Marko Käning <mk-macpo...@posteo.net> wrote:

> On 01 Nov 2016, at 04:00 , Ryan Schmidt <ryandes...@macports.org> wrote:
>> We suggest that you move your user repository to your own GitHub account 
>> where you can continue to use it as you see fit. Instructions for how to 
>> move it are forthcoming. You should not use the Fork button to do so.
> 
> Can I simply remove it?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to handle MacPorts' handles in the future (including the email address connected to it)??

[Marko Käning]

Hi Rainer,

On 01 Nov 2016, at 21:05 , Rainer Müller  wrote:
> What do you mean by address rewriting? If you are referring to problems
> with SPF,

I guess I do.


> the new mail server is now doing SRS [1].

OK...


> Right now we do not host any mailboxes with IMAP, we only forward mails
> to existing addresses. I would like to keep the administrative overhead
> low, certainly all developers have an existing mailbox.

Yeah, I understand that. I’d be happy enough with the rewriting approach.


> Although I thought about implementing authenticated mail submission on
> our mail server in order to be able to enable SPF for macports.org and
> reduce spam. But that will not happen in the near future while there are
> other issues.

So, what does it mean? Does the new server support it - as written above - or 
doesn’t MacPorts support it?

You see me confused. ;)

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

Re: rev-upgrade question

[Marko Käning]

On 01 Nov 2016, at 19:57 , Rainer Müller <rai...@macports.org> wrote:

> On 2016-11-01 19:50, Clemens Lang wrote:
>> On Tue, Nov 01, 2016 at 07:09:48PM +0100, Marko Käning wrote:
>>> how can I convince rev-upgrade to actually rebuild broken ports if
>>> 'revupgrade_mode' is set to ‘report' in macports.conf? 
>> 
>> You can specifically rebuild them manually using port -nf upgrade $port.
> 
> Never use the global force option -f with upgrade, but instead:
> 
>  sudo port -n upgrade --force $port
> 
> The local --force was specifically added to only force the upgrade, but
> do not apply force to any other phase. In case of variant mismatches,
> the global 'port -f' will continue although the state in the work/
> directory is inconsistent. In case of activation conflicts, the global
> 'port -f' will blindly overwrite existing files.

Jeez, thanks, guys, for the pointers! I haven’t thought about that an
individual upgrade would do the job just fine. But here I see that even
that isn’t that easy...

This should be in the wiki, man page and our Guide!

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

How to handle MacPorts' handles in the future (including the email address connected to it)??

[Marko Käning]

Hi folks,

Mojca was addressing the email and MacPorts handle issue in thread

“[macports-ports] branch master updated: berkeleygw: Remove svn $Id$ 
line.”

which brings me to the point, that this in in fact a bit of an long standing 
annoyance for me.

On 01 Nov 2016, at 19:42 , Mojca Miklavec  wrote:

> Many committers now have two different usernames, one MacPorts handle
> and one GitHub account.


I’d actually be happier if I had my - up to now - MacPorts handle (mk) also for 
the future… :)

But ok, I guess I’ll have to apply at ad...@macports.org for a new handle then, 
being m...@macports.org, right?

The only problem with all this is, that I then have to ask my good old friend 
Brad (pixilla) to create that user mkae on his mail server (which can handle 
address rewriting).

Yet, I’d appreciate if macports.org would have this email service included!

Well, as an alternative I could go through my own email provider, but they have 
special requirements for such address rewriting and I wonder whether at least 
those could be fulfilled by macports.org - in case it is absolutely impossible 
to get an email address at MacPorts’ IMAP server directly.

What can be done about this whole subject in the future?

Best regards,
Marko

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

rev-upgrade question

[Marko Käning]

Hi folks,

how can I convince rev-upgrade to actually rebuild broken ports if 
'revupgrade_mode' is set to ‘report' in macports.conf? 

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

Re: Trac down again

[Marko Käning]

Trac is down again. It seems like it is periodically dying and reviving itself. 
:(
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Marko Käning]

On 01 Nov 2016, at 01:10 , Brandon Allbery  wrote:

> You can even configure so that becomes the default for "git pull" for that 
> repo.
> 
> git config --local --bool pull.rebase true
> git config --local --bool rebase.autoStash true

This should go into the wiki page!

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

Re: Working with Git

[Marko Käning]

On 01 Nov 2016, at 09:57 , Rainer Müller  wrote:
> 
> I do not see valid reasons not to use hub.

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

Re: Removing "$Id$" lines

[Marko Käning]

On 01 Nov 2016, at 02:02 , Rainer Müller  wrote:
> buildbot: ignore

+1

I’d also suggest to use this also to specify which buildbots should be used for 
a commit:

buildbot: Mavericks Sierra

I think that can be very helpful in some cases.


Opened a ticket for this: https://trac.macports.org/ticket/52769#ticket
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub migration complete

[Marko Käning]

On 01 Nov 2016, at 04:00 , Ryan Schmidt  wrote:
> We suggest that you move your user repository to your own GitHub account 
> where you can continue to use it as you see fit. Instructions for how to move 
> it are forthcoming. You should not use the Fork button to do so.

Can I simply remove it?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Marko Käning]

Hi Mojca and Ryan,

On 01 Nov 2016, at 05:54 , Mojca Miklavec  wrote:
> I'm with Ryan in this case. We don't prevent anyone from using this
> software if they choose to, I just don't see the point of advertising
> software whose maintainer decided to go against MP.

I am with you here! Port hub is there for use on MacPorts for anyone who
might find it useful anyways. So, leave it at that and remove the hint on
the wiki page. It doesn’t make sense to do advertisement for someone who’s
not interested in that extra attention.

Greets,
Marko


P.S.: Reading hub’s dev’s comment to the first issue [1] one shouldn’t
even assume open opposition against MacPorts, IMHO. I read there that
the guy wants to support his tool all himself w/o anyone else interfering
and thus he only cares about what he is using, namely HB. I find it
understandable from his point of view if he’s not intending to jointly
develop his code together with the whole Open Source community. The MIT
license allows us to host it and give any interested user access to this
(potentially useful) software. So be it. :)


[1] https://github.com/github/hub/pull/211

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

Re: [macports-ports] branch master updated: jasper: needs a revbump

[Marko Käning]

So, now I ran *again* into a problem with my local install after self updating 
it just now:
---
$ port -v rev-upgrade
--->  Scanning binaries for linking errors
Warning: Error parsing file /opt/local/bin/cdda2wav: Error opening or reading 
file
Warning: Error parsing file /opt/local/bin/cdrecord: Error opening or reading 
file
Warning: Error parsing file /opt/local/bin/readcd: Error opening or reading file
Warning: Error parsing file /opt/local/sbin/rscsi: Error opening or reading file
Warning: Error parsing file /opt/local/libexec/dbus-daemon-launch-helper: Error 
opening or reading file
Incompatible library version: /opt/local/bin/imgcmp requires version 12.0.0 or 
later, but /opt/local/lib/libjpeg.9.dylib provides version 11.0.0
Incompatible library version: /opt/local/bin/imginfo requires version 12.0.0 or 
later, but /opt/local/lib/libjpeg.9.dylib provides version 11.0.0
Incompatible library version: /opt/local/bin/jasper requires version 12.0.0 or 
later, but /opt/local/lib/libjpeg.9.dylib provides version 11.0.0
Incompatible library version: /opt/local/bin/tmrdemo requires version 12.0.0 or 
later, but /opt/local/lib/libjpeg.9.dylib provides version 11.0.0
Incompatible library version: /opt/local/lib/libjasper.1.dylib requires version 
12.0.0 or later, but /opt/local/lib/libjpeg.9.dylib provides version 11.0.0
--->  Found 5 broken file(s), matching files to ports
--->  Found 1 broken port(s):
 jasper @1.900.16 
 /opt/local/bin/imgcmp
 /opt/local/bin/imginfo
 /opt/local/bin/jasper
 /opt/local/bin/tmrdemo
 /opt/local/lib/libjasper.1.dylib
---

So, obviously, my own setup is borked. Turns out I have an older jpeg in my 
ports tree
---
$ port dir jpeg
/Users/marko/WC/GIT/macstrop/graphics/jpeg
---
which is the cause of trouble here.

I am sorry for rev-bumping! Not the first time that this happens to me. I have 
to become more careful!!!
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub migration complete

[Marko Käning]

On 31 Oct 2016, at 21:14 , Lawrence Velázquez <lar...@macports.org> wrote:

>> On Oct 31, 2016, at 5:23 AM, Marko Käning <mk-macpo...@posteo.net> wrote:
>> 
>> a post-commit-hook checking whether the GitHub pull request ID #123
>> actually exists for the main repository seems like a valuable feature,
>> especially in the transition phase. Shall I file a ticket on trac for it?
> 
> Sure, if you like. Feel free to assign me as owner; I'll try to look into it 
> this week.

Thanks, done in https://trac.macports.org/ticket/52763#ticket .
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [macports-ports] branch master updated: jasper: needs a revbump

[Marko Käning]

On 31 Oct 2016, at 20:25 , Joshua Root  wrote:
> Depends on the nature of the breakage, which is not shown above. The only 
> dependency is jpeg, which has not changed in some time. My jasper 
> installation is certainly not broken.

Hmmm…

OK, next time I need to get more detailed logs. Just don’t know how to get that 
done in the demoed workflow. :(


> Maybe something else is being linked to, in which case simply rev bumping 
> does not fix the problem. Or maybe something happened to your copy of jpeg 
> that changed the soname, in which case that is the problem.

I don’t think I can do anything now there anymore.

Perhaps I better ask the list if I run into stg similar again and then we can 
decide together whether to revbump or not?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [macports-ports] branch master updated: jasper: needs a revbump

[Marko Käning]

Hi Joshua,

On 31 Oct 2016, at 18:04 , Joshua Root  wrote:
> Why?

because I ran into this:
---
$ port dir jasper
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/graphics/jasper
$ sudo port upgrade outdated
--->  Computing dependencies for jasper
--->  Fetching archive for jasper
--->  Attempting to fetch jasper-1.900.16_0.darwin_13.x86_64.tbz2 from 
http://nue.de.packages.macports.org/jasper
--->  Attempting to fetch jasper-1.900.16_0.darwin_13.x86_64.tbz2.rmd160 from 
http://nue.de.packages.macports.org/jasper
--->  Installing jasper @1.900.16_0
--->  Cleaning jasper
--->  Computing dependencies for jasper
--->  Deactivating jasper @1.900.5_0
--->  Cleaning jasper
--->  Activating jasper @1.900.16_0
--->  Cleaning jasper
--->  Uninstalling jasper @1.900.5_0
--->  Cleaning jasper
--->  Computing dependencies for py27-pycparser
--->  Fetching archive for py27-pycparser
--->  Attempting to fetch py27-pycparser-2.17_0.darwin_13.noarch.tbz2 from 
http://nue.de.packages.macports.org/py27-pycparser
--->  Attempting to fetch py27-pycparser-2.17_0.darwin_13.noarch.tbz2.rmd160 
from http://nue.de.packages.macports.org/py27-pycparser
--->  Installing py27-pycparser @2.17_0
--->  Cleaning py27-pycparser
--->  Computing dependencies for py27-pycparser
--->  Deactivating py27-pycparser @2.16_1
--->  Cleaning py27-pycparser
--->  Activating py27-pycparser @2.17_0
--->  Cleaning py27-pycparser
--->  Uninstalling py27-pycparser @2.16_1
--->  Cleaning py27-pycparser
--->  Computing dependencies for py27-setuptools
--->  Fetching archive for py27-setuptools
--->  Attempting to fetch py27-setuptools-28.7.0_0.darwin_13.noarch.tbz2 from 
http://nue.de.packages.macports.org/py27-setuptools
--->  Attempting to fetch py27-setuptools-28.7.0_0.darwin_13.noarch.tbz2.rmd160 
from http://nue.de.packages.macports.org/py27-setuptools
--->  Installing py27-setuptools @28.7.0_0
--->  Cleaning py27-setuptools
--->  Computing dependencies for py27-setuptools
--->  Deactivating py27-setuptools @28.5.0_0
--->  Cleaning py27-setuptools
--->  Activating py27-setuptools @28.7.0_0
--->  Cleaning py27-setuptools
--->  Uninstalling py27-setuptools @28.5.0_0
--->  Cleaning py27-setuptools
--->  Computing dependencies for py34-setuptools
--->  Fetching archive for py34-setuptools
--->  Attempting to fetch py34-setuptools-28.7.0_0.darwin_13.noarch.tbz2 from 
http://nue.de.packages.macports.org/py34-setuptools
--->  Attempting to fetch py34-setuptools-28.7.0_0.darwin_13.noarch.tbz2.rmd160 
from http://nue.de.packages.macports.org/py34-setuptools
--->  Installing py34-setuptools @28.7.0_0
--->  Cleaning py34-setuptools
--->  Computing dependencies for py34-setuptools
--->  Deactivating py34-setuptools @28.5.0_0
--->  Cleaning py34-setuptools
--->  Activating py34-setuptools @28.7.0_0
--->  Cleaning py34-setuptools
--->  Uninstalling py34-setuptools @28.5.0_0
--->  Cleaning py34-setuptools
--->  Computing dependencies for py35-setuptools
--->  Fetching archive for py35-setuptools
--->  Attempting to fetch py35-setuptools-28.7.0_0.darwin_13.noarch.tbz2 from 
http://nue.de.packages.macports.org/py35-setuptools
--->  Attempting to fetch py35-setuptools-28.7.0_0.darwin_13.noarch.tbz2.rmd160 
from http://nue.de.packages.macports.org/py35-setuptools
--->  Installing py35-setuptools @28.7.0_0
--->  Cleaning py35-setuptools
--->  Computing dependencies for py35-setuptools
--->  Deactivating py35-setuptools @28.5.0_0
--->  Cleaning py35-setuptools
--->  Activating py35-setuptools @28.7.0_0
--->  Cleaning py35-setuptools
--->  Uninstalling py35-setuptools @28.5.0_0
--->  Cleaning py35-setuptools
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  Found 5 broken file(s), matching files to ports
--->  Found 1 broken port(s), determining rebuild order
--->  Rebuilding in order
 jasper @1.900.16 
--->  Computing dependencies for jasper
--->  Cleaning jasper
--->  Scanning binaries for linking errors
--->  Found 5 broken file(s), matching files to ports
--->  Found 1 broken port(s), determining rebuild order
--->  Rebuilding in order
 jasper @1.900.16 
--->  Computing dependencies for jasper
--->  Fetching distfiles for jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 
http://nue.de.distfiles.macports.org/jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 
https://distfiles.macports.org/jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 
http://lil.fr.distfiles.macports.org/jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 
http://mse.uk.distfiles.macports.org/sites/distfiles.macports.org/jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 
http://osl.no.distfiles.macports.org/jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 
http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 

Re: GitHub migration complete

[Marko Käning]

Hi Larry,

On 31 Oct 2016, at 05:38 , Lawrence Velázquez  wrote:
> Old habits die hard, but from now on do NOT refer to Trac tickets as
> "#12345" in your commit messages; GitHub's website interprets those as
> pull request numbers. Copy and paste the full Trac URL instead.

a post-commit-hook checking whether the GitHub pull request ID #123
actually exists for the main repository seems like a valuable feature,
especially in the transition phase. Shall I file a ticket on trac for it?

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

Re: nested port upgrading and variants

[Marko Käning]

Hi folks,

thanks René, for reporting, but ...

On 27 Oct 2016, at 21:59 , René J.V. Bertin  wrote:
> On Thursday October 27 2016 14:55:59 Ryan Schmidt wrote:
> 
>>> That's what I told Marko too, but we're not talking here about the initial 
>>> installation. I think that when you already have opencv+qt5+opencv 
>>> installed, an automatic upgrade to opencv should behave like `port upgrade 
>>> opencv`. IOW, it should maintain the active variants. Anything else is a 
>>> waste of time and source of frustration.
>> 
>> I'm not aware of any reason why that wouldn't happen. MacPorts preserves 
>> variants on upgrades.
> 
> And neither do I see any reason why the use of the active_variants portgroup 
> would change anything in this matter, but one can never be too sure.
> 
> Let's see what Marko has to tell us about the exact command he used that led 
> to opencv being upgraded without its current variants.

I’ve to see whether I can resurrect some snapshot where I hadn’t updated opencv 
yet to check whether I can reproduce the oddity.

I’ll come back to you soonish, but not very quick, as I am absorbed with other 
more pressing stuff right now.

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

Re: Git tools for managing patchsets

[Marko Käning]

On 26 Oct 2016, at 17:54 , Michael  wrote:

> Interesting that you mention "Quilt". There is another tool -- Stacked Git -- 
> that is modeled after Quilt.

I don’t see the point of these additional tools on top of git?
If git provides branches, why do I need extra magic to work with them?

Yet, even when I worked with Mercurial I also always wondered why people needed 
all this lark called “Mercurial Patch Queues", which is probably something like 
“Quilt" and "Stacked Git”…

I don’t think anyone would need all this stuff for port maintenance on 
macports/macports-ports.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Trac down again

[Marko Käning]

Where is our trac again?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

[Marko Käning]

I fully agree with Mojca, that it is better to work on a private fork for the 
start and let others - like Clemens suggested - take part in reviewing on that 
forked repository. This way one can train what would have to be done on the 
main macports-ports repo before causing trouble there...


On 24 Oct 2016, at 19:58 , Clemens Lang  wrote:

> Yes, that's also my preference. So we can agree on:
> - rebase when merging PRs
> - rewrite history on PR branches until it looks good

A description of how exactly one would rebase (potentially squash and 
history-rewrite) a submitted PR onto current master should be on our 
WorkingWithGit wiki page.

At the moment it is not very clear to me how a MacPorts committer would 
actually deal with a pull request submitted by a port maintainer to the central 
repository. But I’ve got to admit that I haven’t read much more than our wiki 
page up to now. There are surely more details in GitHub’s help...
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Git tools for managing patchsets

[Marko Käning]

Hi folks,

when I read only the first two paragraphs of this thread...

On 24 Oct 2016, at 18:37 , Michael  wrote:
> So since MacPorts is moving to git, and from what I saw in the "how to use 
> git" docs you mentioned, you apparently want people to work with patchsets 
> rebased onto the current head from upstream.
> 
> As I was thinking about that, I realized that you lose your history of the 
> patchset in the process.

... I already got the shivers! My goodness, how much did I enjoy the ease of 
Mercurial! Loosing history because of a patch set?!
:-/

Well, but I think what you, Michael, are describing, is only needed if you work 
with many patches which aren’t really committed to any repository.

Whenever a MacPorts maintainer has finished polishing her/his changes to a 
specific port, those changes will be rebased on top of the current master - 
maintaining all the history - as pointed out by others already.

The only question mark I have there is:

Will we ask the committers to squash their changesets
or prefer to clutter the main repo with potentially
many tiny iterations for the changed ports??

Personally I don’t like history rewriting, but a squash every now and then 
seems fine to me, as an update to a port sometimes requires a few iterations 
until it is ready for pushing to the central repo and it is usually one logical 
unit deserving an atomic commit.

Good night,
Marko

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

Re: QTKit & macOS Sierra

[Marko Käning]

Hi René,

On 24 Oct 2016, at 09:57 , René J.V. Bertin <rjvber...@gmail.com> wrote:

> On Monday October 24 2016 09:54:56 Marko Käning wrote:
> 
> Indirectly, yes. I get the impression port:opencv has been unmaintained for a 
> while, so maybe you can update the official copy from mine?

I’ve added all patches to the main opencv ticket for sierra [1] for stromnov to 
review and also created a ticket for the required changes to CMake’s portgroup 
version 1.1 [2].

@René, can you perhaps add a little description to [2]? Let me know if you 
can’t modify the ticket’s description field. I’ll do that for you in that case.

Thanks in advance!
Greets,
Marko



[1] https://trac.macports.org/ticket/52328
[2] https://trac.macports.org/ticket/52699
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port:qt5 and (proposed) port:qt5-kde cohabitation

[Marko Käning]

Hi,

On 07 Oct 2016, at 17:31 , René J.V. Bertin  wrote:
> Port:qt5-kde doesn't depend on cmake anyway so it's pointless to hold up the 
> Qt5 discussion for it (but the KF5 ports do).

OK, then let’s wait regarding the cmake portgroup until we’ve qt5-kde committed.


> I should have another look at exactly how the mainstream *Qmake5* PortGroup 
> interacts with port:qt5-kde . 

Could you investigate this further in the meantime?
 

> Leaves the 3 Qt5 PortGroup files.

Yes, so we’re indeed down to those three (see also [1]).

I guess we can wait committing those once the new GitHub workflow is in place, 
because
it would make reviewing all the changes much easier in a GitHub’ish pull 
request. :)

Greets,
Marko



[1] https://trac.macports.org/ticket/48967#comment:46

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

Re: port:qt5 and (proposed) port:qt5-kde cohabitation

[Marko Käning]

Hi,

in the light of the upcoming commit of the new 'qt5-kde' port I want to ask 
(again)
whether it would be acceptable, that we - for the sake of housekeeping - store 
all
KF5-related ports in a dedicated folder at

dports/kf5

or whether it is really necessary, that all these KDE ports have to live under

dports/kde

just like all those port files belonging to KDE 3 and 4?

We’re not opposed to do the latter, but it will be somewhat messier!


Since

 - KDE4 will still be around for some time,

 - KF5 only now picking up speed on OSX

 - and both port collections having independent maintainers (Nicolas and René)

it would make maintenance easier if one kept also their storage locations 
separate,
no?


Are there other reasons of not going for such an approach which we up to now 
aren’t
aware of, perhaps?

Greets,
Marko

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

Re: Buildbots logon failing...

[Marko Käning]

On 22 Oct 2016, at 18:28 , Ryan Schmidt  wrote:
> There's been no change to the buildbot. It still uses the separate user and 
> password database from the old macOS forge buildbot. 

Turns out that I tried to log in with my full handle email address, instead of 
only using ‘mk’.

Sorry for the noise!
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Buildbots logon failing...

[Marko Käning]

Hi,

can it be that the authentication info for the buildbots hasn’t been migrated 
yet?

I wanted to restart a build of kmymoney4-devel and couldn’t since my logon 
failed.

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

Re: SVN committing not possible ATM?

[Marko Käning]

Hi Rainer,

On 22 Oct 2016, at 15:17 , Rainer Müller  wrote:
> This is probably some configuration issue on the server. We have not yet
> figured out what causes this, but you are the second to report this. It
> only seems to affect some users with specific commits.
> 
> I have a slight suspicion that it is related to internal locking in
> mod_dav_svn for some operations, but could not nail it down yet.

it seems to be fixed now, as I finally could commit:
---
$ svn ci -m "gwenhywfar4-devel: update to 4.16.0beta"

SendingPortfile
Transmitting file data .done
Committing transaction...
Committed revision 154149.
---

Thanks for dealing with this so quickly!

Greets,
Marko

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

Re: Moving to GitHub: Status Update, Action Required

[Marko Käning]

On 22 Oct 2016, at 14:49 , Joshua Root  wrote:

> Please see the Migration Timeline section in the first message in this 
> thread. Developers cannot yet push to the git repos.

yes, I figured that now.


OK, awaiting you guys’ decisions on the new workflow.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Moving to GitHub: Status Update, Action Required

[Marko Käning]

Hi Clemens,

On 22 Oct 2016, at 14:41 , Clemens Lang  wrote:
> Developers will merge them, either using the command line client, or the
> GitHub UI. We haven't decided and documented which merge method to use,
> although I'd prefer the rebase.

ok, I see.

BTW, you’ve mentioned in some thread lately this GitHub command line client!
However, exactly that client doesn’t yet appear on the WorkingWithGit tools
page [1]. I guess it would be worth adding.


> Pull access means that we haven't given the team write access to the
> repository yet, so at the moment being a member of the GitHub org only
> gives you added privileges in Trac. This will change as soon as we're
> done with the conversion next weekend.

OK, that clarifies things. Thanks.

Greets,
Marko



[1] https://trac.macports.org/wiki/WorkingWithGit#tools

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

Re: Moving to GitHub: Status Update, Action Required

[Marko Käning]

Hi Clemens,

great to see the GitHub conversion progressing this rapidly! Thumbs up from 
me!!!


When reading the WorkingWithGit wiki page [1] I saw how port contributors can 
post
their suggestions to MacPorts via "Pull Requests”, yet it does not get clear 
from
that text how those PRs will then actually be included into the official repo…

Just this moment I got invited to MacPorts' "Developer team" on GitHub and saw 
that
I now have "pull access” to the MacPorts ports repository, which is probably 
enabling
me in the future to push changes into it?

But the term “pull access” confuses me here!

I mean, I can pull in changes into my clone or fork from the MacPorts repo any 
time…

Can you clarify this somewhat, as I have no experience yet in teams on GitHub!?

Thanks,
Marko




[1] 
https://trac.macports.org/wiki/WorkingWithGit#Commongittaskswhileworkingwithports
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: 2nd MacPorts Meeting & Online Meeting

[Marko Käning]

Hi Clemens,

On 16 Oct 2016, at 23:58 , Clemens Lang  wrote:
> Thanks, and sorry for not putting a plan together to do it in Munich in
> the fall. Seems I need to improve my time management :)

now that you say it… Weren’t you aiming at the Wiesn earlier this year?
;-)


>> In addition to the face-to-face meeting, I would like to propose
>> trying out some online meeting some time in mid-November (or any other
>> time, according to your wishes).
> 
> A good idea, we should try that.

+1


> I think this might also be a good time to give a quick status update on
> where we are with the conversion to Git and the move to GitHub, and
> potentially answer questions that any of the attendees might have.

+1


> There's quite a bit of work going on at the moment "behind the scenes"
> that does not make it to the mailing lists, and I have a feeling it
> seems to the list like there is no progress, which is not the case.

I noticed that there is eventually an official MacPorts ports git repo [1]
online since a few days now, which Ryan seems to be administering…
Cools stuff! It looks like MacPorts will soon work through git. I think I
was the first who forked this. ;)

Congratulations for your behind-the-scenes progress!!!

Greets,
Marko





[1] https://github.com/macports/macports-ports
___
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

[Marko Käning]

Hi Ryan,

On 08 Oct 2016, at 10:04 , Ryan Schmidt  wrote:
>> 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.


When I committed that revbump I was already unsure whether I am mistaken. I see 
now I indeed was. Those ports built locally because I have a 
capitalisation-insensitive file system. This is probably not the case for the 
buildbots.

Have tried to fix that now in r153803.

Thanks for your attention, Ryan!

Greets,
Marko



P.S.: Unfortunately the kmymoeny4(-devel) ports are still failing, due to 
akonadi consistently failing on all builtbots at this point in time.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port:qt5 and (proposed) port:qt5-kde cohabitation

[Marko Käning]

Dear Qt folks,

regarding René's post from March (see below) I believe it would be good to
give a _short_ update on the qt5-kde port status.


Currently the situation for port qt5-kde is as follows:

 - Qt at version 5.6.1

 - tested building on Mavericks and El Capitan VMs

 - René also managed to get qt5-kde-qtwebkit into a separate subport

 - allows to build almost all of the KF5 ports @ version 5.24 successfully

 - 5 port groups would have to be updated (see comments 30-34 in [1])



We are very interested in feedback from other Qt maintainers concerning our
chosen path to offer an alternative port for Qt5, which is dedicated to a
better user experience for KDE specifically.


Can we

  a) find a way to merge qt5 and qt5-kde(-devel) somehow 

  b) or should we live with offering a dedicated Qt for KDE ??



   What’s your opinion regarding this?



If you’re FOR b), I’d soonish like to commit this port because automated CI
is simply a must now. Us two doing all the build tests is tedious and error
prone.

Also we’d like to introduce the long-planned introduction of KF5 after all,
since KDE4 apps aren’t really maintained anymore.

Greets,
Marko



  P.S.: I could also test it locally on a macOS "10.12.1 Beta” VM before
committing anything... although I’d prefer to delegate this job
to our macOS buildbot instead. ;-)




[1] https://trac.macports.org/ticket/48967#comment:30





On 17 Mar 2016, at 12:37 , René J.V. Bertin  wrote:

> Hi,
> 
> While working on the update to Qt 5.6.0 I realised I should try to rekindle 
> the probably controversial issue of providing a dedicated Qt5 port that will 
> be optional for but preferred by the KF5 ports currently under testing.
> 
> I've tried to be as succinct as possible... I hope this is all clear enough 
> and not too long; it'd be nice to get some feedback this time.
> 
> The main specific adaptation of qt5-kde is a patch to QStandardPaths that 
> allows that class to return XDG-compliant locations for various settings 
> files and shared resources like icons, DBus scripts, etc. That's more or less 
> an unavoidable modification if we want KF5 applications to build, install and 
> behave (in MacPorts) like their KDE4 counterparts did - and interact with 
> those (and other, e.g. GTk/Gnome apps from the Freedesktop universe). Another 
> important difference is that the install layout follows the layout used by 
> the original, exclusive port:qt4-mac, because it is much closer to an 
> XDG-compliant  layout.
> 
> Having 2 different ports each providing the same middleware is of course not 
> an ideal solution. If things had gone as I'd liked there would now be a 
> single port with a +KDE variant. Alas, that apparently wasn't to be.
> 
> Instead, I've set up my qt5-kde port to be as compatible as possible with the 
> main/official port:qt5. In a nutshell: port:qt5-kde installs everything the 
> qt5 *meta*port does, except the QtWebEngine component which for now is 
> provided as a subport because it is so costly to build (about as much as the 
> rest). Qt5-kde also installs symlinks that provide access to various elements 
> along the same paths as port:qt5 does (e.g. /opt/local/libexec/qt5/include -> 
> /opt/local/include/qt5). With this I have been able to install the binary Qt5 
> Creator package and run the application without issues.
> I have implemented a PortGroup wrapper that takes care of handling most 
> differences between the 2 ports by including the appropriate "payload" 
> PortGroup. As a result, users can install either Qt5 port as a mostly 
> transparent alternative for the other without being obliged to have both 
> installed and activate either the one or the other. A preference setting is 
> provided whereby ports can indicate which Qt5 flavour they prefer, which is 
> what gets installed if no Qt5 port is available yet.
> 
> With these adaptions I think there is little hard reason not to admit qt5-kde 
> : users who don't care about KF5 ports or have reason to run port:qt5 with 
> its fewer patches and all-encompassing install prefix are served as they are 
> now, while users who do want to use KF5 applications in optimal form (or use 
> port:qt5-kde for some of its other specifics, like e.g. providing Qt 5.3.2 on 
> OS X 10.6) also get a choice. They'll still be able to use regular ports 
> depending on Qt5 - at the moment those will be built from source when 
> port:qt5-kde is installed instead of port:qt5 .
> 
> I'm launching this thread to discuss ways to streamline this. For there is a 
> caveat. Originally, the Qt4 and Qt5 ports installed all Qt components, so 
> dependent ports could simply include the respective PortGroup which would 
> then add an appropriate (path:-style) dependency. My own QtWebEngine subport, 
> and now mcalhoun's complete separation into a 1-subport-per-component design 
> make this less trivial (port:qt5-kde does provide the equivalent subports as 
> stubs, btw).

Re: No Xcode 8 CLT for El Capitan

[Marko Käning]

Hi,

there is no CLT for Xcode 8?

How come Xcode 8.0 tells me in "Preferences/Locations" that it uses CLT "Xcode 
8.0 (8A218a)”!

I recently ran into this issue 
---
:info:configure
:info:configureXcode not set up properly. You may need to confirm the 
license
:info:configureagreement by running /usr/bin/xcodebuild without arguments.
:info:configure
---
with Xcode 8 on El-Capitan myself when trying to install port:qt5(-kde).



Qt’s configure script errors out because of a non-found xcrun:
---
$ which xcrun
/usr/bin/xcrun
$ /usr/bin/xcrun -find xcrun
xcrun: error: unable to find utility "xcrun", not a developer tool or in PATH
---

René thus suggested the attached patch for qt5(-kde) as a workaround.

Greets,
Marko





patch-no-xcrun-f-xcrun.diff
Description: Binary data


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

Re: GitHub tester wanted?

[Marko Käning]

Hi Lawrence,

On 20 Aug 2016, at 19:48 , Lawrence Velázquez  wrote:
> How can you play the n00b if you're so fluent? :P

I can tell you: I CAN! :-)

Have proven this umpteen times.

Many of my coworkers tell me that I am the ideal tester! No joking.

8-D

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

GitHub tester wanted?

[Marko Käning]

Hi Clemens,

if you need an independent tester for your MacPorts workflows on GitHub
I am herewith offering my support.

I’d happily clone the official MacPorts git repo (also before it is live)
and try to create pull-requests and play the newbee there, because I think
that’s the best way to ensure foolproofness for the new system.

I am quite fluent in git, tig and GitHub due to my involvement with KDE [1]
and MSYS2. Yet, I’d still have preferred Mercurial as the new DVCS tool… ;-)

Greets,
Marko



[1] KDE uses Phabriactor now, which seems also nice, but I haven’t used it
much in the last while.


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

Re: Goodbye Mac OS Forge, hello GitHub

[Marko Käning]

Dear Ryan,

On 20 Aug 2016, at 02:18 , Ryan Schmidt  wrote:
> I'm pleased to announce that MacPorts will be moving its source code to
> GitHub.

in general I applaud this move! Congratulations to all those involved to make
this change happen!!!


> great collaboration features such as pull requests which some of our
> contributors have been wishing for.

+1 !!!


> Hopefully, in addition to the other benefits, moving to GitHub will help
> us attract and keep new developer talent.

Yes, indeed!


> In a January survey on this list, most developers indicated a preference for
> git, or that they were happy with the Subversion client. GitHub accommodates
> both. More on that in a separate mail to follow.

Well, I voted for Mercurial, but it is unfortunately not as popular as git.


> We also considered converting to Jira or BugZilla, but in the end,
> we decided that staying with Trac is the best and least disruptive choice
> for now. We will migrate the data from our Trac installation to a new
> server, taking the opportunity to upgrade to the latest version of Trac and
> make some other improvements.

Sounds like the way to go! 


> And our new buildbot automated build system announced earlier this month is
> being hosted by me on my hardware, outside of Apple, and will just need
> minor changes to monitor GitHub instead of Subversion.

On your own hardware?!? I guess this means that apart from the MLs Apple
doesn’t want any association with MacPorts anymore!? That I find sad, but
I do appreciate the support for this community driven activity through all
these years.

Well, let’s hope that MacPorts will attract more users and maintainers due
to its move to GitHub!

Thanks once again to all of ye,
Marko

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

Re: New build system

[Marko Käning]

Thanks Ryan,

On 10 Aug 2016, at 08:02 , Ryan Schmidt  wrote:
> There are many options for excluding columns; see:
> 
> https://build.macports.org/waterfall/help


that slipped my attention. Exactly what I needed. :)

Greets,
Marko


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

Re: New build system

[Marko Käning]

Dear MacPorts team,

this is amazing news! Thanks for the great work!!

The grid view looks more informative than before.

The waterfall view is - horizontally - pretty full these days... It would be 
neat if at least a logged on user could customise the view a little, like e.g. 
being able to only display the ports columns while hiding all columns for base!
Or perhaps just introduce a ports waterfall page which allows those who don’t 
need to see base to have an easier way of just tracking the ports?!

Thanks again for all your efforts to improve MacPorts!
You are gold!!!

Greets,
Marko

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

Re: New Mac OS Forge administrator

[Marko Käning]

Hi Ryan,

On 20 Nov 2015, at 03:49 , Ryan Schmidt  wrote:
> I'm pleased finally to be able to tell you that I have been hired to be your 
> new Mac OS Forge administrator. 

this is just great news! I was already wondering why suddenly trac starts to 
show commits
again. Now I know why: You’re continuing the great work for MacPorts in an 
official position.
COOL!

Congratulations to you!!!

Thank god, I was afraid that MacPorts’ infrastructure will stay close to 
unusable for a long time
to come. Now we can stop worrying.

\o/

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

Nonexistent mpi.default variable lets port upgrade fail

[Marko Käning]

Ooops, what does this error suddenly happen?

---
--->  Updating MacPorts base sources using rsync
MacPorts base version 2.3.4 installed,
MacPorts base version 2.3.4 downloaded.
--->  Updating the ports tree
--->  MacPorts base is already the latest version

The ports tree has been updated. To upgrade your installed ports, you should run
  port upgrade outdated
The following installed ports are outdated:
kdetoys4   4.10.5_0 < 4.10.5_1   
Error: Unable to open port: can't read "mpi.default": no such variable
To report a bug, follow the instructions in the guide:
http://guide.macports.org/#project.tickets
---

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

Buildbots stuck?

[Marko Käning]

Just noticed that the waterfall doesn’t show recently committed changes to 
ports…
… are the buildbots stuck?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: All KDE ports need a major revbump, due to recent changes to qt4-mac

[Marko Käning]

Answering my own question now, at least partially, since a rev-upgrade just 
gave me this much longer list:
---
--->  Found 38 broken port(s), determining rebuild order
--->  Rebuilding in order
 qtscriptgenerator @0.2.0
 kdenlive @0.9.10
 kdiff3 @0.9.98
 litecoin @0.8.7.4
 cervisia @4.14.3
 kapptemplate @4.14.3
 kcachegrind4 @4.14.3
 kde-dev-utils @4.14.3
 kde4-filelight @4.14.3
 kdesdk-kioslaves @4.14.3
 kdesdk-strigi-analyzers @4.14.3
 kdesdk-thumbnailers @4.14.3
 libkdegames @4.14.3
 kgoldrunner @4.14.3 +docs
 killbots @4.14.3 +docs
 kjumpingcube @4.14.3 +docs
 kmines @4.14.3
 libkomparediff2 @4.14.3
 kompare @4.14.3
 konquest @4.14.3 +docs
 kpat @4.14.3 +docs
 kubrick @4.14.3 +docs
 libkdcraw @4.14.3
 libkipi @4.14.3
 libksane @4.14.3
 lokalize @4.14.3
 okteta @4.14.3
 palapeli @4.14.3 +docs
 poxml @4.14.3
 smokegen @4.14.3
 smokeqt @4.14.3
 umbrello @4.14.3
 libgpod @0.8.3 +python27
 libkdeedu @4.14.3
 kde4-workspace @4.14.4.20150324 +oxygen
 gwenhywfar4-devel @4.14.0
 gpsd @3.14
 marble @4.14.3
---
which is my host and not the Mavericks-VM I was testing on earlier.


Unfortunately qtscriptgenerator fails to build now, being the first in this 
list…

No time for more digging now.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: All KDE ports need a major revbump, due to recent changes to qt4-mac

[Marko Käning]

On 27 Oct 2015, at 22:48 , Marko Käning <mk-macpo...@posteo.net> wrote:

> Answering my own question now, at least partially, since a rev-upgrade just 
> gave me this much longer list:

Should we forget about revbumping everything and simply rely on that the sanity 
of our users’ MacPorts installations
will be taken care of by rev-upgrade?

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

All KDE ports need a major revbump, due to recent changes to qt4-mac

[Marko Käning]

Hi Nicolas,

while building kdevelop and kdepim4 I came across some rev-upgrades… Thus I 
have rebumped ports kate, libkgapi and konversation.

For instance, the latter tried to find libqca in it’s old location
---
Dyld Error Message:
  Library not loaded: /opt/local/lib/libqca.2.dylib
  Referenced from: 
/Applications/MacPorts/*/konversation.app/Contents/MacOS/konversation
  Reason: image not found
---
which has - in the meantime - moved into $PREFIX/libexec/qt4/lib/:
---
$ port contents qca
Port qca contains:
.
.
.
  /opt/local/libexec/qt4/lib/libqca.2.dylib
  /opt/local/libexec/qt4/lib/libqca.dylib
.
.
.
---
I think that qt4-mac’s change to a concurrent install makes a major revbump for 
Qt and thus also KDE ports necessary.
Perhaps revbumping isn’t really needed for all, but for quite a few at least.
Have no idea how to test which ones are affected, though.

Greets,
Marko

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

Re: Buildbots stuck?

[Marko Käning]

Thanks, Ryan,

On 28 Oct 2015, at 00:28 , Ryan Schmidt  wrote:
> https://trac.macports.org/ticket/49305

for reminding me of that ticket.

Have subscribed to that and the one referenced in there as well.


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

Re: trac.macports.org is down again

[Marko Käning]

I guess it might be worthwhile to collect all these issues on a dedicated wiki 
page:

On 12 Oct 2015, at 16:46 , Daniel J. Luke  wrote:
>> Subversion log importer not running: https://trac.macports.org/ticket/48758
>> 
>> Snow Leopard builder registry corrupted: 
>> https://trac.macports.org/ticket/47976
>> 
>> Lion builder registry corrupted: https://trac.macports.org/ticket/48486
>> 
>> Mavericks builder stuck: https://trac.macports.org/ticket/48802
> 
> Set up El Capitan Builder https://trac.macports.org/ticket/48609
> 
> ftp files not getting mirrored https://trac.macports.org/ticket/45262 

... although such page might be pretty useless if the trac-wiki is dead again 
...

But anyway, I am afraid such a central point where all these issues for the 
Apple
admin would be collected would be a good idea, no?

Greets,
Marko

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

Re: trac.macports.org is down again

[Marko Käning]

Hi Ryan,

On 12 Oct 2015, at 23:10 , Ryan Schmidt  wrote:
> No need for a separate wiki page. The server/hosting component in the issue 
> tracker already serves that purpose.
> 
> https://trac.macports.org/query?status=!closed=server/hosting

ah, yes, that’s sufficient, right. Sorry for that silly proposal!


I just wonder when an Apple admin will really support MacPorts again.

I am already waiting since ages for a change of my email forwarding…

Greets,
Marko

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

Re: qtN-kde port(s)

[Marko Käning]

Dear qt*-maintainers/interested,

On 06 Jul 2015, at 10:00 , René J.V. Bertin rjvber...@gmail.com wrote:
 I think that can only be done by modifying the Qt PortGroup files so that 
 they detect the install layout and adapt the variable definitions they serve 
 accordingly. The cleanest approach I can think of (taking Qt5 as an example) 
 would rename qt5-1.0.tcl to qt5-mac-1.0.tcl and then rewrite qt5-1.0.tcl as 
 follows:
 
 {{{
 # preamble
 
 if {[file exists ${prefix}/some/fingerprint/for/qt5-kde]} {
   PortGroup qt5-kde 1.0
 } else {
   PortGroup qt5-mac 1.0
 }
 }}}

I have no idea what this fingerprint would actually be.

Neither I know whether this would be a viable way to introduce two new port 
groups and put qt5 into pension.

Would be good to get some feedback on how to handle this.

---

Right now I am struggling with phonon [1], since it doesn’t want to install 
itself with current qt5-mac on my system,
but perhaps I better open a separate thread for that topic…

Greets,
Marko



[1] https://trac.macports.org/ticket/46552

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

Re: qtN-kde port(s)

[Marko Käning]

Hi René,

On 07 Jul 2015, at 23:22 , René J.V. Bertin rjvber...@gmail.com wrote:
 A specific file, either one installed anyway by Qt but in a location specific 
 to qt5-kde,
 or something like a README or stub file that's specific to the port.

ah, ok, so it would be up to you to create this specific file for the qt5-kde 
port…


 PortGroup files can and do use PortGroup commands to include other port 
 groups (ex: the qmake PortGroups). 

I know.


 then a port that wants qt5-kde as its default dependency could do
 
 {{{
 set qt5.prefer_kde yes
 PortGroup qt5 1.0
 }}}

Hmmm, interesting…


 Anyway, yes, this could benefit from some discussion, because evidently one 
 would have to
 duplicate at least the path: style dependency declarations in both the 2 
 actual payload
 PortGroups, or else move it into the generic/omnipotent PortGroup …


Yes, this needs careful discussing, as quite a few projects will be hit by this 
in the future.

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

phonon for Qt5 in ticket #46552

[Marko Käning]

Hi again,

On 07 Jul 2015, at 23:22 , René J.V. Bertin rjvber...@gmail.com wrote:
 Right now I am struggling with phonon [1], since it doesn’t want to install 
 itself with
 current qt5-mac on my system, but perhaps I better open a separate thread 
 for that topic…
 
 That's simply because the mainstream Qt5 PortGroup lost a variable my version 
 defines and that
 indicates where the cmake modules are to be installed.
 It's possible that there's no need to specify that location when all of Qt is 
 dumped under a
 single prefix (try it!). It's also possible that it isn't required when the 
 cmake module dir is
 installed as it is under Linux; I (used to?) have a comment in my PortGroup 
 pointing out that
 I'd kept the install location for those files unchanged only to limit the 
 number of changes.

I commented your post-patch phase out and now I was able to install phonon-qt5 
as well as
kf5-knotifications (and more) which depend on phonon… :-)

Thanks for the pointer!!!

Greets,
Marko

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

Re: How to deal with ports-filesystem violation?

[Marko Käning]

On 29 Jun 2015, at 00:26 , Clemens Lang c...@macports.org wrote:

 In your case, since you seem to have a reason to ignore this warning, add this
 line to your Portfile to silence the warning.

I did so, but I still get this warning:
---
Warning: kf5-kdoctools installs files outside the common directory structure.
---
which is intended, I suppose.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to deal with ports-filesystem violation?

[Marko Käning]

Hi Lawrence,

On 29 Jun 2015, at 00:54 , Lawrence Velázquez lar...@macports.org wrote:
 Is this our Qt5?

Yes, it is. :)


 If so, I think it would be best if we modify it so that it looks inside
 ${prefix}/Library also. It won't be good if all KF5 ports need to install junk
 into /Library.


Ha, I did that a year ago already, but I am not keen to patch Qt5 itself 
anymore,
since this had been discussed at length with the Qt devs. They eventually argued
that Qt5 and all apps based on it should make use of OSX’ standard directories 
and
thus let QStandardPaths (QSP) succeed and not tweak anything in Qt’s code base.

If you have the time, you may read those two long debates [1,2] and let us know
what you think.

However, René was courageous enough to patch qt5 anyways [3] and I guess it is 
up
to the MacPorts team to somehow decide, which way we should go wrt to Qt5’s QSP.
A QSP-patched Qt5 would certainly have the MacPorts-ish advantage of

   “freedom of choice” wrt letting all files live under the MacPorts-prefix
   in locations where they are also to be found on Linux

as René formulated it a couple of times.

Any suggestions?

Greets,
Marko


[1] https://codereview.qt-project.org/#/c/103277/
[2] https://bugreports.qt.io/browse/QTBUG-44473
[3] https://trac.macports.org/ticket/46536

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

How to deal with ports-filesystem violation?

[Marko Käning]

Hi maintainers,

I am having a little trouble with some new ports which I am trying to introduce 
anew.

They need to install stuff into OSX’ system locations, specifically into

 - /Library/Application Support 
 - /Library/Preferences

But, of course, this is what I get when trying that:
---
$  sudo port destroot
Password:
Portfile changed since last build; discarding previous state.
---  Computing dependencies for kf5-kdoctools
---  Fetching distfiles for kf5-kdoctools
---  Verifying checksums for kf5-kdoctools
---  Extracting kf5-kdoctools
---  Configuring kf5-kdoctools
---  Building kf5-kdoctools
---  Staging kf5-kdoctools into destroot
Warning: violation by /Library/Application Support
Warning: kf5-kdoctools violates the layout of the ports-filesystems!
Warning: Please fix or indicate this misbehavior (if it is intended), it will 
be an error in future releases!
---

As to be expected, MacPorts allows me to install it in there, but isn’t happy 
about
it and warns that it will be considered to be an erroneous install in the 
future…

   So, I wonder what would be the best way to handle this case now.

I thought about installing everything into ${prefix}/Library/... instead and 
then
fs-traverse through the folders in question and copy (or even better only 
symlink)
all those files one by one into the system location in a post-destroot step. 
This
would allow to fine-granularily check that there’s nothing in the system which 
might
get overwritten.

Anyway, I don’t expect any collisions between the files installed and those 
usually
present on an OSX system, which is why the direct install into /Library/... 
seems
fine for the time being, but I want to do it the right way.

Suggestions?

Greets,
Marko

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

Re: How to deal with ports-filesystem violation?

[Marko Käning]

Hi Clemens,

On 29 Jun 2015, at 00:26 , Clemens Lang c...@macports.org wrote:
 - /Library/Application Support
 - /Library/Preferences
 
 Why do they need to do that?

they do it, because Qt5’s QStandardPaths logic searches in system locations
for its files, which is why it wouldn’t be able to find anything in 
/opt/local/Library/...


 We should turn this from a warning to an error for ports that don't set
  destroot.violate_mtree yes.

Seems so.


 In your case, since you seem to have a reason to ignore this warning, add this
 line to your Portfile to silence the warning.

Ah, okay, good to know. I will test that. Thanks for the pointer.

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

Re: Shouldn't qt5 also include cmake?

[Marko Käning]

Hi René,

On 27 Jun 2015, at 09:36 , René J.V. Bertin rjvber...@gmail.com wrote:
 The {c,q}make portgroups redefine the default build system, so including
 either of them with the qt5 portgroup isn't appropriate

ok, good to know! That’s why I am asking here. :)

Thanks,
Marko

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

Re: [137900] trunk/dports/kde

[Marko Käning]

Ryan, turns out that it was a completely unintended commit to qtcurve.
No idea how that could happen…

Reverted in r137900.

Thanks for poking me!

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

How to avoid file system violation during destrooting

[Marko Käning]

Hi,

I am having trouble with file system violation in 
https://trac.macports.org/ticket/48184 …

Seems to be caused by creating file

modules/qt_Attica.pri

in

${prefix}/mkspecs


Any ideas what can be done to avoid it?

Greets,
Marko

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

Re: How to avoid file system violation during destrooting

[Marko Käning]

On 27 Jun 2015, at 03:52 , Lawrence Velázquez lar...@macports.org wrote:

 Patch the build system?

To do what (not) exactly?

Does MacPorts not allow ports to install directly into ${prefix}/mkspecs, or 
what
is the problem here??
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to avoid file system violation during destrooting

[Marko Käning]

Or does the build system install right away into the MP file system instead of 
into destroot?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to avoid file system violation during destrooting

[Marko Käning]

On 27 Jun 2015, at 04:05 , Brandon Allbery allber...@gmail.com wrote:

 That is what it's complaining about, yes.

Oh, ok.

That means I need to find the CMake file which is responsible for this…

Thanks for the pointer guys! :)___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Shouldn't qt5 also include cmake?

[Marko Käning]

Hi Marcus,

I wondered whether port group “qt5” should also include port group “cmake”
since it is internally making use of it anyways?!

Greets,
Marko

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

Re: [MacPorts] #47947: qt5-creator-mac @3.2.2 fails to build

[Marko Käning]

Hi Andrea,

On 19 Jun 2015, at 10:53 , Andrea D'Amore and.dam...@macports.org wrote:
 Just to put things in context you're referring to [1] but that ticket
 is about failing build and doesn't mention parallel building at all.
 Also you are not the reporter there, like you seem to imply.

I didn’t mean to imply that.


 Are you using a custom Portfile?

Yes, I did.


 So multiple correct builds don't ensure parallel building will always
 work, while one single broken build confirms it won't. It works until
 it works and then you disable it (or fix the makefiles).

OK, I see, I wasn’t aware of that.


 That said I have no idea why mcalhoun disabled parallel building in
 first place, you can file a new ticket asking to enable it but ticket
 #47947 doesn't seem the appropriate place to discuss that.

Yep, sorry for having pirated this ticket!

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

Re: [137900] trunk/dports/kde

[Marko Käning]

Hi Ryan,

On 27 Jun 2015, at 02:22 , Ryan Schmidt ryandes...@macports.org wrote:
 Any particular reason for the nonstandard 'exec sh -c cd ... ; ...', 
 instead of the usual 'system -W ... ...”’?

No. Will fix that.


 Note that the compilers macports-clang-2.9, macports-clang-3.0, 
 macports-clang-3.1 and macports-gcc-4.2 don't exist…

Oh, I guess the “macports-*” prefix should be removed, right?

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

Re: How to avoid file system violation during destrooting

[Marko Käning]

On 27 Jun 2015, at 04:21 , Joshua Root j...@macports.org wrote:
 I don't think that's right, the port would not successfully finish
 destroot if that was installing straight to ${prefix} and being stopped
 by sandboxing. The message in the ticket is complaining about an mtree
 violation. /opt/local/mkspecs is not part of the standard filesystem
 layout, see porthier(7).

OK…


 If you really have to, you can set destroot.violate_mtree, but it would
 be much preferable to install to somewhere like ${prefix}/share/mkspecs
 instead.

Thanks very much, Josh, since this
---
configure.args-append -DECM_MKSPECS_INSTALL_DIR=${prefix}/share
---
did that trick!

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

opencv version 3 vs. 2

[Marko Käning]

Hi stromnov,

recently opencv was updated from version 2 to 3, which left at least 2 dependent
ports in limbo [1,2] and there might be even more out there...

I think this may ask for a new port opencv2, until its dependent ports can also
handle version 3.
Do you agree?

If so, I'd suggest to take opencv's latest commit before v3 and create a 
sub-port
opencv2 within opencv's portfile.

Greets,
Marko




[1] VLC-devel: https://trac.macports.org/ticket/48067
[2] digikam: https://trac.macports.org/ticket/48081
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: opencv version 3 vs. 2

[Marko Käning]

Hi Ryan,

 If fixing those two ports is more complicated than just updating them to a
 newer version, or copying an existing patch from upstream, then yes, it
 would be fine to create an opencv2 port.

ok, I'll wait a bit until I have feedback from the digikam developer, but
I have no idea about VLC-devel and the other hidden cases of conflicts.


 However, while it should be based on the last commit of the opencv port
 before it was updated to version 3, it would need to be modified to
 install its files to different locations, so that it does not conflict
 with the opencv port.

That would be the ideal case. I would have made the two opencv versions
simply conflicting for now.

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

Re: [137817] trunk/dports/textproc

[Marko Käning]

 Isn't cppunit a unit-testing framework, which would only used at build or 
 test time?

Oh, yes, that slipped my attention.

Shall I commit with a revbump?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Create a new category named 'kf5' for KDE's KF5?

[Marko Käning]

Hi devs,

as the KDE Frameworks 5 (KF5) are still under heavy development, we can 
expect that
KF5-based software will have to coexist with KDE4 for quite some time to come.

I wonder now, whether these KF5 frameworks could get their own category 'kf5', 
or whether
they should also go into category 'kde'.

I'd like to put all KF5 stuff into trunk/dports/kf5/ instead of 
trunk/dports/kde/.
In any case, thoguh, I would have to prefix all ports with 'kf5-' since many 
frameworks
keep the names of the KDE4-counterparts.

Any objections? Or are there rules for creation of categories which I am not 
aware of?

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

Re: [MacPorts] #47947: qt5-creator-mac @3.2.2 fails to build

[Marko Käning]

Hi, I am saying the opposite!

It always built fine for me in parallel, which is why I raised this issue.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Contributing to MacPorts (specifically to introduce am improved concurrent qt5-mac)

[Marko Käning]

Hi René,

On 14 Jun 2015, at 23:02 , René J.V. Bertin rjvber...@gmail.com wrote:

 Anyway, I suppose you saw I updated ticket in which we discussed my PortGroup
 definition. I hope you'll be able to take a look soon (= before the Portfile
 diff no longer applies).

sorry, I can’t react fast ATM on this one due to some overload on my end. :(


I hope there are other MacPorts devs out there, who can review your patch for
qt5’s port group (as well as the qt5-mac port itself) attached to charm’s ticket

https://trac.macports.org/ticket/48024#comment:18

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

gpsbabel suddenly based on qt5-mac thus leaving qt4-mac-based port qlandkartegt in limbo

[Marko Käning]

I just realised that updated gpsbabel [1] leaves qlandkartegt in limbo because 
of
switching to qt5-mac:
---
$ port deps gpsbabel
Full Name: gpsbabel @1.5.2_0
Build Dependencies:   pkgconfig
Library Dependencies: qt5-mac, expat, libusb-compat, zlib
$ port rdependents gpsbabel
The following ports are dependent on gpsbabel:
  qlandkartegt
---

How to transition from Qt4 to Qt5 more smoothly?? This is going to happen for 
many
ports in the future, so, perhaps this is a port where one could try to exercise 
how
to do it least disturbingly for users having installed qt4-mac ports?!

I - for my part - am still having a fully qt4-mac-based MacPorts system for 
production,
which is why I don’t want such automagic transitions to Qt5, unless all 
dependent ports
have also migrated to Qt5.

Any ideas?

Greets,
Marko




[1] https://trac.macports.org/ticket/47721
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: qt5-mac w/o parallel build

[Marko Käning]

Hi Marcus,

On 08 Jun 2015, at 02:25 , Marcus Calhoun-Lopez marcuscalhounlo...@gmail.com 
wrote:
 It should be fixed in r137268.

thanks for fixing that.

...

BTW, have you intentionally set - by any chance - the X-No-Archive option in 
your mail client?

If not I can’t understand, why your reply doesn’t turn up on macports-dev’s ML 
archive [1].

Greets,
Marko




[1] https://lists.macosforge.org/pipermail/macports-dev/2015-June/date.html

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

qt5-mac w/o parallel build

[Marko Käning]

Commit r137229 [1] actually mentions in line 78:
---
78# TODO: Uncomment out for testing only. Be sure to comment out next line 
before commit. 
79use_parallel_build no 
---
but still doesn’t allow for parallel build...

So, seemingly, the commenting out of line 79 was not made sure at commit time.

Or is there another reason for that?




[1] http://trac.macports.org/changeset/137229
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: gnutar broken

[Marko Käning]

Hi René,

On 20 May 2015, at 10:01 , René JV Bertin rjvber...@gmail.com wrote:
 I simply installed bsdtar and got rid of the gnutar

if I want to go this route myself, where do I find bsdtar on MacPorts?

Greets,
Marko

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

Re: gnutar broken

[Marko Käning]

Hi René,

On 21 May 2015, at 09:36 , René J.V. Bertin rjvber...@gmail.com wrote:
 I was about to say port:bsdtar but indeed, no, it's under the more evocative 
 name of port:libarchive.
 Maybe an idea to rewrite the description to mention that this port doesn't 
 only install libraries …

Jesus, that port was installed all along, but who’d expect to find bsdtar in 
there?

;-)

Thanks for the pointer!

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

gnutar broken

[Marko Käning]

Hi devs,

gnutar is broken since a quarter of a year by now [1]...

Anyone out there who has a clue what might be going on there?

Greets,
Marko




[1] https://trac.macports.org/ticket/47001
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: gnutar broken

[Marko Käning]

Hi folks,

On 20 May 2015, at 10:19 , Andrea D'Amore and.dam...@macports.org wrote:
 It works for me as well using 2.3.99 on OS X 10.10.3.

only now I realise that I misinterpreted something. I thought gnutar wasn’t
building at all at the moment, instead it is only that one open issue...

All (virtual) machines I am using have could install it without any problem.

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

Re: Bad files on buildports-lion-x86_64

[Marko Käning]

David,

I had this in the past with RKWard already twice!!

Check what we’ve done in rkward's pre-activate phase, where we did
delete the left-over files previously, but have disabled the “delete”
commands ATM as we want to understand when those files got created.

Mac OS Forge folks never reacted to any of my queries regarding checking
on files, so stop waiting and do make use of the pre-activate phase as well!!

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

IP traffic monitoring tools on MacPorts with different results

[Marko Käning]

Hi folks,

I have tested a few of MacPorts’ IP traffic monitoring tools for the console and
found that bmon is my favourite - while bwm-ng and ifstat worked fine too.

But I noticed that these two tools

- nload
- iftop

gave unreasonably high transfer rates!!!

Could it be, that these tools aren’t really tested on OSX?

Greets,
Marko

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

Re: MacPorts' trac in Europe slower than usual

[Marko Käning]

Performance has improved again.

Did someone change something somewhere?

Thanks in any case.
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

MacPorts' trac in Europe slower than usual

[Marko Käning]

MacPorts’ trac is quite slow here in Europe since yesterday!
(But it was even slower 12h ago.)

Any ideas what was/is wrong?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: MacPorts' trac in Europe slower than usual

[Marko Käning]

On 22 Apr 2015, at 15:57 , Henry Groen gr...@apple.com wrote:

 I have kicked the server, let me know if you see an improvement.

no, still very slow.

Perhaps it only happens for me...

Marko

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

Re: Port variant libcaca -x11 still pulls in xorg deps...

[Marko Käning]

Hi Jeremy,

thanks for your helpful response.


On 22 Apr 2015, at 00:20 , Jeremy Huddleston Sequoia jerem...@macports.org 
wrote:
 imlib2's configure script looks like it has a way to disable X11 support, but 
 the resulting dylib is still linked against X11 libs.  Here's a patch to get 
 you started:
 
 imlib2.x11_variant.patch

Based on that I have filed a ticket for further review [1]. It builds fine here.


 freeglut (and libGLU) are GLX ports.  freeglut cannot build a GLUT.framework 
 based on OpenGL.framework.  If you need to use GLUT/CGL, don't use the 
 freeglut port.

Well, I am not sure what to do about this in libcaca, as all I did was moving 
things
from the port into the default x11 variant, so changing nothing effectively for 
x11.

As I am not an X11 Xpert, I am unsure about whether a non-X11 port would/could 
build
with or w/o GLUT/CGL.

Wondering whether there is any connection between the above and 
gstreamer1-gst-plugins-good
failing on me [2]...

Greets,
Marko



[1] https://trac.macports.org/ticket/47532
[2] https://trac.macports.org/ticket/47525


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: Ports not listed as outdated

[Marko Käning]

Hi Mojca,

On 22 Apr 2015, at 09:00 , Mojca Miklavec mo...@macports.org wrote:

 MacPorts is behaving a bit weird. It doesn't report some outdated
 ports and as a consequence doesn't upgrade them. I need some clues
 about where I could look to diagnose the source of the problem.


thanks so much for raising this issue. I was puzzled myself yesterday
that I seemed to have some weird behaviour with outdated ports…

Same symptoms here! :(

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

Failing to come up with a working -x11 variant for port gstreamer1-gst-plugins-good

[Marko Käning]

Hi,

I want to be able to build gstreamer without X11. Thanks to [1] I am almost 
there,
but gstreamer1-gst-plugins-good is still failing now that I try to build ‘-x11’:
---
:info:build gstid3v2mux.cc:55:10: fatal error: 'textidentificationframe.h' file 
not found
:info:build #include textidentificationframe.h
---
:-(

What is going wrong here? Is this something for upstream?

Or, is this a side effect of my rigorous changes to libcaca [1]?

Greets,
Marko




[1] https://trac.macports.org/ticket/47526
[2] https://trac.macports.org/ticket/47525
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Port variant libcaca -x11 still pulls in xorg deps...

[Marko Käning]

Turns out that libcaca was easy, although I am not sure that 

https://trac.macports.org/ticket/47526

does this correctly. Well, the project builds fine at least...
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Port variant libcaca -x11 still pulls in xorg deps...

[Marko Käning]

Hi Josh,

On 21 Apr 2015, at 21:43 , Joshua Root j...@macports.org wrote:
 The ticket summary is a bit confusing given that the patch neither adds
 an x11 variant nor makes it default. But the patch looks reasonable,
 assuming that --disable-x11 causes the removed dependencies not to be used.

Sorry, yes, I’ll fix that.

I mixed things up there with my patch for gstreamer1-gst-plugins-good

https://trac.macports.org/ticket/47525

:-)

That one unfortunately does not build anymore with -x11. :(

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

Port variant libcaca -x11 still pulls in xorg deps...

[Marko Käning]

Hi Jeremy,

this pulls in xorg:
---
$ sudo port install libcaca -x11
---  Computing dependencies for libcaca
---  Dependencies to be installed: freeglut libGLU mesa xorg-dri2proto 
xorg-glproto xorg-libXdamage xorg-damageproto xorg-libXxf86vm 
xorg-xf86vidmodeproto imlib2 libid3tag
---

because of imlib2 and free glut - due to missing x11 variants:
---
$ port variants imlib2 freeglut
imlib2 has the variants:
   universal: Build for multiple architectures
freeglut has the variants:
   debug: Enable debug binaries
   universal: Build for multiple architectures
---

Any ideas how to fix this?

Greets,
Marko


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