Re: List of packages with problematic license
On Mon, 3 Jan 2022 at 18:35, Miro Hrončok wrote: > > On 03. 01. 22 19:16, Sérgio Basto wrote: > > Testing rpm-specs/hibernate-jpa-2.0-api.spec > > No terminal defined for 'E' at line 1 col 2 > > > > EPL and BSD > > > > What is the problem with this one ? > > There is no EPL in https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses > -- just EPL-1.0 and EPL-2.0. > EPL was renamed as EPL-1.0 when EPL-2.0 was added. However, don't make the assumption that your project is still EPL-1.0 because many projects moved over to EPL-2.0 after it was released. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers
On Tue, 21 Dec 2021 at 14:35, Alexander Bokovoy wrote: > > I picked up wsdl4j to prevent actions which would lead to tomcat, Dogtag, and > FreeIPA being orphaned over Christmas break. > Have you tried building tomcat without wsdl? I can't see where in the tomcat source it is used. Is it really a build dep? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers
On Mon, 6 Dec 2021 at 10:43, Richard W.M. Jones wrote: > > On Mon, Dec 06, 2021 at 11:21:34AM +0100, Miro Hrončok wrote: > > Full report available at: > > https://churchyard.fedorapeople.org/orphans-2021-12-06.txt > > grep it for your FAS username and follow the dependency chain. > > Could we get rid of the limit > > "Too many dependencies for wsdl4j, not all listed here" > > in the long reports? I don't really care how big that text file is in > my browser. > > > For human readable dependency chains, > > see https://packager-dashboard.fedoraproject.org/ > > For all orphaned packages, > > see https://packager-dashboard.fedoraproject.org/orphan > > This is nicer, not sure if I've seen this before. > > Looks like the main breakage is: > > mingw-nsis -> scons -> fop -> tomcat -> wsdl4j > > That gets increasingly weird. NSIS is an installer builder for > Windows (fine), scons is a Python-based build system (also fine), > fop is a documentation formatting tool, tomcat is an application > server (!) > > So I wonder why a Python-based build system relies on a Java-based > application server. > Well, for whatever reason, upstream fop contains a servlet implementation (which requires an app server) but we don't even build or ship this servlet in our fop package. I removed an unnecessary BR on 'servlet' from the fop package: https://src.fedoraproject.org/rpms/fop/c/fba0361894999fbf17c8672e96d4dc95cc06314f?branch=rawhide Does that add more sanity to the dep chain? -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: java-17-openjdk mass-rebuild for f36 in copr I
On Mon, 29 Nov 2021 at 13:16, Jiri Vanek wrote: > > I would kindly ask you to search yourself in this list: > https://github.com/judovana/FedoraSystemJdkBump/blob/main/scritps/fillCopr/exemplarResults/maintainers.jbump This list contains dead/retired packages. Any chance to regenerate it excluding such? -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Possibly off topic: Slack will discontinue packaging for Fedora
On Fri, 5 Nov 2021 at 17:41, Matthew Miller wrote:
>
> On Fri, Nov 05, 2021 at 10:24:22AM -0700, Gordon Messmer wrote:
> > What I'm asking is whether Fedora, as an organization, is interested
> > in working with prominent vendors to determine whether there are
> > barriers to publishing software for Fedora, or whether they perceive
> > insufficient value in doing so. And, beyond those questions, is
> > there anything we can do as an organization to help change that
> > situation?
>
> I've got thoughts! :)
>
> 1. I think we have some historical wariness of this, because a while ago, we
> put in a big effort around this and it failed. See
> https://fedoraproject.org/wiki/ISV_Special_Interest_Group, which currently
> says "This page was last edited on 12 June 2010, at 22:15." (It won't in a
> second, as I'm adding the {{old}} macro right now...). Former FPL Greg
> DeKoenigsberg
> has some thoughts on why this failed, written about two years after that.
> https://gregdekspeaks.wordpress.com/2012/01/06/why-the-fedora-isv-sig-never-caught-fire/
>
After being a flatpak app maintainer for a few years, Greg's article
was well worth the reread. Flatpak has really nailed some of these
points (e.g. targeting all distros with a single build/release
process, binary dependency predictability, etc)... From an ISV
perspective Flatpak is a *much* better value for money prospect than
in-distro packaging.
--
Mat Booth
http://fedoraproject.org/get-fedora
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: guava 31.0.1 update in rawhide
On Fri, 15 Oct 2021 at 11:12, Mikolaj Izdebski wrote: > > The new version changes API/ABI Honestly it would be more noteworthy if guava did NOT break its API/ABI ;-) -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]
On Wed, 6 Oct 2021 at 11:02, Peter Boy wrote: > > > > Am 06.10.2021 um 07:08 schrieb Michal Srb : > > Hi folks, > > @Matthew Miller Are you still trying to save Fedora from packaging the ocean? > :) > > On Mon, Oct 4, 2021 at 9:10 PM Fabio Valentini wrote: > On Mon, Oct 4, 2021 at 8:49 PM Matthew Miller > wrote: > > > On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote: > > I'm not sure what's the best solution, but I guess the number one > reason to have packages within the Fedora distribution is for a matter > of trust, if this is the case I would argue that a curated list of > maven packages served via a Fedora managed repository would be a > better investment. > > > I'd love to see someone interested in this pursue this idea! I know we > talked about it as long ago as... Flock Prague... and probably before. > > > ….. > > Fedora could ship just Java applications that would bundle JARs (whatever > version they need) from the Fedora Maven repository. I don't see this as a > problem, as long as it would be possible to track what JARs are bundled in > what application. > > Fedora maintainers could then focus on maintaining applications, and not > maintaining a ton of individual libraries that nobody really cares about that > much. > > > I've roughly thought this through with our Java Web CMS project (we don't > currently create Fedora rpm). I think with this idea the effort would be > noticeably reduced. A number of intermediate steps could be omitted. > > My main question: how can we get this going? > > Normally we would first need a concise description and then (try to) discuss > it on java-devel. > > Or is this a case of "do-ocracy“? > Yes ;-) I look forward to reading your proposal on java-devel. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
On Tue, 5 Oct 2021 at 12:08, Peter Boy wrote: > > > > Am 04.10.2021 um 15:07 schrieb Mat Booth : > > Like many Open Source projects, Fedora is a "do-ocracy“ — …. > > A nice phrase with a decent connotation. And it’s true without doubt. > > And at the same time it is also true, Fedora as many other Open Source > projects is as well about coordination and successful cooperation and > communication. And when Debian distribution got into rough waters decades ago > it was not because of a lack of packaging and "do-ocracy“, but of a lack of > coordination and cooperation - just as an example. Same is true for various > Fedora sub-projects. > > And by the way > > As I said before there's always a lot of discussion from people who, > in the end, never get involved. ... > > > your implicit advice for me to just take action instead of arguing is nice > and welcome. However, I have been doing this for quite some time, e.g. by > igniting development of a systematic and supported installation of Wildfly - > albeit mainly as part of my commitment to Fedora Server WG. Not via packaging > - that was found to be practically unfeasible here - but by alternative > means. I invite you to support the effort with your knowledge and experience, > e.g. to find the optimal way to install the upstream binary (simply in /opt > or is there a better way of integration into Fedora Java runtime system, e.g. > similar to Tomcat split up to the different FSH subdirectories, or something > else). > Thanks for the invite, but I've never used Wildfly and have no interest in contributing to Wildfly. > The development of alternatives to rpm packaging was also one of the > suggestions that came up in this thread. > Been there, done that, got the t-shirt. I used my knowledge and experience to develop the flatpak distribution of Eclipse IDE as an alternative to RPMs. Then we orphaned the RPMs in favour using Eclipse as a flatpak application from Flathub. No-one stepped up to continue maintenance of the RPM version so it went away. This is the proper lifecycle of a RPM package; I won't be made to feel bad about that :-) > > … do-ocracy in action! Picking a goal you care about and setting about > achieving it doesn't require a SIG, it requires you to "do." > > So, do you have any specific, concrete goal you want to achieve? If > the removal of a Java package has affected you directly or a Java > application you care about is in danger of being removed that would be > a excellent place to start. > > > Most of this thread was not about package x.y.z but about broader issues, > such as outdated/misleading documentation and information, disruptive and > untrustworthy development histories (failing one of the core values of Java), > need for alternatives to the current packaging process (e.g. "curated list“ > as mentioned in a previous post), etc. All this has an impact on the Fedora > Java eco system. Unfortunately, an answer to those issues cannot get worked > out as a one-man show, I guess. > > > What else really interests me: The "java-maint-sig" will be removed soon. > Then you are really completely content with the Fedora Java world? No > change? No preferrable improvement anywhere? > > Yes I'm content because I have everything I need: a well maintained JDK and well maintained maven. I get my IDE from Flathub and my libraries from Maven Central. I'm a programmer so my use-cases are very basic. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
On Mon, 4 Oct 2021 at 13:07, Peter Boy wrote:
>
> We had a spirited and detailed discussion so far. But nevertheless, I think
> we are none the wiser at the moment. We have many informative contributions
> to the discussion and analyses of the situation.
>
> However, we lack concepts on how to proceed after removing java-maint-sig.
> What consequences do we draw from the analyses?
>
> Emmanuel Seyman has made some suggestions, about 16 posts back. Thoughts on
> those? I posted on the java list some ideas some time ago ('Empowering Fedora
> Java’). Any comments on those?
>
>
>
Like many Open Source projects, Fedora is a "do-ocracy" -- those who
step up to do the work win the responsibility of getting it done. If
you have a clear goal in mind, just go for it.
As I said before there's always a lot of discussion from people who,
in the end, never get involved. And then there are people who are
quietly working away and Getting Things Done™ without the need for
endless discussion. A good example is Nicolas De Amicis who recently
stepped up to revive SWT because he really cares about openjfx in
Fedora and SWT was a dependency. And that is awesome; it is the
do-ocracy in action! Picking a goal you care about and setting about
achieving it doesn't require a SIG, it requires you to "do."
So, do you have any specific, concrete goal you want to achieve? If
the removal of a Java package has affected you directly or a Java
application you care about is in danger of being removed that would be
a excellent place to start.
--
Mat Booth
http://fedoraproject.org/get-fedora
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Adding a contributor to my project
On Thu, 30 Sept 2021 at 18:40, Ravindra Kumar wrote: > > Hi folks, > > https://admin.fedoraproject.org/pkgdb/ is not accessible. How do I add a > contributor to my project? > > Appreciate any help on this. Wow, PkgDb has been gone a long time now :-) Go to: https://src.fedoraproject.org/rpms/ And look at the Users and Groups section on the "Settings" tab. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
On Thu, 30 Sept 2021 at 00:23, Mat Booth wrote: > > On Wed, 29 Sept 2021 at 23:48, Emmanuel Seyman wrote: > > > > * Peter Boy [29/09/2021 23:29] : > > > > > > Any ideas to get it started to fly? > > > > The first step should be to empty the group in FAS and remove its > > bugzilla account from component ownership in Bugzilla (I happen > > to think that this is not a good idea in general but it's even worse > > when the group has no active members). > > > > The second step should be to document the current state of affairs > > in the wiki along with the steps that someone would need to go through > > to revive the group for another try. We could the point anyone who > > wants to contribute to that page and get out of their way while they > > fix things. > > > > As an aside, I'm somewhat surprised that the only commit on the Java > > SIG's main wiki page in nearly 4 years is one that simply fixes a > > spelling mistake. This doesn't jive with the amount of discussion we've > > had on this list nor does it match the amount of work that people claim > > to have done on the stack in recent times. I kind of hate this assumption that work only happens when SIGs are active. I've been maintaining Java packages here for more than a decade, and have seen SIGs come and go. The dormancy or not of a formal SIG has no bearing at all on the amount of care that I have tried to give our packages. And when discussions of revitalising the SIG inevitiably appear, there's a thousand opinions about it from people who (a) are not involved in Java packaging and (b) end up never *becoming* involved in Java packaging. It's hard not to be cynical about such sentiments. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
On Wed, 29 Sept 2021 at 23:48, Emmanuel Seyman wrote: > > * Peter Boy [29/09/2021 23:29] : > > > > Any ideas to get it started to fly? > > The first step should be to empty the group in FAS and remove its > bugzilla account from component ownership in Bugzilla (I happen > to think that this is not a good idea in general but it's even worse > when the group has no active members). > > The second step should be to document the current state of affairs > in the wiki along with the steps that someone would need to go through > to revive the group for another try. We could the point anyone who > wants to contribute to that page and get out of their way while they > fix things. > > As an aside, I'm somewhat surprised that the only commit on the Java > SIG's main wiki page in nearly 4 years is one that simply fixes a > spelling mistake. This doesn't jive with the amount of discussion we've > had on this list nor does it match the amount of work that people claim > to have done on the stack in recent times. > > I would encourage people who want to restart the SIG to reach out to > other distributions and enquire as to how they handle their Java stack. > While I'm as much into Fedora exceptionalism as any other packager, I'm > certain that other distributions have the same problems packaging Java > that we do. At worst, doing this would give us insight into how the > stack can be kept in working condition and, at best, we could gain > new contributers. > > On that topic, I've just read an interview of Nicolas Lécureuil, the > president of the Mageia board, in which he says that Mageia's Java stack > is based on Fedora's and that he interacts with Fedora's Java team > (leading me to wonder who exactly he is interacting with given Fabio's > description of the SIG's activity in the opening mail of this thread). > I've interacted with Java people from Mageia many times over the years. They periodically rebase their stack on Fedora's and have been pretty good at finding things that I didn't notice had stopped working such as bootstapping modes that we don't exercise very often for example. I've made a bunch of changes based on their reports and merged a bunch of changes from them too, so kudos to them. They've historically been active on #fedora-java IRC channel, so I'm sure I'm not the only one with such interactions. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
> Yeah, there's good tooling support for packaging software that uses > ant and maven. > And ant and maven themselves will also continue to be maintained by > Mikolaj, as far as I know. > Projects that use "pure" ant or maven to handle their dependencies and > build are *very easy* to package for Fedora, probably even easier than > some standard C or Python packages. You're not wrong. Thanks to great tooling, there's many Java packages in Fedora whose spec file is simply this: %build %mvn_build %install %mvn_install However, I do feel the pain of upstream projects switching to gradle, not because they are experiencing problems with maven that gradle was designed to solve, but just because it's trendy. I personally ported several projects back over to maven build system to keep something vital in the distro. It's not difficult (maybe, for someone who has been using maven years and years and years), but quite tedious. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora ? Java: The Death of Two SIGs
On Mon, 27 Sept 2021 at 17:31, Richard W.M. Jones wrote: > > On Mon, Sep 27, 2021 at 04:39:03PM +0100, Mat Booth wrote: > > On Mon, 27 Sept 2021 at 13:31, Richard W.M. Jones wrote: > > > https://bugzilla.redhat.com/show_bug.cgi?id=1536762 > > > > > > so it might be more of a saga than just changing a few commands. > > > > > > Rich. > > > > Hi Rich, > > > > TBH it looks like your Java bindings should build fine on Java 11 > > since this change: > > > > https://github.com/libguestfs/libguestfs/commit/662dc5d0bf65e72dab11aa58d4bc373b5a3b7e75 > > You're right - I checked just now using: > > java-11-openjdk-headless-11.0.11.0.9-4.fc35.x86_64 > javapackages-filesystem-6.0.0-1.fc35.noarch > javapackages-tools-6.0.0-1.fc35.noarch > > Tests pass too. > > The bug above is a bit worrying though. I don't think anyone ever > tried to address those issues. I don't know enough to say if they're > real or nice to haves, but they seem serious. > I think the only super serious one is the local reference leaks -- this can be fatal to an application. The other concerns seem "just" perf-related. > BTW another project that would be fun for Java bindings (none exist > presently) is nbdkit https://gitlab.com/nbdkit/nbdkit > > Rich. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora ? Java: The Death of Two SIGs
On Mon, 27 Sept 2021 at 13:31, Richard W.M. Jones wrote: > > On Mon, Sep 27, 2021 at 12:15:32PM +0100, Mat Booth wrote: > > On Mon, 27 Sept 2021 at 12:07, Richard W.M. Jones wrote: > > > > > > A question about this which is semi-related to your email. > > > > > > For some C library packages we have Java bindings, eg: > > > https://github.com/libguestfs/libguestfs/tree/master/java > > > > > > These have been disabled in Fedora for ~2 years, but when they were > > > around they had these BuildRequires: > > > > > > BuildRequires: java-1.8.0-openjdk > > > BuildRequires: java-1.8.0-openjdk-devel > > > BuildRequires: jpackage-utils > > > > > > I believe the only requirements are javac, javah, javadoc (optional) > > > and a JVM to run the tests on. > > > > > > Is it possible to keep this going, or would that require a lot of > > > work? I notice that javah no longer seems to exist. > > > > > > (Note I know almost nothing about how the modern JDK works) > > > > > > Rich. > > > > Hi, the functionality provided by javah has been folded into javac in > > recent JDKs. > > > > These days you can make one call to "javac -h" instead of having to > > call both "javac" and "javah" > > > > I ported quite a few packages this way when Fedora made the switch to > > Java 11 by default. If you like I can probably take a look libguestfs > > and send you a PR? > > Sure thing, thanks. > > However before you start you might also want to know that there are > apparently some serious GC-related problems with how those bindings > work: > > https://bugzilla.redhat.com/show_bug.cgi?id=1536762 > > so it might be more of a saga than just changing a few commands. > > Rich. Hi Rich, TBH it looks like your Java bindings should build fine on Java 11 since this change: https://github.com/libguestfs/libguestfs/commit/662dc5d0bf65e72dab11aa58d4bc373b5a3b7e75 > > > > > > > > > -- > > > Richard Jones, Virtualization Group, Red Hat > > > http://people.redhat.com/~rjones > > > Read my programming and virtualization blog: http://rwmj.wordpress.com > > > virt-p2v converts physical machines to virtual machines. Boot with a > > > live CD or over the network (PXE) and turn machines into KVM guests. > > > http://libguestfs.org/virt-v2v > > > ___ > > > devel mailing list -- devel@lists.fedoraproject.org > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > Fedora Code of Conduct: > > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > Do not reply to spam on the list, report it: > > > https://pagure.io/fedora-infrastructure > > > > > > > > -- > > Mat Booth > > http://fedoraproject.org/get-fedora > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-top is 'top' for virtual machines. Tiny program with many > powerful monitoring features, net stats, disk stats, logging, etc. > http://people.redhat.com/~rjones/virt-top > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora ? Java: The Death of Two SIGs
On Mon, 27 Sept 2021 at 12:07, Richard W.M. Jones wrote: > > A question about this which is semi-related to your email. > > For some C library packages we have Java bindings, eg: > https://github.com/libguestfs/libguestfs/tree/master/java > > These have been disabled in Fedora for ~2 years, but when they were > around they had these BuildRequires: > > BuildRequires: java-1.8.0-openjdk > BuildRequires: java-1.8.0-openjdk-devel > BuildRequires: jpackage-utils > > I believe the only requirements are javac, javah, javadoc (optional) > and a JVM to run the tests on. > > Is it possible to keep this going, or would that require a lot of > work? I notice that javah no longer seems to exist. > > (Note I know almost nothing about how the modern JDK works) > > Rich. Hi, the functionality provided by javah has been folded into javac in recent JDKs. These days you can make one call to "javac -h" instead of having to call both "javac" and "javah" I ported quite a few packages this way when Fedora made the switch to Java 11 by default. If you like I can probably take a look libguestfs and send you a PR? > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-p2v converts physical machines to virtual machines. Boot with a > live CD or over the network (PXE) and turn machines into KVM guests. > http://libguestfs.org/virt-v2v > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Why can't I push to a module branch?
On Tue, 14 Sept 2021 at 12:28, Petr Pisar wrote: > > V Tue, Sep 14, 2021 at 10:01:32AM +0100, Mat Booth napsal(a): > > It would help if the PDC were not so inscrutable. > > > > It was my first thought that the branch was EOL, but I had no idea how > > to look it up Is there some UI I'm not aware of? > > > I don't know what you are and aren't aware of. Well, quite. I was trying to imply I don't know of *any* UI. > I only know about API > documentation at <https://pdc.fedoraproject.org/rest_api/v1/>. > This is not a UI ;-) -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Why can't I push to a module branch?
On Tue, 14 Sept 2021 at 09:51, Petr Pisar wrote: > > V Mon, Sep 13, 2021 at 09:27:37PM -0600, Orion Poplawski napsal(a): > > (base) [orion@vmrawhide-rufous openmpi (4.0)]$ git push > > Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 > > remote: Branch refs/heads/4.0 is unsupported > > remote: Denied push for ref 'refs/heads/4.0' for user 'orion' > > remote: All changes have been rejected > > To ssh://pkgs.fedoraproject.org/rpms/openmpi > > ! [remote rejected] 4.0 -> 4.0 (pre-receive hook declined) > > error: failed to push some refs to > > 'ssh://pkgs.fedoraproject.org/rpms/openmpi' > > > Because the branch ended its life on 2020-12-01 > <https://pdc.fedoraproject.org/rest_api/v1/component-branch-slas/?branch_type=rpm_component=openmpi=4.0>. > > The date is set when creating the branch. The date can be changed at > <https://pagure.io/releng/new_issue> with a request of module_eol type. > > It would be great if the dist-git hook reported that. I files a feature > request <https://pagure.io/releng/issue/10299>. > It would help if the PDC were not so inscrutable. It was my first thought that the branch was EOL, but I had no idea how to look it up Is there some UI I'm not aware of? -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: (Re)orphaning jakarta-commons-httpclient
On Fri, 20 Aug 2021 at 19:10, Jerry James wrote: > > I picked up jakarta-commons-httpclient in an attempt to keep > ant-contrib building. That proved impossible, so I removed all > dependencies on ant-contrib from packages I maintain instead. That > means I don't need jakarta-commons-httpclient, so I am orphaning it > again. > Honestly anything that requires jakarta-commons-httpclient should be blacklisted. This library has been EOL and unmaintained for a *decade* and contains all manner of problems. This package should be retired and dependents should be ported to httpcomponents-client or retired also. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Eclipse IDE packages and friends orphaned
On Tue, 17 Aug 2021 at 14:15, Aleksandar Kurtakov wrote: > > > > On Tue, Aug 17, 2021 at 2:08 PM Frank Ch. Eigler wrote: >> >> >> > [...] Eclipse tries to keep up to date with libraries shipped. Quite >> > often the effort of moving to new versions of a library (e.g. lucene) >> > requires changes in Eclipse itself >> >> Is this level of backward non-compatibility typical in Java? > > > I would not say in Java overall but in certain projects - YES! > > There appears to be something stuck in my throat *cough* lucene *cough* guava *cough* -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Eclipse IDE packages and friends orphaned
On Wed, 18 Aug 2021 at 09:58, Vitaly Zaitsev via devel wrote: > > On 18/08/2021 01:32, Mat Booth wrote: > > Not within the constraints of Fedora's packaging rules. > > Bundling is allowed by Fedora's packaging guidelines. > Binaries not built from source are not allowed: https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries You would have to rebuild all Eclipse deps from source -- at that point it is no different in terms of package maintainer effort than maintaining separate RPMs. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Eclipse IDE packages and friends orphaned
On Tue, 17 Aug 2021 at 13:33, Vitaly Zaitsev via devel wrote: > > On 17/08/2021 11:51, Aleksandar Kurtakov wrote: > > Eclipse Flatpak is maintained and updated shortly after upstream Eclipse > > release by the very same people so for now it's the best integration > > achievable with given manpower. > > Is it possible to bundle all dependencies into an Eclipse's RPM package? > Not within the constraints of Fedora's packaging rules. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Eclipse IDE packages and friends orphaned
On Wed, 11 Aug 2021 at 13:20, Vitaly Zaitsev via devel wrote: > > On 11/08/2021 12:35, Aleksandar Kurtakov wrote: > > Eclipse IDE and its ancillary packages are orphaned now. As a result the > > Eclipse IDE will no longer be installable as a package in Fedora 35. > > > Red Hat Eclipse Team > > Even Red Hat employees can't handle the Java Stack on Fedora. This is so > sad. > It is a full time job for one person to maintain Eclipse as RPMs. The Flatpak system is way less overhead for packagers and ISVs. There should be no surprise at all that maintainers of large applications prefer to distribute via Flatpak. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intent to retire - findbugs / findbugs-bcel / findbugs-contrib / eclipse-findbugs
On Tue, 1 Jun 2021 at 10:14, Richard Fearn wrote: > > > Note that your queries did not check for BuildRequires, since you did > > not enable the foo-source repositories. > > That would require "--enablerepo fedora-source --enablerepo > > updates-source", or "--enablerepo rawhide-source" on rawhide. > > Thanks Fabio - I knew I would get something wrong with that query :-) > > > Since findbugs contains code quality checks, I suspect those three > > packages could be built without those checks without problems, since > > they do not require findbugs at install-/ or runtime. > > I expect so too - I doubt the packages need FindBugs in order to > build. I'll take a look at those packages and contact the maintainers > as necessary. > FWIW, many maven-based packages in Fedora already include the following snippet(s) to avoid build-time quality checks that are only of interest to upstream: %pom_remove_plugin :spotbugs-maven-plugin # and/or %pom_remove_plugin :findbugs-maven-plugin That's probably the only change needed by packages that still express a BR on findbugs. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Death of Java (packages)
On Mon, 26 Apr 2021 at 20:20, Fabio Valentini wrote: > > Hi everybody, > > Long story short, I can no longer in good conscience be the primary > maintainer of (most) Java packages in Fedora. I am not using any of > them, I don't like Java or any other languages targeting the JVM, and > don't get me started on the horrid Java ecosystem. Recently I've been > spending 40-60 hours per week at my desk, and I just don't have the > capacity to feel guilty for not taking care of those packages any > longer. > > New versions and even security issues have been piling up for months > (just look at the SIG's taiga board). Other people tried to step up > for the "new" Java SIG (@java-maint-sig), but other than myself, > nobody has been triaging new bugs in Java packages. Java package > maintainers from Red Hat have been exceptionally unhelpful, and have > not substantially contributed to Java packages in Fedora in years. > Even the Modules that were heralded as "the solution" have stagnated. > On the other hand, Mat Booth and two members of the DogTag PKI team > have been really helpful, but Mat is busy fighting the Eclipse > dumpster fire most of the time, and the other two have since both left > Red Hat for greener pastures. And since I see no way for the situation > to improve, there's only one honest thing left that I can do: > > I will orphan all Java packages I am the main admin of, later today. > > Since this is the majority of remaining Java software in Fedora (~180 > packages), I expect at a decent amount of dependent packages will be > affected. However, given the utter lack of Java package maintainers > and the pitiful state of the overall language ecosystem, I would > strongly urge affected maintainers to drop dependencies on Java, if at > all possible. > > Maybe other members of the java-maint-sig will pick up the orphaned > packages, if they're still here. Or maybe it's finally time to let > Java packages die. Nobody seems to care either way. > > Fabio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure I want to echo everyone else's sentiments and give my thanks for being the one to step into Java packaging when you did. I wish I had more time to donate and honestly I thought modularity would help with that too, but it turned out to be a fools' errand and sapped way too much of my time and motivation. I'm sorry I couldn't help out more, and wish you well in your other endeavours. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Future of the Java Stack (also regarding ELN and RHEL)
On Fri, 11 Sep 2020 at 09:54, Tomasz Torcz wrote: > > On Fri, Sep 11, 2020 at 10:16:02AM +0200, Mikolaj Izdebski wrote: > > You get a side tag in Koji where you can have private build-only > > dependencies that are discarded (filtered) once they are no longer > > needed, after module build is done. For build-only packages most of > > security vulnerabilities are not exploitable easily, or at all, > > therefore are low-severity, which greatly limits maintenance work > > required to address them. For example, if upstream tests are ran on an > > obsolete, 12-years old version of Tomcat, I don't need to skip tests, > > but I can package old Tomcat and run the tests. > > Whoha! Let's step back for a minute and look at this example. > What are the reasons to run tests? To make sure the package will run > correctly.. > Why run tests on 12-years old version instead of on current one? > Probably because tests fail on current version? No, not at all. It's not that the tests fail on newer versions (it probably just needs a servlet container environment) but that this is the version of tomcat that was current when the test fixtures were written. Tomcats' changing embedding APIs in no way invalidate tests performed in a standards-compliant servlet container environment. > > Will the end user run the package on obsolete Tomcat or on the current one? > Of course on the current one. The one on which tests fail. > Tests in this case are worthless, they are not testing the real > situation. Disabling tests is no worse than testing on obsolete version. > Relying on such tests is a disservice for the end user. > > The point of testing is to validate code in real situation. > Crafting special, unrealistic environment (12 years old Tomcat) just to have > test pass is missing the point of tests. > > -- > Tomasz Torcz There exists no separation between gods and men: > to...@pipebreaker.pl one blends softly casual into the other. — Frank > Herbert > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity Improvements Objective
On Fri, 24 Jul 2020 at 16:10, Mat Booth wrote: > > On Fri, 24 Jul 2020 at 13:26, Petr Pisar wrote: > > > > On Fri, Jul 24, 2020 at 01:44:07PM +0200, Daniel Mach wrote: > > > There's a Modularity Improvements Objective draft available[1]. > > > > > > The Objective summarizes the work that is in progress already as well as > > > highlights our plans for Fedora 34. > > > > > > We're planning to fix the current modularity in Fedora 33 and 34. > > > We may look into alternatives or bigger design changes in Fedora 35 and > > > later. > > > > > > You can find more details in the Objective document[1]. > > > > > > - Daniel > > > > > > [1] https://fedoraproject.org/wiki/Objectives/Modularity_Improvements_2020 > > > > I hope that you find resources to properly maintain MBS. Currently (last two > > weeks) it cannot build the modules > > <https://pagure.io/fedora-infrastructure/issue/9066>. > > > > -- Petr > > I opened this ticket more than two months ago. :-( > Err, more than one month ago sorry. Apologies if that mischaracterised the situation. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity Improvements Objective
On Fri, 24 Jul 2020 at 13:26, Petr Pisar wrote: > > On Fri, Jul 24, 2020 at 01:44:07PM +0200, Daniel Mach wrote: > > There's a Modularity Improvements Objective draft available[1]. > > > > The Objective summarizes the work that is in progress already as well as > > highlights our plans for Fedora 34. > > > > We're planning to fix the current modularity in Fedora 33 and 34. > > We may look into alternatives or bigger design changes in Fedora 35 and > > later. > > > > You can find more details in the Objective document[1]. > > > > - Daniel > > > > [1] https://fedoraproject.org/wiki/Objectives/Modularity_Improvements_2020 > > I hope that you find resources to properly maintain MBS. Currently (last two > weeks) it cannot build the modules > <https://pagure.io/fedora-infrastructure/issue/9066>. > > -- Petr I opened this ticket more than two months ago. :-( What's *worse* is that before I filed that infra ticket I filed this ticket [1] at the MBS upstream project and that got *absolutely* no response. Complete silence. In fact *no* ticket reported there haven't seen any activity in months. Not exactly confidence inspiring for the future of the project. [1] https://pagure.io/fm-orchestrator/issue/1640 I've tried *so* hard to get on board with modularity but I think I'm done with modules now in Fedora. In the early days the people who maintained MBS were super helpful and worked hard to fix the bugs I found in it, but now it feels like those days are gone and still it's just hurdle after hurdle. All I want is an easy life, and I thought modules were that, but it's impossible to get anything done in a timely manner, builds have required so much babysitting, the MBS requiring (already scarce) releng resources to intervene periodically Honestly, it's been just exhausting and demoralising how many man-hours have gone to waste. So I've pulled all my packages back into mainline Fedora since that seems to be the path of least resistance even though I will once again have to maintain multiple branches of my whole stack of packages. Interesting experiment, maybe, but if there's going to be no commitment to pay the on-going cost of infra maintenance and fix the design-flaws or whatever serious problem is currently holding back MBS, then I have to end the experiment for my own sanity at least. mbooth -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Mass rebuild for f33-java11 side tag completed
On Fri, 17 Jul 2020 at 09:34, Christian Heimes wrote: > > > Hello! > > > > toatal packages: 610 > > passed: 427 > > failed: 176 > > > > From the failures, there is 29 which passed in the copr before, and now are > > thus failing > > from two > > reasons - unrelated change, or non-intel64-arch failure. I will put this to > > FTBF bugs for > > those 29 > > pacakges, > > > > > > In Monday, or as other duties allows I will fill FTBFS bugs for failures > > with straces and > > reproduce > > steps. > > In default CC will be, me, Severin, decathrope and > > java-devel(a)lists.fedoraproject.org. > > > > Note that during non-sidetag rebuild during fedora 33 branching in start of > > August, we > > can expect > > some indirect dependencies to fail. > > > > Thoughts? > > Hi Jiri, > > how will a merge of the Java 11 side tag into F33 Rawhide affect Dogtag > PKI? Dogtag PKI (aka pki-core package) is mostly written on top of the > Tomcat stack. As far as I know the Dogtag team is still working on Java > 11 support. > > Dogtag is a core component of FreeIPA, which is a one of three major > features of Fedora Server collection (the other two are modularity and > Cockpit) [0]. FreeIPA is also part of Fedora's OpenQA effort. It's > likely that Java 11 update is going to break a core feature of Fedora > and QA gating for a considerable amount of packages. > > Could you please hold of the merge of the side tag and work with the > Dogtag team to solve the issue? > > By the way I see a rebuild of Tomcat in the side tag but there is no > pki-core build. Why is pki-core missing from the tag? Is it one of the > FTBFS packages? > > $ koji list-tagged f33-java11 | grep tomcat > tomcat-9.0.36-2.fc33 f33-java11jvanek > tomcat-native-1.2.23-2.fc33 f33-java11jvanek > tomcat-taglibs-parent-3-12.fc33 f33-java11jvanek > tomcatjss-7.5.0-0.5.fc33 f33-java11jvanek > $ koji list-tagged f33-java11 | grep pki > > pki-core fails to build in the side tag with this error: bad class file: /usr/share/java/tomcatjss.jar(org/apache/tomcat/util/net/jss/IPasswordStore.class) class file has wrong version 55.0, should be 52.0 Please remove or make sure it appears in the correct subdirectory of the classpath. That means that tomcatjss has Java 11 bytecode and I guess pki-core is trying to use Java 8. A quick glance at tomcatjss package shows it is built by ant with no sauce/target level specified at all, which means it is built with Java 11 bytecode by default. You should fix this by rebuilding tomcatjss with Java 8 bytecode. Here's an example where I fixed the same problem in another package: https://src.fedoraproject.org/rpms/aopalliance/c/5fdc6912e39fe15fe55cedcc6392847f773d254c -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [fedora-java] Re: Mass rebuild for f33-java11 side tag completed
On Wed, 15 Jul 2020 at 16:54, Mat Booth wrote: > > On Mon, 13 Jul 2020 at 19:14, Jiri Vanek wrote: > > > > > > > > A cursory glance shows that some failed with network problems. E.g. plexus-velocity failed with this: > > > > > > DEBUG util.py:621: Errors during downloading metadata for repository 'build': > > > DEBUG util.py:621:- Curl error (18): Transferred a partial file for > > > http://kojipkgs-cache01.s390.fedoraproject.org/repos/f33-java11/1710873/s390x/repodata/d901882654dc717c8fc91a6b2f018eeaa538eb6e003b0927bc9ae85895a83786-filelists.xml.gz > > > [transfer closed with 23617146 bytes remaining to read] > > > > > > (Sigh, flakey s390x machines, we meet again.) > > > > > > When I retriggered the build it succeeded: https://koji.fedoraproject.org/koji/buildinfo?buildID=1540681 > > > > > > Might be worth a retry of other failures before filing FTBFS bugs. > > > > Thanx! > > > > Will elaborate on this! > > Any update? Any thoughts on when you want to merge the f33-java11 side tag back into rawhide? > BTW There are some packages, e.g. built by ant with no sauce/target level specified at all, that are built with Java 11-level bytecode. This is bad because if there is a dependent package that requires Java 8 for some reason it won't work because the bytecode of one your dependencies is too new and cannot be interpreted by Java 8. In these cases I am fixing such occurrences in the ```f33-java11``` build target as I encounter them -- just something to be aware of in case you see any UnsupportedClassVersionErrors. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [fedora-java] Re: Mass rebuild for f33-java11 side tag completed
On Mon, 13 Jul 2020 at 19:14, Jiri Vanek wrote: > > > > > A cursory glance shows that some failed with network problems. E.g. plexus-velocity failed with this: > > > > DEBUG util.py:621: Errors during downloading metadata for repository 'build': > > DEBUG util.py:621:- Curl error (18): Transferred a partial file for > > http://kojipkgs-cache01.s390.fedoraproject.org/repos/f33-java11/1710873/s390x/repodata/d901882654dc717c8fc91a6b2f018eeaa538eb6e003b0927bc9ae85895a83786-filelists.xml.gz > > [transfer closed with 23617146 bytes remaining to read] > > > > (Sigh, flakey s390x machines, we meet again.) > > > > When I retriggered the build it succeeded: https://koji.fedoraproject.org/koji/buildinfo?buildID=1540681 > > > > Might be worth a retry of other failures before filing FTBFS bugs. > > Thanx! > > Will elaborate on this! Any update? Any thoughts on when you want to merge the f33-java11 side tag back into rawhide? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [fedora-java] Mass rebuild for f33-java11 side tag completed
On Sat, 11 Jul 2020 at 09:24, Jiri Vanek wrote: > > Hello! > > toatal packages: 610 > passed: 427 > failed: 176 > > From the failures, there is 29 which passed in the copr before, and now are thus failing from two > reasons - unrelated change, or non-intel64-arch failure. I will put this to FTBF bugs for those 29 > pacakges, > > > In Monday, or as other duties allows I will fill FTBFS bugs for failures with straces and reproduce > steps. > In default CC will be, me, Severin, decathrope and java-de...@lists.fedoraproject.org. > > Note that during non-sidetag rebuild during fedora 33 branching in start of August, we can expect > some indirect dependencies to fail. > > Thoughts? > > A cursory glance shows that some failed with network problems. E.g. plexus-velocity failed with this: DEBUG util.py:621: Errors during downloading metadata for repository 'build': DEBUG util.py:621:- Curl error (18): Transferred a partial file for http://kojipkgs-cache01.s390.fedoraproject.org/repos/f33-java11/1710873/s390x/repodata/d901882654dc717c8fc91a6b2f018eeaa538eb6e003b0927bc9ae85895a83786-filelists.xml.gz [transfer closed with 23617146 bytes remaining to read] (Sigh, flakey s390x machines, we meet again.) When I retriggered the build it succeeded: https://koji.fedoraproject.org/koji/buildinfo?buildID=1540681 Might be worth a retry of other failures before filing FTBFS bugs. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [fedora-java] Re: Questions on an update to javamail in ursine
Sure, but when updating the javamail package, you will be providing compatibility aliases for the old maven coordinates using %mvn_alias and compatibility symlinks for the old filename using %mvn_file in order to not break dependent packages, right? Right? ;-) Unless a package somehow is not using the felix-bundle-plugin or aqute-bnd, a simple rebuild should fix OSGi metadata (i.e. the next mass rebuild should take care of it). On Mon, 6 Jul 2020 at 19:59, Jie Kang wrote: > Hey Mat, > > On further investigation, the compatibility changes that require > attention are made in javamail 1.6.3 and later, see: > > https://eclipse-ee4j.github.io/mail/docs/COMPAT.txt > > The maven coordinates are changed, generally javax -> jakarta. This > also affects the osgi provides. > > > Regards, > Jie Kang > > On Thu, Jul 2, 2020 at 5:54 AM Mat Booth wrote: > > > > > > > > On Wed, 1 Jul 2020 at 15:05, Fabio Valentini > wrote: > >> > >> On Mon, Jun 29, 2020 at 4:06 PM Jie Kang wrote: > >> > > >> > Hi all, > >> > > >> > javamail ursine is using version 1.5.2 while there are some module > >> > streams at 1.6.x > >> > > >> > The upstream project also moved to the eclipse foundation and these > >> > 1.6.x releases have different exports for OSGi, making an update to > >> > them potentially breaking for users. > >> > > >> > I'd like to update ursine to 1.6.x, but I understand packages > >> > depending on them should be notified or some such. However I realized > >> > I don't know what commands to run to get a list of such and then where > >> > to send it. Could anyone advise? > >> > > >> > Also, upstream repo was renamed: https://github.com/eclipse-ee4j/mail > >> > so maybe a new package 'mail' can be introduced to use it? Any > >> > thoughts there? > >> > >> I use this command to check for dependent packages: > >> > >> $ dnf --repo rawhide --repo rawhide-source --releasever rawhide > >> repoquery --whatrequires javamail > >> > >> Which is enough, since there are no other subpackages except -javadoc. > >> The command yielded (on July 1): > >> > >> ant-0:1.10.8-1.fc33.src > >> ant-javamail-0:1.10.8-1.fc33.noarch > >> bouncycastle-0:1.65-2.fc33.src > >> httpunit-0:1.7-29.fc32.src > >> log4j-0:2.13.1-1.fc33.src > >> log4j12-0:1.2.17-26.fc32.src > >> openas2-0:2.10.0-2.fc33.src > >> openas2-lib-0:2.10.0-2.fc33.noarch > >> > >> So the list of affected packages seems to be: > >> > >> - ant (Stewardship / Java SIG will deal with this) > >> - bouncycastle (?) > > > > > > Bouncycastle is me (it is a dep of jgit). From reading the javamail > "compat" document: https://javaee.github.io/javamail/docs/COMPAT.txt it > looks like I probably will need to take no action at all. > > > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ > java-devel mailing list -- java-de...@lists.fedoraproject.org > To unsubscribe send an email to java-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/java-de...@lists.fedoraproject.org > -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [fedora-java] Questions on an update to javamail in ursine
On Wed, 1 Jul 2020 at 15:05, Fabio Valentini wrote: > On Mon, Jun 29, 2020 at 4:06 PM Jie Kang wrote: > > > > Hi all, > > > > javamail ursine is using version 1.5.2 while there are some module > > streams at 1.6.x > > > > The upstream project also moved to the eclipse foundation and these > > 1.6.x releases have different exports for OSGi, making an update to > > them potentially breaking for users. > > > > I'd like to update ursine to 1.6.x, but I understand packages > > depending on them should be notified or some such. However I realized > > I don't know what commands to run to get a list of such and then where > > to send it. Could anyone advise? > > > > Also, upstream repo was renamed: https://github.com/eclipse-ee4j/mail > > so maybe a new package 'mail' can be introduced to use it? Any > > thoughts there? > > I use this command to check for dependent packages: > > $ dnf --repo rawhide --repo rawhide-source --releasever rawhide > repoquery --whatrequires javamail > > Which is enough, since there are no other subpackages except -javadoc. > The command yielded (on July 1): > > ant-0:1.10.8-1.fc33.src > ant-javamail-0:1.10.8-1.fc33.noarch > bouncycastle-0:1.65-2.fc33.src > httpunit-0:1.7-29.fc32.src > log4j-0:2.13.1-1.fc33.src > log4j12-0:1.2.17-26.fc32.src > openas2-0:2.10.0-2.fc33.src > openas2-lib-0:2.10.0-2.fc33.noarch > > So the list of affected packages seems to be: > > - ant (Stewardship / Java SIG will deal with this) > - bouncycastle (?) > Bouncycastle is me (it is a dep of jgit). From reading the javamail "compat" document: https://javaee.github.io/javamail/docs/COMPAT.txt it looks like I probably will need to take no action at all. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: koji builder status
On Thu, 19 Dec 2019 at 21:13, Dan Horák wrote: > > On Thu, 19 Dec 2019 12:10:00 -0800 > Kevin Fenzi wrote: > > > On Sun, Dec 15, 2019 at 10:24:16AM +0100, Fabio Valentini wrote: > > > > > > Side note: Considering that there are comparatively few armv7hl > > > builders, I wonder why a rather big share of my noarch builds gets > > > scheduled to run on them. Naively, I'd think that armv7hl should be > > > busy doing builds for "archful" stuff since they're the slowest > > > > I'm not sure why that is. I would expect them to be busy more as > > well. Do note that we are bringing some more hardware on line after > > the new year, which should give us more armv7 builders. > > > > > builders and there are the fewest of them, except for s390x. > > > > s390x now is a great deal faster. It's often the one that finishes > > right after x86_64/i686. > > even ahead x86_64/i686 sometimes :-) > This is great to hear! Until now s390x was the slowest arch for Java by quite a wide margin; with the special Java 8 JIT package[1] installed, even 32bit arm was quicker than s390x :-o [1] "java-1.8.0-openjdk-aarch32" -- https://koji.fedoraproject.org/koji/packageinfo?packageID=22627 -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: (thinking about) unretiring xmlbeans
On Thu, 5 Dec 2019 at 12:52, Zbigniew Jędrzejewski-Szmek wrote: > xmlbeans [1,2] got retired because of lack of maitainers. > It's used by diffoscope now, so I'm thinking about adopting it. > Any major reasons not to? Fedora was at 2.6.0, upstream is now at > 3.1.0, so it'd be definitely some effort to update... > > [1] https://xmlbeans.apache.org/ > [2] https://src.fedoraproject.org/rpms/xmlbeans > Huh, I thought this project was retired upstream I'm curious what you need it for -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: Branch requests from non-maintainers
On Mon, 2 Dec 2019 at 12:56, Igor Gnatenko wrote: > Hello, > > 3 months ago, Miro opened releng ticket[0] raising question whether > non-maintainers (of some specific packages) being able to request > branches. > > However, it never went anywhere outside of that ticket. > > I'd like to ask people on this mailing list a few questions. Let's say > we have some theoretical package and it has only one maintainer in > src.fp.o. > > * Should any other packager (not that maintainer) be able to request > new branches on that repo? > Is there a problem with adding such other packagers as comaintainers if they want to maintain such a branch? For example: I am not at all interested in EPEL branches, but if someone wants to maintain an EPEL branch of my package, I have absolutely no problem with adding them as a co-maintainer. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing new anitya integration and de-orphaning process
On Fri, 29 Nov 2019 at 07:32, Igor Gnatenko < ignatenkobr...@fedoraproject.org> wrote: > > Because it is really hard to run two systems at the same time and keep them synced? Then let me rephrase. IMO the replacement system shouldn't have been commissioned into production before it reached feature parity. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: List of long term FTBFS packages to be retired in February (beta)
On Thu, 28 Nov 2019 at 13:06, Miro Hrončok wrote: > Dear maintainers. > > Based on the latest fail to build from source package, the following > packages > will be retired from Fedora 32 approximately one week before branching > (February > 2020). > > Policy: > > https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ > > The packages in rawhide were not successfully built at least since Fedora > 30. > > This report is based on dist tags and represents a preliminary list of > packages. > > Packages collected via: > > https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb > > The main purpose is to gather feedback. > > If you see a package that was built, please let me know. > If you see a package that should be exempted from the process, please let > me > know and we can work together to get a FESCo approval for that. > > If you see a package that can be rebuilt, please do so. > > > Package (co)maintainers Latest > build > > === > elasticsearch hubbitus, jvanek, lbazan,Fedora > 24 >zbyszek This package elasticsearch looks in a half-retired state -- files still present in dist-git, but no build has been attempted since 2016, even by distro-wide mass-rebuilds. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing new anitya integration and de-orphaning process
On Tue, 26 Nov 2019 at 17:21, Pierre-Yves Chibon wrote: > > Good Morning Everyone, > > Tomorrow we are planning on deploying a new version of pagure and > pagure-dist-git on production. Great stuff. I still don't understand why pkgdb was allowed to go away before the replacements reached feature parity. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What's the State of the Java SIG?
On Mon, 18 Nov 2019 at 11:17, John M. Harris Jr wrote: > I must disagree. That it "works" in RHEL doesn't mean that it should be done > in Fedora. The current situation in Fedora, where maven and ant have been > "moved" to modules has screwed over the Eclipse packagers, for example, and > more are to follow. > I'm flattered that you think there is more than one Eclipse packager these days, but it is not my perception that choices made by the maven and ant maintainer has screwed over Eclipse. >From my PoV the problem is that Ursa Prime née Major has been coming Real Soon Now™ for years to obviate the build issues but it just never materialised. This is why the Eclipse stack has gotten into a bit of a pickle -- I waited far too long with far too much naive optimism before modularising and I'm sad to say that not modularising Eclipse sooner has done a great disservice to users. TBH as a desktop application, I see a brighter future in Flatpak for Eclipse and maybe when our Flatpak distribution is mature enough, we can eventually stop shipping RPMs altogether ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] Fedora 32 Python 3.8 rebuilds have started in a side tag
On Fri, 23 Aug 2019 at 17:39, Miro Hrončok wrote: > On 23. 08. 19 17:15, Vít Ondruch wrote: > > > > Dne 23. 08. 19 v 17:05 Kaleb Keithley napsal(a): > >> > >> > >> On Wed, Aug 21, 2019 at 1:23 PM Miro Hrončok >> <mailto:mhron...@redhat.com>> wrote: > >> > >> On 15. 08. 19 0:18, Miro Hrončok wrote: > >> > Hello, in order to deliver Python 3.8, we are running a > coordinated > >> rebuild in a > >> > side tag. > >> > > >> > >> The side tag was merged. Build in regular rawhide now. Thanks. > >> > >> > >> /me wonders why my `dnf update` on my f32/rawhide box isn't updating > to > >> python-3.8. Should it be? > > > > > > I guess there was no Rawhide compose yet, which would contain the > changes. I > > would not be surprised if the merge broke the compose. > > We are monitoring it to firefight any such breakage, but the current > breakage is > not relevant to 3.8. > > I noticed that eclipse-pydev stopped building with the introduction of python 3.8. Can you offer any clue how to fix it? Here is the log, you can see that the cython-based debugging extension when built against python 3.8 is failing: https://kojipkgs.fedoraproject.org//work/tasks/5618/37405618/build.log As a workaround for now, I have disabled the python 3 extension and am shipping only the python 2 extension for F32. Any hints would be appreciated. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS-UP] gradle will go away
On Fri, 9 Aug 2019 at 14:24, Fabio Valentini wrote: > > Hi everybody! > > After some discussions, we (the Stewardship SIG) have decided that we > cannot continue to maintain gradle in fedora. > > - the current version packaged in fedora is outdated (4.4.1, from Dec. > 2017, vs. 5.5.1 from July 2019) > - it currently doesn't build itself (not even in bootstrap mode), and > needs an older version tagged into rawhide as a buildroot override to > even build (this doesn't work anymore, due to rawhide gating) Is that really true? You can't create buildroot overrides for it? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Over 500 orphaned packages seeking new maintainers
On Tue, 30 Jul 2019 at 18:28, Christopher wrote: > > On Tue, Jul 30, 2019 at 1:10 PM Alexander Scheel wrote: > [snip] > > The Java SIG is here: > > > > - https://fedoraproject.org/wiki/SIGs/Java > > Is there anything special one must do to "Join" the Java SIG? I would > like to join. No, it was just a loose association of packagers who wanted to coordinate work on the Java stack. It's kinda moribund these days, but one or two of us still hang out in #fedora-java on Freenode. Please also join the (low-traffic) java-devel mailing list. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Possibly Unresponsive Maintainer: gil
On Thu, 20 Jun 2019 at 11:25, Fabio Valentini wrote: > > Hi, > > When working on the Java Stack for the Stewardship SIG, I've come > across multiple packages that are officially maintained by gil, but it > looks like he stopped contributing to fedora more than two years ago > (I checked mailing lists, bugzilla, bodhi, koji, and his src.fp.org > dist-git repos). > > There are multiple pages [0] of open bugzilla bugs assigned to him, > and none got any response from him for years, so I think I can safely > skip opening another bug for one of his packages ... > > He also should have received multiple emails from me during the last > two months, when I asked maintainers depending on some of the > Stewardship SIG's packages for help, and he didn't react to any of > these, either ([1] [2], among others). > > If nobody can provide me information to the contrary (i.e. that he's > still an active contributor somehow), I will file a FESCo issue to > initiate the unresponsive maintainer process in a week (June 27). > > Thanks, > Fabio (decathorpe) > > > [0]: https://bugzilla.redhat.com/buglist.cgi?bug_status=__open___status=__closed__=Fedora=puntogil%40libero.it_to1=1=substring=Fedora_format=advanced > > [1]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5UMM5NHS2SR3PCUFLIJGHVZTJQAL722W/ > > [2]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EJMYWJ7VILI4RSOUG2R74WJUUT2PTSVD/ Please proceed with the unresponsive maintainer process. By my own reckoning, he's been AWOL since at least 2017 -- Since then I've been using my provenpackager powers to keep the packages of his that I need updated. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers
p: jboss-jstl-1.2-api, jboss-jsp-2.3-api, mojarra > > ptoscano: mtools > > pwouters: bc > > qa-tools-sig: mtools > > quintela: bc > > qulogic: gsl > > radekmanak: jboss-modules > > rakesh: gsl > > ralph: python-fmn-lib > > rathann: gsl, bc > > rdieter: compat-openssl10-pkcs11-helper, gsl, bc > > rebus: libemu > > rfenkhuber: jboss-websocket-1.0-api, jboss-jms-1.1-api, weld-core, > weld-api > > rgrunber: jboss-websocket-1.1-api, undertow, hibernate-validator, > weld-api, > > weld-core, jboss-classfilewriter, jboss-vfs > > rhughes: gsl > > ricardo: jboss-jacc-1.5-api, xnio, protostream, jboss-parent, checkstyle, > > weld-parent, cookcc, log4j-jboss-logmanager, jboss-servlet-3.1-api, > jboss-dmr, > > jboss-logmanager, jboss-modules, hibernate-validator, > > hibernate-commons-annotations, jboss-logging-tools, aesh, jboss-stdio, > > jboss-threads, apiviz, cookxml, jboss-invocation, jboss-marshalling, > > bean-validation-api, jboss-interceptors-1.1-api, jboss-logging, > > jboss-remoting-jmx, jandex, jboss-sasl, jboss-vfs, staxmapper, jboss-msc, > > jboss-common-core, jboss-jms-1.1-api, h2, jboss-connector-1.7-api, > > jboss-remoting, jboss-websocket-1.1-api, jdeparser, jul-to-slf4j-stub, > jline1, > > undertow, jboss-transaction-1.2-api, jboss-classfilewriter, emma, > > jboss-transaction-1.1-api, jboss-servlet-3.0-api > > richardfearn: jboss-jms-1.1-api, jboss-websocket-1.1-api, undertow, > > hibernate-validator, weld-api, weld-core, jboss-classfilewriter, > jboss-vfs > > rjones: mtools, gsl > > rmattes: gsl > > rmyers: checkstyle > > rnorwood: gsl > > robert: bc > > robotics-sig: gsl > > rstrode: gsl > > runcom: bc > > sagitter: gsl > > sailer: gsl > > sandeen: bc > > sayanchowdhury: python-fmn-lib > > sbergmann: mojarra, bc > > scox: jboss-modules > > sdgathman: hibernate-commons-annotations, h2 > > sergiomb: bc > > sergiopr: gsl > > sharkcz: bc > > shenson: mtools > > skottler: jline1, jboss-specs-parent, checkstyle > > slowrie: bc > > smakarov: jboss-modules > > smani: gsl > > spike: checkstyle > > spot: gsl > > ssp: gsl > > steve: bc > > steved: bc > > stevetraylen: checkstyle > > stewardship-sig: jboss-websocket-1.0-api, weld-parent, jboss-jms-1.1-api, > > jboss-connector-1.7-api, jboss-marshalling, jboss-el-2.2-api, > jboss-jsp-2.3-api, > > felix-osgi-obr-resolver, jline1, jboss-jsf-2.1-api, emma, > jboss-jstl-1.2-api, > > jboss-servlet-3.0-api, hibernate-jpa-2.0-api > > tdawson: felix-osgi-obr-resolver, jboss-specs-parent, mtools, > rubygem-commander > > teuf: mtools > > tflink: mtools > > than: gsl > > thl: bc > > thozza: bc > > timn: gsl > > tnorth: gsl > > tomspur: bc > > trepik: jboss-jms-1.1-api, jboss-marshalling, jboss-jsp-2.3-api, > > felix-osgi-obr-resolver, jline1, jboss-modules, hibernate-validator, bc, > > mojarra, weld-api, emma, weld-core, jboss-jstl-1.2-api, jboss-vfs > > trhoden: ceph-deploy > > tsmetana: gsl > > tstclair: jboss-el-2.2-api, jboss-ejb-3.1-api, > jboss-interceptors-1.1-api, > > jline1, checkstyle > > ttorling: gsl > > twaugh: bc > > vakwetu: jboss-el-3.0-api, jboss-jsp-2.3-api, jboss-jacc-1.5-api, xnio, > > jboss-jstl-1.2-api, protostream, jboss-parent, weld-parent, > jboss-specs-parent, > > cookcc, jboss-annotations-1.2-api, log4j-jboss-logmanager, > > jboss-servlet-3.1-api, jboss-dmr, hibernate-validator, jboss-jsf-2.1-api, > > jboss-logging-tools, aesh, jboss-stdio, jboss-threads, cookxml, > > jboss-invocation, jboss-marshalling, bean-validation-api, > jboss-ejb-3.1-api, > > jboss-interceptors-1.1-api, jboss-jaxrpc-1.1-api, jboss-logging, > > jboss-remoting-jmx, jandex, weld-api, jboss-sasl, staxmapper, jboss-msc, > > hibernate-jpa-2.0-api, jboss-websocket-1.0-api, jboss-websocket-1.1-api, > > jboss-remoting, jboss-connector-1.7-api, jdeparser, jul-to-slf4j-stub, > undertow, > > jline1, jboss-classfilewriter, emma, jboss-transaction-1.1-api > > verdurin: gsl > > virtmaint-sig: mtools, bc > > volter: gsl > > vondruch: felix-osgi-obr-resolver > > walters: pywebkitgtk > > wcohen: jboss-modules > > willb: jboss-jms-1.1-api, emma > > wwoods: mtools > > yzhang: bc > > zbyszek: jboss-jms-1.1-api, gsl, checkstyle, bc > > zdohnal: bc > > zeenix: mtools > > > > -- > > The script creating this output is run and developed by Fedora > > Release Engineering. Please report issues at its pagure instance: > > https://pagure.io/releng/ > > The sources of this script can be found at: > > https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py > > > > -- > > Miro Hrončok > > -- > > Phone: +420777974800 > > IRC: mhroncok > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora modularity and cyclic dependencies
On Tue, 16 Apr 2019 at 14:14, Robert-André Mauchin wrote: > > On Tuesday, 16 April 2019 02:46:49 CEST Mat Booth wrote: > > > > Yes, there is a buildopts section in the yaml file where you can specify > > rpm macros. > > > > Here is the documentation: > > > > https://docs.fedoraproject.org/en-US/modularity/making-modules/defining-modu > > les/#_build_macros_optional > > > > Here is an example where I needed to set --with bootstrap in my module: > > > > https://src.fedoraproject.org/modules/tycho/blob/df837b8793fe460d2c7e72ab6d6 > > 38a0f6e9f47a7/f/tycho.yaml#_76 > > > > > Thanks for the tip but that wouldn't work for Golang. When we bootstrap we > disable certain codepath to workaround the cycle, but we still need to > reenable them later to build the final binary. So we need to do both a > bootstrap build, and then a non-bootstrap build to get all the functionality. > Why wouldn't this work for you? You would just rebuild the module a second time without the bootstrap flag set. This is fairly standard process for packages that buildrequire themselves and not unique to golang. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora modularity and cyclic dependencies
On Tue, 16 Apr 2019 at 00:29, Robert-André Mauchin wrote: > > Hi, > > In Golang, we have a lot of cyclic dependencies for which we have to bootstrap > many packages, and then later build them unbootstrapped when all the deps are > in place. > How are we supposed to handle this in Modularity? Since it rebuilds all > packages from the start, it will fail to build cyclic deps. Is there a way to > turn on the --with bootstrap switch in Modularity? Are we supposed to build > the package two times, one with bootstrap, and later without? > > Best regards, > > Robert-André Yes, there is a buildopts section in the yaml file where you can specify rpm macros. Here is the documentation: https://docs.fedoraproject.org/en-US/modularity/making-modules/defining-modules/#_build_macros_optional Here is an example where I needed to set --with bootstrap in my module: https://src.fedoraproject.org/modules/tycho/blob/df837b8793fe460d2c7e72ab6d638a0f6e9f47a7/f/tycho.yaml#_76 -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] Eclipse dropping 32-bit arches
On Wed, 5 Dec 2018 at 15:29, Mat Booth wrote: > The Eclipse Platform upstream is in the process of dropping all support > for 32bit arches. > > The current state is that upstream are no longer building for 32bit arches > upstream for 4.10 (release 2018-12) onwards. I expect them to start > actively removing 32bit specific code in future releases. > > You can read more about the decision on the upstream bug [2] > > In Fedora, Eclipse 4.10 which I am building for Rawhide and F29 right now, > still builds for 32bit arches, but this will not last long. I expect in a > future release (4.11 or later) Eclipse will no longer build on x86/arm and > at that time I will no longer be able to support these architectures in > Fedora -- I expect to exclude those arches from Fedora builds. > > If you depend on the ECJ batch compiler, this will continue to be > available on all arches as a noarch package. (It is packaged as a discrete > SRPM and has no build or runtime dependency on the Eclipse Platform itself. > ) > > Regards, > Mat > > > [1] > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/XCQIMO3W3D5XGHQHBVVIBUBPIXKJJJWL/ > [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=526620 > It's three months later and I wanted to follow up on this. Eclipse in Fedora has dropped support for 32 bit architectures. The newest builds of Eclipse 4.11 for F30 and newer reflect this and are built for 64 bit architectures only. By now I have touched most Eclipse plug-in packages to limit their availability to the same architectures as Eclipse itself. If you own a package that is not an Eclipse plug-in but it does have a build or runtime dependency on Eclipse, then you will need to follow suit and make your package also exclude 32 bit architecture. If your package simply depends on Eclipse/Equinox for OSGi APIs, then you might be better switching your package to build against the OSGi APIs provided by the osgi-core/osgi-compendium packages instead to stay available on all architecture. Feel free to ping if you are unsure how to proceed. Regards, Mat PS. My next job is modularising Eclipse in Fedora so that it remains available in the distro after the great package retiring happens. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Re: [HEADS UP] Eclipse dropping 32-bit arches
On Wed, 5 Dec 2018 at 15:29, Mat Booth wrote: > The Eclipse Platform upstream is in the process of dropping all support > for 32bit arches. > > The current state is that upstream are no longer building for 32bit arches > upstream for 4.10 (release 2018-12) onwards. I expect them to start > actively removing 32bit specific code in future releases. > > You can read more about the decision on the upstream bug [2] > > In Fedora, Eclipse 4.10 which I am building for Rawhide and F29 right now, > still builds for 32bit arches, but this will not last long. I expect in a > future release (4.11 or later) Eclipse will no longer build on x86/arm and > at that time I will no longer be able to support these architectures in > Fedora -- I expect to exclude those arches from Fedora builds. > > If you depend on the ECJ batch compiler, this will continue to be > available on all arches as a noarch package. (It is packaged as a discrete > SRPM and has no build or runtime dependency on the Eclipse Platform itself. > ) > > Regards, > Mat > > > [1] > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XCQIMO3W3D5XGHQHBVVIBUBPIXKJJJWL/ > [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=526620 > It's three months later and I wanted to follow up on this. Eclipse in Fedora has dropped support for 32 bit architectures. The newest builds of Eclipse 4.11 for F30 and newer reflect this and are built for 64 bit architectures only. By now I have touched most Eclipse plug-in packages to limit their availability to the same architectures as Eclipse itself. If you own a package that is not an Eclipse plug-in but it does have a build or runtime dependency on Eclipse, then you will need to follow suit and make your package also exclude 32 bit architecture. If your package simply depends on Eclipse/Equinox for OSGi APIs, then you might be better switching your package to build against the OSGi APIs provided by the osgi-core/osgi-compendium packages instead to stay available on all architecture. Feel free to ping if you are unsure how to proceed. Regards, Mat PS. My next job is modularising Eclipse in Fedora so that it remains available in the distro after the great package retiring happens. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[HEADS UP] Eclipse dropping 32-bit arches
The message about Ceph [1] reminded me that we should probably make the same notification for Eclipse Platform. The Eclipse Platform upstream is in the process of dropping all support for 32bit arches. The current state is that upstream are no longer building for 32bit arches upstream for 4.10 (release 2018-12) onwards. I expect them to start actively removing 32bit specific code in future releases. You can read more about the decision on the upstream bug [2] In Fedora, Eclipse 4.10 which I am building for Rawhide and F29 right now, still builds for 32bit arches, but this will not last long. I expect in a future release (4.11 or later) Eclipse will no longer build on x86/arm and at that time I will no longer be able to support these architectures in Fedora -- I expect to exclude those arches from Fedora builds. If you depend on the ECJ batch compiler, this will continue to be available on all arches as a noarch package. (It is packaged as a discrete SRPM and has no build or runtime dependency on the Eclipse Platform itself.) Regards, Mat [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XCQIMO3W3D5XGHQHBVVIBUBPIXKJJJWL/ [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=526620 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unretire recordmydesktop
On Sun, 4 Nov 2018 at 19:50, Michael Schwendt wrote: > On Sun, 4 Nov 2018 12:17:00 +, Richard W.M. Jones wrote: > > > recordmydesktop was retired in F27: > > > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/4RCB6MBC4JVGG4SYLIKUDOOT2REGA6N4/ > > > > It's claimed that it doesn't work and is full of crash bugs, but I was > > able to compile it on F29 and it works fine for me, and it's a very > > useful little tool. > > Quoting https://bugzilla.redhat.com/1538352#c1 > > | Yes, recordmydesktop was intentionally retired due to the project being > | abandoned (no new release in 10 years), it contained many crash bugs, > | and was not at all working on Wayland. > > There are various WONTFIX and EOL issues tracked in bugzilla. Bringing > back the package without going through those tickets first doesn't sound > like a good idea. > Agreed. Not only did I get quite regular abrt reports for both recordmydesktop and gtk-recordmydesktop, I also received a good deal of flak from people who had the (quite reasonable, IMO) expectation that it would work on our default windowing system... So I suppose you take ownership of it at your own peril. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Self Introduction: Nicolas De Amicis (deamn)
On Fri, 9 Nov 2018 at 08:28, Nicolas De Amicis wrote: > Hi, > I'm Nicolas De Amicis, I'm 37 years old and I live in Switzerland. My > native language is french. I'm married and I have 2 children. > > I'm software engineer in a metallurgical industry since 2006. > > I'm Fedora user since 2004 and I'm never contribute to a open source > project before now. I create a pull request for openjfx package (see > https://bugzilla.redhat.com/show_bug.cgi?id=1644712 and > https://src.fedoraproject.org/rpms/openjfx). > > My sponsor is Mat Booth, I hope :-) > > Have a nice day! > Nicolas De Amicis > Hi Nicolas, bienvenue à Fedora :-) I will take a look at your PR shortly. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ursa Major (modules in buildroot) enablement
On Thu, 8 Nov 2018 at 05:01, Kevin Kofler wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > This is not about forcing modules unto people. The drive comes from > > the other direction: packages want to be available only as modules, > > But that is exactly what I mean by "forcing modules onto people"! > > If you want to keep non-module version of packages around then you (or any interested party) needs to step up and help with the maintenance of them. Someone said further up that the it makes the Java SIG's life easier. These days the Java SIG is pretty much one guy maintaining hundreds of packages: https://lists.fedoraproject.org/archives/list/java-de...@lists.fedoraproject.org/message/MQMRQVENBLDRS67WLNQ7EOCMSDI5WIET/ So if we want a Java stack in the distro at all and you are not willing or able to lend a hand, then by all means let him maintain those packages in the most efficient way he can. It's not about forcing modules onto users, it's about not forcing more work than necessary onto already overstretched maintainers. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fwd: Orphaning some unused Eclipse packages
Hi all, I orphaned/retired the following low-level Eclipse packages, because they are no longer needed by the plug-ins I maintain: eclipse-emf-transaction eclipse-emf-query eclipse-emf-validation eclipse-mdt-ocl eclipse-mdt-uml2 -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning eclipse-xtext and dependencies
On 10 July 2018 at 12:30, Aleksandar Kurtakov wrote: > eclipse-xtext and its dependencies eclipse-xpand and eclipse-emf-mwe have > just been orphaned. Eclipse SIG has no use of these packages anymore > (despite them being really active upstream), the build system is quite > complicated and they haven't been properly kept upto date lately. > > -- > Alexander Kurtakov > Red Hat Eclipse Team > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@lists. > fedoraproject.org/message/53UPH4FPNNFZVXEUZFKOSQCSN5BM5OZG/ > > Same for eclipse-xtext-antlr-generator, which was a build dep of xtext/xpand mentioned above. I also orphaned eclipse-emf-transaction as it was not needed by any other Eclipse plugin. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OOXDTRQHOEPNVGNMZOPDIGFYVDACEYOU/
Re: Orphaning not-yet-commons-ssl
On 9 July 2018 at 13:36, Aleksandar Kurtakov wrote: > I've just orphaned not-yet-commons-ssl [1]. It is a dependency of > eclipse-fedorapackager but I'm not sure how useful this dependency still is > I haven't used it lately. The library has a dependency on > jakarta-commons-httpclient which has been EOLed in 2011 [2] . > > > I also just orphaned eclipse-fedorapackager since there was not enough time and energy to keep it up to date with changes in the Fedora infrastructure. Bringing it up to date would require some non-trivial effort I think, so if no-one picks it up this package should be retired. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MWY2Y6KLCHAPBF455SHHG5RD7OXMMQCD/
ICU4J License Change notification
ICU4J is now covered by the Unicode License (with MIT and BSD licensed contributed parts.) The Unicode license is very similar to the previous MIT-style ICU license. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/message/MITQQDMOAEO7SHSMPOGUSQ7QYLM3B5WK/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MITQQDMOAEO7SHSMPOGUSQ7QYLM3B5WK/
ICU4J License Change notification
ICU4J is now covered by the Unicode License (with MIT and BSD licensed contributed parts.) The Unicode license is very similar to the previous MIT-style ICU license. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/MITQQDMOAEO7SHSMPOGUSQ7QYLM3B5WK/
License change notification for Eclipse Plugins
Some Eclipse Foundation plug-ins have already made the switch from EPL to EPL-2.0 and I have updated the licence field in the corresponding Rawhide RPMs where I am aware of the change. I expect that most plug-ins from the Foundation and the Eclipse Platform itself will make the switch over the coming year. I don't plan to announce each change individually so if you are interested in Eclipse Platform or plug-in licensing, please pay special attention going forward. Thanks -- Mat Booth http://fedoraproject.org/get-fedora ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/message/7FMYHDQCRO6AGWVC6LIK6OV5E7QHMHCH/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7FMYHDQCRO6AGWVC6LIK6OV5E7QHMHCH/
Re: [RFC] Packages which are not installable (obsoleted by other pacakges)
On 1 March 2018 at 16:46, Igor Gnatenko <ignatenkobr...@fedoraproject.org>
wrote:
> can't install jackson-dataformat-cbor-javadoc-2.7.6-3.fc27.noarch:
> package is obsoleted by jackson-dataformats-binary-javadoc-2.9.4-
> 3.fc28.noarch
> can't install jackson-dataformat-smile-javadoc-2.7.6-3.fc27.noarch:
> package is obsoleted by jackson-dataformats-binary-javadoc-2.9.4-
> 3.fc28.noarch
> can't install jackson-dataformat-csv-javadoc-2.7.6-3.fc27.noarch:
> package is obsoleted by jackson-dataformats-text-javadoc-2.9.4-
> 3.fc28.noarch
> can't install jackson-dataformat-yaml-javadoc-2.7.6-3.fc27.noarch:
> package is obsoleted by jackson-dataformats-text-javadoc-2.9.4-
> 3.fc28.noarch
> can't install jackson-module-jaxb-annotations-javadoc-2.7.6-
> 3.fc27.noarch:
> package is obsoleted by jackson-modules-base-javadoc-2.9.4-
> 2.fc28.noarch
>
>
These individual jackson packages were merged upstream into fewer repos
(and correspondingly fewer source RPMs in Fedora)
jackson-dataformat-{cbor,smile,csv,yaml} and jackson-module-jaxb-annotations
should all be retired.
--
Mat Booth
http://fedoraproject.org/get-fedora
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Intent to retire recordmydesktop
On 4 October 2017 at 10:15, Petr Šabata <con...@redhat.com> wrote: > On Wed, Oct 04, 2017 at 10:04:16AM +0100, Mat Booth wrote: > > Hi all, > > > > The venerable "recordmydesktop" application does not work with Wayland > and > > stopped working out-of-the-box when Wayland was made default. > > > > Project is long since abandoned upstream, is riddled with crash bugs, and > > my own personal use of this project ceased when gnome-shell grew good > > built-in screencast recording functionality. > > > > I plan to retire this package from Fedora shortly. > > recordmydesktop worked fine for me when I needed it. Since I'm > one of those people who use just a simple (X11) WM, are there any > simple, non-Gnome-centric alternatives? > > Cheers, > P > > I have never tried it, but there is a package called "simplescreenrecorder" in the RPMFusion Free repo. There may be others that I am not aware of. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Intent to retire recordmydesktop
Hi all, The venerable "recordmydesktop" application does not work with Wayland and stopped working out-of-the-box when Wayland was made default. Project is long since abandoned upstream, is riddled with crash bugs, and my own personal use of this project ceased when gnome-shell grew good built-in screencast recording functionality. I plan to retire this package from Fedora shortly. -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Mass rebuilds update
On 7 August 2017 at 15:35, Dennis Gilmore <den...@ausil.us> wrote: > [3] https://kojipkgs.fedoraproject.org/mass-rebuild/f27-failures.html > This file seems suspiciously small... I somehow don't believe that there were "0 failed builds" :-) -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Schedule for Thursday's FPC Meeting (YYYY-MM-DD 16:00 UTC)
On 6 July 2017 at 02:40, James Antill <ja...@fedoraproject.org> wrote: > Following is the list of topics that will be discussed in the FPC > meeting Thursday at 2017-07-06 16:00 UTC in #fedora-meeting-1 on > irc.freenode.net. > > Local time information (via. uitime): > > = Day: Thursday == > 2017-07-06 09:00 PDT US/Pacific > 2017-07-06 12:00 EDT --> US/Eastern <-- > 2017-07-06 16:00 UTC UTC > 2017-07-06 17:00 BST Europe/London > 2017-07-06 18:00 CEST Europe/Berlin > 2017-07-06 18:00 CEST Europe/Paris > 2017-07-06 21:30 IST Asia/Calcutta > New Day: Friday - > 2017-07-07 00:00 HKT Asia/Hong_Kong > 2017-07-07 00:00 +08 Asia/Singapore > 2017-07-07 01:00 JST Asia/Tokyo > 2017-07-07 02:00 AEST Australia/Brisbane > > Links to all tickets below can be found at: > > https://pagure.io/packaging-committee/issues?status=Open=meeting > > = Followups = > > #topic #691 noarch *sub*packages with arch-specific dependencies > .fpc 691 > https://pagure.io/packaging-committee/issue/691 > > #topic #693 Wiki:Packaging:RPMMacros > .fpc 693 > https://pagure.io/packaging-committee/issue/693 > > = Open Floor = > > For more complete details, please visit each individual ticket. The > report of the agenda items can be found at: > > https://pagure.io/packaging-committee/issues?status=Open=meeting > > If you would like to add something to this agenda, you can reply to > this e-mail, file a new ticket at https://fedorahosted.org/fpc, > e-mail me directly, or bring it up at the end of the meeting, during > the open floor topic. Note that added topics may be deferred until > the following meeting. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > I will not be at today's meeting -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Spec files maintained in external source control: *please* mention this in the spec file
On 14 February 2017 at 02:58, Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl > wrote: > On Mon, Feb 13, 2017 at 09:44:50AM -0800, Adam Williamson wrote: > > Hi folks! So I got bitten again today by the situation where the > > primary contact for a given package considers the 'canonical' source > > for the spec file to be some external SCM, and finds it a problem when > > someone (e.g. a provenpackager like me...) changes the package directly > > in dist-git. > > https://fedorahosted.org/fpc/ticket/613 > It's seems to be going nowhere. > > > This is at least 50% my fault for not trying to check in before > > changing the package > It'd help if there was a standard way to mark such things. > > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Ticket is still has "need info" status -- if the info is provided, the status should be set to "discuss at next meeting" -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Orphaning packages
On 15 October 2016 at 13:21, Gerard Ryan <gali...@fedoraproject.org> wrote: > > I adopted these guys: - eclipse-webtools - uddi4j - wsil4j -- Mat Booth http://fedoraproject.org/get-fedora ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Orphaned Packages in branched (2016-05-18)
On 18 May 2016 at 22:01, <opensou...@till.name> wrote: > The following packages have broken dependencies and will be retired > on 2016-05-31 (Final Freeze for Fedora 24) unless someone fixes them. If > you > know for sure that the package should be retired, please do so now with a > proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the > affected > packages or a package that depends on one. Please fix the affected package > or > retire your depending package to avoid broken dependencies, otherwise your > package will be retired when the affected package gets retired. > > Package(co)maintainers Status Change > === > eclipse-jbosstools marcusk, galileo, goldmann,12 weeks ago >group::eclipse-sig > eclipse-mylyn akurtakov, arobinso, group 12 weeks ago >::eclipse-sig, jjohnstn, >kdaniel, rgrunber > eclipse-mylyn will be fixed once the right updates land in stable, but I have no intention to fix eclipse-jbosstools. -- Mat Booth http://fedoraproject.org/get-fedora -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Fedora rawhide compose report: 20160312.n.0 changes
On 14 March 2016 at 16:09, Dennis Gilmore <den...@ausil.us> wrote: > On Saturday, March 12, 2016 2:32:38 PM CDT Fedora Rawhide Report wrote: > > Package: eclipse-launchbar-1.0.1-1.gitedd5f69.fc25 > > Old package: eclipse-launchbar-1.0.2-0.1.git93cdb07.fc25 > > Summary: Eclipse Launchbar plug-in > > RPMs: eclipse-launchbar > > Size: 181382 bytes > > Size change: -57708 bytes > > Changelog: > > * Thu Mar 10 2016 Mat Booth <mat.bo...@redhat.com> - > 1:1.0.1-1.gitedd5f69 > > - Take a post-release snapshot of 1.0.1 due to API breakage in newer > > versions > > When doing this you need to add an epoch in order to make sure people get > the > update > > Dennis > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > > Sopot: Please ignore this -- the report is buggy. -- Mat Booth http://fedoraproject.org/get-fedora -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [Guidelines change] Changes to the packaging guidelines
On 22 February 2016 at 17:38, Corey Sheldon <sheldon.co...@gmail.com> wrote: > > Kevin, et al. > > I am willing to help with the re-write but admittedly some of it will require a crash course for me. > > > On 02/22/2016 11:31 AM, Kevin Fenzi wrote: > > On Mon, 22 Feb 2016 15:02:45 + > Mat Booth <fed...@matbooth.co.uk> wrote: > > Wow, that "HOWTO" is a really old page -- not changed since being > imported from the old moin moin wiki. My feeling is that page should > be deleted and the "How to create an RPM package" page should be > updated. > > Here is the official guideline: > https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2 -- > basically, we just got out of the business of keeping track of what > the minimum buildroot contains. > > Should we just delete that HOWTO page? > > Really you should be using mock these days and it should tell you when > you don't have the right buildrequires present by failing until you add > them. > > kevin > > Actually, I just went ahead and made the change: https://fedoraproject.org/w/index.php?title=How_to_create_an_RPM_package=435832=432092 Now it links to a document that tells you how test package builds using mock. -- Mat Booth http://fedoraproject.org/get-fedora -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [Guidelines change] Changes to the packaging guidelines
On 22 February 2016 at 16:31, Kevin Fenzi <ke...@scrye.com> wrote: > On Mon, 22 Feb 2016 15:02:45 +0000 > Mat Booth <fed...@matbooth.co.uk> wrote: > > > Wow, that "HOWTO" is a really old page -- not changed since being > > imported from the old moin moin wiki. My feeling is that page should > > be deleted and the "How to create an RPM package" page should be > > updated. > > > > Here is the official guideline: > > https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2 -- > > basically, we just got out of the business of keeping track of what > > the minimum buildroot contains. > > Should we just delete that HOWTO page? > > Really you should be using mock these days and it should tell you when > you don't have the right buildrequires present by failing until you add > them. > > kevin Yeah, this is what I was suggesting. And the "How to create an RPM package" page should be updated to tell users to use mock. I think anyone can edit these pages (I don't believe they belong to the FPC.) -- Mat Booth http://fedoraproject.org/get-fedora -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [Guidelines change] Changes to the packaging guidelines
On 22 February 2016 at 10:54, Kamil Paral <kpa...@redhat.com> wrote: > > RWMJ> Is that new? > > > > Not really. The change relating to what's in the buildroot was made > > about nine months ago: https://fedorahosted.org/fpc/ticket/497 > > I created my first COPR over this weekend. I worked according to: > https://fedoraproject.org/wiki/How_to_create_an_RPM_package > because that is linked heavily from other pages and also was the first > google result for fedora rpm packaging. > > However, under > https://fedoraproject.org/wiki/How_to_create_an_RPM_package#SPEC_file_overview > it says: > > BuildRequires: ... Some common packages can be omitted, such as gcc. > and links to here: > https://fedoraproject.org/wiki/HOWTOFindMissingBuildRequires#Exceptions > > If that's no longer true, somebody who knows what he's doing should adjust > that, because that wiki page is likely the most visible rpm tutorial for > Fedora. > Wow, that "HOWTO" is a really old page -- not changed since being imported from the old moin moin wiki. My feeling is that page should be deleted and the "How to create an RPM package" page should be updated. Here is the official guideline: https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2 -- basically, we just got out of the business of keeping track of what the minimum buildroot contains. -- Mat Booth http://fedoraproject.org/get-fedora -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Schedule for Thursday's FPC Meeting (2015-09-10 16:00 UTC)
On 9 September 2015 at 19:21, James Antill <ja...@fedoraproject.org> wrote: > Following is the list of topics that will be discussed in the FPC > meeting Thursday at 2015-09-10 16:00 UTC in #fedora-meeting-1 on > irc.freenode.net. > > Local time information (via. rktime): > > 2015-09-10 09:00 Thu US/Pacific PDT > 2015-09-10 12:00 Thu US/Eastern EDT > 2015-09-10 16:00 Thu UTC <- > 2015-09-10 17:00 Thu Europe/London BST > 2015-09-10 18:00 Thu Europe/Paris CEST > 2015-09-10 18:00 Thu Europe/Berlin CEST > 2015-09-10 21:30 Thu Asia/Calcutta IST > --new day-- > 2015-09-11 00:00 Fri Asia/Singapore SGT > 2015-09-11 00:00 Fri Asia/Hong_Kong HKT > 2015-09-11 01:00 Fri Asia/Tokyo JST > 2015-09-11 02:00 Fri Australia/Brisbane EST > > > Links to all tickets below can be found at: > > https://fedorahosted.org/fpc/report/13 > > = New business = > > #topic #566 RPM file triggers > .fpc 566 > https://fedorahosted.org/fpc/ticket/566 > > #topic #567 Packaging Python 3 applications and modules for EPEL 7+ > .fpc 567 > https://fedorahosted.org/fpc/ticket/567 > > = Open Floor = > > For more complete details, please visit each individual ticket. The > report of the agenda items can be found at: > > https://fedorahosted.org/fpc/report/13 > > If you would like to add something to this agenda, you can reply to > this e-mail, file a new ticket at https://fedorahosted.org/fpc, > e-mail me directly, or bring it up at the end of the meeting, during > the open floor topic. Note that added topics may be deferred until > the following meeting. > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Apologies, I am not able to make it to today's meeting. -- Mat Booth http://fedoraproject.org/get-fedora -- 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: Attempting to contact unresponsive maintainer - affix
On 4 September 2015 at 19:26, Scott Wilkerson <swilker...@nagios.com> wrote: > Hello! > > I've been trying to get some old CVE's fixed in the nagios package and it > appears to be falling on deaf ears > https://bugzilla.redhat.com/show_bug.cgi?id=958305 > https://bugzilla.redhat.com/show_bug.cgi?id=1046333 > https://bugzilla.redhat.com/show_bug.cgi?id=1066580 > > I was wondering if anyone knows how to reach Keiran Smith - Affix > https://fedoraproject.org/wiki/User:Affix > > I have tries emailing directly, and wanted to send a message here before > opening a Non-responsive Maintainer ticket with FESCo > > I am willing to take the package if Affix is too busy with other things. > > -- > > Scott Wilkerson > Chief Technology Officer (CTO) > ___ > Nagios Enterprises, LLC > Office: (651)204-9102 > Fax:(651)204-9103 > Email: swilker...@nagios.com > Web:www.nagios.com > > Did you try IRC? Keiran can usually be found on IRC in the #fedora-uk channel on Freenode, username "Affix" -- Mat Booth http://fedoraproject.org/get-fedora -- 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: [ACTION REQUIRED] FTBFS Packages in rawhide (2015-07-08)
On 8 July 2015 at 22:55, opensou...@till.name wrote: Depending on: mysql-connector-java (288), status change: 2014-05-14 (60 weeks ago)a This one is fixed. -- Mat Booth http://fedoraproject.org/get-fedora -- 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: Schedule for Thursday's FPC Meeting (2015-07-08 16:00 UTC)
On 8 July 2015 at 19:46, James Antill ja...@fedoraproject.org wrote: Following is the list of topics that will be discussed in the FPC meeting Thursday at 2015-07-08 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2015-07-08 10:00 Wed US/Pacific PDT 2015-07-08 13:00 Wed US/Eastern EDT 2015-07-08 17:00 Wed UTC - 2015-07-08 18:00 Wed Europe/London BST 2015-07-08 19:00 Wed Europe/Paris CEST 2015-07-08 19:00 Wed Europe/Berlin CEST 2015-07-08 22:30 Wed Asia/Calcutta IST --new day-- 2015-07-09 01:00 Thu Asia/Singapore SGT 2015-07-09 01:00 Thu Asia/Hong_Kong HKT 2015-07-09 02:00 Thu Asia/Tokyo JST 2015-07-09 03:00 Thu Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/13 = Followups = #topic #508 New GID for openstack-neutron .fpc 508 https://fedorahosted.org/fpc/ticket/508 = New business = #topic #550 Darktable and Rawspeed internal library .fpc 550 https://fedorahosted.org/fpc/ticket/550 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/13 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Apologies in advance, in all likelihood I will not be able to make the meeting this week. -- Mat Booth http://fedoraproject.org/get-fedora -- 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 in rawhide (2015-06-30)
On 30 June 2015 at 09:17, Mikolaj Izdebski mizde...@redhat.com wrote: On 06/30/2015 09:12 AM, opensou...@till.name wrote: netty31 orphan 2 weeks ago As far as I can tell only one package directly depended on netty31: gradle. That dependency was actually a bug (gradle should build-require netty3 instead of netty31) and it is fixed [1] in rawhide. [1] http://pkgs.fedoraproject.org/cgit/gradle.git/commit/?id=6102b02 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct I took ownership of netty31 so that I can retire it. I will do so in the next couple of days unless there is severe objection. -- Mat Booth http://fedoraproject.org/get-fedora -- 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: F23 Self Contained Change: npm 2
On 24 June 2015 at 00:48, Jan Kurik jku...@redhat.com wrote: While npm 2 is a major version number update, it contains little in the way of major changes. Why is this worth more than a sentence or two in the release note beats? You must enjoy the extra bureaucracy :-) -- Mat Booth http://fedoraproject.org/get-fedora -- 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: Schedule for Thursday's FPC Meeting (2015-06-25 16:00 UTC)
On 24 June 2015 at 18:26, James Antill ja...@fedoraproject.org wrote: Following is the list of topics that will be discussed in the FPC meeting Thursday at 2015-06-25 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2015-06-25 09:00 Thu US/Pacific PDT 2015-06-25 12:00 Thu US/Eastern EDT 2015-06-25 16:00 Thu UTC - 2015-06-25 17:00 Thu Europe/London BST 2015-06-25 18:00 Thu Europe/Paris CEST 2015-06-25 18:00 Thu Europe/Berlin CEST 2015-06-25 21:30 Thu Asia/Calcutta IST --new day-- 2015-06-26 00:00 Fri Asia/Singapore SGT 2015-06-26 00:00 Fri Asia/Hong_Kong HKT 2015-06-26 01:00 Fri Asia/Tokyo JST 2015-06-26 02:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/13 = Followups = #topic #508 New GID for openstack-neutron .fpc 508 https://fedorahosted.org/fpc/ticket/508 #topic #538 Bundling exception for htmlunit-core-js .fpc 538 https://fedorahosted.org/fpc/ticket/538 = Followup/Votes needed = #topic #281 New Python Macros for Easier Packaging .fpc 281 https://fedorahosted.org/fpc/ticket/281 #topic #541 Package Naming Guidelines - Clarification Required .fpc 541 https://fedorahosted.org/fpc/ticket/541 #topic #542 Forbid python -OO for Python 3.5 .fpc 542 https://fedorahosted.org/fpc/ticket/542 = New business = #topic #543 secure config and log permissions .fpc 543 https://fedorahosted.org/fpc/ticket/543 #topic #544 Case of package names .fpc 544 https://fedorahosted.org/fpc/ticket/544 #topic #545 Python guidelines cleanup .fpc 545 https://fedorahosted.org/fpc/ticket/545 #topic #546 Review/clarity on minor fork of nghttp2; b64.c .fpc 546 https://fedorahosted.org/fpc/ticket/546 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/13 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Apologies, I will not be able to make it to this week's meeting. -- Mat Booth http://fedoraproject.org/get-fedora -- 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: Build-essential packages
On 12 June 2015 at 21:32, Dennis Gilmore den...@ausil.us wrote: On Friday, June 12, 2015 02:21:14 PM Carlos O'Donell wrote: On 06/12/2015 12:11 PM, Dennis Gilmore wrote: On Thursday, June 11, 2015 08:36:38 AM Florian Weimer wrote: On 05/21/2015 10:11 PM, Jason L Tibbitts III wrote: The BuildRequires section of the guidelines has been revised; the exceptions list is gone. The release engineering folks are free to define the buildroot and rpm is free to change its dependency list. * https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2 * https://fedoraproject.org/w/index.php?title=Packaging%3AGuidelinesdiff = 413629oldid=409506 * https://fedorahosted.org/fpc/ticket/497 Can we get a build-essential package instead that requires everything that is needed to get a working C and C++ compiler, and run most autoconf/automake/libtool-generated scripts (but not the autotools themselves)? Can you please help me to understand the problem you are trying to solve? what is different to dnf install @buildsys-build other than a package vs a comps group The recent policy changes mean that developers have to take action to fix broken spec files. Comments like those above are essentially a request, and the request from our developers is going to be: Now that the buildroot can contain almost nothing, what do I need to require in order to build C or C++ applications? Do I have to figure out every possible command that autoconf might call and include it in my BuildRequires or is there some magic meta prodives I can use? To answer this question for C and C++ development I have filed this FPC: https://fedorahosted.org/fpc/ticket/540 And while the pedantic answer is BuildRequire and Require on whatever you need, that is in my opinion insufficient guidance for Fedora packagers. Okay thanks, with my releng hat on I had no idea this was coming and would have suggested to the FPC to not change anything, at the least giving releng a heads up saying that they were going to make us the gatekeepers would have been appreciated. There is certainly no immediate plan to change anything from status quo. Woah, nothing has changed. We just got out of the business of unnecessarily storing this list of packages twice. The build package group is always going to be the canonical reference because no-one was maintaining the list the wiki. -- Mat Booth http://fedoraproject.org/get-fedora -- 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 in rawhide (2015-04-20)
many java packages. -- Mat Booth http://fedoraproject.org/get-fedora -- 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: FAILED: BuildError: package netbeans is blocked for tag f23
On 15 April 2015 at 16:29, مصعب الزعبي moc...@hotmail.com wrote: What's problem ? what's solve ? Mosaab -- 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 was retired due to lack of maintainership. No one from Java SIG was interested in keeping it alive any longer -- it was only here to support VisualVM, IIRC, but that is also now retired. -- Mat Booth http://fedoraproject.org/get-fedora -- 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: Schedule for Thursday's FPC Meeting (2015-04-17 16:00 UTC) Followups:6 New:2
On 16 April 2015 at 02:07, James Antill ja...@fedoraproject.org wrote:
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2015-04-17 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. rktime):
2015-04-17 09:00 Fri US/Pacific PDT
2015-04-17 12:00 Fri US/Eastern EDT
2015-04-17 16:00 Fri UTC -
2015-04-17 17:00 Fri Europe/London BST
2015-04-17 18:00 Fri Europe/Paris CEST
2015-04-17 18:00 Fri Europe/Berlin CEST
2015-04-17 21:30 Fri Asia/Calcutta IST
--new day--
2015-04-18 00:00 Sat Asia/Singapore SGT
2015-04-18 00:00 Sat Asia/Hong_Kong HKT
2015-04-18 01:00 Sat Asia/Tokyo JST
2015-04-18 02:00 Sat Australia/Brisbane EST
Links to all tickets below can be found at:
https://fedorahosted.org/fpc/report/13
= Followups =
#topic #281 New Python Macros for Easier Packaging
.fpc 281
https://fedorahosted.org/fpc/ticket/281
#topic #303 Consider reverting decision to ban %{?_isa} in
BuildRequires
.fpc 303
https://fedorahosted.org/fpc/ticket/303
#topic #508 New GID for openstack-neutron
.fpc 508
https://fedorahosted.org/fpc/ticket/508
#topic #513 Use python -Es in shbang
.fpc 513
https://fedorahosted.org/fpc/ticket/513
#topic #515 Bundling determination and exception request
.fpc 515
https://fedorahosted.org/fpc/ticket/515
#topic #520 [Guidelines Draft] Per-Product Configuration Defaults v2
.fpc 520
https://fedorahosted.org/fpc/ticket/520
= New business =
#topic #522 Should -static packages require -devel
.fpc 522
https://fedorahosted.org/fpc/ticket/522
#topic #524 static UID for ceph
.fpc 524
https://fedorahosted.org/fpc/ticket/524
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
https://fedorahosted.org/fpc/report/13
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Unfortunately due to a prior commitment I will not be able to attend the
meeting this week.
--
Mat Booth
http://fedoraproject.org/get-fedora
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] Schedule for Thursday's FPC Meeting (2015-03-05 17:00 UTC) Followup:4 New:5
On 4 March 2015 at 18:02, James Antill ja...@fedoraproject.org wrote:
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2015-03-05 17:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. rktime):
2015-03-05 09:00 Thu US/Pacific PST
2015-03-05 12:00 Thu US/Eastern EST
2015-03-05 17:00 Thu UTC -
2015-03-05 17:00 Thu Europe/London -
2015-03-05 18:00 Thu Europe/Paris CET
2015-03-05 18:00 Thu Europe/Berlin CET
2015-03-05 22:30 Thu Asia/Calcutta IST
--new day--
2015-03-06 01:00 Fri Asia/Singapore SGT
2015-03-06 01:00 Fri Asia/Hong_Kong HKT
2015-03-06 02:00 Fri Asia/Tokyo JST
2015-03-06 03:00 Fri Australia/Brisbane EST
Links to all tickets below can be found at:
https://fedorahosted.org/fpc/report/13
= Followups =
#topic #126 bundling exception for scintilla
.fpc 126
https://fedorahosted.org/fpc/ticket/126
#topic #248 python-feedgenerator - a standalone version of a bundled
library
.fpc 248
https://fedorahosted.org/fpc/ticket/248
#topic #303 Consider reverting decision to ban %{?_isa} in
BuildRequires
.fpc 303
https://fedorahosted.org/fpc/ticket/303
#topic #497 Clean up BuildRequires section; don't try to define the
minimal build env
.fpc 497
https://fedorahosted.org/fpc/ticket/497
= New business =
#topic #500 Request for bundling exception: numptyphysics bundles
Box2D = 2.0.1
.fpc 500
https://fedorahosted.org/fpc/ticket/500
#topic #502 Temporary exception for DHCP being built using bundled BIND
libraries in Fedora 22+
.fpc 502
https://fedorahosted.org/fpc/ticket/502
#topic #503 Changes/LegacyJDKsInFedora
.fpc 503
https://fedorahosted.org/fpc/ticket/503
#topic #506 Guideline Draft: Service First-Time Setup
.fpc 506
https://fedorahosted.org/fpc/ticket/506
#topic #507 Bundled library exception request: acme files in tonto
.fpc 507
https://fedorahosted.org/fpc/ticket/507
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
https://fedorahosted.org/fpc/report/13
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
--
packaging mailing list
packag...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
--
https://admin.fedoraproject.org/mailman/listinfo/packaging
Mat Booth
https://admin.fedoraproject.org/mailman/listinfo/packaging
http://fedoraproject.org/get-fedora
Apologies, I will be unable to attend today's FPC meeting.
--
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: [Guielines Change] Changes to the packaging guidelines
On 29 January 2015 at 09:50, Richard W.M. Jones rjo...@redhat.com wrote: On Tue, Jan 27, 2015 at 09:03:05PM -0600, Jason L Tibbitts III wrote: Clarified the naming guidelines to indicate how language bindings are named: lua-randomdb instead of randomdb-lua: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28General.29 Good to have this clarified. However java packages don't appear to follow this convention. eg: antlr3-java-1:3.5.2-2.fc21.noarch plplot-java-0:5.10.0-11.fc21.i686 R-java-0:3.1.2-1.fc21.x86_64 tzdata-java-2014j-1.fc21.noarch Does this mean we need to rename all Java subpackages? All language binding sub-packages are named this way, no? (subversion-perl, plplot-ada, xen-ocaml, etc) But doesn't this guideline refer to naming the base package, not sub-packages? Does it need clarifying further? -- Mat Booth http://fedoraproject.org/get-fedora -- 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: Introduction
On 6 October 2014 20:13, James Smith smit...@fedoraproject.org wrote: Hi All Just wanted to introduce myself. I'm James smith aka Smittix I am a UK ambassador and thought I would try my hand at packaging. For my first package I have packaged up an icon theme so I could get used to the guidelines and best practices. I enjoyed this for my first venture and hope to do more soon. I am also in need of a sponsor :) Good to meet you all. Regards James 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 Hi James! Do you have a link to your package review request? -- Mat Booth http://fedoraproject.org/get-fedora -- 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: Is there another Java Mass Rebuild scheduled for Fedora 21?
On 23 September 2014 15:41, Robert Rati rr...@redhat.com wrote: I noticed that some updates to java packages have moved the jar file locations or changed the jar name, which has broken symlinks in dependent packages. I know log4j12 changed the location of the jar and org.eclipse.osgi_3.10.0.v20140731-1655.jar changed versions to org.eclipse.osgi_3.10.0.v20140918-0803.jar. Is there a plan to do another mass rebuild of the java bits? If not, can we schedule one? Packages that depend on eclipse-equinox-osgi (home of org.eclipse.osgi_3.10.0.v*.jar): akka-0:2.3.0-1.fc21.noarch datanucleus-core-0:3.2.15-1.fc21.noarch eclipse-dtp-0:1.12.0-1.fc21.noarch eclipse-jbosstools-common-0:4.2.0-0.1.Beta2.fc21.noarch eclipse-jbosstools-usage-0:4.2.0-0.1.Beta2.fc21.noarch eclipse-jbosstools-ws-0:4.2.0-0.1.Beta2.fc21.noarch eclipse-jdt-1:4.4.0-14.fc21.x86_64 eclipse-jdt-1:4.4.0-15.fc21.x86_64 eclipse-m2e-core-0:1.5.0-13.fc21.noarch eclipse-mpc-0:1.2.1-0.2.git519e70b.fc21.noarch eclipse-mpc-0:1.3.0-1.fc21.noarch eclipse-mylyn-0:3.12.0-3.fc21.noarch eclipse-mylyn-tests-0:3.12.0-3.fc21.noarch eclipse-pde-1:4.4.0-14.fc21.x86_64 eclipse-pde-1:4.4.0-15.fc21.x86_64 eclipse-platform-1:4.4.0-14.fc21.x86_64 eclipse-platform-1:4.4.0-15.fc21.x86_64 eclipse-subclipse-0:1.10.5-1.fc21.noarch eclipse-tests-1:4.4.0-14.fc21.x86_64 eclipse-tests-1:4.4.0-15.fc21.x86_64 eclipse-webtools-common-core-0:3.6.0-7.fc21.noarch eclipse-webtools-javaee-0:3.6.0-7.fc21.noarch eclipse-webtools-jsf-0:3.6.0-7.fc21.noarch eclipse-webtools-sourceediting-0:3.6.0-7.fc21.noarch eclipse-wtp-sourceediting-0:3.5.1-3.fc21.noarch eclipselink-persistence-api-0:2.0.5-3.fc21.noarch hibernate-osgi-0:4.3.5-2.fc21.noarch jetty-osgi-boot-0:9.2.1-1.fc21.noarch jetty-osgi-boot-jsp-0:9.2.1-1.fc21.noarch jetty-osgi-boot-warurl-0:9.2.1-1.fc21.noarch xbean-0:3.17-2.fc21.noarch Maybe I'm misunderstanding the problem, but AFAICT none of these packages contain any symlinks to jars provided by eclipse-equinox-osgi. -- Mat Booth http://fedoraproject.org/get-fedora -- 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: DNF: why does it refresh metadata all the time
On 20 June 2014 10:19, Reindl Harald h.rei...@thelounge.net wrote: Am 20.06.2014 08:55, schrieb drago01: On Thu, Jun 19, 2014 at 8:59 PM, Jared K. Smith jsm...@fedoraproject.org wrote: On Thu, Jun 19, 2014 at 2:01 PM, Reindl Harald h.rei...@thelounge.net wrote: Whether you like it or not, one of the most common complaints about yum (especially from people coming from another package management system) is that it seems slow because of the necessity to download the metadata. The DNF developers -- in trying to address this common complaint -- had solved it by handling metadata in a different way. They've also added settings so that power users like you and I can tune it to better fit our particular needs. and *no* traffic is not cheap everywhere, by far not I probably understand this better than a lot of people on this list, as I've been on a bandwidth-limited connection for the past nine years. Only in the past month have I been able to get high speed internet in my home that wasn't limited to a few gigabytes per month. So yes, I completely understand that traffic isn't cheap (or fast) everywhere. It should be at least smart enough to not do it on mobile broadband (like packagekit does) how should it do that? it's imagination that any software knows anything about the internet connection even 11 years ago with a 56k modem that access was shared for my LAN and so the only thing the notebook knew about the inernet was appears to be slow IIRC, NetworkManager's DBus API should be able to give you that information. -- Mat Booth http://fedoraproject.org/get-fedora -- 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: DNF: why does it refresh metadata all the time
On 20 June 2014 11:50, Reindl Harald h.rei...@thelounge.net wrote: Am 20.06.2014 12:36, schrieb Mat Booth: On 20 June 2014 11:19, Reindl Harald h.rei...@thelounge.net mailto: h.rei...@thelounge.net wrote: Am 20.06.2014 11:57, schrieb Mat Booth: On 20 June 2014 10:19, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net mailto:h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: Am 20.06.2014 08:55, schrieb drago01: On Thu, Jun 19, 2014 at 8:59 PM, Jared K. Smith jsm...@fedoraproject.org mailto:jsm...@fedoraproject.org mailto:jsm...@fedoraproject.org mailto:jsm...@fedoraproject.org wrote: On Thu, Jun 19, 2014 at 2:01 PM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net mailto:h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: Whether you like it or not, one of the most common complaints about yum (especially from people coming from another package management system) is that it seems slow because of the necessity to download the metadata. The DNF developers -- in trying to address this common complaint -- had solved it by handling metadata in a different way. They've also added settings so that power users like you and I can tune it to better fit our particular needs. and *no* traffic is not cheap everywhere, by far not I probably understand this better than a lot of people on this list, as I've been on a bandwidth-limited connection for the past nine years. Only in the past month have I been able to get high speed internet in my home that wasn't limited to a few gigabytes per month. So yes, I completely understand that traffic isn't cheap (or fast) everywhere. It should be at least smart enough to not do it on mobile broadband (like packagekit does) how should it do that? it's imagination that any software knows anything about the internet connection even 11 years ago with a 56k modem that access was shared for my LAN and so the only thing the notebook knew about the inernet was appears to be slow IIRC, NetworkManager's DBus API should be able to give you that information from where should it get that information if your network connection is a Gigabit-Ethernet LAN to the router with a slow DSL upstream? your whole machine has no idea about your WAN connection Woah there... The suggestion was to simply let it be smart enough to not do it on mobile broadband to which you asked how? I answered only that question again: * 3G stick aka mobile broadband as WAN connection * that WAN connection is shared in the LAN * the single machines don't know anything about the WAN connection believe it or not, but here in austria it's not uncommon to get a box with 3G and on the other end a ethernet-port where you connect your devices and have some hundret MB per month in the meantime many of that packages are going in the direction ulimited traffic, but that's nothing you can be sure about as OS supplier Well sure, but there's no sense in throwing out all imperfect solutions because of a desire for perfection. Don't you agree that a good first step would be to teach DNF how to talk to NetworkManager? 3G internet is common in my locale too -- this would at least cover the use case of connecting with a 3G dongle or tethered mobile phone. -- Mat Booth http://fedoraproject.org/get-fedora -- 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: DNF: why does it refresh metadata all the time
On 20 June 2014 12:04, Mat Booth fed...@matbooth.co.uk wrote: On 20 June 2014 11:50, Reindl Harald h.rei...@thelounge.net wrote: Am 20.06.2014 12:36, schrieb Mat Booth: On 20 June 2014 11:19, Reindl Harald h.rei...@thelounge.net mailto: h.rei...@thelounge.net wrote: Am 20.06.2014 11:57, schrieb Mat Booth: On 20 June 2014 10:19, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net mailto:h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: Am 20.06.2014 08:55, schrieb drago01: On Thu, Jun 19, 2014 at 8:59 PM, Jared K. Smith jsm...@fedoraproject.org mailto:jsm...@fedoraproject.org mailto:jsm...@fedoraproject.org mailto:jsm...@fedoraproject.org wrote: On Thu, Jun 19, 2014 at 2:01 PM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net mailto:h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: Whether you like it or not, one of the most common complaints about yum (especially from people coming from another package management system) is that it seems slow because of the necessity to download the metadata. The DNF developers -- in trying to address this common complaint -- had solved it by handling metadata in a different way. They've also added settings so that power users like you and I can tune it to better fit our particular needs. and *no* traffic is not cheap everywhere, by far not I probably understand this better than a lot of people on this list, as I've been on a bandwidth-limited connection for the past nine years. Only in the past month have I been able to get high speed internet in my home that wasn't limited to a few gigabytes per month. So yes, I completely understand that traffic isn't cheap (or fast) everywhere. It should be at least smart enough to not do it on mobile broadband (like packagekit does) how should it do that? it's imagination that any software knows anything about the internet connection even 11 years ago with a 56k modem that access was shared for my LAN and so the only thing the notebook knew about the inernet was appears to be slow IIRC, NetworkManager's DBus API should be able to give you that information from where should it get that information if your network connection is a Gigabit-Ethernet LAN to the router with a slow DSL upstream? your whole machine has no idea about your WAN connection Woah there... The suggestion was to simply let it be smart enough to not do it on mobile broadband to which you asked how? I answered only that question again: * 3G stick aka mobile broadband as WAN connection * that WAN connection is shared in the LAN * the single machines don't know anything about the WAN connection believe it or not, but here in austria it's not uncommon to get a box with 3G and on the other end a ethernet-port where you connect your devices and have some hundret MB per month in the meantime many of that packages are going in the direction ulimited traffic, but that's nothing you can be sure about as OS supplier Well sure, but there's no sense in throwing out all imperfect solutions because of a desire for perfection. Don't you agree that a good first step would be to teach DNF how to talk to NetworkManager? 3G internet is common in my locale too -- this would at least cover the use case of connecting with a 3G dongle or tethered mobile phone. In fact this already seems to be listed in the Feature Backlog, so that's great! https://github.com/akozumpl/dnf/wiki/Features-backlog -- Mat Booth http://fedoraproject.org/get-fedora -- 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: [ACTION REQUIRED] Retiring packages for Fedora 21
On 29 May 2014 14:43, Till Maas opensou...@till.name wrote: eclipse-subclipse orphan, kdaniel, swagiaal This affects some of my packages, taking. -- Mat Booth http://fedoraproject.org/get-fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-java] Hadoop + log4j2 = fullstop
On 21 May 2014 17:03, Robert Rati rr...@redhat.com wrote: I've been working on updating the hadoop package to the latest 2.4.0 release and at this point I've resolved all the issues but I'm now blocked by the log4j2 update. log4j2 breaks the hadoop build pretty severely, and it doesn't seem the log4j2 team has spent much time thinking about how to provide backwards compatibility to existing log4j1.2 users. From my investigation of log4j2: log4j.properties file is no longer read at all configuration file is now in XML or JSON configuration file name is log4j2.[xml|json|jsn] V2 isn't backwards compatible with V1. There's a shim for v1 api but it will only work for a limited set of cases, and for some cases it does work for it turns some operations into noop calls. This is a pretty major change and even the compatibility layer, if it will work for a project, does not seem to guarantee like functionality and minimally will require a re-do of all log4j configuration files a project ships. I'm not sure many sizable upstream projects would undertake/accept such a drastic change very quickly. The list of projects currently blocked by this update are: hadoop hbase oozie hive apache-log4j-extras amplab-tachyon I would be surprised if there aren't a lot more. I understand Fedora is always pushing for the latest versions, but for some fundamental packages can there be compatibility packages introduced at the same time as an incompatible update? Package maintainers of dependent packages will still need to touch their packages and determine if the new version will work for them. Providing a compat package will also allow packages to update to their newer versions while not held up on trying to integrate changes from a compatibility breaking dependency update. Rob -- Yes, there are precedents for compat packages. For example there are both jdom and jdom2 packages in Fedora for this reason. There also used to be a xml-commons-apis12 compat package (not any more though, we were able to finally retire it in favour of xml-commons-apis.) -- Mat Booth http://fedoraproject.org/get-fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaning java-1.5.0-gcj
On 14 April 2014 08:44, Stanislav Ochotnicky sochotni...@redhat.com wrote: On Sun 13 Apr 2014 08:42:43 PM CEST Simo Sorce wrote: [snip] I know little to nothing about java bindings so if it is substantial work I will just remove the java binding and ask rel eng to pull the subpackage. You can't just pull packages. You'll have to properly Obsoletes: lasso-java it. I am attaching a patch which worked for me (including a scratchbuild with openjdk). I haven't actually tested the code, but I guess it should work (it's JNI though so...meh) Not Requires: java-headless ? -- Mat Booth http://fedoraproject.org/get-fedora -- 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: rawhide report: 20140404 changes
On 4 April 2014 17:59, Fedora Rawhide Report rawh...@fedoraproject.orgwrote: Broken deps for i386 -- [solr3] solr3-3.6.2-5.fc21.noarch requires mvn(org.apache.lucene:lucene-stempel) solr3-3.6.2-5.fc21.noarch requires mvn(org.apache.lucene:lucene-smartcn) solr3-3.6.2-5.fc21.noarch requires mvn(org.apache.lucene:lucene-phonetic) solr3-3.6.2-5.fc21.noarch requires mvn(org.apache.lucene:lucene-kuromoji) solr3-3.6.2-5.fc21.noarch requires mvn(org.apache.lucene:lucene-icu) solr3 should be retired and dependent packages should be ported to solr4. I think there is only one package that still requires solr3: $ repoquery --repoid=rawhide --whatrequires solr3 hibernate-search-0:4.5.0-1.fc21.noarch -- Mat Booth http://fedoraproject.org/get-fedora -- 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 with missing %check
On 5 March 2014 10:23, Alexander Todorov atodo...@redhat.com wrote: На 4.03.2014 20:36, Mat Booth написа: On 25 February 2014 11:19, Mikolaj Izdebski mizde...@redhat.com wrote: On 02/25/2014 11:45 AM, Alexander Todorov wrote: 3) Another proposal (sorry don't remember who proposed it) was to have %check with a comment why the test suite is not executed (e.g. requires network) or why it is executed in %build. Commenting why tests are skipped is a very good thing, but I don't like the idea of adding empty %check sections to my 250+ packages just for the sake of documenting that tests are ran in %build because that's what we do in Java world. Agreed, it seems like busy work to me that adds very little value to anyone familiar with Java packages. You are forgetting everyone that is not so familiar with Java. Also I didn't ask you (as a package owner) to do it explicitly, I've asked you to accept a patch which should be much more easier. Wouldn't it be easier to change the whatever tool is generating this report to accommodate for this? If package invokes %mvn_build then don't expect there to be a %check section seems like a reasonable heuristic to me. See https://bugzilla.redhat.com/show_bug.cgi?id=1072417#c4 to avoid repeating myself. Even if the tool uses heuristics to exclude some groups of packages it will not be obvious why there's no %check section. It could be because tests are executed in %build, because they need root or network access and are disabled, because the test framework used is not available (see DHCP) or anything else. If the tool excludes a package based on a heuristic, it can also tell you *why* it was excluded (the heuristic was added for a reason!) A comment in the SPEC is unnecessary duplication of information at that point. -- 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 with missing %check
On 25 February 2014 11:19, Mikolaj Izdebski mizde...@redhat.com wrote: On 02/25/2014 11:45 AM, Alexander Todorov wrote: 3) Another proposal (sorry don't remember who proposed it) was to have %check with a comment why the test suite is not executed (e.g. requires network) or why it is executed in %build. Commenting why tests are skipped is a very good thing, but I don't like the idea of adding empty %check sections to my 250+ packages just for the sake of documenting that tests are ran in %build because that's what we do in Java world. Agreed, it seems like busy work to me that adds very little value to anyone familiar with Java packages. Wouldn't it be easier to change the whatever tool is generating this report to accommodate for this? If package invokes %mvn_build then don't expect there to be a %check section seems like a reasonable heuristic to me. -- Mat Booth http://fedoraproject.org/get-fedora -- 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: Late introduction
On 2 September 2013 10:45, Dridi Boukelmoune dridi.boukelmo...@gmail.comwrote: Hi again, I would like to introduce myself again, now that I've joined the package maintainers. I would like to thank my sponsor (kevin), Chris Roberts for his warm welcome, Christopher Meng and the others who helped me so far. Starting today (at least in my timezone =) the makeself package is available for Fedora 19, and I'll focus on tools for developers. I for instance would like to package tools such as vagrant (that transitively depends on makeself). I have a special interest in Varnish and Java ecosystems, Java and C being my primary languages. I know Linux folks tend to hate Java, so in return I'll hate Ruby[1]. And if sometimes you don't understand my English, please remember : because is French. french Et pour les francophones (parce que je pense en avoir repérés), un petit bonjour. En espérant avoir l'occasion de croiser certains d'entre vous. /french Cheers, Dridi [1] just kidding, and vagrant is written in Ruby AFAIK ;) Good to see more Java folks! Please consider subscribing to the java-devel list too :-) https://admin.fedoraproject.org/mailman/listinfo/java-devel It is low volume, but it is where most Java-specific things are announced and discussed. Regards, Mat Booth (mbooth) -- Mat Booth http://fedoraproject.org/get-fedora -- 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: Overall rawhide package testing.
On 26 August 2013 13:19, Alec Leamas leamas.a...@gmail.com wrote: As agreed [1], we have run fedora-review on (almost) all packages in current rawhide. The results are now available at [2]. Here are reports on issues by package and packages by issue. We have discussed sending email about these results to the package owners. Is this a good idea? In any case, I think it might be good if you check your own packages, chances are that something otherwise unnoticed is discovered. Please don't forget the README. For those interested in the overall distribution, the package by issue reports perhaps also might add something as well as the 'stats' file in the top dir. --alec [1] https://lists.fedoraproject.**org/pipermail/devel/2013-** August/188133.htmlhttps://lists.fedoraproject.org/pipermail/devel/2013-August/188133.html [2] http://leamas.fedorapeople.**org/fedora-review/tree/http://leamas.fedorapeople.org/fedora-review/tree/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-**of-conducthttp://fedoraproject.org/code-of-conduct From the README: The package reports all fail on CheckBuildInMock and CheckBuildRequires. I'd rather you didn't send out a mass email until I can filter these out see just the genuine failures. -- Mat Booth http://fedoraproject.org/get-fedora -- 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: Blocking unblocked retired packages
On 24 August 2013 00:18, Till Maas opensou...@till.name wrote: Hi, On Fri, Aug 23, 2013 at 11:25:47PM +0200, Till Maas wrote: Depending on: maven2-common-poms antlr-maven-plugin (maintained by: spot, tradej) antlr-maven-plugin requires maven2-common-poms = 1.0-50.fc20 This is a BR, I reported it here: https://bugzilla.redhat.com/show_bug.cgi?id=887166 and blocked maven2-common-poms again. Deps on maven2-common-poms are redundant, I thought they had all been removed by now -- sorry about that, I will fix the remaining ones. -- Mat Booth http://fedoraproject.org/get-fedora -- 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: F21 schedule: what would you do with more time?
On 22 August 2013 16:03, Matthew Miller mat...@fedoraproject.org wrote: Based on discussion at Flock, on the devel mailing list, and in the FESCo meeting, we are looking for feedback on the idea of a longer release cycle for Fedora 21 -- not (right now at least) the bigger question of the 6-month cycle overall, but just, right now, slowing down for a release to get some things in order. Specifically, both Release Engineering and QA have clear needs (and even plans for) greater automatiion, but are also incredibly busy simply doing the things they need to do _now_ to get the release out the door. So, FESCo would like to see some specifics, like If we had one week with nothing else to worry about, we could have automated generation and upload of cloud images (to pick an example I personally care about). Or with six months of overall delay, we could have continuous integration testing of a key subset of rawhide. Or we could spend a couple of weeks and automate the new package and review workflow. What Infrastructure projects would be helped by this? Web and design team, would slowing down the release focus allow time to work on, oh, say, getting the Wiki beautiful (or does it not matter)? What else? As we look at Fedora.next ideas and possibly decide to start implementation in the F21 timeframe, we will likely find _new_ things that take specific work. Let's not worry about that right now. What things we do _now_ could be improved with the investment of some effort? Here's my favourite bugbear: https://fedorahosted.org/packagedb/ticket/243 I have no idea why the package retirement process needs intervention from rel-eng. -- Mat Booth http://fedoraproject.org/get-fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
