Re: thunderbird build error
Hi! > I recently updated my port build machine to 11.2-RELEASE. I'm in the > process of recompiling my (previously) 10.4-based ports to 11.2, and > perhaps I shouldn't be trying to do this incrementally. No, the incremental rebuild will not work in most cases. Configure poudriere, build all the ports in poudriere, then use the generated ports to pkg upgrade... Much cleaner and almost no downtime. -- p...@freebsd.org +49 171 3101372 2 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"
thunderbird build error
I recently updated my port build machine to 11.2-RELEASE. I'm in the process of recompiling my (previously) 10.4-based ports to 11.2, and perhaps I shouldn't be trying to do this incrementally. But the build for thunderbird fails at ports revision 487523 with MAKE_JOBS_UNSAFE in /usr/ports/mail/thunderbird/work/.build/toolkit/library/rust thus: gmake[1]: Entering directory '/usr/ports/mail/thunderbird/work/.build/toolkit/library/rust' gmake[1]: Nothing to be done for 'pre-export'. gmake[1]: Leaving directory '/usr/ports/mail/thunderbird/work/.build/toolkit/library/rust' gmake[1]: Entering directory '/usr/ports/mail/thunderbird/work/.build/toolkit/library/rust' gmake[1]: Nothing to be done for 'export'. gmake[1]: Leaving directory '/usr/ports/mail/thunderbird/work/.build/toolkit/library/rust' gmake[1]: Entering directory '/usr/ports/mail/thunderbird/work/.build/toolkit/library/rust' force-cargo-library-build env RUSTC_BOOTSTRAP=1 RUSTFLAGS='-C opt-level=2 ' CARGO_TARGET_DIR=/usr/ports/mail/thunderbird/work/.build/toolkit/library RUSTC=/usr/local/bin/rustc MOZ_SRC=/usr/ports/mail/thunderbird/work/thunderbird-60.4.0 MOZ_DIST=/usr/ports/mail/thunderbird/work/.build/di st LIBCLANG_PATH="/usr/local/llvm70/lib" CLANG_PATH="/usr/local/llvm70/bin/clang" PKG_CONFIG_ALLOW_CROSS=1 RUST_BACKTRACE=full MOZ_TOPOBJDIR=/usr/ports/mail/thunderbird/work/.build MOZ_CARGO_WRAP_LDFLAGS="-pthread -Wl,--as-needed -B/usr/local/bin -Wl,-z,noexecsta ck -Wl,-z,text -Wl,-z,relro -Wl,--build-id -Wl,-rpath-link,/usr/ports/mail/thunderbird/work/.build/dist/bin -Wl,-rpath-link,/usr/local/lib" MOZ_CARGO_WRAP_LD=" /usr/local/bin/clang70 -std=gnu99" CARGO_TARGET_X86_64_UNKNOWN_FREEBSD_LINKER=/usr/ports/mail/thunderbir d/work/thunderbird-60.4.0/build/cargo-linker /usr/local/bin/cargo rustc --release --frozen --manifest-path /usr/ports/mail/thunderbird/work/thunderbird-60.4.0/toolkit/library/rust/Cargo.toml --lib --target=x86_64-unknown-freebsd --features "servo bindgen quantum_ render simd-accel no-static-ideograph-encoder-tables" -- -C lto Compiling style v0.0.1 (/usr/ports/mail/thunderbird/work/thunderbird-60.4.0/servo/components/style) d-script-build` (exit code: 101) --- stdout cargo:rerun-if-changed=build.rs cargo:out_dir=/usr/ports/mail/thunderbird/work/.build/toolkit/library/x86_64-unknown-freebsd/release/build/style-0c712cf90ff81f55/out cargo:rerun-if-changed=properties/properties.mako.rs cargo:rerun-if-changed=properties/Mako-0.9.1.zip cargo:rerun-if-changed=properties/computed_value_flags.rs cargo:rerun-if-changed=properties/gecko.mako.rs cargo:rerun-if-changed=properties/helpers/animated_properties.mako.rs cargo:rerun-if-changed=properties/data.py cargo:rerun-if-changed=properties/helpers.mako.rs cargo:rerun-if-changed=properties/shorthand/border.mako.rs cargo:rerun-if-changed=properties/shorthand/margin.mako.rs cargo:rerun-if-changed=properties/shorthand/serialize.mako.rs cargo:rerun-if-changed=properties/shorthand/mask.mako.rs cargo:rerun-if-changed=properties/shorthand/background.mako.rs cargo:rerun-if-changed=properties/shorthand/column.mako.rs cargo:rerun-if-changed=properties/shorthand/font.mako.rs cargo:rerun-if-changed=properties/shorthand/inherited_text.mako.rs cargo:rerun-if-changed=properties/shorthand/text.mako.rs cargo:rerun-if-changed=properties/shorthand/box.mako.rs cargo:rerun-if-changed=properties/shorthand/inherited_svg.mako.rs cargo:rerun-if-changed=properties/shorthand/padding.mako.rs cargo:rerun-if-changed=properties/shorthand/outline.mako.rs cargo:rerun-if-changed=properties/shorthand/list.mako.rs cargo:rerun-if-changed=properties/shorthand/position.mako.rs cargo:rerun-if-changed=properties/declaration_block.rs cargo:rerun-if-changed=properties/properties.html.mako cargo:rerun-if-changed=properties/longhand/border.mako.rs cargo:rerun-if-changed=properties/longhand/margin.mako.rs cargo:rerun-if-changed=properties/longhand/pointing.mako.rs cargo:rerun-if-changed=properties/longhand/background.mako.rs cargo:rerun-if-changed=properties/longhand/counters.mako.rs cargo:rerun-if-changed=properties/longhand/column.mako.rs cargo:rerun-if-changed=properties/longhand/font.mako.rs cargo:rerun-if-changed=properties/longhand/inherited_text.mako.rs cargo:rerun-if-changed=properties/longhand/inherited_box.mako.rs cargo:rerun-if-changed=properties/longhand/text.mako.rs cargo:rerun-if-changed=properties/longhand/box.mako.rs cargo:rerun-if-changed=properties/longhand/svg.mako.rs cargo:rerun-if-changed=properties/longhand/inherited_svg.mako.rs cargo:rerun-if-changed=properties/longhand/padding.mako.rs cargo:rerun-if-changed=properties/longhand/outline.mako.rs cargo:rerun-if-changed=properties/longhand/color.mako.rs cargo:rerun-if-changed=properties/longhand/list.mako.rs cargo:rerun-if-changed=properties/longhand/table.mako.rs cargo:rerun-if-changed=properties/longhand/position.mako.rs cargo:rerun-if-changed=properties/longhand/inherited_table.mako.rs cargo:rerun-if-changed=properties/longhand/ui.mako.rs
Re: vulnerabilities bogus error
Dimitry Andric wrote: On 14 Dec 2018, at 22:40, Ernie Luzar wrote: Trying to update my port. During make install get a bunch of bogus error messages about the port having vulnerabilities. I know this to not be the case. The first message says pkg-static; unable to open vulnxml file (null): Invalid argument This is a new fresh install of RELEASE 12.0. How do I manually fetch this vulnxml file or where should I "touch" to create it? Run "pkg audit -F". -Dimitry Yep that took care of the problem. Thank you. ___ 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: vulnerabilities bogus error
Ernie Luzar wrote on 2018/12/15 15:22: Walter Schwarzenfeld wrote: https://vuxml.freebsd.org/freebsd/vuln.xml.bz2 What path is this file suppose to be uncompressed into? /var/db/pkg/vuln.xml But isn't "pkg audit -F" enough? Miroslav Lachman ___ 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: vulnerabilities bogus error
On 14 Dec 2018, at 22:40, Ernie Luzar wrote: > > Trying to update my port. During make install get a bunch of bogus error > messages about the port having vulnerabilities. I know this to not be the > case. The first message says > pkg-static; unable to open vulnxml file (null): Invalid argument > > This is a new fresh install of RELEASE 12.0. How do I manually fetch this > vulnxml file or where should I "touch" to create it? Run "pkg audit -F". -Dimitry signature.asc Description: Message signed with OpenPGP
Re: vulnerabilities bogus error
Walter Schwarzenfeld wrote: https://vuxml.freebsd.org/freebsd/vuln.xml.bz2 What path is this file suppose to be uncompressed into? ___ 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: dependency loop in editors/vim with GTK3 option
> There is a dependency recursion loop in the build process for editors/vim > > > if one selects the GTK3 config menu option. The only way I've found so far to > get around this is to choose the GTK2 option instead. > With GTK3 selected, graphics/librsvg2 becomes a dependency, which, in > turn, is dependent upon lang/vala. lang/vala depends upon devel/dconf, which > depends upon devel/gconf2. devel/gconf2 depends upon graphics/graphviz, which > depends upon lang/vala! The recursion occurs there and was found by following > the instructions in UPDATING for the upgrade to perl5.28 when using > portmaster. > The command shown in the instructions is "portmaster -f", so the -f forces all > dependencies and dependent ports to be rebuilt. > As nearly as I can see, this dependency recursion loop breaks any port > involving lang/vala when portmaster -f is used. In the case of editors/vim, > a usable workaround is to choose gtk2 instead of gtk3, but for many other > ports, the perl upgrade's admonition to rebuilt ports that depend upon the > perl library to omit -f when using portmaster while providing portmaster a > complete list of all ports to be built. Provided an acceptable version > of lang/vala is already installed, it will be used, and the dependency loop > gets skipped over because there is no need to build lang/vala. Of course, > if one does that, there is no guarantee that the resulting binaries installed > for any of the ports in the recursion loop will function properly, given that > they may be based upon obsolete versions of the other ports in the loop. > > Scott Bennett, Comm. ASMELG, CFIAG > I have just installed lang/vala from ports and everything went fine. I have checked lang/vala's dependencies with "make all-depends-list" and devel/dconf is not listed. I suggest you try installing lang/vala from ports after having updated your ports tree. If you still get the problem, then you should open a bug report on https://bugs.freebsd.org/bugzilla/ Start your bug report summary with "lang/vala: " so that the port maintainer automatically gets notification of the report and anyone can find your PR easily. Lorenzo Salvadore. ___ 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: dependency loop in editors/vim with GTK3 option
On Sat, Dec 15, 2018 at 2:24 AM Scott Bennett wrote: > > There is a dependency recursion loop in the build process for editors/vim > if one selects the GTK3 config menu option. The only way I've found so far to > get around this is to choose the GTK2 option instead. > With GTK3 selected, graphics/librsvg2 becomes a dependency, which, in > turn, is dependent upon lang/vala. lang/vala depends upon devel/dconf, which > depends upon devel/gconf2. devel/gconf2 depends upon graphics/graphviz, which > depends upon lang/vala! The recursion occurs there and was found by following > the instructions in UPDATING for the upgrade to perl5.28 when using > portmaster. > The command shown in the instructions is "portmaster -f", so the -f forces all > dependencies and dependent ports to be rebuilt. > As nearly as I can see, this dependency recursion loop breaks any port > involving lang/vala when portmaster -f is used. In the case of editors/vim, > a usable workaround is to choose gtk2 instead of gtk3, but for many other > ports, the perl upgrade's admonition to rebuilt ports that depend upon the > perl library to omit -f when using portmaster while providing portmaster a > *complete list* of all ports to be built. Provided an acceptable version > of lang/vala is already installed, it will be used, and the dependency loop > gets skipped over because there is no need to build lang/vala. Of course, > if one does that, there is no guarantee that the resulting binaries installed > for any of the ports in the recursion loop will function properly, given that > they may be based upon obsolete versions of the other ports in the loop. Hi Scott, Thanks for the report. A dependency loop is certainly a distressing appearance! It can occur when non-default OPTIONS are set, but should never occur with default OPTIONS. So, first question: do you have non-default OPTIONS for those ports? That said---your dependency chain doesn't look right. For example, lang/vala depends directly on graphviz, and there is no graphviz configuration that could depend directly on vala. lang/vala does not depend on dconf, and dconf does not depend on gconf2. Some of the dependencies you listed are backwards (gconf2 depends on dconf, and dconf depends on vala), but others don't look possible. If you are able to re-trigger the dependency loop, a log would be extremely helpful. # 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: Ports build fails on 13-CURRENT r341690
From: Justin Hibbits Subject: Re: Ports build fails on 13-CURRENT r341690 Date: Wed, 12 Dec 2018 10:37:25 -0600 > I see the exact same problem on one of my powerpc64 machines (a > P5020-based machine). I see it intermittently on my POWER9, so thought > it was a race condition, but it's 100% reproducible on my P5020 machine. Thank you for reply. I updated my system to r342006 and now the problem disappeared. Just FYI. --- Yasuhiro KIMURA ___ 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"
dependency loop in editors/vim with GTK3 option
There is a dependency recursion loop in the build process for editors/vim if one selects the GTK3 config menu option. The only way I've found so far to get around this is to choose the GTK2 option instead. With GTK3 selected, graphics/librsvg2 becomes a dependency, which, in turn, is dependent upon lang/vala. lang/vala depends upon devel/dconf, which depends upon devel/gconf2. devel/gconf2 depends upon graphics/graphviz, which depends upon lang/vala! The recursion occurs there and was found by following the instructions in UPDATING for the upgrade to perl5.28 when using portmaster. The command shown in the instructions is "portmaster -f", so the -f forces all dependencies and dependent ports to be rebuilt. As nearly as I can see, this dependency recursion loop breaks any port involving lang/vala when portmaster -f is used. In the case of editors/vim, a usable workaround is to choose gtk2 instead of gtk3, but for many other ports, the perl upgrade's admonition to rebuilt ports that depend upon the perl library to omit -f when using portmaster while providing portmaster a *complete list* of all ports to be built. Provided an acceptable version of lang/vala is already installed, it will be used, and the dependency loop gets skipped over because there is no need to build lang/vala. Of course, if one does that, there is no guarantee that the resulting binaries installed for any of the ports in the recursion loop will function properly, given that they may be based upon obsolete versions of the other ports in the loop. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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"
