Self Introduction
Hello, I've been creating rpm packages for Fermi Linux for over 10 years, and Scientific Linux 8 years, but I never had time to do anything for Fedora and EPEL. Now that I'm not with Scientific Linux, I've got the time. I'd like to help with the OpenShift client packages for Fedora and EPEL. So I'm going to sign up to be a co-maintainer for rubygem-rhc, and rubygem-json-pure (a new dependancy for rhc). Troy Dawson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
On 11/30/2011 07:07 PM, seth vidal wrote: > On Wed, 30 Nov 2011 17:25:25 -0600 > Troy Dawson wrote: > >> Hello, >> I've been creating rpm packages for Fermi Linux for over 10 years, and >> Scientific Linux 8 years, but I never had time to do anything for >> Fedora and EPEL. Now that I'm not with Scientific Linux, I've got >> the time. I'd like to help with the OpenShift client packages for >> Fedora and EPEL. So I'm going to sign up to be a co-maintainer for >> rubygem-rhc, and rubygem-json-pure (a new dependancy for rhc). > > > > > I dunno. He's shifty.() He hangs out with known unseemly > people (mmcgrath) and has been known to hang out with even more > unseemly people (physicists!!). > > > > Hi Troy! > -sv Hi Seth, It's good to see our circles are crossing again. Troy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Retiring OpenShift v2 non-client packages from Fedora
OpenShift Origin release 4 no longer supports Fedora, only RHEL/SL/CentOS. The reason is that the ruby in Fedora has progressed so fast that it is no longer compatible with the code in OpenShift Origin. There is currently no plans to update the current code in OpenShift Origin to a newer ruby, instead efforts are being targeted towards OpenShift v3. (Not to be confused with OpenShift Origin release 3. http://origin.openshift.com/blog/openshift-v3-platform-combines-docker-kubernetes-atomic-and-more WE had hoped to prolong OpenShift v2 in Fedora with SCL packages, but that never worked out. I will be removing all non-client OpenShift v2 packages from Fedora. When it is considered stable enough, the OpenShift v3 packages will be added into Fedora. There is no current estimate for that. Note: OpenShift client packages (rubygem-rhc and openshift-java-client) will remain in Fedora. This is the list of packages I plan to retire. openshift-origin-broker openshift-origin-broker-util openshift-origin-cartridge-abstract openshift-origin-cartridge-cron openshift-origin-cartridge-diy openshift-origin-cartridge-mongodb openshift-origin-cartridge-mysql openshift-origin-msg-common openshift-origin-msg-node-mcollective openshift-origin-node-proxy openshift-origin-node-util openshift-origin-port-proxy openshift-origin-util pam_openshift rubygem-openshift-origin-auth-mongo rubygem-openshift-origin-auth-remote-user rubygem-openshift-origin-common rubygem-openshift-origin-controller rubygem-openshift-origin-dns-bind rubygem-openshift-origin-dns-nsupdate rubygem-openshift-origin-msg-broker-mcollective rubygem-openshift-origin-node I will also go through and make sure any pending review requests are closed as well. Please let me know if there are any questions. Thanks Troy Dawson -- 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: Annonce: qt-virt-manager
On 04/22/2015 12:36 PM, Fl@sh wrote:
> Hi, all!
> I'm developing qt-virt-manager.
> I have to say: this is not a Qt-clone of the virt-manager.
> The application is able to perform a lot, so I suggest you to
> use, and look forward to your wishes.
> (I'm make fedora-build, if somebody build it for other
> distributives, then , pls, say to me for annonce on
> opendesktop.org site.)
>
> https://github.com/F1ash/qt-virt-manager
> https://f1ash.fedorapeople.org/qt-virt-manager/
> http://opendesktop.org/content/show.php/qt-virt-manager?content=169785
>
Looks very nice.
I had to build qtermwidget and then make one tweek [2] to the spec file
to get it to build on RHEL7.
I have uploaded my built packages incase others want to try them on
rhel7. [1]
One feature that I think would be nice, would be to make it easy to
find, setup and connect to localhost connections.
Keep up the good work.
Troy Dawson
[1] - https://tdawson.fedorapeople.org/qt-virt-manager/
[2] - %{make_build} isn't in rhel7 rpm macros.
@@ -74,14 +74,14 @@
mkdir %{cmake_build_dir}-qt4
pushd %{cmake_build_dir}-qt4
%cmake ..
- %{make_build}
+ %{__make} %{?_smp_mflags}
popd
%endif
%if %with qt5
mkdir %{cmake_build_dir}-qt5
pushd %{cmake_build_dir}-qt5
%cmake -DBUILD_QT_VERSION=5 ..
- %{make_build}
+ %{__make} %{?_smp_mflags}
popd
%endif
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaning two packages
I have not been able to give mozilla-iot-gateway the attention that it needs. Also, upstream now has Fedora rpm's[1], and a container, so having it in Fedora is not as critical as it once was. Below is the packages I am orphaning: mozilla-iot-gateway nodejs-nanomsg There is nothing that depends on them. Troy Dawson [1] - https://github.com/mozilla-iot/gateway/releases ___ 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: default media size [Was: Proposed F18 feature: MiniDebugInfo]
On 05/09/2012 03:07 PM, Jaroslav Reznik wrote: >> I know I've said this before, but: we should break the CD size >> barrier >> precisely so people can't burn things to CDs. If you must burn to >> optical media, do yourself a favor and burn a DVD, the reduced seek >> time >> is entirely worth it. > > I'd like to break CD limit too but we should not forgot there are users > for which CD is top technology from dreams and we have a lot of these > users among some countries... For me personally CD is history, even > DVD, same 1 GB flash drive. We can afford it. But some people can't > and are our users thanks to the ability to get a cheap OS, that can > run on cheap HW and is still modern. > > The question is - how many people will be affected? Or should we > provide some fallback option - stripped down CD media size image? And > make the bigger one primary one? > > R. > I like the idea of a separate stripped down live CD image. But it doesn't have to be too stripped down. What if we made the LXDE and/or Xfce spin's CD size, while the Gnome and KDE live images would be DVD size. *braces for the Gnome is our default desktop replies* Troy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 21
On 05/29/2014 08:43 AM, Till Maas wrote: > Since the mass rebuild will start in a week (2014-06-06) it is a good > time to start cleaning up Fedora. After the mass rebuild, packages that > fail to build for two releases will be be added to this list. Since this > is the first run after adapting the script to pkgdb2, there might be > some errors here, please report them. > > The following packages are orphaned and will be retired when Fedora > (F21) is branched, unless someone adopts 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 > ... > openshift-origin-cartridge-abstract orphan, > maxamillion > openshift-origin-cartridge-cron-1.4 orphan, > maxamillion, tdawson > openshift-origin-cartridge-diy-0.1orphan, > maxamillion, tdawson ... These three packages need to go away, they have been replaced. Please retire them with a clear conscious. openshift-origin-cartridge-cron-1.4 -> openshift-origin-cartridge-cron openshift-origin-cartridge-diy-0.1 -> openshift-origin-cartridge-diy openshift-origin-cartridge-abstract -> No longer needed. I'd followed the procedure for Renaming/Replacing Existing Packages [1] but I guess your script is just being extra cautious. Troy Dawson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
delta rpms - can we turn them off
Hi, I have a very small server room. It has very good network, but lots of not very powerful computers. Many of them are ARM based. As I hear about ARM users taking 8 hours to update 1 package (I've had it take 12 hours to fail to update a package) I irritates me. The fact that Fedora practically forces people to use delta rpm's has rattled my cage for quite a while. I eventually opened a bugzilla with what I consider a reasonable compromise.[1] " Please put deltarpm=1 in /etc/yum.conf, at a minimum. A comment about it would be better. It would be even better if you put deltarpm=0 for the arm builds. " Why bring it up here? Two reasons. 1 - As you can see, my bugzilla hasn't even been acknowledged. 2 - I'm wondering about dnf (Duke Nukem Forever) -- What is it's stance on delta rpms? --- Does it do them? --- Does it force you to do them like yum does? --- Is there an easy to find option to turn them off/on? Thanks Troy Dawson [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1074600 -- 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: delta rpms - can we turn them off
On 06/27/2014 09:17 AM, Rahul Sundaram wrote: > Hi > > > On Fri, Jun 27, 2014 at 10:07 AM, Troy Dawson wrote: > > The fact that Fedora practically forces people to use delta rpm's has > rattled my cage for quite a while. > > > [Snipped] > > --- Does it force you to do them like yum does? > > > [Snipped] > > You keep calling it force while acknowledging it is merely a > configurable default. > > Rahul It is a hidden default that is not in any man page or documentation. Yes, I used a poor choice of words. The problem is, that people keep hiding the configuration, even you just did it. " Please put deltarpm=1 in /etc/yum.conf, at a minimum. A comment about it would be better. It would be even better if you put deltarpm=0 for the arm builds. " All I'm asking, if this is going to be the default, make it easier for people to find the configuration so they can change it. Troy -- 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: delta rpms - can we turn them off
On 06/27/2014 10:45 AM, Rahul Sundaram wrote: > Hi > > > On Fri, Jun 27, 2014 at 11:26 AM, Troy Dawson wrote: > > > > It is a hidden default that is not in any man page or documentation. > Yes, I used a poor choice of words. > > > man yum.conf > > deltarpm > > When non-zero, delta-RPM files are used if available. The > value > specifies the maximum number of "applydeltarpm" > processes Yum > will spawn, if the value is negative then yum works out > how many > cores you have and multiplies that by the value > (cores=2, > deltarpm=-2; 4 processes). (2 by default). > > Rahul > > > > > Cool, I'm glad it's in the man pages now. It isn't in the man pages of my older versions of yum. And it's actually a very good section, talking about how it determines how many threads to use. Now that we've established that, what about the problem with running deltarpm on ARM or Atom based machines? Looking at the man page, it might not even be a problem with the CPU, but the IO of the machine. Almost all the machines in my tiny sever rack are running off slow disks, USB, or SD cards. All that being said, what is the criteria for getting a default configuration line put into yum.conf? I'd really like to get the deltarpm= line put in there. Troy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Update mongodb to 2.2.0 (latest release)
Hello, I have updated mongodb from 2.0.7 to 2.2.0. It is currently going through the normal channels for rawhide and Fedora 18. 10gen has a very good track record for being backwards compatible. According to their documentation "When upgrading a standalone mongod, 2.2 is a drop-in replacement." and "MongoDB 2.0 data files are compatible with 2.2-series binaries without any special migration process." If upgrading replica sets and sharded cluster, you should follow the procedures from their release notes. http://docs.mongodb.org/manual/release-notes/2.2/#upgrading What are people's thoughts on bringing it into Fedora 16, Fedora 17, EPEL6 and EPEL5? Troy Dawson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update mongodb to 2.2.0 (latest release)
On 10/05/2012 04:43 PM, Troy Dawson wrote: > Hello, > I have updated mongodb from 2.0.7 to 2.2.0. > It is currently going through the normal channels for rawhide and Fedora 18. > > 10gen has a very good track record for being backwards compatible. > According to their documentation "When upgrading a standalone mongod, > 2.2 is a drop-in replacement." and "MongoDB 2.0 data files are > compatible with 2.2-series binaries without any special migration process." > If upgrading replica sets and sharded cluster, you should follow the > procedures from their release notes. > http://docs.mongodb.org/manual/release-notes/2.2/#upgrading > > What are people's thoughts on bringing it into Fedora 16, Fedora 17, > EPEL6 and EPEL5? > > Troy Dawson I have had requests for mongodb 2.2.0 for Fedora 17, as well as EPEL 6 and 5. I am going to build for those tomorrow and let things sit in testing for at least a week (2 weeks for EPEL). The only concern I have received thus far is whether packages will need to be rebuilt against the new mongodb 2.2. From everything I have looked at, the answer is no. The API's should be backward compatible. The libraries provided are the same name, there is no increase in number. $ rpm -qp --provides libmongodb-2.0.7-2.fc18.x86_64.rpm libmongoclient.so()(64bit) libmongodb = 2.0.7-2.fc18 libmongodb(x86-64) = 2.0.7-2.fc18 $ rpm -qp --provides libmongodb-2.2.0-6.fc18.x86_64.rpm libmongoclient.so()(64bit) libmongodb = 2.2.0-6.fc18 libmongodb(x86-64) = 2.2.0-6.fc18 Thank You Troy Dawson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update mongodb to 2.2.0 (latest release)
On 10/09/2012 06:23 AM, Andrey Ponomarenko wrote: > Dan Horák wrote: >> Troy Dawson píše v Po 08. 10. 2012 v 14:48 -0500: >>> On 10/05/2012 04:43 PM, Troy Dawson wrote: >>>> Hello, >>>> I have updated mongodb from 2.0.7 to 2.2.0. >>>> It is currently going through the normal channels for rawhide and >>>> Fedora 18. >>>> >>>> 10gen has a very good track record for being backwards compatible. >>>> According to their documentation "When upgrading a standalone mongod, >>>> 2.2 is a drop-in replacement." and "MongoDB 2.0 data files are >>>> compatible with 2.2-series binaries without any special migration >>>> process." >>>> If upgrading replica sets and sharded cluster, you should follow the >>>> procedures from their release notes. >>>> http://docs.mongodb.org/manual/release-notes/2.2/#upgrading >>>> >>>> What are people's thoughts on bringing it into Fedora 16, Fedora 17, >>>> EPEL6 and EPEL5? >>>> >>>> Troy Dawson >>> I have had requests for mongodb 2.2.0 for Fedora 17, as well as EPEL 6 >>> and 5. I am going to build for those tomorrow and let things sit in >>> testing for at least a week (2 weeks for EPEL). >>> >>> The only concern I have received thus far is whether packages will need >>> to be rebuilt against the new mongodb 2.2. >>> >>> From everything I have looked at, the answer is no. >>> The API's should be backward compatible. >>> The libraries provided are the same name, there is no increase in >>> number. >> you can use the abi-compliance-checker tool to confirm that > > or look at the upstream-tracker report for mongodb: > http://upstream-tracker.org/versions/mongodb.html > > particularly, the compatibility report between 2.0.7 and 2.2.0 versions > is: > http://upstream-tracker.org/compat_reports/mongodb/2.0.7_to_2.2.0/compat_report.html > > Well, that isn't encouraging. I'm pretty sure at the very least we need to update the various mongo drivers (rubygem-mongo, pymongo, etc..) I'm still going to build mongodb 2.2.0 for the various releases, otherwise people won't be able to test it. But they may sit in testing for longer than the standard time. Troy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update mongodb to 2.2.0 (latest release)
On 10/09/2012 09:51 AM, Dennis Jacobfeuerborn wrote: > On 10/08/2012 09:48 PM, Troy Dawson wrote: >> On 10/05/2012 04:43 PM, Troy Dawson wrote: >>> Hello, >>> I have updated mongodb from 2.0.7 to 2.2.0. >>> It is currently going through the normal channels for rawhide and Fedora 18. >>> >>> 10gen has a very good track record for being backwards compatible. >>> According to their documentation "When upgrading a standalone mongod, >>> 2.2 is a drop-in replacement." and "MongoDB 2.0 data files are >>> compatible with 2.2-series binaries without any special migration process." >>> If upgrading replica sets and sharded cluster, you should follow the >>> procedures from their release notes. >>> http://docs.mongodb.org/manual/release-notes/2.2/#upgrading >>> >>> What are people's thoughts on bringing it into Fedora 16, Fedora 17, >>> EPEL6 and EPEL5? >>> >>> Troy Dawson >> >> I have had requests for mongodb 2.2.0 for Fedora 17, as well as EPEL 6 >> and 5. I am going to build for those tomorrow and let things sit in >> testing for at least a week (2 weeks for EPEL). >> >> The only concern I have received thus far is whether packages will need >> to be rebuilt against the new mongodb 2.2. >> >> From everything I have looked at, the answer is no. >> The API's should be backward compatible. >> The libraries provided are the same name, there is no increase in number. >> >> $ rpm -qp --provides libmongodb-2.0.7-2.fc18.x86_64.rpm >> libmongoclient.so()(64bit) >> libmongodb = 2.0.7-2.fc18 >> libmongodb(x86-64) = 2.0.7-2.fc18 >> >> $ rpm -qp --provides libmongodb-2.2.0-6.fc18.x86_64.rpm >> libmongoclient.so()(64bit) >> libmongodb = 2.2.0-6.fc18 >> libmongodb(x86-64) = 2.2.0-6.fc18 > > Updates to existing EPEL/Fedora version should probably wait until at least > 2.2.1 is out. I've seen at least one report of sharding problems with 2.2.0 > that were confirmed by the developers and reported as fixed in trunk and to > be released in 2.2.1. > In general you should probably wait for at least one or two additional > releases to catch the most blatant bugs in the new major version. > > In as-of-yet unreleased verions like Fedora 18 this is not such a big issue > since these will all be fresh setup and bugs will be noticed then and there > but someone who is running 2.0 for a while in Fedora 17 or Centos 6 should > not be hit by such things. > > Regards, > Dennis > Sorry, I did not see this before I sent my previous email. What do you think about building it for EPEL and just letting it sit in testing? Or do you think I should just hold off building it for EPEL completely until 2.2.1 is out? Troy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update mongodb to 2.2.0 (latest release)
On 10/09/2012 10:18 AM, Troy Dawson wrote: > On 10/09/2012 09:51 AM, Dennis Jacobfeuerborn wrote: >> On 10/08/2012 09:48 PM, Troy Dawson wrote: >>> On 10/05/2012 04:43 PM, Troy Dawson wrote: >>>> Hello, >>>> I have updated mongodb from 2.0.7 to 2.2.0. >>>> It is currently going through the normal channels for rawhide and Fedora >>>> 18. >>>> >>>> 10gen has a very good track record for being backwards compatible. >>>> According to their documentation "When upgrading a standalone mongod, >>>> 2.2 is a drop-in replacement." and "MongoDB 2.0 data files are >>>> compatible with 2.2-series binaries without any special migration process." >>>> If upgrading replica sets and sharded cluster, you should follow the >>>> procedures from their release notes. >>>> http://docs.mongodb.org/manual/release-notes/2.2/#upgrading >>>> >>>> What are people's thoughts on bringing it into Fedora 16, Fedora 17, >>>> EPEL6 and EPEL5? >>>> >>>> Troy Dawson >>> >>> I have had requests for mongodb 2.2.0 for Fedora 17, as well as EPEL 6 >>> and 5. I am going to build for those tomorrow and let things sit in >>> testing for at least a week (2 weeks for EPEL). >>> >>> The only concern I have received thus far is whether packages will need >>> to be rebuilt against the new mongodb 2.2. >>> >>> From everything I have looked at, the answer is no. >>> The API's should be backward compatible. >>> The libraries provided are the same name, there is no increase in number. >>> >>> $ rpm -qp --provides libmongodb-2.0.7-2.fc18.x86_64.rpm >>> libmongoclient.so()(64bit) >>> libmongodb = 2.0.7-2.fc18 >>> libmongodb(x86-64) = 2.0.7-2.fc18 >>> >>> $ rpm -qp --provides libmongodb-2.2.0-6.fc18.x86_64.rpm >>> libmongoclient.so()(64bit) >>> libmongodb = 2.2.0-6.fc18 >>> libmongodb(x86-64) = 2.2.0-6.fc18 >> >> Updates to existing EPEL/Fedora version should probably wait until at least >> 2.2.1 is out. I've seen at least one report of sharding problems with 2.2.0 >> that were confirmed by the developers and reported as fixed in trunk and to >> be released in 2.2.1. >> In general you should probably wait for at least one or two additional >> releases to catch the most blatant bugs in the new major version. >> >> In as-of-yet unreleased verions like Fedora 18 this is not such a big issue >> since these will all be fresh setup and bugs will be noticed then and there >> but someone who is running 2.0 for a while in Fedora 17 or Centos 6 should >> not be hit by such things. >> >> Regards, >> Dennis >> > > Sorry, I did not see this before I sent my previous email. What do you > think about building it for EPEL and just letting it sit in testing? Or > do you think I should just hold off building it for EPEL completely > until 2.2.1 is out? > > Troy > mongodb 2.2.0 is in updates-testing for Fedora 17, and epel-testing for EPEL 6. Due to concerns about updating from 2.0.x to 2.2.x these will probably remain in testing until 2.2.1 is out and packaged. So, if you are running Fedora 17, or EPEL 6, you can test mongodb 2.2 by using the testing repositories. But it won't go into those main repo's until at least mongo 2.2.1. Thank you for the feedback I've received. Troy p.s. Nick has been working with me some off-line. But since my project needed 2.2, and his didn't, I took the lead for this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On 07/15/2013 04:26 PM, Jonathan Masters wrote: On Jul 15, 2013, at 5:11, Miroslav Suchý wrote: On 07/15/2013 10:44 AM, Jaroslav Reznik wrote: = Proposed System Wide Change: No Default Syslog = https://fedoraproject.org/wiki/Changes/NoDefaultSyslog Change owner(s): Lennart Poettering , Matthew Miller No longer install a traditional syslog service by default. (Specifically, remove rsyslog from the @core or @standard groups in comps.) The systemd journal will be the default logging solution. Rsyslog, Syslog-NG, and even traditional sysklogd will continue to cover use cases outside of the default. My voice may be one of thousands, but I'm saying: I want to have traditional syslog service as default and have journal from systemd as option. I concur. I have systems that live in a heterogeneous environment and need traditional syslog. By making it optional, it will ultimately die, forcing journal as the only viable option in a Fedora environment. This is IMO not net beneficial for downstream use cases later on either. Jon. I've read though most of the email on this thread, and would just like to put in my $.02. I think this "System Wide Change" is 1 to 2 releases too early. I'm not totally against it. But I live with one foot in RHEL land, and one foot in Fedora. It takes me a while to incorporate these new features. I need more transition time. Just taking it out of @core instead of both would ease the transition. Troy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rubygem-passenger - FTBFS on f20 - need help
Hi, I'm hoping that someone on this list can say "Oh, ya, this change happened and it causes that, here's the solution." because I've spent a month running against a brick wall. Short summary: rubygem-passenger won't build due to uint32_t issues. And it is affecting x86_64 different than it is i386 and arm. Details: With original src.rpm, x86_64 build [1] failed with the error "error: 'uint8_t' does not name a type" and "error: 'uint32_t' does not name a type" With original src.rpm, i386 build [2] failed with the error "error: reference to 'uint32_t' is ambiguous" With a patch that puts "#include " into the correct header files, x86_64 builds correctly.[3] But that patch does nothing for i386 or arm build. [4] So, my question is this. What happened with f20 that causes these errors? What is a good way to track down a solution to "error: reference to 'uint32_t' is ambiguous"? Thanks Troy Dawson [1] http://kojipkgs.fedoraproject.org//work/tasks/1540/5951540/build.log [2] http://kojipkgs.fedoraproject.org//work/tasks/1545/5951545/build.log [3] http://kojipkgs.fedoraproject.org//work/tasks/2733/5952733/build.log [4] http://kojipkgs.fedoraproject.org//work/tasks/2735/5952735/build.log -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rubygem-passenger - FTBFS on f20 - need help
On 09/18/2013 06:45 PM, Lars Seipel wrote: On Wed, Sep 18, 2013 at 03:29:19PM -0500, Troy Dawson wrote: What is a good way to track down a solution to "error: reference to 'uint32_t' is ambiguous"? Sorry for the multiple mails but after looking at the source I think I see the actual problem. So in e.g. ext/common/Utils/MessageIO.h we have: #include ... using namespace std; using namespace boost; ... use uint32_t <- error: reference to 'uint32_t' is ambiguous The bundled boost cstdint header is including stdint.h on systems that have it. So ::uint32_t is provided by that. Additionally it emits typedefs for the stdint types in the boost namespace with a declaration conflicting with glibc's. As the passenger code is importing the boost namespace 'uint32_t' could refer to ::uint32_t (from stdint.h included through boost) or boost::uint32_t. That's what leads to the error. Looking at our system boost cstdint.hpp it is doing something smarter. Instead of coming up with its own uint32_t it's just referring to the one from stdint.h (by means of a using ::uint32_t; declaration), so it can't ever conflict. After looking at the passenger-bundled boost header (instead of only cpp's output) its intention seems to be the same but it's broken. Our boost RPM carries a patch that fixes it. Ah, the joys of bundled libraries. ;-) http://pkgs.fedoraproject.org/cgit/boost.git/tree/boost-1.54.0-__GLIBC_HAVE_LONG_LONG.patch You could apply that patch to the bundled boost copy to fix the issue. Another way would be to just delete the bundled ext/boost/cstdint.hpp file in %prep and let it pick up the system cstdint.hpp. You'd obviously have to buildrequire: boost-devel for that. Hope that helps, Lars Thank you thank you thank you Yes, that did the trick. I recognized that patch because I had looked at the changes in boost between f19 and f20, but it had never crossed my mind to put that change in the passenger boost. Thank you again Troy Dawson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Hardened checking - how?
Hi, Is there an official Fedora way for telling is something is hardened correctly? I'm working on hardening mongodb, and I think I have it right, but I'd really like to check. I was given a couple of scripts, which had dependencies not in Fedora, which then had dependencies not in Fedora, and so forth. At the third level of dependencies, I figured there had to be a more official way. If I missed a Fedora web page on it, or it was in the recent hardening discussion, feel free to point me to it. Thanks Troy Dawson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hardened checking - how?
On 06/06/2013 03:36 PM, Troy Dawson wrote: Hi, Is there an official Fedora way for telling is something is hardened correctly? I'm working on hardening mongodb, and I think I have it right, but I'd really like to check. I was given a couple of scripts, which had dependencies not in Fedora, which then had dependencies not in Fedora, and so forth. At the third level of dependencies, I figured there had to be a more official way. If I missed a Fedora web page on it, or it was in the recent hardening discussion, feel free to point me to it. Thanks Troy Dawson Hi, Thanks for all the suggestions and help. Since there were a couple of threads that came off of this, I'm going to give a summary here. Programs: http://people.redhat.com/sgrubb/files/rpm-chksec (what I ended up using) http://packages.debian.org/sid/hardening-includes (packaged into rpm, see below) https://nohats.ca/checksec.sh (works) https://github.com/kholia/checksec (had fedora dependency problems that are being worked on) rpm: hardening-check - http://koji.fedoraproject.org/koji/packageinfo?packageID=16362 Articles: http://lwn.net/Articles/454532/ Summary: I ended up using rpm-chksec because it did everything I needed and all it's requirements were already installed on my machine. Why I chose that? While the other would check files, rpm-chksec took an rpm as an argument and then checked all the binaries in it, giving a nice output. Again, thanks to everyone who replied. I am glad I checked it. The mongodb scons stuff wasn't accepting arguments as I originally thought, and I found out that I hadn't really hardened mongodb. I'm still working on it. My next patch hardens it, but fails on a few platforms in ways I'm totally not expecting. So, the work goes on, but having a check helps. Thanks Troy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[HEADS-UP] Updating MongoDB in F17 and EPEL6
Hello, A couple of months back I asked about updating MongoDB from 2.0.7 to 2.2.0 in EPEL6 and Fedora 17. Although it is backwards compatible, there were several bugs brought up that people wanted fixed in Mongodb 2.2.x before we moved to this version. With MongoDB 2.2.3, the last of these bugs has been fixed. MongoDB 2.2.3 is now built and in testing, and I propose the following schedule. February 20 Push MongoDB 2.2.3 to stable for Fedora 17 and EPEL6 If anyone has any concerns, please let me know. If anyone knows where else I should announce this other than epel-devel-list, please let me know. Thanks Troy Dawson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Updating MongoDB in F17 and EPEL6
On 02/08/2013 11:54 AM, Troy Dawson wrote: > Hello, > A couple of months back I asked about updating MongoDB from 2.0.7 to > 2.2.0 in EPEL6 and Fedora 17. > Although it is backwards compatible, there were several bugs brought up > that people wanted fixed in Mongodb 2.2.x before we moved to this > version. With MongoDB 2.2.3, the last of these bugs has been fixed. > MongoDB 2.2.3 is now built and in testing, and I propose the following > schedule. > > February 20 > Push MongoDB 2.2.3 to stable for Fedora 17 and EPEL6 > > If anyone has any concerns, please let me know. > If anyone knows where else I should announce this other than > epel-devel-list, please let me know. > > Thanks > Troy Dawson I have only heard positive feedback for this. I am now marking mongodb 2.2.3 to stable for both Fedora 17 and EPEL6. Expect the usual delay of a day or two for these to make it into the stable repositories and to a mirror near you. My thanks to everyone who tested and replied back to me. Troy Dawson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Feature Freeze is tomorrow!
Hi Jaroslav, I had updated our page to say that we were 95% complete, and I thought we were. But our first tests found a major cgroups bug, that has been fixed in our latest release, that just was finished yesterday. In short, yes, we are complete, but there is going to be a major update of packages today. That doesn't mean we are adding features, just fixing a major bug. Troy On 03/11/2013 12:02 PM, Jaroslav Reznik wrote: > REMINDER: Tuesday, March 12 is the Feature Freeze for Fedora 19, > the Planning & Development phase ends - that means tomorrow! > > At this point, all accepted features should be substantially complete, > and testable. Additionally, if a feature is to be enabled by default, > it must be so enabled at Feature Freeze. See [1] and [2]. > > For more detail, check my previous announcement: > http://lists.fedoraproject.org/pipermail/devel-announce/2013-March/001125.html > > There are still quite a lot of Features not updated recently, you will > make my life much more easier by filling the current status (I don't have > to ask everyone individually then;-). And of course, thanks to everyone who > already updates theirs Features! > > Thanks > Jaroslav > > [1] https://fedoraproject.org/wiki/Feature_Freeze_Policy > [2] https://fedoraproject.org/wiki/Features/Policy/Milestones#Feature_Freeze > > ___ > devel-announce mailing list > devel-annou...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Taking ownership of html2text on EPEL6
Hi, I will be taking ownership of html2text on EPEL6. I am already the maintainer for EPEL7, but I missed the notification that the EPEL6 version was being orphaned because of filters. Troy Dawson -- 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: Taking ownership of html2text on EPEL6
On 01/09/2015 02:41 PM, Troy Dawson wrote: > Hi, > I will be taking ownership of html2text on EPEL6. > I am already the maintainer for EPEL7, but I missed the notification > that the EPEL6 version was being orphaned because of filters. > Troy Dawson > Hi All, This has turned out to be much more painful than the documentation [1] would have you believe. Anyway, I've eventually managed to become the maintainer for EPEL6, but my problem now is that it's blocked. I cannot build the package. Can someone unblock html2text on epel6 and/or point me to the documentation that says how to unblock a package. Thank You Troy p.s. If someone wants to talk with me about updating the documentation, I can talk to you about the pain points. But I didn't want that to be the focus of this email. [1] http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package_Procedure -- 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: Taking ownership of html2text on EPEL6
On 02/25/2015 10:23 AM, Vít Ondruch wrote: > Dne 25.2.2015 v 17:18 Troy Dawson napsal(a): >> On 01/09/2015 02:41 PM, Troy Dawson wrote: >>> Hi, >>> I will be taking ownership of html2text on EPEL6. >>> I am already the maintainer for EPEL7, but I missed the notification >>> that the EPEL6 version was being orphaned because of filters. >>> Troy Dawson >>> >> Hi All, >> This has turned out to be much more painful than the documentation [1] >> would have you believe. >> >> Anyway, I've eventually managed to become the maintainer for EPEL6, but >> my problem now is that it's blocked. I cannot build the package. >> >> Can someone unblock html2text on epel6 and/or point me to the >> documentation that says how to unblock a package. >> >> Thank You >> Troy >> >> p.s. If someone wants to talk with me about updating the documentation, >> I can talk to you about the pain points. But I didn't want that to be >> the focus of this email. >> >> [1] >> http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package_Procedure > > Quoting from [1]: > >> 5. Request that the Release Engineering team > <http://fedoraproject.org/wiki/ReleaseEngineering> unblock the package > for the releases that the package should be un-retired for via their > trac instance <https://fedorahosted.org/rel-eng/newticket>. In this > request, please post a link to the completed re-review and clearly > specify which branches should be unblocked. > > So you were are on the right path. > > > Vít > > > [1] > http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package > > Thank you Vit, that was exactly what I was looking for. I don't know why I missed that. Troy -- 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 33 System-Wide Change proposal: ELN Buildroot and Compose
On Wed, Mar 25, 2020 at 6:15 AM Nicolas Mailhot via devel wrote: > > Le mercredi 25 mars 2020 à 13:09 +0100, Aleksandra Fedorova a écrit : > > On Wed, Mar 25, 2020 at 12:48 PM Miro Hrončok > > wrote: > > As I mentioned in the previous mail, branching goes against the > > purpose of the effort. > > > > What we like to achieve is to create a continuous flow from Fedora > > Rawhide through branched Fedora all the way to downstream, which is > > sometimes CentOS and sometimes EPEL. > > Then please work with @rh engineering to get an up-to-date packaging > stack in EL (that means, latest stable Fedora rpm and latest stable > Fedora packaging macros, and all the other things that make packager > work less a shore). > > A huge amount of EL ifdefs is directly caused by the staleness of the > packaging stack in EL. That’s why so much Fedora stuff never makes it > in EPEL. Most people Fedora side do not want to deal with the utter > clustefuck of trying to push complex up to date software to EL using > inadequate obsolete tooling. > > No amount of clever ifdefing is going to mitigate this tooling > staleness. No amount of poking is going to convince people that *do* > *not* *want* *to* *deal* *with* *el* *braindamage* to accept > braindamage side-effects in their own Fedora specs. That’s trying to > put lipstick on a pig. > > We’ve been saying that to @rh representatives for years now. rpm and > its ajuncts is the heart of community packaging. Packaging is done by > packagers. Packaging is not done by people that loath packaging (and > are continuously surprised their own packaging tools for people not > interested in packaging do not see mass packager adoption). > > rpm state in EL prevents most downstreaming. Please focus efforts > there. > > I don’t see how you will get any community adhesion in fixing > downstream problems, if all your solutions are downstream focused, > without caring about the people you want to enroll. > RHELN (currently RHEL9) is supposed to look like rawhide up to whatever the cutover point is. So, up until that point, you shouldn't be putting RHEL conditionals in, unless you do so for EPEL packages. There are exceptions to this, such as the kernel, glibc, firefox, and a handful of others. But those are the exceptions. After the cutover date, then again, RHELN (in the next case it will be RHEL10) should be looking like whatever is in rawhide, so you still shouldn't need RHEL conditionals in, unless you do so for EPEL package builds. This ELN proposal has nothing to do with older RHEL releases or EPEL. Troy ___ 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
[EPEL-devel] Re: RHEL8 package list
On Sun, Mar 29, 2020 at 10:52 AM Kevin Fenzi wrote:
>
> On Sun, Mar 29, 2020 at 06:11:28PM +0200, Dominik 'Rathann' Mierzejewski
> wrote:
> > On Sunday, 29 March 2020 at 15:59, Mattia Verga wrote:
> > > Is there a way to get the package list and their version available in
> > > RHEL8? For example, I would like to make kpmcore and
> > > kde-partitionmanager available in EPEL8, but they require util-linux
> > > >= 2.33.2. Since I can't find what version is available in
> > > Bodhi/Koji/etc. I would like to know if there's some other web
> > > service where I can find that without having to install a VM just for
> > > that...
> >
> > Unofficial, but very useful:
> > http://rpms.remirepo.net/rpmphp/zoom.php
>
> There's also:
>
> https://infrastructure.fedoraproject.org/repo/json/
>
> which are pulled from the repos epel uses in koji.
>
> Looks like util-linux is 2.32.1...
>
> "util-linux": {"channels": {"codeready-builder-for-rhel-8-aarch64-rpms":
> [{"release": "17.el8", "epoch": "0", "versions": "2.32.1"},
>
Please file a bug in bugzilla, requesting both of these to be added to EPEL8.
It's possible that we might need to use the older version from Fedora
30 (kpmcore-3.3.0-5 and kde-partitionmanager-3.3.1-4)
Troy
___
epel-devel mailing list -- epel-de...@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-de...@lists.fedoraproject.org
[EPEL-devel] Re: EL8 pandoc PDF support
On Fri, Apr 17, 2020 at 9:22 AM Leon Fauster wrote:
>
> Am 17.04.20 um 17:00 schrieb Troy Dawson:
> > On Fri, Apr 17, 2020 at 7:07 AM Leon Fauster
> > wrote:
> >>
> >> I am unsure if this is something for RHEL8 or EPEL8:
> >>
> >> The usage in EL8 of
> >>
> >> pandoc --pdf-engine=xelatex
> >> pandoc --pdf-engine=lualatex
> >>
> >> is broken.
> >>
> >> Because EL8 doesn't provide texlive-ucharcat-%{VERSION}.rpm
> >>
> >> I already opened a ticket here:
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1820194
> >>
> > Not much we can do about pandoc, because it is in RHEL8.
> >
> > texlive-* packages ... sorry ... scary nightmare after looking at the
> > spec file for that.
> >
> > Technically, I believe we could have some type of epel-only texlive-*
> > package(s) as long as the source rpm isn't the same name as texlive.
> > But trust me when I say, I won't touch that with a 10 foot pole. I
> > will run screaming if it's even in the same building as me.
> > But if others want to try, as long as things don't conflict. I know
> > there are many texlive-* packages not in RHEL8.
> >
>
> My understanding is that such EPEL8 packages are build outside of
> texlive-base-%VERSION.src.rpm or texlive-%VERSION.src.rpm source
> packages, for EPEL8 its an texlive-extension package. Than Ngo has
> build the initial EPEL8 src.rpm package [1]. Maybe this is less a
> nightmare.
>
> Fedora:
> rpm -q --qf '%{NAME}|%{SOURCERPM}|%{VENDOR}\n' texlive-lacheck
> texlive-ucharcat
> texlive-lacheck|texlive-base-20190410-8.fc31.src.rpm|Fedora Project
> texlive-ucharcat|texlive-2019-19.fc31.src.rpm|Fedora Project
>
> RHEL8
> rpm -q --qf '%{NAME}|%{SOURCERPM}|%{VENDOR}\n' texlive-lacheck
> texlive-lacheck|texlive-extension-20180414-2.el8.src.rpm|Fedora Project
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1785439
>
Thank you Than.
You are the slayer of my nightmares. :)
As it says in that bugzilla.
"there's texlive-extension component in bugzilla, if you want to make
requests like above, please open the bug in texlive-extension and add
your requests there."
And thank you Leon for pointing that out. I won't be so scared of
questions like these anymore. :)
Troy
___
epel-devel mailing list -- epel-de...@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-de...@lists.fedoraproject.org
Re: Co-Maintainers wanted for python-lockfile EPEL branches
On a RHEL8 machine, doing a dnf repoquery --whatrequires python3-lockfile dnf repoquery --whatrequires python2-lockfile Shows that the following depend on it duplicity python3-fedora pungi-legacy I haven't checked EPEL7 yet. On Mon, Apr 20, 2020 at 4:46 AM Fabio Valentini wrote: > > Hi everybody, > > I took over python-lockfile some time ago because it was FTBFS in > fedora / orphaned at the time, but it's a dependency of some of my > packages. > > However, I have zero interest in maintaining the EPEL branches of that > package, because I have no packages in EPEL myself, and it seems I > can't even figure out how to determine which EPEL packages require > python*-lockfile. > > I have received two PRs for the epel7 branch already, and I don't even > know if they're fine or not, so any help would be appreciated. > > If nobody steps up within the next two weeks, I will probably retire > the epel7 and epel8 branches of python-lockfile. > > 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 ___ 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
[EPEL-devel] Re: Playground policy
On Fri, May 1, 2020 at 10:49 AM Michel Alexandre Salim wrote: > > > > On 5/1/20 1:10 AM, Petr Pisar wrote: > > On Thu, Apr 30, 2020 at 12:32:26PM -0700, Michel Alexandre Salim wrote: > >> Generally speaking (I can make this a separate thread if that helps) - do > >> we > >> expect every package in EPEL8 to also be built for EPEL8-playground, either > >> through package.cfg or by building directly from the epel8-playground > >> branch? > > > > There is no such rule, but in my opinion, it is welcomed for exactly the > > terrible > > experience anybody gets when he tries to use epel8-playground. > > > Right, but if some package repos are missing packages.cfg and the > maintainer does not build it separately for epel8-playground, it is a > terrible experience for other packages depending on this missing package > -- everytime the maintainer submits an epel8 build, the epel8-playground > target will report a build failure. > > > The purpose of epel8-playground is to diverge when needed. That's why the > > epel8 > > branch contains package.cfg by default. > > > That seems to be the case for packages branched normally (fedpkg > request-branch). *However* I've seen some packages where the epel8 > branch and master branch are identical -- not sure how it happens, maybe > the committer has force-push permission? Or is there a way to request > that a branch be cloned from another branch instead of created from scratch? > I prefer my EPEL branches to be this way when possible. And it's simple enough to do fedpkg clone cd fedpkg switch-branch epel8 git merge master fedpkg push Nothing fancy about it, as long as you are the maintainer of the epel branch. Troy ___ epel-devel mailing list -- epel-de...@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-de...@lists.fedoraproject.org
[EPEL-devel] Re: Outstanding package requests for EPEL-8
All of the ones I've requested, I waited a few days to see if the
maintainer would pick it up. And after that I asked if they would
mind if I maintained it in EPEL8. About half of those the maintainer
was fine with me maintaining the package in EPEL8.
So, to answer your question, yes you can.
On Fri, Oct 25, 2019 at 6:49 AM Sérgio Basto wrote:
>
> I wonder if we can request the branch and be added as co-maintainer ?
>
>
> On Wed, 2019-10-23 at 13:38 -0400, Stephen John Smoogen wrote:
> > So this came up in the last EPEL meeting:
> > bugzilla query -s NEW -t 'epel8' --outputformat "%{id}:
> > %{component}:
> > %{summary}" | sort | less
> >
> >
> > Most of these are package requests but some are other types.
> >
> > 1739162: libxml++: libxml++ for EPEL8
> > 1739163: libffado: libffado for EPEL8
> > 1741523: mod_auth_cas: mod_auth_cas for EPEL8
> > 1741654: dash: RFE: dash for EPEL8
> > 1744341: jq: RFE: jq for EPEL8
> > 1744343: nagios-plugins-openmanage: RFE: nagios-plugins-openmanage
> > for EPEL8
> > 1744699: perl-Apache-LogFormat-Compiler: [RFE] EPEL8 branch of
> > perl-Apache-LogFormat-Compiler
> > 1744700: perl-Authen-Passphrase: [RFE] EPEL8 branch perl-Authen-
> > Passphrase
> > 1744704: perl-Authen-Simple-Passwd: [RFE] EPEL8 branch of
> > perl-Authen-Simple-Passwd
> > 1744705: perl-Authen-Passphrase: [RFE] EPEL8 branch of perl-Authen-
> > Simple
> > 1744712: perl-IO-Handle-Util: [RFE] EPEL8 branch for perl-IO-Handle-
> > Util
> > 1744782: perl-Crypt-SSLeay: (RFE) EPEL8 branch of perl-Crypt-SSLeay
> > 1744785: perl-Proc-Daemon: (RFE) EPEL8 branch of perl-Proc-Daemon
> > 1745727: apcupsd: [RFE] apcupsd: epel8 build request
> > 1749146: lxqt-session: Build LXQt in EPEL8
> > 1749780: genders: please build for epel8
> > 1750404: php-phpmailer6: [RFE] EPEL8 branch of php-phpmailer6
> > 1753203: weechat: Can you please make a package in EPEL8 with new
> > Weechat version?
> > 1753397: scons: Build for EPEL8
> > 1753401: perl-Class-Accessor-Lite: [RFE] EPEL8 branch of
> > perl-Class-Accessor-Lite
> > 1754155: quazip: Create EPEL8 branc
> > 1755034: python-passlib: [RFE] EPEL8 branch of python-passlib
> > 1755264: dnf-plugins-extras: Please release the snapper plug-in for
> > epel8 also.
> > 1755345: python-mysql: Request to build python3-mysql for EPEL8
> > 1755761: clementine: [RFE] : clementine : epel8 build request
> > 1755789: pidgin-otr: [RFE] : pidgin-otr epel8 build request
> > 1755791: powerline: [RFE] : powerline : epel8 build request
> > 1755793: autossh: [RFE] : autossh epel8 build request
> > 1755809: cross-binutils: [RFE] EPEL8 branch of cross-binutils
> > 1755816: simple-scan: [RFE] : simple-scan : epel8 build request
> > 1755945: bats: [RFE] bats: epel8 build request
> > 1755960: liblastfm: Please provide EPEL8 package
> > 1755963: libmygpo-qt: Please provide EPEL8 package
> > 1755964: libprojectM: Please provide EPEL8 package
> > 1755965: qca: Please provide EPEL8 package
> > 1755966: udisks: Please provide EPEL8 package
> > 1755968: sha2: Please provide EPEL8 package
> > 1755975: phonon: Please provide EPEL8 package
> > 1756036: perl-XML-TreePP: [RFE] perl-XML-TreePP build for epel8
> > 1756170: libcec: [RFE] libcec build for epel8
> > 1756171: perl-Net-UPnP: [RFE] perl-Net-UPnP build for epel8
> > 1756941: kid3: [RFE] : kid3 : epel8 build request
> > 1756942: pylast: [RFE] : pylast : epel8 build request
> > 1756976: gtk-murrine-engine: [RFE] : gtk-murrine-engine : epel8 build
> > request
> > 1757000: xmlstarlet: xmlstarlet missing in EPEL8
> > 1757002: docbook2X: docbook-utils-pdf missing in RHEL8/CentOS-8: need
> > it in EPEL8
> > 1757009: perl-Qt: perl-Qt 4.14.3 missing for EPEL8
> > 1757016: ntfsprogs: ntfsprogs is missing for EPEL8
> > 1757645: python-urlgrabber: [RFE] python3-urlgrabber build for epel8
> > 1757682: thunderbird-enigmail: [RFE] : thunderbird-enigmail : epel8
> > build request
> > 1757868: uboot-tools: Package uboot-tools is not available in EPEL8
> > 1758005: xlockmore: build xlockmore for epel8
> > 1758271: ipython: Branch request: python3-ipython for epel8
> > 1758311: nova-agent: build nova-agent for epel8
> > 1758329: python-requests-cache: [RFE] python-requests-cache for epel8
> > 1758340: python-oauth: [RFE] python-oauth build for epel8
> > 1758778: fmt: fmt not packaged for epel8
> > 1758779: xalan-c: xalan-c not packaged for epel8
> > 1758780: spdlog: spdlog not packaged for epel8
> > 1758822: python-funcsigs: [RFE] EPEL8 branch of python-funcsigs
> > 1759107: python-celery: Branch request: python-celery for epel8
> > 1759108: python-markdown2: Branch request: python-markdown2 for epel8
> > 1759109: python-aiohttp: Branch request: python-aiohttp for epel8
> > 1759112: python-requests-mock: Branch request: python-requests-mock
> > for epel8
> > 1759114: python-cached_property: Branch request:
> > python-cached_property for epel8
> > 1759116: python-xmlsec: Branch request: python-xmlsec for epel8
> > 1759121: python-zeep: Branch request: python-zeep for epel8
[EPEL-devel] Re: giflib-devel
giflib-devel is a sub-package of giflib. It is already in RHEL8 and Centos8, just not in the BaseOS or AppStream repo's. For CentOS 8 it is in the PowerTools repo dnf config-manager --enable PowerTools On Fri, Oct 25, 2019 at 1:29 PM Mateo wrote: > > Hi EPEL developers. > > I am using Centos 8 and am using various packages in the EPEL > repository. I am interested in seeing giflib-devel added to EPEL 8. > > I have approached the current Fedora maintainer (Sandro Mani) and they are not > interested in maintaining the package in EPEL. Are there any EPEL > maintainers who are interested in doing so? > > Thank you > > > ___ > epel-devel mailing list -- epel-de...@lists.fedoraproject.org > To unsubscribe send an email to epel-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/epel-de...@lists.fedoraproject.org ___ epel-devel mailing list -- epel-de...@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-de...@lists.fedoraproject.org
Introducing Square 1
I would like to introduce a plan I call Square 1 [1][2] There are two goals to Square 1. The first is to get, and keep, the core buildroot[3] packages, self-hosting[4]. The second is to get the list of core buildroot packages as small as possible. What are the benefits to Square 1? More stable release and less failed builds. If we are able to shrink binaries, faster koji builds. Smoother initial creation of RHEL 9.[5] What are the milestones to get these benefits? - Get initial list of "core binaries" - write/find software that will find binary/source dependencies - write/find software that will track binary/source dependencies - write/find/setup automation that finds and tracks binary/source dependencies, so people can easily see what has changed over time. - work with package maintainers to trim down binary/source dependencies -- trimming out "extra" package languages. (ex: perl for a minor script, when everything is in python.) -- trimming functionality and/or moving functionality to sub-packages or separate package. - integrate these tests into the rawhide gating system, to alert when new dependencies have been added. Much of this work overlaps with the Fedora Minimization efforts.[6] Square 1 hopes to utilize, rather than duplicate, their efforts. And maybe some tools created for Square 1 can help the minimization efforts. Thoughts? Ideas? Comments? Troy Dawson [1] - Square 1 is at the heart of Ring Zero [2] - This has nothing to do with the company or software with a similar sounding name. [3] - The core buildroot is the packages in @buildsys-build, and everything needed to build those packages. [4] - self-hosting is the ability to build all the packages on themselves. [5] - Yep, I said it. We're already looking at RHEL 9. [6] - https://docs.fedoraproject.org/en-US/minimization/ ___ 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: Introducing Square 1
On Mon, Oct 28, 2019 at 2:58 PM Peter Robinson wrote: > > On Mon, Oct 28, 2019 at 8:00 PM Troy Dawson wrote: > > > > I would like to introduce a plan I call Square 1 [1][2] > > > > There are two goals to Square 1. > > The first is to get, and keep, the core buildroot[3] packages, > > self-hosting[4]. > > The second is to get the list of core buildroot packages as small as > > possible. > > Why can't this be done as part of the minimisation objective? To have > yet another project with another name and another focus and set of > tools just appears to be a little bizarre > I'd love for it to fold into the Minimization project. That project has a better name, and Adam is much more familiar with getting things done properly in Fedora. Currently, the Minimization project is geared towards only binaries, and not the source dependencies. It is still getting setup and on it's feet. I'm worried that throwing source and dependency tree's at it will knock it down before Minimizations infrastructure is in place. But, I'm looking at when we need to get started for RHEL9, and I've seen how slow things can take when dealing with Fedora dependencies, and it has me concerned. I'd like to get the discussion started now, so hopefully we have some things figured out and possibly working by the time it is needed. Is the name confusing? Yep. But Square1 is all I could think of at the time. Can/Should this be merged into Minimization? Yes, that is my hope. Or, at least a good part of it get's merged in there. Eventually. > > What are the benefits to Square 1? > > More stable release and less failed builds. > > If we are able to shrink binaries, faster koji builds. > > Smoother initial creation of RHEL 9.[5] > > > > What are the milestones to get these benefits? > > - Get initial list of "core binaries" > > - write/find software that will find binary/source dependencies I've been looking at the dnf plugins, specifically builddep. If we can get that to be recursive, that would help tremendously. Looking at the plugins, we should also be able to help the Minimization project get their list of packages in a usable format. Currently they are installing all their packages (I believe in a container), and then grabbing the rpm database from that. I think we should be able to make a plugin that generates the list of packages that would be installed, and instead of installing them, generates an repo and/or rpm database. > > - write/find software that will track binary/source dependencies > > - write/find/setup automation that finds and tracks binary/source > > dependencies, so people can easily see what has changed over time. > > - work with package maintainers to trim down binary/source dependencies > > -- trimming out "extra" package languages. (ex: perl for a > > minor script, when everything is in python.) > > -- trimming functionality and/or moving functionality to sub-packages > > or separate package. > > - integrate these tests into the rawhide gating system, to alert when > > new dependencies have been added. > > > > Much of this work overlaps with the Fedora Minimization efforts.[6] > > Square 1 hopes to utilize, rather than duplicate, their efforts. And > > maybe some tools created for Square 1 can help the minimization > > efforts. > > > > Thoughts? > > Ideas? > > Comments? > > > > Troy Dawson > > > > [1] - Square 1 is at the heart of Ring Zero > > [2] - This has nothing to do with the company or software with a > > similar sounding name. > > [3] - The core buildroot is the packages in @buildsys-build, and > > everything needed to build those packages. > > [4] - self-hosting is the ability to build all the packages on themselves. > > [5] - Yep, I said it. We're already looking at RHEL 9. > > [6] - https://docs.fedoraproject.org/en-US/minimization/ ___ 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: Introducing Square 1
I have, and that works fairly well. Although I haven't tried it since F29. I was hoping to have something that works with dnf, and can even be part of an rpm, so others can easily use it. There are some drawbacks to using regular dnf, especially the multi-arch. By the time you get all the source rpm repo's ready for muilti-arch, you might as well use depchase. But it would also be nice for users to be able to quickly check all the build dependencies on their own machine (or virtual machine). On Tue, Oct 29, 2019 at 7:54 AM Igor Gnatenko wrote: > > Have you tried using https://github.com/fedora-modularity/depchase? > That basically does what you are doing and with some small changes it > can perform much more things. > > On Tue, Oct 29, 2019 at 3:27 PM Troy Dawson wrote: > > > > On Mon, Oct 28, 2019 at 2:58 PM Peter Robinson wrote: > > > > > > On Mon, Oct 28, 2019 at 8:00 PM Troy Dawson wrote: > > > > > > > > I would like to introduce a plan I call Square 1 [1][2] > > > > > > > > There are two goals to Square 1. > > > > The first is to get, and keep, the core buildroot[3] packages, > > > > self-hosting[4]. > > > > The second is to get the list of core buildroot packages as small as > > > > possible. > > > > > > Why can't this be done as part of the minimisation objective? To have > > > yet another project with another name and another focus and set of > > > tools just appears to be a little bizarre > > > > > > > I'd love for it to fold into the Minimization project. > > That project has a better name, and Adam is much more familiar with > > getting things done properly in Fedora. > > Currently, the Minimization project is geared towards only binaries, > > and not the source dependencies. It is still getting setup and on > > it's feet. I'm worried that throwing source and dependency tree's at > > it will knock it down before Minimizations infrastructure is in place. > > > > But, I'm looking at when we need to get started for RHEL9, and I've > > seen how slow things can take when dealing with Fedora dependencies, > > and it has me concerned. I'd like to get the discussion started now, > > so hopefully we have some things figured out and possibly working by > > the time it is needed. > > > > Is the name confusing? Yep. But Square1 is all I could think of at the > > time. > > Can/Should this be merged into Minimization? Yes, that is my hope. > > Or, at least a good part of it get's merged in there. Eventually. > > > > > > What are the benefits to Square 1? > > > > More stable release and less failed builds. > > > > If we are able to shrink binaries, faster koji builds. > > > > Smoother initial creation of RHEL 9.[5] > > > > > > > > What are the milestones to get these benefits? > > > > - Get initial list of "core binaries" > > > > - write/find software that will find binary/source dependencies > > > > I've been looking at the dnf plugins, specifically builddep. > > If we can get that to be recursive, that would help tremendously. > > > > Looking at the plugins, we should also be able to help the > > Minimization project get their list of packages in a usable format. > > Currently they are installing all their packages (I believe in a > > container), and then grabbing the rpm database from that. I think we > > should be able to make a plugin that generates the list of packages > > that would be installed, and instead of installing them, generates an > > repo and/or rpm database. > > > > > > - write/find software that will track binary/source dependencies > > > > - write/find/setup automation that finds and tracks binary/source > > > > dependencies, so people can easily see what has changed over time. > > > > - work with package maintainers to trim down binary/source dependencies > > > > -- trimming out "extra" package languages. (ex: perl for a > > > > minor script, when everything is in python.) > > > > -- trimming functionality and/or moving functionality to sub-packages > > > > or separate package. > > > > - integrate these tests into the rawhide gating system, to alert when > > > > new dependencies have been added. > > > > > > > > Much of this work overlaps with the Fedora Minimization efforts.[6] > > > > Square 1 hopes to utilize, rather than d
Re: Join the new Minimization Team
On Tue, Jul 30, 2019 at 7:58 AM Adam Samalik wrote: > > Hi everyone! > > I'm starting a Minimization Objective [1] focusing on minimising the > installation size of some of the popular apps, runtimes, and other pieces of > software in Fedora. > > And there is a new Minimization Team [2] forming. Members of the team will > consult and work with Fedora maintainers, develop tooling and services, > generate reports showing the status of the Fedora ecosystem and a comparison > with other ecosystems, etc. The goal is to build an environment where it's > easy for our maintainers to keep things small over time, it's not just a > one-off effort. Please see the Action Plan [3] for more details. > > Want to become a member? Let me know! > > Cheers! > Adam > > [1] https://docs.fedoraproject.org/en-US/minimization/ > [2] https://docs.fedoraproject.org/en-US/minimization/team/ > [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/ > Hi Adam, Please put me on the list of people who would like to be on the team. I'm not sure how Paul would feel about me working on the minimization efforts (I'm currently doing EPEL stuff), but I feel it would fit in with my RHEL9 and Fedora IoT efforts. Plus, I'm always trying to get installs and systems as small as possible. Troy Dawson ___ 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: [EPEL-devel] Re: Pidgin on EPEL8
On Wed, Aug 7, 2019 at 8:44 AM Pablo Sebastián Greco
wrote:
>
>
> El 7/8/19 a las 12:30, Stephen John Smoogen escribió:
>
>
>
> On Wed, 7 Aug 2019 at 10:52, Vitaly Zaitsev via devel
> wrote:
>>
>> Hello all.
>>
>> While building my Fedora packages for EPEL8, got a very strange error on
>> aarch64 and s390x architectures:
>>
>> No matching package to install: 'pkgconfig(pidgin)'
>>
>> But it builds fine with the same SPEC on x86_64 and ppc64le.
>>
>
> OK so it turns out that RHEL-8 is NOT 1:1 across platforms. For some reason
> desktop is only on x86_64 and ppc64le and s390/aarch64 are a more limited set
> of packages. I don't know if this was the case with the beta's and I missed
> it or if this was something done between the beta and the final.
>
> At this point, i am going to say that ExclusiveArch:x86_64,ppc64le will be
> needed for most desktop/graphical utilities.
>
> Smooge, can we ask to add %{arm} to those ExclusiveArch?
> O in fact, go the ExcludeArch route?
>
> That will do my armhfp rebuild much simpler.
>
I don't think Smooge was saying that EPEL8 would have a build policy
for ExclusiveArch, he was meaning that package maintainers would need
to put that in their spec file.
Ahh and now I see what you mean. You are asking the package
maintainers to put %{arm} in.
OK, I just put it on the packages I have been working on.
Also, here is the EPEL issue about this problem
https://pagure.io/epel/issue/66
And the Beta was the same way as this. But I personally, never tested
the desktop on s390x or aarch64. So I never noticed.
Troy
___
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: Missing arches on EPEL 8 for LibRaw?
On Fri, Aug 16, 2019 at 12:40 AM Vitaly Zaitsev via devel wrote: > > On 16.08.2019 6:22, Richard Shaw wrote: > > I assume this is because LibRaw is available in RHEL but only for x86_64 > > and ppc64le? > > The same as Pidgin and lots of other apps/libs. You need to add > "ExclusiveArch: x86_64 ppc64le" in order to build your package successfully. > This has been reported in the EPEL issues https://pagure.io/epel/issue/66 (Graphical Libraries/Desktop missing from RHEL8 aarch64 and s390x) I like the issue because it has a full list of the packages that are only available on x86_64 and ppc64le. Besides the full list of packages, I think the next important is the comment "I have been told that the RHEL team is aware of this problem, and have several bugs open because of it. I have also been told that it will not be fixed in RHEL 8.1. Let's hope for RHEL 8.2." So, yes, do the ExclusiveArch, but keep in the back of your mind that this is only needed temporarily ... hopefully. Troy ___ 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
systemd-sysusers versus containers
systemd-sysusers seeks to unify user creation[1]. It also has the benefit of being able to create users on bootup. But, it pulls in the entire systemd infrastructure with all it's dependencies. containers do not need systemd to run. They are trying to be as small as possible. But if a package in container needs to add a user, then systemd is pulled in and that container grows by up to 60M.[2] Minimizing containers, both in the short term and long term, are important to the minimization team. We have opened an issue for this.[3] Any ideas on what we recommend to users? Troy Dawson [1] - https://pagure.io/packaging-committee/issue/442 [2] - The amount a container grows when systemd is added depends on how many of the systemd dependencies are needed by the main container packages. As of F31, if they need none of these dependency packages, then a container grows by 60M by adding systemd. [3] - https://pagure.io/minimization/issue/13 ___ 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: systemd-sysusers versus containers
On Tue, Sep 17, 2019 at 10:34 AM Daniel Walsh wrote: > > On 9/17/19 8:04 AM, Colin Walters wrote: > > > > On Mon, Sep 16, 2019, at 12:45 PM, Troy Dawson wrote: > >> systemd-sysusers seeks to unify user creation[1]. It also has the > >> benefit of being able to create users on bootup. But, it pulls in the > >> entire systemd infrastructure with all it's dependencies. > >> > >> containers do not need systemd to run. They are trying to be as small > >> as possible. But if a package in container needs to add a user, then > >> systemd is pulled in and that container grows by up to 60M.[2] > >> > >> Minimizing containers, both in the short term and long term, are > >> important to the minimization team. We have opened an issue for > >> this.[3] > > As I said in the big thread, what we should aim to minimize is containers > > built via multi-stage build; nothing else is going to be small. > > > > The user ID is a very interesting topic...bigger picture for example, > > OpenShift defaults to the `MustRunAsRange` SCC[1] - ensuring a uid is > > dynamically allocated for the container. So the `useradd` and `sysusers` > > stuff isn't relevant. > > (We have a longstanding issue though that the uid isn't in the passwd > > database but I think podman is growing some code to fix that) > Podman and CRI-O handle this now, by adding the runasuser to the > /etc/passwd inside of the container, if it does not exists. > > > > For non-Kubernetes systems (e.g. installing RPMs on a host) - I think in a > > lot of cases, using systemd dynamic users is best: > > http://0pointer.net/blog/dynamic-users-with-systemd.html > > Where possible - using it for e.g. postgres would probably be somewhat of a > > surprise for admins. > > > > It'd be useful in this discussion to look at particular containers - I'm > > guessing it's things like nginx and postgres where we want to ship both an > > RPM and a container image? And where things intersect here is whether or > > not the RPM depends on systemd. Maybe the least bad thing is to introduce > > a `systemd-container-stub` package that is empty except for Provides? > > Dunno...it's messy. > > > > A whole lot of service software is container-only - it doesn't make sense > > to make RPMs for them, which sidesteps a lot of this. > > > > [1] > > https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#security-context-constraints One of the comments in the ticket was to try pulling out systemd-sysusers into it's own sub-package. systemd-sysusers requires libsystemd-shared Pulling libsystemd-shared into it's own sub-package shows that it requires cryptsetup-libs which sets up a circular dependency back to systemd. After many attempts, just using rpm packaging techniques, I have been unsuccessful in breaking the circular dependency. The only way I can see to do it is either remove some functionality, or do some type of re-writting of code in systemd and/or one of the packages in the circular dependency. The "systemd-container-stub" is looking more and more like the way to go. Troy ___ 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: Defining the future of the packager workflow in Fedora
On Thu, Sep 26, 2019 at 6:11 AM Pierre-Yves Chibon wrote: > > On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote: > > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit : > > > Here is what the vision we came to and that we would like to discuss: > > > > > > ○ Every changes to dist-git is done via pull-requests > > > > IMHO Have to stay optional, making this mandatory being a terrible headache. > > What makes it a headache? What can we do to not have this be a terrible > headache? Can we fix/improve the tooling? > > Note: this is the long term vision, as we move towards it things will be > optional: opt-in, then (maybe) opt-out, then (if we want to) mandatory. > There has to be an easier way to do pull requests. And maybe there is, I'm not a git expert. My biggest concern that I see isn't for my own packages, but as a proven packager, there are times I need to "group change" things. An example is that I recently helped with the EPEL 7 python34 -> python36 changeover. This required changing alot of packages. For the sake of simplicity, we'll say it's 100. I now have to fork 100 packages. Download those 100 git repo's. And for each of those packages I have to then create my fork pull-request branch. After that, the steps wouldn't be too different. I would make my changes, commit and push. I would then have to create the pull request (I currently don't know how to do that from the command line), wait for the testing, get the pull request pulled, and from there it's the same. For me, it's those first three steps that are the headache. Especially with having to fork the repo. I look at that and think that it's a waste of space, on both my machine, as well as the server machines. If there was a better, easier way of creating the pull request, then it wouldn't be a headache for me. Troy ___ 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: Defining the future of the packager workflow in Fedora
On Thu, Sep 26, 2019 at 6:56 AM Pierre-Yves Chibon wrote: > > On Thu, Sep 26, 2019 at 06:38:45AM -0700, Troy Dawson wrote: > > On Thu, Sep 26, 2019 at 6:11 AM Pierre-Yves Chibon > > wrote: > > > > > > On Thu, Sep 26, 2019 at 03:01:25PM +0200, Remi Collet wrote: > > > > Le 26/09/2019 à 11:36, Pierre-Yves Chibon a écrit : > > > > > Here is what the vision we came to and that we would like to discuss: > > > > > > > > > > ○ Every changes to dist-git is done via pull-requests > > > > > > > > IMHO Have to stay optional, making this mandatory being a terrible > > > > headache. > > > > > > What makes it a headache? What can we do to not have this be a terrible > > > headache? Can we fix/improve the tooling? > > > > > > Note: this is the long term vision, as we move towards it things will be > > > optional: opt-in, then (maybe) opt-out, then (if we want to) mandatory. > > > > > > > There has to be an easier way to do pull requests. And maybe there > > is, I'm not a git expert. > > My biggest concern that I see isn't for my own packages, but as a > > proven packager, there are times I need to "group change" things. An > > example is that I recently helped with the EPEL 7 python34 -> python36 > > changeover. This required changing alot of packages. For the sake of > > simplicity, we'll say it's 100. > > I now have to fork 100 packages. > > Download those 100 git repo's. > > And for each of those packages I have to then create my fork > > pull-request branch. > > After that, the steps wouldn't be too different. I would make my > > changes, commit and push. > > I would then have to create the pull request (I currently don't know > > how to do that from the command line), wait for the testing, get the > > pull request pulled, and from there it's the same. > > > > For me, it's those first three steps that are the headache. > > Especially with having to fork the repo. I look at that and think > > that it's a waste of space, on both my machine, as well as the server > > machines. > > > > If there was a better, easier way of creating the pull request, then > > it wouldn't be a headache for me. > > All what you are describing here should be achievable with some tooling. > I mean, we could have all the magic be in `fedpkg push` which suddenly, checks > if you have a clone, it not creates it, adds it as a remote to your git repo > and > do the git push to that remote. We could then have a `fedpkg new-pr` to create > the PR or even a `fedpkg push --pr` to do both actions in one step :) > > Would that make it less of a headache? > Yes, if we can achieve that, then that would be good for me. I personally would like to have my pushes checked in some way. And if this achieves that, then I would like to see it. Troy ___ 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: Defining the future of the packager workflow in Fedora
On Thu, Sep 26, 2019 at 10:48 AM Robbie Harwood wrote: > > Pierre-Yves Chibon writes: > > > Here is what the vision we came to and that we would like to discuss: > > > > ○ Every changes to dist-git is done via pull-requests > > ○ Pull-requests are automatically tested > > ○ Every commit to dist-git (ie: PR merged) is automatically built in koji > > ○ Every build in koji results automatically in an update in bodhi > > ○ Every update in bodhi is automatically tested > > ○ If the tests pass, the update is automatically pushed to the repository > > I have a *lot* of objections to this workflow, but maybe it'd be better > to take a step back. > > Instead of trying to create a new workflow, why are you not starting > with defining what we have now? And if there are problems with it that > need to be addressed, what are they and why do they motivate these > changes to you? > I'd like to second this question. What are the problems with our current workflows? At the beginning of this message you said there were several packaging initiatives being worked on, but for those of us that didn't go to Flock, we don't know what those are. Basically, we (those not in the room with you) are starting here on earth, while you are talking about how to properly breath while on the moon. There is alot of disconnect between where we are and what you are talking about. ___ 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: Announcement: EPEL Steering Committee Changes
On Tue, Feb 18, 2020 at 9:36 AM Stephen John Smoogen wrote: > > Hi, > > It has been a pleasure for me to be a part of and help lead the > EPEL steering committee for the last couple of years. It has not > always been smooth sailing but I have found it an enjoyable experience. > > However, as you may know the Fedora project will be moving to a > different data-center later this spring (from Phoenix to northern > Virginia). Being involved in the planning and implementation of this > project, I do not think that I will be able to give EPEL the time > investment it deserve for the next 6 to 9 months. With EPEL-8 still > ramping up and the various opportunities with modularity, I do > not think it is a fair that EPEL suffers from this lack of time. > > As such, I would like to step down as chair/member of the steering > committee and nominate Troy Dawson as my replacement. Troy formerly > worked on Scientific Linux and has worked on OpenShift and other > projects at Red Hat for the last several years. It is clear he has a > good eye on the concerns and problems enterprise users have. Recently, > Troy helped get the initial RHEL-8 and EPEL-8 out the door with > multiple builds and updates to various macro files. > > Once the move is completed and the close down of the old site is done, > I look forward to getting involved again in EPEL. Thank you Stephen for all that you've done for the EPEL community the past several years. I hope the move goes smooth so that you can return to us sooner, rather than later. I will do my best to keep EPEL steering in the right direction. Troy ___ 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 ELN Plans for Summer 2023
On Fri, Jun 16, 2023 at 6:42 AM Stephen Gallagher wrote: > == Open Questions == > 1) For the "canary" Fedora ELN rebuild, we have two choices on how to > select the git hash to be built for each package in the ELN list: > > Approach 1 (Rawhide-style): > 1. Clone each package > 2. Check for the existence of the `eln` branch. > a. If the `eln` branch exists, build from the HEAD of that branch > into the side-tag. > b. Otherwise, build from the HEAD of the `rawhide` branch into the > side-tag. > > Approach 2 (Conservative-style): > 1. Query Koji for the latest-tagged build of each package in Fedora ELN > 2. Interrogate the build task of that build for the git hash > 3. Build that git hash into the side-tag. > > Approach 2 is more heavyweight, relying on a lot of Koji queries > back-and-forth, whereas Approach 1 will pick up changes that have > appeared in Rawhide since the last build (which is more in line with > how Fedora's mass-rebuilds work). I'm personally leaning towards > Approach 2, but I'm open to good arguments either way. > Sorry for being late with this, but I thought I'd already sent this. I'd like to go with Approach 2 (Conservative-style) I've got a python script that grabs the githash for various builds. Although the initial run takes a couple of hours, after that it's fairly quick. It would make it possible to build using the ELN build source githash. In the long run, I believe it takes less time to get the githash rather than pulling down the git repos. It's also something the can be pre-staged, then just run the script right before you run the mass rebuild, to get the latest. Troy ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora 40 Mass Rebuild *finish* delayed
On Wed, Jan 24, 2024 at 2:01 AM Miroslav Suchý wrote: > Dne 24. 01. 24 v 10:51 Aoife Moloney napsal(a): > > > > All other milestones remain the same at this time and the published > schedule[4] has been updated to reflect these changes. > > https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html > > Branching is set to 2024-02-06 while mass rebuilds are supposed to finish > by 2024-02-20. That means we will branch > during mass rebuilds? > > Historically we always branched *after* the mass rebuilds finishes. > The proposal that passed was this. "Delay the F40 schedule 1 week for everything up to and including the start of the Beta Freeze" Branching falls into the list of tasks that is affected by one week. Although they didn't change the schedule yet (and you aren't the first to notice that) it has been pushed back a week. So branching *should* be 2024-02-13 Troy -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: ELN build failures
On Wed, Nov 2, 2022 at 6:42 AM Stephen Gallagher wrote: > > > On Wed, Nov 2, 2022 at 12:26 AM Benson Muite > wrote: > >> If there is a build failure for a package on ELN, does anything need to >> be added to a package spec file? Currently > > > It varies wildly from package to package. Sometimes things can be handled > with a spec file conditional, other times it may be more complicated (like > the compiler flags for RHEL are revealing a coding bug that the Fedora > flags happen to miss or optimize out). > > > > reviewing a package where >> there is a missing dependency, but helpful to also > > > A new package review shouldn’t be expected to build on ELN, and failing to > do so shouldn’t block the review, in general. (Exception: a new package > that is Obsoleting a package currently in ELN might need special handling). > > know if anything >> should be done in general. The documentation at [0] is not clear on >> this. Unclear also if ExcludeArch: ELN with a comment for the reason >> for build failures on ELN would be a useful thing to have in new spec >> files. > > > ELN is not an arch, so that would have no effect whatsoever. ELN already > only rebuilds packages that are needed by RHEL 10 or ELN-Extras packages. > See https://tiny.distro.builders for the list. > Stephen is correct, ELN is not an arch, but there are some packages that do not build on all arches of ELN but do in rawhide. The biggest one is golang. What package(s) are you having problems with? Troy ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: ELN build failures
On Wed, Nov 2, 2022 at 8:23 AM Troy Dawson wrote:
> On Wed, Nov 2, 2022 at 6:42 AM Stephen Gallagher
> wrote:
>
>>
>>
>> On Wed, Nov 2, 2022 at 12:26 AM Benson Muite
>> wrote:
>>
>>> If there is a build failure for a package on ELN, does anything need to
>>> be added to a package spec file? Currently
>>
>>
>> It varies wildly from package to package. Sometimes things can be handled
>> with a spec file conditional, other times it may be more complicated (like
>> the compiler flags for RHEL are revealing a coding bug that the Fedora
>> flags happen to miss or optimize out).
>>
>>
>>
>> reviewing a package where
>>> there is a missing dependency, but helpful to also
>>
>>
>> A new package review shouldn’t be expected to build on ELN, and failing
>> to do so shouldn’t block the review, in general. (Exception: a new package
>> that is Obsoleting a package currently in ELN might need special handling).
>>
>> know if anything
>>> should be done in general. The documentation at [0] is not clear on
>>> this. Unclear also if ExcludeArch: ELN with a comment for the reason
>>> for build failures on ELN would be a useful thing to have in new spec
>>> files.
>>
>>
>> ELN is not an arch, so that would have no effect whatsoever. ELN already
>> only rebuilds packages that are needed by RHEL 10 or ELN-Extras packages.
>> See https://tiny.distro.builders for the list.
>>
>
> Stephen is correct, ELN is not an arch, but there are some packages that
> do not build on all arches of ELN but do in rawhide.
> The biggest one is golang.
>
>
I should have put this in the email.
If your package needs any golang package to build you should put in
ExclusiveArch: %{golang_arches}
What package(s) are you having problems with?
>
> Troy
>
>
___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: ELN build failures
On Wed, Nov 2, 2022 at 10:05 AM Sergey Mende wrote: > > On Wed, Nov 2, 2022 at 8:23 AM Troy Dawson wrote: > > What package(s) are you having problems with? > Troy, > > the package in question is libClipper2 [0] that undergoes the review > presently. It is not go-related. It requires the Google Test that is > unavailable in ELN. It is not really a goal to make it included into ELN: > initially the ELN builds were enabled in COPR and then started to fail > after unbundling Google Test. So, the question arose if there is a need or > a way to mark a package as presently incompatible with a distribution apart > from putting a plain comment into the spec. > > Thank you, > Sergey > [0] https://bugzilla.redhat.com/show_bug.cgi?id=2130903 > Lets take a step back. Packages are only built for ELN if 1 - They are specifically requested by the RHEL teams to be in the next RHEL release or 2 - They are a direct runtime or build dependency of anything in (1) If you are not expecting a new package to be in ELN, then it most likely won't be. Having a package build on ELN should not be part of a Fedora package review. If it has become part of it, then we need to review the process. I'm not sure why copr was building for ELN. I know copr *can* build for ELN, but it shouldn't be automatic. In short, don't worry about the failed copr ELN builds. Just make sure your package builds and is packaged correctly for Fedora Rawhide. Troy ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Python3 will be in next major RHEL release, please adjust %if statements accordingly
Hello,
Python3 will be in the next major RHEL release. I don't mean RHEL
7.6, but with numbers higher than 7.
There are many, many packages with something like the following
if 0%{?fedora}
%define with_python3 1
%endif
If you have something like that, please change it to something like this.
if 0%{?fedora} || 0%{?rhel} > 7
%define with_python3 1
%endif
Thank You
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Python3 will be in next major RHEL release, please adjust %if statements accordingly
On Thu, Jan 11, 2018 at 11:55 PM, Panu Matilainen wrote:
> On 01/12/2018 06:08 AM, Luya Tshimbalanga wrote:
>>
>> On 2018-01-11 01:02 PM, Troy Dawson wrote:
>>>
>>> Hello,
>>> Python3 will be in the next major RHEL release. I don't mean RHEL
>>> 7.6, but with numbers higher than 7.
>>> There are many, many packages with something like the following
>>>
>>>if 0%{?fedora}
>>> %define with_python3 1
>>>%endif
>>>
>>> If you have something like that, please change it to something like this.
>>>
>>>if 0%{?fedora} || 0%{?rhel} > 7
>>> %define with_python3 1
>>>%endif
>>>
>>> Thank You
>>> ___
>>
>>
>> Quick question: why not using %global rather than %define ?
>>
>
> Probably old habit from times before %define got unnecessarily demonized
> within Fedora. FWIW, both achieve exactly the same thing in this context.
>
When writing this email I grabbed the last package that I looked at.
There is a wide variety of these %if statements, ranging from %define
and %global, and different ways of setting "with_python3", to putting
the %if statement around each python3 part of the spec file.
Because of this wide variety, it would be difficult to script a
rewrite of spec files.
Troy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On Wed, Dec 9, 2020 at 11:52 AM James Cassell wrote: > > > > On Wed, Dec 9, 2020, at 1:44 PM, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault > > > > == Summary == > > > > For Nodejs, Fedora should only package: > > * The interpreter, development headers/libraries, and the assorted > > tools to manage project-level installations (NPM, yarn, etc.). > > * Packages that provide binaries that users would want to use in their > > shell. > > * compiled/binary nodejs modules (for now) > > > > Better title would have been, "bundle all nodejs dependencies into binary > packages requiring them". > Yes ... that does sound better. Naming is hard. > It feels contrary to the Minimization Objective. Is there really no better > solution? Can modularity help here? Better packaging macros? > To me this sounds exactly in line with the Minimization Objective. It can get rid of potentially 700 Fedora packages. Minimizing the number of packages needed to be installed as well as being built with. > Is there really no better solution? Not that we've found. This isn't an off the cuff proposal, it was months of discussion on mailling lists and off. To be honest, this is really years in the making. macros and scripts were tried for years, making them better and better in hopes that it would ease the problem. When things finally started falling apart, we really could say we'd tried all we could, but nothing was sustainable. > Can modularity help here? Better packaging macros? No, and No > How will licensing of dependencies be verified? Unlike most other languages, nodejs libraries contain a License field in their package.json. A simple 'find' script can get the licenses of your bundled packages. Run that each time you update your package, putting the output in your License: line of your spec. > What happens when a project adds new dependencies? Re-run your bundling script. You should re-run it every time you do any update, pulling in the correct and often updated nodejs libraries for your package. Troy ___ 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 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On Wed, Dec 9, 2020 at 11:21 AM Miro Hrončok wrote: > > On 12/9/20 7:44 PM, Ben Cotton wrote: > > == How To Test == > > > > * Install all nodejs libraries in Fedora 33. Try to update to Fedora 34. > > What is the plan wrt Obsoletes of the removed packages? > > -- > Miro Hrončok > -- We do not plan on obsoleting them. Obsoleting them has the potential to break third party software. dnf should also clean things up by seeing that the dependencies of an upgraded package have gone away. If dnf misses it, these are libraries, not binaries. If nothing is using them, they just take up some disk space. If a user really wants to clean them up, those types of users usually have their favorite ways of doing so. Troy ___ 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 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On Thu, Dec 10, 2020 at 2:07 AM Dominik 'Rathann' Mierzejewski wrote: > > On Thursday, 10 December 2020 at 00:49, Miro Hrončok wrote: > > On 12/9/20 7:44 PM, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault > > > > > > ... > > > * Policies and guidelines: N/A (not a System Wide Change) > > > > Should there be an update of: > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/JavaScript/ > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/ > > > > ? > > Same question. I wanted to try packaging web-ext and even started a list > of required dependencies[1]. What do I do now if NodeJS ecosystem is > going away? This feels like a total failure of distro packaging > principles. > > [1] https://fedoraproject.org/wiki/Web-ext > > Regards, > Dominik You do just what we say, you bundle those nodejs libraries, instead of using nodejs- packages. For you, that saves you having to make at least 45 new nodejs library packages. But, the reality is closer to 500 packages once you add in all the runtime and build-time dependencies. If you don't already have one, we have a script that makes the bundling easier. I've been using this one. https://github.com/tdawson/tdawson-misc-scripts/tree/master/npm-bundler It still needs a few tweeks, but it does the bundling part just fine. I ran that script for web-ext and it took about 10 minutes. Think of how much time you've already spent looking up what packages are in Fedora, and how many months it would take to get all the nodejs library packages made, and reviewed. It once took me over a year to get a nodejs based package in. Troy ___ 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 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On Fri, Dec 11, 2020 at 3:18 AM Till Maas wrote: > > Hi, > > this does not seem to be self-contained, since it seems to affect people > outside the SIG (it states that this is also affecting packages that are > not owned by the SIG). > > On Wed, Dec 09, 2020 at 01:44:30PM -0500, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault > > > > == Summary == > > > > For Nodejs, Fedora should only package: > > * The interpreter, development headers/libraries, and the assorted > > tools to manage project-level installations (NPM, yarn, etc.). > > * Packages that provide binaries that users would want to use in their > > shell. > > * compiled/binary nodejs modules (for now) > > > > == Owner == > > > > * Name: [[User:tdawson| Troy Dawson]] > > * Email: tdaw...@redhat.com > > * Name: [[User:sgallagh| Stephen Gallagher]] > > * Email: sgall...@redhat.com > > * Name: > > [[https://developer.fedoraproject.org/tech/languages/nodejs/SIG.html| > > Nodejs SIG]] > > * Email: nod...@lists.fedoraproject.org > > > > > > == Detailed Description == > > > > The nodejs libraries have been approved to be bundled, and there is > > infrastructure in place for the bundling to work properly. Currently, > > What does this infrastructure look like? How does it help with > addressing security issues in the bundles components effectivly? > > > it is recommended that packagers should create individual nodejs > > library packages instead of bundling all of the libraries into the > > package requiring them. > > The subject says "Stop Shipping Individual Nodejs Library Packages", > therefore it would be more clear to block all Nodejs libraries in Fedora > instead of only recommending this. Otherwise it will be some half-baked > solution that is probably confusing (Why are some libraries packaged and > others bundled?). > > > This change is to make it default to bundle the nodejs libraries with > > the package that needs them, and retire the vast majority of nodejs > > library packages. > > In summary, for Nodejs Fedora should only package: > > * The interpreter, development headers/libraries, and the assorted > > tools to manage project-level installations (NPM, yarn, etc.). > > * Packages that provide binaries that users would want to use in their > > shell. > > * compiled/binary nodejs modules (for now) > > This should also include the tooling that is needed to manage the > bundling. > > > > == Feedback == > > > > There has been a discussion on the fedora nodejs mailing list about > > what to do with the extreme dependency problem of the nodejs library > > packages. Because of the extreme inter-dependency, upgrading almost > > any package causes others to break. It has caused most packages to > > rot, remaining on unsupported versions for years. Many of the nodejs > > packagers are giving up and orphaning their packages, which has caused > > even more problems. > > > > An initial proposal was to find all of the important nodejs library > > packages and bundle those, making them easier to upgrade and maintain. > > But there was problems with figuring out what was important, and what > > versions should those have. During that discussion, this rather > > extreme solution of getting rid of all nodejs libraries was proposed. > > To our surprise, it has been the best received suggestion and fixes > > the most problems. > > What problems remain? > > > > > == Benefit to Fedora == > > > > * In Fedora 33, there are many nodejs libraries that are > > uninstallable, thus causing other programs based off them to also be > > uninstallable. This gets rid of that problem. > > * Packages in Fedora that use nodejs libraries will be able to use the > > library versions that upstream has tested and approved. > > * If a package in Fedora uses a nodejs library, the packager will not > > have to also package extra individual nodejs library packages. There > > have been times this has led to over 100 extra packages, each with > > their own package reviews and maintenance problems. This change will > > lower the workload on that packager, and possibly get more packages > > into Fedora. > > * The nodejs maintainers can concentrate on nodejs itself, instead of > > the whole nodejs library infrastructure. > > * Nodejs developers using Fedora will no longer have to worry about > > Fedora's global nodejs libraries causing conflicts or inconsistencies. > > > > == Scope == > &
Re: Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On Wed, Dec 9, 2020 at 3:52 PM Miro Hrončok wrote: > > On 12/9/20 7:44 PM, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault > > > > ... > > * Policies and guidelines: N/A (not a System Wide Change) > > Should there be an update of: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/JavaScript/ > https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/ > > ? > Working on the Node.js documentation right now. I currently haven't tested any of the bundling with javascript (js-...) packages. So I am not confident in writing documentation for them. It looks like there is only 20 left in Fedora. I am thinking of putting them in on our exceptions list, along with binary nodejs libraries. So we would get to them at a future time. Troy ___ 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 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On Wed, Dec 9, 2020 at 3:42 PM Miro Hrončok wrote: > > On 12/9/20 9:56 PM, Troy Dawson wrote: > > On Wed, Dec 9, 2020 at 11:21 AM Miro Hrončok wrote: > >> > >> On 12/9/20 7:44 PM, Ben Cotton wrote: > >>> == How To Test == > >>> > >>> * Install all nodejs libraries in Fedora 33. Try to update to Fedora 34. > >> > >> What is the plan wrt Obsoletes of the removed packages? > >> > >> -- > >> Miro Hrončok > >> -- > > > > We do not plan on obsoleting them. > > Obsoleting them has the potential to break third party software. > > dnf should also clean things up by seeing that the dependencies of an > > upgraded package have gone away. > > If dnf misses it, these are libraries, not binaries. If nothing is > > using them, they just take up some disk space. If a user really wants > > to clean them up, those types of users usually have their favorite > > ways of doing so. > > I worry about this specific case: There are several JS libraries unbundled in > python-notebook. Due to RPM/DNF limitations, they can onyl be unbondled if the > JS packages are obsoleted: > > https://bugzilla.redhat.com/show_bug.cgi?id=1787079#c8 > > I can definitively make sure the relevant packages are obsoleted by > fedora-obsolete-packages but that opens a can of worm, because if only some > removed packages are obsoleted, other removed packages will block the upgrade > path to Fedora 34/35. And they will need to be obsoleted as well. > > I rutinelly spend several hours each release to figure out and fix upgrade > path > issues by obsoleting packages via fedora-obsolete-packages. I'd like some help > with this by the change owners / NodeJS SIG. Can I count on that? > The js- (javascript) packages are something I haven't tested with my bundling scripts and thus do not feel confident in documenting and removing them at this time. There are currently only 20 of them, and I think we will add them to our exceptions list, along with the binary nodejs libraries. Hopefully by F35 or F36 we will be able to get to them. But other than those, yes, I believe the Nodejs sig can help with upgrade path issues and obsoleting packages that need to be obsoleted. Troy ___ 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 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On Wed, Dec 16, 2020 at 2:45 AM Miro Hrončok wrote: > > On 12/9/20 7:44 PM, Ben Cotton wrote: > > == Scope == > > * Proposal owners: > > We will go through the Fedora release and determine what nodejs > > packages Fedora should package. We will implement nodejs library > > bundling on those we already own. For those that we do not own, we > > will work with their owners to implement nodejs library bundling. > > > > As packages implement nodejs library bundling, we will monitor the > > nodejs libraries and note which ones are no longer required. When > > they are no longer required, we will retire them, if we own them. If > > we do not own them, we will work with the owners to retire them, if > > they wish. > > > > * Other developers: > > For Fedora packagers whose package rely on nodejs libraries, please > > contact the > > [[https://developer.fedoraproject.org/tech/languages/nodejs/SIG.html| > > Nodejs SIG]] and we will help you find the easiest way to bundle your > > nodejs libraries. > > > > For Fedora nodejs library packages, look to see what depends on your > > library. If it looks like you can do so, retire your nodejs library. > > If you would like, give the > > [[https://developer.fedoraproject.org/tech/languages/nodejs/SIG.html| > > Nodejs SIG]] admin to your nodejs libraries, and they will work > > through the process for you. > > I thought about this a bit more and I would really appreciate to see at least > some preliminary list of packages that will be retired/removed (completely > fine > if it's defined as "all nodejs-* packages except subpackages of nodejs itself > and nodejs-packaging") and the *list of dependent packages that are impacted > by > this change*. > > I've done some preliminary check with: > > https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py > > $ python find_unblocked_orphans.py --skip-orphans $(repoquery > --repo=rawhide-source -a | pkgname | grep ^nodejs- | grep -v > ^nodejs-packaging$ > | sort | uniq) > > ... > > The following packages require above mentioned packages: > Depending on: nodejs-backbone (2), status change: 2017-08-04 (175 weeks ago) > beets (maintained by: maha, mbaldessari) > beets-plugins-1.4.9-8.fc33.noarch requires js-backbone = > 1.3.3-10.fc34 > > python-notebook (maintained by: churchyard, python-sig) > python3-notebook-6.1.4-1.fc34.noarch requires js-backbone = > 1.3.3-10.fc34 > > Depending on: nodejs-generic-pool (1), status change: 2020-08-24 (16 weeks > ago) > statsd (maintained by: noodles, piotrp) > statsd-0.8.6-1.fc34.noarch requires npm(generic-pool) = 2.2.2 > > Depending on: nodejs-shelljs (1), status change: 2020-05-13 (31 weeks ago) > notepadqq (maintained by: orphan) > notepadqq-1.4.8-13.fc33.x86_64 requires nodejs-shelljs = > 0.8.4-2.fc33 > > Depending on: nodejs-typescript (1), status change: 2020-11-22 (3 weeks ago) > gnome-shell-extension-pop-shell (maintained by: carlwgeorge, > dustymabe) > > gnome-shell-extension-pop-shell-1.0.0-3.20201130gitee943b8.fc34.src requires > npm(typescript) = 4.0.2 > > Depending on: nodejs-underscore (11), status change: 2020-05-13 (31 weeks ago) > R-V8 (maintained by: qulogic) > R-V8-3.4.0-1.fc34.src requires js-underscore = 1.10.2-3.fc34 > R-V8-3.4.0-1.fc34.x86_64 requires js-underscore = > 1.10.2-3.fc34 > > beets (maintained by: maha, mbaldessari) > beets-plugins-1.4.9-8.fc33.noarch requires js-underscore = > 1.10.2-3.fc34 > > coffee-script (maintained by: jsmith, nodejs-sig, patches, vjancik) > coffee-script-1.10.0-14.fc33.src requires npm(underscore) = > 1.10.2 > > python-f5-sdk (maintained by: xavierb) > python-f5-sdk-3.0.21-7.fc33.src requires js-underscore = > 1.10.2-3.fc34 > python-f5-sdk-doc-3.0.21-7.fc33.noarch requires js-underscore > = 1.10.2-3.fc34 > > python-h2 (maintained by: eclipseo, python-sig) > python-h2-4.0.0-1.fc34.src requires js-underscore = > 1.10.2-3.fc34 > python-h2-doc-4.0.0-1.fc34.noarch requires js-underscore = > 1.10.2-3.fc34 > > python-hyperlink (maintained by: eclipseo, python-sig) > python-hyperlink-20.0.1-1.fc34.src requires js-underscore = > 1.10.2-3.fc34 > python-hyperlink-doc-20.0.1-1.fc34.noarch requires > js-underscore = 1.10.2-3.fc34 > > python-notebook (maintained by: churchyard, python-sig) > python3-notebook-6.1.4-1.fc34.noarch requires js-underscore = > 1.10.2-3.fc34 > > perl-Mojolicious-Plugin-AssetPack (maintained by: eseyman) > perl-Mojolicious-Plugin-AssetPack-2.10-1.fc34.src requires > coffee-script = > 1.10.0-14.fc33 > > python-webassets (maintained by: dcallagh, kumarpraveen, pjp, > sundaram) > python-webassets-0.1
Re: Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On Fri, Dec 11, 2020 at 9:32 AM Troy Dawson wrote: > > On Fri, Dec 11, 2020 at 3:18 AM Till Maas wrote: > > > > Hi, > > > > this does not seem to be self-contained, since it seems to affect people > > outside the SIG (it states that this is also affecting packages that are > > not owned by the SIG). > > > > On Wed, Dec 09, 2020 at 01:44:30PM -0500, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault > > > > > > == Summary == > > > > > > For Nodejs, Fedora should only package: > > > * The interpreter, development headers/libraries, and the assorted > > > tools to manage project-level installations (NPM, yarn, etc.). > > > * Packages that provide binaries that users would want to use in their > > > shell. > > > * compiled/binary nodejs modules (for now) > > > > > > == Owner == > > > > > > * Name: [[User:tdawson| Troy Dawson]] > > > * Email: tdaw...@redhat.com > > > * Name: [[User:sgallagh| Stephen Gallagher]] > > > * Email: sgall...@redhat.com > > > * Name: > > > [[https://developer.fedoraproject.org/tech/languages/nodejs/SIG.html| > > > Nodejs SIG]] > > > * Email: nod...@lists.fedoraproject.org > > > > > > > > > == Detailed Description == > > > > > > The nodejs libraries have been approved to be bundled, and there is > > > infrastructure in place for the bundling to work properly. Currently, > > > > What does this infrastructure look like? How does it help with > > addressing security issues in the bundles components effectivly? > > > > > it is recommended that packagers should create individual nodejs > > > library packages instead of bundling all of the libraries into the > > > package requiring them. > > > > The subject says "Stop Shipping Individual Nodejs Library Packages", > > therefore it would be more clear to block all Nodejs libraries in Fedora > > instead of only recommending this. Otherwise it will be some half-baked > > solution that is probably confusing (Why are some libraries packaged and > > others bundled?). > > > > > This change is to make it default to bundle the nodejs libraries with > > > the package that needs them, and retire the vast majority of nodejs > > > library packages. > > > In summary, for Nodejs Fedora should only package: > > > * The interpreter, development headers/libraries, and the assorted > > > tools to manage project-level installations (NPM, yarn, etc.). > > > * Packages that provide binaries that users would want to use in their > > > shell. > > > * compiled/binary nodejs modules (for now) > > > > This should also include the tooling that is needed to manage the > > bundling. > > > > > > > == Feedback == > > > > > > There has been a discussion on the fedora nodejs mailing list about > > > what to do with the extreme dependency problem of the nodejs library > > > packages. Because of the extreme inter-dependency, upgrading almost > > > any package causes others to break. It has caused most packages to > > > rot, remaining on unsupported versions for years. Many of the nodejs > > > packagers are giving up and orphaning their packages, which has caused > > > even more problems. > > > > > > An initial proposal was to find all of the important nodejs library > > > packages and bundle those, making them easier to upgrade and maintain. > > > But there was problems with figuring out what was important, and what > > > versions should those have. During that discussion, this rather > > > extreme solution of getting rid of all nodejs libraries was proposed. > > > To our surprise, it has been the best received suggestion and fixes > > > the most problems. > > > > What problems remain? > > > > > > > > == Benefit to Fedora == > > > > > > * In Fedora 33, there are many nodejs libraries that are > > > uninstallable, thus causing other programs based off them to also be > > > uninstallable. This gets rid of that problem. > > > * Packages in Fedora that use nodejs libraries will be able to use the > > > library versions that upstream has tested and approved. > > > * If a package in Fedora uses a nodejs library, the packager will not > > > have to also package extra individual nodejs library packages. There > > > have been times this has led to over 100 extra
Re: Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)
On Thu, Dec 17, 2020 at 2:19 PM Troy Dawson wrote: > > On Wed, Dec 9, 2020 at 3:52 PM Miro Hrončok wrote: > > > > On 12/9/20 7:44 PM, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault > > > > > > ... > > > * Policies and guidelines: N/A (not a System Wide Change) > > > > Should there be an update of: > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/JavaScript/ > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/ > > > > ? > > > Working on the Node.js documentation right now. > I currently haven't tested any of the bundling with javascript > (js-...) packages. So I am not confident in writing documentation for > them. > It looks like there is only 20 left in Fedora. I am thinking of > putting them in on our exceptions list, along with binary nodejs > libraries. So we would get to them at a future time. > > Troy The Node.js packaging Guidelines have a pull request for their update. https://pagure.io/packaging-committee/pull-request/1034 I did not touch the Javascript documentation. I took another look at the 20 javascript packages. Only two of them come from nodejs- libraries. Both of those two look like we can remove the nodejs- runtime package (server side javascript) and leave the js- runtime package (browser side javascript). Troy ___ 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
Orphaning nanomsg and 3 other packages
I created the nanomsg package to support mozilla-iot-gateway. I have orphaned mozilla-iot-gateway because I have not been able to give it the attention it needs. I have decided to orphan nanomsg, and the other supporting packages while I am at it. Below are the packages I am orphaning: nanomsg python-nnpy mozilla-iot-gateway-addon-node mozilla-iot-gateway-addon-python Outside of themselves, there is nothing that depends on these packages. Troy Dawson ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Rebuild
On Mon, Aug 3, 2020 at 10:32 AM Jaroslav Skarvada wrote: > > > > - Original Message - > > On 8/3/2020 9:42 AM, Neal Gompa wrote: > > > On Mon, Aug 3, 2020 at 12:32 PM Gary Buhrmaster > > > wrote: > > >> On Mon, Aug 3, 2020 at 3:15 PM Richard Hughes > > >> wrote: > > >> > > >>> Most of those are the libcroco->gettext breakage, no? > > >> From a very cursory scan (not at all scientific), > > >> some percentage are the cmake macro changes. > > > CMake macros are documented in the packaging guidelines: > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ > > > > > > Here's an example of how to adjust it: > > > https://src.fedoraproject.org/rpms/alembic/c/83812e6c762c28c7e2141860711a3598c101256f > > > > Indeed, using this example appears to have fixed at least one of my > > packages. > > > > > > Erich Eickmeyer > > Fedora Jam 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 > > > > Most of my FTBFSs are in form: > BuildrootError: Requested repo (1785390) is DELETED > > Wtf? > > E.g.: > https://bugzilla.redhat.com/show_bug.cgi?id=1863168 > https://bugzilla.redhat.com/show_bug.cgi?id=1863196 > https://bugzilla.redhat.com/show_bug.cgi?id=1863197 > https://bugzilla.redhat.com/show_bug.cgi?id=1863273 > These are what I call "transient s390x errors", even though it's not always s390x. I've had a couple, and they just required a rebuild with no changes. I have no idea of the technical reason for the error, just that I was able to successfully rebuild. ___ 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: [ELN] Update obsoleted for weird reasons
On Wed, Sep 9, 2020 at 1:34 PM Kevin Fenzi wrote: > > On Wed, Sep 09, 2020 at 08:07:24PM +0200, Miro Hrončok wrote: > > Hello. > > > > I've noticed at https://src.fedoraproject.org/rpms/python3.9 that the latest > > ELN release of python3.9 is behind Fedora. > > > > I've assumed the build has failed, but it succeeded: > > > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1592756 > > > > Except it it not tagged to eln. > > > > I've located the bodhi update: > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-8e33e741d8 > > > > It is "obsoleted" with "This update cannot be pushed to stable. These builds > > python3.9-3.9.0~rc1-2.eln103 have a more recent build in koji's eln tag." > > > > I've checked the koji's eln tag and it has python3.9-3.9.0~rc1-1.eln103 now. > > > > Maybe some different build was tagged when the update was created (no idea > > how to tell). If it was the Fedora build, it indeed has higher > > version-release if that's what meant by "more recent" -- however there is no > > "more recent" (more recently started or more recently completed) build of > > python3.9 in Koji. > > > > This does not show anything suspicious: > > > > $ koji list-history --package=python3.9 | grep eln > > > > Is this expected? Should the update be edited and pushed again? Or should > > the build be tagged manually? Am I expected to deal with that, as the > > package maintainer? > > > > This particular build only fixes a minor user-facing issue and does not > > affect builds of dependent packages so we can "leave it be" and wait for the > > next build, however that might not always be the case. > > I guess this is a bug, but What I think happened is: > > f33 python3.9 finished: > Thu Aug 13 20:40:05 2020 python3.9-3.9.0~rc1-2.fc33 tagged into f33 by bodhi > [still active] > ( eln was inheriting from f33-build at the time ) > > Then, the eln build finished: > Thu Aug 13 23:12:34 2020 python3.9-3.9.0~rc1-2.eln103 tagged into > eln-updates-candidate > by bpeck/jenkins-continuous-infra.apps.ci.centos.org > > but at this point bodhi looks and sees... hey f33 which we inherit > from already has a build of this version, so lets not push this to > stable. > > I think bodhi needs to be a bit smarter about checking for "more recent > builds". Possibly not looking at inheritence? > > I could be wrong, but thats what it seems like from a quick glance... > It was a bit of a race condition. The automatic eln rebuilder got stuck, I'm not positive of the reason. But when it was restarted, it went through all of the package builds that it had missed, and built them. I'm not positive why, but if you look at the start times of the builds, python3.9-3.9.0~rc1-1.eln103 was started AFTER python3.9-3.9.0~rc1-2.eln103. By one minute. Since ...rc1-2 was started before ...rc1-1, bodhi assumed that the one that started it's build last, was supposed to be the one that gets merged. Anyway, bodhi was just doing it's job, and it did it correctly. I think we need to look at our automation and when it get's stuck, make sure the backed up builds it does are in build order. Troy ___ 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: [ELN] Update obsoleted for weird reasons
On Wed, Sep 9, 2020 at 2:19 PM Troy Dawson wrote: > > On Wed, Sep 9, 2020 at 1:34 PM Kevin Fenzi wrote: > > > > On Wed, Sep 09, 2020 at 08:07:24PM +0200, Miro Hrončok wrote: > > > Hello. > > > > > > I've noticed at https://src.fedoraproject.org/rpms/python3.9 that the > > > latest > > > ELN release of python3.9 is behind Fedora. > > > > > > I've assumed the build has failed, but it succeeded: > > > > > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1592756 > > > > > > Except it it not tagged to eln. > > > > > > I've located the bodhi update: > > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-8e33e741d8 > > > > > > It is "obsoleted" with "This update cannot be pushed to stable. These > > > builds > > > python3.9-3.9.0~rc1-2.eln103 have a more recent build in koji's eln tag." > > > > > > I've checked the koji's eln tag and it has python3.9-3.9.0~rc1-1.eln103 > > > now. > > > > > > Maybe some different build was tagged when the update was created (no idea > > > how to tell). If it was the Fedora build, it indeed has higher > > > version-release if that's what meant by "more recent" -- however there is > > > no > > > "more recent" (more recently started or more recently completed) build of > > > python3.9 in Koji. > > > > > > This does not show anything suspicious: > > > > > > $ koji list-history --package=python3.9 | grep eln > > > > > > Is this expected? Should the update be edited and pushed again? Or should > > > the build be tagged manually? Am I expected to deal with that, as the > > > package maintainer? > > > > > > This particular build only fixes a minor user-facing issue and does not > > > affect builds of dependent packages so we can "leave it be" and wait for > > > the > > > next build, however that might not always be the case. > > > > I guess this is a bug, but What I think happened is: > > > > f33 python3.9 finished: > > Thu Aug 13 20:40:05 2020 python3.9-3.9.0~rc1-2.fc33 tagged into f33 by > > bodhi [still active] > > ( eln was inheriting from f33-build at the time ) > > > > Then, the eln build finished: > > Thu Aug 13 23:12:34 2020 python3.9-3.9.0~rc1-2.eln103 tagged into > > eln-updates-candidate > > by bpeck/jenkins-continuous-infra.apps.ci.centos.org > > > > but at this point bodhi looks and sees... hey f33 which we inherit > > from already has a build of this version, so lets not push this to > > stable. > > > > I think bodhi needs to be a bit smarter about checking for "more recent > > builds". Possibly not looking at inheritence? > > > > I could be wrong, but thats what it seems like from a quick glance... > > > > It was a bit of a race condition. > The automatic eln rebuilder got stuck, I'm not positive of the reason. > But when it was restarted, it went through all of the package builds > that it had missed, and built them. > I'm not positive why, but if you look at the start times of the > builds, python3.9-3.9.0~rc1-1.eln103 was started AFTER > python3.9-3.9.0~rc1-2.eln103. By one minute. > > Since ...rc1-2 was started before ...rc1-1, bodhi assumed that the one > that started it's build last, was supposed to be the one that gets > merged. > Anyway, bodhi was just doing it's job, and it did it correctly. > I think we need to look at our automation and when it get's stuck, > make sure the backed up builds it does are in build order. > > Troy Side note. I've manually tagged the new one into ELN. Troy ___ 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
[EPEL-devel] Re: Proposing an EPEL packaging SIG
On Fri, Sep 11, 2020 at 12:10 PM Robbie Harwood wrote: > > Michel Alexandre Salim writes: > > > * Have an expedited flow where this SIG can request EPEL branches and > > admin access to packages if there are no response from package > > maintainers for a set period (3 days? 1 week?) > > * whether it should be full admin access or whether such access > > should be scoped to epel* branches can be discussed. Full admin would > > make it possible to adjust the spec in Rawhide to be more EPEL > > friendly, for example > > Unless I've missed something, we still don't have per-branch ACLs in > dist-git. > > I don't think it's okay to force maintainers to give you admin or commit > to their packages just because you want them in EPEL. > > (I'm also not one of the kind of people who really like having one spec > file for all versions of the package, but I know others disagree with me > on this. Certainly if hypothetically I didn't want to maintain an EPEL > package I wouldn't want its logic /also/ foisted on me in rawhide.) > This does sound a bit over-the-top as far as permissions go. As Robbie said, some people/groups don't like having all sorts of conditions in their spec files. Having a SIG being able to put in, and change, %if statements in Rawhide spec files whenever they want is not a good situation. If they want to open pull requests, for those changes, fine. But giving them permissions to put them in with no oversite, I don't like. Do we have any idea on the timeframe of having per-branch ACLs in dist-git? Troy ___ epel-devel mailing list -- epel-de...@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-de...@lists.fedoraproject.org
Re: [ELN] Why is rubygem-liquid included in eln?
On Fri, Jan 7, 2022 at 12:20 AM Otto Urpelainen wrote: > I am the maintainer of rubygem-liquid package in Fedora. Every now and > then is receive notification that this package has been built and > updated for eln, for example [1,2]. > > I have been trying to understand why this package is included in eln. As > far as I can understand, it should be somehow visible in Content > Resolver [3]. I have not found a "search by package name" feature there, > so I have also grepped the content-resolver-input repository [4]. I > cannot find anything there, either. > > Could somebody explain how this package ends up being included in eln? > > The reason why I care is that I have deferred the Liquid 5 update in > Fedora on the basis that its only consumer, Jekyll, is still on 4. These > eln builds make me suspect that rubygem-liquid is used for something > else there. I would like to check with the correct people that my > decision to stay on 4 is ok for them, too. > > Otto > > [1]: http://koji.fedoraproject.org/koji/buildinfo?buildID=1873495 > [2]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-11b99445de > [3]: https://tiny.distro.builders/ > [4]: https://github.com/minimization/content-resolver-input > It is a build dependency of rubygem-sinatra and rubygem-tilt [5] Currently, the only way to find that was to go into the buildroot section of ELN Views -> eln -> x86_64 -> buildroot This problem of the build dependencies being sort of hidden is being worked on. We are hoping to have the next major release of Content Resolver out in a month or two. It will make it much easier to see why a package is in the list. Troy [5] - https://tiny.distro.builders/view-rpm--view-eln--rubygem-liquid.html ___ 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
First round of nodejs libraries retiring
The following "applications" source rpm's start with nodejs, and have
a binary in /usr/bin/ They have either had their dependencies
bundled, or did not have any nodejs library dependencies.
nodejs-buble nodejs-linefix nodejs-nodemon
nodejs-replace-require-self nodejs-shelljs nodejs-supervisor
nodejs-svgo nodejs-tape
With the above "application" packages bundled, I have moved onto
discovering what nodejs libraries can safely be removed.
I have used the following steps, on a rawhide machine, to find my list.
dnf repoquery --qf="%{source_name}" -a | grep ^nodejs- | sort -u -o
nodejs.sources
vi nodejs.sources # remove the "application" packages from Comment
#1, and nodejs-packaging
./find_unblocked_orphans.py --release rawhide --skip-orphans $(cat
nodejs.sources)
From the above steps, there are only 6 packages that are still
depended upon, and 210 that can be removed if we remove them all at
the same time.
I am planning on removing the 210 packages before the F34 mass
rebuild. Hopefully by end of day Monday, January 18.
During the F34 mass rebuild I will keep watch to see if any packages
are failing builds due to missing nodejs libraries. I will work with
any of these failed builds to get a proper solution following the
change request guidelines.
Note: There are currently only 216 nodejs library packages. There
were 740 two months ago, and 1300 a year ago. These have all gone
away due to being orphaned and/or being uninstallable.
Packages still needed due to dependencies (6):
nodejs-acorn-object-spread
nodejs-backbone nodejs-colors nodejs-generic-pool
nodejs-typescript nodejs-underscore
Packages that can be removed, if done all at once (210):
nodejs-acorn-dynamic-import
nodejs-amdefine nodejs-ansicolors nodejs-any-promise
nodejs-append-transform nodejs-array-buffer-from-string
nodejs-array-index nodejs-asap nodejs-ascli nodejs-base32-encode
nodejs-better-assert nodejs-better-than-before nodejs-bignumber-js
nodejs-boom nodejs-bson nodejs-buf-compare nodejs-buffer-equal
nodejs-builtin-modules nodejs-builtins nodejs-bundle-dependencies
nodejs-bunker nodejs-burrito nodejs-caching-transform
nodejs-caller-callsite nodejs-caller-path nodejs-callsites
nodejs-camelcase-keys nodejs-charm nodejs-ci-info nodejs-cli
nodejs-cli-color nodejs-cli-table nodejs-codemirror
nodejs-code-point-at nodejs-combined-stream nodejs-commander
nodejs-connect-livereload nodejs-consolemd nodejs-cookies
nodejs-cryptiles nodejs-csv nodejs-currently-unhandled
nodejs-cycle nodejs-d nodejs-debug nodejs-decamelize
nodejs-decamelize-keys nodejs-deeper
nodejs-default-require-extensions nodejs-delayed-stream
nodejs-detect-indent nodejs-discord-js nodejs-dot-prop
nodejs-duration nodejs-each nodejs-emojione nodejs-es5-ext
nodejs-es6-iterator nodejs-es6-weak-map nodejs-escape-html
nodejs-escape-regexp-component nodejs-escape-string-regexp
nodejs-espurify nodejs-event-emitter nodejs-fancy-log nodejs-fmix
nodejs-forever-agent nodejs-formatio nodejs-form-data
nodejs-glob-base nodejs-glob-parent nodejs-glogg
nodejs-gonzales-pe nodejs-graceful-readlink nodejs-growl
nodejs-grunt-contrib-nodeunit nodejs-grunt-sed nodejs-gulplog
nodejs-has-ansi nodejs-has-binary2 nodejs-has-flag nodejs-has-glob
nodejs-has-gulplog nodejs-hashish nodejs-hawk
nodejs-hex-to-array-buffer nodejs-hoek nodejs-homedir-polyfill
nodejs-imurmurhash nodejs-indent-string nodejs-indexof
nodejs-ipaddr-dot-js nodejs-irc-colors nodejs-irc-formatting
nodejs-irc-upd nodejs-isarray nodejs-is-builtin-module
nodejs-is-finite nodejs-is-fullwidth-code-point
nodejs-is-observable nodejs-isodate nodejs-is-plain-obj
nodejs-is-promise nodejs-is-text-path nodejs-is-valid-instance
nodejs-js-base64 nodejs-jschardet nodejs-json3 nodejs-jsonify
nodejs-jsonselect nodejs-lcid nodejs-levn nodejs-lolex
nodejs-loud-rejection nodejs-lru-cache nodejs-lru-queue
nodejs-magic-string nodejs-makeerror nodejs-md5-hex
nodejs-memoizee nodejs-minipass nodejs-mkdirp nodejs-mongodb
nodejs-mongodb-core nodejs-murmur-32 nodejs-mustache nodejs-mysql
nodejs-mz nodejs-negative-zero nodejs-npm-run-path
nodejs-nth-check nodejs-observable-to-promise nodejs-once
nodejs-open nodejs-optionator nodejs-option-chain nodejs-options
nodejs-os-homedir nodejs-os-locale nodejs-own-or-env
nodejs-package-license nodejs-parse-glob nodejs-path-is-absolute
nodejs-path-parse nodejs-pkginfo nodejs-platform nodejs-plur
nodejs-pretty-ms nodejs-prism-media nodejs-pruddy-error
nodejs-rainbowsocks nodejs-random-path nodejs-readdir-enhanced
nodejs-require-all nodejs-resolve-cwd nodejs-resolve-from
nodejs-resolve-pkg nodejs-rhea nodejs-runforcover nodejs-samsam
nodejs-shebang-command nodejs-simple-fmt nodejs-simple-is
nodejs-slide nodejs-snapdragon-capture-set nodejs-snapdragon-node
nodejs-snapdragon-util nod
Re: ELN SIG First Meeting
On Mon, Mar 1, 2021 at 11:49 AM Davide Cavalca via devel wrote: > > On Mon, 2021-03-01 at 09:26 -0500, Stephen Gallagher wrote: > > I'd like to encourage anyone interested in this meeting to submit > > agenda topics by replying to this email. Currently the agenda > > One thing I'd be interested in exploring is the feasibility of > extending ELN to cover EPEL as well. This would make it easier to keep > EPEL consistent between major releases (as packages would get branched > automatically). It would also make it possible to test the combined ELN > + EPEL snapshot and find potential issues early on in the process. > Sorry for coming late to the discussion. I took a week off and all sorts of things happened while I was gone. I believe Kevin and Smooge, and possibly even you Davide got this backwards. And I think if we do this right, this can be a thing. When we started ELN, one of the major promises was that it wouldn't interfere with regular Fedora work. That your average Fedora packager that didn't care about ELN, could continue to not care about ELN and nothing would change. I believe we (ELN SIG) should extend the same courtesy to EPEL and the EPEL community and packagers. The email discussion went in the direction of all the work that EPEL would need to do to create an ELN EPEL. But we (ELN SIG) shouldn't have expected that. We should have expected to do all the work. So, if we flip this around, where everything is on ELN, how would that work. We create a new Fedora target and tag: eln-extra (so people do NOT confuse it with real EPEL) eln-extra-build inherits from itself and eln-build If a package is built against the eln-extra target, and it is successful, it gets tagged with the eln-extra tag. There is a daily (or some other time period) repo creation. No images, just a repo, like epel. There is a list of packages, similar to the list of packages used to create the ELN list, on some github/gitlab/pagure repo. If you put a package on that list, you associate your name with that package. Just like ELN, when a package on the eln-extra list gets built in rawhide, it get's built in eln-extra. In fact, it would be best if we just altered the ELN trigger/periodic scripts to look at this list along with the regular ELN list. What are people's thoughts on this? No extra work on EPEL. If someone, or some company wants to test ELN and need packages not in ELN, they can add the packages to the list, with their name/company associated with that package. It would get built, put in the repo, and they can then run their ELN test with the package they need. Thoughts? Troy ___ 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
[ELN] Proposal: ELN Extra
I'm sending this out now so I don't have to say all this in this week's ELN meeting. Problem: Users might want to test ELN for their own package/product that either is only in Fedora, or that has dependencies that are only in Fedora and not ELN. Solution: Create ELN Extra for those extra packages. Details: - Create a new Fedora target and tag: eln-extra -- eln-extra-build inherits from itself and eln-build -- Successful builds are tagged with eln-extra - Repo creation only, no images. -- Repo creation is on the same timescale as ELN composes. - Package list -- Package list is kept in a git repo (pagure/gitlab/github) -- Each package has it's requestor name/email associated with it. - Builds trigger just like ELN -- If a package successfully builds in Rawhide, and it is on the ELN Extra list, it gets built in the ELN Extra target. Notes: - This is not associated with EPEL in any way. -- Just because a package is in ELN Extras does not mean it has to go into EPEL. That is up to the EPEL package maintainer(s). Troy ___ 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: [ELN] Proposal: ELN Extra
On Fri, Mar 19, 2021 at 7:25 AM Troy Dawson wrote: > > I'm sending this out now so I don't have to say all this in this > week's ELN meeting. > > Problem: Users might want to test ELN for their own package/product > that either is only in Fedora, or that has dependencies that are only > in Fedora and not ELN. > > Solution: Create ELN Extra for those extra packages. > > Details: > - Create a new Fedora target and tag: eln-extra > -- eln-extra-build inherits from itself and eln-build > -- Successful builds are tagged with eln-extra > - Repo creation only, no images. > -- Repo creation is on the same timescale as ELN composes. > - Package list > -- Package list is kept in a git repo (pagure/gitlab/github) > -- Each package has it's requestor name/email associated with it. > - Builds trigger just like ELN > -- If a package successfully builds in Rawhide, and it is on the ELN > Extra list, it gets built in the ELN Extra target. > > Notes: > - This is not associated with EPEL in any way. > -- Just because a package is in ELN Extras does not mean it has to go > into EPEL. That is up to the EPEL package maintainer(s). > > Troy I wanted that to be a clean email, without clutter. I see two downsides to this. 1 - More Fedora resources (hardware and admins) used. 2 - More "ELN Spam" and this time to people who likely aren't Red Hat employees and/or maintaining a Fedora package in their own time. To me, this is the biggest downside. Troy ___ 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: [ELN] Proposal: ELN Extra
On Fri, Mar 19, 2021 at 7:55 AM Miro Hrončok wrote: > > On 19. 03. 21 15:25, Troy Dawson wrote: > > Problem: Users might want to test ELN for their own package/product > > that either is only in Fedora, or that has dependencies that are only > > in Fedora and not ELN. > > I am not sure I underrated this problem entirely. > > I thought ELN is used as an additional repo on rawhide [1]. Hence, you get > access to all the rawhide packages when you use ELN. Has that changed? > > [1] > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose#How_To_Test It has not. And I might not totally understand the problem either. It was other people who brought it up. I am merely proposing a solution to what I understand they were telling me. The closest I have to this problem is having some EPEL packages that I want to make sure don't break on RHEL, and I'd rather know sooner rather than later. But, as for me, I plan on using epel-next for that. Troy ___ 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
ELN composes
First, it looks like the ELN composes have been broken for a while. It's failing on "Cant locate template for uri 'runtime-install.tmpl'"[1] but lorax-templates-generic is installed.[2] I'm at a loss on this one. Second, I thought we were shifting ELN Composes to just be once a day. It looks like they are still every 3 hours. Troy [1] - https://kojipkgs.fedoraproject.org//work/tasks/8652/66538652/mock_output.log [2] - https://kojipkgs.fedoraproject.org//work/tasks/8652/66538652/root.log ___ 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
[ELN] Broken ELN Compose detection
I wrote the following script a while ago to check on the ELN composes.[1][2] It's not fancy, and the webpage it outputs isn't fancy,[3] but it works. It's a good starting point for checking ELN Composes. I thought I'd share it before the ELN meeting tomorrow so people would have a chance to look at it. Troy [1] - https://tdawson.fedorapeople.org/eln/eln-compose-status.py [2] - https://tdawson.fedorapeople.org/eln/compose-status.html.jira [3] - https://tdawson.fedorapeople.org/eln/output/compose-status.html ___ 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: [ELN] Rebuild ordering and side-tag support
On Mon, Jun 28, 2021 at 9:21 AM Stephen Gallagher wrote: > Summary: I think we can fix the ELN side-tag rebuild problems and make > the composes more reliable if we change the mechanism for kicking off > rebuilds. I'm soliciting feedback to help identify potential issues > with this proposed approach. > > > ## Background Information ## > Currently in ELN, merging a side-tag into Rawhide results in all of > the packages from that side-tag being rebuilt concurrently in ELN. > This leads to two problems: > > 1. Side-tags containing large numbers of package builds will trigger > many ELN builds at the same time, possibly overwhelming available > resources on the ELN automation systems. > 2. Many (most?) side-tags exist to ensure that packages are built in > a particular order so as to ensure that they are built after their > dependencies. Launching all the rebuilds concurrently means that many > of the builds may succeed *and still be wrong* (such as if they are > built against an older soname). > > ## Proposed Solution ## > I had a discussion with Miro Hrončok this morning where we tackled > this problem and may have come up with a workable solution for 99% of > cases. Instead of treating side-tags as a special event and trying to > sort the builds such that they are built in the same order, we can > instead tag in the Rawhide packages first, then issue the rebuilds > together. With the Rawhide packages available, we won't need to worry > about the ordering, because the dependencies will already be present > in a sufficiently-recent version. As a bonus, we'll reduce the > likelihood of broken ELN composes, since if an ELN rebuild fails, the > Rawhide version will still be present to satisfy dependencies. > > In greater detail: > > Whenever a build is tagged into the 'f35' tag (later, whatever tag > matches Rawhide), ELN automation would take the following steps: > > * Identify whether this package is on the list of packages that ELN > rebuilds[1] > * Tag the Rawhide build into the 'eln' tag (so it is now tagged with > both 'f35' and 'eln') > * Enqueue a Koji build against the 'eln' target from the same Git commit > > The queue mentioned above should be maintained in a separate thread > and used to submit tasks in batches to avoid overloading the > infrastructure. If the Koji build against the 'eln' target fails, the > Rawhide build will remain as the most-recently-tagged version of the > package in ELN and become part of the compose until the ELN rebuild > can be fixed. > > Note that this process would apply to ALL builds in Rawhide, not just > those coming from side-tags. There would be no difference in behavior > between standard direct builds and side-tag merged builds. > > > ## Known potential issues ## > > * Some packages may auto-detect functionality based on functionality > made available by one of their dependencies. If the Rawhide and ELN > versions of that dependency differ in visible functionality, then > building an ELN package with a Rawhide version of its dependency could > result in unexpected behavior. I believe this issue to be rare and > generally best handled by the packager as the subject matter expert. > They'd just need to bump the release number and rebuild the package in > ELN. Alternatively, if this is known to be regularly problematic for a > package, the maintainer can opt out of the automatic rebuild and work > out a strategy with the ELN SIG for dealing with it. > > > > [1] This will be the set of packages provided by > https://tiny.distro.builders/view--view-eln.html minus any packages > that have opted out of automatic rebuilds (they perform manual > rebuilds for ELN). > > Two issues I see deal with failed builds and new dependencies. 1 - failed builds. Will there be an easy way for the ELN SIG (or whoever) to see what the failed builds are? Or are all of these builds fire and forget? 2 - new dependencies. Package foo (in ELN list) get's a new dependency bar (not in ELN list). bar will already be built when foo gets updated and built in rawhide and ELN. bar will eventually get put on the ELN list. But with your proposal, bar has the potential to not be built in ELN for 6 months. It would be nice if there was still something like ELN periodic that checked what packages haven't been built and attempts to rebuild them. I know we've had a problem in the past with it spamming due to retrying failed builds multiple times. But it is there for a reason. Troy ___ 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: ELN rebuild ordering fail (was Re: userspace-rcu 0.13.0 soname bump)
On Wed, Jul 7, 2021 at 2:00 AM Daniel P. Berrangé wrote: > On Tue, Jun 08, 2021 at 02:30:42PM -0400, Michael Jeanson wrote: > > I have started the process to update userspace-rcu to 0.13 in rawhide > which > > implies a soname bump to 8. > > > > From what I understand, the following packages will need to be rebuilt: > > > > device-mapper-multipath > > glusterfs > > knot > > libntirpc > > lttng-tools > > lttng-ust > > netsniff-ng > > nfs-ganesha > > > > > > I have created a side tag 'f35-build-side-42347' and built userspace-rcu, > > lttng-ust and lttng-tools. At this point I'm unsure what the rest of the > > procedure is to get the other packages built in this tag and then get > them > > pushed to rawhide once it's done. > > Using the side tag for the builds of lttng-ust did the job fine for > Fedora rawhide builds, but I'm seeing problems with the ELN rebuilds > I'm getting spammed frequently by the failing libvirt builds for the > ELN rebuilds. 8 failed libvirt builds, and another related 18 failed > libvirt-python builds just since last night > > Most recent is > > https://koji.fedoraproject.org/koji/taskinfo?taskID=71422991 > > Looking at the failed s390x build logs: > > https://kojipkgs.fedoraproject.org//work/tasks/2991/71422991/root.log > > I see the tell tail sign of the soname bump > > Error: > Problem 1: package librados-devel-2:16.2.4-5.eln112.s390x requires > librados.so.2()(64bit), but none of the providers can be installed > - package librados-devel-2:16.2.4-5.eln112.s390x requires > librados_tp.so.2()(64bit), but none of the providers can be installed > - package librados-devel-2:16.2.4-5.eln112.s390x requires librados2 = > 2:16.2.4-5.eln112, but none of the providers can be installed > - package librados2-2:16.2.4-5.eln112.s390x requires > liblttng-ust.so.0()(64bit), but none of the providers can be installed > - conflicting requests > - nothing provides liburcu-bp.so.6()(64bit) needed by > lttng-ust-2.12.2-4.eln112.s390x > - nothing provides liburcu-cds.so.6()(64bit) needed by > lttng-ust-2.12.2-4.eln112.s390x > > > librados-devel can't be installed because librados2 can't be installed > because liblttng-ust can't be installed, because it depends on the > old soname of userspace-rcu. > > Looking at koji logs, I can see the most recent build of userspace-rcu > version 0.13.0-2 which has the soname bump: > > - rawhide: 2021-06-08 16:10:21 > - eln112: 2021-06-23 15:17:36 > > while the rebuilds of lttng-ust were: > > - rawhide: 2021-06-08 17:31:22 > - eln112: 2021-06-11 19:52:32 > > So the rebuilds in ELN were not only in the wrong order, they were > weeks apart in the wrong order. > > According to this proposal to fix ELN, the side tag builds are all > run in parallel. Obviously this relies on luck to work, but in this > particular case I don't see any parallelism. The userspace-rcu > build didn't run till 12 days later. > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EKBW5DRRYGMJ5KOAHBGSXMOKGVSA3NPE/ > > Anyway, it is good to see there's a proposal to fix ELN schedular > but I'm wondering what the right way to fix this immediate problem > is ? > > I presume we need a bogus release bump and rebuild of lttng-ust to > be run in rawhide in order to trigger ELN into fixing itself ? > > Regards, > Daniel > Fixed, including libvirt built on eln. I can't wait for the new way of doing ELN builds. It looks like userspace-rcu-0.13.0-2.fc35, lttng-ust-2.12.2-4.fc35, and several other packages were in a side tag from June 8, until June 23. At that point, they were all tagged into f35 and all built at the same time. *sigh* I've only fixed lttng-ust, so that libvirt would build. I haven't had time to look at the rest yet. Troy ___ 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: [Fedocal] Reminder meeting : ELN SIG
This might not warrant a meeting, but it's something that just came up. ELN-Extra I never went beyond the Content Resolver initial setup, because there weren't any real requests. But now I am getting one. Will the new ELN build implementation be able to do ELN Extra? It would need to pull from the ELN Extra view on Content Resolvers, and build against the eln-extra build target. To me, that seems simple, but I'm not the one setting up the new build implementation. Troy On Fri, Jul 16, 2021 at 5:43 AM Stephen Gallagher wrote: > I don't currently have anything on the agenda for today's meeting. If > you have something, please reply to this email or I will just go ahead > and cancel for this week. > > On Thu, Jul 15, 2021 at 8:00 AM wrote: > > > > Dear all, > > > > You are kindly invited to the meeting: > >ELN SIG on 2021-07-16 from 12:00:00 to 13:00:00 US/Eastern > >At fedora-meet...@irc.libera.chat > > > > The meeting will be about: > > > > > > > > Source: https://calendar.fedoraproject.org//meeting/9920/ > > > > ___ > > 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 > ___ 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: [EPEL-devel] Re: FailsToInstall bugs, can we have it enable on EPEL branches ?
On Sat, Sep 21, 2024 at 3:05 PM Carl George wrote: > On Sat, Sep 21, 2024 at 3:21 PM Miro Hrončok wrote: > > > > On 21. 09. 24 20:00, Sérgio Basto wrote: > > > Hello, > > > > > > On Sat, 2024-09-21 at 10:03 +, bugzi...@redhat.com wrote: > > >> Hello, > > >> > > >> Please note that this comment was generated automatically by > > >> > https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py > > > > > > > > > Have this scripts running on EPEL branches would help me detect FTI > > > more quickly , instead be users reporting it > > > > > > Best regards, > > > > We probably could. It runs against the koji repos, so as long as it does > not > > want to report bugzillas for RHEL content, it should work. > > > This is something that's been on my mind for a while. Uninstallable > packages hurt EPEL's overall reputation. I would actually like to > take this a step further than FTI bugs and also gate EPEL updates on > installability. I do not think it should be allowed to push an update > to stable if it is uninstallable. Even if we can't gate the updates > completely, we should at least disable auto-push based on time/karma > if the installability check fails. The first step will be to actually > run the installability check on EPEL updates, which does not currently > happen. > > https://github.com/fedora-ci/installability-pipeline/issues/40 > > I've also been toying with the idea of having an EPEL policy around > this. Fedora doesn't allow uninstallable packages to sit in the repos > forever, and neither should EPEL. Automatic FTI bugs would be really > useful here for marking the duration, and then the policy could be > something like "untag after X months of not being installable". For > EPEL 10 we could do a one-off bulk untag for everything that doesn't > install right before the official launch. > > Python has a great policy that helps in these situations. The > upstream test suite SHOULD be run in %check, but if it can't a basic > smoke test (e.g. %pyproject_check_import) MUST be run. This ensures > that missing run-time dependencies fail the build. If you get a FTI > bug for one of your Python packages, it likely means this policy isn't > being followed. > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_tests > > -- > Carl George > While that is getting done, I have got my will-it-install page back up and working for epel10 https://tdawson.fedorapeople.org/epel/willit/epel10/status-wont-install.html It's only updating once a day, at least until I get Diego's changes backported. Troy -- ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
