Re: Re-Launching the Java SIG
On 5/12/20 11:55 AM, Felix Schwarz wrote: > > Am 12.05.20 um 12:32 schrieb Ty Young: >> Right, I figured it was some Fedora policy and not up to you. I suppose I >> should have been more clear there. Sorry for any confusion, it was aimed at >> the Fedora project as a whole as this is a Fedora issue. > > This is not a Fedora issue but a consequence of Fedora's core values. You not > agree with it but "building from source" is so fundamental that it does not > make sense to even start a discussion about it on fedora-devel. Yes, exactly. It's not a Java thing, it's a free software thing. If we just grab binaries how do we know that they respect the basic freedoms? > I suggest you read up on the rationale behind that policy (which is > why I linked the policy document in the first place). > > I understand that missing components/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 (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 mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: java-11-openjdk as system JDK in F33
On 3/30/20 4:47 PM, Alex Scheel wrote: > For one example here, take the long-standing Debian ticket against Dogtag: > > https://www.pagure.io/dogtagpki/issue/3088 > > OpenJDK 11 moved to TLS v1.3, but didn't fully implement the spec: PHA isn't > available. This is a requirement for our particular application. > > It isn't clear why forcing TLS v1.2 didn't fix this issue. TLS v1.2 works fine > on OpenJDK 8. IMO, this makes it a JDK11 bug. And not the type we have time to > debug and figure out what broke in OpenJDK. > > > With the introduction 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 (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 mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Java Packaging Guidelines - .so in JARs?
On 2/12/20 8:57 PM, Alex Scheel wrote:
> Per $SUBJ, I was looking for guidance from the Java community about
> embedding .so files within JARs.
>
> I found these docs:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_applicability
>
> Which seem to have conflicting commentary on this:
>
> - A Java package uses JNI if it contains a .so file. Note that this file can
>be embedded within JAR files themselves.
- JAR files using JNI or containing JNI shared objects themselves
MUST be placed in %{_jnidir} and MAY be symlinked to
%{_libdir}/%{name}.
> - JNI shared objects MUST be placed in %{_libdir}/%{name}
>
> As long as the JAR for the application is played in
> %{_libdir}/%{name}/%{name}.jar, does this mean that the .so can be
> placed within the JAR?
Yes. This is explicitly permitted by the rule above.
> The benefit to .so-in-JAR is that the JAR always knows where to find
> the .so, even if the user installs multiple versions of the same
> package, or, worse, copies JARs from different systems around.
>
>
> Wondering what the community's thoughts are,
Hidden shared objects have to be unpacked somewhere in order to be
used. If they're unpacked somewhere private they won't be shared. And
the runtime code will need to find the correct shared object, the one
relevant to the machine in use. I've seen this break on new
architectures.
So, generally it's not such a great idea 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://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Java Dev Group and Fedora Quality
On 1/29/20 3:15 PM, Alex Scheel wrote: > I lump the Java SE platform into "roughly" what I was calling the JVM > team. You're roughly the group that does what'd be the "core" work in > other languages: maintains the compilers and the stdlib. My terminology > there was incorrect; I suppose "JRE" is more correct. > > Is it correct to say that your team and immediate coworkers don't > maintain say, the Apache libraries, the various build systems, IDEs, > and the JBoss libraries? Yes, it's exactly right. However, we (the Java SE team) are part of the Red Hat Middleware division, who do indeed maintain the JBoss libraries. > My point is that some language SIGs/teams take a more active role in > making sure a decent amount of non-stdlib software runs and is > maintained by them. The "core" Java (JVM + JRE) team doesn't seem to > engage in other places. Which is totally fine, from my PoV, as long > as there is communication between the two parts and between the group > and the wider Fedora community, and the overall experience is inclusive. The issue here is as much about separation of concerns as anything else. There's a limit to how much different stuff people can possibly do, and we all have to draw the boundary somewhere. Of course we want people to use Java, and to that end we ensure that it meets its specification, performs well, and so on. One of the most important things we do is maintain compatibility as much as we can, so that packagers have a solid platform on which to build. The wider Java community has created an amazing ecosystem of packages, build tools, and so on. Some of these tools have, er, interesting properties, and I think it's fair to say that the designers of Java itself probably wouldn't have done it that way. However, such tools are testament to the remarkable flexibility of the Java platform, and in a way that flexibility is part of the problem. > Instead, most of the library support falls to Joe's team, including > Mikolaj. That's where most of the shortcomings in Java packaging are > seen, including unfriendly, non-inclusive modularization policies. > They're the ones that have orphaned large segments of packages, which > ultimately lead to starting this mail thread. :-) Even the word "modularization" is problematic here: I guess you mean Fedora modules, not Java modules. Can you provide (or point me to) a brief explanation of where Fedora's modularization policy conflicts with Java's needs? > Perhaps putting words in Bill's mouth here, but I don't subscribe any > of his issues to the JRE team. They're mostly caused by issues in a > lot of packages disappearing, and Matt Booth trying his best to clean > up after that (with the help of Stewardship SIG). But we're all busy > folks and sometimes we can handle that new package load and sometimes > we can't. Sure, I get that. There is inevitable tension between Red Hat's desire to make Fedora a true community effort and the fact that sometimes packaging is hard, and so needs full-time attention. This is especially because of tools things like Maven, where the design of Maven and Fedora packaging seem sometimes to be diametrically opposed. 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 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 mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Java Dev Group and Fedora Quality
On 1/27/20 3:13 PM, Alex Scheel wrote: > N.B.: I'd like to thank the Red Hat JVM team for being solid in > their Fedora execution. But they maintain only the JVM, and not > the rest of the Java ecosystem. :-) Thank you. One (perhaps) rather minor point in the middle of this important discussion: there is no "Red Hat JVM team." We're responsible for the entire base Java (SE) platform, that is to say the VM and the surrounding Java libraries. Also, we're not just responsible for RHEL and Fedora: our team and our partners in a few other organizations are responsible for 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 EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Java Dev Group and Fedora Quality
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 much Red Hat Java leadership cares about the >>> situation by consulting next week’s Java dev room schedule. Red Hat >>> is co- organisator of this dev room >>> https://fosdem.org/2020/schedule/track/free_java/ >> >> Okay, I'll bite. I am part of the Red Hat Java leadership. >> >> I'm pleased with this year's FOSDEM schedule. People have submitted a >> lot of interesting-looking talks, and I expect it'll be a good day. I >> take it that you don't approve of this list, but I don't know what it >> is you don't like about it. > > I was just pointing out that devroom schedules reflect the interests > and priorities of the people organizing the devroom. And that those > interests and priorities do not include Java getting in such a state > that all the Fedora maintainers quit, major apps no loner work, and > users are migrating elsewhere. You would not expect a GCC devroom to be concerned about the problems of all packages written in C and C++, so why would Java be any different? The problems of Fedora Java packaging, while important, are somewhat disjoint from those of the platform, especially at a conference which is not even strictly Linux-specific. > It’s not for me to approve or disapprove. As far as I can tell from what has been said, the problems being discussed here relate to packaging and testing. The packaging of programs which depend on Java is somewhat outside my remit. Having said that, I am interested to discover why Java packaging in Fedora is particularly dysfunctional. -- 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 mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Java Dev Group and Fedora Quality
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 much Red Hat Java leadership cares about the > situation by consulting next week’s Java dev room schedule. Red Hat > is co- organisator of this dev room > https://fosdem.org/2020/schedule/track/free_java/ Okay, I'll bite. I am part of the Red Hat Java leadership. I'm pleased with this year's FOSDEM schedule. People have submitted a lot of interesting-looking talks, and I expect it'll be a good day. I take it that you don't approve of this 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 mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: responding to CVEs
On 1/14/19 4:08 PM, Kevin Kofler wrote: > Dave Love wrote: >> I ask because three CVEs have triggered automated bug reports against >> libxsmm <https://apps.fedoraproject.org/packages/libxsmm/bugs>. I don't >> understand why the CVEs were issued, since a problem with unrealistic >> input to a (rather rarely used) development tool doesn't strike me as a >> security problem. > > libxsmm is NOT a "development tool", it is a library that ends up linked > into scientific applications. Those applications may very well encounter > 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 allocation failure. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: On running gui applications as root
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 get it. I mean, >> I guess I could run an editor in a text window, but I don't want to >> do that. > > That's kind of a non sequitur. To a first order, there are zero root- > owned files you need to edit routinely. And I feel pretty comfortable > calling any counterexamples bugs that need fixing. I don't quite understand what you're saying here. There are plenty of config files in a UNIX-like system, and they are supposed to be edited. And if you think otherwise, then I think you are wrong. >> And finally, it's *my computer*, dammit. > > In the threat model being described, no, it is not, there's another > agent on the system subverting your use of it. > > You are of course free to disregard that risk, or measure it in the > event and conclude it's safe enough, and in many cases it will in fact > be safe. Well, good, as long as I can still do that, I will be happy. > Great, fine, that's a conclusion a consumer can come to. But in the > Fedora context we are the producer, not the consumer. Developing an > operating system means considering what is best in the general case, > and in the general case, if using the system requires a > known-dangerous configuration, we've done our job poorly. Sure. > Phrased another way: no, it's not *your computer* we're talking about > here. The computer in question rightfully belongs to someone else; we > are here discussing how to be responsible for the code they allow us to > run on it. That is a reasonable point for view. However, the point of Free Software is freedom; and the ability to shoot oneself in the foot is part of that freedom. One of the greatest advantage of Free Software from my point of view is that people can choose. And I know that I am not alone in chooing to use (and to write) Free Software for that reason: freedom is not just about strict licence compliance. Five years or so ago I publicly defended Wayland because I was assured that things would continue to work after the transition. Being able to edit files with emacs is an essential part of that "continuing to work." Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: On running gui applications as root
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 rightfully belongs to someone else; we >>> are here discussing how to be responsible for the code they allow us to >>> run on it. >> >> That is a reasonable point for view. However, the point of Free >> Software is freedom; and the ability to shoot oneself in the foot is >> part of that freedom. One of the greatest advantage of Free Software >> from my point of view is that people can choose. And I know that I am >> not alone in chooing to use (and to write) Free Software for that >> reason: freedom is not just about strict licence compliance. >> >> Five years or so ago I publicly defended Wayland because I was assured >> that things would continue to work after the transition. Being able >> to edit files with emacs is an essential part of that "continuing to >> work." >> > I don't see how a lack of access to the GUI when running as root will prevent > Emacs from editing root-owned files. > > TRAMP (if you wish to stay inside emacs) and "sudo -e" (if you'd rather work > outside emacs) both provide mechanisms (that I use today under X11) for emacs > to edit root-only files while the vast bulk of emacs runs as my user ID. > > Put another way: "sudo emacs /etc/hosts" will break under Wayland. That's bad. > "sudo -e > /etc/hosts", "emacsclient /sudo::/etc/hosts" and "emacs /sudo::/etc/hosts" > will all still work as they do today, as will "emacs --eval (find-file > /sudo::/etc/hosts)" I'm complaining about people breaking stuff that Just Works and has worked for *decades*. And they're doing it "because security" or "because I don't do it that way." I see that it's possible to get around the problem in some cases, either by some elaborate shell scripting or (in this case) a special recipe for editing files. But that's really not the point. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: On running gui applications as root
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 https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: On running gui applications as root
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 virt-manager without root. And finally, it's *my computer*, dammit. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: On running gui applications as root
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 normal user. Sure, but even that is a UI regression: applications which ask for the root password discourage long root passwords and train people to type the root password whenever it's asked for. I should not even need to know the root password. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: On running gui applications as root
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 to >>> manage the libvirtd that runs as privileged mode, but even in that >>> case the user interface would run as your normal user. >> >> Sure, but even that is a UI regression: applications which ask for >> the root password discourage long root passwords and train people >> to type the root password whenever it's asked for. I should not >> even need to know the root password. > > Well you'll be pleased to know then that virt-manager doesn't normally > ask for the root password. If you're in the libvirt group then I don't > think it will ask at all, otherwise if you're an administrative user > then it will ask for your password. OK, fair enough. That must be more recent than the host system I use. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
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 maintainer should have to do. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
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. >> >> Well, hold on: you now have the problem of maintaining a local fork. >> Surely that is more than a package maintainer should have to do. > > I disagree. This kind of integration patches is what a distribution > is for to begin with. If users wanted to use vanilla upstream > tarballs with no modifications whatsoever, they'd use LFS. (And in > practice, even LFS has patches they make you manually apply, because > the tarballs won't even COMPILE together as is.) Hmm. I suppose, then, it's a matter of degree: just how much of this porting work can people do for a distro? I understand your point, and it's defensible enough from a principled point of view. However, it requires a packager to be a fairly expert developer of what they package, and to have time to do it. I guess most libraries aren't so bad that it's a huge problem. My instinct is to agree with you because stable APIs are pretty much a prerequisite for a stable operating system: you can't build anything solid on shifting sand. But all distros are, in the end, no better than their upstreams, and API stability is only one aspect of quality and reliability. But sometimes an API changes because a library has been refactored; and it may not even be possible to provide the old interface because an entire class of functions has been removed, perhaps for a very good reason. But that argues for versioned libraries, not bundling, even if a library is only used by one package. At least that way the package gets tested with the library version it was built with... but then we end up with version hell if two libraries need different incompatible versions of libXX.so, and some package uses both of them. Argh! There's no simple way to do it, and no rule that will fix it. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: what it takes to unbundle, in triangle form
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 perspective is not the best practice or not >> including a package at all. I'd certainly prefer to see a somewhat >> smaller well-engineered system than open the doors to packages with >> their own versions of dependencies, each with their own set of bugs. > > The thing is, this is only one aspect of the quality of the packaging — > and let alone bugs and problems in the code itself, which are usually > even bigger in terms of user impact. So, making *this* particular facet > the deciding factor doesn't quite seem right to me. Me either, but of course I didn't say that. IMO it's necessary but not sufficient. > I think the *general* idea, of having a smaller-well engineered core is > a good one. It's just really hard to define exactly what that is, > let alone to do the practical work of untangling dependencies. But > that's basically what the "Fedora Modularization" initiative is all > about. I accept that point. > From an unrelated practical point of view: consider that the metadata > pulled down so DNF can operate is basically the same size as the entire > (compressed) Fedora Cloud Base image. It'd be very nice to not have > that overhead (but still have wider package set available when you want > it). It certainly would, but fixing the DNF metadata problem is a whole 'nother ball of wax! Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: what it takes to unbundle, in triangle form
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 policies. > > I'm still generally in favor of that (and there's lots of room for it > even with the bundling change). But, really, what would it solve above > having everything together and having some kind of "Packaging Quality" > metric for each package? Maybe we're trying to do too much. I suppose it's a question of choosing to do something which from a software engineering perspective is not the best practice or not including a package at all. I'd certainly prefer to see a somewhat smaller well-engineered system than open the doors to packages with their own versions of dependencies, each with their own set of bugs. It would make more sense to push such packages into a separate repository rather than making them part of the OS, or perhaps not packaging them at all. Such badly-packaged projects are IMO not something that should be in a high-quality OS anyway. And I have no doubts about Fedora as a high- quality OS: I presume that is our intention, especially with Red Hat Enterprise Linux and CentOS downstream. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
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 everyone do that. Then > maybe we can see if that is the way to software install nirvana or > if admins start complaining about not being able to maintain their > systems in a rational way. We can then point these latter folks > upstream and say this is what these folks wanted you to do, talk to > them about it. The development model followed by much of the upstream world is immature: it may not even be repeatable, let alone well-defined. Shoehorning upstream's mess of bundled requirements is a very useful service that we can provide to our users. By behaving in a mature way we can show that free software can be more reliable (predictable, trustworthy) than proprietary software. I remember the time before free software distros like Fedora: it was chaotic, with messes of bundles and contradictory dependencies from all over the place, with no reliable tools for finding things. Relying on the upstream ecosystem's way of sorting this out, with a different mechanism provided depending on programming language, isn't going to do it. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
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 sense, I feel you are undermining and torpedoing Fedora. Yeah. In that sense we have a responsibility for raising the bar, showing how a real OS should be done, with fewer of the kludges and shortcuts which plague lesser offerings. We can do better, we have the skills, we know it's the right thing to do, so we should. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Rapid release for security updates
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 update stability policies enforced by Bodhi simply need to be repealed. This problem simply did not exist when maintainers were still trusted to be able to do their job. Or maybe we should modify them for urgent security updates rather than repeal them totally. We certainly have delays with Java security updates on Fedora. Something needs to be done, but I'm not sure exactly what. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
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). That's right. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
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, Freemind, Azureus, Eclipse...) will start using this JDK but they will contain jars compiled for newer JDK thus will fail at runtime. Exactly. But it's worse than that: someone sets an alternative for some temporary purpose, then reboots their computer, then they get pwned via the vulnerable Java. I'm all for freedom, but we should not install traps for our users. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
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 very same discussion is our attempt to pass the ball back to the Community. It's not just a matter of not being able to afford to continue maintenance, but the knowledge that unless an obsolete Java implementation is carefully locked down it may not be safe to use. This proposal is intended to prevent the accidental use of an obsolete implementation. Some of the proposed rules can reasonably be argued about, but the need to prevent an obsolete Java implementation from accidentally being used by any part of the Fedora stack isn't. Of course, if a user decides to override this that's fine, and we should not make it unduly difficult, but it shouldn't happen by default in any Fedora installation. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
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 a simple practical reason: All the JARs we ship are built from source with our default JDK. They will in general NOT work on any JRE that's older than the default JDK. That's the idea. This is not for any part of the Fedora Java stack. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to (formally/easily) allowing multiple versions of the same library installable
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 programs that are part of Fedora rather than programs that a user installs from elsewhere. While this may be true, it's not necessarily a good thing. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Access to failed builds [Was: gcc5 ICE xserver build on ARM]
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: when a build goes wrong a GCC developer needs to be able to see what went wrong, and that means direct access to the box so that they can reproduce the problem. So what might we do to solve this? Is there some way that we can freeze the contents of a buildroot to allow a dev to get in there and poke around? Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: amending the new package process
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 process condenses into All proposed changes must be peer-reviewed by somebody who is formally in charge of a component to be changed. Exceptions apply for obvious changes. It has been a while since I have last been following the GCC mailing lists (so this may or may not have changed since then), but at least back then, a maintainer for a given part of GCC was allowed to commit to that part of GCC without having it reviewed by a second person, and a global maintainer was allowed to commit to ANY part of GCC without having it reviewed by a second person. If you were allowed to approve other people's commits, you were also allowed to approve your own. There were also people only allowed to write after approval, but that was only the default/least-trusted level of commit access granted, and write after approval developers were also not allowed to review other people's submissions (unlike our system where any packager can review other packager's submissions, but never their own). Has this changed since? No. It is as you describe. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Abotu setting 'PermitRootLogin=no' in sshd_config
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 return on investment. At some loss of usability. To often we hear This is better for security, therefore we should do it without considering the usability trade-off. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ExcludeArch tracker doesn't appear to be effective
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 requirements. Fedora includes a lot of packages, some of which are not of mainstream interest. Because of this lack of interest in their packages, some upstream maintainers haven't ported to ARM. Some upstream packages may not even still be actively maintained. How can we fix this? We have to look at this on a case-by-case basis. We might have to ask if a package really is relevant to a general-purpose operating system. [Some packages may have been abandoned upstream. So, they will never be ported to ARM.] Let's look at Bug 1004357 - root no available on ARM due to cint. The upstream maintainers say: We will not implement vararg support for that platform in ROOT 5. It's not trivial and we have to spend our time getting ROOT 6 baked. Thanks for your understanding! So, what should we do? Should we block Fedora from running on ARM because of the lack of upstream support for the ROOT numerical data analysis framework? No! That would be ridiculous. It would mean that Fedora on the ARM target is held hostage by this package. Special-purpose packages are all well and good, but Fedora on ARM is (IMHO, YMMV) far more important than those packages. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaning java-1.5.0-gcj
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 CPU architectures. I didn't know that. It makes some sense, though, given that differ OSs have different toolsets. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Deprecate setjmp/longjmp? [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]
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 setjmp()-freeness a requirement for all code included in Fedora. Would it be worth the effort, and how feasible is it anyway? I don't think it'd be worth the effort, and I think the burden of computing feasibility should rest with those who think it _is_ worth the effort. Well, we could consider banning it from new packages and just let attrition take care of the rest. We could. I still wouldn't consider that a productive use of time. It's a rare API that can't be misused, I'd much prefer if we approached code quality by _actually reading the code_ rather than deciding with grep what we will and won't accept. I know that's a radical idea, that as packagers we ought actually to know the language of the code being packaged, but I think it has merit. Indeed. setjmp has its uses; they're not very common, but it's not unreasonable for an upstream programmer to use setjmp. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaning java-1.5.0-gcj
On 04/07/2014 03:23 PM, Peter Robinson wrote: There have been a few discussions about this in the past but no action. With feature freeze approaching for F21, I think this is a good time to address this. I will be orphaning java-1.5.0-gcj in Fedora on April 8th. If anyone wants to take over, 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 the various variants of ARM we needed this for bringup of the newer releases, is that still the case or is there other means of achieving that? As of JDK8, OpenJDK can be cross-compiled. Not before time, either. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GCJ [was: pdftk retired?]
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. It doesn't claim to be anything more than that, so I don't see the harm in leaving it there. Speaking as the upstream maintainer, I do. Hi Andrew, can you be a little more specific about the potential harm you see with keeping GCJ in Fedora? I think Rahul already answered this. Do you expect me to say something different from him? Well, speaking of harm, yes, I do. Don't take me wrong. I just want to know if there is any reason beyond maintainer unwillingness/ lack of time. No, I don't think there is, beyond the usual objections to leaving packages to rot. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GCJ [was: pdftk retired?]
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 it there. Speaking as the upstream maintainer, I do. Hi Andrew, can you be a little more specific about the potential harm you see with keeping GCJ in Fedora? I think Rahul already answered this. Do you expect me to say something different from him? Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GCJ [was: pdftk retired?]
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 - because of GCJ dependency. iText is second issue. The first could be fixed by rewrite of offending part of code to Java but someone would have to do it first. That's how I understand this situation. The only things I read in the thread are GCJ is abandoned and we really want to get rid of GCJ. Am I supposed to come to the conclusion that the GCJ package is dropped from Fedora? If so, where is this decision made? Why was it made without consulting GCJ users? The problem is more to do with upstream maintainership. If GCJ is to be used in the future it needs to be updated to a current version of the Java class library, but that's a lot of work. GCJ is still a pretty good compiler for the Java language, but it's stuck at JDK5 (ish). 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 it there. Speaking as the upstream maintainer, I do. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
GCJ [was: pdftk retired?]
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 rewrite of offending part of code to Java but someone would have to do it first. That's how I understand this situation. The only things I read in the thread are GCJ is abandoned and we really want to get rid of GCJ. Am I supposed to come to the conclusion that the GCJ package is dropped from Fedora? If so, where is this decision made? Why was it made without consulting GCJ users? The problem is more to do with upstream maintainership. If GCJ is to be used in the future it needs to be updated to a current version of the Java class library, but that's a lot of work. GCJ is still a pretty good compiler for the Java language, but it's stuck at JDK5 (ish). Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 the path? the *writeable for the user* is the problem Any reference for this problem? what about consider the implications? do you really need a written reference for any security relevant fact? i can write one for you if you prefer links :-) Well, the question is really if someone else out there share your concerns about this. Why does it matter? A hidden directory in everyone's path is obviously useful to an attacker, and (IMO) more useful to an attacker than to a user. You shouldn't need any references. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 10:53, schrieb Alec Leamas: Some kind of reference for the bad in having a well-known, hidden directory in the path? the *writeable for the user* is the problem Any reference for this problem? what about consider the implications? do you really need a written reference for any security relevant fact? i can write one for you if you prefer links :-) Well, the question is really if someone else out there share your concerns about this. Why does it matter? A hidden directory in everyone's path is obviously useful to an attacker, and (IMO) more useful to an attacker than to a user. The attacker needs to be able to write to your home directory to take advantage of it. And if he can do that (you lost) he has numerous other ways of doing it. That is true. However, there is an advantage to this one for the attacker: the user probably doesn't know it's there. It's a matter of the attack surface: the 'sum of the different points (the attack vectors) where an unauthorized user (the attacker) can try to enter.' [Wikipedia] Having a writable and hidden directory in everyone's path increases the attack surface. Having the current working directory in everyone's path increases the attack surface, etc, etc. Defence in depth is about reducing the attack surface. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora/Redhat and perfect forward secrecy
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 insanely slow? Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: ARM as primary Architecture
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 slow down the other architectures Is that you don't get to be a primary architecture unless you have demonstrated that nobody outside of the ARM SIG needs to do any work on the architecture == you don't get to be a primary architecture unless it doesn't matter whether you are a primary architecture? Promotion is supposed to benefit Fedora, not the architecture being promoted. Is this some rule that I don't know about? Surely promotion is supposed to benefit Fedora's users. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Where are we going? (Not a rant)
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 software out there they're going to have to upgrade regularly. Otherwise, it's not going to be the latest software. How in the world could it possibly be any different? Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LibRaw: possible license issues
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 exceptions for applications is so widespread in GStreamer land (Totem, PiTiVi, Rhythmbox, Transmageddon, etc.) that I was not comfortable with having a situation where the application silently ends up under a different license due to another library. I don't think that's a problem because the whole purpose of the or any later version of the GPL, at your choice is to allow the GPL to be updated. You don't think that it is a problem that our downstreams might inadvertently end up violating the GPL by shipping GPLv3 code that links to non-free software? I am not saying they are, but the chances are too high for me to take this lightly. Again, if they are doing this then they are already violating the GPL by shipping GPLv2 code that links to non-free software. The v2 versus v3 thing is a red herring. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LibRaw: possible license issues
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 License tag was changed from LGPLv2 or CDDL to GPLv3 when the two demosaic packs were added [1]. One of the demosaic packs is GPLv2+ and the other is GPLv3+. However, http://www.libraw.org/ mentions LibRaw's license as GPLv2+, while the source files continue to claim that they are under LGPLv2 or CDDL. Shotwell, which uses LibRaw, is LGPLv2+. By my reading of the compatibility matrix [2], it means that Shotwell is now effectively GPLv3. If it's linked with a GPLv3+ demosaic pack, it must be GPLv3+. 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+. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LibRaw: possible license issues
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 matters because Shotwell links to GStreamer. GStreamer applications either opt for LGPLv2+ or GPLv2+ with exceptions because they might end up using proprietary or otherwise unfavourably licensed GStreamer plugins . Which is fine, because GPLv3+ is compatible with LGPLv2+ or GPLv2+. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LibRaw: possible license issues
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 using proprietary or otherwise unfavourably licensed GStreamer plugins . Which is fine, because GPLv3+ is compatible with LGPLv2+ or GPLv2+. You missed the proprietary or otherwise unfavourably licensed part. :-) There are proprietary GStreamer plugins for patent encumbered formats. eg., the MP3 codecs from Fluendo. Granted that Fedora does not ship such GStreamer plugins, but some of our downstreams do. (I don't think I am allowed to get into specifics here.) OK, so there are some proprietary or otherwise encumbered plugins that might not be GPLv3-compatible but might be compatible with GPLv2. And you're worried that some unwitting user might by mistake break the terms of a licence. Or, perhaps, some downstream might not be able to ship a plugin because they fear it's not allowed. Plus, this practice of either using LGPLv2+ or GPLv2+ with exceptions for applications is so widespread in GStreamer land (Totem, PiTiVi, Rhythmbox, Transmageddon, etc.) that I was not comfortable with having a situation where the application silently ends up under a different license due to another library. I don't think that's a problem because the whole purpose of the or any later version of the GPL, at your choice is to allow the GPL to be updated. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem with a static bundled library in a package
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 Fedora, I know, but revising the original code of the library sha* Fedora already has about ten crypto libraries, and you'll not get much support for another one. The NSS library probably gets the most attention, and it's hyper-fast optimized for Intel chips. It's also validated. There is no reason to include a static bundled library to do SHA*. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
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 process I want to talk to. A form of authentication, which I already explained. More than once. You have _claimed_ that it's a form of authentication, but you've produced no reason to believe that it is. How do you know that the exact same binary isn't running as some rogue user, with other data injected into it? 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 that to do that is at the present, time computationally intractable. So, it's very unlikely that it's happened unless your opponent is prepared to spend huge resources on you. It's mathematically possible, you know. Any authentication mechanism, short of a mind ray-beam implementation over the Internet, can be defeated. It's only a matter of how much resources are required. Even if some particular approach is not 100% NSA-grade bulletproof, it does not mean that it's worthless. I reject that claim. And this is just another feeble attempt to change the topic. The degree to which this kind of authentication is or isn't reliable, is completely irrelevant and has no bearing on the problem that prelink is creating, by rewriting executables which are currently running. That, I believe, can be evaluated on its own merits. Indeed it can. If what prelink is doing is hunky-dory, then why is it that its wrapper has special-case band-aid init? What's a special-case band-aid about it? It looks perfectly reasonable to me. Why wouldn't you restart init? That's a defacto acknowledgement that prelink is broken, and this is just a lame, pathetic coverup for one of the breaks. But this is nothing to do with prelink. It's to do with your totally bogus assumption that /proc/self/exe is a reliable way to get the binary image of the executable that started current process. It isn't, it never has been, and it never will be. And this is true not just because of prelink; even without prelink you'll still have to be able to cope with this situation. The basic principle of robust programming is that you must expect the unlikely and treat it as normal. This is a classic case of that principle. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
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 that to do that is at the present, time computationally intractable. So, it's very unlikely that it's happened unless your opponent is prepared to spend huge resources on you. But it's not impossible. No, and neither is it impossible that your computer will turn into a bowl of petunias. Same thing here. It is very unlikely that /proc/pid/exe gives you the pathname that was used to start the executable. But just because there are marginal situations where it might not work does not invalidate its value-added benefits. If what prelink is doing is hunky-dory, then why is it that its wrapper has special-case band-aid init? What's a special-case band-aid about it? It looks perfectly reasonable to me. Why wouldn't you restart init? Why would you? If there's nothing wrong with with overwriting an executable, and, after all, that's how UNIX worked forever, then why bother restarting init? Hmm, isn't this to make sure that init is using the current libraries and not holding open the old ones forever? Sounds perfectly reasonable to me. But this is nothing to do with prelink. It's to do with your totally bogus assumption that /proc/self/exe is a reliable way to get the binary image of the executable that started current process. It Well, that's only what proc(5) says it is. Maybe we can fix the man page then. And it works every time. Until prelink overwrites the executable. But that's just the point: until something overwrites the executable. isn't, it never has been, and it never will be. And this is true If the contents of the /proc/self/exe symlink are something random and unrelated, then I think that proc(5) needs to be updated to reflect that. Perhaps so. At best it's only the path to the executable that started the program. not just because of prelink; even without prelink you'll still have to be able to cope with this situation. The basic principle of robust programming is that you must expect the unlikely and treat it as normal. This is a classic case of that principle. No, this is a classic case of denying the problem's root cause, The root cause is the filesystem behaviour of UNIX that allows a program to continue even though its executable file has been rewritten. That's a feature, not a bug, and it's what allows updating to be done without restarting. and blaming something else, which exposes the problem. You have a clear choice. You can either write a robust program that can continue to run in the presence of prelink, updates, and anything else that might change its executable, or you can continue to blame the OS and have a program that is not robust. Your call. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
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 to crack the right prime. Because we know that to do that is at the present, time computationally intractable. So, it's very unlikely that it's happened unless your opponent is prepared to spend huge resources on you. But it's not impossible. No, and neither is it impossible that your computer will turn into a bowl of petunias. Same thing here. It is very unlikely that /proc/pid/exe gives you the pathname that was used to start the executable. But just because there are marginal situations where it might not work does not invalidate its value-added benefits. If what prelink is doing is hunky-dory, then why is it that its wrapper has special-case band-aid init? What's a special-case band-aid about it? It looks perfectly reasonable to me. Why wouldn't you restart init? Why would you? If there's nothing wrong with with overwriting an executable, and, after all, that's how UNIX worked forever, then why bother restarting init? Hmm, isn't this to make sure that init is using the current libraries and not holding open the old ones forever? Sounds perfectly reasonable to me. Ahh, Jakub corrected this. Sorry for the bad info. The rest stands, in particular: You have a clear choice. You can either write a robust program that can continue to run in the presence of prelink, updates, and anything else that might change its executable, or you can continue to blame the OS and have a program that is not robust. Your call. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
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 certainly trust it. But just because I trust it, it doesn't mean that any additional checks have no value. Sure it does. If the credentials are always correct, additional checks past that are a waste of cycles. You feel absolutely confident that just because you can't think of any value of additional checks, there cannot possibly be any. You're wrong. I ask again: do you have a legitimate use case? Is there _any_ case that other checks can succeed that this invented test of yours would catch? I already explained what they are. 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, or the post-prelinked version of the same executable. Anyone who suggests readlinking /proc/self/exe, then the other /proc/pid/exe, and comparing them sans any hardcoded (deleted) suffix is going to get only howls of laughter, in response. 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. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
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, or the post-prelinked version of the same executable. Anyone who suggests readlinking /proc/self/exe, then the other /proc/pid/exe, and comparing them sans any hardcoded (deleted) suffix is going to get only howls of laughter, in response. 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 process I want to talk to. A form of authentication, which I already explained. More than once. You have _claimed_ that it's a form of authentication, but you've produced no reason to believe that it is. How do you know that the exact same binary isn't running as some rogue user, with other data injected into it? And we've been over this. Yes we have. You've made claims, none of which you've justified. Or you may have done but I missed them. But as it stands this is an utterly hopeless way to authenticate anything. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
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 file is a normal UNIX process state so a UNIX It is anything but normal. The normal state of things is documented by proc(5). As documented by that man page, rather plainly, readlink(/proc/self/exe) gives you your own pathname. Yes, it's the pathname that started this process. Yes, that pathname may point to file that no longer exists. That's UNIX. That's how it has always worked, and will always work. Anyone programming in a UNIX environment has to cope with it. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [Full-disclosure] The right to read, debuggers and building future Fedora kernels
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Liberation 2.0 font development plan based on croscore fonts.
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 mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
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 devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
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. What exactly is the conflict? See the error from yum/rpm, that I posted. Oh, sorry, I tend to interpret conflict as meaning a conflict with another file, not a missing dependency. It seems to me that yum/rpm should know what package provides /bin/perl. This surelay makes vastly more sense than changig default paths, which is just papering over the cracks. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
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 is not smart enough to realize that the new package's /bin/perl=/usr/bin/perl, causing a conflict. What exactly is the conflict? See the error from yum/rpm, that I posted. Oh, sorry, I tend to interpret conflict as meaning a conflict with another file, not a missing dependency. It seems to me that yum/rpm should know what package provides /bin/perl. This surely makes vastly more sense than changing default paths, which is just papering over the cracks since /bin and /sbin are now gone it is completly wrong have them in the PATH and use them hardcoded in packages like GLIBC as also in any other package with Provides But we can't prevent them from being in the PATH, can we? All sorts of upstream packages might hard-code /bin:/usr/bin Why not take /bin and /sbin out of the default path *and* make sure that RPM knows about /bin/* ? this is a bug because incomplete UsrMove Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
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 PATH that's compiled into bash should be a simpler change to push through; I see very low risk of any breakage or regressions; and it will probably solve a great majority of the resulting foobarage that cascades downstream into rpm-land. Making rpm a bit smarter is certainly a correct fix, but something else can also be done relatively quickly to take care of most of the current fallout. Well, yeah. But the Law of unintended consequences applies, so we must be careful. I don't think that people expected symlinking /usr/bin to /bin to be risky either. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
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, tedious process. Which is understandable. But changing the default PATH that's compiled into bash should be a simpler change to push through; I see very low risk of any breakage or regressions; and it will probably solve a great majority of the resulting foobarage that cascades downstream into rpm-land. Making rpm a bit smarter is certainly a correct fix, but something else can also be done relatively quickly to take care of most of the current fallout. Well, yeah. But the Law of unintended consequences applies, so we must be careful. I don't think that people expected symlinking /usr/bin to /bin to be risky either. Errr… Wait. Then UsrMove script that ran when I upgraded F16 to F17 symlinked /bin → usr/bin If new F17 installs have /usr/bin → /bin, then this is an even bigger clusterfrak. It doesn't. Don't worry. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 to retrofit alternative operating systems onto those devices. I want to put it out there that this is _not true_. The problem with this claim is that it equivocates on the meaning of a right. There are at least two definitions of a right in this sense: moral rights and legal rights. These are not the same. Moral rights are not in the gift of any Government. While we may not have a legal right to run whatever software we wish on hardware we own, it's not at all unreasonable to claim a moral right to do so. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
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 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. I think I'd disagree with you there. I don't think it's any different from someone using extensive technical measures to prevent anyone other than the authorized dealers of a particular car from servicing it. Such a move would be treated as anti-competitive in many countries, and IMO software should be treated in the same way. Possibly in this example someone might consider Nokia and Microsoft to be infringing their moral right, but (in the US at least) they'd have no recourse. Indeed. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/19/2012 04:50 PM, Eric Smith wrote: I 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 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 extensive technical measures to prevent anyone other than the authorized dealers of a particular car from servicing it. Such a move would be treated as anti-competitive in many countries, and IMO software should be treated in the same way. If the things that make it difficult to run software of your choosing on a device can be proven to serve no purpose but to stifle competition, then yes. But often those things have other purposes as well. For example, requiring firmware updates to be signed has a demonstrable purpose in preventing certain types of malware from infecting a product, so that feature cannot be said to serve no purpose other but to stifle competition. That's true, but couldn't you argue something similar thing for a car? As in, Unauthorized shops may install inferior copied parts. We've all heard this kind of thing before, and treat it with the contempt it deserves. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
LLVM [Was: julia language]
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 in case anyone else wants to play with it. I'm interested in your experience with LLVM. We used it to create the Shark Java VM, but we had a lot of difficulty with LLVM JIT stability on non-x86 targets. If LLVM is looking healthier it might be interesting to revisit Shark, which essentially combines HotSpot and LLVM to create a portable JVM. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM and SecureBoot
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 much credit, and without considering or conceding whether such a machine would be non-free - I'm pretty sure I am willing to sacrifice a minor technical point of software freedom for real gains in human freedom. I suppose I don't know what minor technical point of software freedom you're talking about. I presume it's not the freedom to change a program so it does your computing as you wish, which is scarcely a minor anything. It's more like is building or supporting a machine with this kind of lockdown intrinsically non-free. Well, that depends. Can you change the program (in this case, a kernel) and run it, or not? It's not a difficult or obscure question. I didn't intend to make it sound like you were advocating that kind of objection, I apologize if I put words in your mouth there. I'm not objecting, I'm just trying to find out what's up. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM and SecureBoot
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, so why would supporting them be any different from doing the same on x86? For Windows 8 certification on ARM, Microsoft is going to require UEFI with Secure Boot enabled _and_ no method for users to disable Secure Boot or enroll their own keys (the opposite of x86 where they require a disable method and custom key enrollment support). 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 wants to build an arm machine with SB support capable of running non-Windows operating systems, why would we not want to run there, and why would enabling that look any different from self-signing an x86 machine? Forgive me if I'm missing something, but surely the reason we would not want to run there is that our users would not be able to do so as well: they wouldn't be able to modify our kernel and run it on their machine. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM and SecureBoot
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 wants to build an arm machine with SB support capable of running non-Windows operating systems, why would we not want to run there, and why would enabling that look any different from self-signing an x86 machine? Forgive me if I'm missing something, but surely the reason we would not want to run there is that our users would not be able to do so as well: they wouldn't be able to modify our kernel and run it on their machine. I chose my words carefully. I think you're hearing Secure Boot on arm and concluding immutable Secure Boot configuration, which to my knowledge is not a given. It's a given for machines that will ship with Windows for arm on them, and one can choose to be angry at Microsoft for that I suppose, but that's not necessarily a statement about the broader arm ecosystem. Personally I really like the idea of establishing my own trust chain on my own machines. I like the idea that I can get the assurance that my firmware hasn't been rooted _and_ not rely on anyone else's cert safety practices but my own. If I'm the sort of person who's taking my computer into hostile territory - insert oppressive government of choice here - that level of trust is potentially life saving. I have no objection to such a secure boot either. 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 much credit, and without considering or conceding whether such a machine would be non-free - I'm pretty sure I am willing to sacrifice a minor technical point of software freedom for real gains in human freedom. I suppose I don't know what minor technical point of software freedom you're talking about. I presume it's not the freedom to change a program so it does your computing as you wish, which is scarcely a minor anything. Software freedom is a means, not an end. Microsoft's requirements for SB on x86 enable that kind of trust for Linux (and for anyone else who wants it). It's possible to build arm machines the same way; they won't be able to run Windows, but whatever, as if I want to run Windows anyway. If arm machines like that were to exist, why _wouldn't_ we want to support them? For that matter, why would we not want to enable building them? As long as the technology isn't used to bind users, no reason at all. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x32 abi support?
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 -m64 and -m32, same workload. What workload, though? Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: disruptive libffi upgrade
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 internal debugging functions that should never have been exported have been removed: void ffi_stop_here(void) void ffi_assert(char *expr, char *file, int line) void ffi_type_test(ffi_type *a, char *file, int line) 2. A new function has been introduced to support variadic functions (ffi_prep_cif_var). Libtool's guidelines for .so versioning mandate that I move from libffi.so.5.0.11 to libffi.so.6.0.0 (because functions have been removed). There are more than a handful of packages that depend on libffi, so I'm looking for advice on when to make this change. Also, is there a convenient way to determine which packages in all of Fedora depend on libffi? I would like to notify the maintainers that rebuilds will be required. Or is there some other way to do this? I don't think we need this for F17. F18 will do. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gforth and gcc 4.7
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 0x00 as seen in following diff:
010: 6566 696e 6564 2047 4458 2020 594f 5520 efined GDX YOU
020: 5348 4f55 4c44 2053 4545 2054 4845 2053 SHOULD SEE THE S
030: 5441 4e44 4152 4420 4752 4150 4849 4320 TANDARD GRAPHIC
-040: 4348 4152 4143 5445 5253 3a00 2021 2223 CHARACTERS:. !#
^^ actual output
+040: 4348 4152 4143 5445 5253 3a0a 2021 2223 CHARACTERS:. !#
^^ expected output
050: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%'()*+,-./0123
Removing -O2 from the compiler commandline fixes it, but I have no idea
why this happens. Does anyone have an idea how this can be solved?
If -O0 works and -O2 doesn't, first narrow it down using a binary search
between -O0 and -O2 compiled objects to at least a single compilation
unit, then you could use __attribute__((optimize (0))) (resp.
__attribute__((optimize (2))) ) and/or -fno-inline to narrow it even
further, read the problematic code, see if there aren't any e.g. aliasing
warnings (-O2 enables -fstrict-aliasing), if you don't spot a bug in the
gforth code after this and still suspect the compiler, turn that into
self-contained minimal testcase (for the problematic routine add main
that calls it with the right arguments, make the problematic
routine __attribute__((noinline, noclone)) and stub out anything it calls,
then file a gcc bugreport?
It's this bug, which returns the address of a local array:
diff -r f14bc589172e prim
--- a/prim Thu Apr 12 14:42:46 2012 +0100
+++ b/prim Thu Apr 12 14:51:21 2012 +0100
@@ -1950,7 +1950,7 @@
newline( -- c_addr u ) gforth
String containing the newline sequence of the host OS
-char newline[] = {
+static const char newline[] = {
#if DIRSEP=='/'
/* Unix */
'\n'
We might as well also fix this other bug, which prevents the disassembler from
working:
diff -r f14bc589172e dis-gdb.fs
--- a/dis-gdb.fsThu Apr 12 14:42:46 2012 +0100
+++ b/dis-gdb.fsThu Apr 12 14:51:21 2012 +0100
@@ -25,7 +25,7 @@
: disasm-gdb { addr u -- }
base @ r hex
s\ type mktemp /dev/null type gdb /dev/null file=`mktemp -t
gforthdis.XX` file2=`mktemp -t gforthdis.XX` echo \set
verbose off\nset logging file $file\nset logging on\ndisas save-mem ( addr u
addr1 u1 )
-addr 0 # bl hold # #s 'x hold # # append-extend-string #
+addr 0 # bl hold ',' hold # #s 'x hold # # append-extend-string #
addr u + 0 # # #s 'x hold # # append-extend-string #
r base ! cr
s\ \nset logging off\nquit\n\ $file2 gdb -nx -q -p `ps -p $$ -o
ppid=` -x $file2 2/dev/null /dev/null rm $file2 grep -v \of
assembler\ $file rm $file append-extend-string
Andrew.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gforth and gcc 4.7
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 4458 2020 594f 5520 efined GDX YOU 020: 5348 4f55 4c44 2053 4545 2054 4845 2053 SHOULD SEE THE S 030: 5441 4e44 4152 4420 4752 4150 4849 4320 TANDARD GRAPHIC -040: 4348 4152 4143 5445 5253 3a00 2021 2223 CHARACTERS:. !# ^^ actual output +040: 4348 4152 4143 5445 5253 3a0a 2021 2223 CHARACTERS:. !# ^^ expected output 050: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%'()*+,-./0123 Removing -O2 from the compiler commandline fixes it, but I have no idea why this happens. Does anyone have an idea how this can be solved? Did you ever get help with this? Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: Connotation analysis for Fedora Project codenames
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 personally I'd like to avoid any strict rule/policy as it could hurt our community, we don't have a proper set of skills to do the full analysis during the Board turn and I really hope with help provided by community we can avoid the naming problems in the future - just we need your, community, input. I'm sure that's the right approach. Any thoughts? PS: I like Christoph's comment in ticket - that as an international project we should be proud of our diversity. It is a chance and a burden at the same time, Fedora will face this problem often and we can do our best to respect others and their views. Indeed, but let's not get carried away, lest we end up in a situation where no town that ever had a brewery can be named because it might theoretically offend a religion that forbids alcohol consumption. I'm sure you'll be sensible. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
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 multi-core multi-threaded. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
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 alternatives that are acceptable to FESCo, or provide proof that the requirement will be met within an agreed time frame. ARM should most definitely NOT be approved as a primary architecture before all the requirements are actually met! Hold on, these requirements are something you just made up to suit your argument. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
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 installed on them? Where is the hardware? Do you see signs of ARM boards coming in the near future (next 1 year or so) on which users can install operating systems of their choice? I wonder where you've been. See Raspberry Pi and Trimslice for a couple of recent ones. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
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 (throughput) level, but also on a doesn't destroy my workflow due to waiting on it (latency) level. Sure. Absolutely is a concern for us, as you can see from my other comments above about the kernel, for example, but not just that. Sorry, but I don't think this is fixable any time soon. Come back when (if ever) you have hardware which has comparable speed to x86. I'm trying to figure out what this means. Do you mean that any primary architecture must be as fast as x86 is today, or that it must be as fast as its contemporary version of the x86? So, if the x86 got faster but ARM didn't, then ARM would be dropped? The way I see the CPU market developing over the next few years is that the x86 will continue to be the speed demon if you measure MIPS per core, but other competitors, especially ARM, will focus on cores per die. If we stick religiously to comparable speed to x86 (whatever that means) Fedora can never be a primary arch for anything other than x86. Even if we have builders with dozens or even hundreds of cores. This is wrong, in my view. If we have a great many parallel processors waiting for work, times waiting for build won't be so great. The future does not look like ever-increasing MIPS per core, but ever-increasing parallelism. If Fedora is the OS of the future, we'd better start to embrace that. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Roadmap for Java things in Fedora
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 list as soon as F17 ARM is done to update GCJ to work with JDK7 files. I can't see any strong reason to nuke GCJ: it doesn't take very much maintaining, and I'm happy do do it. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
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 responsibility for that choice, like with any other technological choice. If you aren't will to either take downtime for Anaconda or preupgrade, or do lots of fresh installs, or mess with yum upgrades, use RHEL/CO/SL/Etc. Not for the feint of heart, and I sure as heck don't do it at work. :) For what it's worth, I *do* use it at work and on the whole I have very little trouble. Yes, upgrading can be a PITA, but it's usually just a few hours. I don't mind. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving gnustep to clang/llvm
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 EToile may works only in the llvm environment. So I would like to ask, if there any reason, which may blokcks this step for F-17. 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. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving gnustep to clang/llvm
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 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. Right, so it's probably not a gcc issue but a real bug in gnustep. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving gnustep to clang/llvm
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. Right, so it's probably not a gcc issue but a real bug in gnustep. The cited file objc/objc-api.h was provided by the gcc-objc package and was removed by gcc-4.7.0, so the reason for my issue depends on the gcc-4.7.0 packages. Ah, right. The old Objective-C runtime API has been removed. http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00571.html And, I guess the gnustep maintainers don't want to update. I suppose there's not much choice for the time being. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Moving gnustep to clang/llvm
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 clang/llvm too. I guess we should ask Nicola. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Canonical Will Remove Java From Ubuntu
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 of (infrequent, but persistent) alarms about incompatibility between OpenJDK and proprietary JDK? To know for certain I'd have to trawl all the bug reports, but they seem to boil down to web plugin incompatibilities and assuming a particular layout of the installation. With regard to the plugin, it's much more compatible now, but we still have occasional problems with proprietary applications that make incorrect assumptions. It's particularly difficult with banks that have applications we can't even try. Oh, and we do have bugs sometimes. ;-) Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Canonical Will Remove Java From Ubuntu
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 entered), whilst it does work with Sun/Oracle java 6 and 7. I would much rather use OpenJDK but I haven't a clue how to track down what the problem is, knowing next to nothing about java. We will try to fix this if we can get enough information. FWIW -- and you may be surprised by this -- javaws and the browser plugin aren't part of Java Platform, Standard Edition (Java SE) or of OpenJDK but are a different project (IcedTea-Web) altogether. We have had very few compatibility issues with Java SE itself. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Canonical Will Remove Java From Ubuntu
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 that Java programmers assume. And we fix compatibility bugs if we can. I am afraid that most of these problems are caused by stupid developers who are using (against all advices they were given) com.sun.* classes (which I am said is the most common source of problems). There is no protection against stupid programmers, I am afraid. 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... ;-) Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package segfaults when built with -O2 but not with -O0
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 that's easier said than done. -fno-strict-aliasing might be your friend. It's always easier said than done! Still, one could argue that -fno-strict-aliasing is a fix, kinda sorta. My point is that you've got to do *something*; this warning must not be ignored. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package segfaults when built with -O2 but not with -O0
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 default -O2 is enough to stop this happening. This raises two questions (at least!): 1. Is it reasonable for me to flout the packaging guidelines by rebuilding with -O0 until this is resolved? 2. How to determine what the actual problem is, e.g. a problem with the way the code is written leading to unsafe optimizations, or a gcc bug? You're just going to have to debug it. To start with, build with warnings, and look at them all. If none of that works and you're stuck, I'll have a look. This is unlikely to be a gcc bug. Does the upstream package segfault? Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package segfaults when built with -O2 but not with -O0
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 https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposing Fedora Feature for private /tmp and /var/tmp for all systemd services in Fedora 17.
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 moment, the only way to share a file with other local users is to put it into a tmp dir. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bug in javac ?
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 it in 7: http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/4a3b9801f7a0 If you have code that resembles the above and would like to see the fix backported to 6, please feel free to open a bug. Thanks. Bug is open (#750301) This one should be submitted to the tools people @ Oracle rather than just patched into Icedtea, I think. Their input might avoid us breaking anything. It's worth a try, but they've been pretty unhelpful in the past. The OpenJDK6 toolset is a mess (being some fairly random point in the development of the 7 compiler) and their main contribution has being to break the TCK run. Perhaps, but we really need their input for anything non-trivial on the compiler. The type inference logic is very convoluted, and it is extremely difficult for anyone to look at a patch that fixes one thing and know that it doesn't break something else. It's really easy for a fix to work for, say, building JBoss but not Eclipse. It's arguable whether a patch for something that has been wrong for the whole life of OpenJDK 6 should go in now. On that note, a good initial test for this would be to see if the patched version passes the TCK. Then post to compiler-dev and jdk6-dev. Right. That's the right way to start. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bug in javac ?
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 resembles the above and would like to see the fix backported to 6, please feel free to open a bug. Thanks. Bug is open (#750301) This one should be submitted to the tools people @ Oracle rather than just patched into Icedtea, I think. Their input might avoid us breaking anything. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Java 7 for Fedora 16
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. The real cause is that optimizations used in an older VM are enabled by default. I still think we'll have to ship 6 and 7 in parallel. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
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 change. xdg doesn't mention anything to do with bin dirs. This is purely Fedora-local. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
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 editors gave up on normalizing /home layout and pushed the problem xdg-side) No, because this is not an xdg-mandated change. xdg doesn't mention anything to do with bin dirs. This is purely Fedora-local. xdg normalizes the /home parts that matter for interoperability. Other normalization groups like the FHS have already agreed they are the right forum to define /home layout conventions. It is pointless to try to start defining location conventions for binaries in /home fedora side and bypass xdg now. I can no longer tell whether you are for or against adding ~/.local/bin to the default PATH. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
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 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 change. xdg doesn't mention anything to do with bin dirs. This is purely Fedora-local. xdg normalizes the /home parts that matter for interoperability. Other normalization groups like the FHS have already agreed they are the right forum to define /home layout conventions. It is pointless to try to start defining location conventions for binaries in /home fedora side and bypass xdg now. I can no longer tell whether you are for or against adding ~/.local/bin to the default PATH. I am against discussing the problem without putting xdg in the loop Lennart reads this. He wrote: Nah, the basedir spec does not mandate the bin subdir. WHat I said in the bug report is that I think it makes a lot of sense to have the XDG basedir stuff in the $PATH. I have to say that a. xdg (in the form of Lennart) already is in the loop b. xdg doesn't require (or even suggest) ~/.local/bin and therefore c. This issue is purely Fedora-local, at least for the time being. Maybe xdg will decide to endorse ~/.local/bin; maybe not. Either way, it may be that this change to Fedora is premature. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User-level instance of /bin in PATH
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 brother. I've never heard of ~/.local/bin . Are there many people who use this? ~/bin is common. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
SELinux oddity
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
Re: Trusted Boot in Fedora
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? The purpose of the blob is to measure the system state; only the blob (and hardware reset) is allowed to restart the measuring process in the TPM. For this to work securely, the blob must be signed by someone that the TPM itself trusts - otherwise an attacker could replace the blob by something that lies about the system state. So, from a standpoint of hacking, it doesn't matter - users won't have the practical freedom to modify the blob anyway because they can't sign it. What we're saying, then, is that the TPM doesn't trust the owner of the computer, but its manufacturer. It's impossible for a user to decide who they trust. Surely, from a Fedora standpoint, this is a complete non-starter. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trusted Boot in Fedora
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
