Re: [new] www/geckodriver
On Wed, Sep 26, 2018 at 04:15:16PM -0600, Aaron Bieber wrote: > Hi! > > Here is a port of Mozilla's geckodriver. > > geckodriver is a "proxy" that allows W3C WebDriver compatible clients to > diddle Gecko-based web browsers. > > It lets one use things like Selenium to test web pages in an automated way. > > I went back and forth on adding www/mozilla-firefox as a RUN_DEP.. This port > doesn't have it. > > DESCR: > Proxy for using W3C WebDriver compatible clients to interact with > Gecko-based > browsers. > > This program provides the HTTP API described by the WebDriver protocol to > communicate with Gecko browsers, such as Firefox. It translates calls into > the > Firefox remote protocol by acting as a proxy between the local- and remote > ends. > > Clue sticks? This is my first rust port. Looks good, COMMENT lacks an o on Gecko. As for the RDEP, does it work without firefox installed (ie with a different gecko browser ?) or with a remote instance with remote something enabled ?
NEW: inputmethods/fcitx-qt5
Hi, fcitx-qt5 is Qt5 IM module for fcitx. I can now use fcitx in x11/lxqt. ok? fcitx-qt5.tgz Description: application/gtar-compressed
[new] www/geckodriver
Hi! Here is a port of Mozilla's geckodriver. geckodriver is a "proxy" that allows W3C WebDriver compatible clients to diddle Gecko-based web browsers. It lets one use things like Selenium to test web pages in an automated way. I went back and forth on adding www/mozilla-firefox as a RUN_DEP.. This port doesn't have it. DESCR: Proxy for using W3C WebDriver compatible clients to interact with Gecko-based browsers. This program provides the HTTP API described by the WebDriver protocol to communicate with Gecko browsers, such as Firefox. It translates calls into the Firefox remote protocol by acting as a proxy between the local- and remote ends. Clue sticks? This is my first rust port. Cheers, Aaron -- PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE geckodriver.tgz Description: Binary data
Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]
On 2018/09/26 12:28, Chris Bennett wrote: > I was about to file a bug report, perhaps this is relevant here? > > This was happening also on a recent snap before this one. > > Using spectrwm, my windows freeze up until I go yo another screen and > back. For example, cat file or ls -la show screen output, but no > scrolling with mouse until I switch screens back and forth. > Same for firefox, etc. It's not going to be related to the current topic of today's commit to KERN_CPTIME2. The spectrwm port was updated recently (9 September) so I'd expect it's probably related to that. > > OpenBSD 6.4-beta (GENERIC.MP) #325: Tue Sep 25 22:24:42 MDT 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 4077236224 (3888MB) > avail mem = 3944398848 (3761MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xdbb33000 (45 entries) > bios0: vendor LENOVO version "5PCN20WW" date 01/15/2018 > bios0: LENOVO 80XV > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP UEFI HPET APIC MCFG SBST SSDT MSDM BATB SSDT SSDT > IVRS CRAT VFCT SSDT FPDT SSDT BGRT UEFI > acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP2(S4) GPP3(S4) GPP4(S4) GFX0(S4) > GFX1(S4) GFX2(S4) GFX3(S4) GFX4(S4) XHC0(S3) EHC1(S3) SBAZ(S4) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpihpet0 at acpi0: 14318180 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 16 (boot processor) > cpu0: AMD A9-9420 RADEON R5, 5 COMPUTE CORES 2C+3G, 2994.81 MHz, 15-70-00 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,XSAVEOPT > cpu0: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line > 16-way L2 cache > cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative > cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, IBE > cpu1 at mainbus0: apid 17 (application processor) > cpu1: AMD A9-9420 RADEON R5, 5 COMPUTE CORES 2C+3G, 2994.39 MHz, 15-70-00 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,XSAVEOPT > cpu1: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line > 16-way L2 cache > cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative > cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu1: smt 1, core 0, package 0 > ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins, remapped > ioapic1 at mainbus0: apid 5 pa 0xfec01000, version 21, 32 pins, remapped > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf800, bus 0-63 > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (GPP0) > acpiprt2 at acpi0: bus -1 (GPP1) > acpiprt3 at acpi0: bus 1 (GPP2) > acpiprt4 at acpi0: bus 2 (GPP3) > acpiprt5 at acpi0: bus -1 (GPP4) > acpiprt6 at acpi0: bus -1 (GFX0) > acpiprt7 at acpi0: bus -1 (GFX1) > acpiprt8 at acpi0: bus -1 (GFX2) > acpiprt9 at acpi0: bus -1 (GFX3) > acpiprt10 at acpi0: bus -1 (GFX4) > acpiec0 at acpi0 > acpicpu0 at acpi0: C2(0@400 io@0x814), C1(@1 halt!), PSS > acpicpu1 at acpi0: C2(0@400 io@0x814), C1(@1 halt!), PSS > acpipwrres0 at acpi0: P0U3, resource for XHC0 > acpipwrres1 at acpi0: P3U3, resource for XHC0 > acpipwrres2 at acpi0: P0U2, resource for EHC1 > acpipwrres3 at acpi0: P3U2, resource for EHC1 > acpipwrres4 at acpi0: P0SD > acpipwrres5 at acpi0: P3SD > acpipwrres6 at acpi0: P0ST, resource for SATA > acpipwrres7 at acpi0: P3ST, resource for SATA > acpibtn0 at acpi0: PWRB > acpicmos0 at acpi0 > acpibat0 at acpi0: BAT0 model "L16L2PB2" serial 3458 type LiP oem "LGC" > "VPC2004" at acpi0 not configured > acpiac0 at acpi0: AC unit online > acpibtn1 at acpi0: LID_ > "PNP0C14" at acpi0 not configured > "AMD0030" at acpi0 not configured > "AMD0010" at acpi0 not configured > "ELAN060C" at acpi0 not configured > acpivideo0 at acpi0: VGA_ > acpivideo1 at acpi0: VGA_ > acpivideo2 at acpi0: VGA_ > cpu0: 2994 MHz: speeds: 3000 2700 2400 2100 1800 1400 MHz > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "AMD AMD64 15h Root Complex" rev 0x00 > "AMD AMD64 15h IOMMU" rev 0x00 at pci0 dev 0 function 2 not configured > vendor "ATI", unkn
Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]
I was about to file a bug report, perhaps this is relevant here? This was happening also on a recent snap before this one. Using spectrwm, my windows freeze up until I go yo another screen and back. For example, cat file or ls -la show screen output, but no scrolling with mouse until I switch screens back and forth. Same for firefox, etc. OpenBSD 6.4-beta (GENERIC.MP) #325: Tue Sep 25 22:24:42 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4077236224 (3888MB) avail mem = 3944398848 (3761MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xdbb33000 (45 entries) bios0: vendor LENOVO version "5PCN20WW" date 01/15/2018 bios0: LENOVO 80XV acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI HPET APIC MCFG SBST SSDT MSDM BATB SSDT SSDT IVRS CRAT VFCT SSDT FPDT SSDT BGRT UEFI acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP2(S4) GPP3(S4) GPP4(S4) GFX0(S4) GFX1(S4) GFX2(S4) GFX3(S4) GFX4(S4) XHC0(S3) EHC1(S3) SBAZ(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 16 (boot processor) cpu0: AMD A9-9420 RADEON R5, 5 COMPUTE CORES 2C+3G, 2994.81 MHz, 15-70-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,XSAVEOPT cpu0: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line 16-way L2 cache cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 17 (application processor) cpu1: AMD A9-9420 RADEON R5, 5 COMPUTE CORES 2C+3G, 2994.39 MHz, 15-70-00 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,XSAVEOPT cpu1: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line 16-way L2 cache cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 1, core 0, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins, remapped ioapic1 at mainbus0: apid 5 pa 0xfec01000, version 21, 32 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (GPP0) acpiprt2 at acpi0: bus -1 (GPP1) acpiprt3 at acpi0: bus 1 (GPP2) acpiprt4 at acpi0: bus 2 (GPP3) acpiprt5 at acpi0: bus -1 (GPP4) acpiprt6 at acpi0: bus -1 (GFX0) acpiprt7 at acpi0: bus -1 (GFX1) acpiprt8 at acpi0: bus -1 (GFX2) acpiprt9 at acpi0: bus -1 (GFX3) acpiprt10 at acpi0: bus -1 (GFX4) acpiec0 at acpi0 acpicpu0 at acpi0: C2(0@400 io@0x814), C1(@1 halt!), PSS acpicpu1 at acpi0: C2(0@400 io@0x814), C1(@1 halt!), PSS acpipwrres0 at acpi0: P0U3, resource for XHC0 acpipwrres1 at acpi0: P3U3, resource for XHC0 acpipwrres2 at acpi0: P0U2, resource for EHC1 acpipwrres3 at acpi0: P3U2, resource for EHC1 acpipwrres4 at acpi0: P0SD acpipwrres5 at acpi0: P3SD acpipwrres6 at acpi0: P0ST, resource for SATA acpipwrres7 at acpi0: P3ST, resource for SATA acpibtn0 at acpi0: PWRB acpicmos0 at acpi0 acpibat0 at acpi0: BAT0 model "L16L2PB2" serial 3458 type LiP oem "LGC" "VPC2004" at acpi0 not configured acpiac0 at acpi0: AC unit online acpibtn1 at acpi0: LID_ "PNP0C14" at acpi0 not configured "AMD0030" at acpi0 not configured "AMD0010" at acpi0 not configured "ELAN060C" at acpi0 not configured acpivideo0 at acpi0: VGA_ acpivideo1 at acpi0: VGA_ acpivideo2 at acpi0: VGA_ cpu0: 2994 MHz: speeds: 3000 2700 2400 2100 1800 1400 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD AMD64 15h Root Complex" rev 0x00 "AMD AMD64 15h IOMMU" rev 0x00 at pci0 dev 0 function 2 not configured vendor "ATI", unknown product 0x98e4 (class display subclass VGA, rev 0xda) at pci0 dev 1 function 0 not configured azalia0 at pci0 dev 1 function 1 vendor "ATI", unknown product 0x15b3 rev 0x00: msi azalia0: no supported codecs pchb1 at pci0 dev 2 function 0 "AMD AMD64 15h Host" rev 0x00 ppb0 at pci0 dev 2 function 3 "AMD AMD64 15h PCIE" rev 0x00: msi pci1 at ppb0 bus 1 vendor "Atheros", unknown product 0x0042 (class network s
Re: KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]
On 2018/09/26 19:16, Stuart Henderson wrote:
> N.B. "Ports using KERN_CPTIME2 will need to be updated."
>
> This is likely to cause a bunch of breakage in things reporting CPU stats
> and time is very short to fix them before release.
>
> If you look after ports that do this, get onto a kernel with this change
> (very new commit so it probably won't be in snaps quite just yet) and
> test ASAP.
Some starting points for investigation,
assorted mozillas
collectd
conky
go
htop
libgtop2
net-snmp
node
pgtop
py-psutil
libuv (+ embedded copies, at least in cmake, maybe more)
zabbix
>
>
>
> - Forwarded message from Scott Soule Cheloha -
>
> From: Scott Soule Cheloha
> Date: Wed, 26 Sep 2018 11:23:13 -0600 (MDT)
> To: source-chan...@openbsd.org
> Subject: CVS: cvs.openbsd.org: src
>
> CVSROOT: /cvs
> Module name: src
> Changes by: chel...@cvs.openbsd.org 2018/09/26 11:23:13
>
> Modified files:
> sys/kern : kern_sched.c kern_sysctl.c
> sys/sys: sched.h
> usr.bin/systat : cpu.c vmstat.c
> usr.bin/top: display.c display.h machine.c machine.h top.c
>
> Log message:
> KERN_CPTIME2: set ENODEV if the CPU is offline.
>
> This lets userspace distinguish between idle CPUs and those that are
> not schedulable because hw.smt=0.
>
> A subsequent commit probably needs to add documentation for this
> to sysctl.2 (and perhaps elsewhere) after the dust settles.
>
> Also included here are changes to systat(1) and top(1) that account
> for the ENODEV case and adjust behavior accordingly:
>
> - systat(1)'s cpu view prints placeholder marks ('-') instead of
> percentages for each state if the given CPU is offline.
>
> - systat(1)'s vmstat view checks for offline CPUs when computing the
> machine state total and excludes them, so the CPU usage graph
> only represents the states for online CPUs.
>
> - top(1) does not draw CPU rows for offline CPUs when the view is
> redrawn. If CPUs "go offline", percentages for each state are
> replaced by placeholder marks ('-'); the view will need to be
> redrawn to remove these rows. If CPUs "go online" the view will
> need to be redrawn to show these new CPUs. In "combined CPU" mode,
> the count and the state totals only represent online CPUs.
>
> Ports using KERN_CPTIME2 will need to be updated. The changes
> described above to make systat(1) and top(1) aware of the ENODEV
> case *and* gracefully handle a changing HW_NCPUONLINE while the
> application is running are not necessarily appropriate for each
> and every port.
>
> The changes described above are so extensive in part to demonstrate
> one way a program *might* be made robust to changing CPU availability.
> In particular, changing hw.smt after boot is an extremely rare event,
> and this needs to be weighed when updating ports.
>
> The logic needed to account for the KERN_CPTIME2 ENODEV case is
> very roughly:
>
> if (sysctl(...) == -1) {
> if (errno != ENODEV) {
> /* Actual error occurred. */
> } else {
> /* CPU is offline. */
> }
> } else {
> /* CPU is online and CPU states were set by sysctl(2). */
> }
>
> Prompted by deraadt@. Basic idea for ENODEV from kettenis@. Discussed at
> length with kettenis@. Additional testing by tb@.
>
> No complaints from hackers@ after a week.
>
> ok kettenis@, "I think you should commit [now]" deraadt@
>
>
> - End forwarded message -
>
Re: Remove net/wireless
Hi Gregor Can you write a note in security/wpa_supplicant's README, so users can know what the hint is? Thanks! -peter On 2018 Sep 26 (Wed) at 18:58:13 +0200 (+0200), Gregor Best wrote: : :Hi, : :with the recent(-ish) introduction of `ifconfig $dev join $nwid`, :net/wireless became quite obsolete. : :The only thing that it does that the current implementation of :autojoining in the kernel can't (yet?) do is kicking wpa_supplicant :after associating with an 802.1X network. That can be done manually by :running `wpa_cli reassoc` once the network has been associated with. : :I'd like to propose removing net/wireless, so that it won't clutter 6.4s :ports tree/package collection by doing something that the kernel can do :by itself 95% of the time. : :-- : Gregor -- Every program is a part of some other program, and rarely fits.
KERN_CPTIME2 [chel...@openbsd.org: CVS: cvs.openbsd.org: src]
N.B. "Ports using KERN_CPTIME2 will need to be updated."
This is likely to cause a bunch of breakage in things reporting CPU stats
and time is very short to fix them before release.
If you look after ports that do this, get onto a kernel with this change
(very new commit so it probably won't be in snaps quite just yet) and
test ASAP.
- Forwarded message from Scott Soule Cheloha -
From: Scott Soule Cheloha
Date: Wed, 26 Sep 2018 11:23:13 -0600 (MDT)
To: source-chan...@openbsd.org
Subject: CVS: cvs.openbsd.org: src
CVSROOT:/cvs
Module name:src
Changes by: chel...@cvs.openbsd.org 2018/09/26 11:23:13
Modified files:
sys/kern : kern_sched.c kern_sysctl.c
sys/sys: sched.h
usr.bin/systat : cpu.c vmstat.c
usr.bin/top: display.c display.h machine.c machine.h top.c
Log message:
KERN_CPTIME2: set ENODEV if the CPU is offline.
This lets userspace distinguish between idle CPUs and those that are
not schedulable because hw.smt=0.
A subsequent commit probably needs to add documentation for this
to sysctl.2 (and perhaps elsewhere) after the dust settles.
Also included here are changes to systat(1) and top(1) that account
for the ENODEV case and adjust behavior accordingly:
- systat(1)'s cpu view prints placeholder marks ('-') instead of
percentages for each state if the given CPU is offline.
- systat(1)'s vmstat view checks for offline CPUs when computing the
machine state total and excludes them, so the CPU usage graph
only represents the states for online CPUs.
- top(1) does not draw CPU rows for offline CPUs when the view is
redrawn. If CPUs "go offline", percentages for each state are
replaced by placeholder marks ('-'); the view will need to be
redrawn to remove these rows. If CPUs "go online" the view will
need to be redrawn to show these new CPUs. In "combined CPU" mode,
the count and the state totals only represent online CPUs.
Ports using KERN_CPTIME2 will need to be updated. The changes
described above to make systat(1) and top(1) aware of the ENODEV
case *and* gracefully handle a changing HW_NCPUONLINE while the
application is running are not necessarily appropriate for each
and every port.
The changes described above are so extensive in part to demonstrate
one way a program *might* be made robust to changing CPU availability.
In particular, changing hw.smt after boot is an extremely rare event,
and this needs to be weighed when updating ports.
The logic needed to account for the KERN_CPTIME2 ENODEV case is
very roughly:
if (sysctl(...) == -1) {
if (errno != ENODEV) {
/* Actual error occurred. */
} else {
/* CPU is offline. */
}
} else {
/* CPU is online and CPU states were set by sysctl(2). */
}
Prompted by deraadt@. Basic idea for ENODEV from kettenis@. Discussed at
length with kettenis@. Additional testing by tb@.
No complaints from hackers@ after a week.
ok kettenis@, "I think you should commit [now]" deraadt@
- End forwarded message -
Re: Remove net/wireless
I was a very happy net/wireless user, though without 802.1X. I'm ok with removal for 6.4. On September 26, 2018 12:58:13 PM EDT, Gregor Best wrote: > >Hi, > >with the recent(-ish) introduction of `ifconfig $dev join $nwid`, >net/wireless became quite obsolete. > >The only thing that it does that the current implementation of >autojoining in the kernel can't (yet?) do is kicking wpa_supplicant >after associating with an 802.1X network. That can be done manually by >running `wpa_cli reassoc` once the network has been associated with. > >I'd like to propose removing net/wireless, so that it won't clutter >6.4s >ports tree/package collection by doing something that the kernel can do >by itself 95% of the time. > >-- > Gregor -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: New: py-http_ece
On Wed, 26 Sep 2018 09:55:25 -0400, Brian Callahan wrote: > Hi Stuart -- > > On 09/26/18 05:19, Stuart Henderson wrote: > > On 2018/09/25 21:15, Pamela Mosiejczuk wrote: > >> There are no tests included, but the regression test structure is > >> not empty. Per off-list discussion with bcallah@ and danj@, I've > >> nonetheless set NO_TEST=Yes, as running 'make test' with python2 > >> downloads a flake8 package through pip. > > flake8 should be set as a test dependency. If it's already > > installed then this should stop it from being downloaded at test > > time. > > This was my advice. However, flake8 being installed doesn't entirely > stop it from being downloaded. > If you run > env FLAVOR=python3 make test > then flake8 will not be downloaded (provided you already have it > installed). However, > make test > will still download a python2 pip of flake8, even if flake8 is > installed. Indeed. > So my guess is there needs to be some patch for that, though I > haven't had the time to look at it. Sure we could patch the setup.py to remove the tdep on flake8. But there's no test shipped in the tgz anyway, so patching it would make no sense imho (other than giving Pamela a reason to practice patching ;)). The tgz provided by Pamela is ok danj@ Cheers, Daniel
Remove net/wireless
Hi, with the recent(-ish) introduction of `ifconfig $dev join $nwid`, net/wireless became quite obsolete. The only thing that it does that the current implementation of autojoining in the kernel can't (yet?) do is kicking wpa_supplicant after associating with an 802.1X network. That can be done manually by running `wpa_cli reassoc` once the network has been associated with. I'd like to propose removing net/wireless, so that it won't clutter 6.4s ports tree/package collection by doing something that the kernel can do by itself 95% of the time. -- Gregor signature.asc Description: PGP signature
Re: [NEW] security/ssss
On 2018/09/26 16:53, Solene Rapenne wrote:
> Denis Fondras wrote:
> > is an implementation of Shamir's Secret Sharing Scheme. The program
> > suite
> > does both: the generation of shares for a known secret, and the
> > reconstruction
> > of a secret using user-provided shares.
> >
> > http://point-at-infinity.org//
>
> hello
>
> portcheck reports hardcoded paths in Makefile and port-lib-depend-check
> reports
> missing c in WANTLIB
>
> here is a diff to your makefile to fix it
>
> ok solene@ with the diff applied
>
> thank you for porting this, seems very useful :)
>
>
> --- Makefile.orig Wed Sep 26 16:50:25 2018
> +++ MakefileWed Sep 26 16:51:01 2018
> @@ -14,10 +14,10 @@
>
> MASTER_SITES= http://point-at-infinity.org//
>
> -WANTLIB += gmp
> +WANTLIB += c gmp
> LIB_DEPENDS = devel/gmp
>
> -MAKE_FLAGS= CC="${CC} -I/usr/local/include -L/usr/local/lib"
> +MAKE_FLAGS= CC="${CC} -I${LOCALBASE}/include -L${LOCALBASE}/lib"
>
> ALL_TARGET=-split -combine
>
>
Please zap the trailing . in COMMENT, and reorder lines according to
Makefile.template.
Also it needs to be taught to honour CFLAGS, currently it hardcodes -O2,
and avoid stripping if DEBUG is set.
Re: [NEW] security/ssss
Denis Fondras wrote:
> is an implementation of Shamir's Secret Sharing Scheme. The program suite
> does both: the generation of shares for a known secret, and the reconstruction
> of a secret using user-provided shares.
>
> http://point-at-infinity.org//
hello
portcheck reports hardcoded paths in Makefile and port-lib-depend-check reports
missing c in WANTLIB
here is a diff to your makefile to fix it
ok solene@ with the diff applied
thank you for porting this, seems very useful :)
--- Makefile.orig Wed Sep 26 16:50:25 2018
+++ MakefileWed Sep 26 16:51:01 2018
@@ -14,10 +14,10 @@
MASTER_SITES= http://point-at-infinity.org//
-WANTLIB += gmp
+WANTLIB += c gmp
LIB_DEPENDS = devel/gmp
-MAKE_FLAGS= CC="${CC} -I/usr/local/include -L/usr/local/lib"
+MAKE_FLAGS= CC="${CC} -I${LOCALBASE}/include -L${LOCALBASE}/lib"
ALL_TARGET=-split -combine
Re: WIP: Spectrwm-Pledge
On Tue 25/09/2018 09:07, Gonzalo L. Rodriguez wrote:
> Hello,
>
> Upstream Spectrwm is working on a pledge version, test are welcome.
>
> Diff attached.
I think you missed a pledge:
Sep 26 15:54:30 zeus /bsd: spectrwm[24210]: pledge "getpw", syscall 33
> +@@ -12499,6 +12508,9 @@ main(int argc, char *argv[])
> + pwd = getpwuid(getuid());
> + if (pwd == NULL)
> + errx(1, "invalid user: %d", getuid());
> ++
> ++if (pledge("stdio rpath proc exec", NULL) == -1)
I believe it should be added here ^^^
Also, Makefile should mention that the port uses pledge().
I've been running with the diff below (your diff + fixes for above
mentioned issues) for the last couple of hours without any issues so
far.
diff --git Makefile Makefile
index d7f8c5cf637..d481b33b520 100644
--- Makefile
+++ Makefile
@@ -10,6 +10,7 @@ GH_ACCOUNT= conformal
GH_PROJECT=spectrwm
DISTNAME= ${GH_PROJECT}-${V}
CATEGORIES=x11
+REVISION= 0
HOMEPAGE= https://github.com/conformal/spectrwm/
MAINTAINER=Gonzalo L. R.
@@ -17,8 +18,9 @@ MAINTAINER= Gonzalo L. R.
# BSD
PERMIT_PACKAGE_CDROM= Yes
-WANTLIB += X11 X11-xcb Xcursor Xft c util xcb xcb-util xcb-icccm
-WANTLIB += xcb-keysyms xcb-randr xcb-xtest
+# uses pledge()
+WANTLIB += X11 X11-xcb Xcursor Xft c util xcb xcb-icccm xcb-keysyms
+WANTLIB += xcb-randr xcb-util xcb-xinput xcb-xtest
NO_TEST= Yes
diff --git patches/patch-Makefile patches/patch-Makefile
index 238f490df4f..f1141d885ee 100644
--- patches/patch-Makefile
+++ patches/patch-Makefile
@@ -8,7 +8,7 @@ Index: Makefile
#CFLAGS+=-DSWM_DENY_CLOCK_FORMAT
CPPFLAGS+= -I${X11BASE}/include -I${X11BASE}/include/freetype2
-LDADD+=-lutil -L${X11BASE}/lib -lX11 -lX11-xcb -lxcb-util -lxcb-icccm
-lxcb-keysyms -lxcb-randr -lxcb-xtest -lXft -lXcursor
-+LDADD+=-lutil -L${X11BASE}/lib -lX11 -lX11-xcb -lxcb -lxcb-util -lxcb-icccm
-lxcb-keysyms -lxcb-randr -lxcb-xtest -lXft -lXcursor
++LDADD+=-lutil -L${X11BASE}/lib -lX11 -lX11-xcb -lxcb-util -lxcb-icccm
-lxcb-keysyms -lxcb-randr -lxcb-xinput -lxcb-xtest -lXft -lXcursor
BUILDVERSION != sh "${.CURDIR}/buildver.sh"
.if !${BUILDVERSION} == ""
CPPFLAGS+= -DSPECTRWM_BUILDSTR=\"$(BUILDVERSION)\"
diff --git patches/patch-spectrwm_c patches/patch-spectrwm_c
index 9a28b0131bb..71c99bbbdc0 100644
--- patches/patch-spectrwm_c
+++ patches/patch-spectrwm_c
@@ -2,7 +2,26 @@ $OpenBSD: patch-spectrwm_c,v 1.9 2018/09/09 14:00:00 gonzalo
Exp $
Index: spectrwm.c
--- spectrwm.c.orig
+++ spectrwm.c
-@@ -291,7 +291,7 @@ uint32_t swm_debug = 0
+@@ -54,6 +54,9 @@
+ #include
+ #include
+ #include
++#if !defined(__OpenBSD__)
++#include "pledge.h"
++#endif
+ #include
+ #include
+ #include
+@@ -75,7 +78,7 @@
+ #include
+ #include
+ #include
+-#if defined(__linux__) || defined(__FreeBSD__)
++#if defined(__linux__) || defined(__FreeBSD__) || defined(__OpenBSD__)
+ #include
+ #define SWM_XCB_HAS_XINPUT
+ #endif
+@@ -291,7 +294,7 @@ uint32_t swm_debug = 0
#define SWM_CONF_KEYMAPPING (1)
#ifndef SWM_LIB
@@ -11,3 +30,33 @@ Index: spectrwm.c
#endif
char **start_argv;
+@@ -3880,6 +3883,9 @@ spawn(int ws_idx, union arg *args, bool close_fd)
+ if (args == NULL || args->argv[0] == NULL)
+ return;
+
++ if (pledge("stdio proc exec", NULL) == -1)
++ err(1, "pledge");
++
+ DNPRINTF(SWM_D_MISC, "%s\n", args->argv[0]);
+
+ close(xcb_get_file_descriptor(conn));
+@@ -12469,6 +12475,9 @@ main(int argc, char *argv[])
+ if (setlocale(LC_CTYPE, "") == NULL || setlocale(LC_TIME, "") == NULL)
+ warnx("no locale support");
+
++ if (pledge("stdio rpath proc exec getpw dns unix", NULL) == -1)
++ err(1, "pledge");
++
+ /* handle some signals */
+ bzero(&sact, sizeof(sact));
+ sigemptyset(&sact.sa_mask);
+@@ -12499,6 +12508,9 @@ main(int argc, char *argv[])
+ pwd = getpwuid(getuid());
+ if (pwd == NULL)
+ errx(1, "invalid user: %d", getuid());
++
++ if (pledge("stdio rpath proc exec getpw", NULL) == -1)
++ err(1, "pledge");
+
+ xcb_grab_server(conn);
+ xcb_aux_sync(conn);
Re: New: py-http_ece
Hi Stuart -- On 09/26/18 05:19, Stuart Henderson wrote: On 2018/09/25 21:15, Pamela Mosiejczuk wrote: There are no tests included, but the regression test structure is not empty. Per off-list discussion with bcallah@ and danj@, I've nonetheless set NO_TEST=Yes, as running 'make test' with python2 downloads a flake8 package through pip. flake8 should be set as a test dependency. If it's already installed then this should stop it from being downloaded at test time. This was my advice. However, flake8 being installed doesn't entirely stop it from being downloaded. If you run env FLAVOR=python3 make test then flake8 will not be downloaded (provided you already have it installed). However, make test will still download a python2 pip of flake8, even if flake8 is installed. So my guess is there needs to be some patch for that, though I haven't had the time to look at it. ~Brian
Re: sylpheed crashing/asserting in libX11 on poll_for_event
> that would be great. BTW, I'm several more crashes clever and the crash > always happen during the "Mark as read" action. The sequence of step is: > > - click on mailing list folder > - select all unread emails > - right-click to invoke context menu > - select Mark -> Mark as read action (-> CRASH) > Unable to reproduce. > Sure, happy to help. First of all, my sylpheed on OBSD is just a MUA > connected to gmail email/folders. I do have it set to > fetch emails from > time to time (here may be race -- or one possible case) and I'm usually > working in a way to (i) open > email folder, (ii) go thourough it read interesting and then (iii) select > everything (iv) mark everything selected as read > and (v) delete everything. > The crash usually happen on either (iv) or (v), mostly on (iv). I'm just not > sure if in the same time sylpheed has not > started its cycle to refresh folderrs/reread emails. Unable to reproduce. I also have gmail with sylpheed for this account, and I set the auto-fetch interval to 10 min. Sylpheed is rock solid for me with yesterday's snapshot. Thanks
Re: update: lang/rust 1.29.1 (security)
On Wed, Sep 26, 2018 at 02:13:47PM +0200, Sebastien Marie wrote: > On Tue, Sep 25, 2018 at 04:53:54PM +0100, Stuart Henderson wrote: > > > > > > A possible way could be: > > > - having a sub-package -libstd on lang/rust (which would be empty or > > > almost) > > > - add RUN_DEPENDS+=lang/rust,-libstd to port using rustc > > > > > > when lang/rust is updated, the subpackage rust-libstd will automatically > > > crank, and so the signature of packages with RUN_DEPENDS will change, > > > and pkg_add -u will update. Does it make sens ? The drawback would be to > > > manually maintain the RUN_DEPENDS, but it is low overhead and one-time > > > only. > > > > This would work, it feels a little 'dirty' but not too bad. There's a > > similar problem in lang/go fwiw. If this is done via RUN_DEPENDS, > > then PKGSPEC can be used to force updates when needed, without having > > to bump dependent ports. > > > > But for the immediate case, just bumping them makes sense for now, > > I don't think we'll have time for anything more complex. > > > > The following diff tries to implement it. > > Several parts: > - new subpackage lang/rust,-staticlib (with empty PLIST) > > - module devel/cargo will add (by default, but it is overridable) > RUN_DEPENDS += lang/rust,-staticlib > > - for ports not using the module add an explicit RUN_DEPENDS > > - every impacted port (directly by RUN_DEPENDS addition or indirectly > by devel/cargo usage) is bumped > > I did a quick test with ripgrep. When I modify lang/rust version (with > REVISION++), the packaging of ripgrep seems to correctly incoporate the > change: > > ===> Building package for ripgrep-0.8.1p2 > Create > /home/semarie/repos/openbsd/ports/packages/amd64/all/ripgrep-0.8.1p2.tgz > Creating package ripgrep-0.8.1p2 > /home/semarie/repos/openbsd/ports/plist/amd64/ripgrep-0.8.1p2 was > updated > lang/rust,-staticlib:rust-staticlib-*:rust-staticlib-1.29.1p0 -> > lang/rust,-staticlib:rust-staticlib-*:rust-staticlib-1.29.1p1 > Link to > /home/semarie/repos/openbsd/ports/packages/amd64/ftp/ripgrep-0.8.1p2.tgz > Link to > /home/semarie/repos/openbsd/ports/packages/amd64/cdrom/ripgrep-0.8.1p2.tgz > After thought, I think it shouldn't be commited as it. So the diff is mostly for "demonstration" that it should work. A proper fix would be to have a STATICLIB_DEPENDS and lets the infrastructure to make it part of the signature, without the need of a empty package. And we could add it gradually in ports. For lang/rust, it would STATICLIB_DEPENDS to devel/llvm, as it uses libLLVM.a and its compoments. So a change on devel/llvm would be noticed, and the Rust compiler updated. I think it could have value in several area. But it is too late for 6.4 anyway. So we have time to think about it. Thanks. -- Sebastien Marie
Re: update: lang/rust 1.29.1 (security)
On Tue, Sep 25, 2018 at 04:53:54PM +0100, Stuart Henderson wrote:
> >
> > A possible way could be:
> > - having a sub-package -libstd on lang/rust (which would be empty or almost)
> > - add RUN_DEPENDS+=lang/rust,-libstd to port using rustc
> >
> > when lang/rust is updated, the subpackage rust-libstd will automatically
> > crank, and so the signature of packages with RUN_DEPENDS will change,
> > and pkg_add -u will update. Does it make sens ? The drawback would be to
> > manually maintain the RUN_DEPENDS, but it is low overhead and one-time
> > only.
>
> This would work, it feels a little 'dirty' but not too bad. There's a
> similar problem in lang/go fwiw. If this is done via RUN_DEPENDS,
> then PKGSPEC can be used to force updates when needed, without having
> to bump dependent ports.
>
> But for the immediate case, just bumping them makes sense for now,
> I don't think we'll have time for anything more complex.
>
The following diff tries to implement it.
Several parts:
- new subpackage lang/rust,-staticlib (with empty PLIST)
- module devel/cargo will add (by default, but it is overridable)
RUN_DEPENDS += lang/rust,-staticlib
- for ports not using the module add an explicit RUN_DEPENDS
- every impacted port (directly by RUN_DEPENDS addition or indirectly
by devel/cargo usage) is bumped
I did a quick test with ripgrep. When I modify lang/rust version (with
REVISION++), the packaging of ripgrep seems to correctly incoporate the
change:
===> Building package for ripgrep-0.8.1p2
Create
/home/semarie/repos/openbsd/ports/packages/amd64/all/ripgrep-0.8.1p2.tgz
Creating package ripgrep-0.8.1p2
/home/semarie/repos/openbsd/ports/plist/amd64/ripgrep-0.8.1p2 was
updated
lang/rust,-staticlib:rust-staticlib-*:rust-staticlib-1.29.1p0 ->
lang/rust,-staticlib:rust-staticlib-*:rust-staticlib-1.29.1p1
Link to
/home/semarie/repos/openbsd/ports/packages/amd64/ftp/ripgrep-0.8.1p2.tgz
Link to
/home/semarie/repos/openbsd/ports/packages/amd64/cdrom/ripgrep-0.8.1p2.tgz
Thanks
--
Sebastien Marie
Index: devel/cbindgen/Makefile
===
RCS file: /cvs/ports/devel/cbindgen/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- devel/cbindgen/Makefile 25 Sep 2018 21:16:37 - 1.4
+++ devel/cbindgen/Makefile 26 Sep 2018 12:00:37 -
@@ -5,7 +5,7 @@ COMMENT = C bindings generator from rus
GH_ACCOUNT = eqrion
GH_PROJECT = cbindgen
GH_TAGNAME = v0.6.3
-REVISION = 0
+REVISION = 1
CATEGORIES = devel
Index: textproc/ripgrep/Makefile
===
RCS file: /cvs/ports/textproc/ripgrep/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- textproc/ripgrep/Makefile 25 Sep 2018 21:16:37 - 1.10
+++ textproc/ripgrep/Makefile 26 Sep 2018 12:00:41 -
@@ -5,7 +5,7 @@ COMMENT = line oriented search tool usi
GH_ACCOUNT = BurntSushi
GH_PROJECT = ripgrep
GH_TAGNAME = 0.8.1
-REVISION = 1
+REVISION = 2
CATEGORIES = textproc sysutils
Index: www/firefox-esr/Makefile
===
RCS file: /cvs/ports/www/firefox-esr/Makefile,v
retrieving revision 1.82
diff -u -p -r1.82 Makefile
--- www/firefox-esr/Makefile25 Sep 2018 21:16:37 - 1.82
+++ www/firefox-esr/Makefile26 Sep 2018 11:37:53 -
@@ -7,7 +7,7 @@ MOZILLA_VERSION = 60.2.1esr
MOZILLA_BRANCH = release
MOZILLA_PROJECT = firefox
MOZILLA_CODENAME = browser
-REVISION = 0
+REVISION = 1
WRKDIST = ${WRKDIR}/${MOZILLA_DIST}-${MOZILLA_DIST_VERSION:C/esr//}
HOMEPAGE = https://www.mozilla.org/firefox/organizations/
@@ -43,6 +43,8 @@ MOZILLA_USE_BUNDLED_HUNSPELL = Yes
BUILD_DEPENDS += lang/rust
# stylo build needs LLVM
BUILD_DEPENDS += devel/llvm
+
+RUN_DEPENDS += lang/rust,-staticlib
WANTLIB += X11-xcb Xcursor Xi fribidi intl xcb xcb-shm ${COMPILER_LIBCXX}
Index: www/mozilla-firefox/Makefile
===
RCS file: /cvs/ports/www/mozilla-firefox/Makefile,v
retrieving revision 1.361
diff -u -p -r1.361 Makefile
--- www/mozilla-firefox/Makefile25 Sep 2018 21:16:37 - 1.361
+++ www/mozilla-firefox/Makefile26 Sep 2018 11:38:26 -
@@ -9,7 +9,7 @@ MOZILLA_VERSION = 62.0.2
MOZILLA_BRANCH = release
MOZILLA_PROJECT = firefox
MOZILLA_CODENAME = browser
-REVISION = 0
+REVISION = 1
WRKDIST = ${WRKDIR}/${MOZILLA_DIST}-${MOZILLA_DIST_VERSION:C/b[0-9]*//}
HOMEPAGE = https://www.mozilla.org/firefox/
@@ -48,6 +48,8 @@ BUILD_DEPENDS += lang/rust
BUILD_DEPENDS += devel/llvm
# 61 requires both versions of python
Re: sylpheed crashing/asserting in libX11 on poll_for_event
Hi Amit, that would be great. BTW, I'm several more crashes clever and the crash always happen during the "Mark as read" action. The sequence of step is: - click on mailing list folder - select all unread emails - right-click to invoke context menu - select Mark -> Mark as read action (-> CRASH) Thanks! Karel On Tue, 25 Sep 2018 14:16:36 -0500 Amit Kulkarni wrote: > Hey Karel, > Sorry for not getting back to you on the weekend. I will try to take a > look tonight. > > Thanks > On Tue, Sep 25, 2018 at 10:43 AM Karel Gardas wrote: > > > > > > I've switched off Autocheck new email sometime ago and the crash still > > happen. Was able to obtain 2 same cores/backtraces today. > > > > Karel > > > > On Thu, 20 Sep 2018 15:03:10 +0200 > > Karel Gardas wrote: > > > > > On Thu, 20 Sep 2018 14:48:27 +0200 > > > Karel Gardas wrote: > > > > > > > > That's so far what I have observed. As the crashes started to be more > > > > regural on the latest -current/-beta, I'll keep my eye on that and if > > > > anything more concrete surface, I'll let you know. > > > > > > Two more details: the interval to fetch emails is set to 10 minutes and > > > I'm using imap/ssl to access gmail.com. > > > > > > As I see it now and with what Matthieu wrote in mind, it may be actually > > > a race condition between me/interactive select of all messages and then > > > marking them as read and between fetch of new messages. > > > > > > Thanks! > > > Karel > > > > > > > -- Karel Gardas
Re: NEW: sysutils/bfs
Brian Callahan wrote:
> Hi ports --
>
> Attached is a new port, sysutils/bfs. bfs is a breadth-first version of
> the UNIX find command.
>
> ---
> pkg/DESCR:
> bfs is a variant of the UNIX find command that operates breadth-first
> rather than depth-first. It is otherwise intended to be compatible with
> many versions of find, including:
>
> * POSIX find
> * GNU find
> * {Free,Open,Net}BSD find
> * macOS find
> ---
>
> Works fine here. If it's too close to 6.4, that's fine I'll just revive
> it afterwards.
>
> OK?
>
> ~Brian
works fine, I tested a few commands and I can replace bfs by find with same
results. I tried to compare speed and they provide roughly same execution time.
Port seems fine to me.
ok solene :)
Re: New: py-http_ece
On 2018/09/25 21:15, Pamela Mosiejczuk wrote: > There are no tests included, but the regression test structure is not empty. > Per off-list discussion with bcallah@ and danj@, I've nonetheless set > NO_TEST=Yes, as running 'make test' with python2 downloads a flake8 package > through pip. flake8 should be set as a test dependency. If it's already installed then this should stop it from being downloaded at test time.
[wip] xi editor
Hi, here's a wip for xi-core, a 'new' editor written in rust with a clear separation between frontend & backend, using RPC, cf https://xi-editor.github.io/xi-editor/ for the concepts. For the frontends, i've only ported xi-term & xi-gtk, cf https://github.com/eyelash/xi-gtk & https://github.com/xi-frontend/xi-term - xi-gtk doesnt seem to 'really work' with a systemwide install of xi-core but i havent looked much. xi-term basic features seems to work. hope this can be a starting point for a real port once this stuff stabilizes.. Landry xi.tgz Description: application/tar-gz
