Re: Ports updated without maintainer notification?

[Jason Liu]

In this particular situation, the libraries in question are ones that I
specifically added to MacPorts in order to allow my Blender port to build.
No other ports use those libraries, although obviously there's nothing to
prevent other software from starting to use them in the future.

-- 
Jason Liu


On Tue, May 11, 2021 at 7:08 PM Nils Breunese  wrote:

> Ryan Schmidt  wrote:
>
> > Holding back a library to be compatible with one port may not be the
> right choice for other ports that depends on the library.
>
> If other ports would want to use the latest version of foo-lib, but
> Blender needs specifically version 1.15 of foo-lib, it might be an idea to
> have both a foo-lib port with the latest version and a foo-lib-1.15 port
> that Blender can then depend on.
>
> Nils.

Re: Ports updated without maintainer notification?

[Nils Breunese]

Ryan Schmidt  wrote:

> Holding back a library to be compatible with one port may not be the right 
> choice for other ports that depends on the library.

If other ports would want to use the latest version of foo-lib, but Blender 
needs specifically version 1.15 of foo-lib, it might be an idea to have both a 
foo-lib port with the latest version and a foo-lib-1.15 port that Blender can 
then depend on.

Nils.

Re: Ports updated without maintainer notification?

[Ryan Schmidt]

On May 8, 2021, at 14:26, Jason Liu wrote:

> Running port -d sync results in the updated ports now showing up in the list 
> of outdated ports. I was under the impression that port selfupdate ran port 
> sync as a part of the self-update process? Or am I mistaken, and port sync 
> needs to be added to my nightly script?

selfupdate does a sync for you, unless you run selfupdate with the --no-sync 
flag. It is possible for sync (whether performed separately or as part of 
selfupdate) or the subsequent portindexing to fail; the debug output produced 
by running with the -d flag should let you see if that's happening.


> It's not the individual libraries that I'm worried about. It's the fact that 
> these libraries are dependencies for my Blender port. Blender typically uses 
> slightly outdated versions of all of its dependent libraries. Very complex 
> libraries are a particular risk. For example, trying to use the newest 
> version of usd is causing blender builds to fail on my machine. I remember a 
> time when ports with lots of dependencies, such as gimp, could be broken for 
> weeks at a time, because updates to one or more of its dependencies was 
> causing gimp builds to fail. Admittedly, this was an experience from a decade 
> ago, but it did leave a lasting impression.

Sounds like this may be a case where not listing openmaintainer for blender and 
its dependencies that you maintain would be a valid choice.

I know you added a lot of blender's dependencies specifically for blender to 
use, so holding them back in order to be compatible with blender may be 
workable here.

In general though, that's hard to do, since most libraries are used by more 
than one port. Holding back a library to be compatible with one port may not be 
the right choice for other ports that depends on the library.


> Is there some way that I can signal not to update certain libraries without 
> verifying against blender? Should I leave some sort of warning comment in the 
> portfiles?

A comment in the portfile, near where the version is defined since that's where 
someone updating the port will look first, is a great way to communicate that.

Re: Ports updated without maintainer notification?

[Daniel J. Luke]

On May 8, 2021, at 3:48 PM, Jason Liu  wrote:
> As I said in the last message that I just sent, the risk of updating the 
> particular ports I mentioned are that they are dependencies for the blender 
> port, and might cause blender to fail. Every time I have updated those 
> libraries in the past, I have always made sure that the updated version 
> compiles against the blender port. Not only that, but I did run into one 
> instance where blender was compiling successfully against a newer version of 
> one of the libraries, but the Blender app was crashing during runtime 
> whenever I tried to render a project.

Whether or not you decide to keep openmaintainer on the ports in question, it 
would be a good idea to make a note about this in a comment in the portfiles 
for those libraries so that anyone who decides to commit a change 
(openmaintainer/maintainer timeout/security update/mistake) is more likely to 
be aware of this.

-- 
Daniel J. Luke

Re: Ports updated without maintainer notification?

[Joshua Root]

On 2021-5-9 05:26 , Jason Liu wrote:


Is there some way that I can signal not to update certain libraries 
without verifying against blender? Should I leave some sort of warning 
comment in the portfiles?


Yes, that should definitely be documented in those portfiles, both for 
the information of others so they're not tempted to make 
well-intentioned updates, and for the benefit of whoever may someday 
take over the role of Blender maintainer.


- Josh

Re: Ports updated without maintainer notification?

[Jason Liu]

> Adding openmaintainer makes things easier with non-committer maintainers
> in particular, which is why it's recommended to new maintainers, but it's
> not required. If there's a good chance that someone not familiar with the
> nuances of a port will inadvertently break something, then openmaintainer
> is not the right choice.
>

As I said in the last message that I just sent, the risk of updating the
particular ports I mentioned are that they are dependencies for the blender
port, and might cause blender to fail. Every time I have updated those
libraries in the past, I have always made sure that the updated version
compiles against the blender port. Not only that, but I did run into one
instance where blender was compiling successfully against a newer version
of one of the libraries, but the Blender app was crashing during runtime
whenever I tried to render a project.

But you need to respond to tickets and PRs within 3 days, or changes can be
> merged anyway under the maintainer timeout rule.
>

Not usually a problem. Hopefully it's fairly evident that I've been pretty
active since I started submitting ports around a year ago.

Also note that openmaintainer is not carte blanche for others to make
> whatever changes they want to your ports.
>

That's why I was so confused when I suddenly realized that some of the
ports I maintain were updated to new versions, and I couldn't find any PRs
or Trac tickets referring to those changes. I had a moment of real panic,
because at that moment, I had no way of guaranteeing that my blender port
in the public ports tree wasn't suddenly broken.

-- 
Jason Liu


On Fri, May 7, 2021 at 12:43 PM Joshua Root  wrote:

> On 2021-5-8 02:02 , Jason Liu wrote:
> >
> > If your ports are marked openmaintainer, that gives permission to
> > others to make minor modifications to your ports without notifying
> > you. Not all changes happen via PRs; some are committed directly to
> > master.
> >
> >
> > Does this mean that it's okay to have ports with only myself as
> > maintainer? When I started submitting my first ports around a year ago,
> > I was told that I should always add openmaintainer in addition to myself.
>
> Adding openmaintainer makes things easier with non-committer maintainers
> in particular, which is why it's recommended to new maintainers, but
> it's not required. If there's a good chance that someone not familiar
> with the nuances of a port will inadvertently break something, then
> openmaintainer is not the right choice. But you need to respond to
> tickets and PRs within 3 days, or changes can be merged anyway under the
> maintainer timeout rule.
>
> Also note that openmaintainer is not carte blanche for others to make
> whatever changes they want to your ports. Committers are expected to
> apply good judgement when making changes to ports maintained by others,
> and to take responsibility for fixing any problem introduced in doing
> so. If a change is at all risky or there is any doubt as to the correct
> approach, running it by the maintainer first is the right thing to do.
>
> 
>
> - Josh
>

Re: Ports updated without maintainer notification?

[Jason Liu]

> Did you also update all the other outdated ports on your ‘local’ machine,
> or did you just cherry-pick the updated osl from the current master ?
>

>
If so it is really not a good idea to do that, as it means, as appears
> above, you could get an updated binary tarball install that was built
> against another updated port you do not have.
>

I have a cron job (actually a launchd job) that runs port selfupdate and port
upgrade outdated every night on my machine. I did cherry-pick the updated
osl portfile from the current master in git, but only because I noticed
that the portfile had changed in the git tree but the updated ports weren't
showing up as being outdated.

You should *always* keep all your ports updated and consistent.
>
> if you run
>
> > sudo port -d sync
> > sudo port update outdated
>
> does that help >
>

Running port -d sync results in the updated ports now showing up in the
list of outdated ports. I was under the impression that port
selfupdate ran port
sync as a part of the self-update process? Or am I mistaken, and port sync
needs to be added to my nightly script?

Just finally to note, there is nothing wrong with the current osl builds,
> they are available (apart from arm) down to 10.9
>

It's not the individual libraries that I'm worried about. It's the fact
that these libraries are dependencies for my Blender port. Blender
typically uses slightly outdated versions of all of its dependent
libraries. Very complex libraries are a particular risk. For example,
trying to use the newest version of usd is causing blender builds to fail
on my machine. I remember a time when ports with lots of dependencies, such
as gimp, could be broken for weeks at a time, because updates to one or
more of its dependencies was causing gimp builds to fail. Admittedly, this
was an experience from a decade ago, but it did leave a lasting impression.

Is there some way that I can signal not to update certain libraries without
verifying against blender? Should I leave some sort of warning comment in
the portfiles?

-- 
Jason Liu


On Fri, May 7, 2021 at 12:15 PM Christopher Jones 
wrote:

>
> OSL in particular appears to be a problem on my machine. I've copied the
> newer version of the portfile directly to my local machine, and tried to
> build it, but it's failing to build because osl is indirectly dependent on
> opencolorio (by way of openimageio), and apparently there's a new problem
> with either opencolorio or openimageio:
>
> :info:build dyld: Symbol not found:
> __ZN4YAML6detail9node_data12empty_scalarE
> :info:build   Referenced from: /opt/local/lib/libOpenColorIO.1.dylib
> :info:build   Expected in: /opt/local/lib/libyaml-cpp.0.6.dylib
> :info:build  in /opt/local/lib/libOpenColorIO.1.dylib
> :info:build /bin/sh: line 1: 34490 Trace/BPT trap: 5
> :info: build
> opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/build/bin/oslc
> -q
> -I/opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/OpenShadingLanguage-1.11.13.0/src/shaders
> -I/opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/OpenShadingLanguage-1.11.13.0/src/shaders
> -I/opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/OpenShadingLanguage-1.11.13.0/src/shaders
> /opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/OpenShadingLanguage-1.11.13.0/src/shaders/emitter.osl
> -o
> /opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/build/src/shaders/emitter.oso
>
>
>
> Did you also update all the other outdated ports on your ‘local’ machine,
> or did you just cherry-pick the updated osl from the current master ?
>
> If so it is really not a good idea to do that, as it means, as appears
> above, you could get an updated binary tarball install that was built
> against another updated port you do not have.
>
> You should *always* keep all your ports updated and consistent.
>
> if you run
>
> > sudo port -d sync
> > sudo port update outdated
>
> does that help >
>
> Just finally to note, there is nothing wrong with the current osl builds,
> they are available (apart from arm) down to 10.9
>
> https://ports.macports.org/port/osl/summary
>
> Chris
>
>
> --
> Jason Liu
>
>
> On Fri, May 7, 2021 at 7:32 AM Ryan Schmidt 
> wrote:
>
>>
>>
>> On May 7, 2021, at 01:59, Jason Liu wrote:
>>
>> > I've run across a situation that has left me confused. I started
>> updating some of the portfiles for which I'm the maintainer, and then I
>> noticed that the portfiles seem to have already been updated in git.
>> However, I can't find any PRs for such an update, and I was never notified
>> that the ports for which I'm the maintainer was getting updated... usually,
>> if someone submits a PR for a portfile for which I'm the maintainer, I get
>> a notification through GitHub.
>>
>> If your ports are marked openmaintainer, that gives permission to others
>> to make minor modifications to your ports without notifying you. Not all
>> changes 

Re: Ports updated without maintainer notification?

[Joshua Root]

On 2021-5-8 02:02 , Jason Liu wrote:


If your ports are marked openmaintainer, that gives permission to
others to make minor modifications to your ports without notifying
you. Not all changes happen via PRs; some are committed directly to
master.


Does this mean that it's okay to have ports with only myself as 
maintainer? When I started submitting my first ports around a year ago, 
I was told that I should always add openmaintainer in addition to myself.


Adding openmaintainer makes things easier with non-committer maintainers 
in particular, which is why it's recommended to new maintainers, but 
it's not required. If there's a good chance that someone not familiar 
with the nuances of a port will inadvertently break something, then 
openmaintainer is not the right choice. But you need to respond to 
tickets and PRs within 3 days, or changes can be merged anyway under the 
maintainer timeout rule.


Also note that openmaintainer is not carte blanche for others to make 
whatever changes they want to your ports. Committers are expected to 
apply good judgement when making changes to ports maintained by others, 
and to take responsibility for fixing any problem introduced in doing 
so. If a change is at all risky or there is any doubt as to the correct 
approach, running it by the maintainer first is the right thing to do.




- Josh

Re: Ports updated without maintainer notification?

[Christopher Jones]

> OSL in particular appears to be a problem on my machine. I've copied the 
> newer version of the portfile directly to my local machine, and tried to 
> build it, but it's failing to build because osl is indirectly dependent on 
> opencolorio (by way of openimageio), and apparently there's a new problem 
> with either opencolorio or openimageio:
> 
> :info:build dyld: Symbol not found: __ZN4YAML6detail9node_data12empty_scalarE
> :info:build   Referenced from: /opt/local/lib/libOpenColorIO.1.dylib
> :info:build   Expected in: /opt/local/lib/libyaml-cpp.0.6.dylib
> :info:build  in /opt/local/lib/libOpenColorIO.1.dylib
> :info:build /bin/sh: line 1: 34490 Trace/BPT trap: 5
> :info: build  
> opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/build/bin/oslc
>  -q 
> -I/opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/OpenShadingLanguage-1.11.13.0/src/shaders
>  
> -I/opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/OpenShadingLanguage-1.11.13.0/src/shaders
>  
> -I/opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/OpenShadingLanguage-1.11.13.0/src/shaders
>  
> /opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/OpenShadingLanguage-1.11.13.0/src/shaders/emitter.osl
>  -o 
> /opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/build/src/shaders/emitter.oso


Did you also update all the other outdated ports on your ‘local’ machine, or 
did you just cherry-pick the updated osl from the current master ? 

If so it is really not a good idea to do that, as it means, as appears above, 
you could get an updated binary tarball install that was built against another 
updated port you do not have.

You should *always* keep all your ports updated and consistent.

if you run

> sudo port -d sync
> sudo port update outdated

does that help >

Just finally to note, there is nothing wrong with the current osl builds, they 
are available (apart from arm) down to 10.9

https://ports.macports.org/port/osl/summary 


Chris

> 
> -- 
> Jason Liu
> 
> 
> On Fri, May 7, 2021 at 7:32 AM Ryan Schmidt  > wrote:
> 
> 
> On May 7, 2021, at 01:59, Jason Liu wrote:
> 
> > I've run across a situation that has left me confused. I started updating 
> > some of the portfiles for which I'm the maintainer, and then I noticed that 
> > the portfiles seem to have already been updated in git. However, I can't 
> > find any PRs for such an update, and I was never notified that the ports 
> > for which I'm the maintainer was getting updated... usually, if someone 
> > submits a PR for a portfile for which I'm the maintainer, I get a 
> > notification through GitHub.
> 
> If your ports are marked openmaintainer, that gives permission to others to 
> make minor modifications to your ports without notifying you. Not all changes 
> happen via PRs; some are committed directly to master.
> 
> If there is an urgent issue that needs to be fixed in a port, someone else 
> might make that fix, even if the port is not marked openmaintainer.
> 
> If you let us know specifically which ports, we could take a look.
> 
> 
> > In addition, I have run a "port selfupdate" on my machine, and yet the 
> > MacPorts on my machine isn't seeing the new version of the port. Is 
> > something broken, either on my machine, or on GitHub?
> 
> If your MacPorts is configured to get ports via rsync, it can take an hour 
> for changes to propagate from git to the main rsync server, and up to a day 
> longer for changes to propagate from there to other rsync mirrors.



smime.p7s
Description: S/MIME cryptographic signature

Re: Ports updated without maintainer notification?

[Jason Liu]

> If your ports are marked openmaintainer, that gives permission to others
> to make minor modifications to your ports without notifying you. Not all
> changes happen via PRs; some are committed directly to master.
>

Does this mean that it's okay to have ports with only myself as maintainer?
When I started submitting my first ports around a year ago, I was told that
I should always add openmaintainer in addition to myself.

If you let us know specifically which ports, we could take a look.
>

The ports are osl, oidn, and embree.


> In addition, I have run a "port selfupdate" on my machine, and yet the
>> MacPorts on my machine isn't seeing the new version of the port. Is
>> something broken, either on my machine, or on GitHub?
>>
>
> If your MacPorts is configured to get ports via rsync, it can take an hour
> for changes to propagate from git to the main rsync server, and up to a day
> longer for changes to propagate from there to other rsync mirrors.
>

OSL in particular appears to be a problem on my machine. I've copied the
newer version of the portfile directly to my local machine, and tried to
build it, but it's failing to build because osl is indirectly dependent on
opencolorio (by way of openimageio), and apparently there's a new problem
with either opencolorio or openimageio:

:info:build dyld: Symbol not found:
__ZN4YAML6detail9node_data12empty_scalarE
:info:build   Referenced from: /opt/local/lib/libOpenColorIO.1.dylib
:info:build   Expected in: /opt/local/lib/libyaml-cpp.0.6.dylib
:info:build  in /opt/local/lib/libOpenColorIO.1.dylib
:info:build /bin/sh: line 1: 34490 Trace/BPT trap: 5
:info: build
opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/build/bin/oslc
-q
-I/opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/OpenShadingLanguage-1.11.13.0/src/shaders
-I/opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/OpenShadingLanguage-1.11.13.0/src/shaders
-I/opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/OpenShadingLanguage-1.11.13.0/src/shaders
/opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/OpenShadingLanguage-1.11.13.0/src/shaders/emitter.osl
-o
/opt/local/var/macports/build/_Users_jasonliu_ports_graphics_osl/osl/work/build/src/shaders/emitter.oso

-- 
Jason Liu


On Fri, May 7, 2021 at 7:32 AM Ryan Schmidt  wrote:

>
>
> On May 7, 2021, at 01:59, Jason Liu wrote:
>
> > I've run across a situation that has left me confused. I started
> updating some of the portfiles for which I'm the maintainer, and then I
> noticed that the portfiles seem to have already been updated in git.
> However, I can't find any PRs for such an update, and I was never notified
> that the ports for which I'm the maintainer was getting updated... usually,
> if someone submits a PR for a portfile for which I'm the maintainer, I get
> a notification through GitHub.
>
> If your ports are marked openmaintainer, that gives permission to others
> to make minor modifications to your ports without notifying you. Not all
> changes happen via PRs; some are committed directly to master.
>
> If there is an urgent issue that needs to be fixed in a port, someone else
> might make that fix, even if the port is not marked openmaintainer.
>
> If you let us know specifically which ports, we could take a look.
>
>
> > In addition, I have run a "port selfupdate" on my machine, and yet the
> MacPorts on my machine isn't seeing the new version of the port. Is
> something broken, either on my machine, or on GitHub?
>
> If your MacPorts is configured to get ports via rsync, it can take an hour
> for changes to propagate from git to the main rsync server, and up to a day
> longer for changes to propagate from there to other rsync mirrors.

Re: Ports updated without maintainer notification?

[Christopher Jones]

> 
> In addition, I have run a "port selfupdate" on my machine, and yet the 
> MacPorts on my machine isn't seeing the new version of the port. Is something 
> broken, either on my machine, or on GitHub?

If you aren’t already, I strongly recommend using a direct git clone of the 
ports tree rather than the default rsync’ed tarball. i.e.something like this in 
your sources.conf

~/Projects/MacPorts/ports > tail -3 /opt/local/etc/macports/sources.conf

#rsync://rsync.macports.org/macports/release/tarballs/ports.tar [default]
file:///Users/chris/Projects/MacPorts/ports [default]

where the path above points to where ever you choose to git clone the ports 
repo.

Once you have done this, ‘port sync’ automatically updates this via a git 
rebase rather than the rsync tarball.

e.g.

Oberon ~/Projects/MacPorts/ports > port -d sync
--->  Updating the ports tree
Synchronizing local ports tree from file:///Users/chris/Projects/MacPorts/ports
DEBUG: /opt/local/bin/git pull --rebase --autostash
DEBUG: system -W /Users/chris/Projects/MacPorts/ports: /opt/local/bin/git pull 
--rebase --autostash
Current branch master is up to date.
DEBUG: system: /opt/local/bin/portindex /Users/chris/Projects/MacPorts/ports
Creating port index in /Users/chris/Projects/MacPorts/ports

Total number of ports parsed:   0 
Ports successfully parsed:  0 
Ports failed:   0 
Up-to-date ports skipped:   26290


the -d option is very useful here as you get to see the git rebase, tother with 
the portindex update.

If you do this regularly, and before submitting any PR’s, it is basically 
impossible  to ‘miss’ updates to any ports.

Chris

smime.p7s
Description: S/MIME cryptographic signature

Re: Ports updated without maintainer notification?

[Ryan Schmidt]

On May 7, 2021, at 01:59, Jason Liu wrote:

> I've run across a situation that has left me confused. I started updating 
> some of the portfiles for which I'm the maintainer, and then I noticed that 
> the portfiles seem to have already been updated in git. However, I can't find 
> any PRs for such an update, and I was never notified that the ports for which 
> I'm the maintainer was getting updated... usually, if someone submits a PR 
> for a portfile for which I'm the maintainer, I get a notification through 
> GitHub.

If your ports are marked openmaintainer, that gives permission to others to 
make minor modifications to your ports without notifying you. Not all changes 
happen via PRs; some are committed directly to master.

If there is an urgent issue that needs to be fixed in a port, someone else 
might make that fix, even if the port is not marked openmaintainer.

If you let us know specifically which ports, we could take a look.


> In addition, I have run a "port selfupdate" on my machine, and yet the 
> MacPorts on my machine isn't seeing the new version of the port. Is something 
> broken, either on my machine, or on GitHub?

If your MacPorts is configured to get ports via rsync, it can take an hour for 
changes to propagate from git to the main rsync server, and up to a day longer 
for changes to propagate from there to other rsync mirrors.

Ports updated without maintainer notification?

[Jason Liu]

Hi all,

I've run across a situation that has left me confused. I started updating
some of the portfiles for which I'm the maintainer, and then I noticed that
the portfiles seem to have already been updated in git. However, I can't
find any PRs for such an update, and I was never notified that the ports
for which I'm the maintainer was getting updated... usually, if someone
submits a PR for a portfile for which I'm the maintainer, I get a
notification through GitHub.

In addition, I have run a "port selfupdate" on my machine, and yet the
MacPorts on my machine isn't seeing the new version of the port. Is
something broken, either on my machine, or on GitHub?

-- 
Jason Liu