somebody typed the USES setting in /usr/ports/sysutils/screen?
up to date 10.3 up to date ports psg.com:/usr/ports/sysutils/screen# make config make: "/usr/ports/Mk/Uses/ncurses.mk" line 84: USES=ncurses only accept 'port' and 'base' as arguments, got ports ___ 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: Synth and circular dependencies
On 31 August 2017 at 17:59, Thomas Mueller wrote: > Now I've been busy, selecting port options to include in > /usr/local/etc/synth/LiveSystem-make.conf > > but when I run "synth status gnumeric", I get > > Configuration invalid: [D] Port options directory: /var/db/ports > > so without a directory like /var/db/ports showing options derived from the > ports dialog, synth seems not to work. The directory *must* be there, but it can be empty. > Is there any dialog-free way to use synth? Yup, I'm using it with the LiveSystem-make.conf. Cheers. -- Jonathan Chen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Synth and circular dependencies
Now I've been busy, selecting port options to include in /usr/local/etc/synth/LiveSystem-make.conf but when I run "synth status gnumeric", I get Configuration invalid: [D] Port options directory: /var/db/ports so without a directory like /var/db/ports showing options derived from the ports dialog, synth seems not to work. Is there any dialog-free way to use synth? Synth has been ported to pkgsrc where there is no dialog, so maybe there is a way? Or maybe synth does not run with pkgsrc? Synth seems to be falling into desuetude there. Tom ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FYI: qemu-ppc64-static and qemu-ppc-static "live-hang" when I attempt use with poudriere; qemu-arm-static and qemu-aarch64-static work
On 2017-Aug-30, at 4:32 PM, Don Lewis wrote:
> On 30 Aug, Mark Millard wrote:
>> On 2017-Aug-30, at 4:00 AM, Mark Linimon wrote:
>>
>>> On Wed, Aug 30, 2017 at 03:09:40AM -0700, Mark Millard wrote:
It appears that qemu-ppc64-static and qemu-ppc-static from
emulators/qemu-user-static are broken.
>>>
>>> Correct, and known for some time. (fwiw sparc64 hangs as well.)
>>
>> Looks like qemu-ppc64-static is stuck in a loop, calling
>> repeatedly:
>>
>> do_freebsd_syscall (cpu_env=0x860ea3ac0, num=58, arg1=14, arg2=35995509911,
>> arg3=1024, arg4=268435904, arg5=281494784, arg6=35985701568, arg7=515,
>> arg8=35985668288)
>>at
>> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/syscall.c:210
>> 210
>> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/syscall.c:
>> No such file or directory.
>>
>> Which is for:
>>
>> 58 AUE_READLINKSTD { ssize_t readlink(char *path, char *buf, \
>>size_t count); }
>>
>> As confirmed by (note the "callq 0x60207360 " ):
>>
>> (gdb)
>> lock_user_string (guest_addr=14) at
>> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/qemu.h:508
>> 508
>> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/qemu.h:
>> No such file or directory.
>>
>> (gdb) x/64i 0x60045d3e
>> => 0x60045d3e : callq 0x6004fd20
>>
>> 0x60045d43 : test %rax,%rax
>> 0x60045d46 : js 0x6004b99c
>>
>> 0x60045d4c : inc%rax
>> 0x60045d4f : mov$0x1,%edx
>> 0x60045d54 : mov%rbx,%rdi
>> 0x60045d57 : mov%rax,%rsi
>> 0x60045d5a : callq 0x6003c430
>>
>> 0x60045d5f : test %eax,%eax
>> 0x60045d61 : jne0x6004bce4
>>
>> 0x60045d67 : add0x26d91b2(%rip),%rbx
>># 0x6271ef20
>> 0x60045d6e : je 0x6004bce4
>>
>> 0x60045d74 : mov$0x3,%edx
>> 0x60045d79 : mov-0x2a8(%rbp),%r14
>> 0x60045d80 : mov%r14,%rdi
>> 0x60045d83 : mov%r12,%rsi
>> 0x60045d86 : callq 0x6003c430
>>
>> 0x60045d8b : test %eax,%eax
>> 0x60045d8d : jne0x6004bce4
>>
>> 0x60045d93 : add0x26d9186(%rip),%r14
>># 0x6271ef20
>> 0x60045d9a : mov-0x294(%rbp),%r10d
>> 0x60045da1 : mov$0xfff2,%r13
>> 0x60045da8 : je 0x6004bcf2
>>
>> 0x60045dae : mov$0x602b93da,%esi
>> 0x60045db3 : mov%rbx,%rdi
>> 0x60045db6 : callq 0x60230af0
>> 0x60045dbb : test %eax,%eax
>> 0x60045dbd : je 0x6004c566
>>
>> 0x60045dc3 : mov%rbx,%rdi
>> 0x60045dc6 : callq 0x60158660
>> 0x60045dcb : mov%rax,%rdi
>> 0x60045dce : mov%r14,%rsi
>> 0x60045dd1 : mov%r12,%rdx
>> 0x60045dd4 : callq 0x60207360
>>
>> But note that the "lock_user_string (guest_addr=14)" and
>> "do_freebsd_syscall (cpu_env=0x860ea3ac0, num=58, arg1=14,"
>> indicate that the "readlink(char *path," is using a really
>> small address for the path string.
>>
>>
>> I've not figured a way for poudriere bulk builds to leave
>> behind the source code automatically. So far I've not
>> looked at the qemu-bsd-user source code. I do build with
>> both debug and optimization turned on via bsd.port.mk
>> having:
>
> The -w option will create a tarball of the work directory if the
> package build fails. I also often use the testport -i option I want to
> poke around in the WRKDIR after a build.
I've been using -w right along. But I'd not used testport at all.
It looks to me like the syscall errno handling is messed
up. The details that I've observed follow. It follows
a simplified sequence of discovery as far a presentation
order goes.
The looping code is:
static inline void target_cpu_loop(CPUPPCState *env)
{
CPUState *cs = CPU(ppc_env_get_cpu(env));
target_siginfo_t info;
int trapnr;
target_ulong ret;
for(;;) {
cpu_exec_start(cs);
trapnr = cpu_exec(cs);
cpu_exec_end(cs);
process_queued_cpu_work(cs);
switch(trapnr) {
. . .
case POWERPC_EXCP_SYSCALL_USER:
/* system call in user-mode emulation */
/* WARNING:
* PPC ABI uses overflow flag in cr0 to signal an error
* in syscalls.
*/
env->crf[0] &= ~0x1;
ret = do_freebsd_syscall(env, env->gpr[0], env->gpr[3], env->gpr[4],
env->gpr[5], env->gpr[6], env->gpr[7],
env->gpr[8], env->gpr[9], env->gpr[10]);
if (ret == (target_ulong)(-TARGET_QEMU_ESIGRETURN)) {
/* Returning from a successful sigreturn syscall.
Avoid corrupting register state. */
break;
}
if (ret > (target_ulong)(-515))
Re: FYI: qemu-ppc64-static and qemu-ppc-static "live-hang" when I attempt use with poudriere; qemu-arm-static and qemu-aarch64-static work
On 30 Aug, Mark Millard wrote:
> On 2017-Aug-30, at 4:00 AM, Mark Linimon wrote:
>
>> On Wed, Aug 30, 2017 at 03:09:40AM -0700, Mark Millard wrote:
>>> It appears that qemu-ppc64-static and qemu-ppc-static from
>>> emulators/qemu-user-static are broken.
>>
>> Correct, and known for some time. (fwiw sparc64 hangs as well.)
>
> Looks like qemu-ppc64-static is stuck in a loop, calling
> repeatedly:
>
> do_freebsd_syscall (cpu_env=0x860ea3ac0, num=58, arg1=14, arg2=35995509911,
> arg3=1024, arg4=268435904, arg5=281494784, arg6=35985701568, arg7=515,
> arg8=35985668288)
> at
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/syscall.c:210
> 210
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/syscall.c:
> No such file or directory.
>
> Which is for:
>
> 58 AUE_READLINKSTD { ssize_t readlink(char *path, char *buf, \
> size_t count); }
>
> As confirmed by (note the "callq 0x60207360 " ):
>
> (gdb)
> lock_user_string (guest_addr=14) at
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/qemu.h:508
> 508
> /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/qemu.h:
> No such file or directory.
>
> (gdb) x/64i 0x60045d3e
> => 0x60045d3e : callq 0x6004fd20
>
>0x60045d43 : test %rax,%rax
>0x60045d46 : js 0x6004b99c
>
>0x60045d4c : inc%rax
>0x60045d4f : mov$0x1,%edx
>0x60045d54 : mov%rbx,%rdi
>0x60045d57 : mov%rax,%rsi
>0x60045d5a : callq 0x6003c430
>
>0x60045d5f : test %eax,%eax
>0x60045d61 : jne0x6004bce4
>
>0x60045d67 : add0x26d91b2(%rip),%rbx
># 0x6271ef20
>0x60045d6e : je 0x6004bce4
>
>0x60045d74 : mov$0x3,%edx
>0x60045d79 : mov-0x2a8(%rbp),%r14
>0x60045d80 : mov%r14,%rdi
>0x60045d83 : mov%r12,%rsi
>0x60045d86 : callq 0x6003c430
>
>0x60045d8b : test %eax,%eax
>0x60045d8d : jne0x6004bce4
>
>0x60045d93 : add0x26d9186(%rip),%r14
># 0x6271ef20
>0x60045d9a : mov-0x294(%rbp),%r10d
>0x60045da1 : mov$0xfff2,%r13
>0x60045da8 : je 0x6004bcf2
>
>0x60045dae : mov$0x602b93da,%esi
>0x60045db3 : mov%rbx,%rdi
>0x60045db6 : callq 0x60230af0
>0x60045dbb : test %eax,%eax
>0x60045dbd : je 0x6004c566
>
>0x60045dc3 : mov%rbx,%rdi
>0x60045dc6 : callq 0x60158660
>0x60045dcb : mov%rax,%rdi
>0x60045dce : mov%r14,%rsi
>0x60045dd1 : mov%r12,%rdx
>0x60045dd4 : callq 0x60207360
>
> But note that the "lock_user_string (guest_addr=14)" and
> "do_freebsd_syscall (cpu_env=0x860ea3ac0, num=58, arg1=14,"
> indicate that the "readlink(char *path," is using a really
> small address for the path string.
>
>
> I've not figured a way for poudriere bulk builds to leave
> behind the source code automatically. So far I've not
> looked at the qemu-bsd-user source code. I do build with
> both debug and optimization turned on via bsd.port.mk
> having:
The -w option will create a tarball of the work directory if the
package build fails. I also often use the testport -i option I want to
poke around in the WRKDIR after a build.
___
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: qemu-ppc64-static and qemu-ppc-static "live-hang" when I attempt use with poudriere; qemu-arm-static and qemu-aarch64-static work
On 2017-Aug-30, at 4:00 AM, Mark Linimon wrote:
> On Wed, Aug 30, 2017 at 03:09:40AM -0700, Mark Millard wrote:
>> It appears that qemu-ppc64-static and qemu-ppc-static from
>> emulators/qemu-user-static are broken.
>
> Correct, and known for some time. (fwiw sparc64 hangs as well.)
Looks like qemu-ppc64-static is stuck in a loop, calling
repeatedly:
do_freebsd_syscall (cpu_env=0x860ea3ac0, num=58, arg1=14, arg2=35995509911,
arg3=1024, arg4=268435904, arg5=281494784, arg6=35985701568, arg7=515,
arg8=35985668288)
at
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/syscall.c:210
210
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/syscall.c:
No such file or directory.
Which is for:
58 AUE_READLINKSTD { ssize_t readlink(char *path, char *buf, \
size_t count); }
As confirmed by (note the "callq 0x60207360 " ):
(gdb)
lock_user_string (guest_addr=14) at
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/qemu.h:508
508
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/qemu.h:
No such file or directory.
(gdb) x/64i 0x60045d3e
=> 0x60045d3e :callq 0x6004fd20
0x60045d43 :test %rax,%rax
0x60045d46 :js 0x6004b99c
0x60045d4c :inc%rax
0x60045d4f :mov$0x1,%edx
0x60045d54 :mov%rbx,%rdi
0x60045d57 :mov%rax,%rsi
0x60045d5a :callq 0x6003c430
0x60045d5f :test %eax,%eax
0x60045d61 :jne0x6004bce4
0x60045d67 :add0x26d91b2(%rip),%rbx
# 0x6271ef20
0x60045d6e :je 0x6004bce4
0x60045d74 :mov$0x3,%edx
0x60045d79 :mov-0x2a8(%rbp),%r14
0x60045d80 :mov%r14,%rdi
0x60045d83 :mov%r12,%rsi
0x60045d86 :callq 0x6003c430
0x60045d8b :test %eax,%eax
0x60045d8d :jne0x6004bce4
0x60045d93 :add0x26d9186(%rip),%r14
# 0x6271ef20
0x60045d9a :mov-0x294(%rbp),%r10d
0x60045da1 :mov$0xfff2,%r13
0x60045da8 :je 0x6004bcf2
0x60045dae :mov$0x602b93da,%esi
0x60045db3 :mov%rbx,%rdi
0x60045db6 :callq 0x60230af0
0x60045dbb :test %eax,%eax
0x60045dbd :je 0x6004c566
0x60045dc3 :mov%rbx,%rdi
0x60045dc6 :callq 0x60158660
0x60045dcb :mov%rax,%rdi
0x60045dce :mov%r14,%rsi
0x60045dd1 :mov%r12,%rdx
0x60045dd4 :callq 0x60207360
But note that the "lock_user_string (guest_addr=14)" and
"do_freebsd_syscall (cpu_env=0x860ea3ac0, num=58, arg1=14,"
indicate that the "readlink(char *path," is using a really
small address for the path string.
I've not figured a way for poudriere bulk builds to leave
behind the source code automatically. So far I've not
looked at the qemu-bsd-user source code. I do build with
both debug and optimization turned on via bsd.port.mk
having:
STRIP_CMD= ${TRUE}
.endif
DEBUG_FLAGS?= -g
+.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG)
+CFLAGS:= ${CFLAGS} ${DEBUG_FLAGS}
+.else
CFLAGS:= ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS}
+.endif
.if defined(INSTALL_TARGET)
INSTALL_TARGET:= ${INSTALL_TARGET:S/^install-strip$/install/g}
.endif
mixed with make.conf indicating to use the
new alternative:
WANT_QT_VERBOSE_CONFIGURE=1
#
DEFAULT_VERSIONS+=perl5=5.24 gcc=7
#
# From a local /usr/ports/Mk/bsd.port.mk extension:
ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=
#
.if ${.CURDIR:M*/devel/llvm*}
#WITH_DEBUG=
.elif ${.CURDIR:M*/www/webkit-qt5*}
#WITH_DEBUG=
.else
WITH_DEBUG=
.endif
MALLOC_PRODUCTION=
I got as much information as I report
above via use of:
/usr/local/bin/gdb /usr/local/bin/qemu-user-static
and then:
run /usr/obj/DESTDIRs/clang-powerpc64-installworld-dist-from-src/rescue/id
and then interrupting it and exploring.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: pkg issue after FreeBSD 11 upgrade
Thank you for your support Baptiste, I really appreciate that. As same as HANDLE_RC_SCRIPTS option the new one should be handled carefully. Please keep us posted when it's ready. On Wednesday, August 30, 2017, Baptiste Daroussin wrote: > On Wed, Aug 30, 2017 at 10:07:51AM -0300, Cassiano Peixoto wrote: > > Ok I know about HANDLE_RC_SCRIPTS, it's a good approach. But how to deal > > with when I need to restart a service without upgrading? Reaper > > functionnality is a trouble for many administrators who made meta ports > to > > manage their servers. I really think it could be a option to be > > enabled/disabled. Can you see this possibility? > > > > Yes I could add an option to disable the reaper functionnality (and will > probably to unblock such use case as soon as I have time to do it.) > > However I still think this is not the right idea :) and a better one could > be > found > > Bapt > ___ 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 issue after FreeBSD 11 upgrade
On Wed, Aug 30, 2017 at 10:07:51AM -0300, Cassiano Peixoto wrote: > Ok I know about HANDLE_RC_SCRIPTS, it's a good approach. But how to deal > with when I need to restart a service without upgrading? Reaper > functionnality is a trouble for many administrators who made meta ports to > manage their servers. I really think it could be a option to be > enabled/disabled. Can you see this possibility? > Yes I could add an option to disable the reaper functionnality (and will probably to unblock such use case as soon as I have time to do it.) However I still think this is not the right idea :) and a better one could be found Bapt signature.asc Description: PGP signature
Re: pkg issue after FreeBSD 11 upgrade
Cassiano Peixoto wrote: Ok I know about HANDLE_RC_SCRIPTS, it's a good approach. But how to deal with when I need to restart a service without upgrading? Reaper functionnality is a trouble for many administrators who made meta ports to manage their servers. I really think it could be a option to be enabled/disabled. Can you see this possibility? Thanks. On Wed, Aug 30, 2017 at 9:59 AM, Baptiste Daroussin wrote: On Wed, Aug 30, 2017 at 09:55:22AM -0300, Cassiano Peixoto wrote: Hi Baptiste, Why it used to work on FreeBSD 10? It stopped worked on FreeBSD 11 only. It only worked on FreeBSD 10 prior to 10.2, the reaper functionnality in freebsd kernel appeared in 10.2 Cron is just an example, I manage more than 50 FreeBSD servers, and I've been using ports for years to update some configs and restart the service on all of them. Many times I need to change nginx config, ldap, etc. I just need to restart the service. HANDLE_RC_SCRIPTS=true in your pkg.conf and pkg will automatically restart anything rc script provide once the package containing it is upgrading. This is off by default because in many cases it is dangerous (database upgrades, dovecot like things upgrade etc). But if you know what you are doing it does the job. Best regards, Bapt Hey, I think you also want process supervision given your other comments. You can do this easily using daemon -P to run your scripts (but you'd need to rewrite the rc script...) Or use runit or similar? You could implement "runlevels" with that if that's REALLY what you want :) Cheers, Chris -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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 issue after FreeBSD 11 upgrade
Hi Baptiste, > On 30. Aug 2017, at 3:05 PM, Baptiste Daroussin wrote: > >> No. At OPNsense we use a patch to revert the behaviour. >> >> https://github.com/opnsense/ports/blob/master/ports-mgmt/pkg/files/patch-libpkg_scripts.c > > Why and what is your use case, there is a reason why this code has been added, > and I would like to hear more about use cases so we can try to address them. There's to things in this patch. (1) The hard fail for scripts leaves a GUI-driven environment without its package, so post-install fails become fatal and appliances are completely stranded, possibly left without means of recovery. This is where FreeBSD base and the "appliance" GUI packages are completely separated. This is somewhat mitigated by marking said GUI package vital, but vital won't help if the package was deinstalled during an upgrade and then the upgrade script itself fails. Every now and then, I see "user disappeared" during package installs on stock FreeBSD systems so the install fails. I am guessing that's the same issue. (2) The reaper kills a package-based watchdog / backend service. Maybe HANDLE_RC_SCRIPTS can cope with this, but it would be beneficial to be able to enable this per package / rc service / metadata as generally the reaper is a fine and sane addition. Cheers, Franco ___ 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 issue after FreeBSD 11 upgrade
Hi Franco, Thank you. You know what I'm suffering. As I said in my last email I think it would be an option to enable/disable. I just upgraded my customers servers to FreeBSD 11 and I just realized it. I think when more admins who maintain this kind of port (needing to restart services), as soon as they migrate they will face the same problem. On Wed, Aug 30, 2017 at 10:01 AM, Franco Fichtner wrote: > Hi Cassiano, > > > On 30. Aug 2017, at 2:55 PM, Cassiano Peixoto > wrote: > > > > Why it used to work on FreeBSD 10? It stopped worked on FreeBSD 11 only. > > It was a later 10.x change as far as I know. > > > Is there some flag to disable it? Or some hack that I could do? > > No. At OPNsense we use a patch to revert the behaviour. > > https://github.com/opnsense/ports/blob/master/ports-mgmt/ > pkg/files/patch-libpkg_scripts.c > > > Cheers, > Franco ___ 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 issue after FreeBSD 11 upgrade
Ok I know about HANDLE_RC_SCRIPTS, it's a good approach. But how to deal with when I need to restart a service without upgrading? Reaper functionnality is a trouble for many administrators who made meta ports to manage their servers. I really think it could be a option to be enabled/disabled. Can you see this possibility? Thanks. On Wed, Aug 30, 2017 at 9:59 AM, Baptiste Daroussin wrote: > On Wed, Aug 30, 2017 at 09:55:22AM -0300, Cassiano Peixoto wrote: > > Hi Baptiste, > > > > Why it used to work on FreeBSD 10? It stopped worked on FreeBSD 11 only. > > It only worked on FreeBSD 10 prior to 10.2, the reaper functionnality in > freebsd > kernel appeared in 10.2 > > > > Cron is just an example, I manage more than 50 FreeBSD servers, and I've > > been using ports for years to update some configs and restart the service > > on all of them. Many times I need to change nginx config, ldap, etc. I > just > > need to restart the service. > > HANDLE_RC_SCRIPTS=true in your pkg.conf and pkg will automatically restart > anything rc script provide once the package containing it is upgrading. > > This is off by default because in many cases it is dangerous (database > upgrades, > dovecot like things upgrade etc). But if you know what you are doing it > does the > job. > > Best regards, > Bapt > ___ 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 issue after FreeBSD 11 upgrade
On Wed, Aug 30, 2017 at 03:01:30PM +0200, Franco Fichtner wrote: > Hi Cassiano, > > > On 30. Aug 2017, at 2:55 PM, Cassiano Peixoto > > wrote: > > > > Why it used to work on FreeBSD 10? It stopped worked on FreeBSD 11 only. > > It was a later 10.x change as far as I know. > > > Is there some flag to disable it? Or some hack that I could do? > > No. At OPNsense we use a patch to revert the behaviour. > > https://github.com/opnsense/ports/blob/master/ports-mgmt/pkg/files/patch-libpkg_scripts.c Why and what is your use case, there is a reason why this code has been added, and I would like to hear more about use cases so we can try to address them. Best regards, Bapt signature.asc Description: PGP signature
Re: pkg issue after FreeBSD 11 upgrade
Hi Cassiano, > On 30. Aug 2017, at 2:55 PM, Cassiano Peixoto > wrote: > > Why it used to work on FreeBSD 10? It stopped worked on FreeBSD 11 only. It was a later 10.x change as far as I know. > Is there some flag to disable it? Or some hack that I could do? No. At OPNsense we use a patch to revert the behaviour. https://github.com/opnsense/ports/blob/master/ports-mgmt/pkg/files/patch-libpkg_scripts.c Cheers, Franco ___ 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 issue after FreeBSD 11 upgrade
On Wed, Aug 30, 2017 at 09:55:22AM -0300, Cassiano Peixoto wrote: > Hi Baptiste, > > Why it used to work on FreeBSD 10? It stopped worked on FreeBSD 11 only. It only worked on FreeBSD 10 prior to 10.2, the reaper functionnality in freebsd kernel appeared in 10.2 > > Cron is just an example, I manage more than 50 FreeBSD servers, and I've > been using ports for years to update some configs and restart the service > on all of them. Many times I need to change nginx config, ldap, etc. I just > need to restart the service. HANDLE_RC_SCRIPTS=true in your pkg.conf and pkg will automatically restart anything rc script provide once the package containing it is upgrading. This is off by default because in many cases it is dangerous (database upgrades, dovecot like things upgrade etc). But if you know what you are doing it does the job. Best regards, Bapt signature.asc Description: PGP signature
Re: pkg issue after FreeBSD 11 upgrade
Hi Baptiste, Why it used to work on FreeBSD 10? It stopped worked on FreeBSD 11 only. Cron is just an example, I manage more than 50 FreeBSD servers, and I've been using ports for years to update some configs and restart the service on all of them. Many times I need to change nginx config, ldap, etc. I just need to restart the service. Is there some flag to disable it? Or some hack that I could do? Thanks. On Wed, Aug 30, 2017 at 9:48 AM, Baptiste Daroussin wrote: > On Wed, Aug 30, 2017 at 09:00:55AM -0300, Cassiano Peixoto wrote: > > Hi Matthew, > > > > Sorry back to this subject. But I really need to restart services with a > > port. I'm quite sure there is a bug with pkg and FreeBSD 11. > > > > I made a simple port to restart cron service: > > It is not a bug, it is by design, pkg becomes the reaper of the scripts it > runs > and kills everything once the script is executed. > > btw if you install crontab in cron.d you do not need to restart the > service, > cron will figure out itself and reload what it needed. > > Bapt > ___ 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 issue after FreeBSD 11 upgrade
On Wed, Aug 30, 2017 at 09:00:55AM -0300, Cassiano Peixoto wrote: > Hi Matthew, > > Sorry back to this subject. But I really need to restart services with a > port. I'm quite sure there is a bug with pkg and FreeBSD 11. > > I made a simple port to restart cron service: It is not a bug, it is by design, pkg becomes the reaper of the scripts it runs and kills everything once the script is executed. btw if you install crontab in cron.d you do not need to restart the service, cron will figure out itself and reload what it needed. Bapt signature.asc Description: PGP signature
Re: pkg issue after FreeBSD 11 upgrade
Try tracing the install with truss or ktrace.
I suspect you'll find there is an issue where a pipe being closed;
stdin, stdout or stderr, which results in the daemon that was started
being stopped again, or something similar.
On 30/08/2017 13:00, Cassiano Peixoto wrote:
Hi Matthew,
Sorry back to this subject. But I really need to restart services with a
port. I'm quite sure there is a bug with pkg and FreeBSD 11.
I made a simple port to restart cron service:
# $FreeBSD$
PORTNAME= ze
PORTVERSION=1.0
CATEGORIES= custom
MASTER_SITES= #
DISTFILES= #
EXTRACT_ONLY= # NONE
MAINTAINER= peixotocassi...@gmail.com
COMMENT=ze port
#NO_MTREE= yes
SUB_FILES= pkg-install
NO_BUILD= yes
NO_WRKSUBDIR= yes
do-install:
mkdir -p ${STAGEDIR}${DATADIR}
@${CP} -r ${FILESDIR}/versions ${STAGEDIR}${DATADIR}/
post-install:
${SH} ${PKGINSTALL} ${PKGNAME} POST-INSTALL
.include
Here is my pkg-install to restart cron service:
#!/bin/sh
if [ $2 = "POST-INSTALL" ]; then
service cron restart
fi
Here is the output when I install the port:
root@kkk:~ # service cron start
cron already running? (pid=2287).
root@kkk:~ # pkg install ze
Updating Custom repository catalogue...
Fetching meta.txz: 100%560 B 0.6kB/s00:01
Fetching packagesite.txz: 100% 122 KiB 62.6kB/s00:02
Processing entries: 100%
Custom repository update completed. 427 packages processed.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
ze: 1.0
Number of packages to be installed: 1
672 B to be downloaded.
[1/1] Fetching ze-1.0.txz: 100%672 B 0.7kB/s00:01
Checking integrity... done (0 conflicting)
[1/1] Installing ze-1.0...
+ set -- ze-1.0 PRE-INSTALL
+ [ PRE-INSTALL '=' POST-INSTALL ]
Extracting ze-1.0: 100%
+ set -- ze-1.0 POST-INSTALL
+ [ POST-INSTALL '=' POST-INSTALL ]
+ service cron restart
Stopping cron.
Waiting for PIDS: 2287.
Starting cron.
root@kkk:~ # ps ax | grep cron
2320 1 S+ 0:00.00 grep cron
As you can see the cron has stopped but hasn't started.
But If I install the same port with traditional ports approach it works,
see:
root@kkk: /usr/ports/custom/ze/# ps ax | grep cron
1280 - Is 0:00.97 /usr/sbin/cron -s
root@kkk: /usr/ports/custom/ze# make install
===> ze-1.1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by ze-1.1 for building
===> Extracting for ze-1.1
===> Patching for ze-1.1
===> Configuring for ze-1.1
===> Staging for ze-1.1
===> Generating temporary packing list
mkdir -p /usr/ports/custom/ze/work/stage/usr/local/share/ze
/bin/sh /usr/ports/custom/ze/work/pkg-install ze-1.1 POST-INSTALL
> Compressing man pages (compress-man)
===> Installing for ze-1.1
===> Checking if ze already installed
Stopping cron.
Waiting for PIDS: 1280.
Starting cron.
===> Registering installation for ze-1.1
Installing ze-1.1...
root@kkk: /usr/ports/custom/ze# ps ax | grep cron
37527 - Ss 0:00.00 /usr/sbin/cron -s
Thanks for your help.
On Fri, Aug 11, 2017 at 1:45 PM, Cassiano Peixoto
wrote:
Hi Matthew,
Thanks for your answer. Slapd is just an example, it happens with any
application like apache, mysql, dovecot and others.
I can see the process is running and up, and it dies after pkg process has
finished. Looks like pkg is killing any application related to its thread.
I know it's not the best approach, but used to work on FreeBSD 10.
Anyway, I'll change my script to restart services out of pkg process.
Thanks.
On Fri, Aug 11, 2017 at 5:09 AM, Matthew Seaman
wrote:
On 10/08/2017 22:05, Cassiano Peixoto wrote:
I ran into an issue after FreeBSD 11 upgrade. I have some meta ports
that
starts services like slapd.
Its has been working fine on 10-STABLE. But after FreeBSD
11-STABLE r321625M upgrade it stopped working.
Here is a simple example of my pkg-install.in script:
#!/bin/sh
/usr/local/etc/rc.d/slapd stop
/usr/local/etc/rc.d/slapd start
I can see its executing while upgrading a package:
Stopping slapd.
Waiting for PIDS: 13875.
Starting slapd.
But looking if the process is running, it's not:
# ps ax | grep slapd
14164 0 S+ 0:00.00 grep slapd
Then I manually run the rc.d script and the service starts:
# /usr/local/etc/rc.d/slapd restart
slapd not running? (check /var/run/openldap/slapd.pid).
Starting slapd.
So my question is: something has changed on FreeBSD 11 not allowing this
kind of execution?
BTW, I'm using pkg 1.10.1 and my ports collection is as same as I was
using
on FreeBSD 10.
Restarting daemons after upgrading is something the project has been
quite resistant to implementing. Mostly because as soon as you start
looking into it in any depth the true complexity of doing that sort of
thing reliably for any conceivable system becomes apparent and you end
up muttering darkly about systemd and losing the will to live.
However, yes, restarting
Re: pkg issue after FreeBSD 11 upgrade
Hi Matthew,
Sorry back to this subject. But I really need to restart services with a
port. I'm quite sure there is a bug with pkg and FreeBSD 11.
I made a simple port to restart cron service:
# $FreeBSD$
PORTNAME= ze
PORTVERSION=1.0
CATEGORIES= custom
MASTER_SITES= #
DISTFILES= #
EXTRACT_ONLY= # NONE
MAINTAINER= peixotocassi...@gmail.com
COMMENT=ze port
#NO_MTREE= yes
SUB_FILES= pkg-install
NO_BUILD= yes
NO_WRKSUBDIR= yes
do-install:
mkdir -p ${STAGEDIR}${DATADIR}
@${CP} -r ${FILESDIR}/versions ${STAGEDIR}${DATADIR}/
post-install:
${SH} ${PKGINSTALL} ${PKGNAME} POST-INSTALL
.include
Here is my pkg-install to restart cron service:
#!/bin/sh
if [ $2 = "POST-INSTALL" ]; then
service cron restart
fi
Here is the output when I install the port:
root@kkk:~ # service cron start
cron already running? (pid=2287).
root@kkk:~ # pkg install ze
Updating Custom repository catalogue...
Fetching meta.txz: 100%560 B 0.6kB/s00:01
Fetching packagesite.txz: 100% 122 KiB 62.6kB/s00:02
Processing entries: 100%
Custom repository update completed. 427 packages processed.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
ze: 1.0
Number of packages to be installed: 1
672 B to be downloaded.
[1/1] Fetching ze-1.0.txz: 100%672 B 0.7kB/s00:01
Checking integrity... done (0 conflicting)
[1/1] Installing ze-1.0...
+ set -- ze-1.0 PRE-INSTALL
+ [ PRE-INSTALL '=' POST-INSTALL ]
Extracting ze-1.0: 100%
+ set -- ze-1.0 POST-INSTALL
+ [ POST-INSTALL '=' POST-INSTALL ]
+ service cron restart
Stopping cron.
Waiting for PIDS: 2287.
Starting cron.
root@kkk:~ # ps ax | grep cron
2320 1 S+ 0:00.00 grep cron
As you can see the cron has stopped but hasn't started.
But If I install the same port with traditional ports approach it works,
see:
root@kkk: /usr/ports/custom/ze/# ps ax | grep cron
1280 - Is 0:00.97 /usr/sbin/cron -s
root@kkk: /usr/ports/custom/ze# make install
===> ze-1.1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by ze-1.1 for building
===> Extracting for ze-1.1
===> Patching for ze-1.1
===> Configuring for ze-1.1
===> Staging for ze-1.1
===> Generating temporary packing list
mkdir -p /usr/ports/custom/ze/work/stage/usr/local/share/ze
/bin/sh /usr/ports/custom/ze/work/pkg-install ze-1.1 POST-INSTALL
> Compressing man pages (compress-man)
===> Installing for ze-1.1
===> Checking if ze already installed
Stopping cron.
Waiting for PIDS: 1280.
Starting cron.
===> Registering installation for ze-1.1
Installing ze-1.1...
root@kkk: /usr/ports/custom/ze# ps ax | grep cron
37527 - Ss 0:00.00 /usr/sbin/cron -s
Thanks for your help.
On Fri, Aug 11, 2017 at 1:45 PM, Cassiano Peixoto wrote:
> Hi Matthew,
>
> Thanks for your answer. Slapd is just an example, it happens with any
> application like apache, mysql, dovecot and others.
>
> I can see the process is running and up, and it dies after pkg process has
> finished. Looks like pkg is killing any application related to its thread.
>
> I know it's not the best approach, but used to work on FreeBSD 10.
>
> Anyway, I'll change my script to restart services out of pkg process.
>
> Thanks.
>
> On Fri, Aug 11, 2017 at 5:09 AM, Matthew Seaman
> wrote:
>
>> On 10/08/2017 22:05, Cassiano Peixoto wrote:
>> > I ran into an issue after FreeBSD 11 upgrade. I have some meta ports
>> that
>> > starts services like slapd.
>> >
>> > Its has been working fine on 10-STABLE. But after FreeBSD
>> > 11-STABLE r321625M upgrade it stopped working.
>> >
>> > Here is a simple example of my pkg-install.in script:
>> >
>> > #!/bin/sh
>> > /usr/local/etc/rc.d/slapd stop
>> > /usr/local/etc/rc.d/slapd start
>> >
>> > I can see its executing while upgrading a package:
>> >
>> > Stopping slapd.
>> > Waiting for PIDS: 13875.
>> > Starting slapd.
>> >
>> > But looking if the process is running, it's not:
>> >
>> > # ps ax | grep slapd
>> > 14164 0 S+ 0:00.00 grep slapd
>> >
>> > Then I manually run the rc.d script and the service starts:
>> >
>> > # /usr/local/etc/rc.d/slapd restart
>> > slapd not running? (check /var/run/openldap/slapd.pid).
>> > Starting slapd.
>> >
>> > So my question is: something has changed on FreeBSD 11 not allowing this
>> > kind of execution?
>> >
>> > BTW, I'm using pkg 1.10.1 and my ports collection is as same as I was
>> using
>> > on FreeBSD 10.
>>
>> Restarting daemons after upgrading is something the project has been
>> quite resistant to implementing. Mostly because as soon as you start
>> looking into it in any depth the true complexity of doing that sort of
>> thing reliably for any conceivable system becomes apparent and you end
>> up muttering darkly about systemd and losing the will to live.
>>
>> However, yes, restarting slapd -- it's clear that your script does get
>> called, but slapd fai
Re: FYI: qemu-ppc64-static and qemu-ppc-static "live-hang" when I attempt use with poudriere; qemu-arm-static and qemu-aarch64-static work
On Wed, Aug 30, 2017 at 03:09:40AM -0700, Mark Millard wrote: > It appears that qemu-ppc64-static and qemu-ppc-static from > emulators/qemu-user-static are broken. Correct, and known for some time. (fwiw sparc64 hangs as well.) mcl ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: PR looking for committer
El 29 ago. 2017 21:36, "Kurt Jaeger" escribió: Hi! > Can a committer have a look at this? > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221835 It hit the tree, thanks! Thank you. Could you (or any other committer) also have a look at the PR blocked by this one? -- p...@opsec.eu+49 171 3101372 3 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FYI: qemu-ppc64-static and qemu-ppc-static "live-hang" when I attempt use with poudriere; qemu-arm-static and qemu-aarch64-static work
qemu-ppc64-static and qemu-ppc-static "live-hang" when I attempt use them with poudriere, hanging at the command (showing an example process id): /usr/local/bin/qemu-ppc-static /bin/ps -ww -p 47841 -o jid= which eats CPU time and grows memory SIZE over time. Examples from after waiting a while in each case: PID USERNAMETHR PRI NICE SIZERES SWAP STATE C TIME CPU COMMAND 48319 root 2 1030 8413M 234M 0K CPU11 11 2:50 101.97% /usr/local/bin/qemu-ppc64-static /bin/ps -ww -p 48318 -o jid PID USERNAMETHR PRI NICE SIZERES SWAP STATE C TIME CPU COMMAND 47842 root 2 1030 16597M 455M 0K CPU11 5:25 96.38% /usr/local/bin/qemu-ppc-static /bin/ps -ww -p 47841 -o jid= By contrast I've no such problem with qemu-arm-static or qemu-aarch64-static : these were able to build lang/gcc7 (full bootstrap) in between 4 and 5 hours hours each, the prerequisites also being built in the process. # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 448068 Last Changed Rev: 448068 My attempts to manually use qemu-ppc64-static and qemu-ppc-static (with -L supplied) also get such results. The same for qemu-ppc*-static running a statically linked rescue program (so no -L needed). It appears that qemu-ppc64-static and qemu-ppc-static from emulators/qemu-user-static are broken. === Mark Millard markmi at dsl-only.net ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeBSD ports you maintain which are out of date
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/po...@freebsd.org.html Port| Current version | New version +-+ emulators/mame | 0.166 | mame0189 +-+ emulators/mess | 0.166 | mame0189 +-+ 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. ___ 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"
