Re: Firefox bug: 66.0.3 disables all extensions
On Sat, May 04, 2019 at 07:01:55PM +0100, Anthony Campbell wrote: > After upgrading Firefox today to 66.0.3 in -current, all my add-ons > were inactivated. A quick search showed that this is a widespread > problem, apparently due to a bug in FF. I was able to fix it > temporarily by means of a suggestion on ghacks.net to change > > xpinstall.signatures.required > > in about.config to "false". > > Presumably it will be fixed soon upstream. Disabling signature checks is almost always a bad idea. Open this url with firefox and install the extension. https://storage.googleapis.com/moz-fx-normandy-prod-addons/extensions/hotfix-update-xpi-intermediate%40mozilla.com-1.0.2-signed.xpi -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Firefox bug: 66.0.3 disables all extensions
On 04.05.19 20:01, Anthony Campbell wrote: > After upgrading Firefox today to 66.0.3 in -current, all my add-ons > were inactivated. A quick search showed that this is a widespread > problem, apparently due to a bug in FF. I was able to fix it > temporarily by means of a suggestion on ghacks.net to change > > xpinstall.signatures.required > > in about.config to "false". > > Presumably it will be fixed soon upstream. More information can be found here: https://bugzilla.mozilla.org/show_bug.cgi?id=1548973 https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/ Citing the blog: There are a number of work-arounds being discussed in the community. These are not recommended as they may conflict with fixes we are deploying.
new CPAN Smoker release for OpenBSD 6.5
Hello folks, I just release a new version of the custom Perl CPAN smoker on OpenBSD 6.5 as a Vagrant box: https://app.vagrantup.com/arfreitas/boxes/openbsd-6.5-cpan-smoker Regards, Alceu
Firefox bug: 66.0.3 disables all extensions
After upgrading Firefox today to 66.0.3 in -current, all my add-ons were inactivated. A quick search showed that this is a widespread problem, apparently due to a bug in FF. I was able to fix it temporarily by means of a suggestion on ghacks.net to change xpinstall.signatures.required in about.config to "false". Presumably it will be fixed soon upstream. -- Anthony Campbellhttp://www.acampbell.uk
Re: Upgrade procedure (6.4 -> 6.5)
On Sat, May 04, 2019 at 01:07:34AM -0400, Nick Holland wrote:
On 5/3/19 2:32 PM, Strahil Nikolov wrote:
On May 3, 2019 10:49:55 PM GMT+03:00, Nick Holland
wrote:
On 5/2/19 1:52 AM, Consus wrote:
[ ... ]
I tried to update a VM (stock setup) with a 10 GB disk from 6.4 to
6.5 and thus it seemed that booting from the 6.5 DVD will do the
trick. Sadly the installer never checked the avalable space , but
just started to do it's stuff until reporting that not enough space
is available.
A default Fedora installation here is using 39GB from a whole disk
(no VM), after two or three years of using it, with a a few upgrades
in between. Now admittedly there a few big files in that sum. But even
if I count those big ones off I'd assume that a default install or
upgrade of any OS (Windows, Linux, whatever ...) on a disk with just
10(!) GB might be just a little, little bit too small: and it takes no
installer to tell me that ... ;)
[ ... ]
And ... considering the number of times I've seen and heard about Linux
systems hose themselves with upgrades, I question your implication.
Major Linux upgrade? Most people I know just say "Screw it. Rebuild,
reload".
Even on that Fedora Linux from where I'm writing this, it takes a
bit of preparation for a major upgrade: like close down X, the DM,
move to a console, start (as an example) some tmux, and from there
start very specific steps to upgrade. To just believe one can press an
upgrade button in Fedora and hope this will work is akin to asking for
trouble right on my knees ... ;)
But I admit, Fedora users might be to lured into this
"just-press-the-upgrade-button" easily - not being sure why this is
so ...
[ .. ]
Why did the installer allow installation despite the available space
is low ( even windows checks available space :) )???
see above ... ;)
Here comes my favorite part:
OpenBSD has what I call a "Learning Curb". You gotta lift your feet.
Not a lot, it's not hard, but you can't just shuffle along mindlessly
and expect to be carried to the next level without your engaging your brain
Well: it is hard. It takes time to learn. Tho' no university grades
being needed to succeed in that, I think.
If you used Linux for a little bit and figured that OpenBSD is "just
like Linux, but different", yeah, no, you are going to be disappointed.
Different beast.
From a management perspective, I'd say Linux and Windows are much
more alike than Linux and OpenBSD.
+1
Linux is written for and by those frustrated with Windows
("Reinventing Windows, poorly"). OpenBSD is Unix. It's probably the
simplest Unix out there to use and manage, but it's not Windows (or
Linux).
Or... Think of Linux (and windows) as the big cushy luxury car.
Easy to drive, assuming you work within the anticipated parameters,
but you really have no idea what's going on under the hood. "you
aren't supposed to". That's the design goal, and it works pretty
well...until it doesn't.
again: +1
OpenBSD is more like a semi-primative small car with tight
suspension and a stick-shift trans. It's got antilock brakes, but for
the most part, it assumes you know what you are doing when you get
behind the wheel. When it gets a little wonky, you pop the hood, look
around, see what's not right. Grab a couple tools from the trunk
(included!) fix it, and be back on the road before the guy in the Luxury
car has figured out how to call for a tow truck.
Spend a little time learning OpenBSD,
Yes: time needed, I think: Took me a while until I got that ... :)
and you will find you can make it do amazing things.
Nick.
Thanks, and Regards,
Wolfgang
Today's snapshot, amd64: >70% spin during subsequent pkg_add -u
I've been a little slack in upgrading my laptop lately, so the jump from the previous snap may have been approximately a week. But anyway, upgrading with sysupgrade went as it should, in the expected handsoff fasion. But then when I set the machine to do the package upgrade (doas pkg_add -vVuUm FWIW), everything and anything running with the xfce environment became extremely sluggish. After a while I fired up top and saw that we had essentially no CPU idle, but 'spin' was fluctuating in the range 70 to approximately 85 percent, with the fans going more intensely than I can remember since configuring apmd (which runs with -aA). What are the most useful steps to diagnosing here? dmesg attached as a starting point. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. OpenBSD 6.5-current (GENERIC.MP) #3: Fri May 3 23:06:13 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34247041024 (32660MB) avail mem = 33199075328 (31661MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7d317000 (42 entries) bios0: vendor American Megatrends Inc. version "1.05.05" date 04/27/2017 bios0: Notebook U831 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG SSDT FIDT SSDT HPET SSDT UEFI SSDT SSDT LPIT WSMT SSDT SSDT DBGP DBG2 BGRT DMAR TPM2 ASF! acpi0: wakeup devices PXSX(S4) RP21(S4) PXSX(S4) RP22(S4) PXSX(S4) RP23(S4) PXSX(S4) RP24(S4) PXSX(S4) RP17(S4) PXSX(S4) RP18(S4) PXSX(S4) RP19(S4) PXSX(S4) RP20(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 3481.56 MHz, 06-8e-09 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 23MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 3491.84 MHz, 06-8e-09 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 3491.84 MHz, 06-8e-09 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 3491.84 MHz, 06-8e-09 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 2399 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1
Re: Upgrade procedure (6.4 -> 6.5)
On May 4, 2019 10:11:07 AM GMT+03:00, Nick Holland wrote: >On 5/3/19 2:32 PM, Strahil Nikolov wrote: >> On May 3, 2019 10:49:55 PM GMT+03:00, Nick Holland >> wrote: >>> On 5/2/19 1:52 AM, Consus wrote: Hi, I've upgraded my systems from 6.4 to 6.5 without a glitch, but I see that /etc/networks and some other files (like malloc.conf.5) are >>> still present, although there is no use for them in the new release. Is there a reason why these files are not listed in "FIles to >>> remove"? Is there a way to track them? It's not like something gonna break, >>> but old configuration files (and manual pages) lying around can make someone's life harder during the debug session. >>> >>> There is no promise that an upgraded machine will be file-for-file >>> identical to a fresh install. Here is the list of problems this >>> might cause you, as you can see, it's a long list and quite >>> horrible: >>> >>> * If you use the same hw for 20 years, you might run out of disk >>> space? >>> >>> Ok, not very long and not very horrible. >>> >>> You are trying to solve a non-problem. And sometimes, 'specially >>> on an upgraded machine, it's great to see how things WERE when the >>> machine was set up. If you really care, go ahead, delete stuff. >>> >>> Nick. >> >> Hi All, >> >> As I linux guy (my experience in openBSD can be easily measured in >> days) I can share the view of less experienced user that was planing >> to upgrade from 6.4 to 6.5 and that eneded with a full reinstall. >> >> I tried to update a VM (stock setup) with a 10 GB disk from 6.4 to >> 6.5 and thus it seemed that booting from the 6.5 DVD will do the >> trick. Sadly the installer never checked the avalable space , but >> just started to do it's stuff until reporting that not enough space >> is available. > >The installer didn't check. Neither did you. Let's blame the >installer. Well, O can't presict how big are the new tars's size -yet the updater shoulddo that. If my /usr is too small - it should make the calculation for me and refuse to update. How do you estinate how much space do you need for the update ? Get the iso and extract each archive to predict that ? Nah let's blame the newbie. >Ok, sure, might be nice, but when there are a snootload of different >platforms with radically different size binaries, it's not trivial. Well, if it's done in linux , its doable in openBSD. >But >feel free to send in a patch. Test on two or three different >platforms, >first, though, please. I would, if I find some time... which is currently my most precious resource. >And ... considering the number of times I've seen and heard about Linux >systems hose themselves with upgrades, I question your implication. >Major Linux upgrade? Most people I know just say "Screw it. Rebuild, >reload". Linux might have the edge on incremental upgrades, but >eventually, you are going to need to move to the more current >release...and then OpenBSD starts looking REALLY GOOD. Maybe you haven't used RHEL or SUSE - they both support major upgrade (Red Hat released the tool for migration from 6 to 7. Check the release notes for RHEL 7.5) >10g disk? When I first started working with OpenBSD, that was really >big. But then, I had to manually partition the disk. 20 years later, >10G is tiny. The installer auto-partioner is really intended for >bigger >disks. Yeah, you are in "Special Case" territory, which isn't a good >spot to be as a new user. If I'm so special, then where was the warning of the installer in the first place? Just a short notice like 'You have a very small disk and upgrades might not be supported!' would be enough to keep my mouth shut. Still, there was no such warning in the first place. >> Why did the installer allow installation despite the available space >> is low ( even windows checks available space :) )??? > >The average windows user doesn't know what the units of storage mean. Yet, we are not windows users :) Are we ? openBSD is great, but it needs some improvement s and that's what I was trying to imply here, not to criticize. >> Why should the end-user delete old unnecessary/problematic files ? > >That's my question. What's the big deal? On a modern disk, just >ignore >them. They won't be a problem until long after your rotate out the hw. >Problem is, you used a 2001 vintage size disk. You should have rotated >that out around 2005. I saw that at least the man pages will be wrong if I keep them - and of course this will cause issues in the future. >And I'm curious how a CentOS 6 to Centos 7 upgrade would go on a 10G >disk. I have my suspicions, and I suspect it would be entertaining to >watch...assuming it wasn't something you were dependent upon. I'm quite active in the CentOS forum and I can assure you that the tool that Red Hat use has no maintainers and thus it doesn't work. The community will be happy if become a maintainer and start working
Re: umb0 ucom0 umodem0 detached
On 03.05.2019 17:07, Malte Wedel wrote: Hello Misc, I have OpenBSD running on a Thinkpad X1 Carbon, 3rd Gen, everything is working great, except for the builtin 4G modem "umb0" which detaches and disappears from time to time and needs a reboot to become available again. I found this thread which seems to be exactly my issue: http://openbsd-archive.7691.n7.nabble.com/Re-Current-197-Nov-5-umb0-ucom0-umodem0-detached-td330969.html For the record, this can be better worked around with a sleep/resume cycle, no need to reboot.
Re: Upgrade procedure (6.4 -> 6.5)
On 04/05/2019 07:07, Nick Holland wrote:
On 5/3/19 2:32 PM, Strahil Nikolov wrote:
On May 3, 2019 10:49:55 PM GMT+03:00, Nick Holland
wrote:
On 5/2/19 1:52 AM, Consus wrote:
Hi,
I've upgraded my systems from 6.4 to 6.5 without a glitch, but I
see that /etc/networks and some other files (like malloc.conf.5)
are
still
present, although there is no use for them in the new release.
Is there a reason why these files are not listed in "FIles to
remove"?
Is there a way to track them? It's not like something gonna
break,
but
old configuration files (and manual pages) lying around can make
someone's life harder during the debug session.
There is no promise that an upgraded machine will be file-for-file
identical to a fresh install. Here is the list of problems this
might cause you, as you can see, it's a long list and quite
horrible:
* If you use the same hw for 20 years, you might run out of disk
space?
Ok, not very long and not very horrible.
You are trying to solve a non-problem. And sometimes, 'specially
on an upgraded machine, it's great to see how things WERE when the
machine was set up. If you really care, go ahead, delete stuff.
Nick.
Hi All,
As I linux guy (my experience in openBSD can be easily measured in
days) I can share the view of less experienced user that was planing
to upgrade from 6.4 to 6.5 and that eneded with a full reinstall.
I tried to update a VM (stock setup) with a 10 GB disk from 6.4 to
6.5 and thus it seemed that booting from the 6.5 DVD will do the
trick. Sadly the installer never checked the avalable space , but
just started to do it's stuff until reporting that not enough space
is available.
The installer didn't check. Neither did you. Let's blame the installer.
Ok, sure, might be nice, but when there are a snootload of different
platforms with radically different size binaries, it's not trivial. But
feel free to send in a patch. Test on two or three different platforms,
first, though, please.
And ... considering the number of times I've seen and heard about Linux
systems hose themselves with upgrades, I question your implication.
Major Linux upgrade? Most people I know just say "Screw it. Rebuild,
reload". Linux might have the edge on incremental upgrades, but
eventually, you are going to need to move to the more current
release...and then OpenBSD starts looking REALLY GOOD.
10g disk? When I first started working with OpenBSD, that was really
big. But then, I had to manually partition the disk. 20 years later,
10G is tiny. The installer auto-partioner is really intended for bigger
disks. Yeah, you are in "Special Case" territory, which isn't a good
spot to be as a new user.
Why did the installer allow installation despite the available space
is low ( even windows checks available space :) )???
The average windows user doesn't know what the units of storage mean.
Why should the end-user delete old unnecessary/problematic files ?
That's my question. What's the big deal? On a modern disk, just ignore
them. They won't be a problem until long after your rotate out the hw.
Problem is, you used a 2001 vintage size disk. You should have rotated
that out around 2005.
And I'm curious how a CentOS 6 to Centos 7 upgrade would go on a 10G
disk. I have my suspicions, and I suspect it would be entertaining to
watch...assuming it wasn't something you were dependent upon.
Usually we do have package management system to take care of that (or
at least to rename those files in case we really need them).
Yeah, you need to wait until Linux "package management" screws itself
into a knot for you.
For me, system upgrade is a very complicated and error prone
procedure.
OpenBSD has what I call a "Learning Curb". You gotta lift your feet.
Not a lot, it's not hard, but you can't just shuffle along mindlessly
and expect to be carried to the next level without your engaging your brain
If you used Linux for a little bit and figured that OpenBSD is "just
like Linux, but different", yeah, no, you are going to be disappointed.
Different beast. From a management perspective, I'd say Linux and
Windows are much more alike than Linux and OpenBSD. Linux is written
for and by those frustrated with Windows ("Reinventing Windows,
poorly"). OpenBSD is Unix. It's probably the simplest Unix out there
to use and manage, but it's not Windows (or Linux).
Or... Think of Linux (and windows) as the big cushy luxury car. Easy
to drive, assuming you work within the anticipated parameters, but you
really have no idea what's going on under the hood. "you aren't
supposed to". That's the design goal, and it works pretty well...until
it doesn't. OpenBSD is more like a semi-primative small car with tight
suspension and a stick-shift trans. It's got antilock brakes, but for
the most part, it assumes you know what you are doing when you get
behind the wheel. When it gets a little wonky, you pop the hood, look
around, see what's not right. Grab a couple tools
