[EPEL-devel] Fedora EPEL 7 updates-testing report
The following builds have been pushed to Fedora EPEL 7 updates-testing borgbackup-1.1.18-1.el7 phoronix-test-suite-10.8.3-1.el7 Details about builds: borgbackup-1.1.18-1.el7 (FEDORA-EPEL-2022-f6cbffad47) A deduplicating backup program with compression and authenticated encryption Update Information: update to latest upstream version 1.1.18 which includes quite a few bug fixes ChangeLog: * Sun Jun 5 2022 Felix Schwarz - 1.1.18-1 - update to 1.1.18 phoronix-test-suite-10.8.3-1.el7 (FEDORA-EPEL-2022-13047a3b00) An Automated, Open-Source Testing Framework Update Information: pts-core: Improved TTF font file detection pts-core: Minor random fixes phodevi: Apple M1 detection on Linux ChangeLog: * Fri Jun 3 2022 Michel Alexandre Salim 10.8.3-1 - Update to 10.8.3 References: [ 1 ] Bug #2078289 - phoronix-test-suite-10.8.3 is available https://bugzilla.redhat.com/show_bug.cgi?id=2078289 ___ epel-devel mailing list -- epel-devel@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-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following builds have been pushed to Fedora EPEL 8 updates-testing drbd-9.21.1-1.el8 phoronix-test-suite-10.8.3-1.el8 powerline-2.8.3-4.el8 Details about builds: drbd-9.21.1-1.el8 (FEDORA-EPEL-2022-f27f30c512) DRBD user-land tools and scripts Update Information: Upstream release of 9.21.1 ChangeLog: * Sun Jun 5 2022 Peter Hanecak - 9.21.1-1 - Upstream release of 9.21.1 * Sun Feb 6 2022 Peter Hanecak - 9.20.2-1 - Upstream release of 9.20.2 - glibc2.32_clock_gettime patch dropped * Thu Jan 20 2022 Fedora Release Engineering - 9.20.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Sun Jan 16 2022 Peter Hanecak - 9.20.0-1 - Upstream release of 9.20.0 - Build now requires pkgconf - glibc2.32_clock_gettime patch updated * Mon Nov 1 2021 Peter Hanecak - 9.19.0-1 - Upstream release of 9.19.0 - Own /usr/lib/ocf/resource.d/linbit/, fixing #1847138 * Sun Aug 15 2021 Peter Hanecak - 9.18.2-1 - Upstream release of 9.18.2 (note: /lib/drbd/drbd moved to /lib/drbd/scripts/drbd) - Adjusted URL of the source package - Custom drbd.service dropped, upstream variant used, since upstream reworked quite a lot - Build now requires rubygem-asciidoctor * Wed Jul 21 2021 Fedora Release Engineering - 9.17.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild References: [ 1 ] Bug #2078467 - drbd-9.21.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=2078467 phoronix-test-suite-10.8.3-1.el8 (FEDORA-EPEL-2022-964cc0bc57) An Automated, Open-Source Testing Framework Update Information: pts-core: Improved TTF font file detection pts-core: Minor random fixes phodevi: Apple M1 detection on Linux ChangeLog: * Fri Jun 3 2022 Michel Alexandre Salim 10.8.3-1 - Update to 10.8.3 References: [ 1 ] Bug #2078289 - phoronix-test-suite-10.8.3 is available https://bugzilla.redhat.com/show_bug.cgi?id=2078289 powerline-2.8.3-4.el8 (FEDORA-EPEL-2022-8873de81db) The ultimate status-line/prompt utility Update Information: Use correct `%systemd_` RPM macros for user unit (#2093695) Build `powerline` binary with correct linker flags ChangeLog: * Sun Jun 5 2022 Christoph Erhardt - 2.8.3-4 - Use correct `%systemd_` RPM macros for user unit (#2093695) * Fri Jun 3 2022 Christoph Erhardt - 2.8.3-3 - Build `powerline` binary with correct linker flags - Make Fontconfig symlink relative - Change fontconfig dependency to fontpackages-filesystem (#2093167) References: [ 1 ] Bug #2093167 - powerline-fonts shouldn't have a dependency to fontconfig https://bugzilla.redhat.com/show_bug.cgi?id=2093167 [ 2 ] Bug #2093695 - Package installation issue https://bugzilla.redhat.com/show_bug.cgi?id=2093695 ___ epel-devel mailing list -- epel-devel@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-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following builds have been pushed to Fedora EPEL 8 updates-testing tio-1.38-1.el8 Details about builds: tio-1.38-1.el8 (FEDORA-EPEL-2022-419a953a1a) Simple TTY terminal I/O application Update Information: # tio v1.38* Redirect error messages to stderr* Improve help and man page* Mention config file in `--help`* Fix running without config file * Fix config file error messages* Redirect error messages to stderr* Add repology packaging status* Fix parsing of default settings Default configuration file settings were not parsed in case a section was matched. Now we make sure that the default (unnamed) settings are always parsed.* Append to existing log file (no truncation)* Add socket info to show configuration * Print socket info at startup* Fix socket option parsing* Match user input against config section names if pattern matching was unsuccessful. This allows for better config file ergonomics if the user has a diverse set of serial devices as the name does not need to be specified in the config file twice.* Add support for external control via a Unix domain socket. This feature allows an external program to inject output into and listen to input from a serial port via a Unix domain socket (path specified via the `-S`/`--socket` command line flag, or the socket config file option) while tio is running. This is useful for ad-hoc scripting of serial port interactions while still permitting manual control. Since many serial devices (at least on Linux) get confused when opened by multiple processes, and most commands do not know how to correctly open a serial device, this allows a more convenient usage model than directly writing to the device node from an external program. Any input from clients connected to the socket is sent on the serial port as if entered at the terminal where tio is running (except that `ctrl-t` sequences are not recognized), and any input from the serial port is multiplexed to the terminal and all connected clients. Sockets remain open while the serial port is disconnected, and writes will block. Example usage 1 (issue a command): `echo command | nc -UN /path/to/socket > /dev/null` Example usage 2 (use the expect command to script an interaction): ``` #!/usr/bin/expect -f set timeout -1 log_user 0 spawn nc -UN /path/to/socket set uart $spawn_id send -i $uart "command1\n" expect -i $uart "prompt> " send -i $uart "command2\n" expect -i $uart "prompt> " ```* fix for using option `log` without `log- filename` in config file ChangeLog: * Sat Jun 4 2022 Robert Scheck 1.38-1 - Upgrade to 1.38 (#2092955) References: [ 1 ] Bug #2092955 - tio-1.38 is available https://bugzilla.redhat.com/show_bug.cgi?id=2092955 ___ epel-devel mailing list -- epel-devel@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-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
Jun 4, 2022 4:01:42 PM Troy Dawson : > 3 - We are taking the choice away from users > After I stopped and thought about it, there are plenty of scenarios where > people want epel for just one or two packages, which do not require crb. > > 4 - All the many small side cases. > auto-enabling crb will have bugs. RHEL and it's clones are in too many odd > places for us to not hit some odd use cases we didn't expect. We'd have to > keep fixing the scripts. I will just add that both of these issues can be remedied. For my part, I have suggested edits on Troy's epel-release PR[1] to allow an opt-out mechanism and make the script more robust. Users who are knowledgeable enough to check whether the packages they use need CRB should also be able to opt out. I think the real question is whether epel-release should be touching subscriptions/repos it doesn't own in the first place (Troy's question #2). Another option would be to have the %post script only print a warning if CRB/Powertools isn't enabled instead of actually enabling it. This won't help with automated deployments[2], but it should catch some cases. [1]: https://src.fedoraproject.org/rpms/epel-release/pull-request/21 [2]: With my ansible hat on, it also doesn't help that the two most popular epel roles on Ansible Galaxy don't enable CRB/Powertools, but I disgress. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@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-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
On Sat, Jun 4, 2022 at 21:17 Manuel Wolfshant wrote: > On 6/5/22 03:47, Stephen Smoogen wrote: > > > > On Sat, 4 Jun 2022 at 18:54, Neal Gompa wrote: > >> On Sat, Jun 4, 2022 at 10:52 PM Troy Dawson wrote: >> > >> > When I first created the EPEL issue to auto-enable crb repo[1] I was >> only thinking of CAN we do it. I wasn't thinking SHOULD we do it. >> > We've come to the point that we actually can do it. But before we go >> down that road, I wanted to take a step back and ask, should we do it. >> > >> > The more I think about it, the more I think we shouldn't auto-enable >> the crb repo for epel8 and epel9. Here are my reasons why. >> > >> > 1 - The need to auto-enable crb isn't as big as it was before. >> > At the time that I wrote that issue, I was getting quite alot of bugs / >> pings / emails about epel packages not being installable. I think on >> average about 2 a month. >> > With epel being in fedora-docs, and with Carl's re-write of how to >> enable epel, that number has dropped significantly. I possibly still >> average one a month, but that's an average over a year, with most of them >> being last year. >> > In short, I believe the documentation is better, and easier to find, >> allowing people to enable crb on their own, without automation. >> > >> > 2 - crb isn't an epel repo >> > We really shouldn't be messing with other repo's that we, epel, don't >> own. >> > >> > 3 - We are taking the choice away from users >> > After I stopped and thought about it, there are plenty of scenarios >> where people want epel for just one or two packages, which do not require >> crb. >> > >> > 4 - All the many small side cases. >> > auto-enabling crb will have bugs. RHEL and it's clones are in too many >> odd places for us to not hit some odd use cases we didn't expect. We'd >> have to keep fixing the scripts. >> > >> > I could go into more explanation on each of those things, but in the >> end, I've talked myself out of wanting to auto-enable crb for epel8 and >> epel9. >> > But I also wanted to get others' thoughts before I close the bug and >> pull request. >> > >> > What do others think? >> > >> >> Let me start with examples that I get *regularly*: Pagure fails to >> install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown is >> not available. KDE Plasma fails to install because of a mass of >> missing dependencies. >> >> >> To be crystal clear, I would like this fixed for at least the majority >> of cases and gracefully fail when it can't be fixed. >> >> > The issue is going to be that an RPM which changes outside subscriptions > will probably be an auditable finding for a lot of sites. It is one of the > reasons this has been considered bad form in the past and would probably > cause a lot of requests that it be made optional, removed, OR epel black > listed. It doesn't matter if we all think that would be a silly finding, > changes like this are considered security issues at various sites > especially if for the last 15 years, epel-release has not done something > like that and so had been 'approved' for use. > > At best I could see an optional side package > `epel-release-enable-other-repo` or some similar name which just has these > changes and is not pulled in by default and requires epel-release. Thus you > could tell people to install `epel-release-enable-crb` and would get > packages and if people have reports of broken packages you tell them to > install this which will do the correct repo changes. > > > I really do not want to bash anyone but for _ages_ and I really mean a > long long time, Ubuntu and Debian know how to be friendly and fail > gracefully, suggesting the exact command that must be used when a package > fails to get installed because it is not found. It's not like it is so hard > to tell the user to run "dnf config-manager --set-enabled > $whateverrepoisneeded" or even better continue with " Do you want me to > enable it for you now ?" > > That is built into how deb and apt are written versus rpm. Doing out put like this in rpm’s breaks a lot of automation which is built around the idea that rpm are not saying things like that. > wolfy > ___ > epel-devel mailing list -- epel-devel@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-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to
