Re: [MacPorts] #54594: mariadb-10.1 @10.1.24: update to 10.1.26

[Zero King]

On Sat, Aug 12, 2017 at 02:37:12PM -0700, Bradley Giesbrecht wrote:

Is there a pull request?

Regards,
Bradley Giesbrecht (pixilla)


No, there isn't. This update fixes 3 CVEs but I don't have the time to
test this port, so I created the ticket.



On Aug 11, 2017, at 9:02 PM, MacPorts  wrote:

#54594: mariadb-10.1 @10.1.24: update to 10.1.26
--+--
Reporter:  l2dy  |  Owner:  pixilla
Type:  update| Status:  new
Priority:  Normal|  Milestone:
Component:  ports |Version:
Keywords:  security  |   Port:  mariadb-10.1
--+--


--
Ticket URL: 
MacPorts 
Ports system for macOS




--
Best regards,
Zero King


smime.p7s
Description: S/MIME cryptographic signature

Re: should cxx11 1.1 PortGroup also blacklist older clangs (< 600, say) during libc++ builds?

[Ken Cunningham]

I’m sorry - retract this. I see there is already a section where this is done 
that I had glossed past before.

I’ll have to look into why I still need to fiddle with this sometimes.

Sorry for noise.

Ken


> On Aug 12, 2017, at 3:02 PM, Ken Cunningham  
> wrote:
> 
> The libstdc++ section of this portgroup forces clang 4.0, and the PPC section 
> forces gcc6. Those cover almost all current port compiler requirements.
> 
> But there is still a hole in the libc++ section, and it happens often enough 
> that older clangs (< 600 or so) have to be blacklisted on older systems 
> separately.
> 
> It would seem consistent with the purpose of the Portgroup that this might be 
> included in the libc++ section to save this coming into each Portfile 
> separately.
> 
> Something like this:
> 
> 
> 
> } else {
># GCC compilers can not use libc++
>compiler.blacklist-append   *gcc*
> 
>compiler.blacklist-append   { clang < 600 }
> 
> }
> 
> ==
> 
> would probably do it for now. (That could be bumped to 800 - or more - rather 
> easily in the future when that is needed).
> 
> 
> Ken

should cxx11 1.1 PortGroup also blacklist older clangs (< 600, say) during libc++ builds?

[Ken Cunningham]

The libstdc++ section of this portgroup forces clang 4.0, and the PPC section 
forces gcc6. Those cover almost all current port compiler requirements.

But there is still a hole in the libc++ section, and it happens often enough 
that older clangs (< 600 or so) have to be blacklisted on older systems 
separately.

It would seem consistent with the purpose of the Portgroup that this might be 
included in the libc++ section to save this coming into each Portfile 
separately.

Something like this:



} else {
# GCC compilers can not use libc++
compiler.blacklist-append   *gcc*

compiler.blacklist-append   { clang < 600 }

}

==

would probably do it for now. (That could be bumped to 800 - or more - rather 
easily in the future when that is needed).


Ken

Re: Possible patch for sox build failure on 10.7

[Joshua Root]

On 2017-8-13 01:12 , Ken Cunningham wrote:

Thank you Josh. I missed ./configure --disable-silent-libtool.


I am a bit confused about this. According to 
, 
disable-silent-rules is the default.


For Automake-generated Makefiles, the user may influence the verbosity 
at |configure| run time as well as at |make| run time:


  * Passing --enable-silent-rules to |configure| will cause build rules
to be less verbose; the option --disable-silent-rules will cause
normal verbose output.


But sox's configure.ac has:

AM_SILENT_RULES([yes])

- Josh

Re: [GSoC] migration

[Umesh Singla]

> > That was a suggested design; if you're already doing it differently then
> I guess you don't need a design. I disagree with the last sentence though,
> a snapshot can be viewed as precisely the state of the original tables at a
> previous time.
>
> If that is the case, we can simply (insert into snapshot_ports select *
> from ports) to create a snapshot. Obviously the snapshot_ports table needs
> an extra snapshot_id column.
>

Yes, that's what we are indirectly doing at present.


> >> Also, we are not using version and revision. Even going by the literal
> meaning of a snapshot, it should not have a key or id linked to something
> that can change over time. It's simply the present state.
> >
> > The row in the ports table would not change over time, it would simply
> persist until no longer needed. If we ever get the ability to install old
> versions then that information would come in handy.
>
> Sounds right.


Sure.

- Umesh

Re: [GSoC] migration

[Umesh Singla]

> > Later, I am planning to keep information on the manual portgroups in the
> snapshot, if there are any.
> >
> > What would this information be used for?
> >
> > I am under the impression that a user can categorize and classify the
> ports into portgroups, so it should be better if we migrate them too.
> Though, it seems highly
>
> Checkout "man portgroup”, I think your understanding may not be 100%
> correct. Portgroups simply provide a way for port authors to include common
> code in there ports.
>
> Perhaps you are thinking that we would need to snapshot portgroup files if
> we where to ever support installing older versions of software. In that
> case you would be correct, the portgroup files would need to match the
> version of the portfile.
>

As I said, I myself am not very clear at present but just listing the
points to be used later. But the above is what I meant more or less, though
I was clear on the relation between portgroups and the versions.

- Umesh

Re: [MacPorts] #54594: mariadb-10.1 @10.1.24: update to 10.1.26

[Bradley Giesbrecht]

Is there a pull request?

Regards,
Bradley Giesbrecht (pixilla)




> On Aug 11, 2017, at 9:02 PM, MacPorts  wrote:
> 
> #54594: mariadb-10.1 @10.1.24: update to 10.1.26
> --+--
> Reporter:  l2dy  |  Owner:  pixilla
> Type:  update| Status:  new
> Priority:  Normal|  Milestone:
> Component:  ports |Version:
> Keywords:  security  |   Port:  mariadb-10.1
> --+--
> 
> 
> --
> Ticket URL: 
> MacPorts 
> Ports system for macOS

Re: [GSoC] migration

[Bradley Giesbrecht]

> On Aug 11, 2017, at 12:46 PM, Umesh Singla  wrote:
> 
> Hi Josh,
> 
> And then again, I am sensing a confusion with the idea of
> snapshot with Josh, like when he says "remove ports when they
> are no longer referenced by any snapshot".
> 
> 
> What confusion exactly? A snapshot is simply a set of ports (by
> which I mean rows in the 'ports' table, with a unique combination of
> name,version,revision,variants). When nothing references a row any
> more, it needs to be deleted.
> 
> 
> By 'ports', do you mean 'registry.ports' table? If yes, then I disagree. It's 
> actually 'registry.snapshot_ports' table. A snapshot has nothing to do with 
> the original registry "tables".
> 
> That was a suggested design; if you're already doing it differently then I 
> guess you don't need a design. I disagree with the last sentence though, a 
> snapshot can be viewed as precisely the state of the original tables at a 
> previous time.
> 
> This is on the lines what I had in mind regarding a snapshot.
> 
> Also, we are not using version and revision. Even going by the literal 
> meaning of a snapshot, it should not have a key or id linked to something 
> that can change over time. It's simply the present state.
> 
> The row in the ports table would not change over time, it would simply 
> persist until no longer needed. If we ever get the ability to install old 
> versions then that information would come in handy.
> 
> I meant when the port gets updates, the row in the 'ports' table will change 
> but not in 'snapshot_ports' table because for a particular snapshot, the 
> state has changed. But I think it's clear now.
> 
> And yes, version and revision can help in restoring older versions of ports 
> present in older snapshots.
>  
> Later, I am planning to keep information on the manual portgroups in the 
> snapshot, if there are any.
> 
> What would this information be used for?
>  
> I am under the impression that a user can categorize and classify the ports 
> into portgroups, so it should be better if we migrate them too. Though, it 
> seems highly 

Checkout "man portgroup”, I think your understanding may not be 100% correct. 
Portgroups simply provide a way for port authors to include common code in 
there ports.

Perhaps you are thinking that we would need to snapshot portgroup files if we 
where to ever support installing older versions of software. In that case you 
would be correct, the portgroup files would need to match the version of the 
portfile.

—
Brad

Re: [GSoC] migration

[Bradley Giesbrecht]

> On Aug 11, 2017, at 11:16 AM, Joshua Root  wrote:
> 
> On 2017-8-11 21:14 , Umesh Singla wrote:
>> Hi
>>And then again, I am sensing a confusion with the idea of
>>snapshot with Josh, like when he says "remove ports when they
>>are no longer referenced by any snapshot".
>>What confusion exactly? A snapshot is simply a set of ports (by
>>which I mean rows in the 'ports' table, with a unique combination of
>>name,version,revision,variants). When nothing references a row any
>>more, it needs to be deleted.
>> By 'ports', do you mean 'registry.ports' table? If yes, then I disagree. 
>> It's actually 'registry.snapshot_ports' table. A snapshot has nothing to do 
>> with the original registry "tables".
> 
> That was a suggested design; if you're already doing it differently then I 
> guess you don't need a design. I disagree with the last sentence though, a 
> snapshot can be viewed as precisely the state of the original tables at a 
> previous time.

If that is the case, we can simply (insert into snapshot_ports select * from 
ports) to create a snapshot. Obviously the snapshot_ports table needs an extra 
snapshot_id column.

>> Also, we are not using version and revision. Even going by the literal 
>> meaning of a snapshot, it should not have a key or id linked to something 
>> that can change over time. It's simply the present state.
> 
> The row in the ports table would not change over time, it would simply 
> persist until no longer needed. If we ever get the ability to install old 
> versions then that information would come in handy.

Sounds right.

>> Later, I am planning to keep information on the manual portgroups in the 
>> snapshot, if there are any.
> 
> What would this information be used for?

Sorry, I don’t understand what “manual ports groups” refers to. Maybe I missed 
an earlier conversation.

—
Brad

configure.compiler=macports-clang-devel doesn't work. Is there a proper value?

[Ken Cunningham]

Doesn’t seem to be an entry for clang-devel in 
> and some trial and 
error didn’t find it easily…

Also, can’t spot an entry in 
>
 to use.

Ken

Re: Possible patch for sox build failure on 10.7

[Ken Cunningham]

> Thank you Josh. I missed ./configure --disable-silent-libtool.

I am a bit confused about this. According to 
>,
 disable-silent-rules is the default.

For Automake-generated Makefiles, the user may influence the verbosity at 
configure run time as well as at make run time:

 <>  <>Passing --enable-silent-rules to configure will cause build rules to be 
less verbose; the option --disable-silent-rules will cause normal verbose 
output.



Ken

Re: Possible patch for sox build failure on 10.7

[Jan Stary]

On Aug 12 10:56:57, mo...@macports.org wrote:
> On 12 August 2017 at 10:36, Jan Stary wrote:
> >
> > libtool: link: /usr/bin/grep -E -e 
> > "^(sox_.*|lsx_(check_read_params|(close|open)_dllibrary|(debug(_more|_most)?|fail|report|warn)_impl|eof|fail_errno|filelength|find_(enum_(text|value)|file_extension)|getopt(_init)?|lpc10_(create_(de|en)coder_state|(de|en)code)|raw(read|write)|read(_b_buf|buf|chars)|realloc|rewind|seeki|sigfigs3p?|strcasecmp|tell|unreadb|write(b|_b_buf|buf|s)))$"
> >  ".libs/libsox.exp" > ".libs/libsox.expT"
> >
> > Can someone on 10.7 please check that this is the failing grep line?
> > (Not even in connection with SoX, just grep that regexp on anything.)
> 
> Confirming.

Thank you I will ask upstream whether the regexp can be simplified
(or is even up to date), to see if we can avoid the dependency on grep.

Jan

Re: Possible patch for sox build failure on 10.7

[Mojca Miklavec]

On 12 August 2017 at 10:36, Jan Stary wrote:
>
> libtool: link: /usr/bin/grep -E -e 
> "^(sox_.*|lsx_(check_read_params|(close|open)_dllibrary|(debug(_more|_most)?|fail|report|warn)_impl|eof|fail_errno|filelength|find_(enum_(text|value)|file_extension)|getopt(_init)?|lpc10_(create_(de|en)coder_state|(de|en)code)|raw(read|write)|read(_b_buf|buf|chars)|realloc|rewind|seeki|sigfigs3p?|strcasecmp|tell|unreadb|write(b|_b_buf|buf|s)))$"
>  ".libs/libsox.exp" > ".libs/libsox.expT"
>
> Can someone on 10.7 please check that this is the failing grep line?
> (Not even in connection with SoX, just grep that regexp on anything.)

Confirming.

Mojca

Re: Possible patch for sox build failure on 10.7

[Jan Stary]

On Aug 10 06:30:12, j...@macports.org wrote:
> On 2017-8-9 23:15 , Jan Stary wrote:
> > On Aug 09 15:06:35, ken.cunningham.web...@gmail.com wrote:
> > > I can work with you on this. I'll build a failing version and email you 
> > > the entire log off-list tonight.
> > 
> > Thank you Ken.
> > 
> > I looked on the detailed log of vanilla SoX 14.4.2 itself,
> > but cannot find the offending grep. Is it run by SoX's build system,
> > or is the nm/grep combo run by the building robot?
> 
> The addition of --disable-silent-rules in the patch was to hopefully show
> more of the failing command (and it's a good idea anyway since silent rules
> make logs much less useful).

'make V=1' disables the silent rules

$ ./configure --help
--enable-silent-rules   less verbose build output (undo: "make V=1")
--disable-silent-rules  verbose build output (undo: "make V=0")

> This is not something that would be specific to
> the buildbot. I'm not sure, but given what is happening when the error
> occurs, the offending grep command may be invoked by (g)libtool.

Thank you Josh. I missed ./configure --disable-silent-libtool.
Then the full build log (attached) reveals

libtool: link: /usr/bin/grep -E -e 
"^(sox_.*|lsx_(check_read_params|(close|open)_dllibrary|(debug(_more|_most)?|fail|report|warn)_impl|eof|fail_errno|filelength|find_(enum_(text|value)|file_extension)|getopt(_init)?|lpc10_(create_(de|en)coder_state|(de|en)code)|raw(read|write)|read(_b_buf|buf|chars)|realloc|rewind|seeki|sigfigs3p?|strcasecmp|tell|unreadb|write(b|_b_buf|buf|s)))$"
 ".libs/libsox.exp" > ".libs/libsox.expT"

Can someone on 10.7 please check that this is the failing grep line?
(Not even in connection with SoX, just grep that regexp on anything.)

Jan



typescript.gz
Description: application/gunzip