ents/features due to the source
> requirement are annoying but Fedora (and other distros) decided to
> take the "high road" here and actually fix stuff instead of shipping
> whatever upstream came up with.
Quite. The high road is never the easy road. Thank you.
--
Andrew Haley
of JSS's SSLEngine, we can work around this problem, but
> that isn't yet merged.
>
> https://github.com/dogtagpki/jss/pull/150
Tricky. It's kinda inevitable that some things will break at some time. We
have to decide whether Dogtag is a blocker for JDK 11 as system JDK.
--
Andrew Haley
to hide shared objects in
JARS, but it's not absolutely forbidden because we know that sometimes
this is what Java programs do and we don't want to burden packagers
unduly.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://
. I
don't know enough about this to suggest a solution, but I am sure it
is a hard problem.
> And yes, you do a lot of great work in other places too. I thank you
> for that the few times I need to touch Java on non-Linux platforms. :-)
>
> Keep up the good work,
Thanks!
--
Andrew Hal
all OpenJDK
updates for 7, 8, and 11, everywhere, not just GNU and Linux. Which is
to say, apart from Oracle's proprietary customers, most of the Java in
the world.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
On 1/26/20 11:52 AM, Nicolas Mailhot wrote:
> Le dimanche 26 janvier 2020 à 10:10 +0000, Andrew Haley a écrit :
>> On 1/26/20 8:43 AM, Nicolas Mailhot via devel wrote:
>>
>>> Java has been in a terminal course in Fedora for a year at
>>> least. You can see how m
his list, but I don't know what it
is you don't like about it.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
___
devel
; untrusted input, especially here where we are talking about importing
> external files! So those security issues absolutely MUST be fixed!
The bugs are raised not against the runtime library but against a command-
line development tool. When unrealistic arguments are given there is a memory
alloc
On 11/18/2015 06:49 PM, Adam Jackson wrote:
> On Tue, 2015-11-17 at 17:30 +0000, Andrew Haley wrote:
>> On 11/02/2015 03:05 PM, Adam Jackson wrote:
>>> But, why take the risk exposure, when you could simply not?
>>
>> How else would I edit root-owned files? I don't
On 11/19/2015 12:57 PM, Simon Farnsworth wrote:
> On Thursday 19 Nov 2015 12:48:50 Andrew Haley wrote:
>> On 11/18/2015 06:49 PM, Adam Jackson wrote:
>
>>> Phrased another way: no, it's not *your computer* we're talking about
>>> here. The computer in question righ
On 11/19/2015 01:03 PM, Simon Farnsworth wrote:
> "sudo -e /etc/hosts", will ... still work
Hold on, I think I may not be understanding something. If "sudo -e /etc/hosts"
will still work, why won't "sudo emacs /etc/hosts" ?
Andrew.
--
devel mailing list
devel@lists.fedoraproject.org
On 11/02/2015 03:05 PM, Adam Jackson wrote:
> But, why take the risk exposure, when you could simply not?
How else would I edit root-owned files? I don't get it. I mean,
I guess I could run an editor in a text window, but I don't want to
do that.
And I have no idea how to run things like
On 11/17/2015 05:55 PM, Joonas Sarajärvi wrote:
> My impression is that by default in fedora, virt-manager runs as
> non-root. I guess it might ask for the root password in order to
> manage the libvirtd that runs as privileged mode, but even in that
> case the user interface would run as your
On 11/17/2015 06:25 PM, Tom Hughes wrote:
> On 17/11/15 18:11, Andrew Haley wrote:
>> On 11/17/2015 05:55 PM, Joonas Sarajärvi wrote:
>>> My impression is that by default in fedora, virt-manager runs as
>>> non-root. I guess it might ask for the root password in order
On 10/10/2015 12:12 AM, Kevin Kofler wrote:
> Then you try to port the application to the new APIs, and if it's not
> possible, you revert the library commit that removed the old API.
Well, hold on: you now have the problem of maintaining a local fork.
Surely that is more than a package
On 10/12/2015 04:29 PM, Kevin Kofler wrote:
> Andrew Haley wrote:
>
>> On 10/10/2015 12:12 AM, Kevin Kofler wrote:
>>> Then you try to port the application to the new APIs, and if it's not
>>> possible, you revert the library commit that removed the old API.
>
On 10/08/2015 08:08 PM, Matthew Miller wrote:
> On Thu, Oct 08, 2015 at 03:37:32PM +0100, Andrew Haley wrote:
>> Maybe we're trying to do too much.
>>
>> I suppose it's a question of choosing to do something which from a
>> software engineering perspecti
On 10/08/2015 02:01 PM, Matthew Miller wrote:
> On Thu, Oct 08, 2015 at 02:50:59PM +0200, Pierre-Yves Chibon wrote:
>> There was a middle ground there that could have been pursued a little
>> more: the sandbock repo which less strict guidelines keeping the
>> current Fedora repo with the current
On 09/13/2015 09:23 PM, Haïkel wrote:
> I'm not speaking about PHP, most of the upstream I deal with
> are python developers. Bad habits are rather spreading than
> regressing.
We're not going to solve that problem by adopting bad habits
ourselves.
Andrew.
--
devel mailing list
On 09/12/2015 03:21 PM, Orion Poplawski wrote:
> But if we're in a situation where we are just killing ourselves
> shoehorning upstream's mess of bundled requirements into rpms and
> their response is just 'well just run "pip install foo" and be done
> with it', I think it's time to just let
On 09/10/2015 03:06 PM, Ralf Corsepius wrote:
> My view: It's an ongoing struggle and fight against upstream
> incompetence, carelessness, sloppiness and low-quality crap software.
> It's a fight we should not give up to, because it would cause damage the
> quality of Fedora.
>
> In that
On 19/05/15 16:20, Kevin Kofler wrote:
Martin Stransky wrote:
is there any mechanism how to speed up release of critical security
fixes by Fedora update system?
For instance Firefox packages are released *week* after official Mozilla
release which is really bad.
Any idea here?
The
On 02/27/2015 10:47 AM, Aleksandar Kurtakov wrote:
If we want to be sure that this legacy jdk will not interfere with
the system JDK let it not provide anything via alternatives. That
way people that want it can use it by playing with PATH/JAVA_HOME
(just like they do with other JVMs).
On 02/27/2015 10:58 AM, Aleksandar Kurtakov wrote:
The problem with alternatives is they are system wide so if one changes the
alternatives to point to the legacy JDK for their third party app this
becomes the JDK system wide. Thus all Fedora packaged Java apps (Tomcat,
Jetty, JBoss,
On 26/02/15 14:59, Mario Torre wrote:
In this case, it's about giving users one thing they asked, which is
easy access to a previous version of Java. We can't afford
maintaining it as Java Team, but this doesn't mean we will refuse to
help people doing it. In fact, the exact existence of this
On 25/02/15 00:31, Kevin Kofler wrote:
Jaroslav Reznik wrote:
= Proposed System Wide Change: Legacy implementations of the Java platform
in Fedora =
https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora
Change owner(s): Jiri Vanek jva...@redhat.com
IMHO, this is not implementable for
On 02/16/2015 04:17 PM, Ralf Corsepius wrote:
I don't buy this argument wrt. Fedora.
Fedora is a rapid moving, forward looking distro, in which such
regressions should be fixed and not be worked around by compat-libs.
That rather assumes that the only use for Fedora libraries is running
On 17/02/15 07:21, David Airlie wrote:
Well I can't provide any info, I don't have an ARM box here, and it
happens in the buildroot which I don't think I can access to get the
files out from.
I've been bitten by this several times. We need to find a better way
to handle issues like this:
On 01/24/2015 07:14 PM, Kevin Kofler wrote:
Ralf Corsepius wrote:
This is not entirely true. GCC and related projects apply a pretty
complex peer review process, with defined roles and privileges. (Cf. the
file MAINTAINERS in GCC's sourcetree for details).
Somewhat over-simplified the
On 27/11/14 14:52, Nico Kadel-Garcia wrote:
On Thu, Nov 27, 2014 at 8:06 AM, P J P pj.pan...@yahoo.co.in wrote:
Overall this feature adds more value to Fedora, than its perceived short
term cost.
I agree, from a basic security standpoint, that it's the simplest
change with the largest
On 10/06/14 19:28, Matthew Garrett wrote:
Fedora is supposed to provide a consistent experience across primary
architectures. Having a subset of our packages fail to build on ARM
means that's not true, and the current state of affairs clearly violates
point 8 of the architecture promotion
On 04/30/2014 12:07 PM, Florian Weimer wrote:
On 04/07/2014 07:29 PM, Andrew Haley wrote:
As of JDK8, OpenJDK can be cross-compiled. Not before time, either.
It seems to me that support is fairly limited—you cannot compile Hotspot
across different operating systems, but perhaps across
On 04/28/2014 03:49 PM, Adam Jackson wrote:
On Mon, 2014-04-28 at 09:58 -0400, Casey Dahlin wrote:
On Mon, Apr 28, 2014 at 08:57:27AM -0400, Adam Jackson wrote:
On Sun, 2014-04-27 at 23:02 +0100, Andrew Price wrote:
On 24/04/14 15:13, Lennart Poettering wrote:
We probably should make
, please let me know. Please do keep in mind though
that we really should just remove GCJ (despite the effect it will have
on pdftk) as preferred by one of the primary authors of it (Andrew
Haley):
How does this affect the bring up of new architectures, I seem to
remember when doing
On 03/24/2014 12:48 PM, Orcan Ogetbil wrote:
On Mon, Mar 24, 2014 at 6:02 AM, Andrew Haley wrote:
On 03/22/2014 07:51 PM, Orcan Ogetbil wrote:
On Thu, Mar 20, 2014 at 7:24 AM, Andrew Haley wrote:
On 03/19/2014 10:59 PM, Andrew Hughes wrote:
And JDK5 might be good enough for the use required
On 03/22/2014 07:51 PM, Orcan Ogetbil wrote:
On Thu, Mar 20, 2014 at 7:24 AM, Andrew Haley wrote:
On 03/19/2014 10:59 PM, Andrew Hughes wrote:
And JDK5 might be good enough for the use required. It doesn't claim
to be anything more than that, so I don't see the harm in leaving
On 03/19/2014 10:59 PM, Andrew Hughes wrote:
- Original Message -
On 03/08/2014 03:37 AM, Orcan Ogetbil wrote:
On Fri, Mar 7, 2014 at 9:32 AM, Jaroslav Reznik wrote:
Sorry I am missing something. Why can't we keep the old pdftk that
works with itext2?
Check the whole thread -
On 03/08/2014 03:37 AM, Orcan Ogetbil wrote:
On Fri, Mar 7, 2014 at 9:32 AM, Jaroslav Reznik wrote:
Sorry I am missing something. Why can't we keep the old pdftk that
works with itext2?
Check the whole thread - because of GCJ dependency. iText is second
issue. The first could be fixed by
On 10/30/2013 10:27 AM, Alec Leamas wrote:
On 2013-10-30 11:23, Reindl Harald wrote:
Am 30.10.2013 11:20, schrieb Alec Leamas:
On 2013-10-30 10:58, Reindl Harald wrote:
Am 30.10.2013 10:53, schrieb Alec Leamas:
Some kind of reference for the bad in having a well-known, hidden
directory in
On 11/01/2013 09:38 AM, drago01 wrote:
On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley a...@redhat.com wrote:
On 10/30/2013 10:27 AM, Alec Leamas wrote:
On 2013-10-30 11:23, Reindl Harald wrote:
Am 30.10.2013 11:20, schrieb Alec Leamas:
On 2013-10-30 10:58, Reindl Harald wrote:
Am 30.10.2013
On 09/07/2013 12:52 AM, Gregory Maxwell wrote:
Regardless, I think that argument would be an ignorant one:
Approximately no one runs non-ECDH PFS on the web: it's insanely slow
and it breaks clients.
Hmm. Isn't non-ECDH PFS just straight integer (mod N) Diffie-Hellman?
And that's what is
On 07/11/2013 03:33 PM, Matthew Garrett wrote:
On Thu, Jul 11, 2013 at 04:01:15PM +0200, Miloslav Trmač wrote:
On Tue, Jul 9, 2013 at 7:52 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
That's the point. You don't get to be a primary architecture until
you've demonstrated that doing so won't
On 12/08/2012 04:12 PM, Arun SAG wrote:
Not really! We are already a customer of RHEL. Money is not the problem. We
want our users to use the latest software out there but we also want to
reduce the upgrade cycle.
I don't understand what you're saying. If you want your users to use
latest
On 11/27/2012 10:08 AM, Debarshi Ray wrote:
OK, so there are some proprietary or otherwise encumbered plugins that might
not be GPLv3-compatible but might be compatible with GPLv2.
You again missed the GPLv2 with exceptions part.
Plus, this practice of either using LGPLv2+ or GPLv2+ with
On 11/26/2012 10:14 AM, Debarshi Ray wrote:
I came across what looks like a possible licensing issue with LibRaw and
applications that link to it. I am not totally sure that there is a problem,
but I have enough reason to have doubts. I welcome any clarifications and
advice.
LibRaw's
On 11/26/2012 04:26 PM, Debarshi Ray wrote:
If that is the case, then has Yorba been notified of that? I doubt they
would suddenly want their code to become GPLv3 instead of LGPLv2+.
Why does it matter? Their code hasn't changed, and has not become GPLv3.
The package is GPLv3+.
It
On 11/26/2012 06:29 PM, Debarshi Ray wrote:
Why does it matter? Their code hasn't changed, and has not become GPLv3.
The package is GPLv3+.
It matters because Shotwell links to GStreamer.
GStreamer applications either opt for LGPLv2+ or GPLv2+ with exceptions
because they might end up
On 09/20/2012 06:28 AM, Eduardo Javier Echeverria Alvarado wrote:
I've a problem with a static bundled library in a package, specifically
duff - Quickly find duplicate files - BZ Review 857639, I already made a
ticket in FPC #211 seeking an exception, my choice is to package the
library in
On 07/18/2012 11:37 PM, Sam Varshavchik wrote:
Andrew Haley writes:
On 07/18/2012 12:06 PM, Sam Varshavchik wrote:
But that's not a use case. There's no way to know why you want to do
this: why you care that another process is running the exact same
executable.
Because that's the only
On 07/19/2012 12:10 PM, Sam Varshavchik wrote:
Andrew Haley writes:
On 07/18/2012 11:37 PM, Sam Varshavchik wrote:
How do you know that the server that gave you a seemingly verified SSL
certificate, that checks out, isn't an impostor that managed to crack the
right prime.
Because we know
On 07/19/2012 12:29 PM, Andrew Haley wrote:
On 07/19/2012 12:10 PM, Sam Varshavchik wrote:
Andrew Haley writes:
On 07/18/2012 11:37 PM, Sam Varshavchik wrote:
How do you know that the server that gave you a seemingly verified SSL
certificate, that checks out, isn't an impostor that managed
On 07/18/2012 02:25 AM, Sam Varshavchik wrote:
Chris Adams writes:
Once upon a time, Sam Varshavchik mr...@courier-mta.com said:
Chris Adams writes:
Is there any value in this additional check (that nobody else
apparently does)? Do you not trust the kernel's credential handling?
I
On 07/18/2012 12:06 PM, Sam Varshavchik wrote:
Andrew Haley writes:
On 07/18/2012 02:25 AM, Sam Varshavchik wrote:
Not exactly. You said:
Can you explain, then, the correctly approach by which an
executable can affirm whether another pid is either running the same
executable
On 07/17/2012 12:38 AM, Sam Varshavchik wrote:
Jan Kratochvil writes:
On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote:
And I wouldn't be so presumptions as to state authoritatively what
is or is not a bug, in something whose purpose is not known to me.
Non-existing /proc/self/exe
On 07/12/2012 08:41 AM, yersinia wrote:
For the folk here that don't follow fd. The author is a well know and
respected security researcher.
There's a much more sane independent analysis of Fedora's position at
http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web
Andrew.
On 07/11/2012 08:51 AM, pravin@gmail.com wrote:
I have completed initial work. Yet not able to solve LiberationSansNarrow
licensing stuff might be it will take some more time
Most people reading devel probably don't know what the LiberationSansNarrow
licensing problem is.
Andrew.
--
devel
On 06/22/2012 04:15 AM, Sam Varshavchik wrote:
The new perl package contains /usr/bin/perl. At upgrade, dependency
resolution is not smart enough to realize that the new package's
/bin/perl=/usr/bin/perl, causing a conflict.
What exactly is the conflict?
Andrew.
--
devel mailing list
On 06/22/2012 11:44 AM, Sam Varshavchik wrote:
Andrew Haley writes:
On 06/22/2012 04:15 AM, Sam Varshavchik wrote:
The new perl package contains /usr/bin/perl. At upgrade, dependency
resolution is not smart enough to realize that the new package's
/bin/perl=/usr/bin/perl, causing a conflict
On 06/22/2012 12:10 PM, Reindl Harald wrote:
Am 22.06.2012 13:07, schrieb Andrew Haley:
On 06/22/2012 11:44 AM, Sam Varshavchik wrote:
Andrew Haley writes:
On 06/22/2012 04:15 AM, Sam Varshavchik wrote:
The new perl package contains /usr/bin/perl. At upgrade, dependency
resolution
On 06/22/2012 01:19 PM, Sam Varshavchik wrote:
Andrew Haley writes:
Why not take /bin and /sbin out of the default path *and* make sure
that RPM knows about /bin/* ?
I would expect that changing rpm will be a long, tedious process. Which is
understandable.
But changing the default
On 06/22/2012 01:45 PM, Sam Varshavchik wrote:
Andrew Haley writes:
On 06/22/2012 01:19 PM, Sam Varshavchik wrote:
Andrew Haley writes:
Why not take /bin and /sbin out of the default path *and* make sure
that RPM knows about /bin/* ?
I would expect that changing rpm will be a long
On 06/18/2012 06:18 PM, Adam Williamson wrote:
I hesitate to put words in people's mouths, and correct me if I'm
wrong, but it reads to me as if Jay and others are arguing from an
incorrect premise. That premise is to assume that there is a
God-given right for people who own computing devices
On 06/19/2012 03:45 PM, Eric Smith wrote:
I would claim that the moral right to run whatever software we wish on
hardware we own is a negative right; it doesn't put any obligation on
another party to help you do it. If you can hack up Fedora to run on a
Nokia Windows phone, more power to
power to you, but Nokia and Microsoft aren't
obligated to help you do it, and aren't legally prohibited from doing
things that make it difficult for you to exercise your moral right.
Andrew Haley wrote:
I think I'd disagree with you there. I don't think it's any different
from someone using
On 06/14/2012 10:17 PM, Orion Poplawski wrote:
I spent some time today trying to package up julia. It's pretty messy and
this is no where near complete (it still downloads packages and fails to
build
due to https://github.com/JuliaLang/julia/issues/933), but thought I'd put it
out there
On 06/08/2012 06:37 PM, Adam Jackson wrote:
On Fri, 2012-06-08 at 18:14 +0100, Andrew Haley wrote:
On 06/08/2012 05:42 PM, Adam Jackson wrote:
And - though it pains me that this next thought might actually be
unpopular, though closer investigation might reveal that I'm giving the
feature too
On 06/08/2012 04:24 PM, Adam Jackson wrote:
On Thu, 2012-06-07 at 15:16 -0500, Chris Adams wrote:
Once upon a time, Adam Jackson a...@redhat.com said:
If there are ARM machines where UEFI and Secure Boot are available,
we're going to have tools to do your own trust database management
anyway,
On 06/08/2012 05:42 PM, Adam Jackson wrote:
On Fri, 2012-06-08 at 16:29 +0100, Andrew Haley wrote:
On 06/08/2012 04:24 PM, Adam Jackson wrote:
And? I wasn't speaking to we should sign our arm images with
Microsoft's key, I was speaking to we should support Secure Boot on
arm. If someone
On 05/17/2012 04:37 PM, Frank Ch. Eigler wrote:
Tomasz Torcz to...@pipebreaker.pl writes:
[...] Can we get some definite numbers?
Yeah, not enough of those going around. A quick test with systemtap,
a typical pointer/datastructure-heavy program, on same x86-64 machine,
compiled with
On 04/13/2012 01:59 AM, Anthony Green wrote:
I recently release libffi 3.0.11, and ABI changes are mandating a .so
number change. Despite the ABI change, I suspect that simple rebuilds
are all that will be required for dependent packages.
The ABI changes are simply:
1. Some
On 03/26/2012 05:46 PM, Jakub Jelinek wrote:
On Mon, Mar 26, 2012 at 04:54:05PM +0200, Adrian Reber wrote:
Trying to build gforth with gcc 4.7 fails currently. The forth engine is
build but it fails its included tests. The problem is that every newline
the forth engine writes is replaced with
On 03/26/2012 03:54 PM, Adrian Reber wrote:
Trying to build gforth with gcc 4.7 fails currently. The forth engine is
build but it fails its included tests. The problem is that every newline
the forth engine writes is replaced with 0x00 as seen in following diff:
010: 6566 696e 6564 2047
On 03/26/2012 11:01 PM, Robert 'Bob' Jensen wrote:
As I already pointed out - the process is open. Anybody can step
into in the early phase of naming selection and comment the
potential problems. And I believe the Board members will think
about the concerns raised (at least me ;-).
So
On 03/22/2012 01:38 AM, Kevin Kofler wrote:
(but the multi-core ARM setups actually present themselves as a
multi-computer cluster, which is not supported by make -j, not as
a multi-CPU computer)
FWIW, I'm pretty sure this is not the case for the ARM computers
on the way now: they are
On 03/22/2012 02:00 AM, Kevin Kofler wrote:
Peter Robinson wrote:
Exactly! Ultimately what we need is FESCo to document what are the
requirements of being promoted to a primary architecture and then it's
the ARM SIGs job of ensuring they adhere to the requirements, provide
viable workable
On 03/22/2012 10:17 AM, elison.ni...@gmail.com wrote:
And what will Fedora have achieved after putting in so much work? A
few users (read geeks) who will be willing to install Fedora on their
android tablets or ipads? Are there any ARM boards out in the market
that are waiting to get Fedora
On 03/20/2012 05:44 PM, Kevin Kofler wrote:
Jon Masters wrote:
On 03/20/2012 11:52 AM, Peter Jones wrote:
7) it can't be a serious maintenance burdon due to build related issues.
We need a couple of groups to sign off that builds are fast enough, not
just on a full distro rebuild
On 03/07/2012 04:34 PM, Bill Nottingham wrote:
Any plans for sunsetting GCJ?
That's an interesting question. It's still useful in a number
of niche roles: for example, it's used in PDFTK. Also, it would
have been very hard to bootstrap OpenJDK onto ARM without it.
For that reason, it's on my
On 02/10/2012 07:12 PM, Jon Ciesla wrote:
Given all that, it seems only logical to conclude that Fedora really
_isn't_ primarily intended for use as a production server.
Bingo, which is why it's important for people like me who do it to
realize what they're getting into and take some
On 01/18/2012 04:11 PM, Jochen Schmitt wrote:
because I have got issues with the gcc-4.7 compiler suite i have
contacted the
upstream of the gnustep project to get a solution for my issues.
He has adviced me to migrate the gnustep stuff to clang/llvm. Espeicially
some gnustep stuff like
On 01/18/2012 04:53 PM, Jochen Schmitt wrote:
On 18.01.2012 17:25, Andrew Haley wrote:
On 01/18/2012 04:11 PM, Jochen Schmitt wrote:
It might be more helpful to tell us what these issues are. While
LLVM might well be OK on x86, I'm less convinced about support for
other arches.
The issue
On 01/18/2012 05:03 PM, Jochen Schmitt wrote:
On 18.01.2012 17:57, Andrew Haley wrote:
The issue was, that during thu build of gnustep-base I have got a
error messag which told me, that the file objc/objc-api.h was not
found.
So I have ask upstream for support to solve this issue
On 01/18/2012 05:10 PM, Jakub Jelinek wrote:
so it is surprising that gnustep maintainers didn't bother to do anything
to move toward objc/runtime.h. And it surprises me that clang actually
didn't remove that header too, I'd have thought that Nicola Pero
removed it because it was gone in
On 12/21/2011 10:45 PM, Matej Cepl wrote:
On 21.12.2011 18:52, Andrew Haley wrote:
There really is very little difference between the com.sun.* classes
in OpenJDK and the proprietary JDK, as far as I know. Of course, I
haven't really checked, but... ;-)
So, what is the root cause
On 12/22/2011 10:41 AM, Paul Howarth wrote:
At $WORKPLACE I use a Java app (via javaws) - EMC NetWorker Management
Console - that won't work with OpenJDK (it pops up a username/password
window as expected but doesn't then pop up the main app window once the
username+password have been
On 12/21/2011 05:09 PM, Matej Cepl wrote:
On 20.12.2011 19:30, Dennis Jacobfeuerborn wrote:
Probably because OpenJDK and SunJDK aren't really that compatible.
Well, hold on. Both the proprietary JDK and OpenJDK meet the
specification, and we try very hard to be compatible with all
the things
On 11/18/2011 11:32 PM, Tom Lane wrote:
Andrew Haley a...@redhat.com writes:
On 11/18/2011 05:53 PM, Ralf Corsepius wrote:
pptp.c:459:33: warning: dereferencing type-punned pointer might break
strict-aliasing rules [-Wstrict-aliasing]
Bingo! Bugs like this must be fixed.
Sometimes
On 11/18/2011 11:31 AM, Paul Howarth wrote:
One of my packages, pptp, suffers occasional segfaults as reported in
http://bugzilla.redhat.com/749455. However, whilst investigating this,
it seems to be the case that simply rebuilding the package using no
optimization (-O0) as opposed to the
On 11/18/2011 05:53 PM, Ralf Corsepius wrote:
pptp.c:459:33: warning: dereferencing type-punned pointer might break
strict-aliasing rules [-Wstrict-aliasing]
Bingo! Bugs like this must be fixed.
Andrew.
--
devel mailing list
devel@lists.fedoraproject.org
On 11/08/2011 02:22 PM, Rahul Sundaram wrote:
On 11/08/2011 06:06 PM, Stijn Hoop wrote:
Right, I assumed that this would be implemented for every user != root
(basically). In other words, also for normal local users.
Why is that not part of the proposal?
It'd break things. At the
On 10/31/2011 09:49 PM, Dr Andrew John Hughes wrote:
On 16:48 Mon 31 Oct , Andrew Haley wrote:
Am 31.10.2011 17:00, schrieb Deepak Bhole:
It looks like a known bug in the 6 compiler related to interface
inheritance and covariant return types. I think this is the commit
that fixed
Am 31.10.2011 17:00, schrieb Deepak Bhole:
It looks like a known bug in the 6 compiler related to interface
inheritance and covariant return types. I think this is the commit
that fixed it in 7:
http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/4a3b9801f7a0
If you have code that
On 08/01/2011 11:28 AM, Marcela Mašláňová wrote:
I found different warning about Java 7 changes:
http://www.lucidimagination.com/search/document/1a0d3986e48a9348/warning_index_corruption_and_crashes_in_apache_lucene_core_apache_solr_with_java_7
That's not a Java 7 change, it's a new VM bug.
On 27/07/11 11:19, Nicolas Mailhot wrote:
Really, this discussion is pointless. It should be taken to whoever
maintains the xdg directory layout specs nowadays (even the FHS editors
gave up on normalizing /home layout and pushed the problem xdg-side)
No, because this is not an xdg-mandated
On 07/27/2011 11:45 AM, Nicolas Mailhot wrote:
Le mercredi 27 juillet 2011 à 11:23 +0100, Andrew Haley a écrit :
On 27/07/11 11:19, Nicolas Mailhot wrote:
Really, this discussion is pointless. It should be taken to whoever
maintains the xdg directory layout specs nowadays (even the FHS
On 07/27/2011 01:00 PM, Nicolas Mailhot wrote:
Le mercredi 27 juillet 2011 à 12:54 +0100, Andrew Haley a écrit :
On 07/27/2011 11:45 AM, Nicolas Mailhot wrote:
Le mercredi 27 juillet 2011 à 11:23 +0100, Andrew Haley a écrit :
On 27/07/11 11:19, Nicolas Mailhot wrote:
Really, this discussion
On 26/07/11 10:22, Misha Shnurapet wrote:
Since F15 ~/bin has been added to PATH, and commands that are
supposed to run user scripts will work without changing into that
directory. Meanwhile, ~/.local/bin isn't used. I'd like to propose
that it is also added because technically it is ~/bin's
A strange alert:
The process /usr/bin/tee attempted to mount on /proc/bus/usb.
This is F14, fully updated.
Any ideas what this might be?
Thanks,
Andrew.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 24/06/11 20:49, Miloslav Trmač wrote:
On Fri, Jun 24, 2011 at 12:49 PM, Andrew Haley a...@redhat.com wrote:
What I don't understand is why this feature requires a binary blob.
Surely whatever northbridge code is required can be free software,
Is this just security through obscurity
What I don't understand is why this feature requires a binary blob.
Surely whatever northbridge code is required can be free software,
Is this just security through obscurity?
Andrew.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
1 - 100 of 150 matches
Mail list logo
