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?
[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"
[bountysource] Add FreeBSD support to electron
Just FYI: https://www.bountysource.com/issues/29075473-add-freebsd-support-to-electron -- Iblis Lin 林峻頤 GitHub: https://github.com/iblis17 signature.asc Description: OpenPGP digital signature
Debugging a crash
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
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&revision=254525 The corresponding bsd.port.mk version was: https://svnweb.freebsd.org/ports?view=revision&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&r2=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)
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)
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
> 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)
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"
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 -fdebug-compilatio
Re: Working on FLAVOR support in portmaster
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)
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)
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
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)
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)
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&&etcupdate&&reboot 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"
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?
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
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
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&revision=254525 The corresponding bsd.port.mk version was: https://svnweb.freebsd.org/ports?view=revision&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&r2=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
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
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}?
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
[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
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"
[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
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)
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?
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
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
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?
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
> 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)
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&&etcupdate&&reboot 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
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?
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?
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
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)
> 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)
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?
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
> 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)
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&&etcupdate&&reboot 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
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?
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?
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?
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?
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
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"