Package: clang
Version: 1:3.5-26
An update to the "clang" package in the last month breaks clang++ when
using -std=gnu++1y and -g. The following error begins to appear all over:
error: debug information for auto is not yet supported
Unfortunately, the error has no line number, making it hard to
After a system update and reboot, the problem went away, even though I'm
still on the same linux-image package. So maybe the problem wasn't in the
kernel, but I have no idea what else it might have been.
Package: linux-image-3.16.0-4-amd64
Version: 3.16.7-ckt11-1
After installing updates today and rebooting, I found that my USB keyboard
and mouse, after being idle for exactly two seconds, would be suspended,
such that they would not wake up until after a key/button press, and the
wake-up press wou
fixed 774195 2:3.17.4-1
Could the fixed version in experimental please get pushed along to
unstable? Otherwise we're training users to ignore https errors and
masking real problems.
On Sat, Mar 14, 2015 at 8:00 PM, Kenton Varda wrote:
> Because of this bug, Chrome (42.0.2311.39) now fl
ted ? "true" : "false");
}
};
class B: virtual public A {};
class C: virtual public B {};
class D: public C {};
int main() {
A a = D();
}
=
On Tue, Mar 24, 2015 at 12:37 AM, Bastian Blank wrote:
> Moin
>
> On Mon, Mar 23, 2015 at 03:18:08PM
Package: g++-4.9
Version: 4.9.2-10
Using g++ 4.9.2-10 on amd64, the below program behaves differently
when compiled with -O2 vs. not. The non-optimized version is correct;
the program's output should be:
~A(): moved = true
~A(): moved = false
However, with the optimized version, the program inco
Because of this bug, Chrome (42.0.2311.39) now flags most HTTPS
certificates as broken. For example, tweetdeck.twitter.com shows "https"
struck out in red, as in this screenshot:
https://lh5.googleusercontent.com/-uL3aeiJeg6U/VQOyNUF51rI/HlQ/HUFK3SyDvGk/w359-h30-no/https-not.png
Hello,
I'm the lead developer of Sandstorm.io. We do containerization stuff.
Often it's a lot easier to build a static binary than to try to make
all the right libraries available in a container.
We actually ship our own updates using our own update infrastructure,
so the security update benefits
I do have experience with sonames, actually, from protobufs. My experience
was:
- We never did two releases that had the same binary interface.
- We occasionally forgot to bump the soname, leading to problems.
The nature of C++ is that binary compatibility between versions is nearly
impossible t
any other option.
On Wed, Nov 18, 2009 at 8:44 PM, Dirk Eddelbuettel wrote:
>
> Kenton,
>
> On 18 November 2009 at 19:37, Dirk Eddelbuettel wrote:
> | On 18 November 2009 at 17:10, Kenton Varda wrote:
> | | I've created a 2.2.0a release:
> | |
> | | SVN: http://
nfirm that it
fixes the problem.
On Wed, Nov 18, 2009 at 4:41 PM, Kenton Varda wrote:
> Bumping the soname is part of our release process, since C++ ABI
> compatibility is practically impossible to maintain. Unfortunately, if SVN
> is to be believed, it appears that somehow this didn
ewing
anything up!
I guess I will do a 2.2.0a which does nothing but fix this. I'd like to
avoid changing the last digit there because it would create a bunch of new
ways that I could screw up.
On Wed, Nov 18, 2009 at 3:55 PM, Robert Edmonds wrote:
> [ kenton varda, upstream release engineer
12 matches
Mail list logo
