Re: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
On Fri, May 14, 2021 at 12:24:06PM +1000, Kubilay Kocak wrote: > > happy to help identify the root cause if you can jump on IRC > (#freebsd-python @ freenode) If sorting out the conflict between python versions helps the community in general I'm willing to try. I simply use make in the ports tree, not wanting the disk and cpu overhead imposed by ports management software. But, that approach seems to be getting obsolete. I don't mind being a Luddite, but there's no profit in being the _last_ Luddite. 8-) I've never used IRC, is it somehow better than this list? Thanks for writing, bob prohaska ___ 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-fallout: License not correctly defined: defining both LICENSE_FILE and LICENSE_TEXT is not allowed
## Chris (portmas...@bsdforge.com): > > but the way it currently interacts > > with your port is not that fine: in the very least, it overwrites > > your LICENSE variables, which cannot be your intention. (Try > > "make -V LICENSE" in kde-icons-nuovoext2). > Sorry. My bad. LGPL3 is now included in the current LICENSE Templates. > So LICENSE_FILE is redundant && pkg-fallout (the ports framework) was > trying to use a "clue bat" to tell me so. ;-) Absolutely not. Due to the included file, your port has not set the LICENSE to "LGPL3" but to "theme". That is a severe problem, you're not allowed to just put another license on that port. It's also not "look at the Makefile, the intention is clear": the LICENSE field ends up in the package, and there's no weaseling around the problem. Code bugs may be annoying, but "wrong license" is a mistake with potential to awaken the lawyers. Fix it. Regards, Christoph -- Spare Space ___ 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-fallout: License not correctly defined: defining both LICENSE_FILE and LICENSE_TEXT is not allowed
On 2021-05-14 14:19, Christoph Moench-Tegeder wrote:
## Chris (portmas...@bsdforge.com):
> but the way it currently interacts
> with your port is not that fine: in the very least, it overwrites
> your LICENSE variables, which cannot be your intention. (Try
> "make -V LICENSE" in kde-icons-nuovoext2).
Sorry. My bad. LGPL3 is now included in the current LICENSE Templates.
So LICENSE_FILE is redundant && pkg-fallout (the ports framework) was
trying to use a "clue bat" to tell me so. ;-)
Absolutely not. Due to the included file, your port has not set
the LICENSE to "LGPL3" but to "theme". That is a severe problem,
you're not allowed to just put another license on that port. It's
also not "look at the Makefile, the intention is clear": the
LICENSE field ends up in the package, and there's no weaseling
around the problem.
Code bugs may be annoying, but "wrong license" is a mistake with
potential to awaken the lawyers. Fix it.
I'm confused by your reply.
The problem I'm addressing in this case; is that the following as
*always* worked for licenses which carried a copy in
${WRKSRC}/LICENSE_NAME:
LICENSE=LICENSE_TYPE
LICENSE_FILE= ${WRKSRC}/LICENSE_NAME
however. I've recently been plagued with complaints from pkg-fallout:
===> License not correctly defined: defining both LICENSE_FILE and
LICENSE_TEXT is not allowed
make: exec(exit) failed (No such file or directory)
*** Error code 1
When using that strategy. Sure enough; when performing a make test
on the problem port. I get roughly the same ERROR. Curious I thought.
Something in the ports framework must have changed. fe;
LICENSE=LGPL3
LICENSE_FILE= ${WRKSRC}/COPYING
fails. EVEN though the file ${WRKSRC}/COPYING exists.
ALSO; LICENSE_FILE *and* LICENSE_TEXT are not BOTH defined, as stated
in the ERROR output.
Removing LICENSE_FILE returns; no problems with port.
So there you have it. The long version. :-)
you're not allowed to just put another license on that port.
I'm not. It's a verbatim LGPL3 port && license as reported
within the port' source. :-)
Code bugs may be annoying, but "wrong license" is a mistake with
potential to awaken the lawyers.
I'm well versed in law, and I've performed nothing contrary to the
ports' source' intent. :-)
--Chris
Regards,
Christoph
___
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-fallout: License not correctly defined: defining both LICENSE_FILE and LICENSE_TEXT is not allowed
## Chris (portmas...@bsdforge.com):
> The problem I'm addressing in this case; is that the following as
> *always* worked for licenses which carried a copy in
> ${WRKSRC}/LICENSE_NAME:
The problem you're trying to address is only a consecutive error and
not the real problem.
As I wrote in my first reply:
: Foremost, that Makefile has an .include, and that's where the mess
: (for this use case) happens.
An .include includes the given file at that point (duh), and in this
case that's kde-icons-noia/Makefile.icons, which overwrites your
LICENSE variables (and brings in LICENSE_TEXT). And, as stated before:
that cannot be your intention (and including kde-icons-noia/Makefile.icons
only makes sense in a very limited number of ports if at all). And you
can (and should, in case of doubt or problems) double-check your
variables by running e.g. "make -V LICENSE" in the port's directory
(or "make -C -V ", yadda yadda, make(1), etc).
> > you're not allowed to just put another license on that port.
> I'm not. It's a verbatim LGPL3 port && license as reported
> within the port' source. :-)
: cmt: x11-themes/kde-icons-nuovext2$ make -V LICENSE
: theme
That's not LGPL3.
Regards,
Christoph
--
Spare Space
___
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-fallout: License not correctly defined: defining both LICENSE_FILE and LICENSE_TEXT is not allowed
On 2021-05-14 15:15, Christoph Moench-Tegeder wrote:
## Chris (portmas...@bsdforge.com):
The problem I'm addressing in this case; is that the following as
*always* worked for licenses which carried a copy in
${WRKSRC}/LICENSE_NAME:
The problem you're trying to address is only a consecutive error and
not the real problem.
As I wrote in my first reply:
: Foremost, that Makefile has an .include, and that's where the mess
: (for this use case) happens.
DO'H!
Sorry. I've been fairly overwhelmed w/$DAYJOB so *clearly* glossed over
that (important) section.
Thank you for taking the time to use your "clue bat" on me. :-)
Yes. That's *exactly* why the error(s) are occurring.
The only question I have at this juncture; is *why* after some ~5yrs
later is it *now* throwing an error?
Oh well. In any case, I can easily resolve the problem and set things
straight with these ports.
Thanks again! :-)
--Chris
An .include includes the given file at that point (duh), and in this
case that's kde-icons-noia/Makefile.icons, which overwrites your
LICENSE variables (and brings in LICENSE_TEXT). And, as stated before:
that cannot be your intention (and including kde-icons-noia/Makefile.icons
only makes sense in a very limited number of ports if at all). And you
can (and should, in case of doubt or problems) double-check your
variables by running e.g. "make -V LICENSE" in the port's directory
(or "make -C -V ", yadda yadda, make(1), etc).
> you're not allowed to just put another license on that port.
I'm not. It's a verbatim LGPL3 port && license as reported
within the port' source. :-)
: cmt: x11-themes/kde-icons-nuovext2$ make -V LICENSE
: theme
That's not LGPL3.
Regards,
Christoph
___
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: Python 37/38 conflict, was Re: Trubles compiling lxqt on RPi4
bob prohaska fbsd at www.zefox.net wrote on Fri May 14 01:35:28 UTC 2021 : > On Thu, May 13, 2021 at 01:35:50PM -0700, Mark Millard wrote: > > You have apparently chosen to build/update ports via a > > technique that requires you to manage the dependencies, at > > least some of the time. (Not that when is necessarily > > obvious up front.) > > > > You give me too much credit 8-) > > > Your environment is now based on a mix of python37 and > > python 38 related materials. You are likely going to > > need to rework/rebuild/reinstall things to avoid that. > > > > Hints may come from that UPDATING that I quoted but > > things are more broken overall than what UPDATING is > > intended to cover. You might end up needing to > > uninstall a bunch of stuff until python is unused > > (or only one python is used) and then follow the > > notes if you have only python37 use and want to > > get to python38. Finally rebuild/reinstall what > > was uninstalled, based on python38 as a context. > > > Trying to deinstall both python37 and python38 didn't > suffice. Python38's reinstall fails with the same > conflict. Deleting the offending file doesn't help > If other things need to be deinstalled it's not clear > what they might be. > > > Due to how I build/install ports, I've not had to deal > > with ending up with the mix so I'm not familiar with > > the details for recovering from a messy mix. > > > > Would use of poudriere help with this sort of problem? > It isn't trivial to configure, but this sort of difficulty > has been growing ever worse. I didn't want to deal with the > complexity and overhead, but maybe it's time. > I happen to use ports-mgmt/poudriere-devel and it avoids such issues but does have build-time tradeoffs and the like. (I'll note that I presume the sort of sustem tuning to avoid Out Of Memory kills and I try to scale to avoid a literal out of swap space problems.) I'll start with very overall background for port building because I do not understand your context or goals. Otherwise my material could end-up implicitly be picking from the alternatives in an inappropriate way. Some of this is relevant to (all?) other forms of port building as well. Some basic questions will be: A) ZFS vs. UFS? (There are some configuration setting(s) dependent on which.) I currently have examples of both: I've started experimenting with ZFS again in some contexts, after years of not using it. No individual context is using a mix of both and I use ZFS in contexts with >= 8 GiBytes of RAM. I do not try to tune it for small memory contexts (small on ZFS's scale). B) How a builder establishes a world-context to execute in? For reasons of testing patches and such I build and install a world into a directory tree and have poudriere use that tree instead of poudriere installing or even building its own world in a tree. (And I've never done it any other way.) I do this with separate world-trees for aarch64 vs. armv7 on an aarch64 system so I build for armv7 in a faster context with more RAM and then transfer materials to the armv7 system for pkg to use for pkg commands. (I've not set up a server/client context.) You could, of course, just deal with "native" and ignore the RPi* aarch64's supporting doing armv7 builds. I use the same buildworld for updating the running kernel and world and for installing the world used for poudriere when the same OS vintage/variation is to be used for both. If you prebuild, there will be questions of what paths you want to use to reference the for-poudriere build trees. C) How a builder establishes a ports tree? For reasons of testing patches and such I have a /usr/ports tree of my own (sometimes under another name) and have poudriere use that tree instead of making its own. (And I've never done it any other way.) I use the same /usr/ports for both aarch64 and armv7, so only the one copy. You might want a different path than /usr/ports if you pre-establish the ports tree. D) What FreeBSD versions to target? I do not happen to use ports that must track the kernel version in detail so I can target a releng/13's release/13.?.? and use the ports for stable/13 as well. In fact, I can generally get away with using those same ports on main [so: 14], being explicit about the ABI for the pkg commands. You might use ports to drive displays and such in a way that leaves you required to track kernel versions more closely. But if it is only RPi*'s, then may be not for that. But there are other ports around that violate the clean separation vs. kernel details. To some extent this gets into "how many builds to cover all the systems?". That in turn can influence how the systems are set up, such as to eliminate some builds being needed. Your context might be simple, with only one type of context to cover. E) Build as root? As non-root? I happen to only have done build as root but the systems are not used for other activities. There could be ownership/permission issues that I've
