https://bugzilla.redhat.com/show_bug.cgi?id=1741756
Bug ID: 1741756
Summary: Request to build ack for EPEL 8
Product: Fedora EPEL
Version: epel8
Status: NEW
Component: ack
Assignee: robinlee.s...@gmail.com
https://bugzilla.redhat.com/show_bug.cgi?id=1739463
Petr Pisar changed:
What|Removed |Added
Fixed In Version|perl-Pod-Perldoc-3.28.01-44 |perl-Pod-Perldoc-3.28.01-44
Richard Shaw wrote:
> Perhaps a partial solution is encouraging people to ask for help. Sure
> it's easy to post to the devel list but sometimes it's difficult to admit
> you need help :)
IMHO, it should be the job of those people who broke the packages to fix
them. E.g., if yet another
Miro Hrončok wrote:
> Once more: The one package you keep talking about stays.
The python2 package stays, but we have to jump through completely
unreasonable hoops to be allowed to actually use it.
Kevin Kofler
___
devel mailing list --
(Moving to EPEL list)
On 8/15/19 10:22 PM, Richard Shaw wrote:
I assume this is because LibRaw is available in RHEL but only for x86_64
and ppc64le?
So I'm assuming there is some sort of procedure to build only for s390x
and aarch64 for EPEL?
Yes, many libs appear to be missing on those
I assume this is because LibRaw is available in RHEL but only for x86_64
and ppc64le?
So I'm assuming there is some sort of procedure to build only for s390x and
aarch64 for EPEL?
Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
https://fedorapeople.org/groups/389ds/ci/nightly/2019/08/16/report-389-ds-base-1.4.1.6-20190815gitca915d5.fc30.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
On Fri, Aug 16, 2019 at 11:56:43AM +1000, William Brown wrote:
> Sure thing, I'll look soon :)
Great, thanks!
Forgot to put the link:
https://pagure.io/389-ds-base/pull-request/50549
>
> > On 16 Aug 2019, at 11:55, Simon Pichugin wrote:
> >
> > Hi team,
> > I have a big chunk of work ready
Sure thing, I'll look soon :)
> On 16 Aug 2019, at 11:55, Simon Pichugin wrote:
>
> Hi team,
> I have a big chunk of work ready for review.
> The main part is done and I just need to polish it a bit more and add
> more tests.
>
> In a mean while...
>
> William, could you please take a look?
Hi team,
I have a big chunk of work ready for review.
The main part is done and I just need to polish it a bit more and add
more tests.
In a mean while...
William, could you please take a look?
The lib389 part for Accounts is much bigger now and has much more to
offer.
Thanks,
Simon
Does it make sense for packages to wait in testing for two weeks when they
are new packages?
For example, all the packages I'm building for the first time in epel8...
Even outside of new packages I rarely get karma for my Fedora packages,
much less for my EPEL packages and two weeks is a "long
On Thu, Aug 15, 2019 at 1:33 PM Adam Williamson
wrote:
> Or just fix it so it damn well builds. Even if *you* don't need to use
> it. I mean, is it so hard? I get *itchy* if I have an FTBFS bug on one
> of my packages for three days. I can't imagine letting one sit there
> for six months!
>
I
Please disregard, just found the thread covering this.
Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Now that f32 has branched when I build packages for f31 I can't add them to
a bodhi update nor are they added automatically.
Is f31 acting like pre-gating rawhide or are the packages going into the
nether?
Thanks,
Richard
___
devel mailing list --
SIGs are more of a mediocrity so Bob may be one of the founders but whether
he's still active or not is irrelevant. :) Just edit the wiki to join and
dig in!
I took over maintenance of a lot of the packages NBEMS suite (fldigi,
flrig, flmsg, etc), QSSTV, CQRLOG, wsjtx, js8call, the AX.25 stack
On Fri, Aug 16, 2019 at 7:48 AM Chris Murphy wrote:
>
> On Thu, Aug 15, 2019 at 2:19 PM Chris Murphy wrote:
> >
> > [ 718.068633] fmac.local kernel: SLUB: Unable to allocate memory on
> > node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
> > [ 718.068636] fmac.local kernel: cache: page->ptl, object
Troy,
I did fedpkg request-branch epel8 and it did indeed make two issues.
Looking back at all issues that I previously had requested, last time it
only made one issues for epel8 and did not make the epel8-playground
issue. I wonder how many other people had or will have the same
problem. I
On Thu, Aug 15, 2019 at 2:19 PM Chris Murphy wrote:
>
> [ 718.068633] fmac.local kernel: SLUB: Unable to allocate memory on
> node -1, gfp=0x900(GFP_NOWAIT|__GFP_ZERO)
> [ 718.068636] fmac.local kernel: cache: page->ptl, object size: 72,
> buffer size: 72, default order: 0, min order: 0
> [
> My qemu boot command is currently:
> qemu-system-ppc64 -m 2048 -smp 2 -machine pseries -cpu power9 -hda -cdrom
Looks like you are running an LE image in the BE machine:
try qemu-system-ppc64le
___
devel mailing list -- devel@lists.fedoraproject.org
On 8/15/19 7:44 AM, Alexander Bokovoy wrote:
> On to, 15 elo 2019, Kaleb Keithley wrote:
>> On Thu, Aug 15, 2019 at 10:21 AM Alexander Bokovoy
>> wrote:
>>
>>> On to, 15 elo 2019, Kaleb Keithley wrote:
>>> >I've tried to submit a build on f31 to testing, using both the cli
>>> and via
>>> >the
On 8/15/19 3:18 AM, Dave Love wrote:
> I've tried to get a couple of epel8 branches created, and the tickets
> have been closed (twice in one case after I re-opened it) with "The
> branch in PDC already exists". (It worked for other packages.) I don't
> know what PDC is, but the branch
On Thu, Aug 15, 2019 at 1:51 AM Artem Tim wrote:
>
> BFQ scheduler help a lot with this issue. Using it on Fedora since 4.19
> kernel. Also there was previous discussion about make it default for
> Workstation
>
On Thu, Aug 15, 2019 at 9:14 AM Dridi Boukelmoune
wrote:
>
> > Well, it went through many revisions, and some of the bits are very
> > recent. For example, the pre-boot random seed stuff has been added in
> > v243, of which we only posted an -rc1 so far,
> >
> > However, the basics have been
The following builds have been pushed to Fedora EPEL 6 updates-testing
clustershell-1.8.2-1.el6
procenv-0.51-1.el6
python-regex-2019.06.08-1.el6
Details about builds:
clustershell-1.8.2-1.el6
Note: I am not an expert of gcc-objc.
I just see that it wasn't built with the RHEL8 gcc and I'm answering
accordingly.
Someone else might have different, better answers.
On Thu, Aug 15, 2019 at 9:14 AM Orion Poplawski wrote:
>
> What to do about missing gcc-objc from RHEL8?
Open a customer
The following builds have been pushed to Fedora EPEL 8 updates-testing
Lmod-8.1.10-2.el8
aalib-1.4.0-0.37.rc5.el8
byobu-5.129-2.el8
clustershell-1.8.2-1.el8
cros-guest-tools-1.0-0.16.20190815git4e1b573.el8
dar-2.6.5-2.el8
hdf-4.2.14-5.el8
libxsmm-1.13-2.el8
On 8/13/19 4:21 AM, Geoffrey Marr wrote:
> I have tried to join the Amateur Radio SIG twice, once in January, and
> again recently in August. The owner, Bob Jensen [0], does not seem to be
> around any longer in the Fedora community or the amateur radio community as
> his FCC license has expired
On Thu, 2019-08-15 at 09:33 +0200, Miro Hrončok wrote:
> On 15. 08. 19 7:39, Vít Ondruch wrote:
> > Of course you might consider this special case, but apparently all the
> > other people who speak up had different special cases.
>
> "special cases aren't special enough to break the rules"
>
> I
Will do.
--
Gwyn Ciesla
she/her/hers
in your fear, seek only peace
in your fear, seek only love
-d. bowie
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Thursday, August 15, 2019 1:06 PM, Kevin Fenzi wrote:
> On
On 8/15/19 11:03 AM, Stephen Gallagher wrote:
> On Thu, Aug 15, 2019 at 1:21 PM Gwyn Ciesla via devel <
> devel@lists.fedoraproject.org> wrote:
>
>> CCing Mohan.
>>
>>
>> --
>> Gwyn Ciesla
>> she/her/hers
>>
>> in your fear, seek only peace
>> in
On Thu, Aug 15, 2019 at 1:21 PM Gwyn Ciesla via devel <
devel@lists.fedoraproject.org> wrote:
> CCing Mohan.
>
>
> --
> Gwyn Ciesla
> she/her/hers
>
> in your fear, seek only peace
> in your fear, seek only love
> -d. bowie
>
> Sent with ProtonMail
On 8/14/2019 2:08 PM, Jason L Tibbitts III wrote:
"DS" == David Sommerseth writes:
DS> As I can see it, there is little benefit of removing lz4-static.
Isn't that entirely the decision of those maintaining the package? It's
still completely reasonable if they want to remove it for no other
CCing Mohan.
--
Gwyn Ciesla
she/her/hers
in your fear, seek only peace
in your fear, seek only love
-d. bowie
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Thursday, August 15, 2019 11:26 AM, Robert-André Mauchin
Notification time stamped 2019-08-15 17:06:33 UTC
From 067bde8a3f3a3c470e4f5a3766c3ac3861a0e415 Mon Sep 17 00:00:00 2001
From: Tom Callaway
Date: Aug 15 2019 17:02:49 +
Subject: update to 0.101
---
diff --git a/.gitignore b/.gitignore
index fe14587..6467202 100644
--- a/.gitignore
+++
Notification time stamped 2019-08-15 17:02:55 UTC
From 067bde8a3f3a3c470e4f5a3766c3ac3861a0e415 Mon Sep 17 00:00:00 2001
From: Tom Callaway
Date: Aug 15 2019 17:02:49 +
Subject: update to 0.101
---
diff --git a/.gitignore b/.gitignore
index fe14587..6467202 100644
--- a/.gitignore
+++
https://bugzilla.redhat.com/show_bug.cgi?id=1741574
Tom "spot" Callaway changed:
What|Removed |Added
Status|NEW |CLOSED
Resolution|---
On Wednesday, 14 August 2019 18:40:53 CEST Gwyn Ciesla via devel wrote:
> I believe Mohan has corrected this in git, but hasn't cut a release yet.
>
> --
> Gwyn Ciesla
> she/her/hers
>
> in your fear, seek only peace
> in your fear, seek only
On 8/15/19 7:31 AM, Troy Dawson wrote:
> Oh ... then there really is a problem. 12 hours (or longer) is a very
> long time for a package to not make it into the repo. The longest I
> had to wait was 4 hours, because I was doing things in the middle of
> the F31 mass rebuild.
> I'm afraid helping
On Thursday, 15 August 2019 12:18:12 CEST Dave Love wrote:
> I've tried to get a couple of epel8 branches created, and the tickets
> have been closed (twice in one case after I re-opened it) with "The
> branch in PDC already exists". (It worked for other packages.) I don't
> know what PDC is,
What to do about missing gcc-objc from RHEL8? Are there alternative compilers
yet that we can access? Will we have to package gcc-objc for EPEL8 separately?
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380
On Thu, 15 Aug 2019, Greg Hellings wrote:
I'm trying to track down a build error in my package that appears only on
ppc64le architectures in Rawhide. As I have no access to ppc64le machines,
I'm attempting to boot a VM with qemu. But when I get into the system many
of the more useful commands
Halp!
I'm trying to track down a build error in my package that appears only on
ppc64le architectures in Rawhide. As I have no access to ppc64le machines,
I'm attempting to boot a VM with qemu. But when I get into the system many
of the more useful commands aren't working properly. Like "dnf".
Hello,
It somehow slipped my radar that rubygem-taskjuggler had been retired.
Even though upstream isn't exactly active, the current git HEAD builds
fine. I've set it up in a COPR here now:
https://copr.fedorainfracloud.org/coprs/ankursinha/Takjuggler
The updated spec and sources are here on my
> Well, it went through many revisions, and some of the bits are very
> recent. For example, the pre-boot random seed stuff has been added in
> v243, of which we only posted an -rc1 so far,
>
> However, the basics have been around very early on, yes.
Well, from someone not versed in bios, efi and
On to, 15 elo 2019, Kaleb Keithley wrote:
On Thu, Aug 15, 2019 at 10:21 AM Alexander Bokovoy
wrote:
On to, 15 elo 2019, Kaleb Keithley wrote:
>I've tried to submit a build on f31 to testing, using both the cli and via
>the web site, and both are failing
>
>On the web site I get a popup with:
On Thu, Aug 15, 2019 at 10:21 AM Alexander Bokovoy
wrote:
> On to, 15 elo 2019, Kaleb Keithley wrote:
> >I've tried to submit a build on f31 to testing, using both the cli and via
> >the web site, and both are failing
> >
> >On the web site I get a popup with: Builds : Cannot find release
>
On to, 15 elo 2019, Kaleb Keithley wrote:
I've tried to submit a build on f31 to testing, using both the cli and via
the web site, and both are failing
On the web site I get a popup with: Builds : Cannot find release associated
with build: nfs-ganesha-2.8.2-5.fc31, tags: ['f31']
fedpkg update
I've tried to submit a build on f31 to testing, using both the cli and via
the web site, and both are failing
On the web site I get a popup with: Builds : Cannot find release associated
with build: nfs-ganesha-2.8.2-5.fc31, tags: ['f31']
fedpkg update gets: Could not execute update: Could not
On Wed, 14 Aug 2019 11:23:53 -0500, you wrote:
>So in summary, I guess I mostly support allowing packages which can't be
>rebuilt to stay in the distribution as long as they actually work and
>aren't causing maintenance burden elsewhere
On the other hand, unbuildable packages could be viewed as
Oh ... then there really is a problem. 12 hours (or longer) is a very
long time for a package to not make it into the repo. The longest I
had to wait was 4 hours, because I was doing things in the middle of
the F31 mass rebuild.
I'm afraid helping with this is above my fedora permissions. I
That's not the error I was getting. I gave it a try also, and got the
same error as you.
I'd say, re-request the branches. When they try to re-make a branch
that is already there, it will just say that the branch is already
there, if it isn't, then it will make it. No real harm in
https://bugzilla.redhat.com/show_bug.cgi?id=1739463
Petr Pisar changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
Fixed In Version|
https://bugzilla.redhat.com/show_bug.cgi?id=1740157
Jitka Plesnikova changed:
What|Removed |Added
Status|CLOSED |NEW
Resolution|RAWHIDE
On 15. 08. 19 14:40, Vít Ondruch wrote:
Interestingly enough, some people who complains the most about the process are
too busy to even switch the component to assigned ...
¯\_(ツ)_/¯
To rephrase: People have real work to do, so we should stop bothering them.
--
Miro Hrončok
--
Phone:
Dne 15. 08. 19 v 14:40 Vít Ondruch napsal(a):
>
>
> Dne 15. 08. 19 v 13:36 Pavel Valena napsal(a):
>> - Original Message -
>>> Sent: Thursday, August 15, 2019 12:42:02 PM
>>> Subject: Re: Let's revisit the FTBFS policy
>>>
>>> On 15. 08. 19 12:06, Vít Ondruch wrote:
At the end, if
On 15. 08. 19 14:33, Kevin Kofler wrote:
What is more work: maintaining one compatibility package, or porting
hundreds of packages (which are not getting ported upstream for whatever
reason) to the new incompatible version?
Once more: The one package you keep talking about stays.
--
Miro
https://bugzilla.redhat.com/show_bug.cgi?id=1741574
Bug ID: 1741574
Summary: Upgrade perl-DateTime-Calendar-Julian to 0.101
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-DateTime-Calendar-Julian
Assignee:
https://bugzilla.redhat.com/show_bug.cgi?id=1741573
Bug ID: 1741573
Summary: Upgrade perl-Data-ICal to 0.23
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Data-ICal
Assignee: rc040...@freenet.de
Dne 15. 08. 19 v 13:36 Pavel Valena napsal(a):
> - Original Message -
>> Sent: Thursday, August 15, 2019 12:42:02 PM
>> Subject: Re: Let's revisit the FTBFS policy
>>
>> On 15. 08. 19 12:06, Vít Ondruch wrote:
>>> At the end, if somebody cares about such cases, it should not be hard to
Nico Kadel-Garcia wrote:
> I've been seeing migrations like this for d decades, with major
> releases of many software tools. Preserving legacy versions, forever,
> is the precise opposite of "scalable".
What is more work: maintaining one compatibility package, or porting
hundreds of packages
Hi,
I am orphaning the following packages:
recode -- The upstream development of recode is not very active, and I
don't use it anymore.
python-bibtex -- The upstream develepoment is not very active and it
depends on python2.
See the bug at https://bugzilla.redhat.com/show_bug.cgi?id=1738118
- Original Message -
> Sent: Thursday, August 15, 2019 12:42:02 PM
> Subject: Re: Let's revisit the FTBFS policy
>
> On 15. 08. 19 12:06, Vít Ondruch wrote:
> > At the end, if somebody cares about such cases, it should not be hard to
> > discover and act upon them, i.e. bugging the
Hello,
Thanks for the links folks. If there are any others, please reply to
this e-mail today. I'll submit our request tomorrow.
--
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
signature.asc
Description:
On 15. 08. 19 12:06, Vít Ondruch wrote:
At the end, if somebody cares about such cases, it should not be hard to
discover and act upon them, i.e. bugging the maintainer, fixing them,
taking over the maintenance etc.
This part is problematic. Because it requires human action that can be seen as
Notification time stamped 2019-08-15 10:39:08 UTC
From 9680086198dc9542bec569d9e4992e5b0c189271 Mon Sep 17 00:00:00 2001
From: Paul Howarth
Date: Aug 15 2019 10:27:59 +
Subject: Update to 1.844
- New upstream release 1.844
- Completed validation running Kelp and Raisin apps with
Notification time stamped 2019-08-15 10:28:43 UTC
From 9680086198dc9542bec569d9e4992e5b0c189271 Mon Sep 17 00:00:00 2001
From: Paul Howarth
Date: Aug 15 2019 10:27:59 +
Subject: Update to 1.844
- New upstream release 1.844
- Completed validation running Kelp and Raisin apps with
I've tried to get a couple of epel8 branches created, and the tickets
have been closed (twice in one case after I re-opened it) with "The
branch in PDC already exists". (It worked for other packages.) I don't
know what PDC is, but the branch definitely isn't in git. An example is
Notification time stamped 2019-08-15 10:14:34 UTC
From 62b9138893d3dcb030bbf9d391a818846a703377 Mon Sep 17 00:00:00 2001
From: Paul Howarth
Date: Aug 15 2019 10:04:04 +
Subject: Update to 0.44
- New upstream release 0.44
- Replaced the use of B with XString if it is installed; the latter
Dne 15. 08. 19 v 9:33 Miro Hrončok napsal(a):
> On 15. 08. 19 7:39, Vít Ondruch wrote:
>> Of course you might consider this special case, but apparently all the
>> other people who speak up had different special cases.
>
> "special cases aren't special enough to break the rules"
They had either
Notification time stamped 2019-08-15 10:04:49 UTC
From 62b9138893d3dcb030bbf9d391a818846a703377 Mon Sep 17 00:00:00 2001
From: Paul Howarth
Date: Aug 15 2019 10:04:04 +
Subject: Update to 0.44
- New upstream release 0.44
- Replaced the use of B with XString if it is installed; the latter
On 14/08/2019 23:08, Jason L Tibbitts III wrote:
>> "DS" == David Sommerseth writes:
>
> DS> As I can see it, there is little benefit of removing lz4-static.
>
> Isn't that entirely the decision of those maintaining the package? It's
> still completely reasonable if they want to remove it
On Wed, Aug 14, 2019 at 8:49 PM Robbie Harwood wrote:
> > Here's the scriptlet:
> >
> > %triggerun libs -- krb5-libs < 1.15.1-5
> > if ! grep -q 'includedir /etc/krb5.conf.d' /etc/krb5.conf ; then
> > sed -i '1i # To opt out of the system crypto-policies
> > configuration of krb5,
> > remove
On 8/14/19 8:22 PM, Ben Cotton wrote:
I want to publicly express my appreciation for Miro's efforts to
enforce our policy and his willingness to take the hits from people
being rightly upset at its flaws.
Seconded. FWIW.
- Panu -
___
devel
Dne 02. 08. 19 v 12:33 Matthew Miller napsal(a):
> On Thu, Aug 01, 2019 at 10:16:40AM -0700, Adam Williamson wrote:
>> Hmm. I never really chipped into the ~ discussion, but it just occurred
>> to me it intersects with a discussion I care quite a lot about: RPM
>> version comparison. Especially
BFQ scheduler help a lot with this issue. Using it on Fedora since 4.19 kernel.
Also there was previous discussion about make it default for Workstation
https://lists.fedoraproject.org/archives/list/ker...@lists.fedoraproject.org/message/I2OZWDD4QCDYUXJ5NHYTMGNAB4KLJN2K/
On 15. 08. 19 7:39, Vít Ondruch wrote:
Of course you might consider this special case, but apparently all the
other people who speak up had different special cases.
"special cases aren't special enough to break the rules"
I still think that if somebody would need to keep package unretired for
76 matches
Mail list logo
