Re: current: cd /lib ; ln -s libncurses.so.9 libncurses.so.8 xterm & ffox
‐‐‐ Original Message ‐‐‐ On Wednesday 1 April 2020 16:34, Julian H. Stacey wrote: > Hi, Reference: > > > From: Lorenzo Salvadore phascolarc...@protonmail.ch > > Reply-to: Lorenzo Salvadore phascolarc...@protonmail.ch > > Date: Wed, 01 Apr 2020 09:56:27 + > > Lorenzo Salvadore wrote: > > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday 1 April 2020 02:22, Julian H. Stacey j...@berklix.com wrote: > > > > > Hi ports@ > > > A libcurses version problem: > > > Running 13.0-CURRENT with > > > /usr/src > > > cat .svn_revision 359319 > > > cat .ctm_status src-cur 14430 > > > /usr/ports > > > cat .svn_revision 529842 > > > cat .ctm_status ports-cur 13423 > > > After > > > pkg upgrade > > > pkg autoremove > > > xterm & firefox failed with > > > ld-elf.so.1: Shared object "libncurses.so.8" not found, required by > > > "xterm" > > > Fixed temporarily with: > > > cd /lib ; ln -s libncurses.so.9 libncurses.so.8 ; ldconfig -R > > > > I think the recommended fix is to install misc/compat12x. I was suggested to > > do that in another context and it worked for me. I gave the same suggestion > > to someone else with the same problem and it also worked. > > Cheers, > > Lorenzo Salvadore > > Thanks Lorenzo that worked, confirmed by > cd /lib ; mv libncurses.so.8 libncurses.so.8.jhs > cd /usr/ports/misc/compat12x ; make install ; reboot > > To identify package name for others: > make package > produces > /usr/ports/packages/All/compat12x-amd64-12.1.1201000.20200220.txz > however no > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-current/All > & I dont see > "man pkg-info" > has an option to list what's available on repository > (Eventualy I found > http://pkg.freebsd.org/FreeBSD:13:amd64/latest/All/ > with > compat12x-amd64-12.1.1201000.20200220.txz > pkg install compat12x-amd64-12.1.1201000.20200220 > The most recent versions of packages are already installed > Which confirms the pkg name.) Please note however that in most cases you should not need compat12x. What is normally needed is to rebuild all the ports that depend on ncurses on your system. When this is not possible, for example because instead of using ports you use an out of date package repository that you cannot update or because you install a port that needs "hand made" packages (such as i386-wine or i386-wine-devel), then you need compat12x. It seems xterm and firefox are up to date in the official repository: http://pkg.freebsd.org/FreeBSD:13:amd64/latest/All/ . I do not know how the ports are built, it might be that they use some "hand made" packages. 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: current: cd /lib ; ln -s libncurses.so.9 libncurses.so.8 xterm & ffox
‐‐‐ Original Message ‐‐‐ On Wednesday 1 April 2020 02:22, Julian H. Stacey wrote: > Hi ports@ > A libcurses version problem: > > Running 13.0-CURRENT with > /usr/src > cat .svn_revision 359319 > cat .ctm_status src-cur 14430 > /usr/ports > cat .svn_revision 529842 > cat .ctm_status ports-cur 13423 > > After > pkg upgrade > pkg autoremove > xterm & firefox failed with > ld-elf.so.1: Shared object "libncurses.so.8" not found, required by "xterm" > > Fixed temporarily with: > cd /lib ; ln -s libncurses.so.9 libncurses.so.8 ; ldconfig -R I think the recommended fix is to install misc/compat12x. I was suggested to do that in another context and it worked for me. I gave the same suggestion to someone else with the same problem and it also worked. Cheers, 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"
Help would be appreciated about rc scripts
Hello. Can anyone please take a look at review https://reviews.freebsd.org/D24104 ? My mentor would like an advice from someone with some expertise about rc scripts to check if everything is fine. Also, there is an issue with licensing: if you want to give an advice about that issue as well it is welcome. Thanks! Lorenzo Salvadore Sent with ProtonMail Secure Email. ___ 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: svn commit: r358166 - head
> > Are there any way to know which of installed ports are linked to base > > ncurses? > > Best Regards. > > All the one with USES=ncurses in ports, otherwise I am sorry but no we have no > way to track that down. What about "pkg query -a '%n: %B' | grep ncurses"? Maybe it can not distinguish between base ncurses and ports ncurses, but I think it helps. 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: Massive PORTS_REVISION bump after making gcc-9.1 default
‐‐‐ Original Message ‐‐‐
On Sunday 28 July 2019 20:56, Gerald Pfeifer wrote:
> On Sun, 28 Jul 2019, Kevin Oberman wrote:
>
> > The description of the commit states:
> > This includes ports
> >
> > - with USE_GCC=yes or USE_GCC=any,
> > - with USES=fortran,
> > - using Mk/bsd.octave.mk which in turn features USES=fortran, and
> > - with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
> > c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
> > plus, everything INDEX-11 shows with a dependency on lang/gcc9 now.
> >
> >
> > This would appear to me like it did catch a great many ports which are
> > not build with or any anything to do will gcc, though I am not sure.
>
> These ports may not use GCC on your system, or even the majority of
> systems, but there are systems and situations where they do, and bumping
> PORTREVISION is a global binary decision for each port considered.
>
> > E.g. I thought that USES=compiler:c11 and similar were asking for
> > c11 semantics from whatever compiler was used but
>
> Let's look at your example. ports/Mk/Uses/compiler.mk has the following
> on USES=compiler:c11:
>
> .if ${_COMPILER_ARGS:Mc11}
> .if !${COMPILER_FEATURES:Mc11}
> .if (defined(FAVORITE_COMPILER) && ${FAVORITE_COMPILER} == gcc) ||
> (${ARCH} != amd64 && ${ARCH} != i386) # clang not always supported on Tier-2
> USE_GCC= yes
> CHOSEN_COMPILER_TYPE= gcc
> .elif ${COMPILER_TYPE} == gcc
>
> That is, if a user has set a preference for GCC or for non x86/x86-64
> platforms, GCC is used.
>
> And if there is one legitimate configuration on the planet where a
> PORTREVISION bump is required, we have to perform it in our repository.
>
> (This is not saying I may not have made a mistake somewhere, but in
> general those bumps do appear necessary.)
>
> Gerald
It might be useful to add a command to pkg that bumps PORTREVISION
for installed packages without really building them again, for those cases
when users know that they are not affected by the bump.
I think at the moment this is possible only by manually modifying
/var/db/pkg/local.sqlite (I never tried).
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: GSoC: Separation of Ports Build Process from Local Installation
> On 29/05/2019 10:56, Peter Pentchev wrote:
>
> > Hmm, I could be wrong, but isn't ${LOCALBASE} supposed to be where
> > ports find stuffduring the build, and ${PREFIX} where they
> > install the built files? Of course, I haven't actually touched
> > a FreeBSD ports build in years, so I might very likely be wrong.
> > I also seem to remember a series of test port builds done a long
> > time ago with a different value for LOCALBASE, specifically to catch
> > ports that do not honor the policy in this regard.
>
> No, you are correct. The LOCALBASE setting is where the ports will look
> for build dependencies. However, the problem here is there is no
> guarrantee that the LOCALBASE value will not somehow be compiled into a
> resulting package (eg. as RPATH for dynamically loading a shlib) so
> would also be needed for runtime dependencies.
Indeed, I maintain a port where LOCALBASE is a value that appears in the
resulting package's files (not as RPATH): math/maxima. See its Makefile at
line 65.
> Being able to build with a custom value of LOCALBASE and then install
> and run the resulting package onto a system using different value for
> PREFIX would be an interesting piece of work. The applicability would
> be people that custom build their own ports, but who are for some reason
> unable or unwilling to set up some sort of clean-build environment.
> This does strike me as an awful lot of work to solve a perceived problem
> where we do already have some pretty good solutions in place, but not to
> everybodies' taste.
Here again I can give an example of someone who does not want any
clean-build environment: myself. My machine is pretty old, cpu is slow,
ram is low and poudriere gets annoying on it: it needs to install and deinstall
plenty of dependencies for each single new package it builds. My solution
at the moment is using ports keeping all the build depenencies always installed.
However, if I understood the project correctly, I fear it would not offer a
useful alternative in my case.
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: Fwd: FreeBSD ports you maintain which are out of date
On Sunday 17 March 2019 10:48, Lorenzo Salvadore via freebsd-ports wrote: > ‐‐‐ Original Message ‐‐‐ > On Saturday 16 March 2019 22:08, Alfred Perlstein alf...@freebsd.org wrote: > > > How do I stop these emails? > > I just retired my commit bit and stopped committing to ports after some > > folks yelled at me for committing to ports without signoff even though I > > was doing ports before the src/ports split. > > thanks, > > -Alfred > > Forwarded Message > > Subject: FreeBSD ports you maintain which are out of date > > Date: Thu, 14 Mar 2019 11:27:00 + > > From: portsc...@freebsd.org > > To: alf...@freebsd.org > > Dear port maintainer, > > The portscout new distfile checker has detected that one or more of your > > ports appears to be out of date. Please take the opportunity to check > > each of the ports listed below, and if possible and appropriate, > > submit/commit an update. If any ports have already been updated, you can > > safely ignore the entry. > > You will not be e-mailed again for any of the port/version combinations > > below. > > Full details can be found at the following URL: > > http://portscout.freebsd.org/alf...@freebsd.org.html > > Port | Current version | New version > > +-+ > > www/py-djangorestframework-filters | 0.10.2 | 0.11.0 > > +-+ > > If any of the above results are invalid, please check the following page > > for details on how to improve portscout's detection and selection of > > distfiles on a per-port basis: > > http://portscout.freebsd.org/info/portscout-portconfig.txt > > Thanks. > > These e-mails are not send to committers, but to port maintainers. Apparently, > you are py-djangorestframework-filters maintainer: ask to drop maintainership > for your ports (I think you can do it either on this mailing list or on > bugzilla) > and you won't receive any e-mail of this kind any more. > > Lorenzo Salvadore. I forgot to add that e-mails for ports without maintainers are sent to this mailing list (I am almost sure, but not completely). Thus, to get rid of them, you have to unsubscribe from it. 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: Fwd: FreeBSD ports you maintain which are out of date
‐‐‐ Original Message ‐‐‐ On Saturday 16 March 2019 22:08, Alfred Perlstein wrote: > How do I stop these emails? > > I just retired my commit bit and stopped committing to ports after some > folks yelled at me for committing to ports without signoff even though I > was doing ports before the src/ports split. > > thanks, > > -Alfred > > Forwarded Message > Subject: FreeBSD ports you maintain which are out of date > Date: Thu, 14 Mar 2019 11:27:00 + > From: portsc...@freebsd.org > To: alf...@freebsd.org > > Dear port maintainer, > > The portscout new distfile checker has detected that one or more of your > ports appears to be out of date. Please take the opportunity to check > each of the ports listed below, and if possible and appropriate, > submit/commit an update. If any ports have already been updated, you can > safely ignore the entry. > > You will not be e-mailed again for any of the port/version combinations > below. > > Full details can be found at the following URL: > http://portscout.freebsd.org/alf...@freebsd.org.html > > Port | Current version | New version > +-+ > www/py-djangorestframework-filters | 0.10.2 | 0.11.0 > +-+ > > If any of the above results are invalid, please check the following page > for details on how to improve portscout's detection and selection of > distfiles on a per-port basis: > > http://portscout.freebsd.org/info/portscout-portconfig.txt > > Thanks. These e-mails are not send to committers, but to port maintainers. Apparently, you are py-djangorestframework-filters maintainer: ask to drop maintainership for your ports (I think you can do it either on this mailing list or on bugzilla) and you won't receive any e-mail of this kind any more. 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: Poudriere very slow when building in i386 jails
> > Hi! > > > > > > SSD or spinning drives ? > > > > > > > > > I have 3.6 Gb of RAM and 2 Gb of swap. > > > > > > > > Run top and check the state of ARC. > > > > I think it needs much more RAM. > > > > > > I don't think it is a SSD (it has cylinders, sectors etc.). > > > If you can tell me a way to check it I will be glad to do it. > > > This is the output of diskinfo -v /dev/ada0 in case it answers the > > > question: > > > /dev/ada0 > > > 512 # sectorsize > > > 320072933376 # mediasize in bytes (298G) > > > 625142448 # mediasize in sectors > > > 4096 # stripesize > > > 0 # stripeoffset > > > 620181 # Cylinders according to firmware. > > > 16 # Heads according to firmware. > > > 63 # Sectors according to firmware. > > > HGST HTS545032A7E680 # Disk descr. > > > > This is a HGST drive, spinning, no SSD. > > > > > TMA45DZG06UX8R # Disk ident. > > > No # TRIM/UNMAP support > > > 5400 # Rotation rate in RPM > > > Not_Zoned # Zone Mode > > > These are are lines of top's header (poudriere is building one of the > > > ports I think > > > might be problematic): > > > CPU: 32.8% user, 4.8% nice, 8.3% system, 0.5% interrupt, 53.5% idle > > > Mem: 1200M Active, 332M Inact, 32M Laundry, 2084M Wired, 187M Free > > > ARC: 1122M Total, 649M MFU, 323M MRU, 1371K Anon, 16M Header, 133M Other > > > 401M Compressed, 1064M Uncompressed, 2.65:1 Ratio > > > > So, when it's slow during builds, it's most probably swapping. > I have found the real cause of most of the problems: it's ccache configuration. I used the same cache of 15 Gb for the host (amd64) and for all jails (both amd64 and i386): the i386 jails disliked it very much. Creating a new cache only for the i386 jails fixed the problems. Maybe I will have to make the cache smaller to avoid problems in future, but for now it is almost empty and everything is fine. Thanks everybody for your help. 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: Poudriere very slow when building in i386 jails
> Hi! > > > > SSD or spinning drives ? > > > > > > > I have 3.6 Gb of RAM and 2 Gb of swap. > > > > > > Run top and check the state of ARC. > > > I think it needs much more RAM. > > > > I don't think it is a SSD (it has cylinders, sectors etc.). > > If you can tell me a way to check it I will be glad to do it. > > This is the output of diskinfo -v /dev/ada0 in case it answers the question: > > /dev/ada0 > > 512 # sectorsize > > 320072933376 # mediasize in bytes (298G) > > 625142448 # mediasize in sectors > > 4096 # stripesize > > 0 # stripeoffset > > 620181 # Cylinders according to firmware. > > 16 # Heads according to firmware. > > 63 # Sectors according to firmware. > > HGST HTS545032A7E680 # Disk descr. > > This is a HGST drive, spinning, no SSD. > > > TMA45DZG06UX8R # Disk ident. > > No # TRIM/UNMAP support > > 5400 # Rotation rate in RPM > > Not_Zoned # Zone Mode > > These are are lines of top's header (poudriere is building one of the ports > > I think > > might be problematic): > > CPU: 32.8% user, 4.8% nice, 8.3% system, 0.5% interrupt, 53.5% idle > > Mem: 1200M Active, 332M Inact, 32M Laundry, 2084M Wired, 187M Free > > ARC: 1122M Total, 649M MFU, 323M MRU, 1371K Anon, 16M Header, 133M Other > > 401M Compressed, 1064M Uncompressed, 2.65:1 Ratio > > So, when it's slow during builds, it's most probably swapping. Thanks, I will try to work on avoiding using swap as much as possible. 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: Poudriere very slow when building in i386 jails
> Hi! > > > > > Am I the only poudriere user that notices very long build times on an > > > > amd64 machine in i386 jails? This does not happen always, but > > > > frequently enough to be a nuisance. > > > > > > Can you say more about the rest of the setup ? > > > Filesystem type ? Type of storage ? Memory size ? Base and jail system > > > version ? > > > > Filesystem is ZFS. > > I don't understand what you mean by "type of storage": can you make an > > example? > > SSD or spinning drives ? > > > I have 3.6 Gb of RAM and 2 Gb of swap. > > Run top and check the state of ARC. > > I think it needs much more RAM. I don't think it is a SSD (it has cylinders, sectors etc.). If you can tell me a way to check it I will be glad to do it. This is the output of diskinfo -v /dev/ada0 in case it answers the question: /dev/ada0 512 # sectorsize 320072933376# mediasize in bytes (298G) 625142448 # mediasize in sectors 4096# stripesize 0 # stripeoffset 620181 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. HGST HTS545032A7E680# Disk descr. TMA45DZG06UX8R # Disk ident. No # TRIM/UNMAP support 5400# Rotation rate in RPM Not_Zoned # Zone Mode These are are lines of top's header (poudriere is building one of the ports I think might be problematic): CPU: 32.8% user, 4.8% nice, 8.3% system, 0.5% interrupt, 53.5% idle Mem: 1200M Active, 332M Inact, 32M Laundry, 2084M Wired, 187M Free ARC: 1122M Total, 649M MFU, 323M MRU, 1371K Anon, 16M Header, 133M Other 401M Compressed, 1064M Uncompressed, 2.65:1 Ratio Swap: 2048M Total, 210M Used, 1838M Free, 10% Inuse 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: Poudriere very slow when building in i386 jails
> On 31.12.18 21:03, Lorenzo Salvadore via freebsd-ports wrote: > > > > Hi! > > > > > > > Am I the only poudriere user that notices very long build times on an > > > > amd64 machine in i386 jails? This does not happen always, but > > > > frequently enough to be a nuisance. > > > > Can you say more about the rest of the setup ? > > > > > > Filesystem type ? Type of storage ? Memory size ? Base and jail system > > > version ? > > > Filesystem is ZFS. > > > > I don't understand what you mean by "type of storage": can you make an > > example? > > I have 3.6 Gb of RAM and 2 Gb of swap. > > My base system is 12.0-RELEASE. Jails are 11.2-RELEASE and 12.0-RELEASE > > CCACHE aktive? Yes, ccache is active. 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: Poudriere very slow when building in i386 jails
> Hi! > > > Am I the only poudriere user that notices very long build times on an amd64 > > machine in i386 jails? This does not happen always, but frequently enough > > to be a nuisance. > > Can you say more about the rest of the setup ? > > Filesystem type ? Type of storage ? Memory size ? Base and jail system > version ? Filesystem is ZFS. I don't understand what you mean by "type of storage": can you make an example? I have 3.6 Gb of RAM and 2 Gb of swap. My base system is 12.0-RELEASE. Jails are 11.2-RELEASE and 12.0-RELEASE. Thanks. 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"
Poudriere very slow when building in i386 jails
Hello. Am I the only poudriere user that notices very long build times on an amd64 machine in i386 jails? This does not happen always, but frequently enough to be a nuisance. More precisely, building some packages in an i386 jail takes ages compared to the same packages built in an amd64 jail. Moreover, sometimes building a package in an i386 jail with all options on takes a reasonable time while building the same package in the same jail but with all options off takes ages although the amount of work (compilation, testing...) to do is the same or even less than in the first case; and I experienced it with ccache installed and by doing the two builds in the written order. I am trying to find a good example of port to offer for testing. At the moment the best example I can offer is security/libgcrypt (options off): I had to build it as a dependency for a testport yesterday, but after 6 hours of build I had to turn off the machine and gave up. But as I do not know well this port, I do not know if this time should be expected. My machine is amd64, 3.6 Gb of RAM, dual core: not very powerful, I know, but I do not think this is enough to explain very large differences in build times in the contexts I described. Any idea what is going on and what could I do to speed up things? Thanks. Lorenzo Salvadore. Sent with [ProtonMail](https://protonmail.com) Secure Email. ___ 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: Committ request - bug #233772
> Hi! > > > It looks like the patch attached to bug #233772 is needed: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233772 > > It is an update of cad/z88: the user that requested the update > > asks if the patch will be merged. The patch has been tested > > with poudriere on 11.2-RELEASE, 12.0-RELEASE, both on > > i386 and amd64. > > Committed, just in time for 2019Q1 8-} Great! Thank you very much. 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"
Committ request - bug #233772
Hello. It looks like the patch attached to bug #233772 is needed: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233772 It is an update of cad/z88: the user that requested the update asks if the patch will be merged. The patch has been tested with poudriere on 11.2-RELEASE, 12.0-RELEASE, both on i386 and amd64. Thanks. Lorenzo Salvadore. Sent with [ProtonMail](https://protonmail.com) Secure Email. ___ 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: category qt?
> The qt* ports spreads around in the whole portstree. > > It is reasonable to concentrate all these ports in a qt category? I > think it is easier to find (and also easier to maintain). Indeed it is a bit annoying for me when I have to update qt* ports. I don't use portmaster or similar (I don't like them): I wrote my own utility, but it has still some issues, such as this one. I guess having all the qt* ports in the same category would help. 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
> 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: Pourdriere begginner
> Hello, > > Poudriere is installed, poudriere.conf adjusted to my config, then I > create the firts jail, following handbook/ports-poudriere.html : > > > poudriere jail -c -j 12amd64 -v 12.0-STABLE > > > > > > > > [00:00:00] Creating 12amd64 fs at /usr/local/poudriere/jails/12amd64... done > > [00:00:01] Fetching MANIFEST for FreeBSD 12.0-STABLE amd64 > > /usr/local/poudriere/jails/12amd64/fromftp/MAN 1045 B 13 MBps 00s > > [00:00:02] Fetching base for FreeBSD 12.0-STABLE amd64 > > fetch: > > https://download.FreeBSD.org/ftp/snapshots/amd64/amd64/12.0-STABLE/base.txz: > > Not Found > > fetch: > > https://download.FreeBSD.org/ftp/snapshots/amd64/amd64/12.0-STABLE/base.txz: > > Not Found > > [00:00:02] Error: Failed to fetch from > > https://download.FreeBSD.org/ftp/snapshots/amd64/amd64/12.0-STABLE/base.txz > > [00:00:02] Error while creating jail, cleaning up. > > [00:00:02] Removing 12amd64 jail... done > > [00:00:04] Cleaning 12amd64 data... done > > What did I wrong ? Try poudriere jail -c -j 12amd64 -v 12.0-RELEASE 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: Ports with many licenses
>Hi! > >> I am working on creating and adopting some ports and I see that a >> it is very frequent that distfiles have multiple licenses with the following >> scheme: the project has one main license (declared in a COPYING or >> LICENSE file for example) but also many files with their own licenses >> (a frequent case is with files related to the GNU tools, for examples >> Makefile.in). >> >> Then I wondered what should I really write in the LICENSE field: should I >> take care only of the main license or should I track all licenses of all >> files? > > For a first cut, just take care of the main license. If you find time > after doing all the other work to update/create a port, then you > can still track all the licenses. > >> This second case looks very impractical: it would often (always?) require >> to inspect all files one by one. > > Yes. Therefore, do it only if you find nothing else to do 8-} Thank you very much for your answer: that was exactly what I needed. Lorenzo Salvadore. Sent with [ProtonMail](https://protonmail.com) Secure Email. ___ 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"
Ports with many licenses
Hello! I am working on creating and adopting some ports and I see that a it is very frequent that distfiles have multiple licenses with the following scheme: the project has one main license (declared in a COPYING or LICENSE file for example) but also many files with their own licenses (a frequent case is with files related to the GNU tools, for examples Makefile.in). Then I wondered what should I really write in the LICENSE field: should I take care only of the main license or should I track all licenses of all files? This second case looks very impractical: it would often (always?) require to inspect all files one by one. Thanks. Lorenzo Salvadore. Sent with [ProtonMail](https://protonmail.com) Secure Email. ___ 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: Problems building rust with poudriere
> Hello, > > For some time, I've had problems building rust with poudriere. > > Poudriere log: https://borderworlds.dk/~xi/rust-1.30.0.log.txt > > It looks like the system is running out of swap as I get this in > /var/log/messages: > > Oct 30 05:15:31 xindi kernel: pid 68935 (rustc), uid 65534, was killed: > out of swap space > > The build host had 6GB og RAM and 14GB of swap. I think that ought to be > enough for building mostly anything. > > Has anyone else observed this behaviour? > > Best regards > Christian 6 GB of RAM and 14 GB of swap are surely enough, since I can build rust on my system with 4 GB of RAM and 2 GB of swap. I suspect the poudriere's jail has not access to all of that memory for some reason or some other process in your system eats much memory. The poudriere's jail itself surely eats some: I do not know how much, but I do not think it is a small amount. 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: Cleanup poudriere old data
> Dear all, > > normally if I switch to a new release a remove the old jail by using: > > poudriere jails -d -j 111amd64 > > But it seems that it does not remove everything, all the logs are not > deleted: > http://pkg.fechner.net/index.html > > I created again the jail with: > poudriere jail -c -v 11.1-RELEASE -a amd64 -j 111amd64 > > I removed it again with: > poudriere jails -d -C all -j 111amd64 > > But it does not remove the entries from the website, the locale file system: > /usr/local/poudriere/data/logs/bulk/111amd64-default > /usr/local/poudriere/data/logs/bulk/111amd64-gitlab > /usr/local/poudriere/data/logs/bulk/111amd64-2018Q2 > /usr/local/poudriere/data/logs/bulk/111amd64-2018Q3 > ... > /usr/local/poudriere/data/packages/amd64-default > ... > > Is this a bug or did I understand the man-page not correctly? > How can I get rid of all this old stuff (logs, cache, packages)? > > Thanks. I normally use two methods: either I remove the files manually (probably it is unrecommended, but if the jail has already been removed I do not see what problem could come frome such a method) or I use the following commands: poudriere distclean poudriere logclean poudriere pkgclean You find the details in poudriere's manual. 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: Packages not updated?
> > > So I just saw another post on this list that mentioned the "pkg version > > > -vL=" > > > command. Now, I've got a /usr/ports tree used by poudriere and run on the > > > same machine. I svn updated my /usr/ports and kicked off poudriere. When > > > it > > > was done I ran "pkg upgrade". But the "pkg version -vL=" still shows this: > > > py27-ndg_httpsclient-0.4.2 < needs updating (port has 0.5.1) > > > py27-pbr-1.8.1_1 < needs updating (port has 3.1.1) > > > py27-pip-9.0.1 < needs updating (port has 9.0.3) > > > py27-psutil-5.2.2 < needs updating (port has 5.4.7) > > > py27-pyasn1-0.2.2 < needs updating (port has 0.4.2) > > > py27-python2-pythondialog-3.4.0 < needs updating (port has 3.4.0_1) > > > py27-werkzeug-0.12.2 < needs updating (port has 0.14.1) > > > transmission-web-2.93_1 < needs updating (port has 2.94) > > > The question is: why are these packages not getting upgraded when I run > > > pkg upgrade? > > > And, yes, pkg version is getting its info from my poudriere server. I'm > > > looking at the web server logs in real time. > > > Any ideas? > > > > pkg upgrade is for upgrading packages and not ports, but pkg version is > > comparing > > your version against the versions of the port tree, not of the package > > repository. > > It is comparing against the version of the ports treeshared with > Poudriere. I'm running my own package server. The packages installed, > the packages built by Poudriere, and the ports tree should all be sync > because they are all on the same machine. But they aren't it seems. That's > odd. > > > To compare against the package repository, use the -R flag: > > pkg version -RvL= > > Huh. When I try that I get: > > idnkit-1.0_7 ? orphaned: dns/idnkit > py27-funcsigs-1.0.2 ? orphaned: devel/py-funcsigs > py27-mock-2.0.0 ? orphaned: devel/py-mock > py27-ndg_httpsclient-0.4.2 ? orphaned: net/py-ndg_httpsclient > py27-pbr-1.8.1_1 ? orphaned: devel/py-pbr > py27-pip-9.0.1 ? orphaned: devel/py-pip > py27-psutil-5.2.2 ? orphaned: sysutils/py-psutil > py27-pyasn1-0.2.2 ? orphaned: devel/py-pyasn1 > py27-python2-pythondialog-3.4.0 ? orphaned: devel/py-python2-pythondialog > py27-werkzeug-0.12.2 ? orphaned: www/py-werkzeug > python2-2_3 ? orphaned: lang/python2 > transmission-web-2.93_1 ? orphaned: www/transmission-web > > ... and there's no hit on the web server for the packages database. > > I do notice that none of these packages are listed in the file that tells > Poudriere what to build. It is telling me that these packages were > dependencies of something but aren't any longer? But they're still getting > built I guess because why else would Poudriere say they are in the meta.txz > or packagesite.txz files (I don't know which one)? I do not use poudriere in the same way (I use it only for testing ports), but I guess that, as you suggested, those softwares were installed as a special kind of dependecies, i.e. build dependencies. Then poudriere probably created a package repository in your jail with only the explicitly installed software in it and maybe its run dependencies, but not the build dependencies, thus the missing packages. 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: Packages not updated?
> So I just saw another post on this list that mentioned the "pkg version -vL=" > command. Now, I've got a /usr/ports tree used by poudriere and run on the > same machine. I svn updated my /usr/ports and kicked off poudriere. When it > was done I ran "pkg upgrade". But the "pkg version -vL=" still shows this: > > py27-ndg_httpsclient-0.4.2 < needs updating (port has 0.5.1) > py27-pbr-1.8.1_1 < needs updating (port has 3.1.1) > py27-pip-9.0.1 < needs updating (port has 9.0.3) > py27-psutil-5.2.2 < needs updating (port has 5.4.7) > py27-pyasn1-0.2.2 < needs updating (port has 0.4.2) > py27-python2-pythondialog-3.4.0 < needs updating (port has 3.4.0_1) > py27-werkzeug-0.12.2 < needs updating (port has 0.14.1) > transmission-web-2.93_1 < needs updating (port has 2.94) > > The question is: why are these packages not getting upgraded when I run > pkg upgrade? > > And, yes, pkg version is getting its info from my poudriere server. I'm > looking at the web server logs in real time. > > Any ideas? pkg upgrade is for upgrading packages and not ports, but pkg version is comparing your version against the versions of the port tree, not of the package repository. To compare against the package repository, use the -R flag: pkg version -RvL= 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: orphaned: www/suphp
> I just updated my ports tree and then proceeded to run: "pkg version -vL=" > which produced this: > > suphp-0.7.2_2 ? orphaned: www/suphp > > There is nothing about this in either the UPDATING or MOVED files. Has this > port actually been removed and if so, why? I have it in my port tree, which I just updated. 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: How to exclude some sparse files from LICENSE_DISTFILES
> On Sun, Oct 07, 2018 at 12:24:54PM +0000, Lorenzo Salvadore via freebsd-ports > wrote: > > > Hello. > > I am trying to adopt and update a port which has no license specified. > > Almost all files are under public domain, but there are some exceptions, > > not all > > in the same directories, so I would need to assign to LICENSE_DISTFILES_PD > > a value that means "all files are under public domain unless otherwise > > stated". > > I thought I could use something like LICENSE_DISTFILES_PD!=$(find ... ), > > but I know > > that != is discouraged ( > > https://lists.freebsd.org/pipermail/freebsd-ports/2008-July/049777.html ). > > Is there some nice solution to this problem? Maybe just not defining > > LICENSE_DISTFILES_PD? > > Defining an ALMOSTPD license? > > LICENSE_DISTFILES* is about distfiles, the things in > /usr/ports/distfiles, not about the files in the work directory. You > can say "this tar.gz is PD, and this tar.gz is GPL" but not more than that. > > What you want is > > LICENSE= PD OTHER > LICENSE_COMB= multi > > (Note if the other license is not defined, you have to define it > further.) Thank you very much. Indeed, I had misunderstood the documentation: now everything is clear (and I have some new ports to correct). 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"
How to exclude some sparse files from LICENSE_DISTFILES
Hello. I am trying to adopt and update a port which has no license specified. Almost all files are under public domain, but there are some exceptions, not all in the same directories, so I would need to assign to LICENSE_DISTFILES_PD a value that means "all files are under public domain unless otherwise stated". I thought I could use something like LICENSE_DISTFILES_PD!=$(find ... ), but I know that != is discouraged ( https://lists.freebsd.org/pipermail/freebsd-ports/2008-July/049777.html ). Is there some nice solution to this problem? Maybe just not defining LICENSE_DISTFILES_PD? Defining an ALMOSTPD license? Thanks. Lorenzo Salvadore. Sent with [ProtonMail](https://protonmail.com) Secure Email. ___ 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: gcc5
> Todays update and I am using portmaster: > ===>>> Starting build for ports that need updating <<<=== > > ===>>> Launching child to install lang/gcc5 > > ===>>> All >> lang/gcc5 (1/2) > > ===>>> Currently installed version: gcc5-5.5.0_4 > ===>>> Port directory: /usr/ports/lang/gcc5 > > ===>>> Starting check for build dependencies > ===>>> Gathering dependency list for lang/gcc5 from ports > ===>>> Dependency check complete for lang/gcc5 > > ===>>> All >> gcc5-5.5.0_4 (1/2) > > ===> Cleaning for gcc5-5.5.0_5 > Making GCC 5.5.0 for x86_64-portbld-freebsd11.2 [c,c++,objc,fortran] > ===> NOTICE: > > This port is deprecated; you may wish to reconsider installing it: > > Unsupported by upstream. Use GCC 7 or newer instead.. > > ===> License GPLv3 GPLv3RLE accepted by the user > ===> gcc5-5.5.0_5 depends on file: /usr/local/sbin/pkg - found > ===> Fetching all distfiles required by gcc5-5.5.0_5 for building > ===> Extracting for gcc5-5.5.0_5 > => SHA256 Checksum OK for gcc-5.5.0.tar.xz. > > but there are many ports which depend on gcc5: > > Installed packages to be REMOVED: > gcc5-5.5.0_4 > libx264-0.155.2917 > gstreamer-plugins-x264-0.10.19_8,3 > gstreamer1-plugins-x264-1.12.3_2 > mencoder-1.3.0.20180920 > ffmpeg-4.0.2_4,1 > libstreamanalyzer-0.7.8_12 > aqualung-1.0_9 > chromaprint-1.4.3_2 > mlt-6.10.0_1 > iridium-browser-2018.5.67_4 > youtube_dl-2018.09.10 > synfig-1.2.1_9 > blender-2.79b_6 > gimp-gmic-plugin-1.6.9_16 > gegl-0.2.0_25 > mpv-0.29.0_6,1 > gegl3-0.3.34_2 > gstreamer1-plugins-chromaprint-1.12.3 > synfigstudio-1.2.1_5 > py27-gimp-2.8.22_1 > gimp-app-2.8.22_1,1 > gnome-mpv-0.15 > gimp-2.8.22,2 > gimp-resynthesizer-2.0.3 > gimp-lqr-plugin-0.7.2 > gimpfx-foundry-2.6_2,1 > gimp-wavelet-decompose-plugin-0.1.2_3 > gimp-wavelet-sharpen-plugin-0.1.2_3 > gimp-wavelet-denoise-plugin-0.3.1_3 > gimp-lensfun-plugin-0.2.4.d_7 > gimp-gutenprint-5.2.14 > gimp-beautify-plugin-2012.08.12.00_7 > gimp-refocus-plugin-0.9.0_7 > > Number of packages to be removed: 34 > > The operation will free 863 MiB. > > Proceed with deinstalling packages? [y/N]: I think you should do the following: pkg remove -f gcc5 This should remove gcc5 only and ignore dependencies. Once you install gcc7 you will probably have your broken dependencies solved with gcc7 or you will have to reinstall them. As a side note, I do not think that all the ports listed depends on gcc5: for example I do not think that ffmepg depends on any gcc version. This would mean that you have only a few ports depending on gcc5 (maybe only one) and that ffmpeg is installed automatically as a dependency of those ports: since the ports that depend on gcc5 are removed, their dependencies are not needed any more and are also removed. 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: error: undefined symbol: OPENSSL_cpuid_setup
> On Wed, Sep 26, 2018 at 09:53:32AM +0000, Lorenzo Salvadore via freebsd-ports > wrote: > > > > > While playing with compiling www/chromium, I'm seeing make stop with > > > > /usr/bin/ld.lld: error: undefined symbol: OPENSSL_cpuid_setup > > > > This is on a Raspberry Pi 3 running > > > > FreeBSD www.zefox.org 12.0-ALPHA7 FreeBSD 12.0-ALPHA7 r338880 GENERIC > > > > with ports at > > > > 480613 > > > > World and kernel build, install and run acceptably, so the system as > > > > a whole isn't hugely broken. Can anybody suggest a fix/workaround? > > > > > > Changed the make command to > > > make -DBATCH DISABLE_VULNERABILITIES=yes DEFAULT_VERSIONS+=ssl=base > > > > make.log > > > but make stopped with the same error: > > > /usr/bin/ld.lld: error: undefined symbol: OPENSSL_cpuid_setup > > > > > > > > > referenced by crypto.c > > > > > > crypto.o:(do_library_init) in archive > > > > > > obj/third_party/boringssl/libboringssl.a > > > > > > c++: error: linker command failed with exit code 1 (use -v to see > > > invocation) > > > It's not clear to me if this is an issue with the port, or the base > > > system. > > > Any advice appreciated! > > > > I might be wrong, but I see some similiraties with an issue discussed in > > those days > > under the subject "error: undefined symbol: main in poudriere jail". It was > > a > > linking problem that appeared only on 12.0-ALPHA7 (or current any anyway, > > not on > > 11.2-RELEASE). I suggest you take a look into it. > > Here are the links to the most relevant messages (from the week archive, so > > they > > will not work anymore after the week pass and then you will have to search > > them > > in an other archive): > > https://docs.freebsd.org/cgi/getmsg.cgi?fetch=87161+0+current/freebsd-ports > > https://docs.freebsd.org/cgi/getmsg.cgi?fetch=108259+0+current/freebsd-ports > > My situation is much simpler than the one described, there's no jail, just > a plain "make" in /usr/ports/www/chromium. Hopefully it'll be less complex! The jail was not relevant for that problem: the point was that the new default linker for 12.0-ALPHA7 made disappear the symbol main() and my guess is that it also makes disappear the symbol OPENSSL_cpuid_setup in your case. If that was the case making the suggested symlink may solve your problem: ln -sf ld.bfd /usr/bin/ld As I do not have a 12.0-ALPHA7 installed, I can not tell you where is ld.bfd, but I am sure you will not have problem to find it. On this topic, you might also like to take a look at this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214864 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: error: undefined symbol: OPENSSL_cpuid_setup
> > While playing with compiling www/chromium, I'm seeing make stop with > > /usr/bin/ld.lld: error: undefined symbol: OPENSSL_cpuid_setup > > This is on a Raspberry Pi 3 running > > FreeBSD www.zefox.org 12.0-ALPHA7 FreeBSD 12.0-ALPHA7 r338880 GENERIC > > with ports at > > 480613 > > World and kernel build, install and run acceptably, so the system as > > a whole isn't hugely broken. Can anybody suggest a fix/workaround? > > Changed the make command to > make -DBATCH DISABLE_VULNERABILITIES=yes DEFAULT_VERSIONS+=ssl=base > make.log > > but make stopped with the same error: > /usr/bin/ld.lld: error: undefined symbol: OPENSSL_cpuid_setup > > > > > referenced by crypto.c > > > > crypto.o:(do_library_init) in archive > > > > obj/third_party/boringssl/libboringssl.a > > c++: error: linker command failed with exit code 1 (use -v to see invocation) > > It's not clear to me if this is an issue with the port, or the base system. > Any advice appreciated! I might be wrong, but I see some similiraties with an issue discussed in those days under the subject "error: undefined symbol: main in poudriere jail". It was a linking problem that appeared only on 12.0-ALPHA7 (or current any anyway, not on 11.2-RELEASE). I suggest you take a look into it. Here are the links to the most relevant messages (from the week archive, so they will not work anymore after the week pass and then you will have to search them in an other archive): https://docs.freebsd.org/cgi/getmsg.cgi?fetch=87161+0+current/freebsd-ports https://docs.freebsd.org/cgi/getmsg.cgi?fetch=108259+0+current/freebsd-ports I hope it helps. 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: error: undefined symbol: main in poudriere jail
> > That's the problem, the same code works for earlier version of FreeBSD. > > You can try switching back to the old GNU ld via something like "ln > -fs ld.bfd /usr/bin/ld" and building the port on 12. (Or, set > WITHOUT_LLD_IS_LD in src.conf.) If that works I'll try to suggest some > further steps. I will repeat the test for current: this will need some time. However I fear that I will only confirm that I receive the same error and probably the best solution is to try something like Ed Maste's suggestion. 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: error: undefined symbol: main in poudriere jail
> I am testing both the actual version of brlcad and your changes. Since I have > a > slow computer, this will take some time (if someone else with a more powerful > computer can perform the tests in less time it is welcomed). I have finished testing. While the actual version of brlcad fails to build for me, your changes worked: the build was successful (on poudriere with a jail with 11.2-RELEASE). 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: error: undefined symbol: main in poudriere jail
> I am trying to update cad/brlcad there's an open issue on the Bugzilla that > I'd like to resolve. > > I'm getting this error both in poudriere but now it's also showing up when > trying to build outside of poudriere. > > Here is the build log > https://transfer.sh/bn41v/brlcad-7.26.4_8.log > > this is a .shar file with the changes > https://transfer.sh/wVh1c/brlcad-7.26.4.shar > > both my machine and poudriere are on r338902 > > Is this link error only affecting me? I am testing both the actual version of brlcad and your changes. Since I have a slow computer, this will take some time (if someone else with a more powerful computer can perform the tests in less time it is welcomed). While we wait the results, here are two suggestions: - ask the mantainer: he is the probably the one that knows better the port and hence the best person that can help you (since you are dealing with a bug report, you might like to contact him through this same bug report); - I gave a quick look to your changes and seen the line CMAKE_ARGS+= -DBRLCAD_BUNDLED_LIBS=ON. Bundled libraries often bring problems and, since you are having a linking problem, this might be the cause; anyway, you should avoid using them if you can (see https://www.freebsd.org/doc/en/books/porters-handbook/bundled-libs.html ). If someone else wants to help, it might be useful to give the link to the bug report that you are working on. Probably this is the link (it is the only open issue on cad/brlcad that I found): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211921 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: error: undefined symbol: main in poudriere jail
> This issue seemed to have come up in the past: > https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068870.html > > Jail name: amd64_cur > Jail version: 12.0-ALPHA7 1200084 > Jail vcs version: r338898 > Jail arch: amd64 > Jail method: svn > Jail mount: /usr/local/poudriere/jails/amd64_cur > Jail fs: zroot/poudriere/jails/amd64_cur > Jail updated: 2018-09-24 03:39:31 > Tree name: default > Tree method: portsnap > Status: > > error > /usr/bin/cc -pipe -fno-strict-aliasing -fno-common -fexceptions -std=gnu99 > -m64 -Qunused-arguments -O3 -march=native -finline-functions -flto > -fomit-frame-pointer -pedantic -pedantic-errors -Wall -Wextra -Wundef > -Wfloat-equal -Wshadow -Wbad-function-cast -Wdeclaration-after-statement > -Wc++-compat -Winline -Wno-long-long -Wno-variadic-macros -Wdocumentation > -m64 src/rttherm/CMakeFiles/rttherm.dir/spectrum.c.o > src/rttherm/CMakeFiles/rttherm.dir/viewtherm.c.o -o bin/rttherm > -Wl,-rpath,/wrkdirs/usr/ports/cad/brlcad/work/.build/lib:/usr/local/lib: > lib/libged.so.20.0.1 lib/librtuif_multispectral.a > lib/libmultispectral.so.20.0.1 lib/libfb.so.20.0.1 lib/libpkg.so.20.0.1 > /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so > /usr/local/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so > /usr/local/lib/libGLU.so /usr/local/lib/libGL.so lib/libtk.so.8.5 > /usr/local/lib/libX11.so /usr/local/lib/libXext.so lib/libtkstub.a > lib/libtclstub.a /usr/local/lib/libXrender.so lib/libwdb.so.20.0.1 > lib/libicv.so.20.0.1 lib/libpng16.so.16.29.0 lib/libnetpbm.so > lib/libanalyze.so.20.0.1 lib/libtcl.so.8.5.19 lib/libclipper.so.4.6.0 > lib/librt.so.20.0.1 lib/libnmg.so lib/libgdiam.so lib/libvds.so.1.0.1 > lib/libbrep.so.20.0.1 lib/libbg.so.20.0.1 lib/libopenNURBS.so.2012.10.245 > lib/libp2t.so.1.0.1 lib/libz.so.1.2.11 lib/libtinycthread.so lib/liblz4.so > lib/libbn.so.20.0.1 lib/libbu.so.20.0.1 lib/libregex.so.1.0.4 -lm -pthread > -ldl && : > FAILED: bin/rttherm > : && /usr/bin/cc -pipe -fno-strict-aliasing -fno-common -fexceptions > -std=gnu99 -m64 -Qunused-arguments -O3 -march=native -finline-functions > -flto -fomit-frame-pointer -pedantic -pedantic-errors -Wall -Wextra -Wundef > -Wfloat-equal -Wshadow -Wbad-function-cast -Wdeclaration-after-statement > -Wc++-compat -Winline -Wno-long-long -Wno-variadic-macros -Wdocumentation > -m64 src/rttherm/CMakeFiles/rttherm.dir/spectrum.c.o > src/rttherm/CMakeFiles/rttherm.dir/viewtherm.c.o -o bin/rttherm > -Wl,-rpath,/wrkdirs/usr/ports/cad/brlcad/work/.build/lib:/usr/local/lib: > lib/libged.so.20.0.1 lib/librtuif_multispectral.a > lib/libmultispectral.so.20.0.1 lib/libfb.so.20.0.1 lib/libpkg.so.20.0.1 > /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so > /usr/local/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so > /usr/local/lib/libGLU.so /usr/local/lib/libGL.so lib/libtk.so.8.5 > /usr/local/lib/libX11.so /usr/local/lib/libXext.so lib/libtkstub.a > lib/libtclstub.a /usr/local/lib/libXrender.so lib/libwdb.so.20.0.1 > lib/libicv.so.20.0.1 lib/libpng16.so.16.29.0 lib/libnetpbm.so > lib/libanalyze.so.20.0.1 lib/libtcl.so.8.5.19 lib/libclipper.so.4.6.0 > lib/librt.so.20.0.1 lib/libnmg.so lib/libgdiam.so lib/libvds.so.1.0.1 > lib/libbrep.so.20.0.1 lib/libbg.so.20.0.1 lib/libopenNURBS.so.2012.10.245 > lib/libp2t.so.1.0.1 lib/libz.so.1.2.11 lib/libtinycthread.so lib/liblz4.so > lib/libbn.so.20.0.1 lib/libbu.so.20.0.1 lib/libregex.so.1.0.4 -lm -pthread > -ldl && : > /usr/bin/ld: error: undefined symbol: main > > > > > referenced by crt1.c:74 > > (/usr/local/poudriere/jails/amd64_cur/usr/src/lib/csu/amd64/crt1.c:74) > > > > > /usr/lib/crt1.o:(_start) > > > > > > cc: error: linker command failed with exit code 1 (use -v to see invocation) > ninja: build stopped: subcommand failed. > *** Error code 1 Can you please explain what were you trying to do and how the error can be reproduced? 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: pkg-plist and stage directory for new port
> Hi,
>
> In my quest for creating a new port (pgadmin4) I'm having a problem with
> creating a working pkg-plist. Seems to me that at least the created binary
> should be in the pkg-plist file, in my case "bin/pgAdmin4". But when I do
> that, make check-plist results in an error:
>
> ===> Checking for items in pkg-plist which are not in STAGEDIR
> Error: Missing: bin/pgAdmin4
> ===> Error: Plist issues found.
>
> *** Error code 1
>
> Which is correct because the /stage directory is empty. I could remove the
> bin/pgAdmin4 line from the pkg-plist file but that doesn't seem right to
> me because then the created binary isn't installed at all I guess. Correct
> thing imo would be that the created binary is copied to the
> /stage/usr/local/bin directory.
>
> So biggest question is why is the /stage directory still empty?
Show us your makefile please.
When I created my first port, I remember I had some difficulty to
understand staging: imho it needs to be explained better in the documentation.
Are you aware of the variable ${STAGEDIR}? You probably need to add
to your makefile some lines similar to the followings:
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/??/pgAdmin4 ${STAGEDIR}${PREFIX}/bin
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: Poudriere
> > Removed that file from those ports and didn't seem to help
>
> Can you tell if installing port lang/python36 alone instead of as a
> dependency works? I think it does not.
> The problem might be at the end of lang/python36/Makefile (from
> line 140 and down). There is a similiar block at the end of
> lang/python37/Makefile, while lang/python27/Makefile last block
> is a bit different.
Could you also execute the following Makefile and give us the output?
all:
@echo OSVERSION = ${OSVERSION}
@echo OSREL = ${OSREL}
.include
It might be that 12-CURRENT on a non x86 architecture sets wrongly
those variables.
Lorenzo Salvaore.
___
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: Poudriere
> Removed that file from those ports and didn't seem to help Can you tell if installing port lang/python36 alone instead of as a dependency works? I think it does not. The problem might be at the end of lang/python36/Makefile (from line 140 and down). There is a similiar block at the end of lang/python37/Makefile, while lang/python27/Makefile last block is a bit different. 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: how to enforce one version of python
> Maybe I need to stop using portupgrade. What is the best replacement? I never liked traditional updaters: to me, they seem too complex for a task that should be rather simple. Thus I wrote one myself: Caronte. It has not yet been committed to the port tree, but you can find the port here, waiting for a commit: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230769 Keep in mind that the project is new and I have not tested it in many situation yet. In particular, I found that I need to work a bit in the case new options are added to a port after an update (at the moment, in this case, the upgrade is suspended in the configuration step of the updated port until you press CTRL + C), but I will fix that as soon as possible (it was not a priority until I was the only user). I think my updater has a nice behavior with flavors (read manpage), but if it has not, you can post an issue on github and I will deal with it as a priority: https://github.com/lsalvadore/caronte 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: Poudriere
> > It happens only on non x86 no matter version of freebsd. Py-pytest at py36 > > does it for me. Koobs tested it in his arm64 at py36. It’s not the port > > itself. As the file that touches during build isn’t related to the port The > > freebsd11 changes to freebsd12 according to jail version > > usr/local/lib/python3.6/pycache/sysconfigdata_m_freebsd11.cpython-36.pyc: > > size (17379, 17331) > > Your problem must be in lang/python. Read lang/python36/pkg-plist line 154: > you find the name of your file. And in lang/python37/pkg-plist, line 157 > again. > > On the contrary, there is no such file in lang/python27. A possible workaround could be to force the value of OSMAJOR to 11 (or 12, I am not sure which is the one you want) in line 49 of lang/python36/Makefile and in line 49 of lang/python37/Makefile. But of course, if it works it would be only a workaround: you should file a bug report and someone should fix it properly. 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: Poudriere
> It happens only on non x86 no matter version of freebsd. Py-pytest at py36 > does it for me. Koobs tested it in his arm64 at py36. It’s not the port > itself. As the file that touches during build isn’t related to the port The > freebsd11 changes to freebsd12 according to jail version > usr/local/lib/python3.6/pycache/sysconfigdata_m_freebsd11.cpython-36.pyc: > size (17379, 17331) Your problem must be in lang/python. Read lang/python36/pkg-plist line 154: you find the name of your file. And in lang/python37/pkg-plist, line 157 again. On the contrary, there is no such file in lang/python27. 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: how to enforce one version of python
> Hi, > There are a number of ports that seem to have their own preferential > flavour of python, and some for example want to install python27 and > python36 in the same place, and it's a pain when using portupgrade or > similar tools. > I have this in my /etc/make.conf: > DEFAULT_VERSIONS+= python=2.7 > Is this incorrect? I assume it must be, as for example devel/pylint > (pylint-py27-1.9.2) wants to upgrade to pylint-py36-2.1.1 > thanks, > J. I think the correct line would be the following: FLAVOR?= py27 Lorenzo Salvadore. PS: sorry for posting on the wrong mailing list before: my mail is a pain when replying on mailing lists... ___ 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: Poudriere
> Submitting this here as I believe this may be best place to ask the question > as I use poudriere to test ports before sending patches > I am on 12 current. If I’m building a port that can use either py27 or py36 > on an non x86based system the py27 works fine on all my jails. If I test with > py36 poudriere errors out saying a file touched my FS during build and it > actually does install a file on my FS as I can delete the file it refers to > and retry build and it will be there again. The FS violation happens on my > mips/mips64/armv6/arm64/ poudriere jails with py36. To try something I forced > it to use py37 and it does the same. > I’ve created a new arch jail with new name and it happens on fresh jail > install as well. I’ve disabled ccache and that didn’t fix the issue either This looks like a problem in some py36 port's Makefile. Can you tell us which file is installed? This might help find the right package. Moreover, does it happen only on 12 current? Can you try on 11.2-RELEASE for example? What about changing architecture? Is py36 fine on a x86 based system? I could do some testing too: can you give an explicit example of broken port? 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"
