Comments
pdestefa
I think this is definitely better. Bug report log shows:
Generating backtrace
Backtrace is generated and saved, 93134 bytes
So, yes, I think this pkg version fixed the problem reported in BZ#2190050. However, it wasn't able to finish the report due to this error:
Looking for similar problems in bugzilla
fatal: RPC failed at server. The API key you specified has been revoked by the user that created it.
abrt-action-find-bodhi-update [ERROR] Search for duplicate bugs failed: None
('analyze_BodhiUpdates' exited with 2)
I'm very familiar with reporting bugs with ABRT, so I'm going to assume this is not correct behavior. But, I could be wrong. Someone else will need to determine.
Upgrade was smooth, no problems detected on restart.
Ah! Okay, I didn't understand what the text in this update meant. I found an update package on updates-testing.
However, my MWE still will not build, although the error is not related to fvextra, now. Since I only changed -pythontex and -fvextra pkgs, I'm worried one of them introduced some new problem. I see this now:
...
[1{/usr/share/texlive/texmf-dist/fonts/map/pdftex/updmap/pdftex.map}]
[2] (./standalone.aux)
kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 0+438/600 --dpi 438 txsys
mktexpk: don't know how to create bitmap font for txsys.
mktexpk: perhaps txsys is missing from the map file.
kpathsea: Appending font creation commands to missfont.log.
)
!pdfTeX error: pdflatex (file txsys): Font txsys at 438 not found
==> Fatal error occurred, no output PDF file produced!
==
... So, poking around a bit, I became suspicious of mktexpk and looked into updmap. I had some old .texlive/ directories, which I deleted, and I reran updmap systemwide. Does that sound right?
My MWE now builds and seems to look okay, although I'm worried why I had to rebuild the updmap.
I did remove R to install the package, but that didn't solve the problem with fvextra.sty missing. Did you really test it? I did.
During install of package, I get this error:
================================================================================================================ Package Arch Version Repository Size ================================================================================================================ Upgrading: texlive noarch 6:2016-48.20160520.fc28 @commandline 36 k texlive-base x86_64 7:20170520-38.fc28 @commandline 931 k
Transaction Summary
Upgrade 2 Packages
Total size: 967 k Is this ok [y/N]: y Downloading Packages: Running transaction check Transaction check succeeded. Running transaction test Error: Transaction check error: file /usr/share/texmf from install of texlive-base-7:20170520-38.fc28.x86_64 conflicts with file from package R-core-3.4.4-1.fc28.x86_64
Error Summary
Also, after upgrade, I still get this error from pdflatex: ! LaTeX Error: File `fvextra.sty' not found.
Cannot comment on CVEs, but this package no longer produces node warnings/indicators regarding old tor version and it is functional, AFAICT.
As reported by others, this does not fix bug 1462381.
Don't know about these particular bugs, but...
This package is generally functional (with local SELinux policies).
dnf local install worked. SELinux policy (3.13.1-191.13) prevents Tor from starting. However, with SELinux local policy overrides (or not enforcing), Tor seems to start okay.
Sorry, I was sure it was a problem with Tor, but it was bug 1357395. I'm now running this Tor pkg and it seems okay.
Fails to start. Error: OpenSSL version from headers does not match the version we're running with. ...
This is the same as previous tor pkg after release of openssl pkg openssl-1.0.2h-3.fc24.
FWIW, this breaks Tor.
Sorry, this build breaks WiFi interfaces after wake from sleep, at least for wlp2 devices. After wake, NM shows old SSID scan list and doesn't re-scan automatically nor even if WiFi is disabled and re-enabled.
BTW, what does "obsolete" mean if there isn't any succeeding version of this package?
Yes, thanks. This works for me, too.
Hmm, sorry. I pushed for this for several reasons but I didn't get a chance to test before it was pulled.
I'm surprised, though, since I built boincmgr and boinc client 7.6.23 from offical src back in February on F23. I had to fiddle a bit, but it worked. And, I just recently updated to 7.6.31 and that also worked. If there is a problem with service, it's not because the binary will not run. Also, 7.6 boincmgr does work and works much better, in fact, than 7.2 on my desktop.
Breaks sudo. PAM authentication error: Module is unknown
Breaks xscreensaver. -- Logs begin at Sat 2015-01-10 10:25:45 PST, end at Tue 2016-03-15 13:28:05 PDT. -- Mar 15 13:28:04 <hostname> xscreensaver[1439]: PAM unable to dlopen(/usr/lib64/security/pam_yubico.so): /usr/lib64/security/pam_yubico.so: undefined symbol: ykclient_set_proxy Mar 15 13:28:04 <hostname> xscreensaver[1439]: PAM adding faulty module: /usr/lib64/security/pam_yubico.so Mar 15 13:28:04 <hostname> audit[1439]: ANOM_ABEND auid=13013 uid=13013 gid=13013 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=1439 comm="xscreensaver" exe="/usr/bin/xscreensaver" sig=11
I haven't done any prescribed tests, but I'm using it a lot and it seems to function.
Okay, so I think I see what was going on. Maybe FF41 was out there on updates-testing, but, since it requires new sqlite that wasn't available, dnf wouldn't upgrade it. That's just what bojan said, above. But, as soon as the new sqlite was available, dnf found it and would do the upgrade.
Shouldn't be long now before sqlite hits the normal updates repo, but I got a slight jump on it with --enablerepo=updates-testing; that's where dnf found the new sqlite.
So, the answer to my question is, yes, the sqlite dep was a major part of this delay.
So, so confusing. Firstly, when will Fedora users be able to get this security update? It's still not even available via updates-testing. (Obviously, I mean a binary rpm on the mirrors, normal update procedure.) Secondly, what is the source of the delay? drago01 says the sqlite requirement is not related at all, but every other post here suggest that is.
Okay, I guess I needed a new API. This pkg makes reporting crashes work as expected, is generally functional, resolves BZ#2190050.