powerpc64 & system-clang vs. building the likes of lang/gcc7 (at least): vec_step name pollution causes compile failures, should gcc7 source code avoid the name?

[Mark Millard]

[I experiment with clang-based worlds and kernels
on powerpc64 and powerpc. But I'm not sure that
such is the only type of context is required to
see the below problem.]

Attempting to build lang/gcc7 on a system-clang based
powerpc64 (world and kernel) gets:


/wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3835:27: 
error: expected unqualified-id
  tree new_vec, vec_init, vec_step, t;
  ^
/wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3835:26: 
error: expected ';' at end of declaration
  tree new_vec, vec_init, vec_step, t;
 ^
 ;

Well, it turns out that vec_step has the following
potential naming conflicts, one for powerpc64 FreeBSD
specifics, and one for clang specifics (for support of
OpenCL). . .

For powerpc64:

/usr/src/contrib/gcc/config/rs6000/altivec.h:#define vec_step(x) 
__builtin_vec_step (* (__typeof__ (x) *) 0)

(I'm point the above out despite my clang-based context.)

For clang:

/usr/src/contrib/llvm/tools/clang/lib/Parse/ParseExpr.cpp:/// vec_step and we 
are at the start of an expression or a parenthesized
/usr/src/contrib/llvm/tools/clang/lib/Parse/ParseExpr.cpp:/// [OpenCL 1.1 
6.11.12] vec_step built-in function:
/usr/src/contrib/llvm/tools/clang/lib/Parse/ParseExpr.cpp:///   
vec_step ( expressions )
/usr/src/contrib/llvm/tools/clang/lib/Parse/ParseExpr.cpp:///   
vec_step ( type-name )
/usr/src/contrib/llvm/tools/clang/lib/Parse/ParseExpr.cpp: "Not a 
typeof/sizeof/alignof/vec_step expression!");
/usr/src/contrib/llvm/tools/clang/lib/Parse/ParseExpr.cpp: "Not a 
sizeof/alignof/vec_step expression!");
/usr/src/contrib/llvm/tools/clang/lib/Sema/SemaExpr.cpp:  // [OpenCL 1.1 
6.11.12] "The vec_step built-in function takes a built-in
/usr/src/contrib/llvm/tools/clang/lib/Sema/TreeTransform.h:  /// \brief Build a 
new sizeof, alignof or vec_step expression with a
/usr/src/contrib/llvm/tools/clang/include/clang/AST/Expr.h:/// vec_step (OpenCL 
1.1 6.11.12).
/usr/src/contrib/llvm/tools/clang/include/clang/ASTMatchers/ASTMatchers.h:/// 
\brief Matches sizeof (C99), alignof (C++11) and vec_step (OpenCL)
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td:  
"invalid application of '%select{sizeof|alignof|vec_step}0' to a "
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td:  
"invalid application of '%select{sizeof|alignof|vec_step}0' to a void "
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td:  
"invalid application of 
'%select{sizeof|alignof|vec_step|__builtin_omp_required_simd_align}0' to a void 
type">;
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td:  
"invalid application of 
'%select{sizeof|alignof|vec_step|__builtin_omp_required_simd_align}0' to an "
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td:  
"invalid application of 
'%select{sizeof|alignof|vec_step|__builtin_omp_required_simd_align}0' to a "
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td:  
"'vec_step' requires built-in scalar or vector type, %0 invalid">;
/usr/src/contrib/llvm/tools/clang/include/clang/Basic/TokenKinds.def:KEYWORD(vec_step
, KEYOPENCL|KEYALTIVEC|KEYZVECTOR)

(The lists were extracted from a: grep -r "\" /usr/src/*
Some material was omitted from the reported matches.)


Given the clang extension for having vec_step for OpenCL,
it might be best if lang/gcc7 was updated to avoid the
name (upstream as well). devel/llvm50 likely has the
same vec_step as system-clang. I'm not sure about
devel/llvm40 .

This might be true of some other lang/gcc*'s: I just
happen to build lang/gcc7 but not the others (generally).

Context details:

# uname -apKU
FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT  r326192M  powerpc powerpc64 
1200054 1200054

# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 455204
Last Changed Rev: 455204

(Last before FLAVORS is enabled.)

===
Mark Millard
markmi at dsl-only.net

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Debugging a crash

[George Mitchell]

FreeBSD 10.3-RELEASE-p24
FreeBSD clang version 3.4.1 (from base)
GNU gdb 6.1.1 (from base)
I'm trying to debug a crash in the multimedia/tvheadend 4.2.3 server on
the above system when playing a recorded program on tvheadend's Android
client.  It reliably crashes when I try to fast forward.  But if I run
the server under gdb to catch the SIGSEGV, the stack is complete trash.
Even if I try to single-step through the top level of main(), gdb acts
unhappy (though before starting the program I can at least list the
source, having specified "directory /usr/ports/").  Should base gdb
be able to debug base clang binaries?  Do I need clang from ports? or
gdb from ports?  Does devel/lldb38 work better?  Thanks from this
prospective cord-cutter for any help.  -- George



signature.asc
Description: OpenPGP digital signature

Re: Working on FLAVOR support in portmaster

[Chris H]

On Tue, 5 Dec 2017 13:48:12 -0600 "Mark Linimon"  said


On Tue, Dec 05, 2017 at 08:42:27AM -0800, Chris H wrote:
> IMHO it might be a good idea to make a legacy branch, in the ports
> tree before gutting the pre-NG stuff.

Good lord, people.

The pre-NG stuff has Left The Building.  It is not coming back.

The last (even trivial) revision to the pkg_* codebase was Mon Aug 19
14:04:35 2013 UTC:

 https://svnweb.freebsd.org/base?view=revision=254525

The corresponding bsd.port.mk version was:

 https://svnweb.freebsd.org/ports?view=revision=324051

For comparison:

 ports is currently at r455604 [*]
 USES= had recently been introduced at r313517 Wed Mar 6 14:28:57
   2013 UTC (4 years, 9 months ago)
 options handling had recently been reworked at r321785 Wed Jun 26
   07:22:06 2013 UTC (4 years, 5 months ago)
 LIB_DEPENDS had recently been reworked at r322328 Fri Jul 5 14:10:55
   2013 UTC (4 years, 5 months ago) by bapt
 staging came in at r327910 Mon Sep 23 05:56:35 2013 UTC (4 years,
   2 months ago) 
 the warning about pkg_* EOL was r342537 Tue Feb 4 14:23:08 2014
   UTC (3 years, 10 months ago) 
 and I'm not going to iterate over all the refactoring and bug-

   fixing since that time.

(Most likely, pkg_* was not thoroughly tested since early 2013, so I've
included the first 4 big reworks above.)

If you want to look at the diffs to bsd.port.mk since the last time pkg_*
was even trivially maintained:

 https://svnweb.freebsd.org/ports/head/Mk/bsd.port.mk?r1=324051=455280

The diff is 5528 lines.  It's unreadable.

If you're staying with pkg_*, you're basically saying "I don't mind
running with something that hasn't really been QAed with those 5528 lines
of changes."

IMVVHO: madness.

I really don't have anything more I can say on the matter.

mcl

* Because I'm now annoyed, I'm going to do some math:

 455604 - 324051 = 131553

That's over One. Hundred. Thousand. Ports. Commits. Ago.

That's 7 pages of commits to bsd.port.mk itself, per svnweb.

OK now that just makes me look like an idiot. You cite me, then
trim the only redeeming part of my reply.
Now I'm annoyed. ;)


The sensible side of me also agrees that this is probably a reasonable,
and efficient approach. But the practical side says there will likely
be some screaming on the mailing lists, once this change lands.


You see. Like you, I *too* can be sensible. :)

--Chris


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Flavors *COMPLETELY* break the port system (synth and poudriere are useless)

[Ultima]

I wonder if making a simple man page for general users would be wise and
referencing the fully featured man page in it for more experienced users?
It seems that many users want a simple route and the current man page is
simply too intimidating for them to even consider attempting to use. A
small how to at the bottom like how Bryan suggested would be helpful as
well. (Maybe leave out the amount of characters used bit =)

Poudriere is a powerful beast and I personally love it because of this. I
felt very overwhelmed when I first started using it but not everyone is
willing to take the time to get up to speed.

Best regards,
Richard Gallamore

On Dec 5, 2017 3:30 PM, "Mark Linimon"  wrote:

> On Tue, Dec 05, 2017 at 05:25:13PM -0500, Baho Utot wrote:
> > Thank you for taking a perfectly good system and breaking it as well as
> > making it unusable, unstable.
>
> You made your point 10 posts ago.
>
> You are repeating yourself.
>
> Why???
>
> mcl
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Flavors *COMPLETELY* break the port system (synth and poudriere are useless)

[Per olof Ljungmark]

On 12/05/17 23:25, Baho Utot wrote:
> Thank you for taking a perfectly good system and breaking it as well as
> making it unusable, unstable.  You just don't know of all the countless
> hours spent after running an update and taking a week to get it working
> again.
> 
> It really helps motivate all of us users to continue to have to fix
> broken systems due to broken ports system and then be told how great
> things are, brings us so much joy and keeps our attitude positive.

Please, can we just get on with our lives, a lot of good people are
already working hard to fix whatever needs to be fixed.

Patience is a virtue

//per
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Central build runs out of file descriptors on devel/RStudio

[Adam Weinberger]

> On 5 Dec, 2017, at 15:00, Mathieu Arnold  wrote:
> 
> Le 03/12/2017 à 03:30, Adam Weinberger a écrit :
>>> On 2 Dec, 2017, at 18:57, Yuri  wrote:
>>> 
>>> Build opens too many file descriptors, and fails:
>>> 
>>> http://beefy5.nyi.freebsd.org/data/103i386-default/455387/logs/RStudio-1.1.385.log
>>> 
>>> http://beefy6.nyi.freebsd.org/data/103amd64-default/455387/logs/RStudio-1.1.385.log
>>> 
>>> 
>>> It looks like kern.maxfiles on beefy needs to be beefed up.
>> Then MAKE_JOBS_NUMBER_LIMIT (or MAKE_JOBS_UNSAFE) would be my next step. If 
>> it fails on the beefy builders, it's likely to fail on resource-starved 
>> end-user boxes. The builders do many concurrent builds, but it's possible 
>> for end-users to hit that level of activity too.
> 
> 
> But the package builders don't use MAKE_JOBS, so it will not change
> anything.

Oh geez, of course they don't.

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.org

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Flavors *COMPLETELY* break the port system (synth and poudriere are useless)

[Mark Linimon]

On Tue, Dec 05, 2017 at 05:25:13PM -0500, Baho Utot wrote:
> Thank you for taking a perfectly good system and breaking it as well as
> making it unusable, unstable.

You made your point 10 posts ago.

You are repeating yourself.

Why???

mcl
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: 32-bit powerpc system-clang based builds of devel/llvm40 and devel/llvm50: fails via "Host compiler appears to require libatomic, but cannot find it"

[Mark Millard]

On 2017-Dec-5, at 12:39 PM, Roman Divacky  wrote:

> The cmake test just tries to compile:
> 
> #include 
> std::atomic x;
> int main() {
>  return x;
> }
> 
> What happens if you try to compile this small code with your host compiler?
> 
> Roman

[I later show that it seems to be testing
with: std::atomic x (0) instead
and is also using a line the example does
not have (devel/llvm50 example):

  uint64_t i = x.load(std::memory_order_relaxed);
.]

# uname -apKU
FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT  r326192M  powerpc powerpc 
1200054 1200054

# more cpp_atomic.cpp 
#include 
std::atomic x;
int main() {
 return x;
}

# clang++ -v cpp_atomic.cpp
FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 
5.0.0svn)
Target: powerpc-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin
 "/usr/bin/clang++" -cc1 -triple powerpc-unknown-freebsd12.0 -emit-obj 
-mrelax-all -disable-free -main-file-name cpp_atomic.cpp -mrelocation-model 
static -mthread-model posix -mdisable-fp-elim -masm-verbose 
-mconstructor-aliases -target-cpu ppc -mfloat-abi hard -v -dwarf-column-info 
-debugger-tuning=gdb -resource-dir /usr/lib/clang/5.0.0 -internal-isystem 
/usr/include/c++/v1 -fdeprecated-macro -fdebug-compilation-dir /root/c_tests 
-ferror-limit 19 -fmessage-length 200 -fno-signed-char -fobjc-runtime=gnustep 
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o 
/tmp/cpp_atomic-3b1ae2.o -x c++ cpp_atomic.cpp
clang -cc1 version 5.0.0 based upon LLVM 5.0.0svn default target 
powerpc-unknown-freebsd12.0
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/v1
 /usr/lib/clang/5.0.0/include
 /usr/include
End of search list.
 "/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 
--enable-new-dtags -m elf32ppc_fbsd -o a.out /usr/lib/crt1.o /usr/lib/crti.o 
/usr/lib/crtbegin.o -L/usr/lib /tmp/cpp_atomic-3b1ae2.o -lc++ -lm -lgcc 
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed 
/usr/lib/crtend.o /usr/lib/crtn.o

# ./a.out
#

So, the example works fine.

Nothing about that example program would seem to
match the note:

-- Looking for __atomic_load_8 in atomic

I would guess that the __atomic_load_8 test
is somewhat different. . .

Looking at an expansion of a wrkdirs' .tbz that
poudriere produced, CheckAtomic.cmake has . . .

. . .
# Check for 64 bit atomic operations.
if(MSVC)
  set(HAVE_CXX_ATOMICS64_WITHOUT_LIB True)
else()
  check_working_cxx_atomics64(HAVE_CXX_ATOMICS64_WITHOUT_LIB)
endif()

# If not, check if the library exists, and atomics work with it.
if(NOT HAVE_CXX_ATOMICS64_WITHOUT_LIB)
  check_library_exists(atomic __atomic_load_8 "" HAVE_CXX_LIBATOMICS64)
  if(HAVE_CXX_LIBATOMICS64)
list(APPEND CMAKE_REQUIRED_LIBRARIES "atomic")
check_working_cxx_atomics64(HAVE_CXX_ATOMICS64_WITH_LIB)
if (NOT HAVE_CXX_ATOMICS64_WITH_LIB)
  message(FATAL_ERROR "Host compiler must support std::atomic!")
endif()
  else()
message(FATAL_ERROR "Host compiler appears to require libatomic, but cannot 
find it.")
  endif()
endif()
. . .

>From this I get:

A) check_working_cxx_atomics64(HAVE_CXX_ATOMICS64_WITHOUT_LIB)
   set: NOT HAVE_CXX_ATOMICS64_WITHOUT_LIB

B) check_library_exists(atomic __atomic_load_8 "" HAVE_CXX_LIBATOMICS64)
   set: NOT HAVE_CXX_LIBATOMICS64

For (A), looking at the test code (found by
name-text matching):

function(check_working_cxx_atomics64 varname)
  set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
  set(CMAKE_REQUIRED_FLAGS "-std=c++11 ${CMAKE_REQUIRED_FLAGS}")
  CHECK_CXX_SOURCE_COMPILES("
#include 
#include 
std::atomic x (0);
int main() {
  uint64_t i = x.load(std::memory_order_relaxed);
  return 0;
}
" ${varname})
  set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
endfunction(check_working_cxx_atomics64)

I see:

#include 
#include 
std::atomic x (0);
int main() {
  uint64_t i = x.load(std::memory_order_relaxed);
  return 0;
}

Trying that example I see:

/tmp/cpp_atomic_64_test-1fa999.o: In function `main':
cpp_atomic_64_test.cpp:(.text+0xa8): undefined reference to `__atomic_load_8'
clang++: error: linker command failed with exit code 1 (use -v to see 
invocation)

Details:

# more cpp_atomic_64_test.cpp 
#include 
#include 
std::atomic x (0);
int main() {
  uint64_t i = x.load(std::memory_order_relaxed);
  return 0;
}

# clang++ -v cpp_atomic_64_test.cpp 
FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 
5.0.0svn)
Target: powerpc-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin
 "/usr/bin/clang++" -cc1 -triple powerpc-unknown-freebsd12.0 -emit-obj 
-mrelax-all -disable-free -main-file-name cpp_atomic_64_test.cpp 
-mrelocation-model static -mthread-model posix -mdisable-fp-elim -masm-verbose 
-mconstructor-aliases -target-cpu ppc -mfloat-abi hard -v -dwarf-column-info 
-debugger-tuning=gdb -resource-dir /usr/lib/clang/5.0.0 -internal-isystem 
/usr/include/c++/v1 -fdeprecated-macro 

Re: Working on FLAVOR support in portmaster

[Eric Masson]

Stefan Esser  writes:

Hi Stefan

> Is it acceptable, to have portmaster stop supporting the old package system?

I think so.

Thanks for your work on this.

Éric Masson

-- 
 Discuter tranquillement avec Michel Guillou???
 Je n'ai JAMAIS vu quelqu'un de plus *facho* que ce type. C'est
 écoeurant.
 -+- Rocou In GNU - T'as l'adresse des FFL, c'est pour écrire -+-
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Flavors *COMPLETELY* break the port system (synth and poudriere are useless)

[Baho Utot]

On 12/05/17 17:09, Mathieu Arnold wrote:

Le 05/12/2017 à 10:53, Aryeh Friedman a écrit :

TL;DR;
Flavors 'ed up ports and there are no good ways/alternates for how
to use the ports collection for normal everyday users/maintainers



Thank you for supporting all the hard work and countless hours that so
many volunteers put in making the ports tree better.

It really helps motivate all of us continue bringing the ports tree
forward when we get emails with so much joy and positive attitude.




Thank you for taking a perfectly good system and breaking it as well as 
making it unusable, unstable.  You just don't know of all the countless 
hours spent after running an update and taking a week to get it working 
again.


It really helps motivate all of us users to continue to have to fix 
broken systems due to broken ports system and then be told how great 
things are, brings us so much joy and keeps our attitude positive.


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Flavors *COMPLETELY* break the port system (synth and poudriere are useless)

[Mathieu Arnold]

Le 05/12/2017 à 10:53, Aryeh Friedman a écrit :
> TL;DR;
> Flavors 'ed up ports and there are no good ways/alternates for how
> to use the ports collection for normal everyday users/maintainers


Thank you for supporting all the hard work and countless hours that so
many volunteers put in making the ports tree better.

It really helps motivate all of us continue bringing the ports tree
forward when we get emails with so much joy and positive attitude.


-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: Central build runs out of file descriptors on devel/RStudio

[Mathieu Arnold]

Le 03/12/2017 à 03:30, Adam Weinberger a écrit :
>> On 2 Dec, 2017, at 18:57, Yuri  wrote:
>>
>> Build opens too many file descriptors, and fails:
>>
>> http://beefy5.nyi.freebsd.org/data/103i386-default/455387/logs/RStudio-1.1.385.log
>>
>> http://beefy6.nyi.freebsd.org/data/103amd64-default/455387/logs/RStudio-1.1.385.log
>>
>>
>> It looks like kern.maxfiles on beefy needs to be beefed up.
> Then MAKE_JOBS_NUMBER_LIMIT (or MAKE_JOBS_UNSAFE) would be my next step. If 
> it fails on the beefy builders, it's likely to fail on resource-starved 
> end-user boxes. The builders do many concurrent builds, but it's possible for 
> end-users to hit that level of activity too.


But the package builders don't use MAKE_JOBS, so it will not change
anything.


-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: Flavors *COMPLETELY* break the port system (synth and poudriere are useless)

[Bryan Drewery]

On 12/5/2017 1:53 AM, Aryeh Friedman wrote:
> 1. I decide to try poudriere since it seems to what people are raving
> about.   What a 'ing confusing mess it is use After deciding it
> is over kill I go to option 2


1 time setup:
  echo ZPOOL=zroot >> /usr/local/etc/poudriere.conf
  poudriere jail -c -j 11amd64 -v 11.1-RELEASE
  poudriere ports -c
After that:
  # edit /some/file and add your port list
  poudriere bulk -j 11amd64 -f /some/file

You typed 1612 characters in this email but poudriere would have taken
157 at a minimum.

Looking at
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-poudriere.html
it also agrees with my setup advice, very trivial.

There's this silly idea that Poudriere is hard to setup.  It's not
tinderbox which required maintaining an external database and migrations
on it and such.  I do agree Poudriere has option and command overload
which makes it confusing, but the official guide is to the point and
mostly simple (it needlessly uses -p and -z when not needed).
Customizing its options are something to be done optionally later.

I do like that synth supports upgrading the *HOST* more simply.  I want
to add such a feature to Poudriere as well eventually.

-- 
Regards,
Bryan Drewery
bdrewery@freenode/EFNet
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Flavors *COMPLETELY* break the port system (synth and poudriere are useless)

[Baho Utot]

On 12/05/17 04:53, Aryeh Friedman wrote:

First some background (my typical use cases for ports):

0. FreeBSD lilith 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321664: Fri Jul 28
23:35:18 EDT 2017 root@lilith:/usr/obj/usr/src/sys/GENERIC  amd64

1. Daily routine (current):

   cd /usr/src
   svn update (from 11.1-RELEASE)
   [make -DESTDIR=/ world kernel&& as needed]

   cd /usr/ports
   svn update (from HEAD)
   portmaster -ad
   [reboot if any Xorg/xfce or stuff in rc.d got modified]

2. I maintain devel/aegis (which as per Bug 219284 does not compile with
anything greater then GCC 5 [I don't have time to figure out how to patch
it is make it work {the upstream maintainer died a few years ago}]).

So what happens when I see UPDATING 20171130:

1. I decide to try poudriere since it seems to what people are raving
about.   What a 'ing confusing mess it is use After deciding it
is over kill I go to option 2

2. I installed synth (2.00) and *ATTEMPTED* to do a upgrade-system with the
following results (still not a successful run):

 a. Hard freezes the machine (not even a kernel panic) 4 times in a row

 b. Skips devel/aegis recompile because it can't understand the makefile
or something (see above).  *BUT* gives no clues as to why and gives me
nothing actionable on how to repair the port

3. The suggestion of using plainly old make install on each port is
unworkable because it is fundamentally error prone with my daily use case.

TL;DR;
Flavors 'ed up ports and there are no good ways/alternates for how
to use the ports collection for normal everyday users/maintainers



Welcome to the state of the art of FreeBSD
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: 32-bit powerpc system-clang based builds of devel/llvm40 and devel/llvm50: fails via "Host compiler appears to require libatomic, but cannot find it"

[Roman Divacky]

The cmake test just tries to compile:

#include 
std::atomic x;
int main() {
  return x;
}

What happens if you try to compile this small code with your host compiler?

Roman

On Tue, Dec 05, 2017 at 10:42:49AM -0800, Mark Millard wrote:
> [I experiment with system-clang based
> buildworld and/or buildkernel based
> TARGET_ARCH=powerpc64 and
> TARGET_ARCH=powerpc environments.]
> 
> For TARGET_ARCH=powerpc devel/llvm40 and
> devel/llvm50 get failure reports like:
> 
> -- Looking for __atomic_load_8 in atomic - not found
> CMake Error at cmake/modules/CheckAtomic.cmake:74 (message):
>   Host compiler appears to require libatomic, but cannot find it.
> Call Stack (most recent call first):
>   cmake/config-ix.cmake:307 (include)
>   CMakeLists.txt:582 (include)
> 
> 
> I had tried to avoid any need for 8-Byte atomics
> (among other things) by avoiding LIT, LLD, and LLDB:
> 
> # more /usr/local/etc/poudriere.d/options/devel_llvm50/options
> # This file is auto-generated by 'make config'.
> # Options for llvm50-5.0.0_1
> _OPTIONS_READ=llvm50-5.0.0_1
> _FILE_COMPLETE_OPTIONS_LIST=CLANG DOCS EXTRAS LIT LLD LLDB
> OPTIONS_FILE_SET+=CLANG
> OPTIONS_FILE_SET+=DOCS
> OPTIONS_FILE_SET+=EXTRAS
> OPTIONS_FILE_UNSET+=LIT
> OPTIONS_FILE_UNSET+=LLD
> OPTIONS_FILE_UNSET+=LLDB
> 
> # more /usr/local/etc/poudriere.d/options/devel_llvm40/options
> # This file is auto-generated by 'make config'.
> # Options for llvm40-4.0.1_1
> _OPTIONS_READ=llvm40-4.0.1_1
> _FILE_COMPLETE_OPTIONS_LIST=CLANG DOCS EXTRAS LIT LLD LLDB
> OPTIONS_FILE_SET+=CLANG
> OPTIONS_FILE_SET+=DOCS
> OPTIONS_FILE_SET+=EXTRAS
> OPTIONS_FILE_UNSET+=LIT
> OPTIONS_FILE_UNSET+=LLD
> OPTIONS_FILE_UNSET+=LLDB
> 
> For clang-based buildworld avoiding such things
> prevents running into the 8-Byte atomics based
> build failures:
> 
> WITH_LIBCPLUSPLUS=
> WITH_BINUTILS_BOOTSTRAP=
> WITH_ELFTOOLCHAIN_BOOTSTRAP=
> #WITH_CLANG_BOOTSTRAP=
> WITH_CLANG=
> WITH_CLANG_IS_CC=
> WITH_CLANG_FULL=
> WITH_CLANG_EXTRAS=
> WITH_LLD=
> # lldb requires missing atomic 8-byte operations for powerpc (non-64)
> WITHOUT_LLDB=
> #
> WITH_BOOT=
> 
> (Note: buildkernel currently fails.)
> 
> # clang++ --version
> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 
> 5.0.0svn)
> Target: powerpc-unknown-freebsd12.0
> Thread model: posix
> InstalledDir: /usr/bin
> 
> # uname -apKU
> FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT  r326192M  powerpc powerpc 
> 1200054 1200054
> 
> # svnlite info /usr/ports/ | grep "Re[plv]"
> Relative URL: ^/head
> Repository Root: https://svn.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 455204
> Last Changed Rev: 455204
> 
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
> ___
> freebsd-toolch...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Welcome flavors! portmaster now dead? synth?

[Bryan Drewery]

On 12/1/2017 9:59 AM, Kevin Oberman wrote:
> First, welcome flavors. It has been badly needed for a while and is going
> to clean up a couple of messes that have been plaguing the port system for
> a long time.

I plan to look at portupgrade + FLAVORS support in the next few weeks as
well.

-- 
Regards,
Bryan Drewery
bdrewery@freenode/EFNet
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Working on FLAVOR support in portmaster

[Bryan Drewery]

On 12/4/2017 11:35 PM, Stefan Esser wrote:
> Is it acceptable, to have portmaster stop supporting the old package system?
> AFAIK, there is no way that a modern ports tree with flavor support works
> with a non-PKG_NG infrastructure?

100% yes.
If someone needs pkg_* support for an older tree then they can simply
install a portmaster from that older tree.
Pkg has been the only tool since at least 10.0+ which itself has been
EOL since Feb 28 2015. If someone is still somehow depending on pkg_
tools by now with a current ports tree (HOW??) then they are definitely
on their own.

-- 
Regards,
Bryan Drewery
bdrewery@freenode/EFNet
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Working on FLAVOR support in portmaster

[Mark Linimon]

On Tue, Dec 05, 2017 at 08:42:27AM -0800, Chris H wrote:
> IMHO it might be a good idea to make a legacy branch, in the ports
> tree before gutting the pre-NG stuff.

Good lord, people.

The pre-NG stuff has Left The Building.  It is not coming back.

The last (even trivial) revision to the pkg_* codebase was Mon Aug 19
14:04:35 2013 UTC:

  https://svnweb.freebsd.org/base?view=revision=254525

The corresponding bsd.port.mk version was:

  https://svnweb.freebsd.org/ports?view=revision=324051

For comparison:

  ports is currently at r455604 [*]
  USES= had recently been introduced at r313517 Wed Mar 6 14:28:57
2013 UTC (4 years, 9 months ago)
  options handling had recently been reworked at r321785 Wed Jun 26
07:22:06 2013 UTC (4 years, 5 months ago)
  LIB_DEPENDS had recently been reworked at r322328 Fri Jul 5 14:10:55
2013 UTC (4 years, 5 months ago) by bapt
  staging came in at r327910 Mon Sep 23 05:56:35 2013 UTC (4 years,
2 months ago) 
  the warning about pkg_* EOL was r342537 Tue Feb 4 14:23:08 2014
UTC (3 years, 10 months ago) 
  and I'm not going to iterate over all the refactoring and bug-
fixing since that time.

(Most likely, pkg_* was not thoroughly tested since early 2013, so I've
included the first 4 big reworks above.)

If you want to look at the diffs to bsd.port.mk since the last time pkg_*
was even trivially maintained:

  https://svnweb.freebsd.org/ports/head/Mk/bsd.port.mk?r1=324051=455280

The diff is 5528 lines.  It's unreadable.

If you're staying with pkg_*, you're basically saying "I don't mind
running with something that hasn't really been QAed with those 5528 lines
of changes."

IMVVHO: madness.

I really don't have anything more I can say on the matter.

mcl

* Because I'm now annoyed, I'm going to do some math:

  455604 - 324051 = 131553

That's over One. Hundred. Thousand. Ports. Commits. Ago.

That's 7 pages of commits to bsd.port.mk itself, per svnweb.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Working on FLAVOR support in portmaster

[Rainer Hurling]

Am 05.12.2017 um 08:35 schrieb Stefan Esser:
> Am 05.12.17 um 00:43 schrieb Tatsuki Makino:
>> By the way, where is the clever way to update to flavor?
>> I am using portmaster.
> 
> I'm working on FLAVOR support in portmaster. My version did already build
> all updated ports, the FLAVOR parameter is passed to build sub-processes,
> but there is still some confusion between multiple flavored versions of the
> same port (installing the py27 version wants to deinstall the py36 version
> and vice versa), which I still have to fix.

Isn't the described behaviour (installing the py27 version wants to
deinstall the py36 version and vice versa) caused by the underlying
ports mechanisms? As far as I can see, portmaster gives exactly the
output, that also comes from using pure 'make deinstall' and 'make
reinstall'.

> I'm not sure that I have time to complete the fix today, but it is not too
> hard. Ports need to complement the port origin with the FLAVOR, where
> appropriate (e.g. when a flavored destination is found in MOVED). Already
> installed packages are annotated with "flavor" and that must be passed to
> the build command, when that port is updated. Most other logic in portmaster
> remains unaffected.
> 
> 
> My work version has all non PKG_NG support stripped, but that is mainly to
> not waste effort fixing irrelevant sub-routines.
> 
> Is it acceptable, to have portmaster stop supporting the old package system?
> AFAIK, there is no way that a modern ports tree with flavor support works
> with a non-PKG_NG infrastructure?
> 
> Regards, STefan

Many thanks for your efforts in bringing flavors into portmaster. Really
appreciated!

Regards,
Rainer
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Central build runs out of file descriptors on devel/RStudio

[Yuri]

On 12/02/17 18:30, Adam Weinberger wrote:

Then MAKE_JOBS_NUMBER_LIMIT (or MAKE_JOBS_UNSAFE) would be my next step. If it 
fails on the beefy builders, it's likely to fail on resource-starved end-user 
boxes. The builders do many concurrent builds, but it's possible for end-users 
to hit that level of activity too.



This is one way. But isn't it more reasonable to increase the limit on 
the servers so that such problems also don't occur for other projects?



Yuri

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Why XDG_DATA_HOME is set to ${WRKDIR}?

[Yuri]

I have the project that uses xdg-utils to install the desktop-related 
files. It installs them under $XDG_DATA_HOME into ${WRKDIR}.


Is this a mistake? Shouldn't it be ${STAGEDIR}${PREFIX}/share?


Yuri

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

32-bit powerpc lang/ruby23 build fails: [BUG] Segmentation fault

[Mark Millard]

[I experiment with system-clang based
buildworld and/or buildkernel based
TARGET_ARCH=powerpc64 and
TARGET_ARCH=powerpc environments.]


linking miniruby
generating encdb.h
/wrkdirs/usr/ports/lang/ruby23/work/ruby-2.3.5/tool/vpath.rb:18: [BUG] 
Segmentation fault at 0x256400cf
ruby 2.3.5p376 (2017-09-14 revision 59905) [powerpc-freebsd12]

-- Control frame information ---
c:0007 p: s:0042 e:41 CFUNC  :initialize
c:0006 p: s:0040 e:39 CFUNC  :open
c:0005 p: s:0038 e:37 CFUNC  :call
c:0004 p:0017 s:0033 e:32 METHOD 
/wrkdirs/usr/ports/lang/ruby23/work/ruby-2.3.5/tool/vpath.rb:18
c:0003 p:0024 s:0026 e:25 METHOD 
/wrkdirs/usr/ports/lang/ruby23/work/ruby-2.3.5/tool/vpath.rb:35
c:0002 p:0408 s:0021 E:001dcc EVAL   ./tool/generic_erb.rb:40 [FINISH]
c:0001 p: s:0002 E:000a88 (none) [FINISH]

-- Ruby level backtrace information 
./tool/generic_erb.rb:40:in `'
/wrkdirs/usr/ports/lang/ruby23/work/ruby-2.3.5/tool/vpath.rb:35:in `open'
/wrkdirs/usr/ports/lang/ruby23/work/ruby-2.3.5/tool/vpath.rb:18:in `search'
/wrkdirs/usr/ports/lang/ruby23/work/ruby-2.3.5/tool/vpath.rb:18:in `call'
/wrkdirs/usr/ports/lang/ruby23/work/ruby-2.3.5/tool/vpath.rb:18:in `open'
/wrkdirs/usr/ports/lang/ruby23/work/ruby-2.3.5/tool/vpath.rb:18:in `initialize'


# clang++ --version
FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 
5.0.0svn)
Target: powerpc-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin

(clang was used to buildworld. clang-based buildworld
for TARGET_ARCH=powerpc currently produces system
libraries that crash for any thrown C++ exception.
TARGET_ARCH=powerpc64 has the same issue.)

# uname -apKU
FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT  r326192M  powerpc powerpc 
1200054 1200054

# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: https://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 455204
Last Changed Rev: 455204

# svnlite status /usr/src/ | sort
?   /usr/src/sys/amd64/conf/GENERIC-DBG
?   /usr/src/sys/amd64/conf/GENERIC-NODBG
?   /usr/src/sys/arm/conf/GENERIC-DBG
?   /usr/src/sys/arm/conf/GENERIC-NODBG
?   /usr/src/sys/arm64/conf/GENERIC-DBG
?   /usr/src/sys/arm64/conf/GENERIC-NODBG
?   /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG
?   /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG
?   /usr/src/sys/powerpc/conf/GENERICvtsc-DBG
?   /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG
M   /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
M   /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp
M   /usr/src/crypto/openssl/crypto/armcap.c
M   /usr/src/lib/libkvm/kvm_powerpc.c
M   /usr/src/lib/libkvm/kvm_private.c
M   /usr/src/stand/defs.mk
M   /usr/src/stand/powerpc/boot1.chrp/Makefile
M   /usr/src/stand/powerpc/kboot/Makefile
M   /usr/src/sys/arm/allwinner/aw_usbphy.c
M   /usr/src/sys/arm64/arm64/identcpu.c
M   /usr/src/sys/conf/kmod.mk
M   /usr/src/sys/conf/ldscript.powerpc
M   /usr/src/sys/ddb/db_main.c
M   /usr/src/sys/ddb/db_script.c
M   /usr/src/sys/kern/subr_pcpu.c
M   /usr/src/sys/modules/dtb/allwinner/Makefile
M   /usr/src/sys/powerpc/aim/mmu_oea64.c
M   /usr/src/sys/powerpc/ofw/ofw_machdep.c
M   /usr/src/sys/powerpc/powerpc/interrupt.c
M   /usr/src/sys/powerpc/powerpc/mp_machdep.c
M   /usr/src/sys/powerpc/powerpc/trap.c


===
Mark Millard
markmi at dsl-only.net

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Working on FLAVOR support in portmaster

[Jeremy Lea]

Hi,

On Tue, Dec 05, 2017 at 08:35:55AM +0100, Stefan Esser wrote:
> Is it acceptable, to have portmaster stop supporting the old package system?
> AFAIK, there is no way that a modern ports tree with flavor support works
> with a non-PKG_NG infrastructure?

I also started working on this yesterday...  Looking at the code it is
probably also worth asking if portmaster needs to continue to support so
many binary package options.  Many of the options can be done directly
with 'pkg', and many of the use cases are probably better served by
poudriere, and many of them don't work with portmaster and pkgng anyway.

Regards,
  -Jeremy
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

32-bit powerpc system-clang based builds of devel/llvm40 and devel/llvm50: fails via "Host compiler appears to require libatomic, but cannot find it"

[Mark Millard]

[I experiment with system-clang based
buildworld and/or buildkernel based
TARGET_ARCH=powerpc64 and
TARGET_ARCH=powerpc environments.]

For TARGET_ARCH=powerpc devel/llvm40 and
devel/llvm50 get failure reports like:

-- Looking for __atomic_load_8 in atomic - not found
CMake Error at cmake/modules/CheckAtomic.cmake:74 (message):
  Host compiler appears to require libatomic, but cannot find it.
Call Stack (most recent call first):
  cmake/config-ix.cmake:307 (include)
  CMakeLists.txt:582 (include)


I had tried to avoid any need for 8-Byte atomics
(among other things) by avoiding LIT, LLD, and LLDB:

# more /usr/local/etc/poudriere.d/options/devel_llvm50/options
# This file is auto-generated by 'make config'.
# Options for llvm50-5.0.0_1
_OPTIONS_READ=llvm50-5.0.0_1
_FILE_COMPLETE_OPTIONS_LIST=CLANG DOCS EXTRAS LIT LLD LLDB
OPTIONS_FILE_SET+=CLANG
OPTIONS_FILE_SET+=DOCS
OPTIONS_FILE_SET+=EXTRAS
OPTIONS_FILE_UNSET+=LIT
OPTIONS_FILE_UNSET+=LLD
OPTIONS_FILE_UNSET+=LLDB

# more /usr/local/etc/poudriere.d/options/devel_llvm40/options
# This file is auto-generated by 'make config'.
# Options for llvm40-4.0.1_1
_OPTIONS_READ=llvm40-4.0.1_1
_FILE_COMPLETE_OPTIONS_LIST=CLANG DOCS EXTRAS LIT LLD LLDB
OPTIONS_FILE_SET+=CLANG
OPTIONS_FILE_SET+=DOCS
OPTIONS_FILE_SET+=EXTRAS
OPTIONS_FILE_UNSET+=LIT
OPTIONS_FILE_UNSET+=LLD
OPTIONS_FILE_UNSET+=LLDB

For clang-based buildworld avoiding such things
prevents running into the 8-Byte atomics based
build failures:

WITH_LIBCPLUSPLUS=
WITH_BINUTILS_BOOTSTRAP=
WITH_ELFTOOLCHAIN_BOOTSTRAP=
#WITH_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLD=
# lldb requires missing atomic 8-byte operations for powerpc (non-64)
WITHOUT_LLDB=
#
WITH_BOOT=

(Note: buildkernel currently fails.)

# clang++ --version
FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 
5.0.0svn)
Target: powerpc-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin

# uname -apKU
FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT  r326192M  powerpc powerpc 
1200054 1200054

# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: https://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 455204
Last Changed Rev: 455204


===
Mark Millard
markmi at dsl-only.net

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: devel/scons port fails to build, please contact maintainer

[Koen Martens]

Hi all,

On Mon, Dec 04, 2017 at 10:31:47PM +0100, Jan Beich wrote:
> Koen Martens  writes:
> 
> > I've installed poudriere through pkg, which gives me 3.1.22 at the
> > moment. I'll try 3.2 from ports tomorrow, wasn't aware that the binary
> > packages had an out of date version. I'll report back on whether that
> > worked or not.
> 
> poudriere 3.2.* has been available as binary package for >2 weeks.
> My guess, you're on /quarterly package set. If so you need to either
> switch to /latest set or stick to building quarterly branches.

Yep, i have a default 11.1 system where I do the poudriere building.
Installed from packages, which by default is on quarterly (I learned
from thread). I installed from ports, and with poudriere 3.2.2 all is
well.

I didn't explicitly choose latest/quarterly for pkg nor the ports
collection used by poudriere, so I guess what I did wrong was using
defaults for both host package repository and poudriere ports tree.

I guess I could've figured this out by myself, if i carefully read the
message in UPDATING and checked my poudriere version. Sorry for the
noise, and thanks all for your help!

- Koen Martens



signature.asc
Description: PGP signature

Re: Flavors *COMPLETELY* break the port system (synth and poudriere are useless)

[Jonathan Chen]

On 5 December 2017 at 22:53, Aryeh Friedman  wrote:
[...]
> 2. I installed synth (2.00) and *ATTEMPTED* to do a upgrade-system with the
> following results (still not a successful run):
>
> a. Hard freezes the machine (not even a kernel panic) 4 times in a row

synth runs parallel builds using multi-workers, and it can trash the
hard disk pretty hard as it uses swap for tmpfs. Reduce the number of
workers and/or jobs if you intend using the box during a build.

Cheers.
-- 
Jonathan Chen 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Last flavorless revision?

[Steve Kargl]

On Tue, Dec 05, 2017 at 09:13:38AM +0100, Mathieu Arnold wrote:
> Le 04/12/2017 à 18:33, Steve Kargl a écrit :
> > On Mon, Dec 04, 2017 at 11:49:30AM +, Alan Hicks wrote:
> >>
> >> On 02/12/2017 17:28, Steve Kargl wrote:
> >>> On Sat, Dec 02, 2017 at 02:06:32PM +0100, Christian Ullrich wrote:
>  * Steve Kargl wrote:
> 
> >>> Given that I asked about a specific revision number, it stands
> >>> to reason that I had already spent too much time wandering around
> >>> svnweb.freebsd.org.  An entry needs to be added to ports/UPDATING
> >>> to state which revision turns on flavors and by extension neuters
> >>> all port management tools except poudriere.  Four months from now
> >>> when users update a system finding that information by crawling
> >>> through svnweb.freebsd.org will be a challenge.
> >>>
> >> Your friend is subversion log search
> >> svn log --search FLAVORS svn://svn.FreeBSD.org
> >>
> >> r455205 | mat | 2017-11-30 15:33:29 + (Thu, 30 Nov 2017) | 13 lines
> >>
> >> Generic FLAVORS work.
> > This does not document the change in ports/UPDATING.  FreeBSD
> > users have been told to check {src/ports}/UPDATING for 20+
> > years.  A change that fundamentally changes the way users 
> > interact with ports/ should document.
> 
> 
> This did not change anything for the users, so there was nothing in
> UPDATING.
> 

Any user who uses portmaster runs into problems after 455205.
How does that "not change anything"?

-- 
Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Working on FLAVOR support in portmaster

[Chris H]

On Tue, 5 Dec 2017 03:33:10 -0800 "David Wolfskill"  said


On Tue, Dec 05, 2017 at 08:35:55AM +0100, Stefan Esser wrote:
> ...
> I'm working on FLAVOR support in portmaster. My version did already build
> all updated ports, the FLAVOR parameter is passed to build sub-processes,
> but there is still some confusion between multiple flavored versions of the
> same port (installing the py27 version wants to deinstall the py36 version
> and vice versa), which I still have to fix.

Thank you; that is encouraging.

> I'm not sure that I have time to complete the fix today, but it is not too
> hard. Ports need to complement the port origin with the FLAVOR, where
> appropriate (e.g. when a flavored destination is found in MOVED). Already
> installed packages are annotated with "flavor" and that must be passed to
> the build command, when that port is updated. Most other logic in portmaster
> remains unaffected.

That seems reasonable.

> My work version has all non PKG_NG support stripped, but that is mainly to
> not waste effort fixing irrelevant sub-routines.

Also reasonable, IMO.

> Is it acceptable, to have portmaster stop supporting the old package system?
> AFAIK, there is no way that a modern ports tree with flavor support works
> with a non-PKG_NG infrastructure?

I believe so: if for no other reason, one wishing to support such a
non-PKG_NG infrastructure can certainly use an older version of
portmaster.

The sensible side of me also agrees that this is probably a reasonable,
and efficient approach. But the practical side says there will likely
be some screaming on the mailing lists, once this change lands.
IMHO it might be a good idea to make a legacy branch, in the ports
tree before gutting the pre-NG stuff.

Just a thought. :)


> Regards, STefan
> 

Peace,
david


--Chris


___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Working on FLAVOR support in portmaster

[Matthieu Volat]

On Tue, 5 Dec 2017 08:35:55 +0100
Stefan Esser  wrote:

> Am 05.12.17 um 00:43 schrieb Tatsuki Makino:
> > By the way, where is the clever way to update to flavor?
> > I am using portmaster.  
> 
> I'm working on FLAVOR support in portmaster. My version did already build
> all updated ports, the FLAVOR parameter is passed to build sub-processes,
> but there is still some confusion between multiple flavored versions of the
> same port (installing the py27 version wants to deinstall the py36 version
> and vice versa), which I still have to fix.
> 
> I'm not sure that I have time to complete the fix today, but it is not too
> hard. Ports need to complement the port origin with the FLAVOR, where
> appropriate (e.g. when a flavored destination is found in MOVED). Already
> installed packages are annotated with "flavor" and that must be passed to
> the build command, when that port is updated. Most other logic in portmaster
> remains unaffected.
> 
> 
> My work version has all non PKG_NG support stripped, but that is mainly to
> not waste effort fixing irrelevant sub-routines.
> 
> Is it acceptable, to have portmaster stop supporting the old package system?
> AFAIK, there is no way that a modern ports tree with flavor support works
> with a non-PKG_NG infrastructure?
> 
> Regards, STefan

Ho, and here I was, almost ready to request some comments after playing a bit:

  
https://github.com/freebsd/portmaster/compare/master...mazhe:wip-flavors?expand=1

Regarding old pkg support, wasn't it removed from the repo master branch?


pgpEgNBrsxMHc.pgp
Description: OpenPGP digital signature

Re: Welcome flavors! portmaster now dead? synth?

[Dennis Glatting]

On Mon, 2017-12-04 at 18:10 +0100, Jan Beich wrote:
> Dennis Glatting  writes:
> 
> >  1) I am tired of port breakage. I am past tired of being told to
> > read
> > UPDATEs when UPDATEs often has limited information, including
> > install
> > conflicts. 
> > 
> >  2) "Error 70" on installs with no indication of where the error
> > was
> > incurred and thus requiring me to make with debug flags and then
> > dig
> > deep is past annoying. 
> 
> [...]
> > Further:
> > 
> > 1) Under FreeBSD I do not do binaries, rather I do source and I do
> > source for reasons. Under Linux, source is troublesome.
> 
> I'm curious what are those "reasons" that don't affect Linux. Those
> may
> be valid FreeBSD shortcomings unlike what you've listed above which
> is
> mainly about source vs. binary packages.

Source verses binaries are valid "reasons" and are based on application
and operation placement. 

With source, I can compile out optional  code (e.g., SQL hooks in
OpenLDAP) whereas binary packages are often compiled to be all things
to all people (i.e., more functionality is offered). Although one can
argue that inclusion of compile-time optional code into a binary is
only operationally enabled through a proper configuration, there are
problems with that argument:

 1) The compile-time optional code may not be truly disabled 
through configuration files,
 2) Some functions are enabled by default, and
 3) They represent threat vectors.

If you do not include compile-time optional code then reduced threat
vectors.

Linux is a series of trade offs. If application code is written with
CUDA then you have to support the application with all of its warts and
baggage. If I /have/ to do source under Linux then I have to do source
but I don't /want/ to do source because the process is often ugly.  

Another trade off, which annoys the hell out of me, is NetworkManager
verses other "helpful" tools. None of those tools are fun when doing
custom networking, which includes VLANs and IPv6 as if those are new
advanced concepts, and configuration is different across Linux
distributions including Debian Stretch and Raspberry PI3 although
they're running nearly the same version of Debian. 

It is maddening. Hulk want to smash!

With FreeBSD, I simply hack a few files in /etc and I'm good to go.
Also under FreeBSD, what I need to configure in /etc is often obvious
and I don't have to waddle through gobs of confusing, unrelated, and
often erroneous documents and Internet posts. FreeBSD isn't perfect but
FreeBSD has this useful thing called a Handbook.

I can, and do, enable IPTables in Linux and IPFW in FreeBSD for added 
protections but if a threat vector isn't there (i.e., not in the
binary) then there are less exploitable threat vectors - it's
discernible math at that point. Do I want to manage lists of IPTables
and IPFW? No. They get complex and create breakage paths.

When one is required to have heterogeneous infrastructures one wants
commonness and simplicity while at the same time not admitting to that
bottle of whiskey in one's desk drawer. I often strip stupid stuff,
such as NetworkManager, and life gets simpler and less migraine prone.

That all said, my response was based on the point of that the finite
resource sword cuts both ways. If one operating system increases my 
annoyance and another does not, there is a point where my bias leans.

Oh, and "hell no" to Windows. It's evil and I live across Lake
Sammamish from the Evil Empire.

-- 
Dennis Glatting
Numbers Skeptic
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Working on FLAVOR support in portmaster

[Adam Weinberger]

> On 5 Dec, 2017, at 0:35, Stefan Esser  wrote:
> 
> Am 05.12.17 um 00:43 schrieb Tatsuki Makino:
>> By the way, where is the clever way to update to flavor?
>> I am using portmaster.
> 
> I'm working on FLAVOR support in portmaster. My version did already build
> all updated ports, the FLAVOR parameter is passed to build sub-processes,
> but there is still some confusion between multiple flavored versions of the
> same port (installing the py27 version wants to deinstall the py36 version
> and vice versa), which I still have to fix.
> 
> I'm not sure that I have time to complete the fix today, but it is not too
> hard. Ports need to complement the port origin with the FLAVOR, where
> appropriate (e.g. when a flavored destination is found in MOVED). Already
> installed packages are annotated with "flavor" and that must be passed to
> the build command, when that port is updated. Most other logic in portmaster
> remains unaffected.
> 
> 
> My work version has all non PKG_NG support stripped, but that is mainly to
> not waste effort fixing irrelevant sub-routines.
> 
> Is it acceptable, to have portmaster stop supporting the old package system?
> AFAIK, there is no way that a modern ports tree with flavor support works
> with a non-PKG_NG infrastructure?
> 
> Regards, STefan

Thank you for doing the work!!!

Yes, old package (PKG_OG?) support should be removed. Even if portmaster 
supported it, the ports tree itself doesn't.

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.org

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Flavors *COMPLETELY* break the port system (synth and poudriere are useless)

[Lars Engels]

On Tue, Dec 05, 2017 at 04:53:07AM -0500, Aryeh Friedman wrote:
> First some background (my typical use cases for ports):
> 
> 0. FreeBSD lilith 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321664: Fri Jul 28
> 23:35:18 EDT 2017 root@lilith:/usr/obj/usr/src/sys/GENERIC  amd64
> 
> 1. Daily routine (current):
> 
>   cd /usr/src
>   svn update (from 11.1-RELEASE)
>   [make -DESTDIR=/ world kernel&& as needed]
> 
>   cd /usr/ports
>   svn update (from HEAD)
>   portmaster -ad
>   [reboot if any Xorg/xfce or stuff in rc.d got modified]
> 
> 2. I maintain devel/aegis (which as per Bug 219284 does not compile with
> anything greater then GCC 5 [I don't have time to figure out how to patch
> it is make it work {the upstream maintainer died a few years ago}]).
> 
> So what happens when I see UPDATING 20171130:
> 
> 1. I decide to try poudriere since it seems to what people are raving
> about.   What a 'ing confusing mess it is use After deciding it
> is over kill I go to option 2

[...]

What's wrong with [1]?

[1] 
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-poudriere.html
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Working on FLAVOR support in portmaster

[George Mitchell]

On 12/05/17 02:35, Stefan Esser wrote:
> [...]
> Is it acceptable, to have portmaster stop supporting the old package system?
> AFAIK, there is no way that a modern ports tree with flavor support works
> with a non-PKG_NG infrastructure?
> 
> Regards, STefan
> [...]
One vote here for dropping old package support.-- George



signature.asc
Description: OpenPGP digital signature

Re: Last flavorless revision?

[George Mitchell]

On 12/05/17 03:13, Mathieu Arnold wrote:
> Le 04/12/2017 à 18:33, Steve Kargl a écrit :
>> [...]
>> This does not document the change in ports/UPDATING.  FreeBSD
>> users have been told to check {src/ports}/UPDATING for 20+
>> years.  A change that fundamentally changes the way users 
>> interact with ports/ should document.
> 
> 
> This did not change anything for the users, so there was nothing in
> UPDATING.
I think there is some cognitive dissonance here on who the users are.
I would be astonished if any end user of a FreeBSD system had ever
read the contents of /usr/ports/UPDATING except for the system
administrator, and administrators are definitely affected (to say
the least).   -- George



signature.asc
Description: OpenPGP digital signature

Re: Missing fixes for various ports in Q4 branch?

[Vlad K.]

On 2017-12-05 12:32, Patrick M. Hausen wrote:


We relied on just updating the branch every night and running
poudriere ... looks
like I should implement something around pkg audit that sends us daily 
status

reports.


Yes, but note that pkgaudit depends on VuXML which is also not up to 
date (it's on the best effort basis just like MFH). There's some effort 
going on to automate CVE entries, but until that's implemented (and if 
at all, as automation depends on CPE which many ports do not have), I'd 
suggest tracking CVEs independently in order to be best informed. 
Following linux distros secvuln announcements (Canonical's, RedHat's, 
Debian's) is a good start, so is being subscribed to oss-seclist, and of 
course the NVD or Mitre feeds themselves.


* https://usn.ubuntu.com/usn/rss.xml
* https://www.debian.org/security/dsa
* https://cve.mitre.org/

It'd be very helpful if bug reports would be filed on FreeBSD's bugzilla 
(https://bugs.freebsd.org) tagged with keyword "security" if any 
undocumented vulns (not submitted to VuXML) are found.




--
Vlad K.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Working on FLAVOR support in portmaster

[David Wolfskill]

On Tue, Dec 05, 2017 at 08:35:55AM +0100, Stefan Esser wrote:
> ...
> I'm working on FLAVOR support in portmaster. My version did already build
> all updated ports, the FLAVOR parameter is passed to build sub-processes,
> but there is still some confusion between multiple flavored versions of the
> same port (installing the py27 version wants to deinstall the py36 version
> and vice versa), which I still have to fix.

Thank you; that is encouraging.

> I'm not sure that I have time to complete the fix today, but it is not too
> hard. Ports need to complement the port origin with the FLAVOR, where
> appropriate (e.g. when a flavored destination is found in MOVED). Already
> installed packages are annotated with "flavor" and that must be passed to
> the build command, when that port is updated. Most other logic in portmaster
> remains unaffected.

That seems reasonable.

> My work version has all non PKG_NG support stripped, but that is mainly to
> not waste effort fixing irrelevant sub-routines.

Also reasonable, IMO.

> Is it acceptable, to have portmaster stop supporting the old package system?
> AFAIK, there is no way that a modern ports tree with flavor support works
> with a non-PKG_NG infrastructure?

I believe so: if for no other reason, one wishing to support such a
non-PKG_NG infrastructure can certainly use an older version of
portmaster.

> Regards, STefan
> 

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Trump is an incompetent, lying bully who is unfit for any public office.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Missing fixes for various ports in Q4 branch? (was: MySQL 5.6)

[Patrick M. Hausen]

> Am 05.12.2017 um 12:05 schrieb Patrick M. Hausen :
> PHP 5.6 is 5.6.31 in Q4 with CVE-2016-1283 and 5.6.32 in HEAD.
> Update to HEAD 4 weeks ago.
> 
> Curl is behind, too - though this fix was committed to HEAD just 2 days ago.

And graphics/OpenEXR received security updates in HEAD 4 days ago.

I assumed merging from HEAD to quarterly for security issues was automatic?

We relied on just updating the branch every night and running poudriere ... 
looks
like I should implement something around pkg audit that sends us daily status
reports.

Kind regards,
Patrick
-- 
punkt.de GmbH   Internet - Dienstleistungen - Beratung
Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100
76133 Karlsruhe i...@punkt.de   http://punkt.de
AG Mannheim 108285  Gf: Juergen Egeling

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Missing fixes for various ports in Q4 branch? (was: MySQL 5.6)

[Patrick M. Hausen]

Hi all,

> Am 05.12.2017 um 11:55 schrieb Kurt Jaeger :
> 
> Hi!
> 
>> I thought quarterly ports branches would receive security fixes from
>> HEAD but no other version bumps.
>> 
>> If this is correct, then why is MySQL 5.6 in Q4 one version behind HEAD
>> (updated 6 weeks ago) and with all the critical security issues still 
>> present?
> 
> Maintainer just committed the merge from HEAD to quarterly.
> 
> Thanks for the heads-up. Sometimes things slip through.

OK ... in that case ...

PHP 5.6 is 5.6.31 in Q4 with CVE-2016-1283 and 5.6.32 in HEAD.
Update to HEAD 4 weeks ago.

Curl is behind, too - though this fix was committed to HEAD just 2 days ago.


I'll routinely use `pkg audit` after building a new master image for our hosting
from now on.


Kind regards,
Patrick
-- 
punkt.de GmbH   Internet - Dienstleistungen - Beratung
Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100
76133 Karlsruhe i...@punkt.de   http://punkt.de
AG Mannheim 108285  Gf: Juergen Egeling

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Missing fixes for mysql56-server in Q4 branch?

[Kurt Jaeger]

Hi!

> I thought quarterly ports branches would receive security fixes from
> HEAD but no other version bumps.
> 
> If this is correct, then why is MySQL 5.6 in Q4 one version behind HEAD
> (updated 6 weeks ago) and with all the critical security issues still present?

Maintainer just committed the merge from HEAD to quarterly.

Thanks for the heads-up. Sometimes things slip through.

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Working on FLAVOR support in portmaster

[Thomas Mueller]

> On 05.12.2017 08:35, Stefan Esser wrote:
> > Am 05.12.17 um 00:43 schrieb Tatsuki Makino:
> > > By the way, where is the clever way to update to flavor?
> > > I am using portmaster.

> > I'm working on FLAVOR support in portmaster. My version did already build
> > all updated ports, the FLAVOR parameter is passed to build sub-processes,
> > but there is still some confusion between multiple flavored versions of the
> > same port (installing the py27 version wants to deinstall the py36 version
> > and vice versa), which I still have to fix.

> Great news. I was starting today and just read your email. Lucky me :D

> > My work version has all non PKG_NG support stripped, but that is mainly to
> > not waste effort fixing irrelevant sub-routines.

> > Is it acceptable, to have portmaster stop supporting the old package system?
> > AFAIK, there is no way that a modern ports tree with flavor support works
> > with a non-PKG_NG infrastructure?

> This was something i aimed for in portmaster 2 since many changes were very
> subtle and there is no test-suite.

> But if there are some volunteers to test, i'm fine with it right now.

> Greetings,
> Torsten

As far as I know, no supported version of FreeBSD supports the old pkg_* tools, 
it's all pkgng.

So I can't see any need for portmaster to support the pre-pkgng infrastructure.

Tom

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Flavors *COMPLETELY* break the port system (synth and poudriere are useless)

[Aryeh Friedman]

First some background (my typical use cases for ports):

0. FreeBSD lilith 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321664: Fri Jul 28
23:35:18 EDT 2017 root@lilith:/usr/obj/usr/src/sys/GENERIC  amd64

1. Daily routine (current):

  cd /usr/src
  svn update (from 11.1-RELEASE)
  [make -DESTDIR=/ world kernel&& as needed]

  cd /usr/ports
  svn update (from HEAD)
  portmaster -ad
  [reboot if any Xorg/xfce or stuff in rc.d got modified]

2. I maintain devel/aegis (which as per Bug 219284 does not compile with
anything greater then GCC 5 [I don't have time to figure out how to patch
it is make it work {the upstream maintainer died a few years ago}]).

So what happens when I see UPDATING 20171130:

1. I decide to try poudriere since it seems to what people are raving
about.   What a 'ing confusing mess it is use After deciding it
is over kill I go to option 2

2. I installed synth (2.00) and *ATTEMPTED* to do a upgrade-system with the
following results (still not a successful run):

a. Hard freezes the machine (not even a kernel panic) 4 times in a row

b. Skips devel/aegis recompile because it can't understand the makefile
or something (see above).  *BUT* gives no clues as to why and gives me
nothing actionable on how to repair the port

3. The suggestion of using plainly old make install on each port is
unworkable because it is fundamentally error prone with my daily use case.

TL;DR;
Flavors 'ed up ports and there are no good ways/alternates for how
to use the ports collection for normal everyday users/maintainers
-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Working on FLAVOR support in portmaster

[Torsten Zuehlsdorff]

Aloha Stefan,
On 05.12.2017 08:35, Stefan Esser wrote:

Am 05.12.17 um 00:43 schrieb Tatsuki Makino:

By the way, where is the clever way to update to flavor?
I am using portmaster.


I'm working on FLAVOR support in portmaster. My version did already build
all updated ports, the FLAVOR parameter is passed to build sub-processes,
but there is still some confusion between multiple flavored versions of the
same port (installing the py27 version wants to deinstall the py36 version
and vice versa), which I still have to fix.


Great news. I was starting today and just read your email. Lucky me :D


My work version has all non PKG_NG support stripped, but that is mainly to
not waste effort fixing irrelevant sub-routines.

Is it acceptable, to have portmaster stop supporting the old package system?
AFAIK, there is no way that a modern ports tree with flavor support works
with a non-PKG_NG infrastructure?


This was something i aimed for in portmaster 2 since many changes were 
very subtle and there is no test-suite.


But if there are some volunteers to test, i'm fine with it right now.

Greetings,
Torsten
--
Support me at:
https://www.patreon.com/TorstenZuehlsdorff
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Last flavorless revision?

[Steven Hartland]

On 05/12/2017 08:13, Mathieu Arnold wrote:

Le 04/12/2017 à 18:33, Steve Kargl a écrit :

On Mon, Dec 04, 2017 at 11:49:30AM +, Alan Hicks wrote:

On 02/12/2017 17:28, Steve Kargl wrote:

On Sat, Dec 02, 2017 at 02:06:32PM +0100, Christian Ullrich wrote:

* Steve Kargl wrote:


Given that I asked about a specific revision number, it stands
to reason that I had already spent too much time wandering around
svnweb.freebsd.org.  An entry needs to be added to ports/UPDATING
to state which revision turns on flavors and by extension neuters
all port management tools except poudriere.  Four months from now
when users update a system finding that information by crawling
through svnweb.freebsd.org will be a challenge.


Your friend is subversion log search
svn log --search FLAVORS svn://svn.FreeBSD.org

r455205 | mat | 2017-11-30 15:33:29 + (Thu, 30 Nov 2017) | 13 lines

Generic FLAVORS work.

This does not document the change in ports/UPDATING.  FreeBSD
users have been told to check {src/ports}/UPDATING for 20+
years.  A change that fundamentally changes the way users
interact with ports/ should document.


This did not change anything for the users, so there was nothing in
UPDATING.

That's not true, for example it meant there was a minimum version 
requirement for poudriere without which it would fail to build any 
python packages, so if nothing else that should have been mentioned.


    Regards
    Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Welcome flavors! portmaster now dead? synth?

[Steven Hartland]

On 05/12/2017 04:51, Michelle Sullivan wrote:

Steven Hartland wrote:
On Mon, 4 Dec 2017 at 03:02, Michelle Sullivan  
wrote:



You mean if you're not into security or part of a security company stay
on quarterly, but if you need to keep patched up because you are in the
top 100 of most attacked sites/companies in the world, deploy a team of
people to patch security issues and run your own ports tree because
breakage on HEAD is often and when you need it the least and quarterly
doesn't guarantee it'll even work/compile and nearly never gets 
security

patches.


Sorry, but that's the truth of it and the reason I no longer use 
FreeBSD

or the Ports tree, instead using a derivative of each which is a lot
more stable and patched against security issues within hours of them
being identified.


This has not been our experience here, we’ve run our own ports tree from
HEAD for many years and while we’ve had some internal patches that need
fixing on update, thats always been down to us not keeping them up to 
date

with changes.


We were using HEAD, not a local copy that we could put patches in 
(that was the issue - we'd submit patches up and find them not applied 
for months in some cases.)
That's really unfortunate and I don't think you're alone, bringing in 
more resources to ports something that needs to be worked on.


Sure we could have got lucky but it does mean that such a blanket 
statement

is not valid for everyone’s use case.


I think you'll find using HEAD (as in the raw HEAD) not just a local 
copy with local patches it probably does ring true a lot - that said, 
didn't really bite me badly until the decision to force user changes 
by breaking the existing system (for me that was pkg_* -> pkgng) for 
others.. well they can say if they dare to chip in.
pkg -> pkgng was a little bit bumpy at the start but the results have 
been very much worth it.




I’m not sure if it’s possible but if you’re already allocating 
resources to

help handle security patches could that not be something that the wider
user base could benefit from via helping the secteam, if its turnaround
time on security patches you’re highlighting as an issue here?



Not working on FreeBSD now, the team deals with all in house OSes, 
FreeBSD is not deployed here anymore except on legacy machines that 
are being replaced (and I'm surprised there are any left now.)



Sorry to hear that.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Missing fixes for mysql56-server in Q4 branch?

[Patrick M. Hausen]

Hi all,

I thought quarterly ports branches would receive security fixes from
HEAD but no other version bumps.

If this is correct, then why is MySQL 5.6 in Q4 one version behind HEAD
(updated 6 weeks ago) and with all the critical security issues still present?

https://svnweb.freebsd.org/ports/head/databases/mysql56-server/
https://svnweb.freebsd.org/ports/branches/2017Q4/databases/mysql56-server/

http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html#AppendixMSQL

Thanks for clarifying,
Patrick
-- 
punkt.de GmbH   Internet - Dienstleistungen - Beratung
Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100
76133 Karlsruhe i...@punkt.de   http://punkt.de
AG Mannheim 108285  Gf: Juergen Egeling

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Last flavorless revision?

[Mathieu Arnold]

Le 04/12/2017 à 18:33, Steve Kargl a écrit :
> On Mon, Dec 04, 2017 at 11:49:30AM +, Alan Hicks wrote:
>>
>> On 02/12/2017 17:28, Steve Kargl wrote:
>>> On Sat, Dec 02, 2017 at 02:06:32PM +0100, Christian Ullrich wrote:
 * Steve Kargl wrote:

>>> Given that I asked about a specific revision number, it stands
>>> to reason that I had already spent too much time wandering around
>>> svnweb.freebsd.org.  An entry needs to be added to ports/UPDATING
>>> to state which revision turns on flavors and by extension neuters
>>> all port management tools except poudriere.  Four months from now
>>> when users update a system finding that information by crawling
>>> through svnweb.freebsd.org will be a challenge.
>>>
>> Your friend is subversion log search
>> svn log --search FLAVORS svn://svn.FreeBSD.org
>>
>> r455205 | mat | 2017-11-30 15:33:29 + (Thu, 30 Nov 2017) | 13 lines
>>
>> Generic FLAVORS work.
> This does not document the change in ports/UPDATING.  FreeBSD
> users have been told to check {src/ports}/UPDATING for 20+
> years.  A change that fundamentally changes the way users 
> interact with ports/ should document.


This did not change anything for the users, so there was nothing in
UPDATING.


-- 
Mathieu Arnold




signature.asc
Description: OpenPGP digital signature

Re: Working on FLAVOR support in portmaster

[Milan Obuch]

On Tue, 5 Dec 2017 08:35:55 +0100
Stefan Esser  wrote:

> Am 05.12.17 um 00:43 schrieb Tatsuki Makino:
> > By the way, where is the clever way to update to flavor?
> > I am using portmaster.  
> 
> I'm working on FLAVOR support in portmaster. My version did already
> build all updated ports, the FLAVOR parameter is passed to build
> sub-processes, but there is still some confusion between multiple
> flavored versions of the same port (installing the py27 version wants
> to deinstall the py36 version and vice versa), which I still have to
> fix.
>

Thank you! Great news.

> I'm not sure that I have time to complete the fix today, but it is
> not too hard. Ports need to complement the port origin with the
> FLAVOR, where appropriate (e.g. when a flavored destination is found
> in MOVED). Already installed packages are annotated with "flavor" and
> that must be passed to the build command, when that port is updated.
> Most other logic in portmaster remains unaffected.
>

As I understand it, portmaster is kind of wrapper around ports
infrastructure. What makes it complicated is a good number corner cases
which are not easy to handle right.

In my experience, even unaltered still kind of works for me with recet
port tree. I did even upgrade some python ports with it, so chances are
it could be done.

> My work version has all non PKG_NG support stripped, but that is
> mainly to not waste effort fixing irrelevant sub-routines.
> 
> Is it acceptable, to have portmaster stop supporting the old package
> system? AFAIK, there is no way that a modern ports tree with flavor
> support works with a non-PKG_NG infrastructure?
> 

This is not easy to tell... Is there still interest in old pkg_tools?
In my opinion, old pkg_tools should be in history (and I know I did use
them as long as it was kind of working before moving to current pkg).
How much of portmaster code deals with this legacy tools? Removing this
code could have positive effect of less code to deal with means less
space for bugs... Or portmaster-legacy port could be created, if there
is real interest.

Regards,
Milan
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"