Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora

[Jiri Vanek]

On 02/24/2015 08:36 PM, Sumit Bhardwaj wrote:

Hi All,

I have been reading this mail chain for some time and there is something I 
wanted to say. It's kind
of a long mail, I apologize for taking so much of your time but request you to 
please bear with me.
I work as a technical consultant on IBM WebSphere, IBM BPM, Java/J2EE and 
Python technology stacks,
who has to code on Java/J2EEquite often as well and I use Fedora 21 Workstation 
as my primary OS. My
field of work is such that I need to use JDK versions 1.4, 5, 6, 7 and 8, all 
from time to time.
This is because as time passed, solutions delivered to customers were built 
using incremental
versions of Java/J2EE specifications and were not frequently upgraded. In my 
role, the changes/fixes
I do to these enterprise apps are usually small and require only a certain jar 
file to be
recompiled, or in some cases only one class. In such cases, maintaining binary 
compatibility is a
must and for that I need to recompile that one jar/class with the original 
version of JDK that was
used to compile the rest of the project in the first place.

I use Oracle java in most cases due to corporate policies (for personal use, I 
use the latest
version of OpenJDK). Now as per Oracle's policy, which I am sure is similar for 
OpenJDK as well, a
particular version of JDK/JRE is updated till and even some time after the next 
major version is
released, and then at a certain Update level, Oracle stops supporting it. That 
update version
becomes the final update for that particular major release, and is sent into 
archives, while updates
keep on getting released for the current version.

With Oracle JDK, there are two installation approaches available for RPM based 
systems. They provide
an RPM package which installs java in /usr/java, i.e. in system area and the 
latest installed java
version become default. However, they also provides tarballs of JDKs, that 
contain certain standard
directory structure of JDK  intact inside one folder. These tarballs can be 
extracted and placed in
any place on file system and once JAVA_HOME is pointed towards these+PATH is 
locally updated to
include it, user can basically use this JDK without any issues. What version of 
Java is installed in
system as default, in system area (/usr/java) become irrelevant.

With IDEs like Eclipse and NetBeans the process is even simpler, as you can 
define these individual
folders as JDKs for particular API versions in IDE configuration permanently 
and while creating a
project can choose to use any of these "defined JDKs". This is the approach 
that I take. I have the
last updated versions of all the JDKs from 1.4 to 8 in my /opt folder. I have 
these configured in
Eclipse and NetBeans for each API version and I use them all as required by the 
project.

So I guess if OpenJDK can follow the same approach and can give an option to 
download tarballs of
older versions and use them in place, without requiring any installation, as a 
definite directory
structure, then the problem is solved. There is no need to maintain old version 
per se in
repositories, as these are not updated anymore and the user will be able to use 
multiple versions
without conflict of any kind. As for the default JDK, it can be kept how it is 
now i.e. The latest
available JDK can be maintained in Fedora repos as they are being maintained 
now and updates can be
provided for the defined lifetime of that JDK.

Let me know what you guys think about this approach.



This is lying on  openjdk table for long time to have  at least source tarballs... As you can see, 
nothing,.  However  once you are able to build jdk on your own,  nothing prevents you form mercurial 
clone of *any* version. So this is the way you should go.


If you wont binary images to be supported by openjdk itself, its completely different and more 
complex story.



J.

--
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

[Jiri Vanek]

On 02/24/2015 06:22 PM, Mikolaj Izdebski wrote:

On 02/24/2015 05:21 PM, Mario Torre wrote:

On Tue, 2015-02-24 at 15:37 +0100, Mikolaj Izdebski wrote:

On 02/24/2015 02:15 PM, Jiri Vanek wrote:

On 02/24/2015 12:43 PM, Mikolaj Izdebski wrote:

I am against official guidelines or policy for legacy JDK packages. I
don't think that any such policy is needed and it would only encourage
adoption of old packages for which there might be no security updates.


Well thats the point - people are calling for them. And wont to maintain
them with this risk.


I thought that the point of this change proposal was "enabling community
to maintain legacy JDKs", not encouraging people to package them without
good reason or without involvement to truly maintaining them. Packaging
older JDKs is *already* possible, so IMHO this change accomplishes
nothing but showing people how they can dump old, unmaintained software
into Fedora.


Well, in this case it would not be un-maintained, the Fedora package
would *not* be maintained *by us* (the Red Hat Java Team) indeed, but we
are still actively contributing to the upstream software in its various
versions. While you as a packager cannot specifically count on that,
there's still a level of confidence that the base software won't be
abandoned any time soon. And even when we will stop supporting those
older versions, the community will take over if there is a need for
that, exactly like we have done ourselves before.

Indeed, there's an overhead for the downstream maintainers, we may need
to drop specific version of OpenJDK, or skip a release, or do other
funny things and the Fedora maintainers will have to adapt, but this is
no different than usual I believe. Realistically, we are so conservative
with older JDKs that I doubt this will ever really be an issue.


Correct me if I am wrong, but in my understanding maintaining JDK
package requires a lot of ongoing work (including obtaining and applying


Here you are right,


patches, running TCK, pushing updates in timely manner and so on). JDK
maintainers should know this and I'm assuming that the amount of
required work is the main reason for them not wanting to maintain older
JDKs.



I would say here you are not. No one will force the legacy jdks to be uodated. And afaik there will 
be no need to do it somehow furiously.


Keeping package of EOLed programis actually most simple thing... (unles it FBfS and die by naturalk 
death)




The work required to add old JDK package to Fedora is relatively small
compared to ongoing maintenance work. Someone willing to truly maintain
JDK in Fedora should have knowledge about JDK packaging and they
shouldn't have problem finding time to come up with a working solution,
proposing and discussing it.

If you make the process of adding legacy JDKs to Fedora too easy then
someone without enough time and required knowledge will surely do that


Thats not an intention of the proposal.
But the need to highlight that regular review can not appy to java packages was 
necessary.


and we may easily end with unmaintained package. I'd rather not have old
JDK than have unmaintained JDK with security holes.


There is no workaround for human factor.



Package that doesn't pass review shouldn't be part of Fedora.


Well, if your goal is to reduce the user base of Fedora, I'm sure we can
talk about removing the JDK :)


We can't sacrifice our basic principles (such as passing review) for the
sake of increasing user base.



As told, it is not it. But java packages will not never ever pass regular review. And in adition the 
legacy ones will probably need to follow even more rules (aka this proposal...)


J.

--
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

[Mikolaj Izdebski]

On 02/25/2015 06:58 PM, Miloslav Trmač wrote:
>> On 02/24/2015 06:41 PM, Miloslav Trmač wrote:
>>> Hello,
 "java" would be the preferred JRE in Fedora. The package would have no
 content, but it would have Requires on preferred Fedora JRE, currently
 java-1.8.0-openjdk. This could be easily changed as default JRE changes.
 The same is for other binary subpackages of "java", respectively.

 All system packages would require subpackages of "java" as they do now
 (unless there is good reason not to). Users that install "java" would
 get latest JRE, which would be updated to new major versions as they
 become default. Older JDKs would not be removed during update (unless
 there is no maintainer and they are obsoleted as currently),
>>>
>>> AFAIK nothing obsoletes a package just because it is orphaned…
>>
>> If no volunteer shows up for maintenance of old JDK then it would be
>> deprecated and obsoleted, as it's was done with previous JDK packages.
> 
> How would that work _exactly_?

1) JDK maintainers announce deprecation in advance and call for
volunteers to maintain old JDK

2) when the time of deprecation comes, JDK package is reassigned to new
maintainer, if such showed up; no obsoletes are added

3) if there is no new maintainer then old JDK is redired in pkgdb,
blocked in koji and obsoleted by some other package

4) if maintainer shows up after old JDK was retired then he can just
revive package (passing review if needed); package release is bumped to
be higher that obsoletes

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
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

[Mikolaj Izdebski]

On 02/26/2015 08:45 AM, Jiri Vanek wrote:
>> I'm not really proposing as I haven't thought about this much yet, but
>> the idea was about be adding a few empty binary packages "java",
>> "java-devel", "java-headless" and so on (they could be subpackages of
>> javapackages-tools). Existing provides with the same names could be
>> removed from JDK packages.
>>
>> "java" would be the preferred JRE in Fedora. The package would have no
>> content, but it would have Requires on preferred Fedora JRE, currently
>> java-1.8.0-openjdk. This could be easily changed as default JRE changes.
>> The same is for other binary subpackages of "java", respectively.
>>
>> All system packages would require subpackages of "java" as they do now
>> (unless there is good reason not to). Users that install "java" would
>> get latest JRE, which would be updated to new major versions as they
>> become default. Older JDKs would not be removed during update (unless
>> there is no maintainer and they are obsoleted as currently), but users
>> could remove them with "yum autoremove", unless something requires older
>> JDK or they installed it explicitly.
> 
> Does it really seem to you as more simple  solution both for packagers
> and users?
> 
> it does snot to me...

Yes, IMO it is much simpler than the policy you are proposing.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
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

[Aleksandar Kurtakov]

- Original Message -
> From: "Jiri Vanek" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, February 26, 2015 9:52:42 AM
> Subject: Re: F22 System Wide Change: Legacy implementations of the Java   
> platform in Fedora
> 
> On 02/24/2015 05:21 PM, Mikolaj Izdebski wrote:
> > On 02/24/2015 04:59 PM, Pete Travis wrote:
> >> On Feb 24, 2015 8:32 AM, "Mikolaj Izdebski"  wrote:
> >>>
> >>> On 02/24/2015 02:17 PM, Aleksandar Kurtakov wrote:
> > I would much rather live without any legacy jdk, and if so then
> >> without any
> > rules. But not setting
> > them will bring chaos for majority of users.
> 
>  I have a question: Is there anybody that stepped in to maintain the
> >> legacy jdk?
>  If there is nobody to maintain it trying to come up with this
> >> guidelines now would be pointless.
>  In short I think that such guidelines would better be created *only*
> >> when there are interested parties, jointly with them and the process is
> >> played a bit by some copr repo or similar. Purely theoretical work is not
> 
> This pure theoretical work is based on various troubles various
> multiple/legacy jdks caused in last
> years.  So it is preventing the issues we know will rise.
> 
> >> needed.
> >>>
> >>> I fully agree with Alex here.
> >>>
> >>> I would add that if someone really wants to maintain older JDK in Fedora
> >>> then it should up to *them* to come up with a solution that will work
> 
> Them? ANy packaging/openjdk newbie? Cool. It will break and will breaak a
> lot.

As long as this happens in COPR repo until it's good to go I don't see a 
problem. This will also means that at the time it goes into Fedora we do not 
speak about newbie anymore. 

Alexander Kurtakov
Red Hat Eclipse team

> 
> Those guidelines were written to protect fedora from possible harm.
> 
> >>> and satisfy expectations of JKD maintainers and Java SIG. Maintaining
> >>> package is more than clicking "unorphan" in pkgdb.
> >>>
> >>> --
> >>> --
> >>>
> >>
> >> If some third party supplies 'java' as the $legacy jdk, and the user
> >> installs a Fedora package built on $current jdk, which provider will win,
> >> and what packages will break?
> >
> 
> Hopefully none. And the guidelines should prevent any unsuitable jdk to "win"
> automatically.
> 
> > It's implementation detail of different package management systems
> > (yum/dnf etc) and in general it's unspecfied. My experience shows that
> > multiple packages providing the same thing are unreliable in practice
> > and best avoided.
> >
> >> If the user uses alternatives to set the jdk (that applies here, right?)
> >> any applications that need one version or the other could break?
> >
> 
> I don't know how to avoid this issue. But at least it will happen - if happen
> at all - after the
> manual switch is done.
> 
> > Particular applications can be configured to use different JRE/JDK
> > versions (for example you can run Maven with Java 8, but Ant with Java
> > 7). Per-user configuration is also possible (user bob runs Maven with
> > Java 8, but fred with Java 7). Fedora is quite flexible in this aspect.
> >
> > Moreover, Fedora can be configured not to use alternatives for Java
> > apps, so you can have /usr/bin/java pointing to old JDK while Fedora
> > applications are running with default (latest) JDK.
> >
> >> I understand these are relatively ignorant questions, but if the aim is to
> >> provide a path for someone to maintain older JDKs it seems better to offer
> >> them guidelines and best practices instead of "you'd better be competent
> >> enough to figure it out".  They might not think of all the potential
> >> conflicts.
> 
> Yes, this sounds right.
> >
> > If someone wants to maintain old JDK they are free to do so. Moreover,
> > they will surely get help from Java SIG with implementing that, provided
> > they show enough involvement. But IMO packaging guidelines is not a
> What is an better place?
> 
> > place for listing details how compat packages for JDK should look like.
> >
> 
> Java SIG is busy enough. Why to add you more work?
> 
> J.
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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

[Mikolaj Izdebski]

On 02/26/2015 08:42 AM, Jiri Vanek wrote:
>>> Also, my proposal of introducing "java" metapackage (see my other post
>>> in this thread), which would always require the latest JDK, solves this
>>> problem in a different way, without modifying ordinary Java packages
>>> at all.
>>>
> 
> May you be more exact with the metapackage? Before I come up with
> legacy, I hoped to solve the issues via some metapackage. At the end I
> gave up, because the touch of user was always necessary.

I described it in much detail in other posts in this thread
(for example message-ID 54eca102.1070...@redhat.com)

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
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

[Jiri Vanek]

On 02/26/2015 09:20 AM, Mikolaj Izdebski wrote:

On 02/26/2015 08:42 AM, Jiri Vanek wrote:

Also, my proposal of introducing "java" metapackage (see my other post
in this thread), which would always require the latest JDK, solves this
problem in a different way, without modifying ordinary Java packages
at all.



May you be more exact with the metapackage? Before I come up with
legacy, I hoped to solve the issues via some metapackage. At the end I
gave up, because the touch of user was always necessary.


I described it in much detail in other posts in this thread
(for example message-ID 54eca102.1070...@redhat.com)



Yah. Sorry. I walked across it later then replied this.

However - I'm not convinced that metapackage will work as expected.  If nothing else it will need 
some changes in current infrastructure which I wonted to avoid.



Thanx for that!

J.
--
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

[Aleksandar Kurtakov]

- Original Message -
> From: "Mikolaj Izdebski" 
> To: devel@lists.fedoraproject.org
> Sent: Thursday, February 26, 2015 10:16:26 AM
> Subject: Re: F22 System Wide Change: Legacy implementations of the Java   
> platform in Fedora
> 
> On 02/25/2015 06:58 PM, Miloslav Trmač wrote:
> >> On 02/24/2015 06:41 PM, Miloslav Trmač wrote:
> >>> Hello,
>  "java" would be the preferred JRE in Fedora. The package would have no
>  content, but it would have Requires on preferred Fedora JRE, currently
>  java-1.8.0-openjdk. This could be easily changed as default JRE changes.
>  The same is for other binary subpackages of "java", respectively.
> 
>  All system packages would require subpackages of "java" as they do now
>  (unless there is good reason not to). Users that install "java" would
>  get latest JRE, which would be updated to new major versions as they
>  become default. Older JDKs would not be removed during update (unless
>  there is no maintainer and they are obsoleted as currently),
> >>>
> >>> AFAIK nothing obsoletes a package just because it is orphaned…
> >>
> >> If no volunteer shows up for maintenance of old JDK then it would be
> >> deprecated and obsoleted, as it's was done with previous JDK packages.
> > 
> > How would that work _exactly_?
> 
> 1) JDK maintainers announce deprecation in advance and call for
> volunteers to maintain old JDK
> 
> 2) when the time of deprecation comes, JDK package is reassigned to new
> maintainer, if such showed up; no obsoletes are added

We speak about people that are already Fedora packagers, right? Just sponsoring 
someone that showed up and let him/her maintain legacy JDK in Fedora is recipe 
for disaster.
For not-yet-packagers they would have to go through the full review-sponsoring 
process.


Alexander Kurtakov
Red Hat Eclipse team

> 
> 3) if there is no new maintainer then old JDK is redired in pkgdb,
> blocked in koji and obsoleted by some other package
> 
> 4) if maintainer shows up after old JDK was retired then he can just
> revive package (passing review if needed); package release is bumped to
> be higher that obsoletes
> 
> --
> Mikolaj Izdebski
> Software Engineer, Red Hat
> IRC: mizdebsk
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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

[Jiri Vanek]

On 02/26/2015 09:16 AM, Mikolaj Izdebski wrote:

On 02/25/2015 06:58 PM, Miloslav Trmač wrote:

On 02/24/2015 06:41 PM, Miloslav Trmač wrote:

Hello,

"java" would be the preferred JRE in Fedora. The package would have no
content, but it would have Requires on preferred Fedora JRE, currently
java-1.8.0-openjdk. This could be easily changed as default JRE changes.
The same is for other binary subpackages of "java", respectively.

All system packages would require subpackages of "java" as they do now
(unless there is good reason not to). Users that install "java" would
get latest JRE, which would be updated to new major versions as they
become default. Older JDKs would not be removed during update (unless
there is no maintainer and they are obsoleted as currently),


AFAIK nothing obsoletes a package just because it is orphaned…


If no volunteer shows up for maintenance of old JDK then it would be
deprecated and obsoleted, as it's was done with previous JDK packages.


How would that work _exactly_?


1) JDK maintainers announce deprecation in advance and call for
volunteers to maintain old JDK

2) when the time of deprecation comes, JDK package is reassigned to new
maintainer, if such showed up; no obsoletes are added


This is heavily untrue. The obsolete (or similar mechanism) is necessary.
We do not wont any user to live unvoulenteerly and unwillingly  with legacy jdk. I would like also 
to avoid just keeping the legacy jdk on his drive.

Two reasons
1- the stack will eb compiled by nex (newr) jdk - so old jdk will not be bel 
tun it.
  - even keeping it on drive may lead to risk of usage it (speaking about basic user here). Not 
speaking about vasting of space on drive after several major updates.


2- low mainatainance. The community maintained jdk can never be expected to be so uptodate == so 
safe asmain jdk, which is mainatined by openjdk upstream-working people.


3) if there is no new maintainer then old JDK is redired in pkgdb,
blocked in koji and obsoleted by some other package

4) if maintainer shows up after old JDK was retired then he can just
revive package (passing review if needed); package release is bumped to
be higher that obsoletes



--
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

[Jiri Vanek]

On 02/26/2015 09:31 AM, Aleksandar Kurtakov wrote:

- Original Message -

From: "Mikolaj Izdebski" 
To: devel@lists.fedoraproject.org
Sent: Thursday, February 26, 2015 10:16:26 AM
Subject: Re: F22 System Wide Change: Legacy implementations of the Java 
platform in Fedora

On 02/25/2015 06:58 PM, Miloslav Trmač wrote:

On 02/24/2015 06:41 PM, Miloslav Trmač wrote:

Hello,

"java" would be the preferred JRE in Fedora. The package would have no
content, but it would have Requires on preferred Fedora JRE, currently
java-1.8.0-openjdk. This could be easily changed as default JRE changes.
The same is for other binary subpackages of "java", respectively.

All system packages would require subpackages of "java" as they do now
(unless there is good reason not to). Users that install "java" would
get latest JRE, which would be updated to new major versions as they
become default. Older JDKs would not be removed during update (unless
there is no maintainer and they are obsoleted as currently),


AFAIK nothing obsoletes a package just because it is orphaned…


If no volunteer shows up for maintenance of old JDK then it would be
deprecated and obsoleted, as it's was done with previous JDK packages.


How would that work _exactly_?


1) JDK maintainers announce deprecation in advance and call for
volunteers to maintain old JDK

2) when the time of deprecation comes, JDK package is reassigned to new
maintainer, if such showed up; no obsoletes are added


We speak about people that are already Fedora packagers, right? Just sponsoring 
someone that showed up and let him/her maintain

Still it is possible scenario.

I can even guess that this person will be apckaging newbe - most of java developers do not care 
about packaged stuff below. They have theirs Java EE and are happy that packages are solving all the 
issues they dont like.


On contrary, if such a  person wonts to pack it then you cna expect him to 
learn quicly.

> legacy JDK in Fedora is recipe for disaster.

Thats what this guidelines should prevent...



For not-yet-packagers they would have to go through the full review-sponsoring 
process.


Alexander Kurtakov
Red Hat Eclipse team



3) if there is no new maintainer then old JDK is redired in pkgdb,
blocked in koji and obsoleted by some other package

4) if maintainer shows up after old JDK was retired then he can just
revive package (passing review if needed); package release is bumped to
be higher that obsoletes

--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


--
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

[Mikolaj Izdebski]

On 02/26/2015 09:31 AM, Aleksandar Kurtakov wrote:
 If no volunteer shows up for maintenance of old JDK then it would be
 deprecated and obsoleted, as it's was done with previous JDK packages.
>>>
>>> How would that work _exactly_?
>>
>> 1) JDK maintainers announce deprecation in advance and call for
>> volunteers to maintain old JDK
>>
>> 2) when the time of deprecation comes, JDK package is reassigned to new
>> maintainer, if such showed up; no obsoletes are added
> 
> We speak about people that are already Fedora packagers, right? Just 
> sponsoring someone that showed up and let him/her maintain legacy JDK in 
> Fedora is recipe for disaster.

Either could work, but new packagers would need to find a sponsor.
I would have no problem sponsoring someone that shows involvement in
Fedora and has good knowledge about JDK internals, for example OpenJDK
upstream developer.

> For not-yet-packagers they would have to go through the full 
> review-sponsoring process.

No package review is necessary to sponsor new packager.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
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

[Aleksandar Kurtakov]

- Original Message -
> From: "Jiri Vanek" 
> To: devel@lists.fedoraproject.org
> Sent: Thursday, February 26, 2015 10:39:35 AM
> Subject: Re: F22 System Wide Change: Legacy implementations of the Java   
> platform in Fedora
> 
> On 02/26/2015 09:31 AM, Aleksandar Kurtakov wrote:
> > - Original Message -
> >> From: "Mikolaj Izdebski" 
> >> To: devel@lists.fedoraproject.org
> >> Sent: Thursday, February 26, 2015 10:16:26 AM
> >> Subject: Re: F22 System Wide Change: Legacy implementations of the Java
> >>platform in Fedora
> >>
> >> On 02/25/2015 06:58 PM, Miloslav Trmač wrote:
>  On 02/24/2015 06:41 PM, Miloslav Trmač wrote:
> > Hello,
> >> "java" would be the preferred JRE in Fedora. The package would have no
> >> content, but it would have Requires on preferred Fedora JRE, currently
> >> java-1.8.0-openjdk. This could be easily changed as default JRE
> >> changes.
> >> The same is for other binary subpackages of "java", respectively.
> >>
> >> All system packages would require subpackages of "java" as they do now
> >> (unless there is good reason not to). Users that install "java" would
> >> get latest JRE, which would be updated to new major versions as they
> >> become default. Older JDKs would not be removed during update (unless
> >> there is no maintainer and they are obsoleted as currently),
> >
> > AFAIK nothing obsoletes a package just because it is orphaned…
> 
>  If no volunteer shows up for maintenance of old JDK then it would be
>  deprecated and obsoleted, as it's was done with previous JDK packages.
> >>>
> >>> How would that work _exactly_?
> >>
> >> 1) JDK maintainers announce deprecation in advance and call for
> >> volunteers to maintain old JDK
> >>
> >> 2) when the time of deprecation comes, JDK package is reassigned to new
> >> maintainer, if such showed up; no obsoletes are added
> >
> > We speak about people that are already Fedora packagers, right? Just
> > sponsoring someone that showed up and let him/her maintain
> Still it is possible scenario.
> 
> I can even guess that this person will be apckaging newbe - most of java
> developers do not care
> about packaged stuff below. They have theirs Java EE and are happy that
> packages are solving all the
> issues they dont like.
> 
> On contrary, if such a  person wonts to pack it then you cna expect him to
> learn quicly.
> 
>  > legacy JDK in Fedora is recipe for disaster.
> 
> Thats what this guidelines should prevent...

No, no guidelines can prevent someone putting %post rm -fr /etc in a spec file. 
There is a reason for not having blank approval for anybody.


Alexander Kurtakov
Red Hat Eclipse team

> 
> 
> > For not-yet-packagers they would have to go through the full
> > review-sponsoring process.
> >
> >
> > Alexander Kurtakov
> > Red Hat Eclipse team
> >
> >>
> >> 3) if there is no new maintainer then old JDK is redired in pkgdb,
> >> blocked in koji and obsoleted by some other package
> >>
> >> 4) if maintainer shows up after old JDK was retired then he can just
> >> revive package (passing review if needed); package release is bumped to
> >> be higher that obsoletes
> >>
> >> --
> >> Mikolaj Izdebski
> >> Software Engineer, Red Hat
> >> IRC: mizdebsk
> >> --
> >> devel mailing list
> >> devel@lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/devel
> >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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: Libinput now enabled as default xorg driver for F-22 workstation installs

[Hans de Goede]

Hi,

On 24-02-15 18:34, drago01 wrote:

On Mon, Feb 23, 2015 at 1:32 PM, Hans de Goede  wrote:

Hi All,

As described here: https://fedoraproject.org/wiki/Changes/LibinputForXorg

We've been working on making xorg-x11-drv-libinput the default input driver
for the Xorg xserver under Fedora 22. All the necessary changes for this are
in place for the GNOME and KDE desktops. So starting with the next Fedora 22
compose new Fedora 22 Workstation installations will be using
xorg-x11-drv-libinput instead of the -evdev and -synaptics drivers.

For existing installations the move to libinput will not happen
automatically, as  we have not added a hard dependency on
xorg-x11-drv-libinput so the XFCE, LXDE, etc. spins can keep using the old
drivers until they have adopted their mouse/touchpad configuration settings
tools to also work with xorg-x11-drv-libinput.

If you're running F-22 with GNOME or KDE, please do the following to switch
to the new driver:

"sudo dnf install xorg-x11-drv-libinput"

And let us know if you experience any issues while using the new driver.


So we'd have two sets of users ... those who upgraded and those how
reinstalled running different drivers for the same hardware?


Yes, we need to maintain both stacks for a while anyways for e.g. lxde users,
etc. Given that XFCE now supports libinput too, we could reconsider this
and make xorg-drv-libinput a hard dep of the X server so that everyone gets
it, but officially we are past the end of the feature merge window.

Peter, any thoughts on this ?

Regards,

Hans
--
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: Orphaned packages up for new point of contact

[Emmanuel Seyman]

* Kevin Fenzi [25/02/2015 12:48] :
>
> The following packages had their point of contact changed to orphan

[...]

> perl-Text-CharWidth
> perl-Text-WrapI18N

I've taken these two.

Emmanuel
-- 
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

[Mikolaj Izdebski]

On 02/26/2015 09:23 AM, Jiri Vanek wrote:
> On 02/26/2015 09:20 AM, Mikolaj Izdebski wrote:
>> On 02/26/2015 08:42 AM, Jiri Vanek wrote:
> Also, my proposal of introducing "java" metapackage (see my other post
> in this thread), which would always require the latest JDK, solves
> this
> problem in a different way, without modifying ordinary Java packages
> at all.
>
>>>
>>> May you be more exact with the metapackage? Before I come up with
>>> legacy, I hoped to solve the issues via some metapackage. At the end I
>>> gave up, because the touch of user was always necessary.
>>
>> I described it in much detail in other posts in this thread
>> (for example message-ID 54eca102.1070...@redhat.com)
>>
> 
> Yah. Sorry. I walked across it later then replied this.
> 
> However - I'm not convinced that metapackage will work as expected.  If
> nothing else it will need some changes in current infrastructure which I
> wonted to avoid.

It works exactly how I described it.  Old JDK won't be removed during
update, but that's expected behaviour of package management software,
such as DNF, and JDK packages should not differ from other Fedora
packages in this aspect. Consider a detailed example below.


Assume we start with Java 7:

sh-4.3# rpm -qa | grep java
java-1.7.0-openjdk-1.7.0-1.fc23.x86_64
java-1.7.0-1.fc23.x86_64


Then update to newer version of java metapackage, which brings Java 8:

sh-4.3# dnf -y update
Using metadata from Thu Feb 26 09:51:07 2015
Dependencies resolved.

 Package  Arch Version  Repository
   Size

Installing:
 java-1.8.0-openjdk   x86_64   666:1.8.0-1.fc23 rpm   5.6 k
Upgrading:
 java x86_64   666:1.8.0-1.fc23 rpm   5.6 k

Transaction Summary

Install  1 Package
Upgrade  1 Package

Total size: 11 k
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Installing  : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6   1/3
  Upgrading   : java-666:1.8.0-1.fc23.x86_642/3
  Cleanup : java-666:1.7.0-1.fc23.x86_643/3
  Verifying   : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6   1/3
  Verifying   : java-666:1.8.0-1.fc23.x86_642/3
  Verifying   : java-666:1.7.0-1.fc23.x86_643/3

Installed:
  java-1.8.0-openjdk.x86_64 666:1.8.0-1.fc23

Upgraded:
  java.x86_64 666:1.8.0-1.fc23

Complete!


Now both Java 8 and legacy Java 7 are installed:

sh-4.3# rpm -qa | grep java
java-1.8.0-1.fc23.x86_64
java-1.7.0-openjdk-1.7.0-1.fc23.x86_64
java-1.8.0-openjdk-1.8.0-1.fc23.x86_64


But user can easily remove packages which were installed to satisfy
dependency, but which are no longer needed using autoremove command:

sh-4.3# dnf -y autoremove
Using metadata from Thu Feb 26 09:51:07 2015
Dependencies resolved.

 Package ArchVersion Repository
   Size

Removing:
 java-1.7.0-openjdk  x86_64  666:1.7.0-1.fc23@System0

Transaction Summary

Remove  1 Package

Installed size: 0
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Erasing : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6   1/1
  Verifying   : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6   1/1

Removed:
  java-1.7.0-openjdk.x86_64 666:1.7.0-1.fc23


After autoremove Java 7 is no longer installed:

Complete!
sh-4.3# rpm -qa | grep java
java-1.8.0-1.fc23.x86_64
java-1.8.0-openjdk-1.8.0-1.fc23.x86_64



-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
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: i686 kernel bug priority plan

[Jared K. Smith]

On Wed, Feb 25, 2015 at 8:50 AM, Stephen Gallagher 
wrote:

> we should strongly consider demoting i686 to secondary architecture
> for installation media at the Fedora 23 branch point (about six months
> from now).
>

Is this intended only for 32-bit kernels on x86-based processors, or for
other 32-bit platforms such as ARM as well?  It'd be a shame to see arm7hl
support demoted to secondary arch, especially when there's a strong group
of contributors actively working on issues, and Aarch64 hardware is still
reasonably hard to obtain.

--
Jared Smith
-- 
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: i686 kernel bug priority plan

[drago01]

On Thu, Feb 26, 2015 at 11:38 AM, Jared K. Smith
 wrote:
>
> On Wed, Feb 25, 2015 at 8:50 AM, Stephen Gallagher 
> wrote:
>>
>> we should strongly consider demoting i686 to secondary architecture
>> for installation media at the Fedora 23 branch point (about six months
>> from now).
>
>
> Is this intended only for 32-bit kernels on x86-based processors, or for
> other 32-bit platforms such as ARM as well?  It'd be a shame to see arm7hl
> support demoted to secondary arch, especially when there's a strong group of
> contributors actively working on issues, and Aarch64 hardware is still
> reasonably hard to obtain.

i686 has nothing to do with ARM. So when someone says "i686" he/she
means "32bit x86".
-- 
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: i686 kernel bug priority plan

[Jared K. Smith]

On Thu, Feb 26, 2015 at 5:40 AM, drago01  wrote:

> i686 has nothing to do with ARM. So when someone says "i686" he/she
> means "32bit x86".
>


Well yes -- that's what *I* take it to mean -- I just wanted to make sure
that's what everyone else took it to mean as well.  I just wanted to make
sure that the conversation really was around 32-bit x86 and not 32-bit in
general.

Sorry if I caused any confusion.

--
Jared Smith
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Geos rebuild needed with gcc5?

[Marcin Juszkiewicz]

Hi

I wanted to fix osm2pgsql failure on aarch64 [1]. Went through osm2pgsql
github page and list of issues there.

1. http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2897601


It pointed me to --without-lockfree argument to configure script to fix
libboost_atomic linking issue. Had to update to 0.87.2 to get that. And
it fixed f22 failure.

But in f23 it still failed on geos linking...

---
./.libs/libosm2pgsql.a(geometry-builder.o): In function
`geometry_builder::parse_wkt(char const*, osmNode***, int**, int*)':

/builddir/build/BUILD/osm2pgsql-0.87.0/geometry-builder.cpp:295:
undefined reference to
`geos::io::WKTReader::read(std::__cxx11::basic_string, std::allocator > co
nst&)'


---

Rebuilt geos, updated it in mock and then osm2pgsql 0.87.2 built fine as
well.

Issue in f23 happens also on primary archs:
http://koji.fedoraproject.org/koji/taskinfo?taskID=9080614
-- 
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: Orphaned packages up for new point of contact

[Pierre-Yves Chibon]

On Wed, Feb 25, 2015 at 11:52:46PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 25 February 2015 at 20:48, Kevin Fenzi wrote:
> > The following packages had their point of contact changed to orphan
> > based on: https://fedorahosted.org/fesco/ticket/1417

> > fakeroot -- Gives a fake root environment ( master f22 f21 f20 )
> 
> Taken (f21+).
> 
> As always, co-maintainers are welcome.

Looks like someone beat you to it :)

Pierre
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Base] Base Design WG agenda meeting 27 February 2015 15:00 UTC on #fedora-meeting

[Harald Hoyer]

Agenda:
 - Interview candidates for new memberships
 - Optionally accept new members
 - Vote for new chairman of the Base Design WG to replace Phil Knirsch
 - Open Floor

Please add items by replying to this mail.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Looking for new Members - Fedora Base Design Working Group

[Harald Hoyer]

Hi folks,

the Fedora Base Design Working Group () is
looking for new members, as Phil Knirsch left Red Hat and Jaroslav Reznik is
tentative to leave the group. So, if you want to influence the base of Fedora
and have a profound knowledge about the inner workings, please apply for a
membership by visiting tomorrow's meeting at 15:00 UTC in #fedora-meeting.

ru
Harald
-- 
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: ninja/ninja-build

[Igor Gnatenko]

Hi,

On Tue, Jan 27, 2015 at 7:34 PM, Adrian Reber  wrote:
> I am planning to orphan the IRC client ninja. One of the reasons to
> orphan it is that there is a build system[1] which has the same name.
> In Fedora the ninja build system is called ninja-build which makes it
> incompatible with most other Linux distributions[2]. In addition the
> current release is from 2002 and upstream does not exist anymore.
> Most of the other Linux distributions do not even ship it, although
> there are other packages which are called ninja. It seems the name ninja
> is already taken multiple times and maybe not a good idea for future
> projects.
>
> Adrian
>
> [1] http://martine.github.io/ninja/
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1166135
Any news here? I maintain new buildsystem `meson` which uses ninja as
backend. So I'm interested to rename ninja-build -> ninja
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



-- 
-Igor Gnatenko
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

GCC5 rebuilds required for sflphone: ccrtp, libzrtpcpp, dbus-c++

[Sandro Mani]

Hi,

I need ccrtp, libzrtpcpp and dbus-c++ to be rebuilt against GCC5 to get 
sflphone building [1].


Thanks,
Sandro

[1] https://kojipkgs.fedoraproject.org//work/tasks/4328/9074328/build.log
--
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: i686 kernel bug priority plan

[Josh Boyer]

On Thu, Feb 26, 2015 at 5:43 AM, Jared K. Smith
 wrote:
>
>
> On Thu, Feb 26, 2015 at 5:40 AM, drago01  wrote:
>>
>> i686 has nothing to do with ARM. So when someone says "i686" he/she
>> means "32bit x86".
>
>
>
> Well yes -- that's what *I* take it to mean -- I just wanted to make sure 
> that's what everyone else took it to mean as well.  I just wanted to make 
> sure that the conversation really was around 32-bit x86 and not 32-bit in 
> general.

i686 means i686, not all of 32-bit.  I even gave the ARM and other
architecture SIGs kudos and thank yous as examples of how I'd like to
see i686 support grow earlier in the thread...

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-List-Compare/f21] 0.48 bump, yet even more performance improvements

[Petr Šabata]

Summary of changes:

  a656988... 0.48 bump, yet even more performance improvements (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-List-Compare/f22] 0.48 bump, yet even more performance improvements

[Petr Šabata]

Summary of changes:

  a656988... 0.48 bump, yet even more performance improvements (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: ninja/ninja-build

[Christopher Meng]

Without consent from FPC such shift would be problematic.


-- 

Yours sincerely,
Christopher Meng

http://cicku.me
-- 
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: Django 1.8

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 26, 2015 at 08:04:54AM +0100, Matthias Runge wrote:
> On Tue, Jan 27, 2015 at 01:33:57PM +0100, Matthias Runge wrote:
> > On 27/01/15 11:51, Miloslav Trmač wrote:
> > > Hello,
> > >> ** A build containing latest Django will be pushed to f22 branch late in 
> > >> dev
> > >> cycle. If we decide not to push Django-1.8, nothing will be broken.
> > >> ** Django 1.8 final release is expected around April 1st, 2015: [2]
> 
> A bit late, yesterday Django-1.8 beta was released. A package is
> available for rawhide. I would like to push it to f22, too.
> 
> Strictly speaking[1], I don't need a permission to do so. Still, I would 
> like to ask for opinions here.
It will not be pushed until after alpha release unless it gets an exception.

> [1] https://fedoraproject.org/wiki/Updates_Policy#Pre_Beta
See https://fedoraproject.org/wiki/Updates_Policy#Milestone_freezes :)

Zbyszek
-- 
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: systemd-219 issues with 22 and Rawhide composes

[Matthew Miller]

On Mon, Feb 23, 2015 at 05:13:53PM +0100, Lennart Poettering wrote:
> Sure I have a stake in systemd, but certainly none in
> fedora-release.rpm. But even for systemd, there are a number of people

Sorry for the somewhat slow reply, but I've been thinking about all of
this I guess, primarily, what I'd really hope for is for _all_
Fedora package maintainers to feel like they have a stake in
fedora-release.rpm, at least in a symbolic and general sense. As Fedora
contributors, we should not just think about individual ownership of
the packages we are primarily responsible for, but also how it all fits
together.


-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

To Whomever: You Made My Day

[John Florian]

Yesterday I was browsing the Fedora pkgdb/git/bohdi pages and this morning I 
returned to go backwards thru my web browser history when I stumbled upon a 
real hidden gem for a HTTP 500 response.  Our hot dog armed with a ray gun 
against a nuclear panda... oh man that was great.  Best 500 I've seen yet.

--
John Florian

-- 
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

[Jiri Vanek]

On 02/26/2015 09:43 AM, Aleksandar Kurtakov wrote:

- Original Message -

From: "Jiri Vanek" 
To: devel@lists.fedoraproject.org
Sent: Thursday, February 26, 2015 10:39:35 AM
Subject: Re: F22 System Wide Change: Legacy implementations of the Java 
platform in Fedora

On 02/26/2015 09:31 AM, Aleksandar Kurtakov wrote:

- Original Message -

From: "Mikolaj Izdebski" 
To: devel@lists.fedoraproject.org
Sent: Thursday, February 26, 2015 10:16:26 AM
Subject: Re: F22 System Wide Change: Legacy implementations of the Java
platform in Fedora

On 02/25/2015 06:58 PM, Miloslav Trmač wrote:

On 02/24/2015 06:41 PM, Miloslav Trmač wrote:

Hello,

"java" would be the preferred JRE in Fedora. The package would have no
content, but it would have Requires on preferred Fedora JRE, currently
java-1.8.0-openjdk. This could be easily changed as default JRE
changes.
The same is for other binary subpackages of "java", respectively.

All system packages would require subpackages of "java" as they do now
(unless there is good reason not to). Users that install "java" would
get latest JRE, which would be updated to new major versions as they
become default. Older JDKs would not be removed during update (unless
there is no maintainer and they are obsoleted as currently),


AFAIK nothing obsoletes a package just because it is orphaned…


If no volunteer shows up for maintenance of old JDK then it would be
deprecated and obsoleted, as it's was done with previous JDK packages.


How would that work _exactly_?


1) JDK maintainers announce deprecation in advance and call for
volunteers to maintain old JDK

2) when the time of deprecation comes, JDK package is reassigned to new
maintainer, if such showed up; no obsoletes are added


We speak about people that are already Fedora packagers, right? Just
sponsoring someone that showed up and let him/her maintain

Still it is possible scenario.

I can even guess that this person will be apckaging newbe - most of java
developers do not care
about packaged stuff below. They have theirs Java EE and are happy that
packages are solving all the
issues they dont like.

On contrary, if such a  person wonts to pack it then you cna expect him to
learn quicly.

  > legacy JDK in Fedora is recipe for disaster.

Thats what this guidelines should prevent...


No, no guidelines can prevent someone putting %post rm -fr /etc in a spec file. 
There is a reason for not having blank approval for anybody.


Then we are discussing only one point of this proposal. And I guees "formal review" one. Level of 
the formalness have to be agreed. And somebody have look over pacakge. I would say the rm rf / in 
postun  is protected by step 5.


By "formal review" I was higlighting that no jdk package can actually pass 
general review.

J.



Alexander Kurtakov
Red Hat Eclipse team





For not-yet-packagers they would have to go through the full
review-sponsoring process.


Alexander Kurtakov
Red Hat Eclipse team



3) if there is no new maintainer then old JDK is redired in pkgdb,
blocked in koji and obsoleted by some other package

4) if maintainer shows up after old JDK was retired then he can just
revive package (passing review if needed); package release is bumped to
be higher that obsoletes

--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


--
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

[Jiri Vanek]

On 02/26/2015 10:13 AM, Mikolaj Izdebski wrote:

On 02/26/2015 09:23 AM, Jiri Vanek wrote:

On 02/26/2015 09:20 AM, Mikolaj Izdebski wrote:

On 02/26/2015 08:42 AM, Jiri Vanek wrote:

Also, my proposal of introducing "java" metapackage (see my other post
in this thread), which would always require the latest JDK, solves
this
problem in a different way, without modifying ordinary Java packages
at all.



May you be more exact with the metapackage? Before I come up with
legacy, I hoped to solve the issues via some metapackage. At the end I
gave up, because the touch of user was always necessary.


I described it in much detail in other posts in this thread
(for example message-ID 54eca102.1070...@redhat.com)



Yah. Sorry. I walked across it later then replied this.

However - I'm not convinced that metapackage will work as expected.  If


Still the metapackge's correct dependence have to be someones responsibility. Will you be able to 
take this burden?



nothing else it will need some changes in current infrastructure which I
wonted to avoid.


It works exactly how I described it.  Old JDK won't be removed during


Is it really wonted? If so, we can skip the "option one" and continue with with 
option two.


update, but that's expected behaviour of package management software,
such as DNF, and JDK packages should not differ from other Fedora


Really should not? We done pretty god work to have only one main jdk unlike python1, python2,python3 
or glib2,glib3,glibN... We are settled in special directory and so on. So in what is JDK actually 
similar to other packages?



packages in this aspect. Consider a detailed example below.


Thank you for this. I understood it from yuor describtion and already had the same. However I 
consider the keeping of old jdk as no-go for this.


J.



Assume we start with Java 7:

sh-4.3# rpm -qa | grep java
java-1.7.0-openjdk-1.7.0-1.fc23.x86_64
java-1.7.0-1.fc23.x86_64


Then update to newer version of java metapackage, which brings Java 8:

sh-4.3# dnf -y update
Using metadata from Thu Feb 26 09:51:07 2015
Dependencies resolved.

  Package  Arch Version  Repository
Size

Installing:
  java-1.8.0-openjdk   x86_64   666:1.8.0-1.fc23 rpm   5.6 k
Upgrading:
  java x86_64   666:1.8.0-1.fc23 rpm   5.6 k

Transaction Summary

Install  1 Package
Upgrade  1 Package

Total size: 11 k
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
   Installing  : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6   1/3
   Upgrading   : java-666:1.8.0-1.fc23.x86_642/3
   Cleanup : java-666:1.7.0-1.fc23.x86_643/3
   Verifying   : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6   1/3
   Verifying   : java-666:1.8.0-1.fc23.x86_642/3
   Verifying   : java-666:1.7.0-1.fc23.x86_643/3

Installed:
   java-1.8.0-openjdk.x86_64 666:1.8.0-1.fc23

Upgraded:
   java.x86_64 666:1.8.0-1.fc23

Complete!


Now both Java 8 and legacy Java 7 are installed:

sh-4.3# rpm -qa | grep java
java-1.8.0-1.fc23.x86_64
java-1.7.0-openjdk-1.7.0-1.fc23.x86_64
java-1.8.0-openjdk-1.8.0-1.fc23.x86_64


But user can easily remove packages which were installed to satisfy
dependency, but which are no longer needed using autoremove command:

sh-4.3# dnf -y autoremove
Using metadata from Thu Feb 26 09:51:07 2015
Dependencies resolved.

  Package ArchVersion Repository
Size

Removing:
  java-1.7.0-openjdk  x86_64  666:1.7.0-1.fc23@System0

Transaction Summary

Remove  1 Package

Installed size: 0
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
   Erasing : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6   1/1
   Verifying   : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6   1/1

Removed:
   java-1.7.0-openjdk.x86_64 666:1.7.0-1.fc23


After autoremove Java 7 is no longer installed:

Complete!
sh-4.3# rpm -qa | grep java
java-1.8.0-1.fc23.x86_64
java-1.8.0-openjdk-1.8.0-1.fc23.x86_64





--
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

[Jiri Vanek]

On 02/24/2015 10:34 AM, 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 

Currently Fedora supports one main Java runtime and Java Development Kit (JDK)
and from time to time one future JDK as a tech preview. This change should be
set of rules, which will enable community to maintain legacy JDKs. Please
note, people are bugging main JDK maintainers pretty often with this, and to
allow them to maintain legacy JDKs is a step in right direction.

* This Change is announced after the Change Submission Deadline as an
exception to the process. May not be approved for proposed Fedora release. *

== Detailed Description ==
This is no real work proposal. The result of this proposal is set of rules,
which will allow community maintainers to pack any legacy jdk and will be
ensuring that this JDKs will not conflict by any other JDK and will smoothly
integrate to system. The results are summarized here, and pledged for
discussion until final resolution is done.

=== Proposed rules ===
0. '''Main JDK maintainers are not never ever responsible for any legacy jdk.
This must remain clear'''

 option one - introducing new packages - preferred 
1. main jdk is proclaimed as dead as it was until now.  The new jdk is derived
as new package prviousName-legacy
  1. so from killed java-1.7.0-openjdk will become new package java-1.7.0-
openjdk-legacy
  2. next main jdk do Obsolete previous one as usually
2. new package '''must''' not do any virtual provides (aka java,java-devel)...
(protection against random pull by as dependence)
  1. it provides only itself by name
3 its priority '''must''' be kept on less digits (right now it would be 5)
then main jdk (protection against winning in alternatives after update)
  1. the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084
are '''mandatory'''
4. at least one of the main-jdk's members '''must''' be set as comaintainer
(to watch the commits and save the world if necessary)
5. new  package '''should''' to follow both original jdk (ideally not change
at all (except source updates and necessary)) and current main jdk as close as
possibly
  1. here it requires some common sense and a lot of testing if integration
with system is as expected
6. as it is generally not new package, the review process '''should''' be only
formal - to know maintainer and to create cvs repo
  1. this is quite important, otherwise the new maintainer can become really
frustrated, and we are forcing the "dead" package over"orpahned" so the full
review (especially in alignment with rule 5) really should not be forced.
  2. on the contrary, rules agreed here '''must''' be checked.  (even the
number 5)
7. all depending packages '''must''' keep requiring java-headless or java (and
BuildRequires java-devel). Requirements on any exact jdk - or even worse on
any exact legacy jdk are forbidden and needs FESCO exception.

This option is forcing maintainers to fight with the name x current setup of
alternatives. However, the work should be minimal. But it makes the update
path pretty clear and it keeps users well protected against legacy jdk.

 option two - orphaning legacy jdks and ensure update path 
1. main JDK is only orphaned when new main JDK landed
  1. it do '''not''' Obsolate previous jdk
2. other rules (2-7) are same

This is making life of legacy JDK maintainers a bit simpler. But I don't know,
how to ensure proper "obsolete" implementation in this case.

== Scope ==
* Proposal owners: are responsible for initial setup of those guidelines.
The FESCO, the owners and pssible legacy JDKs maintainers have to agree on
those rules. New legacy JDK can be then added anytime in Fedora lifecycle.
* Other developers: no developers
* Release engineering: in ideal case, no release engineer needed
* Policies and guidelines: The proposal may split to proposal and "Legacy JDKs
in Fedora guidelines" pages
___



Small restart.

Looking to the discussion, although many people claimed  "against any rules" at the end it seems to 
me that everybody agree on "some rules" - even if it would be existence of metapackage or only 
removed virtual provides and priority

From  that point of view, do you mind to help me to improve those rules?


J.

--
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: GCC5 rebuilds required for sflphone: ccrtp, libzrtpcpp, dbus-c++

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 26, 2015 at 01:36:31PM +0100, Sandro Mani wrote:
> Hi,
> 
> I need ccrtp, libzrtpcpp
Building those two now.

> and dbus-c++ to be rebuilt against GCC5 to
> get sflphone building [1].

Zbyszek
-- 
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

[Miloslav Trmač]

> = Proposed System Wide Change: Legacy implementations of the Java platform in
> Fedora =
> https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora
> 
> == Detailed Description ==
> This is no real work proposal.

Stepping back, I’m not sure this has been said explicitly: this is really a 
packaging guideline proposal, not really a Change, so it should probably go 
through the FPC.  
(https://fedoraproject.org/wiki/Packaging_Committee?rd=Packaging:Committee#Guideline_Change_Procedure
 )

(This is not intended to kill or affect the implementation details discussion 
at all.  I’m just trying to minimize the bureaucracy (hah!) by not setting a 
precedent for doing it this way, so that all future packaging guideline 
proposals go directly to the FPC and skip this redirection step.)
Mirek
-- 
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: systemd-219 issues with 22 and Rawhide composes

[Jóhann B. Guðmundsson]

On 02/26/2015 01:29 PM, Matthew Miller wrote:

On Mon, Feb 23, 2015 at 05:13:53PM +0100, Lennart Poettering wrote:

Sure I have a stake in systemd, but certainly none in
fedora-release.rpm. But even for systemd, there are a number of people

Sorry for the somewhat slow reply, but I've been thinking about all of
this I guess, primarily, what I'd really hope for is for _all_
Fedora package maintainers to feel like they have a stake in
fedora-release.rpm, at least in a symbolic and general sense. As Fedora
contributors, we should not just think about individual ownership of
the packages we are primarily responsible for, but also how it all fits
together.




You will need to change the ownership model of packages in the 
distribution if you want to change that and related expectations 
regarding individual ownership.


Until you do you should expect others to expect relevant maintainer(s) 
be responsible for the component they maintain.


JBG
--
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: Django 1.8

[Matthias Runge]

On Thu, Feb 26, 2015 at 02:20:35PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > Strictly speaking[1], I don't need a permission to do so. Still, I would 
> > like to ask for opinions here.
> It will not be pushed until after alpha release unless it gets an exception.
> 
> > [1] https://fedoraproject.org/wiki/Updates_Policy#Pre_Beta
> See https://fedoraproject.org/wiki/Updates_Policy#Milestone_freezes :)

Yeah, but that wouldn't really help in testing this.

If I would build it now, and it get's submitted way later, it may be too
late in the game to land this feature.

Matthias
-- 
Matthias Runge 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

koji is broken

[Ralf Corsepius]

Hi,

seems to me as if koji has seized operation:

https://kojipkgs.fedoraproject.org//work/tasks/1304/9081304/root.log
https://kojipkgs.fedoraproject.org//work/tasks/1319/9081319/root.log

Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Intend to retire kde-plasma-daisy

[Michael J Gruber]

Hi there

this is a heads up notice that I intend to retire kde-plasma-daisy, the
reasons being:

- no upstream updates in almost 3 years

- FTBFS in rawhide because there's no kde-workspace{-devel}

- I don't use it myself.

- Repackaging for Plasma 5 would probably require a new package
plasma-daisy (which should not pass review, given upstream is dead), or
a kde5-plasma-daisy subpackage (but then the spec would still FTBFS), or
who knows what. I certainly don't know and don't see any specs to follow.

If anyone would like to take over I'm happy to pass the package on
rather than retire it.

Retirement is planned for rawhide and, possibly also the F22 branch,
depending on what will remain in there kde-wise.

Michael

[1]https://admin.fedoraproject.org/pkgdb/package/kde-plasma-daisy/
-- 
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: koji is broken

[Dan Horák]

On Thu, 26 Feb 2015 15:11:33 +0100
Ralf Corsepius  wrote:

> Hi,
> 
> seems to me as if koji has seized operation:
> 
> https://kojipkgs.fedoraproject.org//work/tasks/1304/9081304/root.log
> https://kojipkgs.fedoraproject.org//work/tasks/1319/9081319/root.log

I guess this is the known "squid doesn't respond" issue. nirik will
restart it.


Dan
-- 
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

[Mario Torre]

On Thu, 2015-02-26 at 09:00 +0100, Jiri Vanek wrote:
> On 02/24/2015 08:36 PM, Sumit Bhardwaj wrote:
> > Hi All,
> >
> > I have been reading this mail chain for some time and there is something I 
> > wanted to say. It's kind
> > of a long mail, I apologize for taking so much of your time but request you 
> > to please bear with me.
> > I work as a technical consultant on IBM WebSphere, IBM BPM, Java/J2EE and 
> > Python technology stacks,
> > who has to code on Java/J2EEquite often as well and I use Fedora 21 
> > Workstation as my primary OS. My
> > field of work is such that I need to use JDK versions 1.4, 5, 6, 7 and 8, 
> > all from time to time.
> > This is because as time passed, solutions delivered to customers were built 
> > using incremental
> > versions of Java/J2EE specifications and were not frequently upgraded. In 
> > my role, the changes/fixes
> > I do to these enterprise apps are usually small and require only a certain 
> > jar file to be
> > recompiled, or in some cases only one class. In such cases, maintaining 
> > binary compatibility is a
> > must and for that I need to recompile that one jar/class with the original 
> > version of JDK that was
> > used to compile the rest of the project in the first place.
> >
> > I use Oracle java in most cases due to corporate policies (for personal 
> > use, I use the latest
> > version of OpenJDK). Now as per Oracle's policy, which I am sure is similar 
> > for OpenJDK as well, a
> > particular version of JDK/JRE is updated till and even some time after the 
> > next major version is
> > released, and then at a certain Update level, Oracle stops supporting it. 
> > That update version
> > becomes the final update for that particular major release, and is sent 
> > into archives, while updates
> > keep on getting released for the current version.
> >
> > With Oracle JDK, there are two installation approaches available for RPM 
> > based systems. They provide
> > an RPM package which installs java in /usr/java, i.e. in system area and 
> > the latest installed java
> > version become default. However, they also provides tarballs of JDKs, that 
> > contain certain standard
> > directory structure of JDK  intact inside one folder. These tarballs can be 
> > extracted and placed in
> > any place on file system and once JAVA_HOME is pointed towards these+PATH 
> > is locally updated to
> > include it, user can basically use this JDK without any issues. What 
> > version of Java is installed in
> > system as default, in system area (/usr/java) become irrelevant.
> >
> > With IDEs like Eclipse and NetBeans the process is even simpler, as you can 
> > define these individual
> > folders as JDKs for particular API versions in IDE configuration 
> > permanently and while creating a
> > project can choose to use any of these "defined JDKs". This is the approach 
> > that I take. I have the
> > last updated versions of all the JDKs from 1.4 to 8 in my /opt folder. I 
> > have these configured in
> > Eclipse and NetBeans for each API version and I use them all as required by 
> > the project.
> >
> > So I guess if OpenJDK can follow the same approach and can give an option 
> > to download tarballs of
> > older versions and use them in place, without requiring any installation, 
> > as a definite directory
> > structure, then the problem is solved. There is no need to maintain old 
> > version per se in
> > repositories, as these are not updated anymore and the user will be able to 
> > use multiple versions
> > without conflict of any kind. As for the default JDK, it can be kept how it 
> > is now i.e. The latest
> > available JDK can be maintained in Fedora repos as they are being 
> > maintained now and updates can be
> > provided for the defined lifetime of that JDK.
> >
> > Let me know what you guys think about this approach.
> >
> 
> This is lying on  openjdk table for long time to have  at least source 
> tarballs... As you can see, 
> nothing,.  However  once you are able to build jdk on your own,  nothing 
> prevents you form mercurial 
> clone of *any* version. So this is the way you should go.
> 
> If you wont binary images to be supported by openjdk itself, its completely 
> different and more 
> complex story.

Indeed, and for that you need to go to an OS that supports long term
stability, like RHEL or Centos (playing in house, but you have other
choices). Fedora is not really good for that, since it promotes bleeding
edge code over long term stability.

Cheers,
Mario


-- 
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: Django 1.8

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 26, 2015 at 03:15:22PM +0100, Matthias Runge wrote:
> On Thu, Feb 26, 2015 at 02:20:35PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > > Strictly speaking[1], I don't need a permission to do so. Still, I would 
> > > like to ask for opinions here.
> > It will not be pushed until after alpha release unless it gets an exception.
> > 
> > > [1] https://fedoraproject.org/wiki/Updates_Policy#Pre_Beta
> > See https://fedoraproject.org/wiki/Updates_Policy#Milestone_freezes :)
> 
> Yeah, but that wouldn't really help in testing this.
> 
> If I would build it now, and it get's submitted way later, it may be too
> late in the game to land this feature.
It will help with testing. I'd suppose that most poeple who run F22 at this
point run with updates-testing enabled. It will not land in the alpha iso,
but you don't need that. So yeah, you should just biuld it.

Zbyszek
-- 
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: systemd-219 issues with 22 and Rawhide composes

[Reindl Harald]

Am 26.02.2015 um 15:05 schrieb Jóhann B. Guðmundsson:

On 02/26/2015 01:29 PM, Matthew Miller wrote:

On Mon, Feb 23, 2015 at 05:13:53PM +0100, Lennart Poettering wrote:

Sure I have a stake in systemd, but certainly none in
fedora-release.rpm. But even for systemd, there are a number of people

Sorry for the somewhat slow reply, but I've been thinking about all of
this I guess, primarily, what I'd really hope for is for _all_
Fedora package maintainers to feel like they have a stake in
fedora-release.rpm, at least in a symbolic and general sense. As Fedora
contributors, we should not just think about individual ownership of
the packages we are primarily responsible for, but also how it all fits
together.


You will need to change the ownership model of packages in the
distribution if you want to change that and related expectations
regarding individual ownership.

Until you do you should expect others to expect relevant maintainer(s)
be responsible for the component they maintain


really?
why?
how do you come to that weird conclusion?

surely, one can say "not my package, not my problem" but that's ignorant 
and needs no guidelines and policies - sanity should be enough




signature.asc
Description: OpenPGP digital signature
-- 
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

[Mikolaj Izdebski]

On 02/26/2015 02:46 PM, Jiri Vanek wrote:
> On 02/26/2015 10:13 AM, Mikolaj Izdebski wrote:
>> On 02/26/2015 09:23 AM, Jiri Vanek wrote:
>>> On 02/26/2015 09:20 AM, Mikolaj Izdebski wrote:
 On 02/26/2015 08:42 AM, Jiri Vanek wrote:
>>> Also, my proposal of introducing "java" metapackage (see my other
>>> post
>>> in this thread), which would always require the latest JDK, solves
>>> this
>>> problem in a different way, without modifying ordinary Java packages
>>> at all.
>>>
>
> May you be more exact with the metapackage? Before I come up with
> legacy, I hoped to solve the issues via some metapackage. At the end I
> gave up, because the touch of user was always necessary.

 I described it in much detail in other posts in this thread
 (for example message-ID 54eca102.1070...@redhat.com)

>>>
>>> Yah. Sorry. I walked across it later then replied this.
>>>
>>> However - I'm not convinced that metapackage will work as expected.  If
> 
> Still the metapackge's correct dependence have to be someones
> responsibility. Will you be able to take this burden?

Sure, I can create and maintain metapackage. (In this case it would
probably be subpackage of javapackages-tools.)

>>> nothing else it will need some changes in current infrastructure which I
>>> wonted to avoid.
>>
>> It works exactly how I described it.  Old JDK won't be removed during
> 
> Is it really wonted? If so, we can skip the "option one" and continue
> with with option two.

If you really think that old JDK should be removed during update and
insist on that then there is still a way to achieve that with versioned
obsoletes. Metapackage would Obsolete: java-1.N.0-openjdk* < e:v-(r+1),
where e:v-r is the latest evr of java-1.N.0-openjdk* when JDK N was
considered as "main JDK". I've just tested it and it works, see below.


Lets start with JDK 7 installed.

sh-4.3# rpm -qa | grep java
java-1.7.0-1.fc23.x86_64
java-1.7.0-openjdk-1.7.0-1.fc23.x86_64


Update installs JDK 8 and erases JDK 7.

sh-4.3# dnf -y update
Using metadata from Thu Feb 26 15:37:47 2015
Dependencies resolved.
Nothing to do.
sh-4.3# rm -rf /var/cache/dnf/
sh-4.3# rm -rf rpm
sh-4.3# dnf -y update
rpm 966 kB/s | 1.3 kB 00:00
Using metadata from Thu Feb 26 15:38:06 2015
Dependencies resolved.

 Package  Arch Version  Repository
   Size

Installing:
 java-1.8.0-openjdk   x86_64   666:1.8.0-1.fc23 rpm   5.6 k
Upgrading:
 java x86_64   666:1.8.0-1.fc23 rpm   5.7 k
 replacing  java-1.7.0-openjdk.x86_64 666:1.7.0-1.fc23

Transaction Summary

Install  1 Package
Upgrade  1 Package

Total size: 11 k
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Installing  : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6   1/4
  Upgrading   : java-666:1.8.0-1.fc23.x86_642/4
  Cleanup : java-666:1.7.0-1.fc23.x86_643/4
  Obsoleting  : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6   4/4
  Verifying   : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6   1/4
  Verifying   : java-666:1.8.0-1.fc23.x86_642/4
  Verifying   : java-666:1.7.0-1.fc23.x86_643/4
  Verifying   : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6   4/4

Installed:
  java-1.8.0-openjdk.x86_64 666:1.8.0-1.fc23

Upgraded:
  java.x86_64 666:1.8.0-1.fc23

Complete!


After update only JDK 8 is installed:

sh-4.3# rpm -qa | grep java
java-1.8.0-openjdk-1.8.0-1.fc23.x86_64
java-1.8.0-1.fc23.x86_64


But user can still install JDK 7:

sh-4.3# dnf install -y java-1.7.0-openjdk
Using metadata from Thu Feb 26 15:38:06 2015
Dependencies resolved.

 Package  Arch Version  Repository
   Size

Installing:
 java-1.7.0-openjdk   x86_64   666:1.7.0-2.fc23 rpm   5.7 k

Transaction Summary

Install  1 Package

Total size: 5.7 k
Installed size: 0
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Installing  : java-1.7.0-openjdk-666:1.7.0-2.fc23.x86_6   1/1
  Verifying   : java-1.7.0-openjdk-666:1.7.0-2.fc23.x86_6   1/1

Installed:
  java-1.7.0-openjdk.x86_64 666:1.7.0-2.fc23

Complete!


JDK 7 and 8 can coexist without any problem:

sh-4.3# rpm -qa | grep java
java-1.8.0-openjdk-1.8.0-1.fc23.x86_64
java-1.7.0-openjdk-1.7.0-2.fc23.x86_64
java-1.8.0-1.f

Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora

[Mario Torre]

On Tue, 2015-02-24 at 18:22 +0100, Mikolaj Izdebski wrote:
> On 02/24/2015 05:21 PM, Mario Torre wrote:
> > On Tue, 2015-02-24 at 15:37 +0100, Mikolaj Izdebski wrote:
> >> On 02/24/2015 02:15 PM, Jiri Vanek wrote:
> >>> On 02/24/2015 12:43 PM, Mikolaj Izdebski wrote:
>  I am against official guidelines or policy for legacy JDK packages. I
>  don't think that any such policy is needed and it would only encourage
>  adoption of old packages for which there might be no security updates.
> >>>
> >>> Well thats the point - people are calling for them. And wont to maintain
> >>> them with this risk.
> >>
> >> I thought that the point of this change proposal was "enabling community
> >> to maintain legacy JDKs", not encouraging people to package them without
> >> good reason or without involvement to truly maintaining them. Packaging
> >> older JDKs is *already* possible, so IMHO this change accomplishes
> >> nothing but showing people how they can dump old, unmaintained software
> >> into Fedora.
> > 
> > Well, in this case it would not be un-maintained, the Fedora package
> > would *not* be maintained *by us* (the Red Hat Java Team) indeed, but we
> > are still actively contributing to the upstream software in its various
> > versions. While you as a packager cannot specifically count on that,
> > there's still a level of confidence that the base software won't be
> > abandoned any time soon. And even when we will stop supporting those
> > older versions, the community will take over if there is a need for
> > that, exactly like we have done ourselves before.
> > 
> > Indeed, there's an overhead for the downstream maintainers, we may need
> > to drop specific version of OpenJDK, or skip a release, or do other
> > funny things and the Fedora maintainers will have to adapt, but this is
> > no different than usual I believe. Realistically, we are so conservative
> > with older JDKs that I doubt this will ever really be an issue.
> 
> Correct me if I am wrong, but in my understanding maintaining JDK
> package requires a lot of ongoing work (including obtaining and applying
> patches, running TCK, pushing updates in timely manner and so on). JDK
> maintainers should know this and I'm assuming that the amount of
> required work is the main reason for them not wanting to maintain older
> JDKs.
> 
> The work required to add old JDK package to Fedora is relatively small
> compared to ongoing maintenance work. Someone willing to truly maintain
> JDK in Fedora should have knowledge about JDK packaging and they
> shouldn't have problem finding time to come up with a working solution,
> proposing and discussing it.

Indeed, but don't underestimate this "relatively", which is the main
reason why *we* won't do that.

> If you make the process of adding legacy JDKs to Fedora too easy then
> someone without enough time and required knowledge will surely do that
> and we may easily end with unmaintained package. I'd rather not have old
> JDK than have unmaintained JDK with security holes.

I don't see how giving proper rules means making something like that
"easy". The fact is that making things artificially complicated just to
scare off people from doing them doesn't really match with my view of
Freedom. I think instead that rules, however complex for the matter at
hand, should be crafted so that they impose the minimum possible
overhead.

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.

> >> Package that doesn't pass review shouldn't be part of Fedora.
> > 
> > Well, if your goal is to reduce the user base of Fedora, I'm sure we can
> > talk about removing the JDK :)
> 
> We can't sacrifice our basic principles (such as passing review) for the
> sake of increasing user base.

If you put the mean before the end, yes. But I hope you will agree with
me that one of those core principles *is* the Freedom of allowing users
to use such a critical tool as Java for their own daily reasons
*without* forcing them to switch distribution.

While I see your point that this can be extended to anything (why don't
we package an older Eclipse?) so we need to draw a line, I believe an
important core component like the JDK falls in that category of things
that should be allowed to coexist even a bit longer than originally
intended.

Now, the question is how to make this happens by preserving both quality
and freedom.

Cheers,
Mario


-- 
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

[Mikolaj Izdebski]

On 02/26/2015 02:51 PM, Jiri Vanek wrote:
> Small restart.
> 
> Looking to the discussion, although many people claimed  "against any
> rules" at the end it seems to me that everybody agree on "some rules" -
> even if it would be existence of metapackage or only removed virtual
> provides and priority
> From  that point of view, do you mind to help me to improve those rules?

As always I'm happy to help improving state of Java in Fedora. Next week
I'm on vacation [1], but after I come back I can work on this. Once we
agree on requirements and other assumptions then finding optimal
solution should be easy.

[1] https://apps.fedoraproject.org/calendar/vacation/#m2268

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
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

[Aleksandar Kurtakov]

- Original Message -
> From: "Mario Torre" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, February 26, 2015 4:59:35 PM
> Subject: Re: F22 System Wide Change: Legacy implementations of the Java   
> platform in Fedora
> 
> On Tue, 2015-02-24 at 18:22 +0100, Mikolaj Izdebski wrote:
> > On 02/24/2015 05:21 PM, Mario Torre wrote:
> > > On Tue, 2015-02-24 at 15:37 +0100, Mikolaj Izdebski wrote:
> > >> On 02/24/2015 02:15 PM, Jiri Vanek wrote:
> > >>> On 02/24/2015 12:43 PM, Mikolaj Izdebski wrote:
> >  I am against official guidelines or policy for legacy JDK packages. I
> >  don't think that any such policy is needed and it would only encourage
> >  adoption of old packages for which there might be no security updates.
> > >>>
> > >>> Well thats the point - people are calling for them. And wont to
> > >>> maintain
> > >>> them with this risk.
> > >>
> > >> I thought that the point of this change proposal was "enabling community
> > >> to maintain legacy JDKs", not encouraging people to package them without
> > >> good reason or without involvement to truly maintaining them. Packaging
> > >> older JDKs is *already* possible, so IMHO this change accomplishes
> > >> nothing but showing people how they can dump old, unmaintained software
> > >> into Fedora.
> > > 
> > > Well, in this case it would not be un-maintained, the Fedora package
> > > would *not* be maintained *by us* (the Red Hat Java Team) indeed, but we
> > > are still actively contributing to the upstream software in its various
> > > versions. While you as a packager cannot specifically count on that,
> > > there's still a level of confidence that the base software won't be
> > > abandoned any time soon. And even when we will stop supporting those
> > > older versions, the community will take over if there is a need for
> > > that, exactly like we have done ourselves before.
> > > 
> > > Indeed, there's an overhead for the downstream maintainers, we may need
> > > to drop specific version of OpenJDK, or skip a release, or do other
> > > funny things and the Fedora maintainers will have to adapt, but this is
> > > no different than usual I believe. Realistically, we are so conservative
> > > with older JDKs that I doubt this will ever really be an issue.
> > 
> > Correct me if I am wrong, but in my understanding maintaining JDK
> > package requires a lot of ongoing work (including obtaining and applying
> > patches, running TCK, pushing updates in timely manner and so on). JDK
> > maintainers should know this and I'm assuming that the amount of
> > required work is the main reason for them not wanting to maintain older
> > JDKs.
> > 
> > The work required to add old JDK package to Fedora is relatively small
> > compared to ongoing maintenance work. Someone willing to truly maintain
> > JDK in Fedora should have knowledge about JDK packaging and they
> > shouldn't have problem finding time to come up with a working solution,
> > proposing and discussing it.
> 
> Indeed, but don't underestimate this "relatively", which is the main
> reason why *we* won't do that.
> 
> > If you make the process of adding legacy JDKs to Fedora too easy then
> > someone without enough time and required knowledge will surely do that
> > and we may easily end with unmaintained package. I'd rather not have old
> > JDK than have unmaintained JDK with security holes.
> 
> I don't see how giving proper rules means making something like that
> "easy". The fact is that making things artificially complicated just to
> scare off people from doing them doesn't really match with my view of
> Freedom. I think instead that rules, however complex for the matter at
> hand, should be crafted so that they impose the minimum possible
> overhead.
> 
> 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.
> 
> > >> Package that doesn't pass review shouldn't be part of Fedora.
> > > 
> > > Well, if your goal is to reduce the user base of Fedora, I'm sure we can
> > > talk about removing the JDK :)
> > 
> > We can't sacrifice our basic principles (such as passing review) for the
> > sake of increasing user base.
> 
> If you put the mean before the end, yes. But I hope you will agree with
> me that one of those core principles *is* the Freedom of allowing users
> to use such a critical tool as Java for their own daily reasons
> *without* forcing them to switch distribution.
> 
> While I see your point that this can be extended to anything (why don't
> we package an older Eclipse?) so we need to draw a line, I believe an
> important core component like the JDK falls in that category of things
> that should be allowed to coexist even a bit longer than originally
> inte

Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora

[Robert Marcano]

On 02/24/2015 05:04 AM, 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 

Currently Fedora supports one main Java runtime and Java Development Kit (JDK)
and from time to time one future JDK as a tech preview. This change should be
set of rules, which will enable community to maintain legacy JDKs. Please
note, people are bugging main JDK maintainers pretty often with this, and to
allow them to maintain legacy JDKs is a step in right direction.

* This Change is announced after the Change Submission Deadline as an
exception to the process. May not be approved for proposed Fedora release. *

== Detailed Description ==
This is no real work proposal. The result of this proposal is set of rules,
which will allow community maintainers to pack any legacy jdk and will be
ensuring that this JDKs will not conflict by any other JDK and will smoothly
integrate to system. The results are summarized here, and pledged for
discussion until final resolution is done.


I think for this to work, real work should be done by all Java 
packagers. There is no advantages of being able to install any community 
maintained legacy JDK if I can't use already packaged code. An example 
PostgreSQL JDBC driver is currently built with Java 8 bytecode level, it 
can't be used with any previous Java release. This happen because 
upstream developers frequently forget to add the --target javac command 
line argument for the minimum supported Java release they support (and 
work with upstream to add it). So a lot of packages need to be patched 
because they will target the built time Java bytecode level.




=== Proposed rules ===
0. '''Main JDK maintainers are not never ever responsible for any legacy jdk.
This must remain clear'''

 option one - introducing new packages - preferred 
1. main jdk is proclaimed as dead as it was until now.  The new jdk is derived
as new package prviousName-legacy
  1. so from killed java-1.7.0-openjdk will become new package java-1.7.0-
openjdk-legacy
  2. next main jdk do Obsolete previous one as usually
2. new package '''must''' not do any virtual provides (aka java,java-devel)...
(protection against random pull by as dependence)
  1. it provides only itself by name
3 its priority '''must''' be kept on less digits (right now it would be 5)
then main jdk (protection against winning in alternatives after update)
  1. the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084
are '''mandatory'''
4. at least one of the main-jdk's members '''must''' be set as comaintainer
(to watch the commits and save the world if necessary)
5. new  package '''should''' to follow both original jdk (ideally not change
at all (except source updates and necessary)) and current main jdk as close as
possibly
  1. here it requires some common sense and a lot of testing if integration
with system is as expected
6. as it is generally not new package, the review process '''should''' be only
formal - to know maintainer and to create cvs repo
  1. this is quite important, otherwise the new maintainer can become really
frustrated, and we are forcing the "dead" package over"orpahned" so the full
review (especially in alignment with rule 5) really should not be forced.
  2. on the contrary, rules agreed here '''must''' be checked.  (even the
number 5)
7. all depending packages '''must''' keep requiring java-headless or java (and
BuildRequires java-devel). Requirements on any exact jdk - or even worse on
any exact legacy jdk are forbidden and needs FESCO exception.

This option is forcing maintainers to fight with the name x current setup of
alternatives. However, the work should be minimal. But it makes the update
path pretty clear and it keeps users well protected against legacy jdk.

 option two - orphaning legacy jdks and ensure update path 
1. main JDK is only orphaned when new main JDK landed
  1. it do '''not''' Obsolate previous jdk
2. other rules (2-7) are same

This is making life of legacy JDK maintainers a bit simpler. But I don't know,
how to ensure proper "obsolete" implementation in this case.

== Scope ==
* Proposal owners: are responsible for initial setup of those guidelines.
The FESCO, the owners and pssible legacy JDKs maintainers have to agree on
those rules. New legacy JDK can be then added anytime in Fedora lifecycle.
* Other developers: no developers
* Release engineering: in ideal case, no release engineer needed
* Policies and guidelines: The proposal may split to proposal and "Legacy JDKs
in Fedora guidelines" pages
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedorapr

Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora

[Aleksandar Kurtakov]

- Original Message -
> From: "Robert Marcano" 
> To: devel@lists.fedoraproject.org
> Sent: Thursday, February 26, 2015 5:20:04 PM
> Subject: Re: F22 System Wide Change: Legacy implementations of the Java   
> platform in Fedora
> 
> On 02/24/2015 05:04 AM, 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 
> >
> > Currently Fedora supports one main Java runtime and Java Development Kit
> > (JDK)
> > and from time to time one future JDK as a tech preview. This change should
> > be
> > set of rules, which will enable community to maintain legacy JDKs. Please
> > note, people are bugging main JDK maintainers pretty often with this, and
> > to
> > allow them to maintain legacy JDKs is a step in right direction.
> >
> > * This Change is announced after the Change Submission Deadline as an
> > exception to the process. May not be approved for proposed Fedora release.
> > *
> >
> > == Detailed Description ==
> > This is no real work proposal. The result of this proposal is set of rules,
> > which will allow community maintainers to pack any legacy jdk and will be
> > ensuring that this JDKs will not conflict by any other JDK and will
> > smoothly
> > integrate to system. The results are summarized here, and pledged for
> > discussion until final resolution is done.
> 
> I think for this to work, real work should be done by all Java
> packagers. There is no advantages of being able to install any community
> maintained legacy JDK if I can't use already packaged code. An example
> PostgreSQL JDBC driver is currently built with Java 8 bytecode level, it
> can't be used with any previous Java release. This happen because
> upstream developers frequently forget to add the --target javac command
> line argument for the minimum supported Java release they support (and
> work with upstream to add it). So a lot of packages need to be patched
> because they will target the built time Java bytecode level.

Now, this is the kind of work I would not do for my packages. There are 2 
options for this to happen:
* Interested person becomes maintainer of the package and takes care of such 
patching. I'll happily give maintainership to any such person.
* Interested person fixes setting target upstream properly (note that this is 
double edged sword as target 1.5 would not work with Java 9 and requires 
keeping track). Once Fedora version is updated this would be fixed in Fedora.

Alexander Kurtakov
Red Hat Eclipse team

> 
> >
> > === Proposed rules ===
> > 0. '''Main JDK maintainers are not never ever responsible for any legacy
> > jdk.
> > This must remain clear'''
> >
> >  option one - introducing new packages - preferred 
> > 1. main jdk is proclaimed as dead as it was until now.  The new jdk is
> > derived
> > as new package prviousName-legacy
> >   1. so from killed java-1.7.0-openjdk will become new package java-1.7.0-
> > openjdk-legacy
> >   2. next main jdk do Obsolete previous one as usually
> > 2. new package '''must''' not do any virtual provides (aka
> > java,java-devel)...
> > (protection against random pull by as dependence)
> >   1. it provides only itself by name
> > 3 its priority '''must''' be kept on less digits (right now it would be 5)
> > then main jdk (protection against winning in alternatives after update)
> >   1. the automated check as
> >   https://bugzilla.redhat.com/show_bug.cgi?id=1189084
> > are '''mandatory'''
> > 4. at least one of the main-jdk's members '''must''' be set as comaintainer
> > (to watch the commits and save the world if necessary)
> > 5. new  package '''should''' to follow both original jdk (ideally not
> > change
> > at all (except source updates and necessary)) and current main jdk as close
> > as
> > possibly
> >   1. here it requires some common sense and a lot of testing if integration
> > with system is as expected
> > 6. as it is generally not new package, the review process '''should''' be
> > only
> > formal - to know maintainer and to create cvs repo
> >   1. this is quite important, otherwise the new maintainer can become
> >   really
> > frustrated, and we are forcing the "dead" package over"orpahned" so the
> > full
> > review (especially in alignment with rule 5) really should not be forced.
> >   2. on the contrary, rules agreed here '''must''' be checked.  (even the
> > number 5)
> > 7. all depending packages '''must''' keep requiring java-headless or java
> > (and
> > BuildRequires java-devel). Requirements on any exact jdk - or even worse on
> > any exact legacy jdk are forbidden and needs FESCO exception.
> >
> > This option is forcing maintainers to fight with the name x current setup
> > of
> > alternatives. However, the work should be minimal. But it makes the update
> > path pretty clear and it keeps users well protected against legacy jdk.
> >
> >  option two - orpha

Minutes from Env-and-Stacks WG meeting (2015-02-26)

[Honza Horak]

==
#fedora-meeting-2: Env and Stacks (2015-02-26)
==


Meeting started by hhorak at 13:02:49 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-2/2015-02-26/env-and-stacks.2015-02-26-13.02.log.html
.



Meeting summary
---
* init process  (hhorak, 13:03:21)

* Removing 'scls' from %{_sysconfdir} and %{_localstatedir}  (hhorak,
  13:07:05)
  * LINK:
https://www.redhat.com/archives/sclorg/2015-February/msg00032.html
(hhorak, 13:07:30)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=105#c8
(hhorak, 13:10:27)
  * HELP:   (hhorak, 13:21:53)
  * AGREED: The preferred way for collections in Fedora is to use a
directory under /opt/, which allows to categorize content
from one vendor (e.g. /opt/fedora/scls)  (hhorak, 13:30:18)
  * AGREED: to use scls for "directory for collections" rather than scl
(hhorak, 13:40:09)

* Follow-ups: Dockerfiles recommended tips  (hhorak, 13:40:52)
  * having some docker.fedoraproject.org will be very beneficial
(hhorak, 13:55:01)
  * IDEA: content should focus on "docker in Fedora" and developer
workflow for container based deployments, not that on "what is
Docker?"  (hhorak, 13:55:01)
  * IDEA: making DevAssistant fedora-dockerfiles aware would be quite
neat  (hhorak, 13:55:30)

Meeting ended at 14:08:47 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* phracek (62)
* ncoghlan (58)
* hhorak (46)
* bkabrda1 (30)
* ttomecek (24)
* juhp (22)
* zodbot (4)
* langdon (3)
* ttomecek1 (1)
* bkabrda (0)
* sicampbell (0)
* vpavlin (0)
* walters (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

--
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: systemd-219 issues with 22 and Rawhide composes

[Jóhann B. Guðmundsson]

On 02/26/2015 02:10 PM, Reindl Harald wrote:




really?
why?
how do you come to that weird conclusion?

surely, one can say "not my package, not my problem" but that's 
ignorant and needs no guidelines and policies - sanity should be enough 


I guess you did not grasp I was referring to the ownership model of 
components in the distribution which are irrelevant to guidelines and 
policy's.


The fact is the distribution has been using the ownership model since 
it's interception which means one to one mapping from a component to an 
individual.


As such the thought process of "I take care of what I own has" been 
breed into maintainers for the past ten years.


There have been several cases where the community has explode due to 
"lack of communications" as an result of that with the most notorious of 
those being the Gnome half of the Red Hat's desktop team where more 
often than not they have broken bits for other *DE's that have been 
sharing underlying components in the distribution. ( search this lists 
archives if you need proof of that )


On top of that there are around 15k components in the distribution and 
expecting all maintainers to be able to keep tabs on all packager 
relations ( to their own or in general ) is ignant or expect them to 
does so for a single fedora-release rpm after the distribution has been 
split up again into core ( products ) and extra ( the inferior rest ) 
where the inevitale outcome is for those products eventually start 
shipping their own fedora release package...


If the PLL had thought though these thing thoroughly through he would 
have realized that.


JBG
--
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

[Jiri Vanek]

On 02/26/2015 04:20 PM, Robert Marcano wrote:

On 02/24/2015 05:04 AM, 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 

Currently Fedora supports one main Java runtime and Java Development Kit (JDK)
and from time to time one future JDK as a tech preview. This change should be
set of rules, which will enable community to maintain legacy JDKs. Please
note, people are bugging main JDK maintainers pretty often with this, and to
allow them to maintain legacy JDKs is a step in right direction.

* This Change is announced after the Change Submission Deadline as an
exception to the process. May not be approved for proposed Fedora release. *

== Detailed Description ==
This is no real work proposal. The result of this proposal is set of rules,
which will allow community maintainers to pack any legacy jdk and will be
ensuring that this JDKs will not conflict by any other JDK and will smoothly
integrate to system. The results are summarized here, and pledged for
discussion until final resolution is done.


I think for this to work, real work should be done by all Java packagers. There 
is no advantages of
being able to install any community maintained legacy JDK if I can't use 
already packaged code. An
example PostgreSQL JDBC driver is currently built with Java 8 bytecode level, 
it can't be used with
any previous Java release. This happen because upstream developers frequently 
forget to add the
--target javac command line argument for the minimum supported Java release 
they support (and work
with upstream to add it). So a lot of packages need to be patched because they 
will target the built
time Java bytecode level.



The legacy jdk have not unvoulenteerly run this regular fedora-java stack code - never. Thats what 
those rules should achieve.


The usage should be for third party development/usage only.


J.




=== Proposed rules ===
0. '''Main JDK maintainers are not never ever responsible for any legacy jdk.
This must remain clear'''

 option one - introducing new packages - preferred 
1. main jdk is proclaimed as dead as it was until now.  The new jdk is derived
as new package prviousName-legacy
  1. so from killed java-1.7.0-openjdk will become new package java-1.7.0-
openjdk-legacy
  2. next main jdk do Obsolete previous one as usually
2. new package '''must''' not do any virtual provides (aka java,java-devel)...
(protection against random pull by as dependence)
  1. it provides only itself by name
3 its priority '''must''' be kept on less digits (right now it would be 5)
then main jdk (protection against winning in alternatives after update)
  1. the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084
are '''mandatory'''
4. at least one of the main-jdk's members '''must''' be set as comaintainer
(to watch the commits and save the world if necessary)
5. new  package '''should''' to follow both original jdk (ideally not change
at all (except source updates and necessary)) and current main jdk as close as
possibly
  1. here it requires some common sense and a lot of testing if integration
with system is as expected
6. as it is generally not new package, the review process '''should''' be only
formal - to know maintainer and to create cvs repo
  1. this is quite important, otherwise the new maintainer can become really
frustrated, and we are forcing the "dead" package over"orpahned" so the full
review (especially in alignment with rule 5) really should not be forced.
  2. on the contrary, rules agreed here '''must''' be checked.  (even the
number 5)
7. all depending packages '''must''' keep requiring java-headless or java (and
BuildRequires java-devel). Requirements on any exact jdk - or even worse on
any exact legacy jdk are forbidden and needs FESCO exception.

This option is forcing maintainers to fight with the name x current setup of
alternatives. However, the work should be minimal. But it makes the update
path pretty clear and it keeps users well protected against legacy jdk.

 option two - orphaning legacy jdks and ensure update path 
1. main JDK is only orphaned when new main JDK landed
  1. it do '''not''' Obsolate previous jdk
2. other rules (2-7) are same

This is making life of legacy JDK maintainers a bit simpler. But I don't know,
how to ensure proper "obsolete" implementation in this case.

== Scope ==
* Proposal owners: are responsible for initial setup of those guidelines.
The FESCO, the owners and pssible legacy JDKs maintainers have to agree on
those rules. New legacy JDK can be then added anytime in Fedora lifecycle.
* Other developers: no developers
* Release engineering: in ideal case, no release engineer needed
* Policies and guidelines: The proposal may split to proposal and "Legacy JDKs
in Fedora guidelines" pages
___
devel-announce mailing list
devel-ann

Re: koji is broken

[Kevin Fenzi]

On Thu, 26 Feb 2015 15:26:32 +0100
Dan Horák  wrote:

> On Thu, 26 Feb 2015 15:11:33 +0100
> Ralf Corsepius  wrote:
> 
> > Hi,
> > 
> > seems to me as if koji has seized operation:
> > 
> > https://kojipkgs.fedoraproject.org//work/tasks/1304/9081304/root.log
> > https://kojipkgs.fedoraproject.org//work/tasks/1319/9081319/root.log
> 
> I guess this is the known "squid doesn't respond" issue. nirik will
> restart it.

Rather it's the known 'squid starts being very slow and failing some
builds' so that was me restarting it. 

Just resubmit for now. 

I am working on tracking down the problem, but it's proving quite
elusive. ;( 

kevin


pgpJS9kq3tI3_.pgp
Description: OpenPGP digital signature
-- 
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: systemd-219 issues with 22 and Rawhide composes

[Reindl Harald]

Am 26.02.2015 um 16:37 schrieb Jóhann B. Guðmundsson:

On 02/26/2015 02:10 PM, Reindl Harald wrote:

really?
why?
how do you come to that weird conclusion?

surely, one can say "not my package, not my problem" but that's
ignorant and needs no guidelines and policies - sanity should be enough


I guess you did not grasp I was referring to the ownership model of
components in the distribution which are irrelevant to guidelines and
policy's


i did


The fact is the distribution has been using the ownership model since
it's interception which means one to one mapping from a component to an
individual.

As such the thought process of "I take care of what I own has" been
breed into maintainers for the past ten years.


and i doubt that this is true in general

every maintainer with responsiblity is or should be aware that his piece 
is *part of a distribution* because otherwise he could just build his 
package outside for his own



There have been several cases where the community has explode due to
"lack of communications" as an result of that with the most notorious of
those being the Gnome half of the Red Hat's desktop team where more
often than not they have broken bits for other *DE's that have been
sharing underlying components in the distribution. ( search this lists
archives if you need proof of that )


and without the "ownership model" it would have been prevented
what model would you use?
you can't only say "that model is wrong" without any alternative

having everybody mangle every package is also not a solution because you 
can't expect the needed knowledge for mangle around in a perl package 
from a java-user and so on



On top of that there are around 15k components in the distribution and
expecting all maintainers to be able to keep tabs on all packager
relations ( to their own or in general ) is ignant or expect them to
does so for a single fedora-release rpm after the distribution has been
split up again into core ( products ) and extra ( the inferior rest )
where the inevitale outcome is for those products eventually start
shipping their own fedora release package...

If the PLL had thought though these thing thoroughly through he would
have realized that.


that's a completly different topic



signature.asc
Description: OpenPGP digital signature
-- 
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: Why sysrq is limited to only "sync" command on official fedora kernel?

[Pete Travis]

On Feb 25, 2015 1:50 PM, "Reindl Harald"  wrote:
>
>
>
> Am 25.02.2015 um 21:38 schrieb Zdenek Kabelac:
>
>> Dne 25.2.2015 v 18:44 Reindl Harald napsal(a):
>>>
>>>
>>> Am 25.02.2015 um 18:37 schrieb Paul Wouters:

 On Wed, 25 Feb 2015, Lennart Poettering wrote:

> Hmm? Syncing is allowed to my knowledge. C-a-d and gdm allow a clean
> reboot/poweroff. But sysrq does an abnormal reboot/poweroff, which we
> cannot allow. Similar, remounting read-only is also security senstive,
> which we cannot allow.
>
> Without being logged in there's very little you can do on a host right
> now, and sysrq should not open up more there by default.


 You must have forgotten your university days

 The alternative to not being able to sync-umount-boot using sysrq is to
 flip the switch. I'd rather have them use sysrq.

 I said it when they closed X ctrl-alt-backspace and I'll say it now.
 When you are on console with the power plug, preventing these actions
 is stupid
>>>
>>>
>>> when you are on a machine where you have pysical only keyboard and
>>> mouse it is
>>> not - not every PC stands in front of your face - think about kiosk
>>> mode and
>>> so on...
>>
>>
>> When I read such answers - I always wonder myself - how many kiosk ever
>> run Fedora...
>>
>> It's such a bad idea to optimize Fedora for one-in-milion users and
>> those 999.999 has to suffer instead of require 1 guy to configure more
>> secure version
>
>
> you can be sure that the need for sysrq is the one-in-milion users just
because i am a *heavy user* with a lot of setups and used it 4 times in the
past 12 years while restricted it to "kernel.sysrq = 20" long before the
systemd change
>
> it's such a bad idea to *not* optimize out-of-the box for security
>
> the ones which don't care can disable it, most won't care, nor have a
need nor do they even know about a lot of things - this users are also not
in the position to fix bad security defaults because they have no idea
about it
>
>
> --
>

The only time I've needed sysrq reboots in recent memory was while running
rawhide and knowingly venturing into uncharted territory.  If I'm not the
only one, would it make sense to include appropriate sysctl snippets in
fedora-release-rawhide ?

--Pete
-- 
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: systemd-219 issues with 22 and Rawhide composes

[Reindl Harald]

Am 26.02.2015 um 16:54 schrieb Jóhann B. Guðmundsson:

On 02/26/2015 03:49 PM, Reindl Harald wrote:


and without the "ownership model" it would have been prevented
what model would you use?
you can't only say "that model is wrong" without any alternative


I have already mentioned alternative before no need to repeat that
proposal to you.

Bottom line that model will not be change due to Red Hat requiring to
keep components it ships under its own control.


you typical Red Hat flame.


Why do you think the distribution has been split into cores and extra
again now through "products"?


that is nonsense and you know that!



signature.asc
Description: OpenPGP digital signature
-- 
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: Geos rebuild needed with gcc5?

[Orion Poplawski]

On 02/26/2015 04:21 AM, Marcin Juszkiewicz wrote:
> Hi
> But in f23 it still failed on geos linking...
> 
> ---
> ./.libs/libosm2pgsql.a(geometry-builder.o): In function
> `geometry_builder::parse_wkt(char const*, osmNode***, int**, int*)':
> 
> /builddir/build/BUILD/osm2pgsql-0.87.0/geometry-builder.cpp:295:
> undefined reference to
> `geos::io::WKTReader::read(std::__cxx11::basic_string std::char_traits, std::allocator > co
> nst&)'
> 
> 
> ---
> 
> Rebuilt geos, updated it in mock and then osm2pgsql 0.87.2 built fine as
> well.

I just kicked off a geos rebuild.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
-- 
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: systemd-219 issues with 22 and Rawhide composes

[Jóhann B. Guðmundsson]

On 02/26/2015 03:49 PM, Reindl Harald wrote:




and without the "ownership model" it would have been prevented
what model would you use?
you can't only say "that model is wrong" without any alternative


I have already mentioned alternative before no need to repeat that 
proposal to you.


Bottom line that model will not be change due to Red Hat requiring to 
keep components it ships under its own control.


Why do you think the distribution has been split into cores and extra 
again now through "products" ?


JBG
--
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: systemd-219 issues with 22 and Rawhide composes

[Jóhann B. Guðmundsson]

On 02/26/2015 03:58 PM, Reindl Harald wrote:


Am 26.02.2015 um 16:54 schrieb Jóhann B. Guðmundsson:

On 02/26/2015 03:49 PM, Reindl Harald wrote:


and without the "ownership model" it would have been prevented
what model would you use?
you can't only say "that model is wrong" without any alternative


I have already mentioned alternative before no need to repeat that
proposal to you.

Bottom line that model will not be change due to Red Hat requiring to
keep components it ships under its own control.


you typical Red Hat flame.


s/flame/facts




Why do you think the distribution has been split into cores and extra
again now through "products"?


that is nonsense and you know that!



It is not.

JBG
--
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: Why sysrq is limited to only "sync" command on official fedora kernel?

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 26, 2015 at 08:51:46AM -0700, Pete Travis wrote:
> The only time I've needed sysrq reboots in recent memory was while running
> rawhide and knowingly venturing into uncharted territory.  If I'm not the
> only one, would it make sense to include appropriate sysctl snippets in
> fedora-release-rawhide ?
We could ship /etc/sysctl.d/sysrq-enable.conf.disabled (name up for discussion),
and interested users could enable it by renaming the file. Maybe even better
to provide it the same in all versions.

Zbyszek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 22 | Firefox 35 | Adwaita Dark Theme

[Carlos Morel-Riquelme]

Hi folks today i update to F22 Workstation ( fresh install ) and well when
the adwaita dark theme is active, the textfield of Firefox 35 have as
background color ( white) and the text have the same color.

here a example of devel list page
firefox + adwaita dark
https://ipomoeba.fedorapeople.org/_shots/Scr1.png


could be this a bug ?
-- 
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: koji is broken

[Ralf Corsepius]

On 02/26/2015 04:40 PM, Kevin Fenzi wrote:

On Thu, 26 Feb 2015 15:26:32 +0100
Dan Horák  wrote:


On Thu, 26 Feb 2015 15:11:33 +0100
Ralf Corsepius  wrote:


Hi,

seems to me as if koji has seized operation:

https://kojipkgs.fedoraproject.org//work/tasks/1304/9081304/root.log
https://kojipkgs.fedoraproject.org//work/tasks/1319/9081319/root.log


I guess this is the known "squid doesn't respond" issue. nirik will
restart it.


Rather it's the known 'squid starts being very slow and failing some
builds' so that was me restarting it.

Just resubmit for now.


# fedpkg build
...
Could not execute build: [('SSL routines', 'SSL3_WRITE_BYTES', 'ssl 
handshake failure')]

...


I am working on tracking down the problem, but it's proving quite
elusive. ;(


BTW: Here's another variant of a break down:
https://kojipkgs.fedoraproject.org//work/tasks/1835/9081835/root.log

This time, yum/dnf (whatever currently is being used, I presume it's 
yum) is demonstrating one of the yum/dnf issues we discussed yesterday:


Yum retries to download packages from a mirror it could have know to be 
broken, because it failed to connect to it before.



Ralf

--
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: koji is broken

[Kevin Fenzi]

On Thu, 26 Feb 2015 17:06:03 +0100
Ralf Corsepius  wrote:

> On 02/26/2015 04:40 PM, Kevin Fenzi wrote:
> > On Thu, 26 Feb 2015 15:26:32 +0100
> > Dan Horák  wrote:
> >
> >> On Thu, 26 Feb 2015 15:11:33 +0100
> >> Ralf Corsepius  wrote:
> >>
> >>> Hi,
> >>>
> >>> seems to me as if koji has seized operation:
> >>>
> >>> https://kojipkgs.fedoraproject.org//work/tasks/1304/9081304/root.log
> >>> https://kojipkgs.fedoraproject.org//work/tasks/1319/9081319/root.log
> >>
> >> I guess this is the known "squid doesn't respond" issue. nirik will
> >> restart it.
> >
> > Rather it's the known 'squid starts being very slow and failing some
> > builds' so that was me restarting it.
> >
> > Just resubmit for now.
> 
> # fedpkg build
> ...
> Could not execute build: [('SSL routines', 'SSL3_WRITE_BYTES', 'ssl 
> handshake failure')]
> ...

That should be completely unrelated to the kojipkgs issue, as that is
talking to the koji hub directly. 

Can you do a:

koji list-tasks --mine

> > I am working on tracking down the problem, but it's proving quite
> > elusive. ;(
> 
> BTW: Here's another variant of a break down:
> https://kojipkgs.fedoraproject.org//work/tasks/1835/9081835/root.log
> 
> This time, yum/dnf (whatever currently is being used, I presume it's 
> yum) is demonstrating one of the yum/dnf issues we discussed
> yesterday:
> 
> Yum retries to download packages from a mirror it could have know to
> be broken, because it failed to connect to it before.

Sure, but then it would have just failed faster as thats the only
mirror thats defined internally for builders. 

This was caused by my restarting squid. 

kevin




pgpCtE440p51r.pgp
Description: OpenPGP digital signature
-- 
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: koji is broken

[Ralf Corsepius]

On 02/26/2015 05:12 PM, Kevin Fenzi wrote:

On Thu, 26 Feb 2015 17:06:03 +0100
Ralf Corsepius  wrote:


On 02/26/2015 04:40 PM, Kevin Fenzi wrote:

On Thu, 26 Feb 2015 15:26:32 +0100
Dan Horák  wrote:


On Thu, 26 Feb 2015 15:11:33 +0100
Ralf Corsepius  wrote:


Hi,

seems to me as if koji has seized operation:

https://kojipkgs.fedoraproject.org//work/tasks/1304/9081304/root.log
https://kojipkgs.fedoraproject.org//work/tasks/1319/9081319/root.log


I guess this is the known "squid doesn't respond" issue. nirik will
restart it.


Rather it's the known 'squid starts being very slow and failing some
builds' so that was me restarting it.

Just resubmit for now.


# fedpkg build
...
Could not execute build: [('SSL routines', 'SSL3_WRITE_BYTES', 'ssl
handshake failure')]
...


That should be completely unrelated to the kojipkgs issue, as that is
talking to the koji hub directly.


And would you have the kindness to tell me what I can to about it?


Can you do a:

koji list-tasks --mine


# koji list-tasks --mine
Error: [('SSL routines', 'SSL3_READ_BYTES', 'ssl handshake failure')]




I am working on tracking down the problem, but it's proving quite
elusive. ;(


BTW: Here's another variant of a break down:
https://kojipkgs.fedoraproject.org//work/tasks/1835/9081835/root.log

This time, yum/dnf (whatever currently is being used, I presume it's
yum) is demonstrating one of the yum/dnf issues we discussed
yesterday:

Yum retries to download packages from a mirror it could have know to
be broken, because it failed to connect to it before.


Sure, but then it would have just failed faster as thats the only
mirror thats defined internally for builders.


yum could have tried a different mirror instead of retrying the already 
broken one again.


--
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: Libinput now enabled as default xorg driver for F-22 workstation installs

[Kevin Fenzi]

On Thu, 26 Feb 2015 09:49:48 +0100
Hans de Goede  wrote:

> Yes, we need to maintain both stacks for a while anyways for e.g.
> lxde users, etc. Given that XFCE now supports libinput too, we could
> reconsider this and make xorg-drv-libinput a hard dep of the X server
> so that everyone gets it, but officially we are past the end of the
> feature merge window.
> 
> Peter, any thoughts on this ?

Note that Xfce does have support commited to the 4.11.x branch, but
thats not in Fedora currently. :) We could backport that patch to 4.10,
but we are hoping there might actually be a 4.12 release this coming
weekend, and if all looks good/stable in rawhide, we might push for a
late f22 change to get it in f22. 

If all that happens, then yes, we would be fine with a libinput
change. ;) 

kevin


pgpQr_EJjkwXA.pgp
Description: OpenPGP digital signature
-- 
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: koji is broken

[Kevin Fenzi]

On Thu, 26 Feb 2015 17:22:01 +0100
Ralf Corsepius  wrote:

> And would you have the kindness to tell me what I can to about it?

I'm not sure. It's some issue with your communication to the koji
hub... 

> > Can you do a:
> >
> > koji list-tasks --mine
> 
> # koji list-tasks --mine
> Error: [('SSL routines', 'SSL3_READ_BYTES', 'ssl handshake failure')]

Is your fedora koji cert up to date? 

Do: 

fedora-cert -v

and if it's expired it should offer to issue you a new one. 
Usually however, it would say expired, not handshake failure. 

Can you ping koji.fedoraproject.org? browse to it? 
Is the time correct on your machine?

> >>> I am working on tracking down the problem, but it's proving quite
> >>> elusive. ;(
> >>
> >> BTW: Here's another variant of a break down:
> >> https://kojipkgs.fedoraproject.org//work/tasks/1835/9081835/root.log
> >>
> >> This time, yum/dnf (whatever currently is being used, I presume
> >> it's yum) is demonstrating one of the yum/dnf issues we discussed
> >> yesterday:
> >>
> >> Yum retries to download packages from a mirror it could have know
> >> to be broken, because it failed to connect to it before.
> >
> > Sure, but then it would have just failed faster as thats the only
> > mirror thats defined internally for builders.
> 
> yum could have tried a different mirror instead of retrying the
> already broken one again.

There's no other mirrors for internal builds. It's a baseurl to the
kojipkgs server. 

I am considering making another kojipkgs server and making them round
robin in dns. At least with this restarting squid won't break a bunch
of builds. 

kevin


pgpYlLr3ukA_X.pgp
Description: OpenPGP digital signature
-- 
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: koji is broken

[Kushal Das]

On Thu, Feb 26, 2015 at 10:44 PM, Kevin Fenzi  wrote:
> On Thu, 26 Feb 2015 17:22:01 +0100
> Ralf Corsepius  wrote:
>
>> And would you have the kindness to tell me what I can to about it?
>
> I'm not sure. It's some issue with your communication to the koji
> hub...
>
>> > Can you do a:
>> >
>> > koji list-tasks --mine
>>
>> # koji list-tasks --mine
>> Error: [('SSL routines', 'SSL3_READ_BYTES', 'ssl handshake failure')]
>
> Is your fedora koji cert up to date?
>
> Do:
>
> fedora-cert -v
>
> and if it's expired it should offer to issue you a new one.
> Usually however, it would say expired, not handshake failure.
>
> Can you ping koji.fedoraproject.org? browse to it?
> Is the time correct on your machine?
>
I also get the same error. I have update cert. I can ping and browse koji.
Time is correct in the system.

Kushal
-- 
Fedora Cloud Engineer
CPython Core Developer
Director Python Software Foundation
http://kushaldas.in
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Package giveaway

[Tomas Bzatek]

I've just made the packages listed below orphan due to my departure from
my current employer. Unfortunately I won't be able to invest my personal
free time either.

fpc: epel7 el6 el5
lazarus: epel7 el6 el5
tuxcmd
udisks2

Feel free to pick up any.
-- 
Tomas Bzatek 


-- 
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: To Whomever: You Made My Day

[Máirín Duffy]

On 02/26/2015 08:31 AM, John Florian wrote:

Yesterday I was browsing the Fedora pkgdb/git/bohdi pages and this
morning I returned to go backwards thru my web browser history when I
stumbled upon a real hidden gem for a HTTP 500 response.  Our hot dog
armed with a ray gun against a nuclear panda… oh man that was great.
Best 500 I’ve seen yet.


For the curious :)

https://apps.fedoraproject.org/packages/inkscape/sdfgsdgf

~m
--
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: koji is broken

[Ralf Corsepius]

On 02/26/2015 06:14 PM, Kevin Fenzi wrote:

On Thu, 26 Feb 2015 17:22:01 +0100
Ralf Corsepius  wrote:


And would you have the kindness to tell me what I can to about it?


I'm not sure. It's some issue with your communication to the koji
hub...


Meanwhile I rebooted (for unrelated reasons), now the ssl-errors are 
gone. So, it have been could be your or my end - No idea.



Can you do a:

koji list-tasks --mine


# koji list-tasks --mine
Error: [('SSL routines', 'SSL3_READ_BYTES', 'ssl handshake failure')]


Is your fedora koji cert up to date?


Yes it is.


Do:

fedora-cert -v

and if it's expired it should offer to issue you a new one.
Usually however, it would say expired, not handshake failure.

Can you ping koji.fedoraproject.org? browse to it?
Is the time correct on your machine?


Yes, yes and yes ... BTW: koji/fedpkg now seems to work again.


I am working on tracking down the problem, but it's proving quite
elusive. ;(


BTW: Here's another variant of a break down:
https://kojipkgs.fedoraproject.org//work/tasks/1835/9081835/root.log

This time, yum/dnf (whatever currently is being used, I presume
it's yum) is demonstrating one of the yum/dnf issues we discussed
yesterday:

Yum retries to download packages from a mirror it could have know
to be broken, because it failed to connect to it before.


Sure, but then it would have just failed faster as thats the only
mirror thats defined internally for builders.


yum could have tried a different mirror instead of retrying the
already broken one again.


There's no other mirrors for internal builds. It's a baseurl to the
kojipkgs server.


Yes, my point is it is X times trying in vain to access a host to 
download X packages. Not sure what happens when this happens with a real 
mirrorlist/metalink-list, whose top 5 are unreachable/flakey/dead or broken.


I am sure I've seen, yum iterating X times over the same list of broken 
mirrors.


Ralf



--
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: Hardened builds

[Rex Dieter]

Jerry James wrote:

> On Wed, Feb 25, 2015 at 9:53 AM, Rex Dieter  wrote:
>> Mamoru TASAKA wrote:
>>> Does
>>> %undefine _hardened_build
>>> help?
>>
>> that version works for me
> 
> Hmmm, am I doing something wrong?  I've tried both:
> 
> %undefine _hardened_build
> 
> and:
> 
> %undefine _hardened_build
> %global _hardened_build 0
> 
> at the top of the spec file, and in both cases, I still see the
> hardened specs in CFLAGS and LDFLAGS when %configure is invoked.  I've
> got the right spec file inside the mock root.  I don't understand
> why this worked for you and isn't working for me.

which package is this again?  I can try experimenting a bit.

The one that worked for me was lightdm, fwiw.

-- Rex

-- 
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: koji is broken

[Matěj Cepl]

On 2015-02-26, 16:22 GMT, Ralf Corsepius wrote:
>> That should be completely unrelated to the kojipkgs issue, as that is
>> talking to the koji hub directly.
>
> And would you have the kindness to tell me what I can to about it?

This is usually very clear and obvious way how Koji tells me 
that my certificates have expired. Running fedora-packager-setup 
should take care of it.

Matěj

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Packages

[Rahul Sundaram]

Hi

I would like to give away as many packages as I can to others who are
interested.  My current job keeps me pretty busy and I have been hanging on
to them in hopes of finding the elusive free time that I don't get much of
anymore.  So if you to be a comaintainer or want to take over anything that
I am the point of contact, feel free to drop a request in pkgdb and send me
a note off list as well.   Thanks for those who have stepped in from time
to time.

The list of packages is at

https://admin.fedoraproject.org/pkgdb/packager/sundaram/

Rahul
-- 
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: koji is broken

[Ralf Corsepius]

On 02/26/2015 06:44 PM, Matěj Cepl wrote:

On 2015-02-26, 16:22 GMT, Ralf Corsepius wrote:

That should be completely unrelated to the kojipkgs issue, as that is
talking to the koji hub directly.


And would you have the kindness to tell me what I can to about it?


This is usually very clear and obvious way how Koji tells me
that my certificates have expired. Running fedora-packager-setup
should take care of it.


The koji message is far from being clear.

My certificate definitely had not expired.

From ~/.fedora.cert
...
  Validity
Not Before: Feb  3 03:23:15 2015 GMT
Not After : Aug  2 03:23:15 2015 GMT
...

# fedora-cert -v
Verifying Certificate
cert expires: 2015-08-02

Ralf

--
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: To Whomever: You Made My Day

[Neal Gompa]

Sweetness!

On Thu, Feb 26, 2015 at 12:37 PM, Máirín Duffy 
wrote:

> On 02/26/2015 08:31 AM, John Florian wrote:
>
>> Yesterday I was browsing the Fedora pkgdb/git/bohdi pages and this
>> morning I returned to go backwards thru my web browser history when I
>> stumbled upon a real hidden gem for a HTTP 500 response.  Our hot dog
>> armed with a ray gun against a nuclear panda… oh man that was great.
>> Best 500 I’ve seen yet.
>>
>
> For the curious :)
>
> https://apps.fedoraproject.org/packages/inkscape/sdfgsdgf
>
> ~m
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
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: Packages

[Haïkel]

Hi Rahul,

I wish you all the best in your new job :)

I suggest that you add the python-sig as co-maintainers for your
python packages.
https://admin.fedoraproject.org/pkgdb/packager/group::python-sig/

Regards,
H.
-- 
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: Packages

[Michael Cronenworth]

On 02/26/2015 12:06 PM, Rahul Sundaram wrote:

Hi

I would like to give away as many packages as I can to others who are
interested.  My current job keeps me pretty busy and I have been hanging on to
them in hopes of finding the elusive free time that I don't get much of
anymore.  So if you to be a comaintainer or want to take over anything that I am
the point of contact, feel free to drop a request in pkgdb and send me a note
off list as well.   Thanks for those who have stepped in from time to time.


I will take deluge.

FAS: mooninite

Thanks,
Michael

--
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: Packages

[Matthias Runge]

On 26/02/15 19:06, Rahul Sundaram wrote:
> Hi
> 
> I would like to give away as many packages as I can to others who are
> interested.  My current job keeps me pretty busy and I have been hanging
> on to them in hopes of finding the elusive free time that I don't get
> much of anymore.  So if you to be a comaintainer or want to take over
> anything that I am the point of contact, feel free to drop a request in
> pkgdb and send me a note off list as well.   Thanks for those who have
> stepped in from time to time.
> 
> The list of packages is at
> 
> https://admin.fedoraproject.org/pkgdb/packager/sundaram/
> 
> Rahul
> 
> 

Congrats to the new job!

I'd take
* python-kombu
-> which I maintained for the past years
* python-gdata
-> which is a dependency on one or the other of my packages
* python-billiard
-> I looked after that for a longer time

* django-* packages should be all become retired.

Matthias
-- 
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: To Whomever: You Made My Day

[Matthew Miller]

On Thu, Feb 26, 2015 at 12:37:49PM -0500, Máirín Duffy wrote:
> https://apps.fedoraproject.org/packages/inkscape/sdfgsdgf

Beautiful.

-- 
Matthew Miller

Fedora Project Leader
-- 
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: Packages

[Dave Melia]

Hi Michael,

Are you interested in being a mentor and allow me to assist with Deluge? 
:)


Regards,

Dave

On 2015-02-26 19:22, Michael Cronenworth wrote:

On 02/26/2015 12:06 PM, Rahul Sundaram wrote:

Hi

I would like to give away as many packages as I can to others who are
interested.  My current job keeps me pretty busy and I have been 
hanging on to
them in hopes of finding the elusive free time that I don't get much 
of
anymore.  So if you to be a comaintainer or want to take over anything 
that I am
the point of contact, feel free to drop a request in pkgdb and send me 
a note
off list as well.   Thanks for those who have stepped in from time to 
time.


I will take deluge.

FAS: mooninite

Thanks,
Michael


--
Dave Melia
Site : http://www.thinklinux.co.uk
Email: d...@thinklinux.co.uk
Linkedin : http://uk.linkedin.com/in/davemelia
--
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: Packages

[Michael Cronenworth]

On 02/26/2015 01:43 PM, Dave Melia wrote:

Are you interested in being a mentor and allow me to assist with Deluge? :)


Sure. Apply for commit access.

Regards,
Michael

--
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: Packages

[Rahul Sundaram]

Hi

On Thu, Feb 26, 2015 at 2:22 PM, Michael Cronenworth  wrote:

>
> I will take deluge.
>
> FAS: mooninite


Done

Rahul
-- 
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: Packages

[Rahul Sundaram]

Hi

On Thu, Feb 26, 2015 at 2:25 PM, Matthias Runge wrote:

>
> Congrats to the new job!
>
> I'd take
> * python-kombu
> * python-gdata
> * python-billiard


Thanks and done.


> * django-* packages should be all become retired.
>

I have orphaned them since they have EPEL branches.

Rahul
-- 
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: Packages

[Adam Williamson]

On Thu, 2015-02-26 at 13:06 -0500, Rahul Sundaram wrote:
> Hi
> 
> I would like to give away as many packages as I can to others who 
> are interested.  My current job keeps me pretty busy and I have been 
> hanging on
> to them in hopes of finding the elusive free time that I don't get 
> much of
> anymore.  So if you to be a comaintainer or want to take over 
> anything that
> I am the point of contact, feel free to drop a request in pkgdb and 
> send me
> a note off list as well.   Thanks for those who have stepped in from 
> time
> to time.

I rely on duplicity (via duply) so I'm willing to take it if no-one 
else will, but I'm really no expert on duplicity per se so I might not 
be the best choice. Is anyone with more experience with it willing to 
take it?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
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: python-sig

[Orion Poplawski]

On 02/26/2015 11:22 AM, Haïkel wrote:
> Hi Rahul,
> 
> I wish you all the best in your new job :)
> 
> I suggest that you add the python-sig as co-maintainers for your
> python packages.
> https://admin.fedoraproject.org/pkgdb/packager/group::python-sig/
> 
> Regards,
> H.
> 

I'd like to do this for my python packages - what ACLs are generally
appropriate for this?

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
-- 
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: Packages

[Rahul Sundaram]

Hi

On Thu, Feb 26, 2015 at 3:51 PM, Adam Williamson  wrote:

>
> I rely on duplicity (via duply) so I'm willing to take it if no-one
> else will, but I'm really no expert on duplicity per se so I might not
> be the best choice. Is anyone with more experience with it willing to
> take it?


Limb asked for it first.  So I have given it to him.  You can request
co-maintainership if you are still interested

Rahul
-- 
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: Packages

[Jon Ciesla]

On Thu, Feb 26, 2015 at 2:51 PM, Adam Williamson  wrote:

> On Thu, 2015-02-26 at 13:06 -0500, Rahul Sundaram wrote:
> > Hi
> >
> > I would like to give away as many packages as I can to others who
> > are interested.  My current job keeps me pretty busy and I have been
> > hanging on
> > to them in hopes of finding the elusive free time that I don't get
> > much of
> > anymore.  So if you to be a comaintainer or want to take over
> > anything that
> > I am the point of contact, feel free to drop a request in pkgdb and
> > send me
> > a note off list as well.   Thanks for those who have stepped in from
> > time
> > to time.
>
> I rely on duplicity (via duply) so I'm willing to take it if no-one
> else will, but I'm really no expert on duplicity per se so I might not
> be the best choice. Is anyone with more experience with it willing to
> take it?
>
I already grabbed it.



> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
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: python-sig

[Pierre-Yves Chibon]

On Thu, Feb 26, 2015 at 01:51:13PM -0700, Orion Poplawski wrote:
> On 02/26/2015 11:22 AM, Haïkel wrote:
> > Hi Rahul,
> > 
> > I wish you all the best in your new job :)
> > 
> > I suggest that you add the python-sig as co-maintainers for your
> > python packages.
> > https://admin.fedoraproject.org/pkgdb/packager/group::python-sig/
> > 
> > Regards,
> > H.
> > 
> 
> I'd like to do this for my python packages - what ACLs are generally
> appropriate for this?

Groups cannot have approveacls, so I guess commit and watch* is the easiest way.
You remain the PoC but the sig will have access to the package if needed.


Note: You could also make the SIG PoC of the package but it might dilute the
feeling of responsability towards updates and bug reports, that's something to
determine on a SIG by SIG basis (and/or package by package basis).

Pierre
-- 
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: Packages

[Adam Williamson]

On Thu, 2015-02-26 at 15:54 -0500, Rahul Sundaram wrote:
> Hi
> 
> On Thu, Feb 26, 2015 at 3:51 PM, Adam Williamson  wrote:
> 
> > 
> > I rely on duplicity (via duply) so I'm willing to take it if no-
> > one else will, but I'm really no expert on duplicity per se so I 
> > might not be the best choice. Is anyone with more experience with 
> > it willing to take it?
> 
> 
> Limb asked for it first.  So I have given it to him.  You can 
> request co-maintainership if you are still interested
> 

I don't need it, I'm a proven packager. MUAUAUAUAAHAAHAHAHAHAHAHA

;)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
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: Packages

[Sereinity]

Le jeudi 26 février 2015 à 13:06 -0500, Rahul Sundaram a écrit :
> Hi
> 
> I would like to give away as many packages as I can to others who are
> interested.  My current job keeps me pretty busy and I have been hanging on
> to them in hopes of finding the elusive free time that I don't get much of
> anymore.  So if you to be a comaintainer or want to take over anything that
> I am the point of contact, feel free to drop a request in pkgdb and send me
> a note off list as well.   Thanks for those who have stepped in from time
> to time.
> 
> The list of packages is at
> 
> https://admin.fedoraproject.org/pkgdb/packager/sundaram/
> 
> Rahul

Hi,

I will take e_dbus and evas-generic-loaders.

Note: e_dbus should be retired as soon as all EFL stack will be
upgraded.

Regards.

-- 
Sereinity


-- 
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: Packages

[Pete Travis]

On 02/26/2015 11:06 AM, Rahul Sundaram wrote:
> Hi
>
> I would like to give away as many packages as I can to others who are
interested.  My current job keeps me pretty busy and I have been hanging
on to them in hopes of finding the elusive free time that I don't get
much of anymore.  So if you to be a comaintainer or want to take over
anything that I am the point of contact, feel free to drop a request in
pkgdb and send me a note off list as well.   Thanks for those who have
stepped in from time to time.
>
> The list of packages is at
>
> https://admin.fedoraproject.org/pkgdb/packager/sundaram/
>
> Rahul
>
>
I'll take python-dateutil15, and see it through to retirement once the
last of the dependencies are gone.

I see you've already retired askbot - any sign from upstream that
they'll support a newer django within a reasonable timeframe?

-- 
-- Pete Travis
 - Fedora Docs Project Leader
 - 'randomuser' on freenode
 - immanet...@fedoraproject.org

-- 
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

[Przemek Klosowski]

On 02/26/2015 09:46 AM, Mikolaj Izdebski wrote:
If you really think that old JDK should be removed during update and 
insist on that
I believe that at least on Windows apps, including browser apps, can 
request a specific version of Java runtime. Malware asks for versions 
that are vulnerable to whatever they're up to, of course. Therefore, 
yes, old runtime has to be deleted unless the user specifically requests 
it, presumably because some obsolete app depends on it ('write once, 
debug everywhere').
-- 
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: Why sysrq is limited to only "sync" command on official fedora kernel?

[Pete Travis]

On Feb 26, 2015 9:01 AM, "Zbigniew Jędrzejewski-Szmek" 
wrote:
>
> On Thu, Feb 26, 2015 at 08:51:46AM -0700, Pete Travis wrote:
> > The only time I've needed sysrq reboots in recent memory was while
running
> > rawhide and knowingly venturing into uncharted territory.  If I'm not
the
> > only one, would it make sense to include appropriate sysctl snippets in
> > fedora-release-rawhide ?
> We could ship /etc/sysctl.d/sysrq-enable.conf.disabled (name up for
discussion),
> and interested users could enable it by renaming the file. Maybe even
better
> to provide it the same in all versions.
>
> Zbyszek
> --
>

All versions might be overkill, but I don't see the harm in the added
convenience, either.  What's the next step?

--Pete
-- 
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: Packages

[Rahul Sundaram]

Hi

On Thu, Feb 26, 2015 at 4:22 PM, Sereinity  wrote:

>
> Hi,
>
> I will take e_dbus and evas-generic-loaders.
>

Done.  The e* stack is quite old in Fedora now.  If you or anyone else
wants to keep it more current, that would be nice

Rahul
-- 
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: Packages

[Rahul Sundaram]

Hi

On Thu, Feb 26, 2015 at 9:28 AM, Pete Travis wrote:

> I'll take python-dateutil15, and see it through to retirement once the
> last of the dependencies are gone.
>

Done.


> I see you've already retired askbot - any sign from upstream that they'll
> support a newer django within a reasonable timeframe?
>

They intend to but no specific timeframe

Rahul
-- 
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: Libinput now enabled as default xorg driver for F-22 workstation installs

[poma]

On 26.02.2015 18:11, Kevin Fenzi wrote:
> On Thu, 26 Feb 2015 09:49:48 +0100
> Hans de Goede  wrote:
> 
>> Yes, we need to maintain both stacks for a while anyways for e.g.
>> lxde users, etc. Given that XFCE now supports libinput too, we could
>> reconsider this and make xorg-drv-libinput a hard dep of the X server
>> so that everyone gets it, but officially we are past the end of the
>> feature merge window.
>>
>> Peter, any thoughts on this ?
> 
> Note that Xfce does have support commited to the 4.11.x branch, but
> thats not in Fedora currently. :) We could backport that patch to 4.10,
> but we are hoping there might actually be a 4.12 release this coming
> weekend, and if all looks good/stable in rawhide, we might push for a
> late f22 change to get it in f22. 
> 
> If all that happens, then yes, we would be fine with a libinput
> change. ;) 
> 
> kevin
> 
> 
> 

You still do not believe!?

Schedule for and Status of the Xfce 4.12 Development Cycle
https://wiki.xfce.org/releng/4.12/roadmap

2015-02-28 or 1 day later   Xfce 4.12 (Final Release)   Celebrate

:)


-- 
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: Libinput now enabled as default xorg driver for F-22 workstation installs

[Kevin Fenzi]

On Thu, 26 Feb 2015 20:26:18 +0100
poma  wrote:

> You still do not believe!?
> 
> Schedule for and Status of the Xfce 4.12 Development Cycle
> https://wiki.xfce.org/releng/4.12/roadmap
> 
> 2015-02-28 or 1 day later Xfce 4.12 (Final Release)
> Celebrate

I shall believe when I start downloading the 4.12 release source. ;) 

kevin






pgpQRqxKWmQeI.pgp
Description: OpenPGP digital signature
-- 
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: Orphaned packages up for new point of contact

[Ralf Corsepius]

On 02/26/2015 06:32 AM, Ralf Corsepius wrote:

On 02/25/2015 08:48 PM, Kevin Fenzi wrote:

The following packages had their point of contact changed to orphan
based on: https://fedorahosted.org/fesco/ticket/1417




fakechroot -- Gives a fake chroot environment ( master f22 f21 f20 )
fakeroot -- Gives a fake root environment ( master f22 f21 f20 )
po4a -- A tool maintaining translations anywhere ( master f22 f21 f20 )


I intend to take these. I am already co-maintainer of these and have
been de-facto maintaining them for years.


I am abandoning this intention and have dropped all co-maintainership of 
these.


Ralf


--
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: Package giveaway

[Michael Catanzaro]

On Thu, Feb 26, 2015 at 11:29 AM, Tomas Bzatek  
wrote:
I've just made the packages listed below orphan due to my departure 
from
my current employer. Unfortunately I won't be able to invest my 
personal

free time either.

fpc: epel7 el6 el5
lazarus: epel7 el6 el5
tuxcmd
udisks2

Feel free to pick up any.


I took udisks2 and also added the GNOME SIG as committers since it's 
essential for Fedora Workstation.


Michael
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct