Re: poudriere segmentation fault on 13-CURRENT

[Grzegorz Junka]

On 20/05/2020 19:33, Yuri Pankov wrote:

Grzegorz Junka wrote:

When configuring ports with this option:

poudriere options -j 13 -p gui -z v8 lang/v8

for every port the configuration ends with "Segmentation fault". For 
example, with that command the first port that shows up is 
"python27-2.7.18". After the ncurses dialog is shown I click OK which 
supposed to save the option. But instead, I see "Segmentation fault" 
and nothing is written to 
/usr/local/etc/poudriere.d/13-gui-v8-options/lang_python27/


This only happens when I use kernel 13-CURRENT and "Segmentation 
fault" would happen regardless if used -j 13 or -j 12 or -j 12.1 
(STABLE and 12.1 jails respectively). Otherwise compiling with 
poudriere on kernel 13 works fine, it's just the options that don't 
work.


I have to boot kernel 12, configure options, then boot kernel 13 to 
compile.


What might be the issue?


Which program is misbehaving, is it dialog4ports? Do you have the core 
and can provide the backtrace?


That's what I would like to find out. No core is dumped in the local 
folder. Not sure where it would be dumped instead? If at all?


The segmentation fault happens after the options have been selected. I 
think it's at the moment when they should have been written to disk.


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"

poudriere segmentation fault on 13-CURRENT

[Grzegorz Junka]

When configuring ports with this option:

poudriere options -j 13 -p gui -z v8 lang/v8

for every port the configuration ends with "Segmentation fault". For 
example, with that command the first port that shows up is 
"python27-2.7.18". After the ncurses dialog is shown I click OK which 
supposed to save the option. But instead, I see "Segmentation fault" and 
nothing is written to 
/usr/local/etc/poudriere.d/13-gui-v8-options/lang_python27/


This only happens when I use kernel 13-CURRENT and "Segmentation fault" 
would happen regardless if used -j 13 or -j 12 or -j 12.1 (STABLE and 
12.1 jails respectively). Otherwise compiling with poudriere on kernel 
13 works fine, it's just the options that don't work.


I have to boot kernel 12, configure options, then boot kernel 13 to compile.

What might be the issue?

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"

xwayland-devel checksum error

[Grzegorz Junka]

Why am I getting this:

===> Fetching all distfiles required by xwayland-devel-1.20.0.641_1 for 
building
=> SHA256 Checksum OK for 
xorg-xserver-785e59060c00129e47da6c0877604a56d7e0e32f_GL0.tar.gz.

=> SHA256 Checksum mismatch for 71749de24509.patch.
=> SHA256 Checksum mismatch for 1e897704c822.patch.
=> SHA256 Checksum mismatch for 83cda3ce3195.patch.
===>  Giving up on fetching files:  71749de24509.patch 
1e897704c822.patch  83cda3ce3195.patch
Make sure the Makefile and distinfo file 
(/usr/ports/x11-servers/xwayland-devel/distinfo)

are up to date.  If you are absolutely sure you want to override this
check, type "make NO_CHECKSUM=yes [other args]".
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/x11-servers/xwayland-devel
*** Error code 1

Stop.
make: stopped in /usr/ports/x11-servers/xwayland-devel
=>> Cleaning up wrkdir
===>  Cleaning for xwayland-devel-1.20.0.641_1
build of x11-servers/xwayland-devel | xwayland-devel-1.20.0.641_1 ended 
at Wed May  6 02:57:16 UTC 2020

build time: 00:00:27
!!! build failure encountered !!!

___
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: amdgpu panics

[Grzegorz Junka]

Tried just now with 12-STABLE installed using FreeBSD-base and all kmod 
packages recompiled in a jail that was created from the same obj/usr as 
the 12-STABLE base packages. In other words:


The build host is running 12.1-RELEASE-p3. On it I fetched 12-STABLE and 
compiled world and kernel. Then packaged both into FreeBSD-base packages 
to install on the destination desktop. Then I created a new poudriere 
jail using the same 12-STABLE usr/obj. Then I used that jail to build 
drm-kmod, drm-fbsd12.0-kmod and gpu-firmware-kmod. Then I reinstalled 
the base (world/kernel) on the destination desktop using FreeBSD-base 
packages and reinstalled on it the three kmod packages recompiled with 
poudriere.


The result is (almost) exactly the same as with 12.1-RELEASE-p3. The 
screen goes blank and to sleep after a few seconds. The ssh session 
survived:


root@venus:~ # kldstat
Id Refs Address    Size Name
 1  142 0x8020  226f3f0 kernel
 2    1 0x8247   3adf68 zfs.ko
 3    2 0x8281e000 a430 opensolaris.ko
 4    1 0x82e11000 4950 linprocfs.ko
 5    3 0x82e16000 3148 linux_common.ko
 6    1 0x82e1a000 8838 tmpfs.ko
 7    1 0x82e23000    16b50 if_iwm.ko
 8    1 0x82e3a000    fb11f iwm3168fw.ko
 9    1 0x82f36000 2658 intpm.ko
10    1 0x82f39000  b60 smbus.ko
11    1 0x82f3a000 1880 uhid.ko
12    1 0x82f3c000 2968 ums.ko
13    1 0x82f3f000 1a40 wmt.ko
14    1 0x82f41000 cbd0 snd_uaudio.ko
15    1 0x82f4e000 4240 ng_ubt.ko
16    6 0x82f53000 9be0 netgraph.ko
17    2 0x82f5d000 91e8 ng_hci.ko
18    3 0x82f67000  9b0 ng_bluetooth.ko
19    1 0x82f68000 cb40 ng_l2cap.ko
20    1 0x82f75000    1b420 ng_btsocket.ko
21    1 0x82f91000 2180 ng_socket.ko
22    1 0x82f94000    3d450 linux.ko
23    1 0x82fd2000    35260 linux64.ko
24    1 0x83008000 1a88 fdescfs.ko
25    3 0x8300a000    764b0 drm.ko
26    5 0x83081000    11170 linuxkpi.ko
27    4 0x83093000    13f30 linuxkpi_gplv2.ko
28    2 0x830a7000  6d0 debugfs.ko
30    1 0x832f8000 ef41 ttm.ko
31    1 0x83307000  2c1 amdgpu_vega10_gpu_info_bin.ko
32    1 0x83308000    27d07 amdgpu_vega10_sos_bin.ko
33    1 0x8333    1e377 amdgpu_vega10_asd_bin.ko
34    1 0x8334f000    4047f amdgpu_vega10_acg_smc_bin.ko
35    1 0x8339 55f7 amdgpu_vega10_pfp_bin.ko
36    1 0x83396000 45f5 amdgpu_vega10_me_bin.ko
37    1 0x8339b000 25f5 amdgpu_vega10_ce_bin.ko
38    1 0x8339e000 4477 amdgpu_vega10_rlc_bin.ko
39    1 0x833a3000    41887 amdgpu_vega10_mec_bin.ko
40    1 0x833e5000    41889 amdgpu_vega10_mec2_bin.ko
41    1 0x83427000 4579 amdgpu_vega10_sdma_bin.ko
42    1 0x8342c000 457b amdgpu_vega10_sdma1_bin.ko
43    1 0x83431000    5c337 amdgpu_vega10_uvd_bin.ko
44    1 0x8348e000    2a797 amdgpu_vega10_vce_bin.ko

root@venus:~ # dmesg
---<>---
Copyright (c) 1992-2020 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.1-STABLE r359722 GENERIC amd64
FreeBSD clang version 9.0.1 (g...@github.com:llvm/llvm-project.git 
c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1)

VT(efifb): resolution 1024x768
CPU: AMD Ryzen 7 2700X Eight-Core Processor  (3700.37-MHz 
K8-class CPU)

  Origin="AuthenticAMD"  Id=0x800f82  Family=0x17  Model=0x8 Stepping=2
Features=0x178bfbff
Features2=0x7ed8320b
  AMD Features=0x2e500800
  AMD 
Features2=0x35c233ff
  Structured Extended 
Features=0x209c01a9

  XSAVE Features=0xf
  AMD Extended Feature Extensions ID EBX=0x1007
  SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
  TSC: P-state invariant, performance statistics
real memory  = 68719476736 (65536 MB)
avail memory = 66808102912 (63713 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs
FreeBSD/SMP: 1 package(s) x 2 cache groups x 4 core(s) x 2 hardware threads
random: unblocking device.
Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid 
Length but zero Address: 0x/0x1 (20191213/tbfadt-796)

ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 24-55 on motherboard
Launching APs: 12 13 9 15 8 11 1 10 14 7 6 3 4 5 2
Timecounter "TSC-low" frequency 1850186165 Hz quality 1000
random: entropy device external interface
kbd1 at kbdmux0
000.23 [4336] netmap_init   netmap: loaded module
[ath_hal] loaded

(...)

[drm] amdgpu kernel modesetting enabled.
drmn0:  on vgapci0
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child 

Re: amdgpu panics

[Grzegorz Junka]

On 06/04/2020 22:08, Tatsuki Makino wrote:

Sorry, I derail from this topic.

I have cloned the host to poudriere with the following command.

poudriere jail -c -j src -m 'src=/usr/src' -v `make -C /usr/src/release/
-V VERSION VERSION=\$\{REVISION:Q\}-\$\{BRANCH:Q\}`

Since the name of this jail is src, create src.conf as follows.

ln -s /etc/src.conf /usr/local/etc/poudriere.d/src-src.conf

Probably, this reproduces the same environment as the host... maybe :)



Just trying this now. Poudriere's help says that -v only makes sense for 
method ftp and svn. For other methods, especially for src that you are 
using, the value is only for display.


Also, I don't think specifying src.conf for jail created with method src 
makes sense? It assumes that the world and kernel is already build. I 
would expect this to only take any effect when creating with -b or with 
method svn?


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: amdgpu panics

[Grzegorz Junka]

On 07/04/2020 11:18, Hans Petter Selasky wrote:

On 2020-04-07 12:09, Grzegorz Junka wrote:

Is it expected that drm doesn't work on 12.1-RELEASE


Yes, for now.

You can diff:

/usr/src/sys/compat/linuxkpi

Between the two to see the differences.


Once I install kernel/world from stable-12 branch should I compile and 
install drm-fbsd12.0-kmod or drm-devel-kmod?


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: amdgpu panics

[Grzegorz Junka]

On 07/04/2020 09:55, Hans Petter Selasky wrote:

On 2020-04-07 11:35, Grzegorz Junka wrote:

kern.osrelease: 12.1-RELEASE-p3


Hi,

This is not 12.1-STABLE! Yes, you can use a 12.1-STABLE kernel with 
the 12.1-RELEASE.


Can you try this:

rm -rf /usr/src
cd /usr
svn checkout https://svn.freebsd.org/base/stable/12 /usr/src

cd /usr/src
make buildkernel -j6
make installkernel -j6

cd /usr/ports/graphics/drm-fbsd12.0-kmod
make all deinstall install clean

cd /usr/ports/graphics/gpu-firmware-kmod
make all deinstall install clean

Then reboot, and try to test the driver again.


I'm sorry to say, you _need_ -stable or -current for now, when using 
the new DRM stuff!




That right, it isn't STABLE. I stated that in one of my previous emails:

> I might be able to recompile everything with 12.1-STABLE instead of 
12.1-RELEASE-p3 but that might take a while so preferably would like to 
try what's possible before embarking on that adventure.


I followed on your previous advice to recompile world and GENERIC kernel 
instead of using my custom VENUS kernel. Trying with STABLE instead was 
a separate thread. I understood those are alternatives. Is it expected 
that drm doesn't work on 12.1-RELEASE even if the kernel and packages 
are compiled from sources?


I remember being able to load amdgpu.ko on 12.0-RELEASE. Why this no 
longer works? Is 12.1-RELEASE expected to work again at some point, 
maybe with p4?



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: amdgpu panics

[Grzegorz Junka]

On 07/04/2020 09:29, Hans Petter Selasky wrote:

On 2020-04-07 11:19, Grzegorz Junka wrote:

25    3 0x83109000    76570 drm.ko


Please also double check, that you've loaded /boot/modules/drm.ko and 
not /boot/kernel/drm.ko !


ll /boot/modules/ | grep drm
-r-xr-xr-x  1 root wheel   757152 Jan 17 15:51 drm.ko*
ll /boot/kernel | grep drm
-r-xr-xr-x  1 root  wheel    165376 Jan 17 15:38 drm.ko*
-r-xr-xr-x  1 root  wheel    535328 Jan 17 15:38 drm2.ko*



Yes, I am loading with

kldload /boot/modules/drm.ko /boot/modules/amdgpu.ko

If I try

kldload /boot/kernel/drm.ko /boot/modules/amdgpu.ko

I am getting error:

Apr  7 09:36:49 venus kernel: KLD amdgpu.ko: depends on drmn - not 
available or version mismatch
Apr  7 09:36:49 venus kernel: linker_load_file: /boot/modules/amdgpu.ko 
- unsupported file type


and kldload fails

___
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: amdgpu panics

[Grzegorz Junka]

On 07/04/2020 09:21, Hans Petter Selasky wrote:

Try:

sysctl -a | grep linuxkpi


That finally crashed the system. After restart I loaded the modules 
again and tried without grep. This is how far it goes:


root@venus:/home/g # sysctl -a
kern.ostype: FreeBSD
kern.osrelease: 12.1-RELEASE-p3
kern.osrevision: 199506
kern.version: FreeBSD 12.1-RELEASE-p3 GENERIC

kern.maxvnodes: 1164970
kern.maxproc: 70804
kern.maxfiles: 2093468
kern.argmax: 262144

Then nothing.

I am loading the modules with:

kldload /boot/modules/drm.ko /boot/modules/admgpu.ko

as you told me in an earlier email. Without loading the modules this is 
what I am getting:



root@venus:~ # sysctl -a | grep linuxkpi
-> nothing


root@venus:~ # sysctl -a | grep compat
kern.features.compat_freebsd7: 1
kern.features.compat_freebsd6: 1
kern.features.compat_freebsd5: 1
kern.features.compat_freebsd4: 1
kern.features.geom_part_ebr_compat: 1
kern.features.compat_freebsd_32bit: 1
hw.snd.compat_linux_mmap: 0
dev.uart.0.%desc: 16550 or compatible
dev.vgapci.0.%desc: VGA-compatible display
compat.linux32.maxvmem: 0
compat.linux32.maxssiz: 67108864
compat.linux32.maxdsiz: 536870912
compat.linux.oss_version: 198144
compat.linux.osrelease: 2.6.32
compat.linux.osname: Linux
compat.ia32.maxvmem: 0
compat.ia32.maxssiz: 67108864
compat.ia32.maxdsiz: 536870912


root@venus:~ # sysctl -a
kern.ostype: FreeBSD
kern.osrelease: 12.1-RELEASE-p3
kern.osrevision: 199506
kern.version: FreeBSD 12.1-RELEASE-p3 GENERIC

kern.maxvnodes: 1164970
kern.maxproc: 70804
kern.maxfiles: 2093468
kern.argmax: 262144
kern.securelevel: -1
...
(and so on, cutting as it's too long)


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: amdgpu panics

[Grzegorz Junka]

On 07/04/2020 09:16, Hans Petter Selasky wrote:

On 2020-04-07 11:06, Grzegorz Junka wrote:


On 07/04/2020 08:54, Hans Petter Selasky wrote:

On 2020-04-07 10:27, Grzegorz Junka wrote:
Apr  7 07:54:38 venus kernel: [drm] Display Core initialized with 
v3.1.27!
Apr  7 07:54:38 venus kernel: [drm] Connector DP-1: get mode from 
tunables:

Apr  7 07:54:38 venus kernel: [drm]   - kern.vt.fb.modes.DP-1
Apr  7 07:54:38 venus kernel: [drm]   - kern.vt.fb.default_mode
Apr  7 07:54:38 venus kernel: [drm] Connector DP-2: get mode from 
tunables:

Apr  7 07:54:38 venus kernel: [drm]   - kern.vt.fb.modes.DP-2
Apr  7 07:54:38 venus kernel: [drm]   - kern.vt.fb.default_mode
Apr  7 07:54:38 venus kernel: [drm] Connector DP-3: get mode from 
tunables:

Apr  7 07:54:38 venus kernel: [drm]   - kern.vt.fb.modes.DP-3
Apr  7 07:54:38 venus kernel: [drm]   - kern.vt.fb.default_mode


Maybe there is a problem configuring the display ports!

Can you dump the output from:

sysctl -a compat.linuxkpi

Maybe there is some knob you need to flip to turn on the monitor!


root@venus:~ # sysctl -a compat.linuxkpi
sysctl: unknown oid 'compat.linuxkpi'



Is this after loading the amdgpu driver?

Can you show:

kldstat



Yes, I am still in the root ssh session that survived the blanked screen.

root@venus:~ # kldstat
Id Refs Address    Size Name
 1  142 0x8020  2448f20 kernel
 2    1 0x8264a000   3a99a8 zfs.ko
 3    2 0x829f4000 a5b8 opensolaris.ko
 4    1 0x82f11000 494c linprocfs.ko
 5    3 0x82f16000 3178 linux_common.ko
 6    1 0x82f1a000 88d8 tmpfs.ko
 7    1 0x82f23000    15d20 if_iwm.ko
 8    1 0x82f39000    fb11f iwm3168fw.ko
 9    1 0x83035000 2668 intpm.ko
10    1 0x83038000  b50 smbus.ko
11    1 0x83039000 18a0 uhid.ko
12    1 0x8303b000 2928 ums.ko
13    1 0x8303e000 1aa0 wmt.ko
14    1 0x8304 cd70 snd_uaudio.ko
15    1 0x8304d000 4260 ng_ubt.ko
16    6 0x83052000 9e30 netgraph.ko
17    2 0x8305c000 91b8 ng_hci.ko
18    3 0x83066000  9c0 ng_bluetooth.ko
19    1 0x83067000 cad0 ng_l2cap.ko
20    1 0x83074000    1ba00 ng_btsocket.ko
21    1 0x8309 21c0 ng_socket.ko
22    1 0x83093000    3df60 linux.ko
23    1 0x830d1000    35b20 linux64.ko
24    1 0x83107000 1aa0 fdescfs.ko
25    3 0x83109000    76570 drm.ko
26    5 0x8318    10eb0 linuxkpi.ko
27    4 0x83191000    12f30 linuxkpi_gplv2.ko
28    2 0x831a4000  6d0 debugfs.ko
30    1 0x833f6000 f181 ttm.ko
31    1 0x83406000  2c1 amdgpu_vega10_gpu_info_bin.ko
32    1 0x83407000    27d07 amdgpu_vega10_sos_bin.ko
33    1 0x8342f000    1e377 amdgpu_vega10_asd_bin.ko
34    1 0x8344e000    4047f amdgpu_vega10_acg_smc_bin.ko
35    1 0x8348f000 55f7 amdgpu_vega10_pfp_bin.ko
36    1 0x83495000 45f5 amdgpu_vega10_me_bin.ko
37    1 0x8349a000 25f5 amdgpu_vega10_ce_bin.ko
38    1 0x8349d000 4477 amdgpu_vega10_rlc_bin.ko
39    1 0x834a2000    41887 amdgpu_vega10_mec_bin.ko
40    1 0x834e4000    41889 amdgpu_vega10_mec2_bin.ko
41    1 0x83526000 4579 amdgpu_vega10_sdma_bin.ko
42    1 0x8352b000 457b amdgpu_vega10_sdma1_bin.ko
43    1 0x8353    5c337 amdgpu_vega10_uvd_bin.ko
44    1 0x8358d000    2a797 amdgpu_vega10_vce_bin.ko


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: amdgpu panics

[Grzegorz Junka]

On 07/04/2020 08:54, Hans Petter Selasky wrote:

On 2020-04-07 10:27, Grzegorz Junka wrote:
Apr  7 07:54:38 venus kernel: [drm] Display Core initialized with 
v3.1.27!
Apr  7 07:54:38 venus kernel: [drm] Connector DP-1: get mode from 
tunables:

Apr  7 07:54:38 venus kernel: [drm]   - kern.vt.fb.modes.DP-1
Apr  7 07:54:38 venus kernel: [drm]   - kern.vt.fb.default_mode
Apr  7 07:54:38 venus kernel: [drm] Connector DP-2: get mode from 
tunables:

Apr  7 07:54:38 venus kernel: [drm]   - kern.vt.fb.modes.DP-2
Apr  7 07:54:38 venus kernel: [drm]   - kern.vt.fb.default_mode
Apr  7 07:54:38 venus kernel: [drm] Connector DP-3: get mode from 
tunables:

Apr  7 07:54:38 venus kernel: [drm]   - kern.vt.fb.modes.DP-3
Apr  7 07:54:38 venus kernel: [drm]   - kern.vt.fb.default_mode


Maybe there is a problem configuring the display ports!

Can you dump the output from:

sysctl -a compat.linuxkpi

Maybe there is some knob you need to flip to turn on the monitor!


root@venus:~ # sysctl -a compat.linuxkpi
sysctl: unknown oid 'compat.linuxkpi'


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: amdgpu panics

[Grzegorz Junka]

On 06/04/2020 23:49, Hans Petter Selasky wrote:

On 2020-04-07 00:07, Grzegorz Junka wrote:


Is it possible to at least gather some debug info where this happens? 
I don't think there is any core dumped if the system doesn't panic?


Can you SSH to this machine and get dmesg?



I sent the dmesg after booting privately as it was quite long. One 
interesting thing I just noticed is that the halt is not a complete 
halt. The system responds to ping and an ssh user session was active, in 
the sense that I could do ls -l and get a response. But it hung as soon 
as I tried su. Same with initiating any new ssh session - the system 
responds with prompt for password but after that nothing happens.


This is the content of the messages log starting at the moment when I 
try to load the modules:


Apr  7 07:54:30 venus kernel: [drm] amdgpu kernel modesetting enabled.
Apr  7 07:54:30 venus kernel: drmn0:  on vgapci0
Apr  7 07:54:30 venus kernel: vgapci0: child drmn0 requested pci_enable_io
Apr  7 07:54:30 venus syslogd: last message repeated 1 times
Apr  7 07:54:30 venus kernel: [drm] initializing kernel modesetting 
(VEGA10 0x1002:0x687F 0x1002:0x0B36 0xC0).

Apr  7 07:54:30 venus kernel: [drm] register mmio base: 0xFD10
Apr  7 07:54:30 venus kernel: [drm] register mmio size: 524288
Apr  7 07:54:30 venus kernel: [drm] PCI I/O BAR is not found.
Apr  7 07:54:30 venus kernel: drmn0: successfully loaded firmware image 
with name: amdgpu/vega10_gpu_info.bin
Apr  7 07:54:30 venus kernel: [drm] probing gen 2 caps for device 
1022:1471 = 700d03/e
Apr  7 07:54:30 venus kernel: [drm] probing mlw for device 1002:687f = 
400d03

Apr  7 07:54:30 venus kernel: [drm] UVD is enabled in VM mode
Apr  7 07:54:30 venus kernel: [drm] UVD ENC is enabled in VM mode
Apr  7 07:54:30 venus kernel: [drm] VCE enabled in VM mode
Apr  7 07:54:30 venus kernel: ATOM BIOS: 113-D0500500-104
Apr  7 07:54:30 venus kernel: [drm] vm size is 262144 GB, 4 levels, 
block size is 9-bit, fragment size is 9-bit
Apr  7 07:54:30 venus kernel: drmn0: VRAM: 8176M 0x00F4 - 
0x00F5FEFF (8176M used)
Apr  7 07:54:30 venus kernel: drmn0: GTT: 256M 0x00F6 - 
0x00F60FFF
Apr  7 07:54:30 venus kernel: Successfully added WC MTRR for 
[0xe000-0xefff]: 0;

Apr  7 07:54:30 venus kernel: [drm] Detected VRAM RAM=8176M, BAR=256M
Apr  7 07:54:30 venus kernel: [drm] RAM width 2048bits HBM
Apr  7 07:54:30 venus kernel: [TTM] Zone  kernel: Available graphics 
memory: 33495488 kiB
Apr  7 07:54:30 venus kernel: [TTM] Zone   dma32: Available graphics 
memory: 2097152 kiB

Apr  7 07:54:30 venus kernel: [TTM] Initializing pool allocator
Apr  7 07:54:30 venus kernel: [drm] amdgpu: 8176M of VRAM memory ready
Apr  7 07:54:30 venus kernel: [drm] amdgpu: 8176M of GTT memory ready.
Apr  7 07:54:30 venus kernel: i_size_write unimplemented
Apr  7 07:54:30 venus kernel: [drm] GART: num cpu pages 65536, num gpu 
pages 65536
Apr  7 07:54:30 venus kernel: [drm] PCIE GART of 256M enabled (table at 
0x00F40080).
Apr  7 07:54:31 venus kernel: drmn0: successfully loaded firmware image 
with name: amdgpu/vega10_sos.bin
Apr  7 07:54:32 venus kernel: drmn0: successfully loaded firmware image 
with name: amdgpu/vega10_asd.bin
Apr  7 07:54:32 venus kernel: drmn0: successfully loaded firmware image 
with name: amdgpu/vega10_acg_smc.bin
Apr  7 07:54:33 venus kernel: drmn0: successfully loaded firmware image 
with name: amdgpu/vega10_pfp.bin
Apr  7 07:54:33 venus kernel: drmn0: successfully loaded firmware image 
with name: amdgpu/vega10_me.bin
Apr  7 07:54:34 venus kernel: drmn0: successfully loaded firmware image 
with name: amdgpu/vega10_ce.bin
Apr  7 07:54:34 venus kernel: drmn0: successfully loaded firmware image 
with name: amdgpu/vega10_rlc.bin
Apr  7 07:54:35 venus kernel: drmn0: successfully loaded firmware image 
with name: amdgpu/vega10_mec.bin
Apr  7 07:54:35 venus kernel: drmn0: successfully loaded firmware image 
with name: amdgpu/vega10_mec2.bin

Apr  7 07:54:35 venus kernel: i_size_write unimplemented
Apr  7 07:54:35 venus syslogd: last message repeated 9 times
Apr  7 07:54:36 venus kernel: drmn0: successfully loaded firmware image 
with name: amdgpu/vega10_sdma.bin
Apr  7 07:54:36 venus kernel: drmn0: successfully loaded firmware image 
with name: amdgpu/vega10_sdma1.bin

Apr  7 07:54:36 venus kernel: [drm] use_doorbell being set to: [true]
Apr  7 07:54:36 venus kernel: i_size_write unimplemented
Apr  7 07:54:36 venus kernel: [drm] use_doorbell being set to: [true]
Apr  7 07:54:36 venus kernel: i_size_write unimplemented
Apr  7 07:54:37 venus kernel: drmn0: successfully loaded firmware image 
with name: amdgpu/vega10_uvd.bin
Apr  7 07:54:37 venus kernel: [drm] Found UVD firmware Version: 65.29 
Family ID: 17

Apr  7 07:54:37 venus kernel: [drm] PSP loading UVD firmware
Apr  7 07:54:37 venus kernel: i_size_write unimplemented
Apr  7 07:54:37 venus syslogd: last message repeated 2 times
Apr  7 07:54:37 venus kernel: drmn0

Re: amdgpu panics

[Grzegorz Junka]

On 06/04/2020 09:25, Hans Petter Selasky wrote:

On 2020-04-06 11:19, Grzegorz Junka wrote:


Of course I can recompile the kernel and world using GENERIC kernel 
config, that at least would compile all modules that aren't normally 
compiled with GENERIC.


I just want to rule out some things, so if you can try this manually 
would be great.


Did that just now. Compiled world and GENERIC kernel on my build host, 
installed on the desktop through FreeBSD-base packages, reinstalled all 
kmod packages.


Once more

kldload /boot/modules/drm.ko /boot/modules/amdgpu.ko

consistently and reliably halts the system. I noticed that it happens 
just after vega10_vce.ko is loaded, probably at the moment when the 
screen is supposed to be switched to the amdgpu framebuffer. There is no 
panic, the screen goes blank and after a while monitor goes to sleep.


Is it possible to at least gather some debug info where this happens? I 
don't think there is any core dumped if the system doesn't panic?


I might be able to recompile everything with 12.1-STABLE instead of 
12.1-RELEASE-p3 but that might take a while so preferably would like to 
try what's possible before embarking on that adventure.


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: amdgpu panics

[Grzegorz Junka]

On 06/04/2020 10:25, Hans Petter Selasky wrote:

On 2020-04-06 11:19, Grzegorz Junka wrote:


Of course I can recompile the kernel and world using GENERIC kernel 
config, that at least would compile all modules that aren't normally 
compiled with GENERIC.


I just want to rule out some things, so if you can try this manually 
would be great.


--HPS



This brings me back to your previous suggestion to build and install 
12-stable kernel instead of release. That wouldn't work unless I also 
compiled gpu-firmware-kmod and drm-fbsd12.0-kmod on the same host, not 
in poudriere?


Recompiling kernel/world with GENERIC should be quite easy, but if that 
still doesn't work, I guess the next step would be to reconfigure 
poudriere to use the /usr/src or even kernel/world from the host.


Thank you for your help so far

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: amdgpu panics

[Grzegorz Junka]

On 06/04/2020 09:32, Matthias Andree wrote:

Am 06.04.20 um 09:37 schrieb Grzegorz Junka:

On 06/04/2020 08:21, Hans Petter Selasky wrote:

They don't match, and they can't.

Files in /boot/modules have been installed by drm-fbsd12.0-kmod and
files in /boot/kernel have been installed by
FreeBSD-kernel-venus-12.1_3 (venus is the name I gave the kernel
configuration).

Is drm-fbsd12.0-kmod built using the same sources as
FreeBSD-kernel-venus-12.1_3. Can you try this:

1) Build and install a fresh 12-stable kernel, not release kernel,
from /usr/src
2) Build and install /usr/ports/graphics/gpu-firmware-kmod
3) Build and install /usr/ports/graphics/drm-fbsd12.0-kmod


I built the ports and the kernel on the same system but at different
times. First I updated all sources (/usr/src and /usr/ports) then I
built packages. When that didn't work, few days later I built the
kernel and world. No updates to the sources have been made between
those two.

kldload /boot/modules/drm.ko /boot/modules/amdgpu.ko  <- doesn't
work, system halts after loading one of the vega10 modules.

--HPS


I am not sure I understand your question. drm-fbsd12.0-kmod is a port
so it's built from /usr/local/poudriere/ports whereas
FreeBSD-kernel-venus-12.1_3 is one of base packages build from /usr/src.

AGAIN:

Do *NOT* build kernel modules in poudriere unless you can guarantee it's
using the *EXACT SAME* kernel configuration and sources, you must solve
this discrepancy:



Sorry, what discrepancy do you mean? How does FreeBSD build the 
drm-fbsd12.0-kmod on the FreeBSD pkg build server if not with poudriere? 
Does it have any specific configuration I don't know about, e.g. null 
mounted /usr/src to the host?


Is it even possible to build a poudriere package with a non-generic 
kernel configuration in the poudriere jail?


What if I create the poudriere build jail from the kernel / world I 
built on the host? Is that possible?




If you are asking if /usr/src is the same when building ports and
kernel then again, no, because when building ports the jail's /usr/src
is used, whereas when building the kernel the host's /usr/src is used.

But I verified that both are the same, i.e.,

diff -r /usr/src /usr/local/poudriere/jails/12rel1/usr/src

doesn't return any differences, apart from the additional kernel
configuration. They are both 12.1-RELEASE-p3 (checked the version
against sources in Github and SVN).

...and "additional kernel configuration" is the thing that MIGHT break
the module in build if the kernel config has any impact on sources that
the module uses.



The issue was the same with a stock GENERIC 12.1-p3 kernel, which I 
would expect would be build from the EXACT same sources as the RELENG 
12.1 branch https://github.com/freebsd/freebsd/tree/releng/12.1, which I 
would expect freebsd-update to fetch to both, my host and the poudriere 
jail after it updated both to 12.1-RELEASE-p3. At least I verified the 
/sys/conf/newvers.sh in my jail and host to match the file in that 
branch in Github.


Of course I can recompile the kernel and world using GENERIC kernel 
config, that at least would compile all modules that aren't normally 
compiled with GENERIC.




I still haven't understood why you cannot boot without amdgpu, and then
built (a) kernel, (b) firmware, (c) amdgpu and DRM drivers all directly
from /usr/src and updated /usr/ports
*ON THE MACHINE WITH THE AMD VGA CARD*. There are way too many variables
in the mix.



I can but I have more than one desktop and I don't want to recompile 
everything from sources on each one. That's why I have a central build 
server. Tell me how I should configure the build server to build the 
packages and/or kernel and/or world in a way that the graphics stack 
expects it to be build and it would be solved.


Or what you are really saying is that if someone wants to use the new 
drm graphics stack they HAVE TO recompile (a) kernel, (b) firmware, (c) 
amdgpu from sources on the host every time?


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: amdgpu panics

[Grzegorz Junka]

On 06/04/2020 08:21, Hans Petter Selasky wrote:


They don't match, and they can't.

Files in /boot/modules have been installed by drm-fbsd12.0-kmod and 
files in /boot/kernel have been installed by 
FreeBSD-kernel-venus-12.1_3 (venus is the name I gave the kernel 
configuration).


Is drm-fbsd12.0-kmod built using the same sources as 
FreeBSD-kernel-venus-12.1_3. Can you try this:


1) Build and install a fresh 12-stable kernel, not release kernel, 
from /usr/src

2) Build and install /usr/ports/graphics/gpu-firmware-kmod
3) Build and install /usr/ports/graphics/drm-fbsd12.0-kmod



I built the ports and the kernel on the same system but at different 
times. First I updated all sources (/usr/src and /usr/ports) then I 
built packages. When that didn't work, few days later I built the 
kernel and world. No updates to the sources have been made between 
those two.


kldload /boot/modules/drm.ko /boot/modules/amdgpu.ko  <- doesn't 
work, system halts after loading one of the vega10 modules.


--HPS



I am not sure I understand your question. drm-fbsd12.0-kmod is a port so 
it's built from /usr/local/poudriere/ports whereas 
FreeBSD-kernel-venus-12.1_3 is one of base packages build from /usr/src.


If you are asking if /usr/src is the same when building ports and kernel 
then again, no, because when building ports the jail's /usr/src is used, 
whereas when building the kernel the host's /usr/src is used.


But I verified that both are the same, i.e.,

diff -r /usr/src /usr/local/poudriere/jails/12rel1/usr/src

doesn't return any differences, apart from the additional kernel 
configuration. They are both 12.1-RELEASE-p3 (checked the version 
against sources in Github and SVN).


I can certainly build and install a stable kernel, but I believe I would 
also need to recompile the packages with stable /usr/src in the 
poudriere's jail, which means creating a new jail and possibly 
recompiling all the packages? Can I install stable kernel into 
12.1-RELEASE-p3 world?


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: amdgpu panics

[Grzegorz Junka]

On 05/04/2020 21:58, Grzegorz Junka wrote:


On 05/04/2020 13:40, Hans Petter Selasky wrote:

On 2020-04-05 14:18, Grzegorz Junka wrote:


How can I debug what's wrong?


Can you check the timestamps for:

ls -l /boot/modules

and

ls -l /boot/kernel

That they match?

Try loading like this:

kldload /boot/modules/drm.ko /boot/modules/amdgpu.ko

--HPS



They don't match, and they can't.

Files in /boot/modules have been installed by drm-fbsd12.0-kmod and 
files in /boot/kernel have been installed by 
FreeBSD-kernel-venus-12.1_3 (venus is the name I gave the kernel 
configuration).


I built the ports and the kernel on the same system but at different 
times. First I updated all sources (/usr/src and /usr/ports) then I 
built packages. When that didn't work, few days later I built the 
kernel and world. No updates to the sources have been made between 
those two.


kldload /boot/modules/drm.ko /boot/modules/amdgpu.ko  <- doesn't work, 
system halts after loading one of the vega10 modules.


GrzegorzJ


^ correction - port sources are of course in /usr/local/poudriere/ports, 
not /usr/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: amdgpu panics

[Grzegorz Junka]

On 05/04/2020 13:40, Hans Petter Selasky wrote:

On 2020-04-05 14:18, Grzegorz Junka wrote:


How can I debug what's wrong?


Can you check the timestamps for:

ls -l /boot/modules

and

ls -l /boot/kernel

That they match?

Try loading like this:

kldload /boot/modules/drm.ko /boot/modules/amdgpu.ko

--HPS



They don't match, and they can't.

Files in /boot/modules have been installed by drm-fbsd12.0-kmod and 
files in /boot/kernel have been installed by FreeBSD-kernel-venus-12.1_3 
(venus is the name I gave the kernel configuration).


I built the ports and the kernel on the same system but at different 
times. First I updated all sources (/usr/src and /usr/ports) then I 
built packages. When that didn't work, few days later I built the kernel 
and world. No updates to the sources have been made between those two.


kldload /boot/modules/drm.ko /boot/modules/amdgpu.ko  <- doesn't work, 
system halts after loading one of the vega10 modules.


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: amdgpu panics

[Grzegorz Junka]

On 04/04/2020 10:27, Matthias Andree wrote:

Thank you John for the comprehensive explanation. It took me a while to
go through all the details, then again to recompile the ports and try to
reinstall all packages.

What i discovered in the meantime is that it's not an isolated problem:


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241787

https://forums.freebsd.org/threads/upgrading-to-freebsd-12-1-release-resolving-an-issue-with-drm-fbsd12-0-kmod.72895/



On my system I indeed had the jail at a different patch level than the
host system, although they were all running 12.1-RELEASE. I updated
the host and the jail to 12.1-RELEASE-p3. Poudriere noticed the
updated jail and deleted and recompiled all 2000+ packages. Then I
upgraded the system on which I wanted to install the packages to
12.1-RELEASE-p3 too. Then I deleted drm-fbsd12.0-kmod and installed
drm-kmod. It reinstalled drm-fbsd12.0-kmod.

The result? Blank screen!!!

I start as single or normal user then do:

kldload amdgpu

I see the driver is loading various graphics kernel modules then the
screen goes blank and the whole system hangs. No panic is shown, no
restart, just hungs. Any SSH sessions to the system become stale. Only
hard reset is able to restart it.

This is really frustrating and a really bad user experience. I
wouldn't be surprised if the remained desktop users moved to Linux or
other FreeBSD forks if they haven't already.

The only option left I see is to also compile the kernel myself from
sources.

Compared to 2,000 packages that seams a reasonable approach, and then IN
THAT SAME LIVE SYSTEM also rebuild the graphics modules.

I understand that the poudriere/pkg proponents have aggressively lobbied
users to use pkg and poudriere for clean-room builds, but I wonder if it
isn't easier to forgo poudriere for drivers and instead:

obtain/update to 12.1-RELEASE-p3 sources in /usr/src (with svn, for
instance)
make buildworld buildkernel
make installkernel
edit your loader.conf[.local] so it doesn't load b0rked graphics modules,
reboot into single-user
mergemaster -Fp
make installworld
mergemaster -Fi
make delete-old # important - there may be 12.0 parts that need removal,
12.1 for instance updated LLVM
rebuild your kmods and drivers IN THIS LIVE SYSTEM RIGHT FROM PORTS (not
poudriere)
install kmods and drivers
reboot and then gradually manually load kernel drivers such as amdgpu
one by one so you know which work (enable them in the loader) and which
won't.

I am not sure if it helps for amdgpu, since I am using nvidia- which
sort-of works (but GNOME frequently flakes out for my user but not other
users)... but I'd think this approach forgoes any potential difference
between the build jail and live system kernel sources

Of course this rules out freebsd-update for kernel/system patching then,
you'd update /usr/src and then make -DNOCLEAN buildworld buildkernel and
install again once -p4 or newer come out.



I reinstalled the whole system from a newly compiled kernel and world. 
It didn't help. When I do "kldload amdgpu" the screen goes blank after 
loading one of the driver modules.


I have compiled the base on another system and firstly just unpacked the 
kernel files. When that didn't work I used FreeBSD-base packages to 
reinstall everything from the build server. It worked pretty well but 
didn't change a thing.


The build system has an NVidia card and an AMD (Phenom) process. The 
system on which I install has AMD Vega 64 card and another AMD (Ryzen) 
processor. I don't use any configuration to build for a specific 
architecture and I hope "drm-fbsd12.0-kmod" doesn't do any optimizations 
based on the architecture on which it's compiled.


How can I debug what's wrong?

Grzegorz J


___
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: amdgpu panics

[Grzegorz Junka]

On 12/03/2020 16:34, John Kennedy wrote:

On Thu, Mar 12, 2020 at 12:22:21AM +, Grzegorz Junka wrote:

On 10/03/2020 19:46, Hans Petter Selasky wrote:

On 2020-03-10 20:29, Grzegorz Junka wrote:

On 09/03/2020 23:04, Hans Petter Selasky wrote:

On 2020-03-10 00:03, Grzegorz Junka wrote:

I've upgraded my system to 12.1. I have recompiled all ports
with poudriere using jail 12.1. As soon as "amdgpu" kernel
module is loaded the system panics. Tried with both,
"drm-kmo" and "drm-fbsd12.0-kmod". Any ideas?

Are the kernel sources in the jail matched with your system?

Sorry, I don't understand your question. Why does it matter? The
jail was created by poudriere. Does the installed package use
sources from my system?

All kernel module packages use sources from the build system!

The base system has also been updated to 12.1 if that's what you are asking.
I am not sure if the sources are the same. Both the host and the poudriere
jail are 12.1. Do they need to be exact to the patch version?

I understood that the drm-kmod or drm-fsbsd12.0-kmod are build as packages
by poudriere in the poudriere jail. Are you saying that they are build with
sources from the host? How is that possible?

   This may have absolutely nothing to do with your setup.  I can only say that
I've been where you are in the past, what I've done, and that it has made me
happy and solved my problems.

   First off, packages are great.  I can't quantify that, but I know that the
small percentage of the time that they don't work for some reason is really
annoying to me (and arguably a personal problem).  (:  But here is how I've
channeled that into something productive, even if it isn't something that
everybody can do.  If everybody could do it, we wouldn't have a strong demand
for packages (even ignoring some economy of scale/ease of use arguments).

   First off, I have a local poudriere setup, and compile all my packages from
source.  I have some non-default options that I prefer, occasionally some odd
platforms (arm64, etc) and run closer to the bleeding edge (I tend to ride
the pre- into OS releases, use the master (vs quarterly) ports, etc.  So I'm
pretty sure I run into all the problems that the ports/src (and other 
reasonable)
people expect.  Compiling from source dodges a huge number of those.  I didn't
have problems with pkg, X11 during -1.20 (except the FIXDRM/DRI issue for one
graphics card, and only showed up with firefox with certain site graphics), the
input problems some people have had, etc.  I've been very pleased to not have
those problems, although a bunch of them had nothing to do with how something
was compiled vs life moving on and things changing (udev/dev/event changes, 
etc).
Lets face it, X11 is annoying.  I have a very stripped down X11 environment
and I think it is at least 253 packages, even more if you have X11 for reasons
(like firefox browser).  Kudos to a lot of nameless people keeping that whole
mess working  as well as it does.

   That "life" choice has been REALLY painful on RPI3/arm64, but not painful
at all on amd64 type systems, your mileage may vary.  It has certainly given
me an understanding on why some packages on FreeBSD's repo take a while to
get out.  I'm only building ~500 packages, and they're building all of them.
Watching a readline upgrade trigger hundreds of packages to rebuild hurts,
but it helps solve the mixing-source-and-package-can-hurt problems.

   In any case, on my poudriere system, I upgrade the kernel jail (poudriere
jail -u ...) once per patch on release systems and maybe once a week (or CVE,
or when they bump __FreeBSD_version) when I'm tracking stable.  Basically
when I think that the kernel ABI might have changed or when some security
related piece of code might need to be baked into the packages.  The ultimate
thing might be once per kernel upgrade, but that is overkill so I try to
compensate with the weekly sync, just in case.  AFAIK, the ports builders
keep theirs at the -release level (?), which is pretty good for most things
but fails in a few cases (and here is where some of the readers are).

   In my case, I created the kernel source jail like this:

poudriere jail -c -j 12-1 -v 12.1 -m src=/usr/src

   It just has whatever source when you create it or when you update it.  I
didn't try to create it with a null method, but maybe that would work.  If
you upgrade your local kernel but not your jail, then yes, you can have some
kernel ABI issues that might bite you like you've seen (kernel panics).

   I haven't had a problem with video drivers myself, but what drove that
behavior used to be virtual box.

   Probably daily I pull down the source tree and let poudriere decide what
ports need to be rebuilt.  They're always built with kernel OS that is really
close to what is actually running.

   On top of all of THAT, I have this in my /etc/make.conf:

# be extra paranoid about drivers being compiled 

Re: amdgpu panics

[Grzegorz Junka]

On 10/03/2020 19:46, Hans Petter Selasky wrote:

On 2020-03-10 20:29, Grzegorz Junka wrote:


On 09/03/2020 23:04, Hans Petter Selasky wrote:

On 2020-03-10 00:03, Grzegorz Junka wrote:
I've upgraded my system to 12.1. I have recompiled all ports with 
poudriere using jail 12.1. As soon as "amdgpu" kernel module is 
loaded the system panics. Tried with both, "drm-kmo" and 
"drm-fbsd12.0-kmod". Any ideas?




Are the kernel sources in the jail matched with your system?

--HPS



Sorry, I don't understand your question. Why does it matter? The jail 
was created by poudriere. Does the installed package use sources from 
my system?




All kernel module packages use sources from the build system!



The base system has also been updated to 12.1 if that's what you are 
asking. I am not sure if the sources are the same. Both the host and the 
poudriere jail are 12.1. Do they need to be exact to the patch version?


I understood that the drm-kmod or drm-fsbsd12.0-kmod are build as 
packages by poudriere in the poudriere jail. Are you saying that they 
are build with sources from the host? How is that possible?


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: amdgpu panics

[Grzegorz Junka]

On 09/03/2020 23:04, Hans Petter Selasky wrote:

On 2020-03-10 00:03, Grzegorz Junka wrote:
I've upgraded my system to 12.1. I have recompiled all ports with 
poudriere using jail 12.1. As soon as "amdgpu" kernel module is 
loaded the system panics. Tried with both, "drm-kmo" and 
"drm-fbsd12.0-kmod". Any ideas?




Are the kernel sources in the jail matched with your system?

--HPS



Sorry, I don't understand your question. Why does it matter? The jail 
was created by poudriere. Does the installed package use sources from my 
system?


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"

amdgpu panics

[Grzegorz Junka]

I've upgraded my system to 12.1. I have recompiled all ports with 
poudriere using jail 12.1. As soon as "amdgpu" kernel module is loaded 
the system panics. Tried with both, "drm-kmo" and "drm-fbsd12.0-kmod". 
Any ideas?


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: pkg / poudriere issue - wrong packagesite / meta

[Grzegorz Junka]

On 02/03/2020 17:49, Grzegorz Junka wrote:
I just finished building ports for FreeBSD 12.1. I have already 
upgraded base to 12.1 and now I am trying to update packages, but pkg 
fails with this cryptic error:


# pkg update
Updating desktop_nvidia repository catalogue...
pkg: repository meta has wrong version 2
pkg: Repository desktop_nvidia load error: meta cannot be loaded No 
error: 0

Fetching meta.txz: 100%    236 B   0.2kB/s    00:01
pkg: repository meta has wrong version 2
repository desktop_nvidia has no meta file, using default settings
Fetching packagesite.txz: 100%  463 KiB 474.1kB/s    00:01
pkg: repository meta has wrong version 2
pkg: Repository desktop_nvidia load error: meta cannot be loaded No 
error: 0

Unable to open created repository desktop_nvidia
Unable to update repository desktop_nvidia
Error updating repositories!



This is now solved, at least for my issue. I copied the pkg locally and 
installed it while the pkg.conf was still pointing to the old repo (with 
old meta). After installing I switched to the new repo and thankfully 
the newer version of pkg was able to read the new meta format and it 
updated the database correctly.



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

pkg / poudriere issue - wrong packagesite / meta

[Grzegorz Junka]

I just finished building ports for FreeBSD 12.1. I have already upgraded 
base to 12.1 and now I am trying to update packages, but pkg fails with 
this cryptic error:


# pkg update
Updating desktop_nvidia repository catalogue...
pkg: repository meta has wrong version 2
pkg: Repository desktop_nvidia load error: meta cannot be loaded No error: 0
Fetching meta.txz: 100%    236 B   0.2kB/s    00:01
pkg: repository meta has wrong version 2
repository desktop_nvidia has no meta file, using default settings
Fetching packagesite.txz: 100%  463 KiB 474.1kB/s    00:01
pkg: repository meta has wrong version 2
pkg: Repository desktop_nvidia load error: meta cannot be loaded No error: 0
Unable to open created repository desktop_nvidia
Unable to update repository desktop_nvidia
Error updating repositories!

There was no error in poudriere, 1067 packages have been built 
successfully, 1 skipped, 3 ignored.


Poudriere version 3.3.2_1

The new repo has meta:

# cat meta.conf
version = 2;
packing_format = "txz";
manifests = "packagesite.yaml";
filesite = "filesite.yaml";
manifests_archive = "packagesite";
filesite_archive = "filesite";

The old repo had meta:

# cat meta
version = 1;
packing_format = "txz";
digest_format = "sha256_base32";
digests = "digests";
manifests = "packagesite.yaml";
filesite = "filesite.yaml";
digests_archive = "digests";
manifests_archive = "packagesite";
filesite_archive = "filesite";

So looks like the meta has changed and the old pkg, which is installed 
on the system, doesn't like it.


How am I supposed to upgrade the pkg and/or database to the new version?


___
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: Starting with poudriere

[Grzegorz Junka]

On 16/02/2020 00:14, Dan McGrath wrote:

Hi,

Just a bit of a heads up that poudriere will require you to be on the new
version of FreeBSD before you can build for it on the current system. For
example, if you are running 12.1, and you upgrade poudriere's jail to 13.0,
it will complain that you have to be running that version on the host you
are using it on. Ideally, poudriere should be running on it's own dedicated
system, not the one you intend to deploy to.


Just a note that this is not a strict requirement. I have been upgrading 
from FreeBSD 9 to 12 currently and was always building on the same 
system that I am deploying to. Yes, poudriere will complain that the 
jail is newer than the base system, but that did not create any major 
practical problem for me yet.


I think only on one occasion I got a build error due to missing symbols. 
Then the solution for me was to upgrade the base system. This of course 
broke the applications that were installed for the older base, but 
thanks to the FreeBSD's separation of base from ports, it's still 
possible to start FreeBSD with just the command line. Then I finished 
building the ports and reinstalled them.


Not that I encourage this approach, it might create additional issues to 
solve, but it is possible/manageable and shouldn't be held against using 
poudriere.


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"

Speeding-up poudriere options

[Grzegorz Junka]

I have a file with a list of packages to compile with poudriere. Every 
time I update ports I execute "poudriere options -j ... -f some_file" in 
order to update options of new packages or whenever something changed.


The issue is that it takes about an hour for poudriere to go through the 
list and try to configure options for each package. If the package was 
renamed or removed poudriere throws an error and stops. Then I need to 
update the list and restart the command.


Is there any better way of updating options than "poudriere options..."?

Can I speed it up by having the ports tree in ram (tmpfs)? If yes, what 
would be the easiest way for setting that up?


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: Possible issues with FreeBSD ports ML?

[Grzegorz Junka]

On 02/08/2019 00:24, Kevin Oberman wrote:

Philip,

Thanks so much for your time. I don't know if anything was ever wrong or
almost everyone on mailing lists just took a couple of days off, but
traffic volume on the lists now looks completely normal and I received no
responses of lost posts to ports.

Thanks so much for taking the time to look at it and sorry for the noise.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683


On Thu, Aug 1, 2019 at 12:00 AM Philip Paeps  wrote:


On 2019-08-01 11:35:54 (+0530), Kevin Oberman wrote:

Over the past dy and a half there have been no posts on the ports
list. The last user-posted message was on July 29 at 23:30:51. There
was a message from portscout about 14 yours later, but nothing else.
This is based on the contents of the ML archive, not just what I have
been seeing. Others of the dozen FreeBSD lists I read have also been a
bit quiet with only a very small number of posts.
postmas...@freebsd.org is aware of what I have seen but have not been
able to confirm a problem.

If this message actually got to you and you have sent a message to
ports or some other list after 16:00 UTC on July 30, please DO NOT
reply to the list, but send me a note with the ML to which the post
was sent and the time the post was sent (or your best guess) and/or
postmas...@freebsd.org.  Mail log entries would be especially useful.

Perhaps nothing is wrong, but to go two days with only about a dozen
messages from several normally active lists like ports, current,
stable, and x11.

As I may be wrong and everyone who normally would post have all taken
summer vacation at the same time. If so, I do apologize for wasting
your time.

As far as postmaster can tell, mail is flowing normally.

If your messages to FreeBSD mailing lists are bouncing or being delayed,
please try to reach out to postmas...@freebsd.org so we can investigate.
   Given the volume of mail that goes through FreeBSD.org, debugging
problems is difficult without at least some details about specific
messages or hosts to grep for.

Philip [hat: postmaster]

--
Philip Paeps
Senior Reality Engineer
Alternative Enterprises
___
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"



I was once told that in the beginning of each month there is a huge 
queue of monthly emails to be sent out and the mailserv is overloaded. 
If it's around that time then don't panic, wait 2-3 days and only worry 
if the issue persists after that.


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: Cleaning up pkg-message

[Grzegorz Junka]

On 09/06/2019 16:55, Adam Weinberger wrote:

On Sun, Jun 9, 2019 at 9:33 AM Grzegorz Junka  wrote:


On 09/06/2019 15:44, Miroslav Lachman wrote:

Grzegorz Junka wrote on 2019/06/09 16:12:

On 08/06/2019 19:11, Adam Weinberger wrote:

Hello everyone,

I want to get some stakeholder input on our pkg-message files. I think
we need to have a clear policy about what does and doesn't belong in
them, and I'd like to get your input.

pkg-message is shown to every user on every install. UPDATING is only
shown when users run `pkg updating` *and* /usr/ports/UPDATING exists.
I suspect that only a small proportion of users do that.

pkg-message needs to contain only highly relevant information. Many,
many ports have messages with irrelevant information that users are
likely to get message fatigue and ignore them entirely. I don't want
to pick on Joe Barbish, because his work is absolutely fantastic, but
dns/dns2blackhole/pkg-message is an example of a giant message that
tells users to do the same thing they always do for any port:



dns2blackhole

 Malware Prevention through Domain Blocking (Black Hole)

 Issue "man dns2blackhole"  For configuration and usage information




We now have the ability to specify messages that appear on initial
install, or on upgrades from/to specific version. So here is what I
propose as policy:

pkg-message must contain only information that is vital to setup and
operation, and that is unique to the port in question. Setup
information should only be shown on initial install, and upgrade
instructions should be shown only when upgrading to the relevant
version. All committers have blanket approval to constrain existing
messages to install/upgrade ranges using the UCL format
specifications. Message pruning falls under the blanket approval as
well, but committers are encouraged to get maintainer input
beforehand.
<<<

What are your thoughts?

# Adam


I don't like the approach of separating install from update messages.
It only works in the ideal scenario, which is almost never. Two reasons:

1. Very rarely I have time to configure all package requirements when
installing a bunch of packages. I usually configure a few most
important ones and leave the rest for later. Then I need to remember
to re-read whatever requirements they might have had.

2. Very rarely just adding packages to the system works. From adding
flavours, to removing KDE4, to renaming packages, etc. There is
always something going on and almost every time I try to upgrade all
packages in the system because of various problems I end up
reinstalling all of them anyway (pkg upgrade -f).

In either case update messages don't matter. In my opinion there
should be just one short message shown when either upgrading or
installing. If there are any specific instructions applicable when
only installing or upgrading then it's safer to show in both cases
with info in what condition they are applicable.

When installing packages with many dependencies a typical user isn't
even aware which packages have been added / installed and which have
been updated. Why make the life more complicated than it needs to be?

I disagree. The more the general messages the more noise to users. If
something is useful only on the first install why should user read it
on each pkg upgrade for many years in a lifetime of a machine? Then
some useful info on upgrade will be missed between many useless messages.
I remember change in PHP extensions which caused printing of useless
notice on every pkg upgrade of every PHP extension. Average webserver
has 10 - 20 of them (or more). This was so annoying that I patched our
ports/Mk to not print those messages.
If new UCL pkg-message format allows us to print only useful
information in specific event I am glad it is finally here!
The current state of pkg-message is very bad. Info in it is something
I totally ignore on each upgrade because it contains useless
informations which are printed to me on all machines on each pkg
upgrade once or twice a month... Why if the info is useful only for
the first install.


Because pkg doesn't know if it's a first install or reinstall. My
opinion is that they should be short and scarce so that even if all of
them are printed it's not a burden to read them. With the PHP example it
doesn't seem like a problem with update vs first install but inadequate
message being put there in the first place. The first problem is with
too many useless messages, the secondary problem is when they are printed.

We are in complete agreement on the first point (they should be
specific and relevant). On the second point, I definitely hear you
that pkgs IRL aren't always simply "new install and then upgrade
forever." However, I feel like we have a great opportunity here: When
only the bare minimum an

Re: Cleaning up pkg-message

[Grzegorz Junka]

On 09/06/2019 15:44, Miroslav Lachman wrote:

Grzegorz Junka wrote on 2019/06/09 16:12:


On 08/06/2019 19:11, Adam Weinberger wrote:

Hello everyone,

I want to get some stakeholder input on our pkg-message files. I think
we need to have a clear policy about what does and doesn't belong in
them, and I'd like to get your input.

pkg-message is shown to every user on every install. UPDATING is only
shown when users run `pkg updating` *and* /usr/ports/UPDATING exists.
I suspect that only a small proportion of users do that.

pkg-message needs to contain only highly relevant information. Many,
many ports have messages with irrelevant information that users are
likely to get message fatigue and ignore them entirely. I don't want
to pick on Joe Barbish, because his work is absolutely fantastic, but
dns/dns2blackhole/pkg-message is an example of a giant message that
tells users to do the same thing they always do for any port:
 



   dns2blackhole

    Malware Prevention through Domain Blocking (Black Hole)

    Issue "man dns2blackhole"  For configuration and usage information

 



We now have the ability to specify messages that appear on initial
install, or on upgrades from/to specific version. So here is what I
propose as policy:

pkg-message must contain only information that is vital to setup and
operation, and that is unique to the port in question. Setup
information should only be shown on initial install, and upgrade
instructions should be shown only when upgrading to the relevant
version. All committers have blanket approval to constrain existing
messages to install/upgrade ranges using the UCL format
specifications. Message pruning falls under the blanket approval as
well, but committers are encouraged to get maintainer input
beforehand.
<<<

What are your thoughts?

# Adam



I don't like the approach of separating install from update messages. 
It only works in the ideal scenario, which is almost never. Two reasons:


1. Very rarely I have time to configure all package requirements when 
installing a bunch of packages. I usually configure a few most 
important ones and leave the rest for later. Then I need to remember 
to re-read whatever requirements they might have had.


2. Very rarely just adding packages to the system works. From adding 
flavours, to removing KDE4, to renaming packages, etc. There is 
always something going on and almost every time I try to upgrade all 
packages in the system because of various problems I end up 
reinstalling all of them anyway (pkg upgrade -f).


In either case update messages don't matter. In my opinion there 
should be just one short message shown when either upgrading or 
installing. If there are any specific instructions applicable when 
only installing or upgrading then it's safer to show in both cases 
with info in what condition they are applicable.


When installing packages with many dependencies a typical user isn't 
even aware which packages have been added / installed and which have 
been updated. Why make the life more complicated than it needs to be?


I disagree. The more the general messages the more noise to users. If 
something is useful only on the first install why should user read it 
on each pkg upgrade for many years in a lifetime of a machine? Then 
some useful info on upgrade will be missed between many useless messages.
I remember change in PHP extensions which caused printing of useless 
notice on every pkg upgrade of every PHP extension. Average webserver 
has 10 - 20 of them (or more). This was so annoying that I patched our 
ports/Mk to not print those messages.
If new UCL pkg-message format allows us to print only useful 
information in specific event I am glad it is finally here!
The current state of pkg-message is very bad. Info in it is something 
I totally ignore on each upgrade because it contains useless 
informations which are printed to me on all machines on each pkg 
upgrade once or twice a month... Why if the info is useful only for 
the first install.




Because pkg doesn't know if it's a first install or reinstall. My 
opinion is that they should be short and scarce so that even if all of 
them are printed it's not a burden to read them. With the PHP example it 
doesn't seem like a problem with update vs first install but inadequate 
message being put there in the first place. The first problem is with 
too many useless messages, the secondary problem is when they are printed.


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: Cleaning up pkg-message

[Grzegorz Junka]

On 08/06/2019 19:11, Adam Weinberger wrote:

Hello everyone,

I want to get some stakeholder input on our pkg-message files. I think
we need to have a clear policy about what does and doesn't belong in
them, and I'd like to get your input.

pkg-message is shown to every user on every install. UPDATING is only
shown when users run `pkg updating` *and* /usr/ports/UPDATING exists.
I suspect that only a small proportion of users do that.

pkg-message needs to contain only highly relevant information. Many,
many ports have messages with irrelevant information that users are
likely to get message fatigue and ignore them entirely. I don't want
to pick on Joe Barbish, because his work is absolutely fantastic, but
dns/dns2blackhole/pkg-message is an example of a giant message that
tells users to do the same thing they always do for any port:


   dns2blackhole

Malware Prevention through Domain Blocking (Black Hole)

Issue "man dns2blackhole"  For configuration and usage information



We now have the ability to specify messages that appear on initial
install, or on upgrades from/to specific version. So here is what I
propose as policy:

pkg-message must contain only information that is vital to setup and
operation, and that is unique to the port in question. Setup
information should only be shown on initial install, and upgrade
instructions should be shown only when upgrading to the relevant
version. All committers have blanket approval to constrain existing
messages to install/upgrade ranges using the UCL format
specifications. Message pruning falls under the blanket approval as
well, but committers are encouraged to get maintainer input
beforehand.
<<<

What are your thoughts?

# Adam



I don't like the approach of separating install from update messages. It 
only works in the ideal scenario, which is almost never. Two reasons:


1. Very rarely I have time to configure all package requirements when 
installing a bunch of packages. I usually configure a few most important 
ones and leave the rest for later. Then I need to remember to re-read 
whatever requirements they might have had.


2. Very rarely just adding packages to the system works. From adding 
flavours, to removing KDE4, to renaming packages, etc. There is always 
something going on and almost every time I try to upgrade all packages 
in the system because of various problems I end up reinstalling all of 
them anyway (pkg upgrade -f).


In either case update messages don't matter. In my opinion there should 
be just one short message shown when either upgrading or installing. If 
there are any specific instructions applicable when only installing or 
upgrading then it's safer to show in both cases with info in what 
condition they are applicable.


When installing packages with many dependencies a typical user isn't 
even aware which packages have been added / installed and which have 
been updated. Why make the life more complicated than it needs to be?


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: games/dMagnetic: A new Port (Need help)

[Grzegorz Junka]

On 20/05/2019 07:14, dettus wrote:

Hello.

SInce the ports@ mailinglist seems to strip away attachments (as it 
should), I uploaded the port to my website.
Please download it at 
http://www.dettus.net/dMagnetic/freebsd_games_dMagnetic.tar.gz
sha256: 
df886bd85e30dc983ae7ab8d441db779355c63fe14c2117797c9889f23a9a00a, 
size=987 bytes.



Thomas Dettbarn

On 5/20/19 4:17 AM, dettus wrote:

Hello.


My name is Thomas Dettbarn. Two of my projects editors/dhex and 
games/nInvaders have already found their way into the FreeBSD ports.
Currently, I am working on dMagnetic, A Magic Scrolls Interpreter. 
This one lets you play classic text adventures such as "The Pawn" or
"The Guild of Thieves" in a terminal. (As well as "Fish!", "Myth", 
"Corruption", "Jinxter" and "Wonderland")


You can see some of the BEAUTIFUL screenshots on my website: 
http://www.dettus.net/dMagnetic. Please have a look.




For this, I created the inkling of an already working FreeBSD port. 
You should find it attached to this email.


Since I primarily see myself as a "developer", rather than a 
"maintainer", I would like to hand this one of to someone more 
experienced.
Plus, I had some issues when I tried adding extra files such as the 
README.txt or an .ini file to the do-install target.



so, please please help me out here guys! It would be an honor.


Thomas Dettbarn




Hi Thomas,

Is the intention of your email to find someone willing to add the games 
to ports? If yes, could mich, the current maintainer of your game (CC'd) 
be a good first contact?


Also, not sure how much traffic is on freebsd-ga...@freebsd.org but that 
might be another option when trying to find a maintainer.


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: Policy on closing bugs

[Grzegorz Junka]

On 24/05/2019 12:26, Kubilay Kocak wrote:

On 24/05/2019 9:30 pm, Grzegorz Junka wrote:


On 24/05/2019 11:12, Kubilay Kocak wrote:

On 24/05/2019 8:07 pm, Grzegorz Junka wrote:

Hey,

Is there any policy/document when a bug can be closed? For example, 
is it OK to close a bug that is fixed upstream but not yet in ports?


Thanks
GrzegorzJ



Hi Grzegorz,

Bugs are closed after they are "resolved". Resolved means a 
resolution has "occurred", but more precisely, the "thing reported" 
has been resolved. Resolved doesn't necessary mean "fixed" (see below)


What resolution is appropriate/set depends on the context of the 
issue, usually the specific nature of the request/proposal. Is there 
a specific bug you're referring to? I can speak to that case 
specifically if so.


For example however, if the bug was a "bug report for the 
port/package", fixed upstream hasn't fixed the port, so not usually, 
no, that wouldn't be considered sufficient to be "resolved" and closed.


Usually commits upstream are backported to the ports, and they are 
closed when those are committed.


There can't be policies for this perse, as its completely 
context/request dependent.


Resolutions can take place either by way of:

1) A change is made: a commit, usually, but could be a wiki update, 
or a DNS update for infrastructure changes, etc.
2) One of the 'non-change' resolutions: not accepted, unable to 
reproduce, feedback timeout, etc


Nothing about the above is special or different than most other 
issue trackers (generally speaking).


Regarding states, we have New, Open, In Progress, Closed

New: Not touched/Untriaged
Open: Initially Triaged (classified)
In Progress: Has a real (person) Assignee, action has started
Closed: Change(s) Made, OR "Non-Change" resolution set.

There's nothing special/different about these either, except that we 
like to have a real person assigned before in progress, and before 
close.


Happy to answer any more questions regarding issue tracking, etc 
anytime




Hi Kubilay,

Thank you for a detailed response. Yes, this is related to a 
particular defect. I didn't mention it because I didn't want to be 
picky and seen as causing troubles :) Also wasn't sure what's OK and 
what's not. Here is the defect:


My pleasure. I understand the desire not to want "cause trouble", but 
it's also important that everyone feel comfortable asking questions, 
and understand/clarify how things works (or should work, ideally). We 
need to see more of it, not less.



https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238086

I appreciate Yuri's contributions to the community and my intention 
isn't to bring this up for judgment. Even though as a FreeBSD user I 
might feel a bit ignored and shuffled under the carpet after the 
defect has been closed, my intention was more to find out if maybe a 
new state "Postponed" could be added for a defect in a state like 
this one?


GrzegorzJ


So there's a few issues involved, that are worth making very distinct:

- A FreeBSD port/package and its users are affected
- Upstream has apparently fixed the issue, but there's not much detail 
about how, where, when, etc

- The bugs resolution type

We'll run through those individually so its hopefully more clear how 
they might interact/overlap with each other:


1) If a port/package is broken in some way, we want to fix it, and as 
maintainers, we have signed up to do that. This is not controversial.


For users, its not always (I would argue in most cases), possible or 
easy for them to distinguish between a port problem, and a software 
problem, and who (freebsd or upstream) should be primarily responsible 
to a) get the initial bug report b) fix it in the first instance. I 
personally don't believe users should be expected to know or do this, 
but its great if/when they can.


There are arguments on both sides of the (unfortunate) 
upstream/downstream divide, about users reporting bugs to the "wrong 
place".


Sometimes downstreams hack software to make it work or do things 
differently in their distribution/OS, and sometimes these things 
break, and upstreams get the report.


Sometimes upstreams break things, and downstreams get the reports.

It's a difficult problem to solve completely and permanently, so 
ultimately it's the relationship between downstreams/upstreams that is 
the most important thing to cultivate.


Having said that, at least in the former case, I don't think its too 
much of a burden for us to receive reports and close them (where 
appropriate) as "wont fix / not accepted" after commenting that the 
report should go upstream.


The question as to what and when is appropriate is very case 
dependent, but the minimum (in my opinion) is that it should be 
explicitly clear to the reporter and documented what the complete 
rationale, analysis is to resolving in that manner.


2) If an upstream ha

Re: Policy on closing bugs

[Grzegorz Junka]

On 24/05/2019 12:48, Kubilay Kocak wrote:

On 24/05/2019 10:45 pm, Grzegorz Junka wrote:


On 24/05/2019 12:34, Kubilay Kocak wrote:

On 24/05/2019 9:52 pm, Grzegorz Junka wrote:


On 24/05/2019 11:30, Grzegorz Junka wrote:


On 24/05/2019 11:12, Kubilay Kocak wrote:

On 24/05/2019 8:07 pm, Grzegorz Junka wrote:

Hey,

Is there any policy/document when a bug can be closed? For 
example, is it OK to close a bug that is fixed upstream but not 
yet in ports?


Thanks
GrzegorzJ



Hi Grzegorz,

Bugs are closed after they are "resolved". Resolved means a 
resolution has "occurred", but more precisely, the "thing 
reported" has been resolved. Resolved doesn't necessary mean 
"fixed" (see below)


What resolution is appropriate/set depends on the context of the 
issue, usually the specific nature of the request/proposal. Is 
there a specific bug you're referring to? I can speak to that 
case specifically if so.


For example however, if the bug was a "bug report for the 
port/package", fixed upstream hasn't fixed the port, so not 
usually, no, that wouldn't be considered sufficient to be 
"resolved" and closed.


Usually commits upstream are backported to the ports, and they 
are closed when those are committed.


There can't be policies for this perse, as its completely 
context/request dependent.


Resolutions can take place either by way of:

1) A change is made: a commit, usually, but could be a wiki 
update, or a DNS update for infrastructure changes, etc.
2) One of the 'non-change' resolutions: not accepted, unable to 
reproduce, feedback timeout, etc


Nothing about the above is special or different than most other 
issue trackers (generally speaking).


Regarding states, we have New, Open, In Progress, Closed

New: Not touched/Untriaged
Open: Initially Triaged (classified)
In Progress: Has a real (person) Assignee, action has started
Closed: Change(s) Made, OR "Non-Change" resolution set.

There's nothing special/different about these either, except that 
we like to have a real person assigned before in progress, and 
before close.


Happy to answer any more questions regarding issue tracking, etc 
anytime




Hi Kubilay,

Thank you for a detailed response. Yes, this is related to a 
particular defect. I didn't mention it because I didn't want to be 
picky and seen as causing troubles :) Also wasn't sure what's OK 
and what's not. Here is the defect:


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238086

I appreciate Yuri's contributions to the community and my 
intention isn't to bring this up for judgment. Even though as a 
FreeBSD user I might feel a bit ignored and shuffled under the 
carpet after the defect has been closed, my intention was more to 
find out if maybe a new state "Postponed" could be added for a 
defect in a state like this one?




A very similar story with:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238088

It's not scheduled to be removed per se yet. The removal is under 
discussion with no clear path agreed as far as I know. I understand 
that a maintainer doesn't want to spend time working on a port that 
will likely undergo significant changes or removal but is closing 
the defect the right thing to do? And again, a "Postponed" state 
seems to me to be more appropriate?


GrzegorzJ




The better resolution for this is again probably: Not Accepted (as 
WONTFIX), though I can understand why "Overcome by Events" was 
selected (wont be fixed *because* of a separate overruling issue).


From a reading of the associated bug (215036), it reads fairly 
clearly that the 0.x branch is not supported (security wise, in 
particular), and no further work will be done on it. That the port 
has been deprecated (DEPRECATED/EXPIRY_DATE) is evidence of that 
decision.




Agreed in principle, but the port hasn't yet been marked as 
DEPRECATED/EXPIRATION_DATE. Unless it was done in the last few days 
(I synced my ports 18 May).



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


Indeed it has: https://svnweb.freebsd.org/changeset/ports/502453

The same day, 6 minutes after your comment about it not having an 
EXPIRATION_DATE :)




All right, I did see the commit but I thought the commit message is the 
actual change. I should have tried to dig deeper. Sorry about that. I 
guess this one is sorted then :)



___
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: Policy on closing bugs

[Grzegorz Junka]

On 24/05/2019 12:34, Kubilay Kocak wrote:

On 24/05/2019 9:52 pm, Grzegorz Junka wrote:


On 24/05/2019 11:30, Grzegorz Junka wrote:


On 24/05/2019 11:12, Kubilay Kocak wrote:

On 24/05/2019 8:07 pm, Grzegorz Junka wrote:

Hey,

Is there any policy/document when a bug can be closed? For 
example, is it OK to close a bug that is fixed upstream but not 
yet in ports?


Thanks
GrzegorzJ



Hi Grzegorz,

Bugs are closed after they are "resolved". Resolved means a 
resolution has "occurred", but more precisely, the "thing reported" 
has been resolved. Resolved doesn't necessary mean "fixed" (see below)


What resolution is appropriate/set depends on the context of the 
issue, usually the specific nature of the request/proposal. Is 
there a specific bug you're referring to? I can speak to that case 
specifically if so.


For example however, if the bug was a "bug report for the 
port/package", fixed upstream hasn't fixed the port, so not 
usually, no, that wouldn't be considered sufficient to be 
"resolved" and closed.


Usually commits upstream are backported to the ports, and they are 
closed when those are committed.


There can't be policies for this perse, as its completely 
context/request dependent.


Resolutions can take place either by way of:

1) A change is made: a commit, usually, but could be a wiki update, 
or a DNS update for infrastructure changes, etc.
2) One of the 'non-change' resolutions: not accepted, unable to 
reproduce, feedback timeout, etc


Nothing about the above is special or different than most other 
issue trackers (generally speaking).


Regarding states, we have New, Open, In Progress, Closed

New: Not touched/Untriaged
Open: Initially Triaged (classified)
In Progress: Has a real (person) Assignee, action has started
Closed: Change(s) Made, OR "Non-Change" resolution set.

There's nothing special/different about these either, except that 
we like to have a real person assigned before in progress, and 
before close.


Happy to answer any more questions regarding issue tracking, etc 
anytime




Hi Kubilay,

Thank you for a detailed response. Yes, this is related to a 
particular defect. I didn't mention it because I didn't want to be 
picky and seen as causing troubles :) Also wasn't sure what's OK and 
what's not. Here is the defect:


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238086

I appreciate Yuri's contributions to the community and my intention 
isn't to bring this up for judgment. Even though as a FreeBSD user I 
might feel a bit ignored and shuffled under the carpet after the 
defect has been closed, my intention was more to find out if maybe a 
new state "Postponed" could be added for a defect in a state like 
this one?




A very similar story with:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238088

It's not scheduled to be removed per se yet. The removal is under 
discussion with no clear path agreed as far as I know. I understand 
that a maintainer doesn't want to spend time working on a port that 
will likely undergo significant changes or removal but is closing the 
defect the right thing to do? And again, a "Postponed" state seems to 
me to be more appropriate?


GrzegorzJ




The better resolution for this is again probably: Not Accepted (as 
WONTFIX), though I can understand why "Overcome by Events" was 
selected (wont be fixed *because* of a separate overruling issue).


From a reading of the associated bug (215036), it reads fairly clearly 
that the 0.x branch is not supported (security wise, in particular), 
and no further work will be done on it. That the port has been 
deprecated (DEPRECATED/EXPIRY_DATE) is evidence of that decision.




Agreed in principle, but the port hasn't yet been marked as 
DEPRECATED/EXPIRATION_DATE. Unless it was done in the last few days (I 
synced my ports 18 May).



___
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: Policy on closing bugs

[Grzegorz Junka]

On 24/05/2019 11:30, Grzegorz Junka wrote:


On 24/05/2019 11:12, Kubilay Kocak wrote:

On 24/05/2019 8:07 pm, Grzegorz Junka wrote:

Hey,

Is there any policy/document when a bug can be closed? For example, 
is it OK to close a bug that is fixed upstream but not yet in ports?


Thanks
GrzegorzJ



Hi Grzegorz,

Bugs are closed after they are "resolved". Resolved means a 
resolution has "occurred", but more precisely, the "thing reported" 
has been resolved. Resolved doesn't necessary mean "fixed" (see below)


What resolution is appropriate/set depends on the context of the 
issue, usually the specific nature of the request/proposal. Is there 
a specific bug you're referring to? I can speak to that case 
specifically if so.


For example however, if the bug was a "bug report for the 
port/package", fixed upstream hasn't fixed the port, so not usually, 
no, that wouldn't be considered sufficient to be "resolved" and closed.


Usually commits upstream are backported to the ports, and they are 
closed when those are committed.


There can't be policies for this perse, as its completely 
context/request dependent.


Resolutions can take place either by way of:

1) A change is made: a commit, usually, but could be a wiki update, 
or a DNS update for infrastructure changes, etc.
2) One of the 'non-change' resolutions: not accepted, unable to 
reproduce, feedback timeout, etc


Nothing about the above is special or different than most other issue 
trackers (generally speaking).


Regarding states, we have New, Open, In Progress, Closed

New: Not touched/Untriaged
Open: Initially Triaged (classified)
In Progress: Has a real (person) Assignee, action has started
Closed: Change(s) Made, OR "Non-Change" resolution set.

There's nothing special/different about these either, except that we 
like to have a real person assigned before in progress, and before 
close.


Happy to answer any more questions regarding issue tracking, etc anytime



Hi Kubilay,

Thank you for a detailed response. Yes, this is related to a 
particular defect. I didn't mention it because I didn't want to be 
picky and seen as causing troubles :) Also wasn't sure what's OK and 
what's not. Here is the defect:


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238086

I appreciate Yuri's contributions to the community and my intention 
isn't to bring this up for judgment. Even though as a FreeBSD user I 
might feel a bit ignored and shuffled under the carpet after the 
defect has been closed, my intention was more to find out if maybe a 
new state "Postponed" could be added for a defect in a state like this 
one?




A very similar story with:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238088

It's not scheduled to be removed per se yet. The removal is under 
discussion with no clear path agreed as far as I know. I understand that 
a maintainer doesn't want to spend time working on a port that will 
likely undergo significant changes or removal but is closing the defect 
the right thing to do? And again, a "Postponed" state seems to me to be 
more appropriate?


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: Policy on closing bugs

[Grzegorz Junka]

On 24/05/2019 11:12, Kubilay Kocak wrote:

On 24/05/2019 8:07 pm, Grzegorz Junka wrote:

Hey,

Is there any policy/document when a bug can be closed? For example, 
is it OK to close a bug that is fixed upstream but not yet in ports?


Thanks
GrzegorzJ



Hi Grzegorz,

Bugs are closed after they are "resolved". Resolved means a resolution 
has "occurred", but more precisely, the "thing reported" has been 
resolved. Resolved doesn't necessary mean "fixed" (see below)


What resolution is appropriate/set depends on the context of the 
issue, usually the specific nature of the request/proposal. Is there a 
specific bug you're referring to? I can speak to that case 
specifically if so.


For example however, if the bug was a "bug report for the 
port/package", fixed upstream hasn't fixed the port, so not usually, 
no, that wouldn't be considered sufficient to be "resolved" and closed.


Usually commits upstream are backported to the ports, and they are 
closed when those are committed.


There can't be policies for this perse, as its completely 
context/request dependent.


Resolutions can take place either by way of:

1) A change is made: a commit, usually, but could be a wiki update, or 
a DNS update for infrastructure changes, etc.
2) One of the 'non-change' resolutions: not accepted, unable to 
reproduce, feedback timeout, etc


Nothing about the above is special or different than most other issue 
trackers (generally speaking).


Regarding states, we have New, Open, In Progress, Closed

New: Not touched/Untriaged
Open: Initially Triaged (classified)
In Progress: Has a real (person) Assignee, action has started
Closed: Change(s) Made, OR "Non-Change" resolution set.

There's nothing special/different about these either, except that we 
like to have a real person assigned before in progress, and before close.


Happy to answer any more questions regarding issue tracking, etc anytime



Hi Kubilay,

Thank you for a detailed response. Yes, this is related to a particular 
defect. I didn't mention it because I didn't want to be picky and seen 
as causing troubles :) Also wasn't sure what's OK and what's not. Here 
is the defect:


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238086

I appreciate Yuri's contributions to the community and my intention 
isn't to bring this up for judgment. Even though as a FreeBSD user I 
might feel a bit ignored and shuffled under the carpet after the defect 
has been closed, my intention was more to find out if maybe a new state 
"Postponed" could be added for a defect in a state like this one?


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: Policy on closing bugs

[Grzegorz Junka]

On 24/05/2019 10:53, Jan Bramkamp wrote:

On 24.05.19 12:07, Grzegorz Junka wrote:

Hey,

Is there any policy/document when a bug can be closed? For example, 
is it OK to close a bug that is fixed upstream but not yet in ports?


Thanks
GrzegorzJ

I don't know of any official policy, but as a user (and port 
maintainer) I would prefer an update to the FreeBSD PR stating that 
the bug has been fixed upstream. Closing the PR should wait until the 
fix made it into the port.




As a port maintainer and user would you like to see an official 
guideline/policy about defect states and when to transition between them?


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

Policy on closing bugs

[Grzegorz Junka]

Hey,

Is there any policy/document when a bug can be closed? For example, is 
it OK to close a bug that is fixed upstream but not yet in ports?


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"

pkg query hackaton

[Grzegorz Junka]

Hi,

I am interested in two pkg query solutions and I thought I will ask here 
first, maybe someone already spend time or knows a better approach.


1. List of packages sorted by the amount of packages that depend on them

2. List of all recursive dependencies of a particular package


Ad1. Basically, it would be a list of all packages installed in the 
system where for each package the query would retrieve the amount of 
dependent packages. Then sort that list.


Bonus. Can 1. be also recursively, e.g. sum amounts of all dependent 
packages, then for each dependent package add that package's dependent 
packages, etc. This will likely cause loops so probably a state with 
packages already added would need to be maintained.


Ad2. Given package A list all its direct dependencies, then for each 
dependency list its dependencies, and so on. Add them to a big list then 
sort and unique. Can that be done in pkg query alone?



Out of interest, is "pkg install -R" truly recursive, i.e. would it 
reinstall any packages that require the given package indirectly 
(through another package, not through a direct dependency)?


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: Reinstalling with dependencies

[Grzegorz Junka]

On 22/05/2019 13:48, Grzegorz Junka wrote:


On 22/05/2019 13:42, Miroslav Lachman wrote:

Grzegorz Junka wrote on 2019/05/22 14:11:

[...]

Are you saying that even if elinks was reinstalled with dependencies 
that wouldn't help?


We have two issues here:

1. How to reinstall a package with dependencies (as stated in the 
subject)


You can try something like this

pkg install -f `pkg info -d elinks | tr -d :`


pkg info -d will list direct dependencies of the port and then this 
list is given to command pkg install -f.




That's a good idea. Thank you. I may probably want to strip versions 
too, to allow upgrading to more recent versions. But I can take it 
from there.




However, I just realized that it may not be enough, i.e. pkg info -d 
lists only direct dependencies, so this would allow me to reinstall all 
direct dependencies but not recursively.


Adding a loop in bash or something is another solution but it starts to 
become clunky.



___
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: Reinstalling with dependencies

[Grzegorz Junka]

On 22/05/2019 13:42, Miroslav Lachman wrote:

Grzegorz Junka wrote on 2019/05/22 14:11:

[...]

Are you saying that even if elinks was reinstalled with dependencies 
that wouldn't help?


We have two issues here:

1. How to reinstall a package with dependencies (as stated in the 
subject)


You can try something like this

pkg install -f `pkg info -d elinks | tr -d :`


pkg info -d will list direct dependencies of the port and then this 
list is given to command pkg install -f.




That's a good idea. Thank you. I may probably want to strip versions 
too, to allow upgrading to more recent versions. But I can take it from 
there.


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: pkg upgrade -f dying on me

[Grzegorz Junka]

On 22/05/2019 13:30, Mark Martinec wrote:

2019-05-22 13:46, je Grzegorz Junka wrote:

root@someserv:~ # pkg --version
1.10.5
root@someserv:~ # /usr/local/sbin/pkg-static upgrade -f
Updating desktop_nvidia repository catalogue...
desktop_nvidia repository is up to date.
All repositories are up to date.
Checking for upgrades (1637 candidates):  46%
libwps03 has no direct installation candidates, change it to libwps? 
[Y/n]:

Checking for upgrades (1637 candidates):  81%
gmime26 has no direct installation candidates, change it to gmime30? 
[Y/n]:

Checking for upgrades (1637 candidates):  82%
glib12 has no direct installation candidates, change it to glib? [Y/n]:
Checking for upgrades (1637 candidates): 100%
Processing candidates (1637 candidates): 100%
Child process pid=4192 terminated abnormally: Segmentation fault


This has been my experience (mostly) ever since pkg-ng was introduced.
When answering Y to such questions, it is very likely it will crash.

My 'solution' is not to accept any of the offered changes, but
just to delete the defunct packages, do the pkg upgrade, then
install whatever is still needed.



Great, thank you Mark. That worked!

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: Reinstalling with dependencies

[Grzegorz Junka]

On 22/05/2019 13:17, Baptiste Daroussin wrote:

On Wed, May 22, 2019 at 01:11:05PM +0100, Grzegorz Junka wrote:

On 22/05/2019 12:51, Baptiste Daroussin wrote:

On Wed, May 22, 2019 at 12:43:33PM +0100, Grzegorz Junka wrote:

Is there any way to reinstall a package with all its dependencies?


I am getting the following error:

root@someserv:~ # pkg check -d
Checking all packages: 100%
elinks is missing a required shared library: libjs.so



2 reasons may happen for that to happen:
1/ spidermonkey17 does not have a proper SONAME for the libjs.so file it
provides (bug 1)
2/ somehow the linked port seems to not register properly spidermonkey17 as a
direct dependency of elinks when the option is checked (bug 2)

I have checked the case 1 and yes libjs.so is buggy I haven't yet checked the
case 2, but I quite sure there is a bug there as well, resulting in a package
that does not have the proper dependencies registered at the creation

Best regards,
Bapt


Are you saying that even if elinks was reinstalled with dependencies that
wouldn't help?

We have two issues here:

1. How to reinstall a package with dependencies (as stated in the subject)

2. Would reinstalling elinks with all dependencies fix the issue mentioned
in the email

I have a couple more packages broken like elinks. I didn't include them
because I only wanted to post an example and assumed they would be fixed if
I reinstalled them properly. But here we go:

No I do mean the elinks packages is probably broken when build with the option
that brings in spidermonkey as a dependency

root@someserv:~ # pkg check -d
Checking all packages: 100%
elinks is missing a required shared library: libjs.so
fireflies is missing a required shared library: libgfx.so
py27-exiv2 is missing a required shared library: libexiv2.so.26

There was also virtuoso but I deinstalled it assuming it's an old version
(the new version doesn't build due to openssl 1.1.0 issue).

So now I have two questions: Is it possible to reinstall a package with it's
dependencies? And what to do with those broken packages above, should I
report a bug?


I don't know for the specific case of the broken packages above, pkg check will
try to reinstall the missing dependency if any is found. If not, it just report
the broken packages and one has to figure out why those packages are broken.

I could easily guess for the elinks case. there might be similar reasons for
other packages.

For example reading at the MOVED file I can easily figure out that py27-exiv2 is
a package that no longer exists.

For fireflies I don't know, one has to check.



Thanks Bapt.  From what you wrote I infer that an option to reinstall a 
package with all dependencies doesn't exist, e.g.


pkg install -D pkg-name (Force reinstallation of package dependencies if 
already installed)


I will raise a bug for elinks when I am done with upgrading packages.


___
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: Reinstalling with dependencies

[Grzegorz Junka]

On 22/05/2019 12:51, Baptiste Daroussin wrote:

On Wed, May 22, 2019 at 12:43:33PM +0100, Grzegorz Junka wrote:

Is there any way to reinstall a package with all its dependencies?


I am getting the following error:

root@someserv:~ # pkg check -d
Checking all packages: 100%
elinks is missing a required shared library: libjs.so



2 reasons may happen for that to happen:
1/ spidermonkey17 does not have a proper SONAME for the libjs.so file it
provides (bug 1)
2/ somehow the linked port seems to not register properly spidermonkey17 as a
direct dependency of elinks when the option is checked (bug 2)

I have checked the case 1 and yes libjs.so is buggy I haven't yet checked the
case 2, but I quite sure there is a bug there as well, resulting in a package
that does not have the proper dependencies registered at the creation

Best regards,
Bapt



Are you saying that even if elinks was reinstalled with dependencies 
that wouldn't help?


We have two issues here:

1. How to reinstall a package with dependencies (as stated in the subject)

2. Would reinstalling elinks with all dependencies fix the issue 
mentioned in the email


I have a couple more packages broken like elinks. I didn't include them 
because I only wanted to post an example and assumed they would be fixed 
if I reinstalled them properly. But here we go:


root@someserv:~ # pkg check -d
Checking all packages: 100%
elinks is missing a required shared library: libjs.so
fireflies is missing a required shared library: libgfx.so
py27-exiv2 is missing a required shared library: libexiv2.so.26

There was also virtuoso but I deinstalled it assuming it's an old 
version (the new version doesn't build due to openssl 1.1.0 issue).


So now I have two questions: Is it possible to reinstall a package with 
it's dependencies? And what to do with those broken packages above, 
should I report a bug?


___
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 upgrade -f dying on me

[Grzegorz Junka]

On 22/05/2019 12:03, Kurt Jaeger wrote:

Hi!


How to debug this?:

root@someserv:~ # pkg upgrade -f

Which version of pkg ?

pkg --version

Try:

/usr/local/sbin/pkg-static upgrade -f



root@someserv:~ # pkg --version
1.10.5
root@someserv:~ # /usr/local/sbin/pkg-static upgrade -f
Updating desktop_nvidia repository catalogue...
desktop_nvidia repository is up to date.
All repositories are up to date.
Checking for upgrades (1637 candidates):  46%
libwps03 has no direct installation candidates, change it to libwps? [Y/n]:
Checking for upgrades (1637 candidates):  81%
gmime26 has no direct installation candidates, change it to gmime30? [Y/n]:
Checking for upgrades (1637 candidates):  82%
glib12 has no direct installation candidates, change it to glib? [Y/n]:
Checking for upgrades (1637 candidates): 100%
Processing candidates (1637 candidates): 100%
Child process pid=4192 terminated abnormally: Segmentation fault

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

Reinstalling with dependencies

[Grzegorz Junka]

Is there any way to reinstall a package with all its dependencies?


I am getting the following error:

root@someserv:~ # pkg check -d
Checking all packages: 100%
elinks is missing a required shared library: libjs.so


But reinstalling elinks doesn't help:


root@someserv:~ # pkg install -fR elinks
Updating desktop_nvidia repository catalogue...
desktop_nvidia 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 REINSTALLED:
    elinks-0.11.7_11

Number of packages to be reinstalled: 1

Proceed with this action? [y/N]: y
[1/1] Reinstalling elinks-0.11.7_11...
[1/1] Extracting elinks-0.11.7_11: 100%


After that same error is shown.

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

pkg upgrade -f dying on me

[Grzegorz Junka]

Hi,

How to debug this?:

root@someserv:~ # pkg upgrade -f
Updating desktop_nvidia repository catalogue...
desktop_nvidia repository is up to date.
All repositories are up to date.
Checking for upgrades (1638 candidates):  46%
libwps03 has no direct installation candidates, change it to libwps? [Y/n]:
Checking for upgrades (1638 candidates):  81%
gmime26 has no direct installation candidates, change it to gmime30? [Y/n]:
Checking for upgrades (1638 candidates):  82%
glib12 has no direct installation candidates, change it to glib? [Y/n]:
Checking for upgrades (1638 candidates): 100%
Processing candidates (1638 candidates): 100%
Child process pid=3850 terminated abnormally: Segmentation fault


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

UNAME_r and OSVERSION mismatch - annoying error

[Grzegorz Junka]

Hi,

poudriere options -c -j 12rel0 -p local -z desktop audio/sdl_sound

throws at me:

make: "/usr/local/poudriere/ports/gui/Mk/bsd.port.mk" line 1203: UNAME_r 
(12.0-RELEASE-p4) and OSVERSION (1102000) do not agree on major version 
number.


What's the easiest way for (temporarily) disabling this error so that I 
can set the options?



Yes, poudriere is compiling with 12.0-RELEASE-p4 jail on a host with 
12.0-RELEASE-p4 kernel but with 11.2-RELEASE-p4 userland. I am just in 
the middle of upgrading the ports and need to recompile one port with 
different options before I can finish upgrading the userland.


Also, is this error expected in that scenario? When I was trying to 
compile using 12 jail on a host with 11 kernel poudriere was only 
showing an error that build errors may occur but never refused to at 
least try to compile. This makefile doesn't even try to set my options. 
Pretty annoying.


I guess I would support merging this patch:

https://lists.freebsd.org/pipermail/freebsd-ports/2015-June/099621.html

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"

The status of docker

[Grzegorz Junka]

Hello, does anyone know the current status of docker on FreeBSD? Wiki 
https://wiki.freebsd.org/Docker states it's experimental. The last 
commit in https://github.com/kvasdopil/docker/tree/freebsd-compat is 
also from 2015.


There in fact are two ports, freebsd-docker (from 2015) and docker 
(18.06). What's the difference between them and which one should I use 
to run docker images on FreeBSD host?


Has this project been completed and now only needs testing, or has it 
been abandoned, or maybe the approach has changed and I am looking in a 
wrong place?


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: Distributed poudriere

[Grzegorz Junka]

On 30/11/2018 19:31, Pete Wright wrote:

On 11/30/18 9:08 AM, Grzegorz Junka wrote:

On 29/11/2018 19:12, Grzegorz Junka wrote:

Hello,

Is it possible to run poudriere in an agent/server setup? Where one 
central server maintains a distfiles folder for already compiled 
packages and agents compile packages fetching and installing from 
the central server dependencies?


Just to make it more clear, I am asking about the build process. 
Poudriere starts the specified amount of jails to build packages in 
parallel. In each jail it then install dependencies by fetching them 
from the distfiles folder. After the build is done a new package is 
created and uploaded to the distfiles folder to be used by builds 
that require it.


This process is CPU-core-bound, i.e. with 32/64 threads cores it 
can't really build more than 64 packages in parallel. And systems 
with so many cores are really expensive. But the whole process is 
inherently distributed (as long as the amount of packages is big 
enough so that they can be build in parallel).


Being able to build on multiple cheaper systems with less CPU cores 
per system over the network seems like a good idea, no?




haven't fully thought this idea through, but couldn't you achieve this 
by mounting the Poudriere 'data' directories as an NFS mountpoint?  
This way each jail would view currently available package metadata and 
hopefully avoid doing duplicate work?


I'm sure there will be racing condition edge cases though which will 
bite you since I don't think there is a build job dispatcher/scheduler 
available in Poudriere.  So for example you may find yourself in a 
situation where multiple jails try building LLVM as it's first package 
which wouldn't really be helpful.


I believe poudriere plans what needs to be build before it starts the 
build in order to detect circular dependencies. I don't think a shared 
NFS mountpoint would be of any use. There ought to be a single scheduler 
which deletes the outdated packages and plans what needs to be build, 
but then instead distributing the build across jails on the same system, 
it would have to be able to distribute the workload across multiple systems.


Thanks for confirming it's not available yet. Would be a nice and useful 
addition. I should start learning poudriere code perhaps to see if this 
is something I could do.


Regards

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: Distributed poudriere

[Grzegorz Junka]

On 29/11/2018 19:12, Grzegorz Junka wrote:

Hello,

Is it possible to run poudriere in an agent/server setup? Where one 
central server maintains a distfiles folder for already compiled 
packages and agents compile packages fetching and installing from the 
central server dependencies?


Just to make it more clear, I am asking about the build process. 
Poudriere starts the specified amount of jails to build packages in 
parallel. In each jail it then install dependencies by fetching them 
from the distfiles folder. After the build is done a new package is 
created and uploaded to the distfiles folder to be used by builds that 
require it.


This process is CPU-core-bound, i.e. with 32/64 threads cores it can't 
really build more than 64 packages in parallel. And systems with so many 
cores are really expensive. But the whole process is inherently 
distributed (as long as the amount of packages is big enough so that 
they can be build in parallel).


Being able to build on multiple cheaper systems with less CPU cores per 
system over the network seems like a good idea, no?


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"

Distributed poudriere

[Grzegorz Junka]

Hello,

Is it possible to run poudriere in an agent/server setup? Where one 
central server maintains a distfiles folder for already compiled 
packages and agents compile packages fetching and installing from the 
central server dependencies?


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: Few how-it-works questions

[Grzegorz Junka]

On 11/11/2018 14:27, Matthew Seaman wrote:

On 11/11/2018 12:34, Grzegorz Junka wrote:

Hi All,

I would like to understand a bit better how the ports infrastructure works.

1. Recommended way of upgrading ports is "poudriere ports -p local -u",
right? But this always gets me the latest version, in which some ports
may not compile, depending on my luck. I know I can use SVN to checkout
a specific version of ports instead, but is it possible to find out in
which SVN version which ports are compiling and which are not? In other
words, can I open the history of builds of FreeBSD ports on the build
servers and check which ports are building in a specific SVN version,
then checkout that version to build on my server?

Firstly ports rarely stay uncompilable for very long.  There are
exceptions mostly due to situations like the problems with openssl-1.1.1
support at the moment.  So there are some additional strategies to apply:


Matthew, thank you for your comprehensive response. Just to be clear, I 
wasn't complaining about the ports tree being broken from time to time. 
It's understandable as it's being constantly updated. I just got caught 
in between renaming ImageMagick to ImageMagick6 and updating some ports 
to use ImageMagick7. As a result some ports didn't built reporting 
strange build errors. But another update one day later and the strange 
errors are gone.


Since it's hardly an exception (flavours or renaming kde to kde4 are 
other examples), I take there must be periods when the ports tree is 
more stable in between those bigger updates and was trying to find a 
strategy to determine those stable periods as a base for updating my 
ports tree.


Waiting, changing versions or options are good suggestions but these are 
reactive approaches. I would prefer a more proactive approach, i.e. not 
have to spend time on building a broken tree and then trying to fix it 
myself (unless there is no other option) but rather update my port tree 
when I know it's stable, and so the idea of being able to check it out 
in between those bigger updates. I will check the URLs and poudriere 
options you suggested.


As a side note, is it known in advance and announced anywhere that those 
bigger, potentially breaking changes are being applied to the port so 
that someone can plan to update beforehand or wait until the storm is over?


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"

Few how-it-works questions

[Grzegorz Junka]

Hi All,

I would like to understand a bit better how the ports infrastructure works.

1. Recommended way of upgrading ports is "poudriere ports -p local -u", 
right? But this always gets me the latest version, in which some ports 
may not compile, depending on my luck. I know I can use SVN to checkout 
a specific version of ports instead, but is it possible to find out in 
which SVN version which ports are compiling and which are not? In other 
words, can I open the history of builds of FreeBSD ports on the build 
servers and check which ports are building in a specific SVN version, 
then checkout that version to build on my server?

 - also, is the ports tree mirrored in Git/GitHub?

2. Every time poudriere builds a new set of packages, it deletes those 
which have changed in ports or for which the options have changed, then 
it tries to build them again. But because the ports change, some may no 
longer build. In that case I am left with no packages to install on a 
system unless I am lucky enough to be able to cleanly build all ports 
again. What is the preferred strategy to maintain old packages until a 
new set is build correctly? Copy the whole folder aside? Is it possible 
to tell poudriere to create a new folder with packages for each new 
build (eventually with the option to use already built packages when 
they have not changed)? I suspect poudriere doesn't maintain such state 
internally, it simply deletes what's no longer relevant and then builds 
what's missing?


3. When a package doesn't build because of a patch error:

===>  Patching for ImageMagick6-6.9.10.14,1
===>  Applying FreeBSD patches for ImageMagick6-6.9.10.14,1
1 out of 1 hunks failed--saving rejects to config/policy.xml.rej
=> FreeBSD patch patch-config_policy.xml failed to apply cleanly.
*** Error code 1

Is this a problem with the ports tree, the upstream package, or some 
other package? In other words, can that problem be fixed without having 
an updated version of the port (e.g. assuming the upstream package or 
the other package gets updated and rebuilding the same package without a 
new version of the ports tree may fix this). Are patches always kept in 
the ports tree or sometimes they may be kept separately (e.g. in another 
repo versioned independently)?


Many thanks for your time

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: Conflicts due to renamed KDE4 ports

[Grzegorz Junka]

On 17/04/2018 09:11, Tijl Coosemans wrote:

On Tue, 17 Apr 2018 00:42:48 +0200 Adriaan de Groot  wrote:

[where did this discussion take place, earlier? this is the first I've seen it]

So, there are roughly two migration paths: supposing someone has x11/kde4
installed, which has dependencies on many applications and a Plasma 4 desktop,
kde@ wants (wanted) to make it possible to migrate to a still-KDE4 desktop,
while renaming everything to have a -kde4 suffix. The other path is to migrate
to the latest-and-greatest-from-KDE .. we don't have a metaport for that, and
if we do get one it probably won't be called x11/kde5.

For single applications, the migration looks similar: you had, around january
2018, port . That's the KDE4 version. Now there is port -kde4, if
you want to stick to KDE4 software (which is no longer released upstream, and
is based on an EOL toolkit, but some people feel quite strongly about this).
Ports  are returning, without a suffix, to mean "the latest-and-greatest-
version-of-". This is consistent with other ports which have a ,
sometimes a -devel for upcoming things, and a - for older
versions if you have specific dependencies on old versions.

Historically, things were a mess with naming with the KDE ports. We think
we've got a good scheme now: -kde4 (and in the far future, -kf5) for
versions of the software based on an older stack, and  for the current
one. But the pain of getting from the mess to something better organized has
to happen at some point.

What happens when you run pkg upgrade on a 6 months old installation of KDE4?


As stated earlier, I had a few kde4-specific applications installed on 
my system (kwrite, kate, konsole, ...). I am using poudriere and wasn't 
upgrading for like 6 months. I tried a few weeks ago and it failed. I 
was getting errors that a file, here listed a path to a file in a new 
package, is already installed by another package. Deleting the file was 
leading to another similar error. Manually uninstalling old packages and 
reinstalling with updated names of course solved the issue but I only 
had a few of those applications.

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: Conflicts due to renamed KDE4 ports

[Grzegorz Junka]

On 14/04/2018 12:18, Stefan Esser wrote:

[cut]

This is another case (after the implementation of FLAVOR support that does
not seem well-designed and causes lots of effort and inefficiencies in port
management tools like portmaster), which makes me consider giving up my
efforts to keep portmaster alive.

STefan


This caused some headache on my system too even though I use poudriere 
to build packages and I don't use the whole kde suite, just some 
applications. I had to manually uninstall all old kde ports and 
re-install them again adding the kde4 suffix. Are you saying I will need 
to do that again when I want to switch to kde5?


I haven't seen any consultation being posted on this forum if/when/how 
the introduction of kde5 should be handled. I imagine it's not the first 
time such a massive upgrade of version has had happened in FreeBSD 
ports. Is it how it's usually handled?


Also, wouldn't in this case converting kde to flavours, i.e. 
kde-base@kde4 and kde-base@kde5 be a better approach?


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: qt5tc and Lumina

[Grzegorz Junka]

On 30/03/2018 11:40, Le Baron d’Merde wrote:

Hi.

I do not use Lumina but

setenv  QT_QPA_PLATFORMTHEMEqt5ct

in my .tcshrc works for me everywhere I needed it.

I *guess* the problem is the way you are setting it.

Cheers!


On Fri, Mar 30, 2018 at 09:00:28AM +, Grzegorz Junka wrote:

Hi,

When opening qt5ct I am getting a popup QT_QPA_PLATFORMTHEME environment
variable is not set correctly

What should it be set to? I tried qt5ct, KDE and GNOME. The default is
lthemeengine. What it should be set to?



Many thanks for quick response. You are right. When I put the line to 
.tcshrc and then started qt5ct it opened fine.

Cheer
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"

qt5tc and Lumina

[Grzegorz Junka]

Hi,

When opening qt5ct I am getting a popup QT_QPA_PLATFORMTHEME environment 
variable is not set correctly


What should it be set to? I tried qt5ct, KDE and GNOME. The default is 
lthemeengine. What it should be set to?


Thansk

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"

pkg check and missing libraries

[Grzegorz Junka]

Hi,

I've updated ports, compiled with poudriere, then did pkg update and pkg 
upgrade. Then pkg upgrade -f (to reinstall everything).


Still, pkg check -B shows the following libraries missing:

root@crayon2:~ # pkg check -B
Checking all packages:   1%
(apache-openoffice-4.1.5_2) 
/usr/local/openoffice-4.1.5/openoffice4/program/libofficebean.so - 
required shared library libjawt.so not found

Checking all packages:  11%
(filerunner-17.04.01.19) 
/usr/local/share/filerunner/packages/inotify/armv6l/libinotify1.4.1.so - 
required shared library libc.so.6 not found

Checking all packages:  20%
(go-1.10,1) /usr/local/go/src/debug/elf/testdata/gcc-386-freebsd-exec - 
required shared library libc.so.6 not found

Checking all packages:  49%
(libreoffice-6.0.2) /usr/local/lib/libreoffice/program/libofficebean.so 
- required shared library libjawt.so not found

Checking all packages:  66%
(opera-12.16_6) 
/usr/local/lib/opera/gstreamer/plugins/libgstoperamatroska.so - required 
shared library libxml2.so.5 not found
(opera-12.16_6) /usr/local/lib/opera/gstreamer/plugins/libgstoperavp8.so 
- required shared library libxml2.so.5 not found
(opera-12.16_6) /usr/local/lib/opera/liboperagtk2.so - required shared 
library libfreetype.so.9 not found
(opera-12.16_6) /usr/local/lib/opera/liboperakde4.so - required shared 
library libkdeui.so.7 not found
(opera-12.16_6) /usr/local/lib/opera/liboperakde4.so - required shared 
library libkio.so.7 not found
(opera-12.16_6) /usr/local/lib/opera/liboperakde4.so - required shared 
library libkdecore.so.7 not found
(opera-12.16_6) /usr/local/lib/opera/opera - required shared library 
libfreetype.so.9 not found

Checking all packages:  89%
(visualparadigm-13.2.20161021) 
/usr/local/share/java/visualparadigm/Application/bin/vp_windows/ci - 
required shared library libpng12.so.0 not found
(visualparadigm-13.2.20161021) 
/usr/local/share/java/visualparadigm/Application/bin/vp_windows/ci - 
required shared library libjpeg.so.62 not found
(visualparadigm-13.2.20161021) 
/usr/local/share/java/visualparadigm/Application/bin/vp_windows/ci - 
required shared library libm.so.6 not found
(visualparadigm-13.2.20161021) 
/usr/local/share/java/visualparadigm/Application/bin/vp_windows/ci - 
required shared library libz.so.1 not found
(visualparadigm-13.2.20161021) 
/usr/local/share/java/visualparadigm/Application/bin/vp_windows/ci - 
required shared library libc.so.6 not found

Checking all packages: 100%

How is that possible?

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: Vote: making wayland=on default

[Grzegorz Junka]

On 21/12/2017 03:19, Michael Gmelin wrote:



On 21. Dec 2017, at 02:14, Chris H  wrote:

On Thu, 21 Dec 2017 00:29:40 +0100 "Michael Gmelin"  said


On 20. Dec 2017, at 18:50, Chris H  wrote:

On Wed, 20 Dec 2017 17:13:43 +  said
On Wed, 20 Dec 2017 16:23:59 + "Johannes Lundberg" 

said

On Wed, Dec 20, 2017 at 4:08 PM, Chris H  wrote:
On Wed, 20 Dec 2017 09:20:20 + "Johannes Lundberg"



said


Hi

I want to suggest that we enable wayland by default. In current state
having some parts of wayland in ports is basically useless the
end-users themselves re-build gtk30 and mesa-libs with wayland
enabled.

libwayland-egl.so from mesa-libs and the extra libraries and headers
from gtk30 adds like a few KB, a drop in the ocean compared to xorg
packages. (might be something more that I missed)

Personally I see no reason not to make it default on, even with
flavors coming up. For any Desktop user (as well as embedded devices
like IVI-systems and whatnot), Wayland is the future. There's no
escaping that.

Wayland has been quite usable on FreeBSD for over a year now but
access to it is limited due to the extra efforts required to use it.

If we are to compare with the other guys, several Linux distros are
already switching to wayland-based compositors as default window
server.

What do you think?

IMHO it's (still) too early. Too much other X(org) related work
still being completed. In fact, I just built a new dev box to
track 12 (CURRENT), and this was the first time I was not required
to pre generate a config file for Xorg. I was only required to
inform /usr/local/etc/X11/xorg.conf.d/nvidia-driver.conf that
the driver was "nvidia", not "nv". Everything work(s|ed) famously.
A real treat. I'm also a bit concerned about the progress (or lack
there of) on network transparency.
I (personally) could conceive it as a KERNEL OPTION, but would not
want to see it in the Default kernel.

Well, those are *my* thoughts. Because you asked. :-)

--Chris


Thanks for your feedback!
Just to clarify, we're not talking about changing any defaults that
would impact or change users' choice of desktop. We only want to
enable Wayland compositors as an alternative to X (leaving X as is).
This does not break or modify anything existing. It does not force you
to do anything differently. It simply adds a couple of libraries that
you won't use unless you run Wayland stuff (if you install qt5/gtk30
and mesa-libs).
The reference to Linux making it default might have been unclear.
Since FreeBSD doesn't have a default desktop, it's hard to change. It
is and will continue to be up to the end user what they choose to use,
we only add more options :)

Thanks for the informative reply, Johannes.
So no kernel (libs/extensions)?
Hmm, gtk3. Why is it not possible to make the Wayland stuff a sub
package/option? I think this is the preferred track/policy anyway.
I do this for all the ports I currently maintain. IOW any DE related
stuff I install, that uses GNOME related material, will pull in gtk3,
which, as I understand you say, will ultimately pull in Weston,mesa,...
is that correct? While I understand, you indicate it's only a few Kb.
I think it's cruft/(unnecessary)overhead. Which, in and of itself
seems insignificant. But in the "big picture", and over many (100's)
of builds/installations, is *not* insignificant. This also dismisses
the security related work, maintaining extra un(used|needed) material.
I suppose some will think that I'm just being nit-picky. But IMHO
I'm not. This sort of thing, if overlooked, *does* affect the bottom
line.

Thanks again, Johannes!
P.S. I have nothing against Wayland. I'm just not ready to run it

on anything "production" related, just yet. :-)

--Chris

The key is to have it in a state that easy to maintain and allows people to

install it using pkg install without conflicting with X, so you can switch
back and forth easily. I'm also not ready to switch to wayland yet (favorite
window manager not available, so many custom configurations I came up with
over the years etc.), but giving users an easy way to test it (or use it, as
it's becoming more and more mainstream now) is a good thing. Having a modern, 
working, out of the box desktop (read: no custom kernel
builds, no need to use ports, a laptop is the point of first contact for many
potential users) is incredibly important for proliferation and compared to
the total size of binaries required to run X, I think the usefulness of
providing wayland easily outweighs the extra overhead.

I wouldn't argue, nor did I argue those points. Who would? But muddying up
the individual ports (gtk3 for example) doesn't make anything lighter, or
better. Quite the contrary. IMHO Wayland should probably be added. Who
doesn't like more options? But, if it's coming to FreeBSD, and the ports
tree. It should 

Re: Building bug report

[Grzegorz Junka]

Whenever I have build errors first thing I try is to build with default 
options (e.g. using a clean setting environment in poudriere). Very 
often it succeeds, which means that the problem is in some of the option 
I have set for Firefox or one of its dependencies. Does it build with 
default options for you?


GrzegorzJ


On 22/11/2017 02:15, Mathieu Demers via freebsd-ports wrote:

Hi,

I have tried to build Firefox57 for 3 days but I had always the same 
error when it is building.


There are the infos:

FreeBSD Laptop-Mathieu 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309: 
Fri Jul 21 02:08:28 UTC 2017 
r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64


/usr/ports/www/firefox/Makefile:
 $FreeBSD: head/www/firefox/Makefile 454194 2017-11-14 19:04:44Z 
jbeich $


The error building:

gmake[3]: Leaving directory '/usr/ports/www/firefox/work/firefox-57.0'
gmake[2]: *** [/usr/ports/www/firefox/work/firefox-57.0/client.mk:237: 
profiledbuild] Error 2

gmake[2]: Leaving directory '/usr/ports/www/firefox/work/firefox-57.0'
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the 
failure to

the maintainer.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/www/firefox
*** Error code 1

Stop.
make: stopped in /usr/ports/www/firefox

===>>> make build failed for www/firefox
===>>> Aborting update

===>>> Update for www/firefox failed
===>>> Aborting update

___
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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Firefox (Doesn't) Build

[Grzegorz Junka]

On 12/11/2017 07:14, Jonathan Chen wrote:

On 12 November 2017 at 12:16, Patrick Dorion  wrote:

What's the difference between using Poudriere or Synth, though?

This is a clean system, I can't imagine a jail being cleaner... it was unpacked 
from the DVD the day before yesterday

Both are clean room builds; ie where only minimal build dependancies
are installed for each port build. The main difference is that:
  * poudriere uses jails to achieve this
  * synth uses unionfs+chroot to achieve this


Does it mean synth can't be used on ZFS? AFAIK unionfs isn't properly 
supported on ZFS, i.e. a file that exists in the underlying fs can't be 
marked as deleted in the overlying fs.


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"

no-x11 support broken for qbittorrent-nox11?

[Grzegorz Junka]

qbittorrent-nox11 doesn't compile because:

[01:24:43] >> [01][00:00:00] Starting build of 
graphics/gtk-update-icon-cache
[01:25:44] >> [01][00:01:01] Finished build of 
graphics/gtk-update-icon-cache: Failed: configure
[01:25:44] >> [01][00:01:01] Skipping build of 
net-p2p/qbittorrent-nox11: Dependent port graphics/gtk-update-icon-cache 
failed



In gtk-update-icon-cache logs I see:

===>  Configuring for gtk-update-icon-cache-2.24.29
gtk-update-icon-cache-2.24.29: Needs cairo with X11 support enabled.
*** Error code 1

Stop.
make: stopped in /usr/ports/graphics/gtk-update-icon-cache
>> Cleaning up wrkdir
===>  Cleaning for gtk-update-icon-cache-2.24.29
build of graphics/gtk-update-icon-cache ended at Sat Oct 21 14:01:53 UTC 
2017

build time: 00:01:01
!!! build failure encountered !!!

So, why do I need to enable X11 in cairo when compiling nox11 version of 
qbittorent? There are no configurable options for gtk-update-icon-cache. 
Perhaps it's missing a nox11 option?


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"

Crashing chromium/iridium

[Grzegorz Junka]

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: portmaster, portupgrade, etc

[Grzegorz Junka]

On 05/10/2017 22:15, Chris H wrote:

On Thu, 5 Oct 2017 20:27:19 + Grzegorz Junka <li...@gjunka.com> wrote


On 05/10/2017 19:54, Baho Utot wrote:


On 10/04/17 16:39, Ernie Luzar wrote:


Here's my take on that.

The future direction has already been decided by the FreeBSD leaders
2 years ago with their development of a better pkg system.


[putolin]


Don't let the few old school die hearts who are afraid of any change
and make the most noise influence you. There will always be edge case
user who think their needs out weight what is best for the group.

So what you are really saying is Go to hell old farts we don't need
you here.  We are not going to listen to you as you are too old to
know anything.  You are old and stupid.

It is looking like I will need to move away from FreeBSD if that is
really what is being accomplished here.

But do those old farts have anything interesting to say or they are just
making noise? What's the alternative to the proposed direction?\

This is an *extremely* difficult question to answer, and these discussions
come up all too often. The short answer is; shut up and code! -- Meaning;
since FreeBSD exists, and grows because of those whom are willing to
produce code to accomplish it. Those who put their code, where their
mouth is, will be the deciding vote. :)
I'm not always loving it. But it is, what it is, and it's hard to argue
with it. No? :)


Yes and no. You are absolutely right that those able to code will have 
an advantage over those who just shout at others but do nothing, even if 
those who code don't do exactly what those who shout would like them to 
do. But that's shortsighted. There are better ways of spending time than 
developing something that no one else is going to use.


FreeBSD exists for its users. This doesn't mean those who shout the 
loudest or those with esoteric needs that no one has time to cater for. 
This means the 90% who are not even subscribed to this list or the 99% 
who have never expressed their opinion about the direction FreeBSD 
should take either on this list or anywhere else (the silent majority).


They vote for the proposed direction either by adopting FreeBSD and 
spreading the word around, or by abandoning it and moving to other 
systems without expressing any complaints. That's the reality.


Now, from that perspective it doesn't really matter if portmaster is 
maintained or not. What does matter is if the proposed changes to pkg 
and the ports system are going to make the life of an average user 
easier or not. Everything else should be secondary.


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: portmaster, portupgrade, etc

[Grzegorz Junka]

On 05/10/2017 22:27, Chris H wrote:

On Thu, 5 Oct 2017 22:05:05 + Grzegorz Junka <li...@gjunka.com> wrote


On 05/10/2017 21:53, Chris H wrote:

On Thu, 5 Oct 2017 10:52:51 -0600 Adam Weinberger <ad...@adamw.org> wrote


On 5 Oct, 2017, at 10:28, Steve Kargl <s...@troutmask.apl.washington.edu>
wrote:
On Thu, Oct 05, 2017 at 09:31:41AM -0600, Adam Weinberger wrote:

On 5 Oct, 2017, at 9:25, Steve Kargl <s...@troutmask.apl.washington.edu>
wrote: Which brings me back to my i686 laptop with limited resources.
If portmgr makes it impractical/impossible to easily install ports
without a sledge hammer, then testing possible future patches to
libm will simply skip i686 class hardware.

I'm not clear what role you think portmgr has in this. Portmgr
merely brings new features to the ports tree. Portmgr itself is
responsible for no build tool other than "make install".

I don't know how many times I need to keep saying this, but
portmgr is not killing off portmaster. There is simply nobody
developing portmaster anymore, and that is not portmgr's
responsibility. There ARE people developing poudriere, and
that is why poudriere continues to work with new ports tree features.


I suppose it's a matter of semantics.  If the Makefiles and *.mk
files under /usr/ports are altered to allow subpackages and
flavours to enhance pkg and poudriere, which will break portmaster
further, then yes portmgr has made a decision to endorse a sledge
hammer over simple tools.

Mere users of the ports collection are not privy to discussions
on a portmgr alias/mailinglist.  A quick scan of the members of
portmgr and contributors to poudriere show at least 4 common
members.  There are 8 people listed under portmgr.  When decisions
were being made on the introduction of subpackages/flavours into
the ports collection, did the 4 common members recluse themselves
from any formal or informal vote?  If no, then there is certainly
a conflict-of-interest in what is best for the ports collection
versus what is best for poudriere.

Yes, portmaster is currently unmaintained.  Doug Barton left
FreeBSD developement because he was continually brow beaten
whenever he pointed out what he felt were (serious) flaws in
FreeBSD and in the ports collection.

Not quite. It works in the other direction. Ports isn't designed for
poudriere. Poudriere is designed for ports. 100% of the flavours
development is happening in public. Anybody who wishes to work on
portmaster can participate in the process too.

I think you have a misperception of the relationship between portmgr and
poudriere. The coming flavours would break poudriere too, except there are
people actively developing it.

You seem to be fully convinced in a conspiracy to destroy portmaster, and
I don't get the impression that I'm going to change your mind. All I can
tell you is that impending portmaster breakage is NOT by design, and is
only happening because portmaster isn't actively developed anymore. If
you'd like to believe in secret poudriere cabals and anti-portmaster
conspiracies, that's up to you.

# Adam

While I have no intention to speak on Steve's behalf. I /would/ like
to speak in his humble defense;
over year ago, I attempted to become maintainer for
ports-mgmt/portmaster. I did so 1) because I /strongly/ believed in
it's value, and 2) it had been scorned for some time, and there were
/many/ discussions to have it removed. At the time I attempted the
request, it had not "officially" had a maintainer, and there was
serious talk as to /really/ having it removed from the ports tree.
bdrewery@ had been nursing it along. Conspiracy, or not. Grepping the
mailing list for portmaster /will/ show /many/ heated discussions
regarding it's removal -- this thread included. In any event, after
a few inquiries regarding taking maintainer for the port. My request
was ultimately declined. I was deemed unqualified. That judgement was
unfounded. :(
Granted, maintenance of portmaster is no small feat -- it's an
enormous scriptbal. But now some months later, I am maintainer for
~120 ports! perform a search for portmaster@ and see for yourself.
You can say what you will about some of those ports, but what it
/does/ show, is commitment, and long term commitment to boot!
I grow weary of the circular discussions surrounding portmaster. So
this is what I'd like to propose. It's maintenance is a bigger job for
anyone whom is not it's original author, for anyone that did not
grow it from scratch, and become so intimately familiar with it. So
perhaps a better solution might be for me to attempt again ask to
become maintainer. But this time, make it a group effort -- if for

What does it mean in practical terms? A list of signatories under your
candidature and a recommendation letter? Endorsements sent to a
particular email?

I don't quite understand why would anybody want to decline a request to
maintain a port that is unmaintained otherwise? Are they expecting
better can

Re: portmaster, portupgrade, etc

[Grzegorz Junka]

On 05/10/2017 22:08, Baho Utot wrote:



On 10/05/17 16:27, Grzegorz Junka wrote:


On 05/10/2017 19:54, Baho Utot wrote:



On 10/04/17 16:39, Ernie Luzar wrote:


Here's my take on that.

The future direction has already been decided by the FreeBSD 
leaders 2 years ago with their development of a better pkg system.




[putolin]

Don't let the few old school die hearts who are afraid of any 
change and make the most noise influence you. There will always be 
edge case user who think their needs out weight what is best for 
the group.


So what you are really saying is Go to hell old farts we don't need 
you here.  We are not going to listen to you as you are too old to 
know anything.  You are old and stupid.


It is looking like I will need to move away from FreeBSD if that is 
really what is being accomplished here.


But do those old farts have anything interesting to say or they are 
just making noise? What's the alternative to the proposed direction?


GrzegorzJ


Everyone should be heard.  who knows if the direction would be the same?

You won't hear from this old fart as every time I have had a question 
or input on direction All I got was grief.


The last time was about pkgng.  As someone that moved from 
LFS/building my own distribution to FreeBSD, and adding a package 
manager and tools for LFS.  I think I may have learned something in 
that process.  SO what did you folks do, Well I was just bitch slapped 
down.  So much for user input.  Hell pkgng can not even merge 
configurations file in /etc when is that going to be fixed. Also the 
packaging of base is just a cluster fuck, there are no other words for 
that non sense.  When the base packaging was started it was told that 
by 11.0 it would be done and here it is at 11.1 and it still a cluster 
fuck.  Now you want to add flavors,  good grief you can not even 
finish the other projects that were started how will this flavors 
thing work out?


Anyway it looks like I will be moving to OpenBSD or just go back to 
rolling my own as I have more free time to pursue building systems 
that work for me.  FreeBSD just doesn't look like it will be a fit for 
me in the future.




What you are saying (or what I am reading) is that the direction isn't 
wrong, but rather that there is too much technical debt being left 
behind. That's not the same thing. Merging configurations in /etc or 
packaging of base are fixable regardless if there are flavours or not. 
So, again, what's the alternative to the proposed direction? If you are 
saying that there could have been a better alternative if the technical 
debt hasn't been left behind then I still don't get it how it would have 
made a difference.

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: portmaster, portupgrade, etc

[Grzegorz Junka]

On 05/10/2017 21:53, Chris H wrote:

On Thu, 5 Oct 2017 10:52:51 -0600 Adam Weinberger  wrote


On 5 Oct, 2017, at 10:28, Steve Kargl 
wrote:
On Thu, Oct 05, 2017 at 09:31:41AM -0600, Adam Weinberger wrote:

On 5 Oct, 2017, at 9:25, Steve Kargl 
wrote: Which brings me back to my i686 laptop with limited resources.
If portmgr makes it impractical/impossible to easily install ports
without a sledge hammer, then testing possible future patches to
libm will simply skip i686 class hardware.

I'm not clear what role you think portmgr has in this. Portmgr
merely brings new features to the ports tree. Portmgr itself is
responsible for no build tool other than "make install".

I don't know how many times I need to keep saying this, but
portmgr is not killing off portmaster. There is simply nobody
developing portmaster anymore, and that is not portmgr's
responsibility. There ARE people developing poudriere, and
that is why poudriere continues to work with new ports tree features.


I suppose it's a matter of semantics.  If the Makefiles and *.mk
files under /usr/ports are altered to allow subpackages and
flavours to enhance pkg and poudriere, which will break portmaster
further, then yes portmgr has made a decision to endorse a sledge
hammer over simple tools.

Mere users of the ports collection are not privy to discussions
on a portmgr alias/mailinglist.  A quick scan of the members of
portmgr and contributors to poudriere show at least 4 common
members.  There are 8 people listed under portmgr.  When decisions
were being made on the introduction of subpackages/flavours into
the ports collection, did the 4 common members recluse themselves
from any formal or informal vote?  If no, then there is certainly
a conflict-of-interest in what is best for the ports collection
versus what is best for poudriere.

Yes, portmaster is currently unmaintained.  Doug Barton left
FreeBSD developement because he was continually brow beaten
whenever he pointed out what he felt were (serious) flaws in
FreeBSD and in the ports collection.

Not quite. It works in the other direction. Ports isn't designed for
poudriere. Poudriere is designed for ports. 100% of the flavours development
is happening in public. Anybody who wishes to work on portmaster can
participate in the process too.

I think you have a misperception of the relationship between portmgr and
poudriere. The coming flavours would break poudriere too, except there are
people actively developing it.

You seem to be fully convinced in a conspiracy to destroy portmaster, and I
don't get the impression that I'm going to change your mind. All I can tell
you is that impending portmaster breakage is NOT by design, and is only
happening because portmaster isn't actively developed anymore. If you'd like
to believe in secret poudriere cabals and anti-portmaster conspiracies,
that's up to you.

# Adam

While I have no intention to speak on Steve's behalf. I /would/ like
to speak in his humble defense;
over year ago, I attempted to become maintainer for
ports-mgmt/portmaster. I did so 1) because I /strongly/ believed in
it's value, and 2) it had been scorned for some time, and there were
/many/ discussions to have it removed. At the time I attempted the
request, it had not "officially" had a maintainer, and there was
serious talk as to /really/ having it removed from the ports tree.
bdrewery@ had been nursing it along. Conspiracy, or not. Grepping the
mailing list for portmaster /will/ show /many/ heated discussions
regarding it's removal -- this thread included. In any event, after
a few inquiries regarding taking maintainer for the port. My request
was ultimately declined. I was deemed unqualified. That judgement was
unfounded. :(
Granted, maintenance of portmaster is no small feat -- it's an
enormous scriptbal. But now some months later, I am maintainer for
~120 ports! perform a search for portmaster@ and see for yourself.
You can say what you will about some of those ports, but what it
/does/ show, is commitment, and long term commitment to boot!
I grow weary of the circular discussions surrounding portmaster. So
this is what I'd like to propose. It's maintenance is a bigger job for
anyone whom is not it's original author, for anyone that did not
grow it from scratch, and become so intimately familiar with it. So
perhaps a better solution might be for me to attempt again ask to
become maintainer. But this time, make it a group effort -- if for


What does it mean in practical terms? A list of signatories under your 
candidature and a recommendation letter? Endorsements sent to a 
particular email?


I don't quite understand why would anybody want to decline a request to 
maintain a port that is unmaintained otherwise? Are they expecting 
better candidatures? I would understand if they had 10 proposals to 
maintain the same port, but not if there is just one? But I am not good 
at politics so 

Re: portmaster, portupgrade, etc

[Grzegorz Junka]

On 05/10/2017 19:54, Baho Utot wrote:



On 10/04/17 16:39, Ernie Luzar wrote:


Here's my take on that.

The future direction has already been decided by the FreeBSD leaders 
2 years ago with their development of a better pkg system.




[putolin]

Don't let the few old school die hearts who are afraid of any change 
and make the most noise influence you. There will always be edge case 
user who think their needs out weight what is best for the group.


So what you are really saying is Go to hell old farts we don't need 
you here.  We are not going to listen to you as you are too old to 
know anything.  You are old and stupid.


It is looking like I will need to move away from FreeBSD if that is 
really what is being accomplished here.


But do those old farts have anything interesting to say or they are just 
making noise? What's the alternative to the proposed direction?


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: portmaster, portupgrade, etc

[Grzegorz Junka]

On 05/10/2017 18:41, Steve Kargl wrote:

On Thu, Oct 05, 2017 at 10:52:51AM -0600, Adam Weinberger wrote:

(courtesy long-line wrap)


You seem to be fully convinced in a conspiracy to destroy
portmaster, and I don't get the impression that I'm going
to change your mind. All I can tell you is that impending
portmaster breakage is NOT by design, and is only happening
because portmaster isn't actively developed anymore. If
you'd like to believe in secret poudriere cabals and
anti-portmaster conspiracies, that's up to you.

Nope. No conspiracy theory here.  But, the above is a good
method to deflect attention and blame.

I simply find it ironic/comical that someone dreamt up
flavours/subpackage for the ports collections with the
knowledge that this will break all tools used to manage
ports, and portmgr which is charged with

Discusses how that the way that the Ports Collection is
implemented affects the above policies, and, in particular,
such concepts as changes that require regression tests and
sweeping changes.

(see https://www.freebsd.org/portmgr/) seems to have endorsed
a "sweeping change" with this outcome.

Then that someone managed to convince developers of a single
ports management tool to implement support for flavours/subpackaged.
So, portmgr now is going ahead with a "sweeping change" at the expense
of all other ports management tool.  I have simply pointed out, portmgr
and contributors to that single ports manange tool have a significant
overlap.  Nope.  No conspiracy.  Just the truth.

So, Adam, if the poudriere developers had stated that poudriere
would not support flavors/subpackages would portmgr still wedge
the necessary infrastructure into the Makefiles and *.mk files?



I don't understand this argument. Are flavours / subpackages good / 
desirable or they are not good / undesirable? As far as I know they 
enable features that otherwise wouldn't be possible. So surely not the 
later. So if the former, could they have been designed in a way that 
doesn't break existing build tools? Maybe yes, but if that was the case 
then surely someone would have proposed such a design? Or maybe even 
implemented it. Maybe at an additional cost of non-trivial changes 
somewhere else. Maybe updating the build tools was the easier option. In 
the end those are just build tools and no one should expect them to 
never change. But if that was the case, how would they go about updating 
ports to support new features? Of course, they would discuss with the 
maintainers of those tools, (why wouldn't they ?), if the change is 
feasible to implement in the tools and would take less effort than the 
mentioned change somewhere else instead. How many maintainers they would 
need to contact? I know of 4 - portmaster, portupgrade, synth and 
poudriere. Am I missing something? Oh, yes, the mighty make. But it will 
be mass-updated so no need to look for anyone. So, who should they 
contact to discuss the support for ports/subpackages in portmaster, 
portupgrade and synth? Should they hold off until a maintainer is found? 
Should they pay for updating these tools from their pocket (using their 
time)?


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: portmaster, portupgrade, etc

[Grzegorz Junka]

On 04/10/2017 21:00, Mark Linimon wrote:

On Wed, Oct 04, 2017 at 08:56:00PM +, Grzegorz Junka wrote:

Maybe I am just too ambitious or maybe poudriere is more
idiot-proof?

My possibly incorrect understanding is that poudriere
trades off doing a lot more work in an attempt to produce
more rigorously correct results.



I think it's the other way around. Poudriere does as much as a 
standalone build server would have to do, but it does it in a jail, so 
the main system isn't affected and can be used to non-build related work 
in the meantime. It's portmaster/portupgrade that trade off doing less 
work with less resources in an attempt to produce less rigorously 
correct result (and often no result at all, or even an additional work 
needed to restore the build server to a working condition).

___
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: portmaster, portupgrade, etc

[Grzegorz Junka]

On 04/10/2017 21:22, Steve Kargl wrote:

On Wed, Oct 04, 2017 at 08:30:49PM +, Grzegorz Junka wrote:

On 04/10/2017 19:40, Steve Kargl wrote:

Ahem, yeah, so I'm not allowed to request a short description
on how to use poudiere in a resource constrained environment?


The environment isn't constrained by poudriere but by the ports you want
to compile. When compiling libreoffice or chromium or firefox I don't
think there is anything else that can be done than setting poudriere to
run no more than 1 job at a time. Poudriere itself doesn't take any
additional resources, it's just a dedicated jail and a bunch of scripts.


I did not state that the "environment is constrained by poudriere".
The environment is contrained due to resource limits.  If you
only have 1 Gb of memory and 5-10 GB diskspace, then using poudriere
with zfs and jails is a nonstarter.  Yes, I'm aware that zfs is not
required.  Can't find info on whether jails can be avoided.  Having
say lang/llvm40 installed in /usr/local and in a jail would consumes
2.6 GB.  That's 1 port!



Would temporarily spinning up an EC2 instance on AWS be an option? It's 
priced per hour so shouldn't cost much to compile required packages? On 
the other hand, a desktop with 4GB of RAM and 250GB HDD costs $50-100.


I sometimes think if setting up a build system where someone would be 
able to build ports with their own customized options could become 
popular...


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: portmaster, portupgrade, etc

[Grzegorz Junka]

On 04/10/2017 20:43, Mark Linimon wrote:

On Wed, Oct 04, 2017 at 08:13:16PM +, Grzegorz Junka wrote:

I was trying
to compile with the system that was being updated at the
same time - this can't possibly work (or can it?).

It works somewhere between "quite often" to "nearly all
the time".  It can vary depending on the complexity of


Well, that's not my experience. For me it worked occasionally at best. A 
few times the system became so broken that many applications couldn't be 
opened any more and I had to spend hours to restore it to some kind of 
usability. Even with poudriere I still manage to break the ports quite 
often by setting various options not to their recommended values - see 
defects I have been raising on 
https://www.freebsd.org/support/bugreports.html But at least I am not 
able to install them until they are fixed.


Maybe I am just too ambitious or maybe poudriere is more idiot-proof? I 
guess portmaster or portupgrade may work fine if one uses the default 
options, but in that case, hey, why bother? Just use the compiled 
packages! If you try to change some ports to non-default options, and 
something doesn't compile, portmaster/portupgrade will leave the system 
in half-baked state. And then only heavens can help...



the ports you have installed, what state the tree is in,
how much the ports you use are often used by others, and
subtle differences in changes to port dependencies.

This is complex enough to be indistinguishable from "phase
of the moon."

In this case I really wish I were joking.

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"


___
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: portmaster, portupgrade, etc

[Grzegorz Junka]

On 04/10/2017 19:40, Steve Kargl wrote:

On Wed, Oct 04, 2017 at 02:57:08PM -0400, George Mitchell wrote:

On 10/04/17 14:14, Steve Kargl wrote:

On Wed, Oct 04, 2017 at 10:21:26AM -0700, Freddie Cash wrote:

On Wed, Oct 4, 2017 at 10:15 AM, Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:


On Wed, Oct 04, 2017 at 12:16:49PM -0400, Michael W. Lucas wrote:

Poudriere really needs its own small book. Yes, you can do simple
poudriere installs, but once you start covering it properly the docs
quickly expand. My notes alone are longer than my af3e chapter
limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
2018).

Please include a discussion on how to use poudriere on
a system with limited resouces [...]

​Pretty sure the standard response will be along the lines of:​ [...]

Some users cannot afford a 16-core, 32 GB ram, 2TB diskspace box
to simply build ports with custom options.  [...]

While I agree with you, allow me to insert a gentle reminder that the
OP was asking only about whether to include portmaster in his book.
I suggest that he should. -- George

Ahem, yeah, so I'm not allowed to request a short description
on how to use poudiere in a resource constrained environment?



The environment isn't constrained by poudriere but by the ports you want 
to compile. When compiling libreoffice or chromium or firefox I don't 
think there is anything else that can be done than setting poudriere to 
run no more than 1 job at a time. Poudriere itself doesn't take any 
additional resources, it's just a dedicated jail and a bunch of scripts.


I would rather say that the amount of resources poudriere takes to 
compile stuff is normal, the baseline. Portmaster or portupgrade make a 
compromise - unstable compilation environment for some additional memory 
to compile especially resource hungry ports.


What I am trying to say is that there isn't probably much to discuss. 
However, explaining the difference between portmaster/portupgrade and 
poudriere and how to plan computer resources for compiling various sizes 
of ports may be more useful?


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: portmaster, portupgrade, etc

[Grzegorz Junka]

On 04/10/2017 16:16, Michael W. Lucas wrote:

Hi,

I'm doing tech edits on the new edition of "Absolute FreeBSD," and
stumbled into what's apparently a delicate topic.

Some of my reviewers are happy I included portmaster in the book.

Some reviewers beg me not to include it.

Unfortunately, people will be reading af3e and considering it
definitive for the next several years. So I have to get a feel for
where things are going. :-/

I've read a couple threads on portmaster's current problems/growing
pains and its looming difficulty with forthcoming flavors.

I've been a happy portmaster user for many years now. All things being
equal, if its future is still being debated I'm inclined to keep it in
the book.

Poudriere really needs its own small book. Yes, you can do simple
poudriere installs, but once you start covering it properly the docs
quickly expand. My notes alone are longer than my af3e chapter
limits. (I'll probably publish "FreeBSD Packaging Misery^WMastery" in
2018).

Truly, I'm not looking to start a flame war here. I only want a bit of
guidance on The Future...



If describing the basic usage of poudriere takes more than 2-3 pages 
then something is wrong. The handbook has it covered in just a few 
paragraphs:

https://www.freebsd.org/doc/handbook/ports-poudriere.html

When I moved to FreeBSD I tried for months to use portmaster and 
portupgrade because that was the official way described in the handbook. 
But there were always problems. I was happy when my system was still 
usable after an upgrade, not mentioning the upgraded ports to work as 
expected.


I remember often thinking, what kind of system this FeeBSD is if even a 
simple update from sources can screw up so many things! Is anyone really 
using it, or is it some kind of niche OS, the sort of MorphOS or AROS?


I started looking on the internet how others compile it, and I 
discovered that I was doing it all wrong!!! I read that handbook chapter 
and it all made sense. I was trying to compile with the system that was 
being updated at the same time - this can't possibly work (or can it?). 
I spent one afternoon setting up poudriere and I haven't looked back 
since then.


If you wish please mention portmaster and/or portupgrade, but IN 
ADDITION to poudriere. I can't imagine a serious book on FreeBSD not 
giving at least as much space to poudriere as to the other tools.


It's great that Absolute FreeBSD is getting an update. That was an 
indispensable source of information when I was learning the FreeBSD way. 
But it became outdated quite quickly. Please make an effort to discuss 
things that are not getting outdated as quickly this time.


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"

dns/unbound patch error

[Grzegorz Junka]

I remember something was mentioned on this list about unbound. Currently 
it fails for me with the following error:


===>  Patching for unbound-1.6.6
/bin/cat 
/wrkdirs/usr/ports/dns/unbound/work/unbound-1.6.6/contrib/-filter-iterator.patch 
| /usr/bin/patch -d /wrkdirs/usr/ports/dns/unbound/work/unbound-1.6.6 -p1 -s

1 out of 3 hunks failed--saving rejects to iterator/iterator.h.rej
*** Error code 1

Stop.
make: stopped in /usr/ports/dns/unbound
>> Cleaning up wrkdir
===>  Cleaning for unbound-1.6.6
build of dns/unbound ended at Mon Sep 25 00:40:44 UTC 2017
build time: 00:00:06
!!! build failure encountered !!!

Is this a known issue?

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: math/R doesn't compile

[Grzegorz Junka]

Looks like the port doesn't compile when LTO is set:

OPTIONS_FILE_SET+=LTO

I have raised a new bug as I couldn't find one mentioning this issue yet:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222553

GrzegorzJ


On 12/09/2017 10:12, Otacílio wrote:

Em 11/09/2017 20:07, Grzegorz Junka escreveu:

../extra/tre/libtre.a: error adding symbols: Malformed archive
collect2: error: ld returned 1 exit status
gmake[4]: *** [Makefile:177: libR.so] Error 1
gmake[4]: Leaving directory 
'/wrkdirs/usr/ports/math/R/work/R-3.4.1/src/main'

gmake[3]: *** [Makefile:135: R] Error 2
gmake[3]: Leaving directory 
'/wrkdirs/usr/ports/math/R/work/R-3.4.1/src/main'

gmake[2]: *** [Makefile:28: R] Error 1
gmake[2]: Leaving directory '/wrkdirs/usr/ports/math/R/work/R-3.4.1/src'
gmake[1]: *** [Makefile:61: R] Error 1
gmake[1]: Leaving directory '/wrkdirs/usr/ports/math/R/work/R-3.4.1'

Which option may be responsible for this problem? I can only set libr 
to be compiled or not.


GrzegorzJ

___ 


Maybe this is a local problem on your system because I have just 
finished a build and install of math/R on my machine (FreeBSD 11.1 
amd64 ports Revision: 449667, default R options):


install  -m 0644 "./dir" "/usr/ports/math/R/work/stage/usr/local/info"
installing R info pages ...
updating '/usr/local/info/dir' ...
gmake[3]: Leaving directory '/usr/ports/math/R/work/R-3.4.1/doc/manual'
gmake[2]: Leaving directory '/usr/ports/math/R/work/R-3.4.1'
> Compressing man pages (compress-man)
===>   Installing ldconfig configuration file
> Running Q/A tests (stage-qa)
root@nostromo:/usr/ports/math/R # make deinstall install
===>  Deinstalling for R
===>   Deinstalling R-3.4.0_2
Updating database digests format: 100%
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 1 packages (of 0 
packages in the universe):


Installed packages to be REMOVED:
R-3.4.0_2

Number of packages to be removed: 1

The operation will free 61 MiB.
[1/1] Deinstalling R-3.4.0_2...
[1/1] Deleting files for R-3.4.0_2: 100%
===>  Installing for R-3.4.1_7
===>   R-3.4.1_7 depends on executable: gmake - found
===>   R-3.4.1_7 depends on executable: wget - found
===>   R-3.4.1_7 depends on executable: gfortran6 - found
===>   R-3.4.1_7 depends on package: ghostscript9-agpl-base>=9.16_2 - 
found
===>   R-3.4.1_7 depends on file: /usr/local/libdata/pkgconfig/ice.pc 
- found
===>   R-3.4.1_7 depends on file: /usr/local/libdata/pkgconfig/sm.pc - 
found
===>   R-3.4.1_7 depends on file: /usr/local/libdata/pkgconfig/x11.pc 
- found
===>   R-3.4.1_7 depends on file: /usr/local/libdata/pkgconfig/xext.pc 
- found
===>   R-3.4.1_7 depends on file: /usr/local/libdata/pkgconfig/xmu.pc 
- found
===>   R-3.4.1_7 depends on file: 
/usr/local/libdata/pkgconfig/xscrnsaver.pc - found
===>   R-3.4.1_7 depends on file: /usr/local/libdata/pkgconfig/xt.pc - 
found

===>   R-3.4.1_7 depends on executable: indexinfo - found
===>   R-3.4.1_7 depends on shared library: libcurl.so - found 
(/usr/local/lib/libcurl.so)
===>   R-3.4.1_7 depends on shared library: libpcre.so - found 
(/usr/local/lib/libpcre.so)
===>   R-3.4.1_7 depends on shared library: libicui18n.so - found 
(/usr/local/lib/libicui18n.so)
===>   R-3.4.1_7 depends on shared library: libpng.so - found 
(/usr/local/lib/libpng.so)
===>   R-3.4.1_7 depends on shared library: libtiff.so - found 
(/usr/local/lib/libtiff.so)
===>   R-3.4.1_7 depends on shared library: libreadline.so.7 - found 
(/usr/local/lib/libreadline.so.7)
===>   R-3.4.1_7 depends on shared library: libintl.so - found 
(/usr/local/lib/libintl.so)
===>   R-3.4.1_7 depends on shared library: libjpeg.so - found 
(/usr/local/lib/libjpeg.so)
===>   R-3.4.1_7 depends on shared library: libtk86.so - found 
(/usr/local/lib/libtk86.so)
===>   R-3.4.1_7 depends on shared library: libtcl86.so - found 
(/usr/local/lib/libtcl86.so)
===>   R-3.4.1_7 depends on shared library: libcairo.so - found 
(/usr/local/lib/libcairo.so)
===>   R-3.4.1_7 depends on shared library: libglib-2.0.so - found 
(/usr/local/lib/libglib-2.0.so)
===>   R-3.4.1_7 depends on shared library: libintl.so - found 
(/usr/local/lib/libintl.so)
===>   R-3.4.1_7 depends on shared library: libpango-1.0.so - found 
(/usr/local/lib/libpango-1.0.so)

===>  Checking if R already installed
===>   Registering installation for R-3.4.1_7
Installing R-3.4.1_7...

On 11.1 and later, there is a problem downloading R packages when
gfortran is chosen as the fortran compiler.

Use either of these workarounds until a permanent solution is found.

1. If you are on an amd64 system, you can use flang as the fortran
   compiler.

2. If you choose gfortran as the fortran compiler, you can add

   options(download.fil

Re: math/R doesn't compile

[Grzegorz Junka]

On 12/09/2017 10:12, Otacílio wrote:

Em 11/09/2017 20:07, Grzegorz Junka escreveu:

../extra/tre/libtre.a: error adding symbols: Malformed archive
collect2: error: ld returned 1 exit status
gmake[4]: *** [Makefile:177: libR.so] Error 1
gmake[4]: Leaving directory 
'/wrkdirs/usr/ports/math/R/work/R-3.4.1/src/main'

gmake[3]: *** [Makefile:135: R] Error 2
gmake[3]: Leaving directory 
'/wrkdirs/usr/ports/math/R/work/R-3.4.1/src/main'

gmake[2]: *** [Makefile:28: R] Error 1
gmake[2]: Leaving directory '/wrkdirs/usr/ports/math/R/work/R-3.4.1/src'
gmake[1]: *** [Makefile:61: R] Error 1
gmake[1]: Leaving directory '/wrkdirs/usr/ports/math/R/work/R-3.4.1'

Which option may be responsible for this problem? I can only set libr 
to be compiled or not.


GrzegorzJ

___ 


Maybe this is a local problem on your system because I have just 
finished a build and install of math/R on my machine (FreeBSD 11.1 
amd64 ports Revision: 449667, default R options):


Could be. Just wanted to verify if it's a known problem. If not they I 
will try to find out which option breaks the build.

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"

multimedia/avidemux-qt4 compilation error

[Grzegorz Junka]

Which option may be responsible for this error:

/wrkdirs/usr/ports/multimedia/avidemux-qt4/work/avidemux_2.6.11/avidemux/qt4/ADM_jobs/src/ADM_jobControl.cpp:115:58: 
error: unable to find string literal operator 'operator""y' with 'const 
char [8]', 'long unsigned int' arguments
 #define MX(x,y) case ADM_JOB_##x: 
status->setIcon(QIcon(":/jobs/"y));break;


Then it repeats a few times when compiling the ADM_jobControl file.

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"

math/R doesn't compile

[Grzegorz Junka]

../extra/tre/libtre.a: error adding symbols: Malformed archive
collect2: error: ld returned 1 exit status
gmake[4]: *** [Makefile:177: libR.so] Error 1
gmake[4]: Leaving directory 
'/wrkdirs/usr/ports/math/R/work/R-3.4.1/src/main'

gmake[3]: *** [Makefile:135: R] Error 2
gmake[3]: Leaving directory 
'/wrkdirs/usr/ports/math/R/work/R-3.4.1/src/main'

gmake[2]: *** [Makefile:28: R] Error 1
gmake[2]: Leaving directory '/wrkdirs/usr/ports/math/R/work/R-3.4.1/src'
gmake[1]: *** [Makefile:61: R] Error 1
gmake[1]: Leaving directory '/wrkdirs/usr/ports/math/R/work/R-3.4.1'

Which option may be responsible for this problem? I can only set libr to 
be compiled or not.


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"

Minor bug in pkg?

[Grzegorz Junka]

Shouldn't pkg be incrementing the first number when installing/upgrading 
packages?


[1/247] Reinstalling blender-2.78c_3...
Extracting blender-2.78c_3: 100%
[1/247] Reinstalling abiword-3.0.1_5...
Extracting abiword-3.0.1_5: 100%
[1/247] Upgrading R from 3.4.0_2 to 3.4.1_4...
Extracting R-3.4.1_4: 100%
[1/247] Upgrading GraphicsMagick from 1.3.25_3,1 to 1.3.26,1...
Extracting GraphicsMagick-1.3.26,1: 100%


___
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: abiword-3.0.1_5

[Grzegorz Junka]

On 24/07/2017 20:24, D.-C. M. wrote:

Hello,

Textproc\link-grammar has been updated recently, since building Abiword with 
Link-Grammar fails.

Unchecking the option fixes the issue



Hi David,
That's not exactly the solution. If the option is not supported please 
remove it or mark it as broken. If it is supported please allow the port 
to compile with it. I will wait until it's resolved either way (I don't 
need Abiword urgently, still using the previous version).

Thanks
Grzegorz J
___
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: Blender and opencv2-core

[Grzegorz Junka]

On 23/07/2017 19:57, Herbert J. Skuhra wrote:

Grzegorz Junka skrev:

On 23/07/2017 12:42, Grzegorz Junka wrote:

I am getting the following error when setting up blender
dependencies in poudriere:

===> Setting user-specified options for blender-2.78c_3 and dependencies
blender-2.78c_3:
"/usr/local/poudriere/ports/local/graphics/opencv2-core"
non-existent -- dependency list incomplete

Has this been removed but not updated in one of dependent ports?

Grzegorz J


Sent too early, this is the actual error when trying to compile:

[00:00:17] >> Error: graphics/openimageio depends on nonexistent
origin 'graphics/opencv2-core'; Please contact maintainer of the port
to fix this.
[00:00:33] >> Error: Fatal errors encountered calculating dependencies

This is of course when OpenImageIO setting is enabled in blender.

Have you tried to modify Makefile?

Index: graphics/openimageio/Makefile
===
--- graphics/openimageio/Makefile   (revision 446433)
+++ graphics/openimageio/Makefile   (working copy)
@@ -69,7 +69,7 @@
  OPENCV_CMAKE_ON=  -DUSE_OPENCV:BOOL=ON
  OPENCV_CMAKE_OFF= -DUSE_OPENCV:BOOL=OFF
  OPENCV_LIB_DEPENDS=   libopencv_highgui.so:graphics/opencv \
-   libopencv_core.so:graphics/opencv2-core \
+   libopencv_core.so:graphics/opencv-core \
libopenjpeg.so:graphics/openjpeg15
  
  OPENJPEG_CMAKE_ON=	-DUSE_OPENJPEG:BOOL=ON




Tried just now and it seems to help. At least there were no errors when 
configuring and starting the build in poudriere. I will need to wait a 
day or so in best case scenario to check if the tree/blender compiles fine.


I am using poudriere to update ports, i.e. poudriere ports -p local -u, 
not svn.


Should I delete this patch before updating ports next time? How will 
poudriere treat a local change a Makefile going forward? What's the best 
practice?


Thanks for help
Grzegorz J

___
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: Blender and opencv2-core

[Grzegorz Junka]

On 23/07/2017 12:42, Grzegorz Junka wrote:
I am getting the following error when setting up blender dependencies 
in poudriere:


===> Setting user-specified options for blender-2.78c_3 and dependencies
blender-2.78c_3: 
"/usr/local/poudriere/ports/local/graphics/opencv2-core" non-existent 
-- dependency list incomplete


Has this been removed but not updated in one of dependent ports?

Grzegorz J



Sent too early, this is the actual error when trying to compile:

[00:00:17] >> Error: graphics/openimageio depends on nonexistent 
origin 'graphics/opencv2-core'; Please contact maintainer of the port to 
fix this.

[00:00:33] >> Error: Fatal errors encountered calculating dependencies

This is of course when OpenImageIO setting is enabled in blender.

Grzegorz J
___
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"

Blender and opencv2-core

[Grzegorz Junka]

I am getting the following error when setting up blender dependencies in 
poudriere:


===> Setting user-specified options for blender-2.78c_3 and dependencies
blender-2.78c_3: 
"/usr/local/poudriere/ports/local/graphics/opencv2-core" non-existent -- 
dependency list incomplete


Has this been removed but not updated in one of dependent ports?

Grzegorz J

___
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: Firefox/GTK3 issue and reinstalling dependent ports

[Grzegorz Junka]

On 16/07/2017 13:35, Kurt Jaeger wrote:

Hi!


Hmm, I found this:

pkg clean -a
cleans the cache and

pkg install -R -f firefox

should force a reinstallation of the package and all dependencies.

Well, indeed, as you posted already, it does not 8-(



I didn't try pkg clean -a before pkg install -R -f firefox before but 
just tried it now and indeed - doesn't work.

___
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: Firefox/GTK3 issue and reinstalling dependent ports

[Grzegorz Junka]

On 16/07/2017 12:45, Kurt Jaeger wrote:



I am using poudriere and wanted to track down which repository/option is
responsible for this issue. I created a new repository where I compiled
Firefox with all its dependencies with default options. But I don't know
how to reinstall Firefox with all its dependencies?

I tried:

pkg install -r firefox-test -R -f www/firefox
pkg upgrade -r firefox-test -f www/firefox

Both of them reinstall only the Firefox package. There is 241
dependencies when building Firefox with default options so it's kind of
difficult to reinstall all of them manually. How do I force to also
reinstall dependencies?

I know no way to do this which is not 'radical':

pkg clean -a

removes the cache. Then remove all packages (pkg delete -a) and
re-install firefox with

pkg install firefox



Thanks for your prompt response!
Will either pkg clean -a or pkg delete -a uninstall any of the installed 
ports? There is over 1000 of them and I wouldn't like to have to install 
all of them again from scratch.


I don't mind cleaning the cache and the database since the package 
repository is served over nginx from the same desktop.


Grzegorz
___
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"

Firefox/GTK3 issue and reinstalling dependent ports

[Grzegorz Junka]

This is a re-post from FreeBSD forum

Firefox on my computer expresses a weird UI issue where many controls 
are rendered without their borders. For example, radios or checkboxes 
can be selected but are invisible, since they have no border. Also 
selecting text doesn't highlight the selected part of the text. I can 
select and copy the selection even if the selection is invisible.


This was also happening with other applications that are using GTK3. 
Since I observed this issue I switched most of them back to GTK2 and the 
issue is gone, however the option to use GTK2 instead of GTK3 is not 
available in all of them, i.e. in gMTP and Firefox among others.


I am using poudriere and wanted to track down which repository/option is 
responsible for this issue. I created a new repository where I compiled 
Firefox with all its dependencies with default options. But I don't know 
how to reinstall Firefox with all its dependencies?


I tried:

pkg install -r firefox-test -R -f www/firefox
pkg upgrade -r firefox-test -f www/firefox

Both of them reinstall only the Firefox package. There is 241 
dependencies when building Firefox with default options so it's kind of 
difficult to reinstall all of them manually. How do I force to also 
reinstall dependencies?


Grzegorz

___
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] Why FreeBSD ports should have branches by OS version

[Grzegorz Junka]

On 27/06/2017 17:45, Mark Linimon wrote:

On Tue, Jun 27, 2017 at 09:24:31AM -0400, scratch65...@att.net wrote:

The number of ports to build a server-of-all-work is not large.

Now the problem is getting people to agree on exactly what that
subset is.


I think this part is fairly easy. We can start with ports for which 
maintainers agree to provide security fixes to the stable branch or 
artificially limit the number and ask people to vote for their 
favourites. Another point for consideration is to firstly consider ports 
with smaller amount of dependencies so that there is less work in 
maintaining them.

No one has ever done the work on "most minimal set of dependencies"
in the ports tree -- and that's because it's hard work.  Add to that
the fact that the technology has never supported partial checkouts
and it complicates things.


Yes, but you need to start somewhere. Otherwise it will remain as 
occasional rant. Clearly starting with 26,000 isn't an option. Then 
starting with small number of ports and learning how to overcome these 
difficulties is best we can do.



tl;dr: I do have long-time experience building subsets of the ports
tree and in my experience it's harder than people think, once you
get beyond a few dozen targets.



I think the hardest part is to agree on a set that is not too difficult 
to maintain but still useful so that people will try to actually install 
systems using them.


Grzegorz
___
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] Why FreeBSD ports should have branches by OS version

[Grzegorz Junka]

Are there any advantages of using pkg instead of pkgsrc on FreeBSD?
Instead of having branches by OS version, would having ports LTS branches
independent of the base system be a better solution?
Grzegorz

It looks like you might have misunderstood something I said about pkgsrc.

I use pkg with FreeBSD ports on FreeBSD, but my interest in pkgsrc and 
pkgsrc-synth is for NetBSD.

Working with pkgsrc on NetBSD convinces me that they need to import portupgrade 
and/or portmaster from FreeBSD, maybe synth will be better?

Pkgsrc is awkward dealing with packages whose names have changes or branched.

Ports LTS branches, is that Long Term Service?  I don't really understand that 
question.

Tom



First question: Sorry, I used a mental shortcut without explaining. I 
imagined that because both pkg and pkgsrc support FreeBSD, the effort of 
maintaining both could be combined, and pkgsrc seemed to be superior 
since it also supports other OSes. I also assumed that that has been 
considered before. So, because pkg hasn't been replaced by pkgsrc, there 
must be some advantages of using pkg on FreeBSD as opposed to using 
pkgsrc. My question was about these.


LTS indeed is Long Term Support. In short, there is a branch (or 
branches) not tied to any specific OS release but can be dependent on a 
specific OS release (e.g. 11.0 as minimum) in which application versions 
don't change as often as in the current branch. It would mostly 
incorporate security fixes. Now, a question if the versions shouldn't 
change for the duration of the LTS branch or if small version changes 
are allowed is a secondary issue. What I am trying to determine if 
having that branch/es would fulfil the requirement of many people on 
this list of having a more stable ports tree (where branches by OS 
versions was one of the proposed solutions).


Grzegorz
___
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] Why FreeBSD ports should have branches by OS version

[Grzegorz Junka]

Fine. Considering that maintainers already apply patches to the latest
quarterly branch. If there were to be OS version branches, it would
mean that maintainers apart from what they are doing now would
additionally need to apply selected patches to those OS version
branches?

"OS version branches" would be a complete waste of time and resources, and it
would remove some level of separation/independence between the base and ports.
The crux of the problem here is so called "stable ports", not necessarily
tying them to the life cycle of a base release. It doesn't make sense to tie
version of a port to the base release. Especially with the new releng support
schedule that would mean 5 years per major version which is quite a lot.

(snip)

I personally can't see the rationale of many OS version branches of ports: far 
too much work.

I had the thought of something like that for (NetBSD) pkgsrc: a very tall 
order, considering that pkgsrc has been ported to many OSes besides NetBSD.

Imagine a separate branch of pkgsrc for every version and branch of NetBSD, 
FreeBSD, Linux, etc.

I only follow the current branch of FreeBSD ports and pkgsrc, though now I have 
also become interested in pkgsrc-synth.

Tom



Are there any advantages of using pkg instead of pkgsrc on FreeBSD?

Instead of having branches by OS version, would having ports LTS 
branches independent of the base system be a better solution?


Grzegorz
___
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] Why FreeBSD ports should have branches by OS version

[Grzegorz Junka]

Can't you just create the branch yourself? It's open source. You just 
clone it and can keep it in Github for free. Then you can apply 
security patches to just the applications you need yourself. If it's 
too difficult you can hire people to apply just specific patches. 
With Github pull requests it's deadly easy. I am sure that if you 
asked maintainers to do the patching for a financial incentive they 
would mind doing it.
I actually explained it..  We do not have the people who understand 
all those ports.
if there is a port hat gets a fix, one assumes there is a maintainer 
who at least understands that port a bit.

I would feel more comfortable if they made the fix.
Having said that I do think tat we do need to pony up some cash at 
some stage.. and many others should too

if we want to have something like this. I've said this elsewhere.


Fine. Considering that maintainers already apply patches to the latest 
quarterly branch. If there were to be OS version branches, it would mean 
that maintainers apart from what they are doing now would additionally 
need to apply selected patches to those OS version branches? Considering 
there would be, say, 3 latest version branches, and that 30% of the 
patches that go to the latest branch would need to also be ported to the 
OS version branches, that would roughly mean twice as much work as today?

Grzegorz
___
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] Why FreeBSD ports should have branches by OS version

[Grzegorz Junka]

On 23/06/2017 12:32, Baho Utot wrote:



On 06/23/17 07:48, RW via freebsd-ports wrote:

On Thu, 22 Jun 2017 22:03:35 -0400
Baho Utot wrote:



The pre-compiled packages is what drove me to build the entire system
as it gave me a broken system that would not work and upon getting it
to function would/**/spontaneous reboot.  My hand built packages
stopped that.

I have built run LFS for 10 years.  I created a packaging system
using rpm for LFS ( it is on github ) .  I worked for turbolinux as a
beta tester and worked with the folks that kept KDE3 alive, so I am
some one that knows something.


And yet you do seem quite exceptionally accident prone.


Oh gee more insults,  is that all you have?

I guess that is encourgement for me to help FreeBSD.  NOT.

I see many posts about FreeBSD needing help and new help leaving just 
as fast.  I wonder why when there is no incentive to work with others 
how that works.  Ya name calling helps.


I think you explained well enough what changes/improvements in 
maintaining of the ports tree you would like to see. Can you be more 
precise what help and from whom you would need in order to implement it?

Grzegorz
___
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] Why FreeBSD ports should have branches by OS version

[Grzegorz Junka]

On 23/06/2017 03:58, Julian Elischer wrote:

On 23/6/17 6:36 am, Miroslav Lachman wrote:

scratch65...@att.net wrote on 2017/06/23 00:15:

[Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon
 wrote:


On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote:

My problem is that my industry experience tells me that reducing
the frequency of port releases is practically *guaranteed* to be
a Really Good Thing for everyone.


I remember before we had the quarterly releases, and people on the
mailing lists complained constantly about the ports bits only being
available once per release, or rolling with -head.


Mark, I can only suppose that those complainers are dilettantes
of some sort who believe that having The Latest-And-Greatest Bits
is a social-status enhancer.  **Nobody** with real work to do
ever willingly fools away time "fixing" what isn't broken.


And this is where you are so wrong. Ports tree is never in the state 
where everything works and has no bugs. (and cannot be, because 
upstreams have bugs) Even if it compiles and installs it does not 
mean that it is not broken and nobody needs newer version.
Just because your needs are different than others doesn't mean others 
are dilettantes.


The usage of the word dilettante can have negative connotations but he 
is in essential facts correct.


I have spent 30 years on BSD systems in industry, and we almost NEVER 
want the latest and greatest (except at project start time).

What we want is:
  A "recent" starting point for our next project/upgrade to start from
and an ongoing version of that, which will get critical fixes only for 
at LEAST 2 years, probably 5.

The key here is the *_*critical fixes only*_* part.

We do NOT want:
A new version of perl, python, ssh, shell openssl (*), apache, 
named, etc. etc.
The less changes the better.  Basically if it doesn't have a CVE 
number or it isn't actually completely broken,

then don't upgrade it in that branch.
We'll fix it ourselves if we need it bad enough (and feed back 
changes if we know it would be taken).


(*) From my experience, the best way to cope with openssl is to have 
everything link with
the system openssl and issue security upgrades to the base OS that 
upgrades that when there is a need.

(this may change, but it's been my experience so far).

The recent starting point doesn't even need to be 100.00% working.
What we will do here is mirror it and from the mirror, put it into our 
own source control branch/tree where we will add our own changes to 
fix/tailor what we need.
We will then keep merging in fixes from upstream. which usually will 
not collide with our private changes/fixes.

From that we generate our required packages.
From our perspective, a yearly branch (6 months would be 'ideal' but 
12 would work) that gets only *critical *fixes would be wonderful.
Remember that from the time when a product major release is planned to 
when it comes out is usually 6 to 12 months lead time.
So when it hits the customer's racks,  the packages were usually 
generated somewhere mid-cycle and are already 6 months old.
We will not be replacing them on the customer premises machine until 
they elect to do/purchase an upgrade / patch release.
which may be in a year or two. Certainly for a minor update it is 
rarely less than 6 months.
It'd have to be a heartbleed scale security issue to get customers to 
do an upgrade earlier.


Can't you just create the branch yourself? It's open source. You just 
clone it and can keep it in Github for free. Then you can apply security 
patches to just the applications you need yourself. If it's too 
difficult you can hire people to apply just specific patches. With 
Github pull requests it's deadly easy. I am sure that if you asked 
maintainers to do the patching for a financial incentive they would mind 
doing it.


Grzegorz
___
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] Why FreeBSD ports should have branches by OS version

[Grzegorz Junka]

On 22/06/2017 23:16, Baho Utot wrote:

On 6/22/2017 6:36 PM, Miroslav Lachman wrote:

scratch65...@att.net wrote on 2017/06/23 00:15:

[Default] On Thu, 22 Jun 2017 16:11:26 -0500, Mark Linimon
 wrote:


On Thu, Jun 22, 2017 at 12:32:45PM -0400, scratch65...@att.net wrote:

My problem is that my industry experience tells me that reducing
the frequency of port releases is practically *guaranteed* to be
a Really Good Thing for everyone.


I remember before we had the quarterly releases, and people on the
mailing lists complained constantly about the ports bits only being
available once per release, or rolling with -head.


Mark, I can only suppose that those complainers are dilettantes
of some sort who believe that having The Latest-And-Greatest Bits
is a social-status enhancer.  **Nobody** with real work to do
ever willingly fools away time "fixing" what isn't broken.


And this is where you are so wrong. Ports tree is never in the state 
where everything works and has no bugs. (and cannot be, because 
upstreams have bugs) Even if it compiles and installs it does not 
mean that it is not broken and nobody needs newer version.
Just because your needs are different than others doesn't mean others 
are dilettantes.




That is just an argument to not do anything, by default.

Here is my point, I am a user that installs an OS ( FreeBSD-11.0). 
Then builds the base from releng-11.0.  Followed by building the ports 
I need.  That doesn't give me a usable system always. Should I not be 
able to do the above and expect a stable system? If not I am running 
the wrong OS/system.  Updates are another monster as I do not want to 
place my now running system ( finally stable ) and do this all over 
again.  I am not up for that.  Hell FreeBSD can not even boot my dual 
boot system Win7 and FreeBSD 11.0 on zfs raid without going to BIOS 
and selecting the disk to boot from.  No one here could point me to 
how to set it up using grub as a boot loader!  The only information I 
got was to wing it using half baked information.


A user would probably start with precompiled packages. Only power users 
who know what they are doing would try to compile the packages 
themselves, and at that point I would expect them to know a thing or two 
about verifying that they compile and work fine.

Grzegorz
___
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] Why FreeBSD ports should have branches by OS version

[Grzegorz Junka]

On 22/06/2017 15:50, scratch65...@att.net wrote:

[Default] On Thu, 22 Jun 2017 15:38:53 +0100, Matthew Seaman
 wrote:


On 2017/06/22 15:03, scratch65...@att.net wrote:

Why don't the same choices apply here?  What am I missing?

Two things:

  1) It's progress in the development of the FreeBSD base system that
drives the release cycle.  The general state of the ports does not exert
much influence on release frequency -- nor should it.

Still not getting it, I'm afraid.How often does the base
system undergo such drastic architecture changes that existing
ports won't run under it?  I haven't really been monitoring the
situation, but I'd guess it's very seldom if only because such an
architectural change is a cursëd big job that can hardly ever be
justfied.

I'd guess that most adults for whom systems are tools not toys
are not too dissimilar to me:  I want to *use* my tools, not
spend time replacing them every quarter or even every year.  As
long as they do the job and don't compromise the system, they're
fine by me.  I have apps running under Win7 that were written for
W2K (and in one case NT, iirc), and they're just as useful today
as they were then.  They do the job: why in the name of sanity
should I replace them?



Not sure how you use your tools or in which industry you work. Take 
front-end development for example. Chrome is releasing a new version 
every couple of days. Sure, I don't upgrade every release, but when I am 
developing a website, I want to test using the same version that my 
customers are using, which is the latest, since Chrome on Windows 
updates itself automatically. The same with new versions of Firefox. 
Often new versions of browsers require new versions of libraries to 
support new features (CSS/JavaScript). That requires new versions of 
compiler and transpilers. They may, in turn, require an updated version 
of node or npm.


Take server-side development as another example. Erlang is releasing a 
new version of OTP every couple of weeks. Sure, I don't need a new 
version when supporting an old application, but I may need one when 
starting a new application. Especially that many libraries that I am 
going to use won't support Erlang older than a specific version.


A similar story with C++ development, where the standard is being 
constantly developed and compilers are adding these features every 
release. Again, you may not need these new features, but a library that 
you need to use may require the new version.


 No matter how long you are going to maintain a specific version of 
ports with locked down versions of applications, there will surely come 
a time when you will need to upgrade. And for every user that time will 
be different. The current model is in my opinion the most common 
denominator - we can't maintain multiple branches with past versions so 
lets try to properly maintain one with current versions.


Grzegorz
___
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: Is pkg quarterly really needed?

[Grzegorz Junka]

On 21/04/2017 02:51, Kurt Jaeger wrote:



If the whole repository builds doesn't it mean by default that any
subset also builds?

If we defined a repo build only as valid if everything builds,
the whole repo is never valid, because approx. 10% of
the ports tree breaks at any given time. More, if you add options.


That's an interesting observation, I didn't know that. Does it mean that 
the quarterly port tree is no better or worse than the main branch? And 
is any tree ever build with non-default options? If no, how do you know 
how many are failing in that case?



My assumption was that only version
upgrades are progressed from CURRENT to STABLE to RELEASE.

Leads to a stagnating tree downstream, if you find maintainers for it.
That's the model Debian is using, and it has other issues. Especially
the load for the maintainers is huge, and users are unhappy
that the packages are getting old. Debian has approx. 6 times
more committers than we have, when I last looked, and more maintainers.

If we take from that that we have to grow our committer base, yes.
Can we reason that unless we have that base, we can't follow that
model ? Maybe.


Well, they can't be as unhappy as, say, Centos, where packages are 
really old. Also, I bet not all users are unhappy when the ports are not 
updated quickly. Corporate users tend to prefer stable versions even if 
they are getting a bit old, enthusiasts tend to prefer newest versions. 
FreeBSD can't cater for both groups a the same time. Which group has 
been chosen, if it has been chosen? Are we defaulting to enthusiasts?


Grzegorz
___
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: Is pkg quarterly really needed?

[Grzegorz Junka]

Hi :)

On 20/04/2017 19:57, Kurt Jaeger wrote:

Hi!


I understand that the main problem with quarterly branches is that they
start from an unstable edge and mature with time, then after three
months at the most mature point they are being deleted and replaced with
a new unstable edge. So, there is no good point of reference to use as a
source of packages.

First, let me say that for my use cases, the pkg tree is in consistent
state most of the time. We have a set of approx. 2500 pkg's build etc,
so roughly 10% of the full repo. We update the ports tree and build the
repo every week, just to see if all is fine, and we update
and build, if we need a package we do not yet have in our repo.
For the thrills, look at our repo at https://repo.nepustil.net


I am maintaining four sets of pkg's for my desktop, laptop and server 
(in two variants) - anything between 100 to 1300 pkg's resulted from 
selecting around 10-200 ports depending on the set. I usually first 
build for my desktop, then if everything is fine I rebuild the set for 
my laptop, and finally the server. I hardly remember a single upgrade to 
the longest set that didn't result in some packages being broken. Sure, 
most of those breakages resulted from me selecting non-standard options 
(but if I wanted standard options then I would simply install from the 
official distribution, wouldn't I?). Only last weekend I filled two bugs 
against ports that didn't compile when either non-default options were 
selected in those packages or in some of their dependent packages.


So, my experience is quite different to yours...


Hmm, let's try this thought experiment.

For each package, keep the whole repo when it was last build sucessfully
(Note: we're not yet discussing whether it runs!)

Worst case: We have n ports and n repos. The question is:
what would be the average case ? Would that be a sustainable model ?

Now, the next question: Even if we have all the repos,
would we find *one* repo where *two* packagew we'd like to have
are in a consistent (build-!)state ? What about the 250+
that are normally needed for a small server ? Or the 1200+
for a multi-role server (some will say: "nah, don't do it, use
container/jails/ whatever virtualisiation").


If the whole repository builds doesn't it mean by default that any 
subset also builds? All packages are build incrementally, the packages 
that don't depend on any other packages are build first, then any 
packages that depend on them, and so on. Sure, it doesn't mean that they 
also run properly, but that's a different story. If packages are build 
then people can install them and fill bugs. That would be the reason for 
having CURRENT, STABLE and RELEASE where fixes would be gradually 
progressed between them.



What I described is taking the good points (maturing the code through
progressing version upgrades from CURRENT, through STABLE to RELEASE)

Now, if we have ports-HEAD, and changes to that (especially fixes and
features to the ports infrastructure), it's getting more and more difficult
to backport fixes from ports-HEAD to the ports-STABLE versions, because
those do not contain dependencies and infrastructure changes.
If we backport those, we have to roll forward some other
changes. This gets out of hand very quickly.


I see where you are getting at. My assumption was that only version 
upgrades are progressed from CURRENT to STABLE to RELEASE. If a port 
can't be progressed because it requires infrastructure change then, 
well, it won't. STABLE and then RELEASE are meant to be more stable so 
we would prefer older versions that work rather than new versions that 
break. Infrastructure changes would have to be progressed eventually but 
that could be done in batches where most fixes in more edge branches 
have been fixed.



So:

If we take the sum of the brain time our maintainers and committers
deliver to keep HEAD in a moving (different from a stagnating) state,
and try to estimate how much *more* time would be needed to
keep additional trees in working conditions, only updating
what is needed, under the assumption that infrastructure changes
*need* to happen ? What would that additional brain time be ?
My inituition tells me that it would probably break the model.


On the other hand developers would be more inclined to do changes in 
CURRENT if they know that they are not going to break ports for the 
majority of users who should use STABLE or RELEASE. According to the 
principle "Failing by design 
". They would be also more 
confident when porting changes to more stable branches knowing that they 
have been tested by many users and if something could have gone wrong 
most likely already did.




Now, if someone wants to *experiment* with that, we
already have quite a few people doing that: By setting up
our own repo boxes, where we build the trees to our liking.


I am not trying to solve the problem for myself. I already have my own 
repo box. I 

Re: Is pkg quarterly really needed?

[Grzegorz Junka]

On 20/04/2017 17:11, Kurt Jaeger wrote:

Hi!


Fine, but would that be a good approach? Doesn't it look more like a
process change than a code change?

For me, it does not look like a process-change only.

I haven't thought through all the details, I'm going with my
intuition here (because thinking it through takes a long time).

One number: I made approx. 40 commits to quarterly trees in 2 years,
and broke it one least once, probably more often. Go to

https://secure.freshbsd.org/search?committer=pi

and then limit the view to the 8 quarterlies and check those commits.
It might as well be my sloppiness, but...


Surely, some code would need to be
changed but then again, wouldn't that be mostly configuration?

My gut feeling says it's more than a little change and a bit
of configuration.



I understand that the main problem with quarterly branches is that they 
start from an unstable edge and mature with time, then after three 
months at the most mature point they are being deleted and replaced with 
a new unstable edge. So, there is no good point of reference to use as a 
source of packages.


What I described is taking the good points (maturing the code through 
progressing version upgrades from CURRENT, through STABLE to RELEASE) 
while keeping good builds as reference points (monthly in CURRENT since 
it changes more often and partial builds may be too often for the server 
to handle, fortnightly in STABLE, and weekly in RELEASE since it is 
expected to contain least breaking changes and full builds are preferred 
over partial builds). Only X last builds would be kept for each of these 
three branches. From that short description it should be more or less 
obvious if that approach is better/doable when opposed to quarterly 
branches?


Grzegorz
___
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"