Self Introduction: Coty Sutherland
Hello everyone!! About me: I have been using Fedora since Fedora 14-ish and have really enjoyed using the OS thus far. I am a software developer with my primary language being Java, but I also enjoy python, javascript, and C (at times). I've gotten a good bit of experience with various RH products as well as been certified as an RHCE and Openstack admin. I've worked at Red Hat for almost 4 years now and my time in Global Support Services was spent supporting the JBoss EAP product, httpd, and Tomcat. I recently transitioned into an Engineering role to help with packaging Tomcat for RHEL and would love to give back to the community! This would be my first real (aside from random github commits) contribution to an OSS project, so I am very excited about it. I recently joined the Fedora project as a contributor and have been wading through the docs so that I can become a package maintainer. It looks like I need to request package ownership by way of emailing this list and taking a few other steps (which I'm working on) outlined in the doc here [0]. The package that I'm looking to maintain (Tomcat6) at this point was retired a few years ago due to lack of updates from the previous maintainer according to the last commit in the SCM dead.package branch. There is an updated version of Tomcat (current is Tomcat 8), but given that Tomcat 6 doesn't EOL until Dec of 2016 I'd like to provide updates to it via Fedora, if that is something that would be useful. I'd also love to assist with the Tomcat7 and/or Tomcat8 package, so I'll be reaching out to the maintainer there separately. If anyone has any feedback on this plan of action, additional steps that I've missed in documentation, or just thinks that I should just assist on the newer packages, let me know. Thanks!! [0] https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package -- Coty Sutherland, RHCSA, RHCE, JBCAA Senior Software Engineer @ Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Bugzilla issues
Hello all, I'm trying to get some help with a couple of BZs that look odd to me. It looks like these two bugs are somehow stuck in an ON_QA state by an obsolete bodhi update. There was an update which resolved them that was pushed to stable a while ago. The two bugs are: https://bugzilla.redhat.com/show_bug.cgi?id=1311102 https://bugzilla.redhat.com/show_bug.cgi?id=1267936 Should we go ahead and close those two as closed/currentrelease given that https://bodhi.fedoraproject.org/updates/FEDORA-2016-48ee453d15 has already been pushed to stable? Or is there something that I need to do so that bodhi does that automatically? Thanks, Coty -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Bugzilla issues
Done, thanks! On Thu, Aug 18, 2016 at 12:13 PM, Zbigniew Jędrzejewski-Szmek wrote: > On 08/18/2016 11:41 AM, Coty Sutherland wrote: >> Hello all, >> >> I'm trying to get some help with a couple of BZs that look odd to me. >> >> It looks like these two bugs are somehow stuck in an ON_QA state by an >> obsolete bodhi update. There was an update which resolved them that >> was pushed to stable a while ago. The two bugs are: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1311102 >> https://bugzilla.redhat.com/show_bug.cgi?id=1267936 >> >> Should we go ahead and close those two as closed/currentrelease given >> that https://bodhi.fedoraproject.org/updates/FEDORA-2016-48ee453d15 >> has already been pushed to stable? Or is there something that I need >> to do so that bodhi does that automatically? > > You should close them. > > Zbyszek > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Self Introduction: Mike Miller
Welcome to the Fedora Project! On Fri, Oct 28, 2016 at 10:15 AM, Mike Miller wrote: > Hello, > > My name is Mike Miller and I have been a software developer for almost ten > years. I am fairly new as a committer to the Open Source Community but I > have developed software using many different free and open source tools. I > frequently use Linux systems, mainly CentOS and am interested in working > with Fedora more closely. I am currently a committer on the Apache Accumulo > project. On a more personal level, I live on the East coast of the United > States and love watching sports and movies and playing video games with > friends. My GitHub username is milleruntime. > > I am looking forward to being a part of the community! > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Question about package module development
Hi all, I'm working on (learning modularity) and developing a module for my package and created a not-so-great (super long) branch name in the dist-git rpm and module repo before I realized that it would be the stream's name too. Also, it seems that the incomplete module was picked up and included in F31; someone was nice enough to open a BZ and tell me it's broken. There are builds associated with the branch, so I probably can't delete it outright, but is there a way for me to hide (or something) that branch and use the correct one that I just requested? I think that `fedpkg retire` is the way to do it, but wanted to ask first since I can't find any supporting documentation. Or now that it's been included in F31 am I stuck with it (even thought it doesn't work)? TIA, -Coty ___ 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: Question about package module development
Thanks for responding! On Fri, Sep 27, 2019 at 8:54 AM Jun Aruga wrote: > > I'm working on (learning modularity) and developing a module for my > package and created a not-so-great (super long) branch name in the dist-git > rpm and module repo before I realized that it would be the stream's name > too. > > I faced similar situation. Ruby module was released as > "private-jaruga-master" stream. > Now the branch is empty, as we can not delete it. > https://src.fedoraproject.org/modules/ruby/tree/private-jaruga-master It appears that you retired the branch, which is what I was thinking of doing. > > > > Also, it seems that the incomplete module was picked up and included in > F31 > > Policy Decision: In-development streams > https://pagure.io/modularity/issue/156#comment-600856 > > Right now "master", "devel" and "rolling" stream names are used to > test a module before releasing version "X.Y" stream. > it's unofficial way. There is a discussion about it on above URL. > Thanks for that tip, I'll use the master branch for now then. > > > someone was nice enough to open a BZ and tell me it's broken. > > Agree. Some checks before releasing are useful. > > > but is there a way for me to hide (or something) that branch and use the > correct one that I just requested? > > Yes, you can hide the branch from the result of "dnf module list". I > asked it to someone to hide "private-jaruga-master" stream. > But I forget the way. > Maybe someone else can help :D > > > but wanted to ask first since I can't find any supporting documentation. > Or now that it's been included in F31 am I stuck with it (even thought it > doesn't work)? > > This is the documentation. But I do not think it is covering your concerns. > https://docs.fedoraproject.org/en-US/modularity/making-modules/ Yeah, I've already read that a few times, but there's nothing about removal. > > > -- > Jun > ___ > 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 > -- Coty Sutherland, RHCSA, RHCE, JBCAA Senior Software Engineer Red Hat <https://www.redhat.com/> c...@redhat.com @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://red.ht/sig> ___ 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
Fwd: Tomcat Package Major Version Update
Hi all, This is a day late, but the tomcat package provided by rawhide has been updated to Tomcat 9.0! This may break some package dependencies because the servlet API package changed (new version). Sorry that I didn't provide a heads up. I have been working with the FreeIPA folks because they had a dependency on things specific to old tomcat versions, but we worked through those issues before updating. So far, I've seen one problem coming from tomcat-servlet-3.1-api being obsoleted by tomcat-servlet-4.0-api. Any packages that have an RPM requirement on that specific servlet version will need to update. Side note: I also updated fc28 to Tomcat 8.5 (from Tomcat 8.0) mid-March, but that change should be fine (minus the effects on tomcatjss). Again, my apologies on the lack of notice. Thanks, Coty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: The Javapocalypse is Monday
On Thu, Jun 3, 2021 at 5:56 PM Sérgio Basto wrote: > On Thu, 2021-06-03 at 15:30 -0600, Jerry James wrote: > > I've just been looking through my packager-dashboard page. A > > depressingly large chunk of my packages are going to become > > unbuildable on Monday when a bunch of orphaned Java packages are > > retired. I think a lot of us are going to be affected. In my case, > > there are quite a few non-Java packages involved (due to the parser > > generators antlr3 and antlr4-project), primarily OCaml and python > > packages. Mikolaj has a huge pile of work on his shoulders, so don't > > take this as criticism of him. > > > > Here are some of the pain points: > > - log4j will be retired, which will break ant. > > - hamcrest2 will be retired, which will break apache-commons-lang3, > > which will break bcel, which will also break ant. > > - google-gson and javassist will be retired, which will break > > reflections, which will break jna, which is used by about a dozen > > packages, including bcel. > > I may take these 4 > That would be great :D My package (Tomcat) still uses ant to build, so if you could save it from retirement that would be great. I don't have bandwidth to take on any additional packages right now, but I don't mind being a co-maintainer if you feel you need it. > > - maven-install-plugin will be retired, which will break tycho, which > > will break eclipse. > > Eclipse for me may fall, I already use eclipse installer from > https://www.eclipse.org/downloads/ > > > > - args4j will be retired, which will break jacoco and jgit. > > - maven-invoker-plugin and several of its dependencies > > (maven-doxia-sitetools, plexus-velocity, maven-reporting-api, > > maven-script-interpreter, and maven-reporting-impl) will be retired, > > which will break xml-maven-plugin, which is used by eclipse. > > - jakarta-el and jakarta-server-pages will be retired, which will > > break eclipse. > > - aopalliance will be retired, which will break maven-native. > > - jdependency will be retired, which will break maven-shade-plugin, > > which is used by openjfx8, a dependency of java-1.8.0-openjdk. > > - apache-ivy will be retired, which will break javapackages-tools. > > > > I can also take these two jdependency and apache-ivy . > > maybe I should also take maven-invoker-plugin . > > what do you think ? > > I have packages that depend directly on the following, so I am > > willing > > to adopt them if nobody more competent shows up (although there is no > > point in taking ant-contrib if ant is going to be broken anyway): > > - ant-contrib > > - jakarta-common-httpclient > > - jakarta-ws-rs > > - maven-invoker-plugin > > - spec-version-maven-plugin > > > > I introduced the jansi1 and jline2 packages so that jansi could be > > moved to 2.x and jline to 3.x, but I don't actually maintain any > > packages that need the old versions. I would like to give them away > > to someone who needs them, but note that you will need to grab > > jansi-native as well, before Monday! > > > > Has anybody already done something about any of these packages (and > > my > > packager-dashboard page just hasn't caught up yet)? Is anybody > > planning to do something about any of these packages before they are > > retired on Monday? > I've dropped all the direct dependencies that I had which were being orphaned, so the only outstanding problems I have are ant (which may be addressed by Sérgio) and javapackages-tools, which I'm a bit confused about. It seems that the latest build relies on java-11, not java-8 so not sure why it's showing up that way in the dep map. It seems that the map isn't generated often, so maybe it's just outdated? > -- > > Jerry James > > http://www.jamezone.org/ > > ___ > > 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 > > -- > Sérgio M. B. > ___ > 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 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fed
Tomcat Package Changes in Rawhide
Hi all, Sorry to be a bit late to the party, but in response to some indirect dependencies being orphaned I've taken the opportunity to clean up the Tomcat package a little. I have removed the following "features" from tomcat: 1) I dropped the "examples" webapp from Tomcat, which is recommended by the Security Considerations page of the upstream project anyway. This removed our dependency on the tomcat-taglibs-standard package. 2) Due to changes in the javapackages-local package (%add_maven_depmap was finally removed), I dropped the maven pom files from the tomcat packages as I feel that their usefulness is limited anyway. If you need to use the poms, Maven Central should work. 3) I've removed the tomcat-jsvc subpackage from the distribution as it isn't very useful either. This removes our dependency on the apache-commons-daemon package. This also removed the logrotate config that was offered since it was used within the tomcat-jsvc package. 4) Dropped geronimo-saaj (aka jakarta-saaj) as it's no longer required by Tomcat 9+. 5) Dropped geronimo-jaxrpc (aka jakarta-xml-rpc), which provided the webservices naming factory resources that are generally unused. This was only a build time dependency, so it wasn't used at runtime (unless users were explicitly installing it for their webapp). If anyone has issues with these changes, please let me know ASAP. There are a couple other dependencies that have to be resolved to keep Tomcat which are ant and javapackage-tools; I hope to see those resolved on the "The Javapocalypse is Monday" thread :) Thanks, Coty ___ 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: Tomcat Package Changes in Rawhide
On Fri, Jun 4, 2021 at 8:58 AM Peter Boy wrote: > Please, could you re-include the logrotate config file. It is useful > independently from the jsvc package and does not harm. > Sure, no problem. Thanks for the reply :) > Thanks > Peter > > > > > Am 04.06.2021 um 13:46 schrieb Coty Sutherland < > csuth...@fedoraproject.org>: > > 3) I've removed the tomcat-jsvc subpackage from the distribution as it > isn't very useful either. This removes our dependency on the > apache-commons-daemon package. This also removed the logrotate config that > was offered since it was used within the tomcat-jsvc package. > ___ > 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 > ___ 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: Tomcat Package Changes in Rawhide
On Fri, Jun 4, 2021 at 10:56 AM Fabio Valentini wrote: > On Fri, Jun 4, 2021 at 1:47 PM Coty Sutherland > wrote: > > > > Hi all, > > > > Sorry to be a bit late to the party, but in response to some indirect > dependencies being orphaned I've taken the opportunity to clean up the > Tomcat package a little. I have removed the following "features" from > tomcat: > > > > 1) I dropped the "examples" webapp from Tomcat, which is recommended by > the Security Considerations page of the upstream project anyway. This > removed our dependency on the tomcat-taglibs-standard package. > > 2) Due to changes in the javapackages-local package (%add_maven_depmap > was finally removed), I dropped the maven pom files from the tomcat > packages as I feel that their usefulness is limited anyway. If you need to > use the poms, Maven Central should work. > > 3) I've removed the tomcat-jsvc subpackage from the distribution as it > isn't very useful either. This removes our dependency on the > apache-commons-daemon package. This also removed the logrotate config that > was offered since it was used within the tomcat-jsvc package. > > 4) Dropped geronimo-saaj (aka jakarta-saaj) as it's no longer required > by Tomcat 9+. > > 5) Dropped geronimo-jaxrpc (aka jakarta-xml-rpc), which provided the > webservices naming factory resources that are generally unused. This was > only a build time dependency, so it wasn't used at runtime (unless users > were explicitly installing it for their webapp). > > > > If anyone has issues with these changes, please let me know ASAP. > > It looks like 2) is causing problems with resteasy, and in turn > pki-core and dogtag-pki (FreeIPA components): > nothing provides mvn(org.apache.tomcat:tomcat-servlet-api) needed by > pki-resteasy-core > > resteasy is built with maven and depends on tomcat, so the pom files > are actually needed ... > That is the worst news I've gotten in a while :/ How many maven artifacts are being used? Could I get away with only providing poms/artifacts for the servlet/jsp/el implementations or do they need all 30+ artifacts? > 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 > ___ 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: Tomcat Package Changes in Rawhide
On Fri, Jun 4, 2021 at 11:21 AM Fabio Valentini wrote: > > That is the worst news I've gotten in a while :/ How many maven > artifacts are being used? Could I get away with only providing > poms/artifacts for the servlet/jsp/el implementations or do they need all > 30+ artifacts? > > It wouldn't have been news if you checked if anything depends on those > "mvn(foo:bar)" virtual Provides before dropping them ;) > > According to koschei, resteasy only depends on one maven pom though: > No package found for: mvn(org.apache.tomcat:tomcat-servlet-api) > > See: https://koschei.fedoraproject.org/package/resteasy > > Not sure if just adding that one back will make it work again, though. > That is true :) I didn't even think about virtual deps to be honest...shame on me for that. Anyway, it looks like pki-core and dogtag-pki depend on the servlet-api via resteasy, so adding it back should be fine. Now I just have to make that happen :) For consistency sake I guess I'll add the other spec impls too, in case anyone needs them. Cheers, ___ 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
