I also still get the occasional Marco crash with a backtrace pointing to
cairo_region_num_rectangles. If I can do something to assist tracking
this down I'm all ears. I can confirm I'm running Marco built off
sources that contain the fix, i.e. marco 1.24.0-1ubuntu1. My stacktrace
looks identical to
I suspect the partyline is that cloudimage shall support serial console
come hell or high water. If that's the case, as an alternative to
modifying cloudimage to suite vagrant, it might make sense to petition
vagrant to provide a sensible default for the serial console to suit
cloudimage.
I ran in
Just as a side note, I'm not sure why sysvinit script is provided at
all. The daemon seems to work just fine with the included systemd config
file in /lib/systemd/system/corosync-qdevice.service. Unless there's a
compelling reason to keep the sysv init script I'd ditch it, if only to
cut on the pot
The snap has restrictions that the pdftk-java package from Cosmic does
not have: the snap refuses to process files in /tmp (even when the
directory has been created securely with mkstemp), which makes it
unusable for some server workloads, including mine.
Other considerations in favor of extending
Upstream package maintainer dropped it because GTK2 is deprecated:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889137#10
Of course, the practical upshot of that decision is that Debian Sid and
Ubuntu >= 17.10 ship an unusable gtkcairo matplotlib backend.
** Bug watch added: Debian Bug track
Redhat released their fixed rpm referencing CVE-2015-7501
(RHSA-2015:2521). It looks like they cherrypicked the
COLLECTIONS-580.patch and released it as jakarta-commons-collections
0:3.2.1-3.5.el6_7.
As usual, MITRE still has CVE-2015-7501 as "reserved".
** CVE added: http://www.cve.mitre.org/cgi
The patch is here:
->
https://issues.apache.org/jira/secure/attachment/12771520/COLLECTIONS-580.patch
Suggestion for the Ubuntu changelog if the cherrypick approach is taken:
The commons-collections library was discovered by foxglovesecurity to
allow pre-auth code execution in environments that
Upstream has released 3.2.2, acknowledging the affected code in 3.0 thru 3.2.1
as dangerously broken.
->
https://issues.apache.org/jira/browse/COLLECTIONS-580?focusedCommentId=15006492&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15006492
Oracle seems to be okay
Unfortunately, that patch is just a partial workaround for a very
limited use case. If the sysadmin ever tries to override more than a
single IP through the route push mechanism of openvpn (i.e., something
larger than a /32), this hack will stop to do what it did. Also,
NetworkManager still sets a
Actually, another commit in the same Debian package release removes
the breakage that made a fix impossible. When I last tried to fix
this, around may 2nd, there was no fix that did not involve removing
code from the apache2 source package that intentionally crippled
mpm-itk. I'll try to find some
I noticed Debian has recently committed this:
http://anonscm.debian.org/gitweb/?p=pkg-
apache/apache2.git;a=commitdiff;h=086fe10486cbc092975e5b87aed8eb18e06433ac
The brokenness in trusty comes from the Debian apache2 install
scripts, which really went out of their way to discourage ITK. I'm
happ
FWIW, I tried fixing this properly by modifying the mpm-itk and apache2
package sources. I ran into a brick wall: ITK has been poisoned rather
well, so even if you get libapache2-mpm-itk to deconfigure the "event"
MPM, Apache will then fail to start, saying that ITK has to be disabled
first. Of cou
A quicker fix if you run into this issue is:
# a2dismod mpm_event
# apt-get install -f
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1286882
Title:
libapache2-mpm-itk postinst failed
To manage not
smiki: Please read comment #13. The CAPABILITIES_MISMATCH that you're
seeing is for your protection. It's ubuntuone's way of telling you: your
client is outdated. The bug that you re-opened is not about
CAPABILITIES_MISMATCH. It's about files being marked for deletion, which
is not the case.
I thi
The problem with being unable to delete a key from Seahorse occurs when
the key file is lost on disk. If you still have access to the file, you
can copy it back, and Seahorse will then allow key deletion or viewing
properties.
I would rate this behavior counter to the principle of least
astonishme
I can confirm the presence of the "radeon_dma.c:210:
radeonRefillCurrentDmaRegion: Assertion `dma_bo->bo->cref == 1' failed.'
assertion on a stock Karmic installation (32 bit, Dell Dimension 3100,
Radeon 7000/VR100).
I have installed Mesa 7.8 and the accompanying libdrm from todays xorg-edgers
PP
The install problem appears not to be in the openbve package source,
whose dependencies look sane on inspection. The weird dependencies are
put in by Debian's automated Mono build process.
I tried to build the package from source and found the libtaoframework-
opengl3.0-cil library from Karmic to
17 matches
Mail list logo
