2.3.0
So, no bugs have been reported against the beta. Unless anyone has a last-minute urgent regression, I guess I'll just go ahead and tag the final release tomorrow. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
copying dependencies of packages from buildbots to package server
Hi, Let's say that a package A is a dependency of B and that B is a dependency of C. Let's assume that I commit a patch/update for B which fails to build due to a broken port A. Then I commit a patch for A, A builds successfully and gets pushed to the package server. Then I commit a patch/update for C. B gets built during the process, but it doesn't end up on packages.macports.org. It would be nice if B was submitted to the server in such cases (but I don't know how difficult it would be to change that or if there are cases where this isn't desirable). One needs to force-build B again – the buildbot then doesn't build anything, it just reports that the package exists, but it pushes B to the package server. Is there any reasonable and harmless way to avoid that extra step? Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 2.3.0
On 2014-04-03 09:19, Joshua Root wrote: So, no bugs have been reported against the beta. Unless anyone has a last-minute urgent regression, I guess I'll just go ahead and tag the final release tomorrow. Does that mean we skip release candidates this time? For the 2.2.0 release we did -beta1, then -rc1, only then the final release. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 2.3.0
Hi, So, no bugs have been reported against the beta. Unless anyone has a last-minute urgent regression, I guess I'll just go ahead and tag the final release tomorrow. Does that mean we skip release candidates this time? For the 2.2.0 release we did -beta1, then -rc1, only then the final release. If nobody is reporting bugs against the beta (and we've had that out for a while now), I don't think anybody will for an RC. It seems unless we make it easier for people to test a beta, only a few users will actually do it. So I'd suggest skipping RC this time, working on selfupdate --beta and releasing a 2.3.1 soon after 2.3.0 if serious problems show up. However, I've noticed during my last use of port_cutleaves from contrib [1] that I see failures to open Portfiles from registry a lot more often than I used to. I tried investigating a little, but haven't been able to pinpoint a reason for that. It might just be my installation (because I had to manually intervene with the database upgrade), but I guess making sure and giving it another look wouldn't hurt. Can anybody reproduce this? It might not be a critical problem though, because it'd only break pre-/post-deactivate hooks, and we don't have a lot of those anyway. [1] http://trac.macports.org/browser/contrib/port_cutleaves/ -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 2.3.0
On 4/3/14, Clemens Lang c...@macports.org wrote: However, I've noticed during my last use of port_cutleaves from contrib [1] that I see failures to open Portfiles from registry a lot more often than I used to. I tried investigating a little, but haven't been able to pinpoint a reason for that. It might just be my installation (because I had to manually intervene with the database upgrade), but I guess making sure and giving it another look wouldn't hurt. Can anybody reproduce this? It might not be a critical problem though, because it'd only break pre-/post-deactivate hooks, and we don't have a lot of those anyway. I count 13 Portfiles with pre-deactivate hooks and 33 Portfiles with post-deactivate hooks. Of course that is not counting the PortGroups that use them: all 3 Haskell PortGroups use pre-deactivate hooks, and there are a few hundred Portfiles using the main Haskell PortGroup. Also, the Octave, TeXLive, and x11font PortGroups each use post-deactivate hooks, and there are a few hundred more Portfiles using at least one of those PortGroups, between the three of them... idk if a few hundred is enough to be considered a lot, considering that we have over 18000 ports overall currently, but I think it is still enough to consider giving it a look... [1] http://trac.macports.org/browser/contrib/port_cutleaves/ -- Clemens Lang ___ 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: Move part of macports infrastructure to GitHub
On Mar 21, 2014, at 4:17 PM, Landon Fuller land...@macports.org wrote: On Mar 20, 2014, at 8:39 PM, Ryan Schmidt ryandes...@macports.org wrote: On Mar 20, 2014, at 19:21, Eric Gallager wrote: That said, a git/hg mirror on GitHub/ButBucket would definitely be nice. Why would that be nicer than the read-only git mirror that Mac OS Forge already provides here: http://www.macosforge.org/post/git-mirrors/ Try to avoid thinking of it as nicer than, but instead think of it as a nice addition to. The nice thing about distributed systems like git is that it makes it easier to mirror a single mirror to multiple places. A git mirror on GitHub could even be the exact same mirror as the one on MacOSForge is. That is similar to how most of the mirrors on the GitHub-Mirrors account work: https://github.com/mirrors (I think I mentioned that earlier in this thread…) Why is a github mirror of the git repository desirable? Why can’t users who want a git version of our repository use the one Mac OS Forge provides? Is it just to help users discover the existence of the repository or what? In my experience, the alternative is that people republish your code on GitHub anyway, in which case you have a bunch of disconnected mirrors of your code under the same name as your project, none of which is obviously canonical. If your code is going to wind up republished to GitHub anyway, having a mirror at least allows you to control the branding, point back to the original project, and ensure that it's clear which repositories are user-uploaded mirrors (forks), and which is the canonical mirror. As a follow-up — it looks like Apache is doing some really neat stuff in terms of integrating with GitHub, while maintaining local canonical control of project hosting and resources: https://blogs.apache.org/infra/entry/improved_integration_between_apache_and https://svn.apache.org/repos/infra/infrastructure/trunk/projects/ -landonf ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On Thu, Apr 3, 2014 at 4:41 PM, Landon Fuller wrote: As a follow-up — it looks like Apache is doing some really neat stuff in terms of integrating with GitHub, while maintaining local canonical control of project hosting and resources: https://blogs.apache.org/infra/entry/improved_integration_between_apache_and https://svn.apache.org/repos/infra/infrastructure/trunk/projects/ I don't quite understand how github - jira integration and integration of Apache's own mailing lists would help MacPorts. Doesn't that only apply to projects hosted at Apache? I see some work being done for better integration between svn and git, but don't yet quite understand how it works. But anyway, this one was amazing: https://issues.apache.org/jira/browse/INFRA-7524 http://www.infoq.com/news/2014/04/svn-migrates-to-git Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: git.macports.org not syncing since 11 March
On Wed, 02 Apr 2014 12:08:00 -0700, Shreeraj Karulkar wrote: You are right there doesn’t seem to be anything wrong with the access from the internet, and I have checked that the internal access to git.macports.org is also okay. I even restarted the cron daemon but it still shows the latest update on git.macports of March 11. I’ll looking but running out of ideas. While you are at it, could you please look into switching the Git mirrors to sync from the https:// URL [1] from the Subversion repository? That would make it easier for developers to use git-svn as only the SSL connection allows authentication (not entirely sure on this, but HTTPS should be preferred anyway). Rainer [1] https://svn.macports.org/repository/macports/ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On Thu, 03 Apr 2014 20:51:23 +0200, Mojca Miklavec wrote: On Thu, Apr 3, 2014 at 4:41 PM, Landon Fuller wrote: As a follow-up — it looks like Apache is doing some really neat stuff in terms of integrating with GitHub, while maintaining local canonical control of project hosting and resources: https://blogs.apache.org/infra/entry/improved_integration_between_apache_and https://svn.apache.org/repos/infra/infrastructure/trunk/projects/ I don't quite understand how github - jira integration and integration of Apache's own mailing lists would help MacPorts. Doesn't that only apply to projects hosted at Apache? It is an example how another project provides a presence on GitHub, but still uses their own infrastructure for main development. They have set it up such that any new pull requests on GitHub triggers a mail report to the project mailing list. Replies to that mailing list thread will even be synced back to appear as comments on GitHub. The second link contains the repository with several scripts that seem to make that work. It's an interesting concept, but sounds like it requires a fair amount of administration work for this infrastructure. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [118513] trunk/dports/devel/dbus
Hi,
[118513] trunk/dports/devel/dbus
Revision 118513
Author mcalh...@macports.org
Date 2014-04-03 10:39:22 -0700 (Thu, 03 Apr 2014)
Log Message Update version 1.6.12-1.8.0
This change will now display the following message to every user, even
if he never consciously selected any of dbus' variants:
--- Configuring dbus
Warning: You have requested an obsolete variant
Warning: Installation of startup items are now determined by
/opt/local/etc/macports/macports.conf
Warning: See https://guide.macports.org/#reference.startupitems
--- Building dbus
Is that really what we want? I know we don't keep track of which
variants a user manually selected, but I'd still argue that we
should just do the right thing for the average user with a
standard install silently – especially since as long as the variant
is present it will be preserved during updates. Maybe you could
remove the variant declaration but continue to use
if {[variant_isset startupitem]}
to print warnings where necessary? As far as I know that should remove
the variant automatically on upgrade.
--
Clemens Lang
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [118513] trunk/dports/devel/dbus
I see your point.
I would be happy to remove it if such warnings are distracting and/or unhelpful.
Does
if {[variant_isset startupitem]}
ever return true if there is NO
variant startupitem {
?
-Marcus
On Apr 3, 2014, at 12:24 PM, Clemens Lang c...@macports.org wrote:
Hi,
[118513] trunk/dports/devel/dbus
Revision 118513
Author mcalh...@macports.org
Date 2014-04-03 10:39:22 -0700 (Thu, 03 Apr 2014)
Log Message Update version 1.6.12-1.8.0
This change will now display the following message to every user, even
if he never consciously selected any of dbus' variants:
--- Configuring dbus
Warning: You have requested an obsolete variant
Warning: Installation of startup items are now determined by
/opt/local/etc/macports/macports.conf
Warning: See https://guide.macports.org/#reference.startupitems
--- Building dbus
Is that really what we want? I know we don't keep track of which
variants a user manually selected, but I'd still argue that we
should just do the right thing for the average user with a
standard install silently – especially since as long as the variant
is present it will be preserved during updates. Maybe you could
remove the variant declaration but continue to use
if {[variant_isset startupitem]}
to print warnings where necessary? As far as I know that should remove
the variant automatically on upgrade.
--
Clemens Lang
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [118513] trunk/dports/devel/dbus
Hi,
I see your point.
I would be happy to remove it if such warnings are distracting and/or
unhelpful.
You don't have to take my word for it:
https://lists.macosforge.org/pipermail/macports-users/2014-April/035084.html
Does
if {[variant_isset startupitem]}
ever return true if there is NO
variant startupitem {
?
Yes, it does:
$ cat Portfile
PortSystem 1.0
namePortName
version PortVersion
maintainers MaintainerHandle
categories Categories
description Description
long_descriptionLongDescription
platforms Platforms
homepageHomepage
if {[variant_isset foobar]} {
ui_msg +foobar!
}
$ port variants +foobar
+foobar!
PortName has the variants:
universal: Build for multiple architectures
I actually think this is a mis-feature, but it's not trivially solvable
and I haven't thought of a good solution I'd implement yet.
--
Clemens Lang
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [118513] trunk/dports/devel/dbus
We sort of relied on that mis-feature during the great x11/quartz divide, where only some dependencies had the variant but it needed to trickle down all the way to ensure it hit them all. On Apr 3, 2014, at 18:22, Clemens Lang c...@macports.org wrote: I actually think this is a mis-feature, but it's not trivially solvable and I haven't thought of a good solution I'd implement yet. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [118513] trunk/dports/devel/dbus
On Apr 3, 2014, at 14:24, Clemens Lang c...@macports.org wrote:
Hi,
[118513] trunk/dports/devel/dbus
Revision 118513
Author mcalh...@macports.org
Date 2014-04-03 10:39:22 -0700 (Thu, 03 Apr 2014)
Log Message Update version 1.6.12-1.8.0
This change will now display the following message to every user, even
if he never consciously selected any of dbus' variants:
--- Configuring dbus
Warning: You have requested an obsolete variant
Warning: Installation of startup items are now determined by
/opt/local/etc/macports/macports.conf
Warning: See https://guide.macports.org/#reference.startupitems
--- Building dbus
Is that really what we want? I know we don't keep track of which
variants a user manually selected, but I'd still argue that we
should just do the right thing for the average user with a
standard install silently – especially since as long as the variant
is present it will be preserved during updates. Maybe you could
remove the variant declaration but continue to use
if {[variant_isset startupitem]}
to print warnings where necessary? As far as I know that should remove
the variant automatically on upgrade.
I would probably remove the variants, and the associated messages.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 2.3.0
On Apr 3, 2014, at 02:19, Joshua Root wrote: So, no bugs have been reported against the beta. Unless anyone has a last-minute urgent regression, I guess I'll just go ahead and tag the final release tomorrow. Two problems I have: 1. I changed the way the environment variables are output, to be sorted and one per line: https://trac.macports.org/ticket/40703 This is easier to read. However for reasons I don’t understand, I don’t always see them in log output; sometimes I just see: DEBUG: Environment: Has anybody else noticed this? Could someone take a look at this and see why that might be? 2. I changed the default configure.cppflags from -I/opt/local/include to -isystem/opt/local/include to fix a whole set of difficult-to-find build failures. You reverted the change. I stand by the change and would like you to reconsider the reversion, or better explain what problems the change caused you. I added a note to the ticket: https://trac.macports.org/ticket/40656 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [118513] trunk/dports/devel/dbus
Now that dbus builds different depending on the startupitem.install setting, will that correctly work with binary distribution? Should we prevent binaries from being installed when a user has startupitem.install off? -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [118513] trunk/dports/devel/dbus
On Apr 3, 2014, at 18:30, Clemens Lang c...@macports.org wrote: Now that dbus builds different depending on the startupitem.install setting, will that correctly work with binary distribution? I don’t see how it would... Should we prevent binaries from being installed when a user has startupitem.install off? That would be one fix, but would unnecessarily prevent the use of binaries for the vast majority of ports that don’t use that setting. (I count only 9 portfiles referencing it, out of over 9600 portfiles.) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [118513] trunk/dports/devel/dbus
On 2014-4-4 10:30 , Clemens Lang wrote: Now that dbus builds different depending on the startupitem.install setting, will that correctly work with binary distribution? Should we prevent binaries from being installed when a user has startupitem.install off? Maybe startupitem.install should just cause an extra link to be created/deleted during activate/deactivate, and not affect the archive contents at all. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 2.3.0
On 2014-4-4 10:35 , Ryan Schmidt wrote: On Apr 3, 2014, at 02:19, Joshua Root wrote: So, no bugs have been reported against the beta. Unless anyone has a last-minute urgent regression, I guess I'll just go ahead and tag the final release tomorrow. Two problems I have: 1. I changed the way the environment variables are output, to be sorted and one per line: https://trac.macports.org/ticket/40703 This is easier to read. However for reasons I don’t understand, I don’t always see them in log output; sometimes I just see: DEBUG: Environment: Has anybody else noticed this? Could someone take a look at this and see why that might be? Yes, anddam was having this problem yesterday with some ports, but I couldn't reproduce it. 2. I changed the default configure.cppflags from -I/opt/local/include to -isystem/opt/local/include to fix a whole set of difficult-to-find build failures. You reverted the change. I stand by the change and would like you to reconsider the reversion, or better explain what problems the change caused you. I added a note to the ticket: https://trac.macports.org/ticket/40656 Hm, I thought I added a comment. Maybe Trac was misbehaving at the time. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 2.3.0
On Apr 3, 2014, at 19:01, Joshua Root wrote:
On 2014-4-4 10:35 , Ryan Schmidt wrote:
On Apr 3, 2014, at 02:19, Joshua Root wrote:
So, no bugs have been reported against the beta. Unless anyone has a
last-minute urgent regression, I guess I'll just go ahead and tag the
final release tomorrow.
Two problems I have:
1. I changed the way the environment variables are output, to be sorted and
one per line:
https://trac.macports.org/ticket/40703
This is easier to read. However for reasons I don’t understand, I don’t
always see them in log output; sometimes I just see:
DEBUG: Environment:
Has anybody else noticed this? Could someone take a look at this and see why
that might be?
Yes, anddam was having this problem yesterday with some ports, but I
couldn't reproduce it.
All I changed was one line in environment_array_to_string, making it so that
the string it returns now contains newlines. The only place where
environment_array_to_string gets called, it’s just sent over to ui_debug as:
ui_debug Environment: [environment_array_to_string ${varprefix}.env_array]”
Can ui_debug not accept multiline strings? I am having trouble locating where
ui_debug is defined.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [118513] trunk/dports/devel/dbus
Hi, Maybe startupitem.install should just cause an extra link to be created/deleted during activate/deactivate, and not affect the archive contents at all. Yes, that's what I've been thinking a couple of weeks ago. Now somebody would just have to implement that :) -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 2.3.0
Hi Ryan, This is easier to read. However for reasons I don’t understand, I don’t always see them in log output; sometimes I just see: DEBUG: Environment: Has anybody else noticed this? Could someone take a look at this and see why that might be? Line buffering while writing to the output file might be a reason why it fails with line breaks, but I still don't understand why that would cause the lines to be missing completely – but then I also don't know how our logging works and that has some weird bugs aswell… Can ui_debug not accept multiline strings? I am having trouble locating where ui_debug is defined. ui_debug is defined in macports1.0/macports.tcl, line 254 in proc macports::ui_init and can be overriden by a proc ui_init in global namespace which should define these functions (see lines 81-98 in macports.tcl, which seems to be the only API documentation we have on that). It doesn't seem port.tcl actually does that (maybe it should?) so the fallback from macports.tcl is used. HTH, -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Problem updating git-core
On 3/31/14 11:23 PM, Ryan Schmidt wrote: On Mar 31, 2014, at 18:06, Thomas Lockhart wrote: Has anyone else noticed a problem fetching the git tarball from kernel.org? I can do so successfully through my browser but it stalls with a zero-length .TMP file when trying to update the port. The update was prompted by running selfupdate then upgrade outdated. I was hoping it was some misbehavior of kernel.org but this has been trouble for a couple of days now. Any suggestions for debugging this? That does sound like misbehavior of that server. Have you talked to them about it? MacPorts eventually gives up on servers that are delivering files too slowly, so if you just wait, it should eventually either finish downloading (if it’s just going slowly), or re-try from a different server. The installation of git-core is working now. I'm not sure what the underlying issue was, but at some point (after I first started this thread) I was having trouble getting DNS resolution of www.kernel.org and some other sites. A reboot seemed to fix the problems :( and MacPorts is now updating successfully :) Thanks for the help! - Tom ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [118532] trunk/dports/devel/glib2-devel/Portfile
On Apr 3, 2014, at 19:46, David Evans dev...@macports.org wrote: On 4/3/14 5:05 PM, ryandes...@macports.org wrote: Revision 118532 Author ryandes...@macports.org Date 2014-04-03 17:05:49 -0700 (Thu, 03 Apr 2014) Log Message glib2-devel: update to 2.40.0 (#43183) Doing the same for glib2 would be a good idea, too. As I mentioned in the ticket, I want to wait until I have had a chance to test on all OS X versions before doing that. I committed glib2-devel so that I could at least see if it succeeds on the buildslaves. They haven’t finished building it yet; they’ve been busy building the kde update. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: 2.3.0
On Apr 3, 2014, at 02:19, Joshua Root wrote: So, no bugs have been reported against the beta. Unless anyone has a last-minute urgent regression, I guess I'll just go ahead and tag the final release tomorrow. PortIndex2MySQL.tcl is failing for me with trunk; if it fails with 2.3.0beta1 also we would want to fix that before releasing it. https://trac.macports.org/ticket/43208 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
