Re: Port upgrade: dead in the water

[Kyle Evans]

On Fri, Jan 15, 2021 at 10:00 PM Greg 'groggy' Lehey  wrote:
>
> After years I have finally got round to upgrading my main computer.
> My intention is to upgrade the ports as well, but pkg doesn't want to
> play nice:
>
>   # pkg-static install -f pkg
>   pkg-static: Warning: Major OS version upgrade detected.  Running 
> "pkg-static install -f pkg" recommended
>   Updating FreeBSD repository catalogue...
>   pkg-static: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2
>   pkg-static: Repository FreeBSD load error: meta cannot be loaded No error: 0
>   Fetching meta.txz: 100%916 B   0.9kB/s00:01
>   pkg-static: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2
>   repository FreeBSD has no meta file, using default settings
>   Fetching packagesite.txz: 100%6 MiB 582.8kB/s00:11
>   pkg-static: repository meta /var/db/pkg/FreeBSD.meta has wrong version 2
>   pkg-static: Repository FreeBSD load error: meta cannot be loaded No error: 0
>   Unable to open created repository FreeBSD
>   Unable to update repository FreeBSD
>   Error updating repositories!
>
> I'm happy to blow everything away, but is there a way to extract
> something that pkg can use to determine which packages to install?

`pkg bootstrap -f` should recover pkg to something usable
___
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: [package - main-i386-default][sysutils/env4801] Failed for env4801-0.3_1 in build

[Kyle Evans]

On Tue, Jan 12, 2021 at 8:20 AM Patrick M. Hausen  wrote:
>
> Dear ports gurus,
>
> what am I doing wrong that makes me still receive this message every couple 
> of days?
>
> > Von: pkg-fall...@freebsd.org
> > Betreff: [package - main-i386-default][sysutils/env4801] Failed for 
> > env4801-0.3_1 in build
> > Datum: 12. Januar 2021 um 15:05:07 MEZ
> > An: p...@hausen.com
> > Kopie: pkg-fall...@freebsd.org
> >
> > ===
> > ===>  Building for env4801-0.3_1
> > make[1]: "/usr/share/mk/bsd.opts.mk" line 110: "NO_MAN is defined, but 
> > deprecated. Please use MK_MAN=no instead."
>
> The issue should be fixed since mid November:
>
> https://svnweb.freebsd.org/ports/head/sysutils/env4801/Makefile?r1=418715=554829
>

This failure in particular stems from line 5 of the Makefile inside the dist:

NO_MAN= sorry

The MK_MAN in the port makefile should probably go away entirely, and
this NO_MAN= sorry should be replaced with MK_MAN=no
___
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: java/openjdk8 failed with "Undefined symbol "regcomp@FBSD_1.6""

[Kyle Evans]

On Thu, Nov 26, 2020 at 6:48 PM Jonathan Chen  wrote:
>
> On Fri, 27 Nov 2020 at 11:33, KIRIYAMA Kazuhiko  wrote:
> [...]
> > ld-elf.so.1: /usr/local/bin/bash: Undefined symbol "regcomp@FBSD_1.6"
>
> Rebuild your bash port first, before attempting to build openjdk8
>

This is actually backwards, their bash port was built against a newer
libc than they have on their system. This is odd, too, because the
FBSD_1.6 version of this symbol predates r367712 by quite a bit.
Something hinky is going on with their base system, but libc must be
rebuilt at a minimum.

Thanks,

Kyle Evans
___
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: Installing or updating jails fail with cp/utils.c error

[Kyle Evans]

On Tue, Oct 6, 2020 at 2:30 PM Rainer Hurling  wrote:
>
> On 02.10.20 11:19, Rainer Hurling wrote:
> > For some time now, I get the following error when trying to create or
> > update 11.4 or 12.2 jails in Poudriere:
> >
> >
> > #poudriere jail -c -j F114i386 -v stable/11 -a i386 -m svn+https
> >
> > [..snip..]
> > --- all_subdir_rescue ---
> > --- /poudriere/jails/F114i386/usr/src/bin/cp/utils.o ---
> > cc  -O2 -pipe   -std=gnu99-Qunused-arguments   -O2 -pipe -c
> > /poudriere/jails/F114i386/usr/src/bin/cp/utils.c -o
> > /poudriere/jails/F114i386/usr/src/bin/cp/utils.o
> > /poudriere/jails/F114i386/usr/src/bin/cp/utils.c:515:14: error: member
> > reference base type 'void' is not a structure or union
> > aclp = >ats_acl;
> > ~~~^ ~~~
> > /poudriere/jails/F114i386/usr/src/bin/cp/utils.c:516:11: error:
> > incomplete definition of type 'struct acl'
> > if (aclp->acl_cnt != 0 && aclsetf(dest_dir,
> > ^
> > /poudriere/jails/F114i386/usr/src/bin/cp/utils.c:466:9: note: forward
> > declaration of 'struct acl'
> > struct acl *aclp;
> >^
> > 2 errors generated.
> > *** [/poudriere/jails/F114i386/usr/src/bin/cp/utils.o] Error code 1
> >
> > make[5]: stopped in
> > /usr/obj/i386.i386/poudriere/jails/F114i386/usr/src/rescue/rescue
> >
> >
> > This happens on a recent 13.0-CURRENT amd64 (r366190). Updating HEAD
> > jails work fine so far.
>
> Just for the record:
>
> After updating my (host) box to 13.0-CURRENT r366466 (crunchgen: fix
> MK_AUTO_OBJ logic), I am able to install and update my jails versions
> 11.4 and 12.1 on Poudriere again.
>

Ah, my apologies for missing this report. :-( Indeed, that should be
the end of that; it will get MFC'd in ~2 days to mitigate the issue on
stable/12 since I MFC'd the breaking commit back, but the bug
fortunately did not make it into 12.2.

Thanks,

Kyle Evans
___
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: Patch compiler warnings away?

[Kyle Evans]

On Thu, Oct 1, 2020 at 4:12 PM Moritz Schmitt  wrote:
>
> Hi,
>
> I recently took over my first maintainership of a port and I have a
> question regarding on how to deal with compiler warnings.
>
> The port is devel/cscope and it seems to be in a rather good shape. It
> contains the newest version of cscope and it builds without any major
> problems. However, when building it the compiler issues three warnings
> that I could easily patch away.
>
> What's the recommended approach? Just ignore the warnings and don't
> modify the software since it builds anyway? Or create patches even
> though they don't seem to be strictly necessary?
>
> In any case, I will send the patches to the project in the hope that
> they fix it upstream in the long run.
>

This is kind of your prerogative as the maintainer to do whatever you
feel is right. Personally, I would usually not bother patching the
port if I can easily send it upstream and they don't look like actual
functional/security issues, *unless* I'm doing a version update
anyways that would cause folks to rebuild the port -- then I might
tack them on at the same time just so I can later point to the port
and say "Hey, we've been running with these and everything is (fine /
on fire)!"

In any event, +1 for sending them upstream regardless. :-)
___
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: math/reduce: could use some help with recent current failure

[Kyle Evans]

On Sun, Aug 30, 2020 at 11:15 AM Pedro Giffuni  wrote:
>
> Hello;
>
> math/reduce appears broken on pkg-fallout due to the recent LLVM upgrade.
>
> It seems like an lld issue:
>
> > ld: error: duplicate symbol: MeToReduce
> >>>> defined at redchild.c
> >>>>rfpsl-redchild.o:(MeToReduce)
> >>>> defined at reddeb.c
> >>>>rfpsl-reddeb.o:(.bss+0x4)
> > ld: error: duplicate symbol: ReduceToMe
>
> Also, I have an updated port here:
>
> https://people.freebsd.org/~pfg/ports/math-reduce.diff
>
>
> I have tried both -fno-common and LLVM11 but I can't reproduce the
> failure, so if someone with -current wants to try, it would be helpful.
>

Hi,

Unfortunately I couldn't convince the update to build (for mysterious
reasons, and I didn't have much time to diagnose), so I wrote (then
realized it was technically backported) the patch that upstream
provided in late May [0] and committed that. This works out well
because that can be MFH'd, then we can circle back on the update
soon-ish.

Patch was committed in r547124.

Thanks,

Kyle Evans

[0] https://sourceforge.net/p/reduce-algebra/code/5307/
___
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 failing with -fno-common with clang 9/gcc 9

[Kyle Evans]

On Mon, Jun 22, 2020 at 1:35 AM Tobias Kortkamp  wrote:
>
> On Thu, Apr 30, 2020, at 14:56, Kyle Evans wrote:
> > In any event, I would urge folks to be proactive and identify this
> > stuff, reporting issues upstream and spreading awareness of the
> > impending default change for those projects that may not already be
> > actively aware.
> >
> > On a closing note, I'm just going to kinda drop these patches here for
> > anyone that's willing/able to help make this a collective effort to
> > identify/fix/report problems here; they backport the default
> > -fno-common patch from future-LLVM11 to the base system compiler on a
> > system near you:
> >
> > HEAD: https://people.freebsd.org/~kevans/llvm-fnocommon-head.diff
>
> Can you ask for an exp-run with this patch applied?  There needs
> to be a comprehensive list of failing ports for people to be able
> to work on this.  We see some failing ports because of default
> -fno-common in GCC 10 [1] already.
>
> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246700

I can, but my only problem in doing so is that I cannot take
responsibility for following up on the issues discovered. I have some
outstanding exp-run that I've dropped the ball on, I'm a bit wobbly on
personally requesting one for this unless some group of people
can/will offer to make sure the issues are fixed so that the exp-run
can actually be completed in a reasonable timeframe.

Thanks,

Kyle Evans
___
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 failing with -fno-common with clang 9/gcc 9

[Kyle Evans]

On Thu, Apr 30, 2020 at 2:20 AM Dewayne Geraghty
 wrote:
>
> As -fno-common will become the default in gcc10/llvm11 per
> https://lists.freebsd.org/pipermail/svn-src-stable-12/2020-April/004761.html
>

First- thanks! It's nice to see confirmation that the messages being
written here aren't just being broadcasted to the void, doubly so when
said confirmation is in the form of e-mails like this. :-)

> I thought I might share the list of ports that failed to build for
> maintainers to be aware of using -fno-common:
>
> I'm sorry this is a small list but I only use 1488 ports.

Indeed, it looks like a small list, but you've just identified 42
problems to work on while only using ~5% (? based on 30,000 ports,
which I know is probably low) of the ports tree.

That is to say, I think this speaks to the magnitude of the issue
we're dealing with here. Many will escape unscathed, but it's a good
idea for everyone to start taking action *now* to identify and fix or
report these so that we're not overloading our relatively small group
of toolchain folks in the next ~6 months. My experience in base
revealed that most of the third party software we had there was
already aware of the coming change and had patches to accommodate, so:

- For projects with a faster release cadence, this may be easily
overcome by events
- For projects with a slower release cadence, you may find patches
that can be or have been backported

In any event, I would urge folks to be proactive and identify this
stuff, reporting issues upstream and spreading awareness of the
impending default change for those projects that may not already be
actively aware.

On a closing note, I'm just going to kinda drop these patches here for
anyone that's willing/able to help make this a collective effort to
identify/fix/report problems here; they backport the default
-fno-common patch from future-LLVM11 to the base system compiler on a
system near you:

HEAD: https://people.freebsd.org/~kevans/llvm-fnocommon-head.diff
stable/12: https://people.freebsd.org/~kevans/llvm-fnocommon-12.diff

**Note that FreeBSD branches earlier than these (in the past couple of
weeks!) will not fully build with this patch applied:**

- r360072 (head)
- r360496 (stable/12)
- r360494 (stable/11)

Userland builds (all that's needed for most poudriere jails) should be
fine in the past couple of weeks earlier than those commits, but no
active releases will build with these patches applied.

Folks can feel free to tag me in -fno-common related PRs if assistance
is needed for any reason.

Thanks,

Kyle Evans
___
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: FreeBSD Port: devel/py-subversion - Python 3 flavor?

[Kyle Evans]

On Thu, Apr 23, 2020 at 9:43 AM Dan Langille  wrote:
>
> Hello Lev,
>
> Do you know of anything preventing devel/py-subversion from working with 
> Python 3?
>
> I ask because devel/py-subversion at present requires Python 2.7 which is 
> past EOL.
>
> While I was typing this, I thought: I should just try it first.
>
> I failed:
>
> https://services.unixathome.org/poudriere/data/121amd64-dvl/2020-04-23_14h34m22s/logs/errors/py37-subversion-1.13.0.log
>
> ModuleNotFoundError: No module named 'libsvn._core'
>
> Ideas?
>

Hi,

The last time I asked/checked, it was decided that upstream doesn't
yet support Python 3 completely but some parts did. FWIW, this should
be of general interest to the FreeBSD community since this one's used
in our repo commit hooks. I think, ideally, clusteradm wouldn't need
to retain the python2 version of this after python2 gets kicked out of
the ports tree.

Thanks,

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

Re: [devel/arduino18] Adding a new board description.

[Kyle Evans]

On Tue, Mar 5, 2019 at 4:49 AM Peter Jeremy  wrote:
>
> On 2019-Mar-04 08:36:52 -0600, Kyle Evans  wrote:
> >I'll find some time this week to see what I can do to bring the board
> >manager back. It was removed when I initially ported Arduino 1.6.x
> >because there was some conflict in the functionality itself with how
> >we patch other bits, but I'm foggy on the details at this point
> >because that's been a couple years.
>
> I had a go at re-enabling the board manager and ran into a problem with
> package_index.json.  The port installs native versions of all the IDE
> dependencies, creates links from /usr/local/arduino/tools-builder to the
> native versions and hand-crafts a package_index_bundled.json that says the
> tool runs on the appropriate FreeBSD version (amd64-freebsd12 in my case).
> If I start the board manages, the IDE downloads fresh copy of package data
> and installs it as ~/.arduino15/package_index.json - this version is
> unpatched and therefore only lists the "supported" tool versions (Linux,
> MacOS & Windows), leading to a null pointer exception.
>

Right, I'm starting to remember the details now... they want to
package all of these things up for the platforms they officially
support, but we're not a supported platform so the system absolutely
freaks out and it was a very large rabbit hole (at the time) to go
down for making any of this work. I haven't started the support
conversation yet upstream -- by the time I got all of my other work
upstreamed, I ran out of time to pursue that.

I had asked if I can add some concept of 'unsupported platforms' to
the IDE to bypass a lot of the checks that they do, but I had received
no response and ran out of time to follow-up.

> Interestingly, the release notes for 1.8.2 include:
> * Allow BoardManager to fetch FreeBSD tools (thanks @kevans91)
> so it seems you have previously fixed the board manager, but the fix
> no longer works.
>

This was my start at getting to where we need to be to stop patching
out this functionality, but it turns out there's a lot more hurdles to
talk about.

The path forward for you is unfortunately going to be hacking it out
locally, or we can look at patching it into the arduino-core port. The
level of effort kind of depends on whether it's AVR/SAM/SAMD core or
another core that we don't currently package -- needs range from
patching the core's boards.txt to porting a new core (relatively
easily also).
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [devel/arduino18] Adding a new board description.

[Kyle Evans]

On Mon, Mar 4, 2019 at 4:37 AM Peter Jeremy  wrote:
>
> I'm trying to use devel/arduino18 with a non-standard board - which
> requires installing a new board description.  According to the board
> documentation, the process is to enter the URL for the new board
> description in the Preferences, then go to Tools -> Board -> Boards
> Manager to actually install the definitions.  My difficulty is that
> the above option doesn't exist because the patches included with ports
> r438914 delete all the relevant code.
>
> I haven't found any discussion as to why the boards manager was removed
> or what the alternatives are for installing new board descriptions.
>
> Can anyone advise the process for adding new board descriptions?
>

(a CC is appreciated; most posts to this list get filtered locally otherwise...)

I'll find some time this week to see what I can do to bring the board
manager back. It was removed when I initially ported Arduino 1.6.x
because there was some conflict in the functionality itself with how
we patch other bits, but I'm foggy on the details at this point
because that's been a couple years.
___
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: qemu-arm-static under amd64: example of stuck looping atomic_cmpset_int while building graphics/poppler-qt5 [a tested fix included]

[Kyle Evans]

On Wed, Jan 2, 2019 at 3:38 AM Mark Millard via freebsd-ports
 wrote:
>
> On 2019-Jan-1, at 18:43, Mark Millard  wrote:
>
> > The below showed up for poudiere-devel bulk getting stuck using one FreeBSD
> > cpu while building graphics/poppler-qt5 . This is not a kevent hang-up, 
> > unlike
> > the last hang-up that I analyzed. I do not yet know how repeatable this is
> > but the original hang-up and the one experiment the below is from.
> >
> > From top:
> >
> >  PID USERNAMETHR PRI NICE   SIZERES SWAP STATEC   TIME CPU 
> > COMMAND
> > 12789 root  4  520   166M33M0 uwait6  36:06  97.22% 
> > /usr/local/bin/qemu-arm-static /usr/local/bin/cmake -E cmake_autogen 
> > /wrkdirs/usr/ports/graphics/poppler-qt5/work/poppler-0
> >
> > Note: The vast margority of the 36:06 has been stuck in the uwait loop 
> > involved.
> >
> > From ps -auxd:
> >
> > root   940750.0  0.0  12932  3552  1  S+   10:420:01.21 |   
> > `-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 -w 
> > graphics/poppler-qt5
> > root19440.0  0.0  12932  3540  1  I+   10:420:00.00 |   
> >   |-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 
> > -w graphics/poppler-qt5
> > root19570.0  0.0  12932  3556  1  I10:420:00.04 |   
> >   |-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg 
> > (poppler-qt5-0.72.0) (sh)
> > root   123280.0  0.0  12932  3548  1  I10:490:00.00 |   
> >   | `-- sh: poudriere[FBSDFSSDjailArmV7-default][01]: build_pkg 
> > (poppler-qt5-0.72.0) (sh)
> > root   123290.0  0.0  10328  1756  1  IJ   10:490:00.01 |   
> >   |   `-- /usr/bin/make -C /usr/ports/graphics/poppler-qt5 stage
> > root   123500.0  0.0   9860  1248  1  IJ   10:490:00.00 |   
> >   | `-- /usr/bin/make -f Makefile 
> > DESTDIR=/wrkdirs/usr/ports/graphics/poppler-qt5/work/stage install
> > root   123530.0  0.0  10236  1664  1  IJ   10:490:00.05 |   
> >   |   `-- /nxb-bin/usr/bin/make -f CMakeFiles/Makefile2 qt5/all
> > root   127870.0  0.0   9856  1236  1  IJ   10:500:00.00 |   
> >   | `-- /nxb-bin/usr/bin/make -f 
> > qt5/tests/CMakeFiles/check_qt5_attachments_autogen.dir/build.make qt5/test
> > root   12789  100.0  0.0 169868 33528  1  IJ   10:50   36:35.26 |   
> >   |   `-- /usr/local/bin/qemu-arm-static 
> > /usr/local/bin/cmake -E cmake_autogen /wrkdirs/usr/ports/graphics/
> > root   944230.0  0.0  12932  3484  1  S+   10:420:12.91 |   
> >   `-- sh -e /usr/local/share/poudriere/bulk.sh -jFBSDFSSDjailArmV7 
> > -w graphics/poppler-qt5
> >
> >
> > (gdb) attach 12789
> > Attaching to process 12789
> > Reading symbols from 
> > /usr/local/poudriere/data/.m/FBSDFSSDjailArmV7-default/01/usr/local/bin/qemu-arm-static...done.
> > [New LWP 101168 of process 12789]
> > [New LWP 101178 of process 12789]
> > [New LWP 101499 of process 12789]
> > [Switching to LWP 100304 of process 12789]
> > _umtx_op () at _umtx_op.S:3
> > 3 RSYSCALL(_umtx_op)
> > (gdb) info threads
> >  Id   Target Id   Frame
> > * 1LWP 100304 of process 12789 _umtx_op () at _umtx_op.S:3
> >  2LWP 101168 of process 12789 _umtx_op_err () at 
> > /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
> >  3LWP 101178 of process 12789 _umtx_op () at _umtx_op.S:3
> >  4LWP 101499 of process 12789 0x60051c26 in atomic_cmpset_int 
> > (dst=, expect=, src=536870912) at 
> > /usr/include/machine/atomic.h:220
> > (gdb) thread 4
> > [Switching to thread 4 (LWP 101499 of process 12789)]
> > #0  0x60051c26 in atomic_cmpset_int (dst=, 
> > expect=, src=536870912) at /usr/include/machine/atomic.h:220
> > 220   ATOMIC_CMPSET(int);
> >
> > (gdb) bt
> > #0  0x60051c26 in atomic_cmpset_int (dst=, 
> > expect=, src=536870912) at /usr/include/machine/atomic.h:220
> > #1  tcmpset_32 (addr=, a=, b=536870912) at 
> > /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:178
> > #2  freebsd_rw_unlock (target_addr=4108246528) at 
> > /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.c:1264
> > #3  0x6004ab33 in do_freebsd__umtx_op (obj=, 
> > op=536870912, val=, uaddr=, 
> > target_time=)
> >at 
> > /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/freebsd/os-thread.h:474
> > #4  0x60041b83 in do_freebsd_syscall (cpu_env=0x86159b118, num=454, 
> > arg1=, arg2=, arg3=, arg4=0, 
> > arg5=0, arg6=-184411592, arg7=-199471616,
> >arg8=-1622188640) at 
> > /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/syscall.c:1364
> > #5  0x600392f0 in target_cpu_loop (env=0x86159b118) at 
> > 

Re: Upgrade of security/openssl111 fails to install

[Kyle Evans]

On Wed, Nov 21, 2018 at 9:53 AM  wrote:
>
> Hello,
>
> After upgrading my packages with poudriere, the updated version
> (1.1.1.a) is not installed by pkg(8). Apparently, because of the
> versioning, it's seen as a downgrade:
>
> root@teresa:~ # pkg upgrade
> Updating poudriere-php56-openssl111 repository catalogue...
> poudriere-php56-openssl111 repository is up to date.
> All repositories are up to date.
> Checking for upgrades (1 candidates): 100%
> Processing candidates (1 candidates): 100%
> Checking integrity... done (0 conflicting)
> Your packages are up to date.
>
>
> root@teresa:~ # pkg upgrade -f openssl111
> Updating poudriere-php56-openssl111 repository catalogue...
> poudriere-php56-openssl111 repository is up to date.
> All repositories are up to date.
> Checking integrity... done (0 conflicting)
> The following 1 package(s) will be affected (of 0 checked):
>
> Installed packages to be DOWNGRADED:
> openssl111: 1.1.1_2 -> 1.1.1.a [poudriere-php56-openssl111]
>
> Number of packages to be downgraded: 1
>
> Proceed with this action? [Y/n]:
>

This should be corrected in the next build; mat@ fixed the version in r485516
___
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: qemu-arm-static: bsd-user/arm/target_syscall.h: #define TARGET_HW_MACHINE_ARCH "armv6" // what of armv7?

[Kyle Evans]

On Mon, Nov 12, 2018 at 10:41 PM Mark Millard  wrote:
>
> 11.x:
> o 11.2-STABLE armv6 BANANAPI
> o 11.2-STABLE armv6 BEAGLEBONE
> o 11.2-STABLE armv6 CUBIEBOARD
> o 11.2-STABLE armv6 CUBIEBOARD2
> o 11.2-STABLE armv6 CUBOX-HUMMINGBOARD
> o 11.2-STABLE armv6 RPI-B
> o 11.2-STABLE armv6 RPI2
> o 11.2-STABLE armv6 PANDABOARD
> o 11.2-STABLE armv6 WANDBOARD
>
> 12.x+ (I got the list from a 13.0 snapshot announcement):
> o 13.0-CURRENT armv6 RPI-B
> o 13.0-CURRENT armv7 BANANAPI
> o 13.0-CURRENT armv7 BEAGLEBONE
> o 13.0-CURRENT armv7 CUBIEBOARD
> o 13.0-CURRENT armv7 CUBIEBOARD2
> o 13.0-CURRENT armv7 CUBOX-HUMMINGBOARD
> o 13.0-CURRENT armv7 RPI2
> o 13.0-CURRENT armv7 PANDABOARD
> o 13.0-CURRENT armv7 WANDBOARD
> o 13.0-CURRENT armv7 GENERICSD
>
> So as of 12.x+ most are armv7 --as are most new ones
> expected to be.
>
> As stands, in my amd64 -> armv7 13.0 cross-build activity,
> uname -p and the like under the chroot context are
> returning armv6 instead of armv7 unless I override via
> a UNAME_p definition.
>
> This appears to trace back to: bsd-user/arm/target_syscall.h
> and its:
>
> #define TARGET_HW_MACHINE   "arm"
> #define TARGET_HW_MACHINE_ARCH  "armv6"
>
> and lack context sensitivity, such as to the FreeBSD version
> that it is in use under.
>

Indeed, I opened this a couple of hours ago:
https://github.com/seanbruno/qemu-bsd-user/pull/70 -- It turns out
this is basically wrong, though I'm not sure immediately how to
rectify. I don't think we can reasonably decide at compile-time what
this should look like since all 32-bit ARM are shoved into this one
target, so perhaps the right answer is that armv6 and armv7 need to
split off from arm.arm and we use a check like the one in the above
PR. CC'ing imp for a wisdom drop.
___
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: FYI: ports head -r484783 poudriere-devel with qemu-arm-static: sometimes hangs between a cc (wait) and its child ld (uwait)

[Kyle Evans]

On Sun, Nov 11, 2018 at 9:11 PM Mark Millard  wrote:
>
> [I still can not produce the problem below on demand.
> It seems racy with no fixed context producing the
> problem as far as which port is building. But the
> general structure of what hangs is the same each
> time so far.]
>
> The following is just an FYI for the other
> qemu-arm-static tied problem that I regularly run into.
> I do not have much useful information so far. It is
> not clear how I'd get such information.
>

Hi,

Just so we're clear- in what kind of time frame did you start
observing this hang?

Thanks,

Kyle Evans
___
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 -r484565 : qemu-arm-static fails with: (start < end): backtrace included; start+len arithmetic overflow (abi_ulong wrap) for TARGET_FREEBSD_NR_mmap use

[Kyle Evans]

On Sun, Nov 11, 2018 at 5:24 AM Mark Millard  wrote:
>
> I attached with gdb in order to stop at the assert and look around.
>
>
>
> The following is a backtrace with notes and prints mixed in:
>
> (gdb) bt
> #0  thr_kill () at thr_kill.S:3
> #1  0x6028a21f in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
> #2  0x60204949 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
> #3  0x6027855a in __assert (func=, file= out>, line=, failedexpr=) at 
> /usr/src/lib/libc/gen/assert.c:51
>
> Note end==37146624 below vs. start (37146624 will show up again in later 
> notes)
>
> #4  0x60036243 in page_set_flags (start=4143968256, end=37146624, 
> flags=9) at 
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-2cb0cdd/accel/tcg/translate-all.c:2077
>
> Note start and len below:
>
> #5  0x6003df2b in target_mmap (start=4143968256, len=188145664, 
> prot=, flags=, fd=, 
> offset=)
> at 
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-2cb0cdd/bsd-user/mmap.c:626
>
> (gdb) print/x start
> $5 = 0xf6fff000
> (gdb) print/x len
> $6 = 0xb36e000
>
> Note start+len for the above (without wrapping):
>
> (gdb) print/x (long long)start + (long long)len
> $10 = 0x10236d000
> (gdb) print (long long)start + (long long)len
> $11 = 4332113920
>
> With wrapping:
>
> (gdb) print/x start+len
> $8 = 0x236d000
> (gdb) print start+len
> $9 = 37146624
>
> And there is end's value again.
>

Hi,

This should be fixed as of ports r484702; please do try this and let
us know how it goes.

Thanks,

Kyle Evans
___
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 -r484565 : qemu-arm-static fails with: (start < end): backtrace included; start+len arithmetic overflow (abi_ulong wrap) for TARGET_FREEBSD_NR_mmap use

[Kyle Evans]

On Sun, Nov 11, 2018 at 5:24 AM Mark Millard  wrote:
>
> I attached with gdb in order to stop at the assert and look around.
>
>
>
> The following is a backtrace with notes and prints mixed in:
>
> (gdb) bt
> #0  thr_kill () at thr_kill.S:3
> #1  0x6028a21f in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
> #2  0x60204949 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
> #3  0x6027855a in __assert (func=, file= out>, line=, failedexpr=) at 
> /usr/src/lib/libc/gen/assert.c:51
>
> Note end==37146624 below vs. start (37146624 will show up again in later 
> notes)
>
> #4  0x60036243 in page_set_flags (start=4143968256, end=37146624, 
> flags=9) at 
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-2cb0cdd/accel/tcg/translate-all.c:2077
>
> Note start and len below:
>
> #5  0x6003df2b in target_mmap (start=4143968256, len=188145664, 
> prot=, flags=, fd=, 
> offset=)
> at 
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-2cb0cdd/bsd-user/mmap.c:626
>
> (gdb) print/x start
> $5 = 0xf6fff000
> (gdb) print/x len
> $6 = 0xb36e000
>

Ahhh, I see where I messed up. I will whip up a patch ASAP to fix. Thanks!
___
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 -r484565 : qemu-arm-static fails with: (start < end), function page_set_flags, file . . . accel/tcg/translate-all.c, line 2077

[Kyle Evans]

On Sat, Nov 10, 2018 at 4:30 PM Mark Millard  wrote:
>
> On 2018-Nov-10, at 12:28, Kyle Evans  wrote:
>
> > On Sat, Nov 10, 2018 at 11:38 AM Mark Millard via freebsd-ports
> >  wrote:
> >>
> >> Having actually installed the reverted code fist ( -r438807 ),
> >> cmake's package stage is now well past were it was failing.
> >>
> >> So it is not the pkg vintage that matters: it is the qemu-sbruno
> >> vintage that matters.
> >>
> >> (gcc8 getting that far is hours away: full bootstrap, so mostly
> >> emulated.)
> >>
> >
> > I find the assertion you've reported fairly bizarre, since all of the
> > page_set_flags invocations we would've touched are generally of the
> > form `page_set_flags(start, start + len, ...)` -- I'm working on
> > reproducing locally, though.
>
> Looking at the overall sources for the two versions ( as seen via
> -r483807 and -r484565 ) I find a possibly-significant changed file:
>
> # diff -u 
> /wrkdirs/usr/ports/emulators/qemu-user-static/*work/qemu-bsd-user-*/bsd-user/mmap.c
>  | more
> --- 
> /wrkdirs/usr/ports/emulators/qemu-user-static/483807-work/qemu-bsd-user-495fb3a/bsd-user/mmap.c
>  2018-05-25 07:28:13.0 -0700
> +++ 
> /wrkdirs/usr/ports/emulators/qemu-user-static/484565-work/qemu-bsd-user-2cb0cdd/bsd-user/mmap.c
>  2018-11-09 09:27:18.0 -0800
>

Yes, I'm familiar with this particular changeset- I wrote it. =)
Unfortunately, I can't reproduce this locally- neither with
devel/cmake nor any of the other ports that I build.  I think we'll
have to wait until either we get more reports of this or portmgr@
trips over it in a way that I can reproduce and dig in a bit.

Thanks,

Kyle Evans
___
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"

Recent patch(1) update

[Kyle Evans]

Hello!

I've recently fixed a bug in patch(1) that caused patches with limited
context to be misapplied under some circumstances. Patches that were
candidates to be misapplied either had low context with respect to the
default max fuzzing (-U0 / -U1) or had lower context due to being near the
beginning/end of a file.

The fix was applied in base r326084; please test port updates with an
updated patch(1) to avoid build failures on -HEAD.

A sweep of the ports tree was done by portmgr@ to correct current cases of
these candidate patches.

Thanks,

Kyle Evans
___
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: Crashing chromium/iridium

[Kyle Evans]

For reference: there's been some escalation of this by asmodai@ (I think --
don't quote me on this): https://bugs.chromium.org/p/chromium/issues/detail?
id=729534 -- asmodai@ was requesting some help in further debugging, but
unfortunately does not seem to have received any help in that regard.


On Fri, Oct 6, 2017 at 2:40 PM, Domagoj Stolfa 
wrote:

> I’ve found this to be an issue as well. None of the things that I’ve seen
> suggested online could fix it, and unfortunately do not have time to look
> at it myself. I’d be interested to hear if anyone has any more details
> regarding this issue.
>
> —
> Domagoj
>
> > On 6 Oct 2017, at 20:39, Grzegorz Junka  wrote:
> >
> > Just wanted to check if anybody else observed this annoying behaviour in
> Chromium/Iridium browsers. Randomly, in about 10-40% of cases, the new tab
> hangs loading for 30-60 seconds, after which time the browser shows a
> dialog that the webpage doesn't load and I can either kill or wait.
> >
> > There is no pattern, sometimes I can open 10 tabs with no issues, but
> sometimes 10 tabs hang in a row and need to be killed. Very often when I
> kill the page reloading the page doesn't help, it still hangs, but when I
> open the same URL in a new tab it works. Sometimes, however, reloading the
> page also works.
> >
> > I compiled and installed Iridium hoping that it will be free from this
> bug but it seems that the behaviour is exactly the same as in Chromium. It
> has been happening for the past year at least. Maybe some of the options I
> checked for Chromium/Iridium don't work well or maybe some of its
> dependencies are compiled with options that don't work well. How would I
> investigate it?
> >
> > I didn't try to install precompiled versions. Also, the issue doesn't
> happen with other browsers (Firefox, any other I could compile on FreeBSD
> are also fine). I tried to open in safe mode, without extensions, but all
> without any difference in this behaviour.
> >
> > Thanks
> >
> > GrzegorzJ
>
___
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: [RFC] less patches: control the PATH

[Kyle Evans]

On Oct 6, 2017 8:24 AM, "Guido Falsi"  wrote:

On 10/06/2017 15:11, Baptiste Daroussin wrote:
> Hi all,
>
> Here is a patch to add a new feature I am willing to get for a while:
> https://reviews.freebsd.org/D12603

> A user can control which binary will be found in the PATH of the build
sequences
> easily by adding
> BINARY_RENAME=source target

> PS2: the BINARY_RENAME variable name sucks, any better name is welcome :)
>

Suggestions from the top of my head:

BINARY_ALIAS

PROGRAM_ALIAS

EXECUTABLE_ALIAS

COMMAND_ALIAS

(Yes I think "alias" expresses the concept better)

--
Guido Falsi 


+1 for BINARY_ALIAS; concise, descriptive, and accurate
___
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: Some github projects aren't fetchable using commit hash

[Kyle Evans]

On Sep 4, 2017 00:29, "Shane Ambler"  wrote:

For a port the distinfo will detect a hash and size difference of the
tarball and fail.


Yeah, but in the more general sense from a GitHub consumer point of view, I
may not notice immediately and if the build process hasn't changed I most
likely won't be expecting the final result.
___
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: Some github projects aren't fetchable using commit hash

[Kyle Evans]

On Sep 1, 2017 20:03, "Shane Ambler"  wrote:


Respond to github support that an abbreviated hash with multiple matches
will fail. Under that condition, it may be desirable to respond with the
newest of the matches rather than a not found error.


To be honest, the failing seems like a little better behavior than suddenly
swapping out the package I thought I was downloading with a newer version.
It'd at least be a little more obvious and theoretically detectable if they
respond properly.
___
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: JAVA_VERSION???

[Kyle Evans]

On Fri, Jun 16, 2017 at 12:50 PM, Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:

>
> Kyle,
>
> Thanks.  That patch fixes the problem with the spurious error
> message.
> 
>

Excellent, I'll file a PR with this patch. You're using bsdgrep and it
hasn't regrown GNU extensions yet, which bsd.java.mk is dependent upon.
We've changed a lot of things to use POSIX compliant expressions, but it
seems that we've not yet caught them all. Sorry for the trouble!
___
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: JAVA_VERSION???

[Kyle Evans]

On Fri, Jun 16, 2017 at 12:34 PM, Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:

> On Fri, Jun 16, 2017 at 05:07:30PM +0200, Mathieu Arnold wrote:
> > Le 16/06/2017 à 16:43, Steve Kargl a écrit :
> > > On Fri, Jun 16, 2017 at 02:17:03PM +0200, Mathieu Arnold wrote:
> > >> Le 16/06/2017 à 01:45, Steve Kargl a écrit :
> > >>> Is this the expected behavior?
> > >>>
> > >>> % cd ports/math/octave
> > >>> % make fetch
> > >>> octave-4.0.3_5: Makefile error: "1.7+" is not a valid value for
> JAVA_VERSION. It should be one or more of: 1.6 1.7 1.8 (with an optional
> "+" suffix.)
> > >>> % grep JAVA_VERSION Makefile
> > >>> JAVA_VERSION=   1.7+
> > >>
> > >> Not really. What OSVERSION are you running?
> > >>
> > >> What is the content of the _JAVA_VERSION_LIST and
> > >> _JAVA_VERSION_LIST_REGEXP variables ?
> > >>
> > > I'm running a month old freebsd-current.
> > >
> > > % uname -a
> > > FreeBSD troutmask.apl.washington.edu 12.0-CURRENT FreeBSD 12.0-CURRENT
> > > #0 r318546: Fri May 19 12:51:04 PDT 2017
> > >
> > > % cd /usr/ports/math/octave
> > > % make -d v fetch |& grep JAVA_VERSION
> >
> > $ make -V _JAVA_VERSION_LIST
> > 1.6 1.7 1.8 1.6+ 1.7+ 1.8+
> > $ make -V _JAVA_VERSION_LIST_REGEXP
> > 1.6\|1.7\|1.8\|1.6+\|1.7+\|1.8+
> >
> > You should get the same as me. I wonder if it is not a difference in how
> > grep behaves on 12 where it does not match 1.7+ with the regexp in there.
> >
>
> Yes, it appears to be a grep issue.  In Mk/bsd.java.mk, I removed
> the @ in line 227 to see what the test did.  I then try to reproduce
> just the part with grep (without the -q option) at a Bourne shell
> prompt.
>
> # echo "1.7+"
> 1.7+
> # echo "1.7+" | /usr/bin/tr " " "\n"
> 1.7+
> # echo "1.7+" | /usr/bin/tr " " "\n" | /usr/bin/grep
> "1.6\|1.7\|1.8\|1.6+\|1.7+\|1.8+"
> #
>
> So, nothing is returned.  If I reduce the regex pattern, I see
>
> # echo "1.7+" | /usr/bin/tr " " "\n" | /usr/bin/grep "1.7+"
> 1.7+
>
>
Hi,

Please try this patch applied to your bsd.java.mk:
https://files.kyle-evans.net/freebsd/java.diff

Thanks,

Kyle Evans
___
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: Licence practice for dependencies - making use of more restrictive licences optional

[Kyle Evans]

On Tue, Apr 25, 2017 at 11:07 PM, Dewayne Geraghty <
dewaynegerag...@gmail.com> wrote:

> The recent change to
> https://svnweb.freebsd.org/ports/head/dns/opendnssec13/
> Makefile?view=markup=439426 which uses BSD3Clause, while gnugrep
> uses GPLv3+; reminded me of a customer's requirement to remove GPLv3 code
> from a device they needed.
>

Hi,

FWIW, and I know the problem is more broad than this specific example but
to hopefully ease your concern in this respect- the working plan is to
re-evaluate all ports dependent on gnugrep when bsdgrep re-grows GNU
extension capabilities.

I hope to do this sooner rather than later- I currently have a working plan
detailed(-ish) on the wiki [1] for growing this functionality out of the
parser currently available in libc/regex without affecting the base
implementation's POSIX compliance and some patches toward this goal. I'm
presently working on some intermediate steps to this end to make for a
smooth transition.

[1] https://wiki.freebsd.org/LibRegex
___
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: recent change to vim defaults?

[Kyle Evans]

On Jan 15, 2017 10:03, "Julian Elischer" <jul...@freebsd.org> wrote:

I noticed that suddenly vim is grabbing mouse movements, which makes life
really hard.

Was there a specific revision that brought in this change, and can it be
removed?

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


Hi,

You might add "set mouse=v" to your vimrc -- it was a new default as of
8.0, IIRC. "set nohl" if the new highlighted of search matches irritates as
well.

Thanks,

Kyle Evans
___
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: HEADSUP: FLAVORS (initial version) and subpackages proposals

[Kyle Evans]

On Mon, Dec 19, 2016 at 2:45 AM, Matthew Seaman  wrote:
> Why can't you have both flavoured and unflavoured variants of the same
> port -- eg. devel/example as well as devel/example/foo and
> devel/example/bar ?

It seems like it would make sense to allow devel/example to be a
default flavor so that, for instantiated example, editors/vim-lite =>
editors/vim/lite and editors/vim could potentially be a 'full' flavor
or unflavored, if that's your flavor. I personally learn towards
default flavor, though, because that gives you a chance to be slightly
more descriptive.
___
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: private ports and pkgs versioning

[Kyle Evans]

On Tue, Oct 18, 2016 at 9:14 AM, Mark Linimon  wrote:
> On Tue, Oct 18, 2016 at 02:52:34PM +0100, Matthew Seaman wrote:
>> Hmmm... looks like this is handled in the 30 or so lines starting at
>> line 1179 of bsd.port.mk
>
> Wouldn't the patch to ports/Makefile just be the following?
>
> .if exists(${.CURDIR}/Makefile.local)
> .include "${.CURDIR}/Makefile.local"
> .endif
>
> Again, I _think_ this is only necessary if you are building INDEX.
>
> mcl
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

/usr/ports/Makefile.local is already included for consideration @
bsd.port.subdir.mk:142
___
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: qa.sh stripped warning

[Kyle Evans]

Hi,

On Wed, Oct 12, 2016 at 10:35 AM, Mathieu Arnold  wrote:
> The warning will never be turned into errors. Maybe add a comment to the
> makefile saying that files must not be stripped. Maybe a bit like go
> ports do it, something like:
>
> STRIP= # Elf firmwares, do not strip

Thanks for the suggestion! I've implemented this. Given the strong
wording you've used here (will never be turned into errors), would you
consider revising the comment @
https://svnweb.freebsd.org/ports/head/Mk/Scripts/qa.sh?view=markup#l191
? It's easy to derive uncertainty from the wording used in the
comment.
___
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"

qa.sh stripped warning

[Kyle Evans]

Hello!

I've got a port with a dozen+ ELF binaries for microcontroller
firmware that I don't think I should be stripping, but qa.sh does not
like this. They're *.elf and *.lib files, so I don't know that adding
these to the general exception of `find` in stripped() is necessarily
a good idea, but it seems like a way to add exceptions for this would
it be a good idea, whether it be through some setting in the port or
on a case-by-case basis in the pkg-plist.. thoughts?

My main concern here is that I don't intend to strip these, but the
comment for stripped() would leave me to believe that there's a chance
these warnings could eventually turn into errors, and I don't want
this to be the case if it's not something that should be stripped.

Thanks,

Kyle Evans
___
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: Help wanted for new port: linking error in FreeCAD

[Kyle Evans]

On Thu, Aug 11, 2016 at 11:50 AM, Pedro Giffuni <p...@freebsd.org> wrote:
>
>
> On 08/11/16 10:43, Kyle Evans wrote:
>>
>> On Thu, Aug 11, 2016 at 10:25 AM, Pedro Giffuni <p...@freebsd.org> wrote:
>>>
>>> Hello guys;
>>>
>>> I wanted to take a look at bringing back some old engineering glory to
>>> the
>>> ports trees by porting FreeCAD (from the Wanted Ports wiki).
>>>
>>> My initial attempt is here:
>>> https://people.freebsd.org/~pfg/ports/freecad.tgz
>>>
>>> Unfortunately it only reaches 71 % of the build and I would need the
>>> help of a CMake/linker expert to continue.
>>>
>>> The complete build log is here:
>>> https://people.freebsd.org/~pfg/ports/freecad-log.txt
>>>
>>> The relevant failure:
>>>
>>> ... [snip]
>>>
>>> Regards,
>>>
>>> Pedro.
>>> ___
>>> 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"
>>
>>
>> Looks like a missing declared dependency of libCoin.so from
>> graphics/Coin, which will likely/hopefully solve the problem --
>> graphics/Coin does include some pkgconfig magic.
>>
>
> Hmm .. I will add it explicitly but it is already installed
> through SoQt:
>
> % ls /usr/local/lib/libCoin*
> /usr/local/lib/libCoin.so /usr/local/lib/libCoinMP.so.1.8.3
> /usr/local/lib/libCoin.so.60 /usr/local/lib/libCoinUtils.so
> /usr/local/lib/libCoin.so.60.1.3 /usr/local/lib/libCoinUtils.so.3
> /usr/local/lib/libCoinMP.so /usr/local/lib/libCoinUtils.so.3.10.10
> /usr/local/lib/libCoinMP.so.1
>
> :(
>
> Pedro.

Hi,

Without diving too deeply into it for lack of time at the moment, I suspect
it's because of the stuff around /CMakeLists.txt:721 -- if I recall
correctly, find_package(Coin3D...) will do two things:

* Search for Coin3D.pc (in this case, in /usr/local/libdata/pkgconfig) to
aide in configuring it properly
* Set COIN3D_* variables, also based on this name

However, FreeCAD is expecting it to be Coin3D, where graphics/Coin gives us
Coin. As a first step, I would attempt a replacement on all CMakeLists.txt
in this project to replace COIN3D_ with COIN_, and then replace the
find_package Coin3D with Coin, see if that solves it.
___
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: Help wanted for new port: linking error in FreeCAD

[Kyle Evans]

On Thu, Aug 11, 2016 at 10:25 AM, Pedro Giffuni <p...@freebsd.org> wrote:
> Hello guys;
>
> I wanted to take a look at bringing back some old engineering glory to the
> ports trees by porting FreeCAD (from the Wanted Ports wiki).
>
> My initial attempt is here:
> https://people.freebsd.org/~pfg/ports/freecad.tgz
>
> Unfortunately it only reaches 71 % of the build and I would need the
> help of a CMake/linker expert to continue.
>
> The complete build log is here:
> https://people.freebsd.org/~pfg/ports/freecad-log.txt
>
> The relevant failure:
>
> ... [snip]
>
> Regards,
>
> Pedro.
> ___
> 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"

Looks like a missing declared dependency of libCoin.so from
graphics/Coin, which will likely/hopefully solve the problem --
graphics/Coin does include some pkgconfig magic.

Thanks,

Kyle Evans
___
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: Asterisk port

[Kyle Evans]

On Thu, Jun 23, 2016 at 3:34 PM, Paul Pathiakis
 wrote:
> Hi,
>
> The port for Asterisk software PBX is woefully out of date.  The current
> version is 2.x and the latest in ports/pkgs is 1.8. Version 1.8 is
> DEPRECATED.
>
> Thank you!
>
> Paul Pathiakis

In addition to Kurt's response, here's the previous response from
madpilot@ about versioning:
https://lists.freebsd.org/pipermail/freebsd-ports/2016-June/103439.html
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [CFT] net-im/ejabberd to 16.02

[Kyle Evans]

Hello!

The updated port includes a ZLIB flag that seems to be used for
inclusion/exclusion of the ezlib.* files, but ejabberd still attempts
to load ezlib.app and fails to do so with the default setup. Am I
missing something important here?

Thanks,

Kyle Evans

-- 
--Kyle Evans
___
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"