Re: Modularity and the system-upgrade path

On Thu, 2019-10-17 at 09:47 -0400, Stephen Gallagher wrote: > On Wed, Oct 16, 2019 at 9:39 PM Kevin Kofler wrote: > > So it looks like I did not describe clearly enough what my proposed > > enable_modules=0 flag would do. ("Disable all module code" was apparently > > too vague.) > > > > How I

Re: Modularity and the system-upgrade path

This does not work for server components and is not generalizable. For > example, you cannot have multiple versions of Samba running on the same > system. You cannot have multiple versions of FreeIPA running on the same > system either. These server components have requirements beyond package >

Re: [Mindshare] Re: [Ambassadors] FOSDEM

Hello Ankur, Matthew and Brian! > > > Is there anyone interested in owning this? If so, can you put together a > > > proposal for Mindshare? > They have a research track this year, so it'll be great to get some > NeuroFedora presence there. I would love to represent Fedora and Neuro-Fedora at

Re: Modularity and the system-upgrade path

17.10.2019, 17:15, "Stephen John Smoogen" : > On Wed, 16 Oct 2019 at 20:27, Stephen Gallagher wrote: >> > >>  So, literally every word of this is wrong. The negative feedback is >>  not "overwhelming". It is approximately four noisy individuals, all of >>  whom have expressed zero interest in

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

On Thu, Oct 17, 2019 at 8:09 AM Stephen Gallagher wrote: > > On Thu, Oct 17, 2019 at 7:53 AM Miro Hrončok wrote: > > > That was a representative example. I came up with it at 11pm after a > > > long day. Don't read too much into the specifics. The point was that > > > builds may require newer or

Re: Next F31 push?

Adam Williamson wrote: > As things stand I'm reasonably confident we'll be able to Go next week, I don't see a fix for the module upgrade path blocker in sight any time soon. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org

Re: Next F31 push?

On 2019-10-18 09:18, Leigh Scott wrote: On Fri, 2019-10-18 at 07:50 +0200, Kevin Kofler wrote: I mean, in the end it would be self-defeating, because the high chance that it would introduce more problems would just mean we'd need to freeze again for longer. So you get a working ISO for

Re: Building eBPF programs

* Steve Grubb: > I am in the process of building a new version of suricata, and IDS program > that watches network traffic. It has a new module that uses eBPF for high > speed > network packet categorization. When building, it uses the following command: > > /usr/bin/clang -Wall -Iinclude -O2

Re: Modularity and the system-upgrade path

On pe, 18 loka 2019, Kevin Kofler wrote: Alexander Bokovoy wrote: This does not work for server components and is not generalizable. For example, you cannot have multiple versions of Samba running on the same system. You cannot have multiple versions of FreeIPA running on the same system

Re: Next F31 push?

> On Fri, 2019-10-18 at 07:50 +0200, Kevin Kofler wrote: > > I mean, in the end it would be self-defeating, because the high chance > that it would introduce more problems would just mean we'd need to > freeze again for longer. > So you get a working ISO for release then break it by releasing

Re: Modularity and the system-upgrade path

On to, 17 loka 2019, Orion Poplawski wrote: You could install the ipa-client package and enroll a system into IPA from a kickstart in RHEL 7 too.. Without modules. That's what I've deployed for the environments I support, for example. Using a module is not required there. That wasn't the

Re: Modularity and the system-upgrade path

On pe, 18 loka 2019, Kevin Kofler wrote: Alexander Bokovoy wrote: That's my point -- requiring parallel installability is not really a MUST, especially in my area. You are driving this requirement as if nothing else could solve your issues. I am not. This is a strawman. What I am saying is

Re: Modularity and the system-upgrade path

Alexander Bokovoy wrote: > That's my point -- requiring parallel installability is not really a > MUST, especially in my area. You are driving this requirement as if > nothing else could solve your issues. I am not. This is a strawman. What I am saying is that modules on which other modules have

Re: Next F31 push?

On Fri, 2019-10-18 at 07:50 +0200, Kevin Kofler wrote: > Sérgio Basto wrote: > > AFAIK , the logic is request an freeze exception , or next push will be > > just after F31 GA . > > I'd like have one unfreeze and push all packages that are waiting to be > > pushed to stable, when we have an NO-GO.

Re: Next F31 push?

On 18. 10. 19 11:22, Kevin Kofler wrote: Adam Williamson wrote: As things stand I'm reasonably confident we'll be able to Go next week, I don't see a fix for the module upgrade path blocker in sight any time soon. Actually:

Re: FOSDEM

I'm happy to help. Also I can get swag from Brno (though the flight ticket might be more expensive). I was there last year so I still remember how to do it more or less :) On Wed, Oct 16, 2019 at 6:32 PM Brian (bex) Exelbierd wrote: > > Hi All, > > I haven't heard anyone mention FOSDEM yet.

Re: Modularity and the system-upgrade path

> > > I'm comfortable saying that most Fedora users are not installing the > distro > just to support one specific application, as one might with RHEL or > CentOS, > but to benefit from the Four Foundations of Fedora, in this case the most > important ones being Freedom, Features and First. >

Fedora-31-20191018.n.0 compose check report

No missing expected images. Failed openQA tests: 4/153 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-31-20191017.n.0): ID: 472059 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/472059 ID: 472063 Test: x86_64

Re: [Mindshare] Re: [Ambassadors] FOSDEM

On Fri, Oct 18, 2019 at 2:37 PM Aniket Pradhan wrote: > > Hello Ankur, Matthew and Brian! > > > > > Is there anyone interested in owning this? If so, can you put together > > > > a > > > > proposal for Mindshare? > > > They have a research track this year, so it'll be great to get some > >

Re: Low Memory Detection on Linux

On Fri, Oct 18, 2019 at 11:48 AM Martin Stransky wrote: > > Folks, > > do you know if there's any reliable and widely available way how to > measure memory usage on Linux by user space application (Firefox in this > case) and detect low-memory state?

Re: Next F31 push?

On Thu, Oct 17, 2019 at 10:25 PM Sérgio Basto wrote: > Hi, > AFAIK , the logic is request an freeze exception , or next push will be > just after F31 GA . > I'd like have one unfreeze and push all packages that are waiting to be > pushed to stable, when we have an NO-GO. > I already made this

Re: Low Memory Detection on Linux

I'm not familiar with this topic, but I can point you to what WebKit does: https://trac.webkit.org/browser/webkit/trunk/Source/WebKit/UIProcess/linux/MemoryPressureMonitor.cpp https://trac.webkit.org/browser/webkit/trunk/Source/WTF/wtf/linux/MemoryPressureHandlerLinux.cpp

Re: Low Memory Detection on Linux

do you know if there's any reliable and widely available way how to measure memory usage on Linux by user space application (Firefox in this case) and detect low-memory state? gmemusage is a tool to show memory usage per userspace application. top can show low memory state. so long MUFTI

Re: Modularity and the system-upgrade path

On Fri, 2019-10-18 at 11:39 +0300, Alexander Bokovoy wrote: > On to, 17 loka 2019, Orion Poplawski wrote: > > > > You could install the ipa-client package and enroll a system into IPA > > > > from a > > > > kickstart in RHEL 7 too.. Without modules. That's what I've deployed > > > > for the > >

Re: Modularity and the system-upgrade path

Or, even better (or worse): Sombody installs GIMP via GNOME Software, > and under the hood, dnf does its magic and installs gimp from the > module, which might depend on another, even non-default module, etc. > But then, what will happen when that module is EOL, and the user has > never even

Re: Low Memory Detection on Linux

On 10/18/19 8:09 AM, J. Scheurich wrote: gmemusage is a tool to show memory usage per userspace application. top can show low memory state. I remember gmemusage from the SGI days and remember using it on Linux too, but currently yum whatprovides */gmemusage claims there are No Matches

Re: Building eBPF programs

On Friday, October 18, 2019 4:39:10 AM EDT Florian Weimer wrote: > * Steve Grubb: > > I am in the process of building a new version of suricata, an IDS > > program that watches network traffic. It has a new module that uses eBPF > > for high speed network packet categorization. When building, it

Re: Building eBPF programs

Once upon a time, Steve Grubb said: > Not sure how to proceed. I suspect this will be a bigger problem as more > people start to take advantage of the eBPF facility. I think the issue is that you are building with clang, not gcc. gcc defines __x86_64__ by default (on the appropriate systems of

Re: Modularity and the system-upgrade path

On Thu, 2019-10-17 at 14:44 -0600, Orion Poplawski wrote: > On 10/17/19 2:35 PM, Adam Williamson wrote: > > On Thu, 2019-10-17 at 09:32 -0700, John M. Harris Jr wrote: > > > On Thursday, October 17, 2019 1:59:19 AM MST Alexander Bokovoy wrote: > > > > The one thing we are using default modular

Re: Building eBPF programs

On 18/10/2019 14:33, Chris Adams wrote: Once upon a time, Steve Grubb said: Not sure how to proceed. I suspect this will be a bigger problem as more people start to take advantage of the eBPF facility. I think the issue is that you are building with clang, not gcc. gcc defines __x86_64__ by

Re: Building eBPF programs

On 18/10/2019 14:59, Chris Adams wrote: Once upon a time, Tom Hughes said: Well I imagine clang will define it when targetting x86_64 output but in this case he is targetting BPF output instead. Adding -D__x86_64__ to the command line may be the quickest workaround for now though. Yes, but

Low Memory Detection on Linux

Folks, do you know if there's any reliable and widely available way how to measure memory usage on Linux by user space application (Firefox in this case) and detect low-memory state? Thanks, ma. --- Hi Vicky, all, our low-memory

Fedora 31 compose report: 20191018.n.0 changes

OLD: Fedora-31-20191017.n.0 NEW: Fedora-31-20191018.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 6 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded

Re: Building eBPF programs

Once upon a time, Tom Hughes said: > Well I imagine clang will define it when targetting x86_64 output > but in this case he is targetting BPF output instead. > > Adding -D__x86_64__ to the command line may be the quickest workaround > for now though. Yes, but in my VERY limited understanding,

Re: Next F31 push?

On Thu, Oct 17, 2019 at 11:02:51PM -0700, Adam Williamson wrote: > We do tweak the release schedule every so often, right now the freeze > periods are fairly long compared to the historical average. I do think > that's given us a benefit in terms of how little slippage we've had for > the last few

[HEADS-UP] maven 3.6 in rawhide next week

Hello Packagers, As some of you might not have been aware, the Stewardship SIG has been busy keeping the Java stack in fedora alive and working. We're now left with 0 build failures on all current branches of fedora for our 235 packages, and no open FTBFS / FTI or known security issues. We've

Re: Next F31 push?

On Fri, 2019-10-18 at 07:18 +, Leigh Scott wrote: > > On Fri, 2019-10-18 at 07:50 +0200, Kevin Kofler wrote: > > > > I mean, in the end it would be self-defeating, because the high chance > > that it would introduce more problems would just mean we'd need to > > freeze again for longer. > >

Re: Next F31 push?

On Fri, 2019-10-18 at 11:22 +0200, Kevin Kofler wrote: > Adam Williamson wrote: > > As things stand I'm reasonably confident we'll be able to Go next week, > > I don't see a fix for the module upgrade path blocker in sight any time > soon. There are three viable ones proposed in the bug, it's

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

Stephen John Smoogen writes: > On Thu, 17 Oct 2019 at 14:15, Randy Barlow > wrote: > >> Or better, can we employ a solution that another distribution has >> developed? > > Not without using their packaging system, their build system and their > other design choices. Working out slots would

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

On Fri, 2019-10-18 at 11:21 -0400, Robbie Harwood wrote: > Obviously we > can't use their code wholesale without migrating to APT, but as you > say, > the goal is to derive inspiration. I honestly think it should be on the table to consider switching to a different packaging technology than

CPE Weekly: 2019-10-18

Hi everyone, Welcome to the CPE team weekly project update mail! *Background:** The Community Platform Engineering group is the Red Hat team combining IT and release engineering from Fedora and CentOS. Our goal is to keep core servers and services running and maintained, build releases, and

Re: Modularity and the system-upgrade path

On Fri, Oct 18, 2019 at 01:03:24PM +0200, Lukas Ruzicka wrote: > Exactly ... this is what I believe, too. I think that Fedora users put > Fedora on their desktops and laptops to be creative in many ways of > creativity. Some make make music, some enhance pictures, some model in > Blender, cut

Re: Next F31 push?

On 18. 10. 19 17:48, Adam Williamson wrote: On Fri, 2019-10-18 at 11:22 +0200, Kevin Kofler wrote: Adam Williamson wrote: As things stand I'm reasonably confident we'll be able to Go next week, I don't see a fix for the module upgrade path blocker in sight any time soon. There are three

Re: Modularity and the system-upgrade path

On Fri, 2019-10-18 at 13:05 +0200, Lukas Ruzicka wrote: > > > Or, even better (or worse): Sombody installs GIMP via GNOME > > Software, > > > > and under the hood, dnf does its magic and installs gimp from the > > > > module, which might depend on another, even non-default module, > > etc. > >

Re: FOSDEM

I would also like to throw my name in the pot for FOSDEM; it would be a great time to share and promote the Fedora Amateur Radio Sig that has been recently getting a makeover. I'd be glad to help with setup/tear-down as well. Geoff Marr IRC: coremodule On Fri, Oct 18, 2019 at 7:55 AM Igor

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

On Fri, Oct 18, 2019 at 11:43 AM Randy Barlow wrote: > > On Fri, 2019-10-18 at 11:21 -0400, Robbie Harwood wrote: > > Obviously we > > can't use their code wholesale without migrating to APT, but as you > > say, > > the goal is to derive inspiration. > > But yeah as you say here, my original

Re: Building eBPF programs

Did you check the following? https://patchwork.ozlabs.org/patch/870656/ https://code.forksand.com/oisf/suricata/commit/7906c521cdde5b1d0eb3ce379b8e343c3055653f Iñaki On Fri, 18 Oct 2019 at 15:22, Steve Grubb wrote: > > On Friday, October 18, 2019 4:39:10 AM EDT Florian Weimer wrote: > > *

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

On 18.10.19 17:21, Robbie Harwood wrote: > While you're right that the solutions from source distros (i.e., NixOS > and Gentoo) would be very hard to adapt, binary distros have also solved > this problem in different ways. I'm most familiar with Debian's > solution (virtual packages[2],

[Test-Announce] Fedora 31 Branched 20191018.n.0 nightly compose nominated for testing

Announcing the creation of a new nightly release validation test event for Fedora 31 Branched 20191018.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki

Re: Building eBPF programs

On Friday, October 18, 2019 9:59:11 AM EDT Chris Adams wrote: > Once upon a time, Tom Hughes said: > > > Well I imagine clang will define it when targetting x86_64 output > > but in this case he is targetting BPF output instead. > > > > Adding -D__x86_64__ to the command line may be the

Re: Next F31 push?

On Fri, Oct 18, 2019 at 09:13:22PM +0200, Kevin Kofler wrote: > This would be a lot less of an issue if we were more actively promoting the > respins that are already being done. Yeah, this is a Fedora Council goal -- we'd like for that SIG to easily be able to make them in infrastructure, and

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

Christopher Engelhard writes: > On 18.10.19 17:21, Robbie Harwood wrote: > >> While you're right that the solutions from source distros (i.e., NixOS >> and Gentoo) would be very hard to adapt, binary distros have also solved >> this problem in different ways. I'm most familiar with Debian's >>

Re: Next F31 push?

Miro Hrončok wrote: > Actually: > https://github.com/rpm-software-management/dnf-plugins-extras/pull/166 Ewww! This kind of hacks should NEVER be accepted in a production distribution! This hack will also NOT fix the issue for users like me who use dnf directly rather than the system-upgrade

Re: CPE Weekly: 2019-10-18

Hi Everyone, Just an FYI, there was a dead link contained in the update - I send these updates to both internal and external mailing list and that one was for internal audiences only. It was an internal briefing on CentOS Streams for staff that had missed the public announcements and just

Re: Next F31 push?

On Fri, 2019-10-18 at 21:19 +0200, Kevin Kofler wrote: > Miro Hrončok wrote: > > Actually: > > https://github.com/rpm-software-management/dnf-plugins-extras/pull/166 > > Ewww! This kind of hacks should NEVER be accepted in a production > distribution! Eh. I don't think it's a particularly bad

Fedora 31 Final blocker status email #6

We will try again for a 29 October release. Action summary Accepted blockers - 1. distribution — Cannot upgrade to Fedora 31: package exa-0.9.0-2.module_f31+5365+04413d87.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed —

Re: Next F31 push?

On Fri, Oct 18, 2019 at 09:19:15PM +0200, Kevin Kofler wrote: > Miro Hrončok wrote: > > Actually: > > https://github.com/rpm-software-management/dnf-plugins-extras/pull/166 > > Ewww! This kind of hacks should NEVER be accepted in a production > distribution! > > This hack will also NOT fix the

Re: libdav1d SONAME bump

On Friday, 11 October 2019 16:10:55 CEST you wrote: > Hello, > > Dav1d 0.5.0 was published today and brings a SONAME bump from libdav1d.so. > 2.0.0 to libdav1d.so.3.0.0. > I will be updating it next week on F31/32, consumers of these libraries > (ffmpeg, xine-lib, vlc) will need to rebuild their

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

On Fri, 2019-10-18 at 16:25 -0400, Robbie Harwood wrote: > Christopher Engelhard writes: > > > On 18.10.19 17:21, Robbie Harwood wrote: > > > > > While you're right that the solutions from source distros (i.e., NixOS > > > and Gentoo) would be very hard to adapt, binary distros have also solved

Fedora 32 System-Wide Change proposal: On-demand Side Tags

https://fedoraproject.org/wiki/Changes/OnDemandSideTags see also: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/4AS3PN23TOCBROA4RZN4TNDBZOP4VE2G/ = On-demand Side Tags = == Summary == Allow on-demand side tags, and allow packagers to a) tag whatever rpms as

Re: Building eBPF programs

* Steve Grubb: >> We certainly do not support building eBPF programs against glibc >> headers. There is no eBPF port of glibc, after all. > > Suricata made it through the Debian/Ubuntu build systems. So, that > leaves me trying to figure out how push this through ours since other > distros did

Re: Low Memory Detection on Linux

gmemusage is a tool to show memory usage per userspace application. top can show low memory state. I remember gmemusage from the SGI days and remember using it on Linux too, but currently yum whatprovides */gmemusage claims there are No Matches Found. Where did you get your gmemusage from?

Re: Next F31 push?

Adam Williamson wrote: > The other issue is that it's *less bad* for a bad update to get out as > a 0-day update than it is for it to be in the frozen compose set. Bugs > that get baked into the live images or the installer are there forever. > A bug that only goes out in an update can be replaced

FedoraRespin-30-updates-20191018.0 compose check report

Missing expected images: Soas live x86_64 Failed openQA tests: 2/31 (x86_64) ID: 472351 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/472351 ID: 472359 Test: x86_64 KDE-live-iso release_identification URL:

[Test-Announce] 2019-10-21 @ 16:00 UTC - Fedora 31 Blocker Review Meeting

# F31 Blocker Review meeting # Date: 2019-10-21 # Time: 16:00 UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We have 2 proposed Final blockers and 4 proposed Final freeze exception to review, so let's have a Fedora 31 blocker review meeting on Monday! If you have time

[Test-Announce] Proposal to CANCEL: 2019-10-21 Fedora QA Meeting

Hi folks! I'm proposing we cancel the QA meeting for Monday. Once again I don't think there's anything urgent right now and we're focused on F31 release testing right now (hopefully this will be the last week and we'll sign off the release). There will be a blocker review meeting. If you're aware

Re: Fedora 32 System-Wide Change proposal: On-demand Side Tags

On 19. 10. 19 0:30, Kevin Fenzi wrote: Can I make a strong suggestion/plea here? Could you meet with the folks working on rawhide multibuild gating and confirm all that process works with your change and then modify your change to just say 'requires multibuild rawhide gating' and only include

Re: libdav1d SONAME bump

Le ven. 18 oct. 2019 à 22:44, Robert-André Mauchin a écrit : > > On Friday, 11 October 2019 16:10:55 CEST you wrote: > > Hello, > > > > Dav1d 0.5.0 was published today and brings a SONAME bump from libdav1d.so. > > 2.0.0 to libdav1d.so.3.0.0. > > I will be updating it next week on F31/32,

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

3) We need to get the policy I described above written onto -stone > tablets- the Packaging Guidelines and then we need to go and make any > stream that isn't compliant with it a non-default stream. > Thank you. If we want to use default streams, then we indeed need a strict policy on how they

Re: Next F31 push?

Adam Williamson wrote: > Eh. I don't think it's a particularly bad hack at all. It's simple, > labelled, we know what it does, and it's inherently limited (it'll > never do anything outside of an upgrade to F31). That's exactly what makes this such a bad hack in my eyes. It "fixes" one

Re: Fedora 32 System-Wide Change proposal: On-demand Side Tags

Can I make a strong suggestion/plea here? Could you meet with the folks working on rawhide multibuild gating and confirm all that process works with your change and then modify your change to just say 'requires multibuild rawhide gating' and only include in your change the things that are

Re: Next F31 push?

On Sat, 2019-10-19 at 00:11 +0200, Kevin Kofler wrote: > Adam Williamson wrote: > > Eh. I don't think it's a particularly bad hack at all. It's simple, > > labelled, we know what it does, and it's inherently limited (it'll > > never do anything outside of an upgrade to F31). > > That's exactly

pghmcfc pushed to perl-Mail-Transport (epel8). "3.000"

Notification time stamped 2019-10-18 13:27:56 UTC From f9044a476b2e58a28fd998549cfa8a056edc7f7b Mon Sep 17 00:00:00 2001 From: Tom Callaway Date: Mar 20 2017 14:11:52 + Subject: 3.000 --- diff --git a/.gitignore b/.gitignore index e69de29..fc65ab5 100644 --- a/.gitignore +++ b/.gitignore

[Bug 1762271] perl-Mail-Message for EL8

https://bugzilla.redhat.com/show_bug.cgi?id=1762271 Paul Howarth changed: What|Removed |Added Status|NEW |ASSIGNED

[Bug 1762449] perl-Type-Tiny for EL8

https://bugzilla.redhat.com/show_bug.cgi?id=1762449 Paul Howarth changed: What|Removed |Added CC||p...@city-fan.org

[Bug 1762969] [RFE] EPEL8 branch of perl-Crypt-PasswdMD5

https://bugzilla.redhat.com/show_bug.cgi?id=1762969 Paul Howarth changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Paul

[Bug 1762269] perl-Email-Abstract for EL 8

https://bugzilla.redhat.com/show_bug.cgi?id=1762269 Paul Howarth changed: What|Removed |Added Status|NEW |ASSIGNED CC|

New Pythons in need for karma

Get Python 3.7.5 and 3.8.0 while they're hot: https://bodhi.fedoraproject.org/updates/?packages=python3=testing https://bodhi.fedoraproject.org/updates/?packages=python38=testing -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel

[Bug 1762928] [RFE] EPEL-8 branch for perl-TeX-Hyphen

https://bugzilla.redhat.com/show_bug.cgi?id=1762928 Jan Pazdziora changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Jan

pghmcfc pushed to perl-Mail-Message (epel8). "Add bootstrap for EPEL-8, spec tidy-up (..more)"

Notification time stamped 2019-10-18 08:50:57 UTC From 31ca140c2aabbbc8004228c3292544007561baa2 Mon Sep 17 00:00:00 2001 From: Paul Howarth Date: Oct 18 2019 08:48:50 + Subject: Add bootstrap for EPEL-8, spec tidy-up - Use author-independent source URL - Classify buildreqs by usage - Drop

pghmcfc pushed to perl-Mail-Transport (master). "Spec tidy-up (..more)"

Notification time stamped 2019-10-18 08:52:19 UTC From c6b3215f0113c444223960d1d97a31fc024f2beb Mon Sep 17 00:00:00 2001 From: Paul Howarth Date: Oct 18 2019 08:42:24 + Subject: Spec tidy-up - Use author-independent source URL - Classify buildreqs by usage - Drop redundant use of

[Bug 1754813] perl-WWW-Curl-4.17-20.fc31 FTBFS: Curl.xs:76:12: error: expected '{' before 'void'

https://bugzilla.redhat.com/show_bug.cgi?id=1754813 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #1 from

[Bug 1758483] perl-Crypt-OpenSSL-X509 for EL8

https://bugzilla.redhat.com/show_bug.cgi?id=1758483 Xavier Bachelot changed: What|Removed |Added Flags||needinfo?(wjhns174@hardaker

pghmcfc pushed to perl-Mail-Transport (epel8). "Merge branch 'master' into epel8"

Notification time stamped 2019-10-18 13:27:56 UTC From 5a06c2b6d74ee925c8452d39e828a867de4889f5 Mon Sep 17 00:00:00 2001 From: Paul Howarth Date: Oct 18 2019 13:27:35 + Subject: Merge branch 'master' into epel8 --- diff --git a/.gitignore b/.gitignore index e69de29..b713ac6 100644 ---

pghmcfc pushed to perl-Mail-Transport (epel8). "Spec tidy-up (..more)"

Notification time stamped 2019-10-18 13:27:56 UTC From c6b3215f0113c444223960d1d97a31fc024f2beb Mon Sep 17 00:00:00 2001 From: Paul Howarth Date: Oct 18 2019 08:42:24 + Subject: Spec tidy-up - Use author-independent source URL - Classify buildreqs by usage - Drop redundant use of

pghmcfc pushed to perl-Mail-Transport (epel8). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild (..more)"

Notification time stamped 2019-10-18 13:27:56 UTC From 8bb25e507b5d6f3a9c6f200ca1bb79898931d887 Mon Sep 17 00:00:00 2001 From: Fedora Release Engineering Date: Jul 26 2019 04:28:31 + Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild Signed-off-by: Fedora Release

pghmcfc pushed to perl-Mail-Transport (epel8). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild (..more)"

Notification time stamped 2019-10-18 13:27:56 UTC From cc602fcdbd7ad223c4d9954e5132f034bde11c8a Mon Sep 17 00:00:00 2001 From: Fedora Release Engineering Date: Jul 13 2018 18:22:38 + Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild Signed-off-by: Fedora Release

pghmcfc pushed to perl-Mail-Transport (epel8). "3.004 bump"

Notification time stamped 2019-10-18 13:27:56 UTC From b07e72230161801772852c683b4a05c9e2e28519 Mon Sep 17 00:00:00 2001 From: Jitka Plesnikova Date: Jun 06 2019 09:04:23 + Subject: 3.004 bump --- diff --git a/.gitignore b/.gitignore index a586bf5..b713ac6 100644 --- a/.gitignore +++

pghmcfc pushed to perl-Mail-Transport (epel8). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild (..more)"

Notification time stamped 2019-10-18 13:27:56 UTC From 6f69f11b83462922e5eb7741889bf91c6028d4a3 Mon Sep 17 00:00:00 2001 From: Fedora Release Engineering Date: Feb 01 2019 22:04:47 + Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild Signed-off-by: Fedora Release

pghmcfc pushed to perl-Mail-Transport (epel8). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild"

Notification time stamped 2019-10-18 13:27:56 UTC From bdffd318ce22bea4cb94a5884f612bed09ce460b Mon Sep 17 00:00:00 2001 From: Fedora Release Engineering Date: Jul 27 2017 04:50:05 + Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild --- diff --git

pghmcfc pushed to perl-Mail-Transport (epel8). "3.002 bump"

Notification time stamped 2019-10-18 13:27:56 UTC From f992cf2408be7e01668810c4ee2ca7eff5e2bf8a Mon Sep 17 00:00:00 2001 From: Jitka Plesnikova Date: Jan 29 2018 11:40:45 + Subject: 3.002 bump --- diff --git a/.gitignore b/.gitignore index fc65ab5..8846b49 100644 --- a/.gitignore +++

pghmcfc pushed to perl-Mail-Transport (epel8). "Perl 5.28 rebuild"

Notification time stamped 2019-10-18 13:27:56 UTC From cb50e1305888ca80642e6d2698183c03161a3295 Mon Sep 17 00:00:00 2001 From: Jitka Plesnikova Date: Jun 29 2018 21:16:05 + Subject: Perl 5.28 rebuild --- diff --git a/perl-Mail-Transport.spec b/perl-Mail-Transport.spec index

pghmcfc pushed to perl-Mail-Transport (epel8). "3.003"

Notification time stamped 2019-10-18 13:27:56 UTC From 0ddea0155a0bbe797e2088e45dfc2ff58c6deb96 Mon Sep 17 00:00:00 2001 From: Tom Callaway Date: Sep 05 2018 17:25:06 + Subject: 3.003 --- diff --git a/.gitignore b/.gitignore index 8846b49..a586bf5 100644 --- a/.gitignore +++ b/.gitignore

pghmcfc pushed to perl-Mail-Transport (epel8). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild (..more)"

Notification time stamped 2019-10-18 13:27:56 UTC From a6f23be32126f4cd10b7d3fc10ea79277dd346c1 Mon Sep 17 00:00:00 2001 From: Fedora Release Engineering Date: Feb 08 2018 22:38:47 + Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild Signed-off-by: Fedora Release

pghmcfc pushed to perl-Mail-Transport (epel8). "Perl 5.26 rebuild"

Notification time stamped 2019-10-18 13:27:56 UTC From 2e59c2ea41a73ab60ebce05e330534413f8fae0c Mon Sep 17 00:00:00 2001 From: Jitka Plesnikova Date: Jun 07 2017 09:36:57 + Subject: Perl 5.26 rebuild --- diff --git a/perl-Mail-Transport.spec b/perl-Mail-Transport.spec index

pghmcfc pushed to perl-Mail-Transport (epel8). "Perl 5.30 rebuild"

Notification time stamped 2019-10-18 13:27:56 UTC From 677603ac7d6f345702d7345567869a999c2fdfbf Mon Sep 17 00:00:00 2001 From: Jitka Plesnikova Date: May 31 2019 14:11:31 + Subject: Perl 5.30 rebuild --- diff --git a/perl-Mail-Transport.spec b/perl-Mail-Transport.spec index

pghmcfc pushed to perl-Mail-Transport (epel8). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2019-10-18 13:27:56 UTC From 2eec826ce4fa3fb3c966464090b585a4cf0c460f Mon Sep 17 00:00:00 2001 From: Petr Písař Date: Jun 04 2018 12:13:59 + Subject: cpan.org addresses moved to MetaCPAN --- diff

pghmcfc pushed to perl-Mail-Transport (epel8). "Remove obsolete Group tag (..more)"

Notification time stamped 2019-10-18 13:27:56 UTC From f7582e43e2e844e80d5fb381de07dc6a02ac39e0 Mon Sep 17 00:00:00 2001 From: Igor Gnatenko Date: Jan 28 2019 19:24:30 + Subject: Remove obsolete Group tag References: https://fedoraproject.org/wiki/Changes/Remove_Group_Tag --- diff --git

pghmcfc pushed to perl-Mail-Transport (epel8). "perl dependency renamed to perl-interpreter "

Notification time stamped 2019-10-18 13:27:56 UTC From 6215e1679a0fee6c0334fd6c4e9f0b49f26db870 Mon Sep 17 00:00:00 2001 From: Petr Písař Date: Jul 12 2017 12:06:16 + Subject: perl dependency renamed to perl-interpreter

[EPEL-devel] How do we want to handle ruby gems in EPEL8?

Do we have a plan for how we want to handle ruby gems in EPEL8? ruby is a module in RHEL8 so it seems like we would want to do that it a modular way, which also suggests the possibility of a group effort to produce a "EPEL8 rubygems" module. Or just dump them into the main repo, at least

  1   2   >