Just noticed the same thing as well. Here's a quick and dirty workaround
for those affected:
$ cp -p /etc/php/mods-available/uuid.ini
/etc/php/7.0/mods-available/uuid.ini
$ ln -s /etc/php/7.0/mods-available/uuid.ini
/etc/php/7.0/cli/conf.d/20-uuid.ini
$ ln -s
In the upstream Debian ticket 799262 there is now a patch that adds the
missing python3-opencv package:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799262#20
The patch looks well formulated. Given that, the packaging work for
OpenCV 3 seems substantially complete.
--
You received this
In the corresponding Debian ticket there is now a patch that adds a
python3-opencv package:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799262#20
The patch looks well formulated. Given this, the packaging work for
OpenCV 3 seems complete. All that remains is the testing...
--
You
FYI, I opened bug #1556156 just now for the specific issue of the
currently-shipped OpenCV version lacking Python 3 support altogether. As
that issue is contingent on first shipping OpenCV 3.0, and the
implications of failing to do so for the next LTS are not limited to
merely the question of
FYI, I opened bug #1556156 just now for the specific issue of the
currently-shipped OpenCV version lacking Python 3 support altogether. As
that issue is contingent on first shipping OpenCV 3.0, and the
implications of failing to do so for the next LTS are not limited to
merely the question of
** Bug watch added: Debian Bug tracker #792677
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792677
** Also affects: opencv (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792677
Importance: Unknown
Status: Unknown
--
You received this bug notification because
Public bug reported:
Because the packaged OpenCV remains at the obsolete 2.4 release even
still in 16.04 (Xenial Xerus), which is already in feature freeze, it is
looking as though 2018 is the earliest that an Ubuntu LTS release will
package OpenCV 3.x, which at that point will be already some 4
Since 16.04 (Xenial Xerus) is now feature-frozen, one supposes this
isn't going to happen for the present LTS release.
This is unfortunate, because the pressing problem with retaining the
ancient OpenCV 2.4 in Xenial is that it doesn't include Python 3
bindings. The python-opencv package requires
Given that 16.04 (Xenial Xerus) is now feature-frozen, it seems unlikely
this is going to happen for the present LTS release.
This is unfortunate, because the pressing problem with retaining the
ancient OpenCV 2.4 in Xenial is that it doesn't include Python 3
bindings. The python-opencv package
This problem still affects even Ubuntu 14.04. The aforementioned
workaround of installing the bochs-sdl package and setting
display_library: sdl in ~/.bochsrc resolves the problem.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hi Michael,
Yes, we couldn't operate within the constraints of a queues_max=1024
kernel hard limit, and could not possibly require our customers to
install a custom-patched kernel, so we had to abandon POSIX message
queues altogether and switch to other forms of IPC. (Your book was
helpful in
Just to follow up on this, we have since abandoned the use of POSIX
message queues altogether so this issue is no longer an ongoing concern
for us.
Still, the mq_overview(7) man page continues to refer to the outdated,
inaccurate queues_max hard limit (INT_MAX instead of 1024) at least as
of
Ran into this bug on 12.10, but was able to work around it using --
addpkg linux-image-generic as described in previous comments.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to vm-builder in Ubuntu.
Ran into this bug on 12.10, but was able to work around it using --
addpkg linux-image-generic as described in previous comments.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1037607
Title:
Michael,
We do run the database software as unprivileged users, yes. Previously,
our installation instructions have advised configuring appropriate
values in /etc/sysctl.d/*.conf and /etc/security/limits.d/*.conf for the
system limits and per-user limits, respectively. After kernel 3.5+, that
Michael, what do you think should be the next step here? Is raising
HARD_QUEUESMAX back upwards feasible, or should the patch be more in
line with what you began formulating?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Michael, I tested your patch against Ubuntu 12.10's 3.5.0-26-generic
kernel, applied after `apt-get source`. Your patch does apply and build
cleanly (offset 1 line compared to the 3.9 sources).
However, it unfortunately does not fix the issue. sysctl still cannot be
used to raise the message
Michael, thanks for that; the patch looks good, but I will make some
time today to build a patched kernel on a virtual machine and get back
to you with a confirmation.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Michael, thanks for looking into this.
In answer to your question: yes, it caused the IPC mechanism in the
database engine my company develops (dydra.com) to break, causing not a
little aggravation. While we don't need millions of message queues, we
had been relying on having at least a few
Michael, time constraints mean that we'll likely have to put in place a
SysV-based workaround in any case.
But sure, I'm willing to make the attempt to get this fixed upstream as
well.
The hard limit remains the same from Linux 3.5 to 3.8, looks like:
http://lxr.free-
This was fixed upstream in:
http://code.google.com/p/irqbalance/source/detail?r=4e7df9d0b5416add20fe10925d82f145d3514715
There is more information at:
https://bugzilla.redhat.com/show_bug.cgi?id=781578
https://bugzilla.redhat.com/show_bug.cgi?id=837646
Anyone affected on 12.10 can mute the
This was fixed upstream in
http://code.google.com/p/irqbalance/source/detail?r=4e7df9d0b5416add20fe10925d82f145d3514715
There is more information at
https://bugzilla.redhat.com/show_bug.cgi?id=781578 and
https://bugzilla.redhat.com/show_bug.cgi?id=837646
Until a newer version of irqbalance is
This was fixed upstream in:
http://code.google.com/p/irqbalance/source/detail?r=4e7df9d0b5416add20fe10925d82f145d3514715
There is more information at:
https://bugzilla.redhat.com/show_bug.cgi?id=781578
https://bugzilla.redhat.com/show_bug.cgi?id=837646
Anyone affected on 12.10 can mute the
This was fixed upstream in
http://code.google.com/p/irqbalance/source/detail?r=4e7df9d0b5416add20fe10925d82f145d3514715
There is more information at
https://bugzilla.redhat.com/show_bug.cgi?id=781578 and
https://bugzilla.redhat.com/show_bug.cgi?id=837646
Until a newer version of irqbalance is
Public bug reported:
The manpages 3.40-0.1ubuntu3 package in Ubuntu 12.10 contains an
mq_overview(7) man page with outdated, severely inaccurate information
regarding the /proc/sys/fs/mqueue/queues_max kernel limit, as follows:
The default value for queues_max is 256; it can be changed to any
25 matches
Mail list logo
