[Bug 1741756] New: Request to build ack for EPEL 8

[bugzilla]

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
  Reporter: adam.winb...@smhi.se
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com
  Target Milestone: ---
Classification: Fedora



Please build ack for EPEL8

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1739463] perldoc -f '<>' complains about pod errors

[bugzilla]

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
   |1.fc32  |1.fc31



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: Let's revisit the FTBFS policy

[Kevin Kofler]

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 incompatible GCC update breaks dozens of C and/or 
C++ packages, it should be up to the GCC maintainers to make them build 
again. If some policy change requires a specfile update (e.g., the addition 
of explicit BuildRequires: gcc-c++), it should be up to the people who 
mandated the policy change to do this update (which was at least partially 
done in the aforementioned example, but there were still dozens of packages 
left to the individual package maintainers to fix for various reasons). The 
current situation where you can break hundreds of packages and then expect 
somebody else to fix them is really antisocial and unfair.

Kevin Kofler
___
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: Why retire Python 2 packages and games that still work to end user ?

[Kevin Kofler]

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 -- 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: Missing arches on EPEL 8 for LibRaw?

[Orion Poplawski]

(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 arches.

ExcludeArch: aarch64 s390x

seems to be the thing to do.

We have a limited arch policy for EPEL6/7, but I'm not sure if we want 
to continue that for EPEL8.


https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages

--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
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

Missing arches on EPEL 8 for LibRaw?

[Richard Shaw]

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
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

[389-devel] 389 DS nightly 2019-08-16 - 96% PASS

[vashirov]

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 389-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/389-devel@lists.fedoraproject.org

[389-devel] Re: Please review: Issue 50206 - Account IDM CLI - WIP

[Simon Pichugin]

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 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
> 
> —
> Sincerely,
> 
> William Brown
> 
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org


signature.asc
Description: PGP signature
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

[389-devel] Re: Please review: Issue 50206 - Account IDM CLI - WIP

[William Brown]

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?
> The lib389 part for Accounts is much bigger now and has much more to
> offer.
> 
> Thanks,
> Simon

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

[389-devel] Please review: Issue 50206 - Account IDM CLI - WIP

[Simon Pichugin]

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


signature.asc
Description: PGP signature
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

[EPEL-devel] 2 weeks in testing for new packages?

[Richard Shaw]

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 time". I have some
upstreams where I have to skip releases because they update within the two
week period and the policy of obsoleting an update when a new one is
created would mean they would perpetually be in testing and never make it
to stable.

Perhaps it would be a good idea to let the maintainer determine if a
previous update should be obsoleted or not when pushing a new update?

Thanks,
Richard
___
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

Re: Let's revisit the FTBFS policy

[Richard Shaw]

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 don't like it either but I have to admit my free cycles have been much
fewer as of late both for personal and professional reasons.

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 :)

I am sometimes guilty of beating my head against the wall to fix something.
I usually can in the long run and I have learned a lot doing it but
sometimes it would be better if things got fixed more quickly.

Just thinking out loud but perhaps some sort of flag in bugzilla that says
"If you know how to fix this please do!"

Thanks,
Richard
___
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: Where are f31 packages going?

[Richard Shaw]

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: 
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

Where are f31 packages going?

[Richard Shaw]

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 -- 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: Unresponsive SIG Leader

[Richard Shaw]

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 (which I
would be happy to give to someone who actually uses it!)

Thanks,
Richard
KF5OIM
___
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: Better interactivity in low-memory situations

[David Airlie]

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 size: 72,
> > buffer size: 72, default order: 0, min order: 0
> > [  718.068639] fmac.local kernel:   node 0: slabs: 296, objs: 16576, free: 0
> > [  718.068704] fmac.local kernel: chronyd: page allocation failure:
> > order:0, mode:0x800(GFP_NOWAIT),
> > nodemask=(null),cpuset=/,mems_allowed=0
> >
> > Not sure what to make of that.
>
> Asked on #fedora-kernel, it's a known issue with 5.3.0-rc4 and drm.
>

Nope it's not that.

Something has leaked all your memory (not drm).

Dave.
___
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: how to use epel8-playground?

[Dave Dykstra]

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 assume this is going to fix the problem and if not I will
follow up. 

Thanks,

Dave

On Thu, Aug 15, 2019 at 06:25:41AM -0700, Troy Dawson wrote:
> 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
> re-requesting them.
> 
>   fedpkg request-branch epel8
> 
> But make sure that it does *two* issues.  If there is only one issue,
> then something is wrong with your fedpkg.
> 
> On Wed, Aug 14, 2019 at 3:25 PM Dave Dykstra  wrote:
> >
> > Hi Troy!
> >
> > I created my branch for singularity from epel8, but that wouldn't make a
> > difference, would it?  When I do fedpkg push from epel8-playground I get
> >
> > Current branch cannot be pushed anywhere!
> > Counting objects: 5, done.
> > Compressing objects: 100% (2/2), done.
> > Writing objects: 100% (3/3), 327 bytes | 0 bytes/s, done.
> > Total 3 (delta 1), reused 0 (delta 0)
> > remote: Unspecified ref refs/heads/epel8-playground is blocked
> > remote: Denied push for ref 'refs/heads/epel8-playground' for user 'dwd'
> > remote: All changes have been rejected
> > To ssh://d...@pkgs.fedoraproject.org/rpms/singularity.git
> >  ! [remote rejected] HEAD -> epel8-playground (pre-receive hook declined)
> > error: failed to push some refs to 
> > 'ssh://d...@pkgs.fedoraproject.org/rpms/singularity.git'
> > Could not execute push: Failed to execute command.
> >
> > Dave
> >
> > On Mon, Aug 12, 2019 at 02:47:08PM -0700, Troy Dawson wrote:
> > > Looks like you need at least fedpkg-1.37-3.el7 for it to work with the
> > > playground stuff, so you should be good.
> > > When I did the branches for KDE (about 350 of them) there were 6 that
> > > didn't properly branch to epel8-playground.
> > > They *said* they were branched, but they weren't.
> > > I was able to push and create a branch though, because everything else
> > > was setup.
> > >
> > >   fedpkg switch-branch f30
> > >   git checkout -b epel8-playground
> > >   fedpkg push
> > >
> > > I did f30 instead of master because that's the version we wanted for
> > > KDE.  You can do that from master if you want.
> > >
> > > Troy
> > >
> > > On Mon, Aug 12, 2019 at 2:17 PM Dave Dykstra  wrote:
> > > >
> > > > Hi Kevin,
> > > >
> > > > I have fedpkg-1.37-4.el7, the latest version.  My yum log shows I
> > > > updated it from 1.37-2 on August 6 an hour and a half before I started
> > > > this thread.  If I recall correctly I saw an instruction somewhere that
> > > > said to update it, and I did that before my initial attempt.
> > > >
> > > > Dave
> > > >
> > > > On Sun, Aug 11, 2019 at 10:01:47AM -0700, Kevin Fenzi wrote:
> > > > > On 8/8/19 11:40 AM, Dave Dykstra wrote:
> > > > > > Stephen,
> > > > > >
> > > > > > The package is singularity.
> > > > > >
> > > > > > The term "branch" in this context is not very clear to me.  All I 
> > > > > > know
> > > > > > is that there's no git branch on 
> > > > > > pkgs.fedoraproject.org/rpms/singularity;
> > > > > > I don't know about other systems.
> > > > >
> > > > > What version of fedpkg do you have there?
> > > > >
> > > > > It might be the version is too old to understand the epel8-playground
> > > > > request?
> > > > >
> > > > > kevin
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > > ___
> > > > > 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
> > > > >  
> > > > ___
> > > > 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
> > > >  
> > > ___
> > > epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> > > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> > > 

Re: Better interactivity in low-memory situations

[Chris Murphy]

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
> [  718.068639] fmac.local kernel:   node 0: slabs: 296, objs: 16576, free: 0
> [  718.068704] fmac.local kernel: chronyd: page allocation failure:
> order:0, mode:0x800(GFP_NOWAIT),
> nodemask=(null),cpuset=/,mems_allowed=0
>
> Not sure what to make of that.

Asked on #fedora-kernel, it's a known issue with 5.3.0-rc4 and drm.


-- 
Chris Murphy
___
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: ppc64le Rawhide VM issues

[Steven Munroe]

> 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
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: when will bodhi (updates) recognize fc31/f31 updates

[Kevin Fenzi]

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 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 generate update
>>> >request: Cannot find release associated with build:
>>> >nfs-ganesha-2.8.2-5.fc31, tags: ['f31']
>>> My understanding is that F31 doesn't need bodhi right now -- all
>>> packages built for it appear in the distro, as with rawhide before.
>>>
>>> Branched will get bodhi activated later this month.
>>>
>>
>> Well, it's confusing (to me anyway), because before branching, new
>> f31/rawhide builds showed up automatically as "stable" in bodhi.
>>
>> And now new f32/rawhide builds show up automatically as "stable."
>>
>> Making me wonder what is status of the new f31 build(s) I've just done?
>> They don't show up in bodhi at all.
> Yes, Bodhi activation for a Branched is marked in the schedule
> separately. This was noted in the mass branching email:
> 
> --
> Bodhi is currently not active for Fedora 31, it will be enabled in
> couple of weeks time when we hit Beta change freeze point in the Fedora
> 31 schedule[1].
> 
> [1] https://fedoraproject.org/wiki/Releases/31/Schedule
> --
> 
> A confusion is probably because at the same time Gating in Rawhide was
> introduced. Gating in Rawhide relies on Bodhi, so there is Bodhi for
> F32. I think we could have made Bodhi for F31 with automated acceptance
> of the packages more visible but it might have been postponed to the
> "Bodhi activation point" altogether.

Yeah, it's been confusing for sure. :(

Right now rawhide (f32) is doing gating as it was before.

Branched (f31) is acting like rawhide used to, pre gating (ie, builds
are just signed and added)

I would expect branched to also do gating, so I think we should move it
to that.

Or, we could just decide to enable bodhi for good at branching. The
reason we didn't do this before was that its more stuff for releng to
deal with at branching, and the 2 weeks give people time to get builds
in fast to finish up things they know for sure they want to get into the
branched release. It might just be a lot less confusing to enable it tho.

kevin



signature.asc
Description: OpenPGP digital signature
___
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: unable to branch to epel8

[Kevin Fenzi]

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 definitely isn't in git.  An example is
> .  Can someone
> tell me what to do about that?

I'm not sure why this sometimes happens. As the downthread reply notes
you can just push the branch yourself now after it's been created in the
product definition center. We should really track that down, but the
entire request system is going to be replaced soon, so hard to dig too
far. ;(

> 
> Also, I don't get any notifications from pagure (as with various other
> -- most? -- services), despite turning on anything relevant-looking in
> the notifications app.  I've asked several times about lack of
> notifications with no luck or suggestions how to debug it.  Can anyone
> make any suggestions now?

Can you expand on 'any notifications from pagure' ? pagure.io?
src.fedoraproject.org? what sort of notifications?

Can you point to a thing that should have notificed you?

This is probibly best as a infrastructure ticket, feel free to file
there: https://pagure.io/fedora-infrastructure/issues

and we will get to the bottom of it.

> I'm increasingly un-motivated to do maintenance particularly because of
> continual infrastructure problems.

Very sorry to hear it. We are trying the best we can with the resources
we have. ;(

kevin



signature.asc
Description: OpenPGP digital signature
___
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: Better interactivity in low-memory situations

[Chris Murphy]

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
> https://lists.fedoraproject.org/archives/list/ker...@lists.fedoraproject.org/message/I2OZWDD4QCDYUXJ5NHYTMGNAB4KLJN2K/

It's mentioned in the workstation issue as having no effect in this case.
https://pagure.io/fedora-workstation/issue/98

I just switched to it and repeating the test case and the GUI still
hangs, is unresponsive, even without substantial pressure on the SSD,
and swap isn't even 1/2 used.
https://drive.google.com/open?id=13_5XIBMu01HfOdzGVH-4qTgd-PLpFsaN

But I am getting something new in kernel messages:


542sysrq+t during a GUI freeze that lasted over 1 minute, and then:

[  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
[  718.068639] fmac.local kernel:   node 0: slabs: 296, objs: 16576, free: 0
[  718.068704] fmac.local kernel: chronyd: page allocation failure:
order:0, mode:0x800(GFP_NOWAIT),
nodemask=(null),cpuset=/,mems_allowed=0

Not sure what to make of that. Complete 'journalctl -k' is here:
https://drive.google.com/open?id=1Z1jAjMrmdXAxuSELdFfd4IKdceeufmVu

-- 
Chris Murphy
___
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: bootctl: no entry could be determined as default (Was: Upgrade to F30 gone wrong)

[Chris Murphy]

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 around very early on, yes.
>
> Well, from someone not versed in bios, efi and bootloaders the spec
> looks reasonable. Now I'm wondering why Fedora doesn't implement the
> interface. Is it only a matter of someone driving the change? Was
> there some push-back? Or is it more complicated because it needs to
> involve the installer and a dozen other components?

Implementing the interface needs to happen in the bootloader. Someone
would need to do the work in GRUB in a way that GRUB upstream will
accept. And then Fedora will get it when rebasing.

-- 
Chris Murphy
___
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] Fedora EPEL 6 updates-testing report

[updates]

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 (FEDORA-EPEL-2019-bc8497a1d3)
 Python framework for efficient cluster administration

Update Information:

Update to upstream version 1.8.2 that contains minor fixes.  More info at
https://clustershell.readthedocs.io/en/v1.8.2/release.html

ChangeLog:

* Mon Aug 12 2019 Stephane Thiell  1.8.2-1
- update to 1.8.2




 procenv-0.51-1.el6 (FEDORA-EPEL-2019-60f231b981)
 Utility to show process environment

Update Information:

New version

ChangeLog:

* Wed Aug 14 2019 Dave love  - 0.51-1
- New version; drop patch
* Fri Jul 26 2019 Fedora Release Engineering  - 0.50-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
* Sat Feb  2 2019 Fedora Release Engineering  - 0.50-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
* Mon Jan 21 2019 Dave Love  - 0.50-4
- Patch to fix failure with gcc 9
* Fri Jul 13 2018 Fedora Release Engineering  - 0.50-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Fri Feb  9 2018 Fedora Release Engineering  - 0.50-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Wed Oct 25 2017 Dave Love  - 0.50-1
- New version
- Remove el5-isms
* Thu Aug  3 2017 Fedora Release Engineering  - 0.49-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild
* Thu Jul 27 2017 Fedora Release Engineering  - 0.49-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
* Wed Feb 22 2017 Dave Love  - 0.49-2
- Bump to rebuild after failed mass rebuild
* Mon Feb 13 2017 Dave Love  - 0.49-1
- New version
* Sat Feb 11 2017 Fedora Release Engineering  - 0.46-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
* Wed Jun  1 2016 Dave Love  - 0.46-1
- New version
- Remove fedora guard in %check
- Don't distribute ChangeLog
* Tue Mar 22 2016 Dave Love  - 0.45-1
- New version




 python-regex-2019.06.08-1.el6 (FEDORA-EPEL-2019-5aa28c4d65)
 Alternative regular expression module, to replace re

Update Information:

Update to the latest released version.

ChangeLog:

* Wed Aug 14 2019 Thomas Moschny  - 2019.06.08-1
- Update to 2019.06.08.
* Fri Jul 26 2019 Fedora Release Engineering  - 
2019.05.25-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild


___
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

[EPEL-devel] Re: What to do about missing gcc-objc from RHEL8?

[Troy Dawson]

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 support ticket with Red Hat.
You could open a bugzilla, but a customer support ticket would be better.

> Are there alternative compilers yet that we can access?

That's a pretty broad question. (Yes, of course.  perl, ruby etc...)
But I assume you mean to compute objective code.
I don't know.

> Will we have to package gcc-objc for EPEL8 separately?

If the answer to the first question, from Red Hat, is that they do not
plan on supporting it anymore.
Yes, you will need to package gcc-objc EPEL8.

Troy
___
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

[EPEL-devel] Fedora EPEL 8 updates-testing report

[updates]

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
opari2-2.0.5-1.el8
python-libarchive-c-2.8-8.el8
scalapack-2.0.2-30.el8
udunits2-2.2.26-5.el8
vid.stab-1.1.0-12.20190213gitaeabc8d.el8

Details about builds:



 Lmod-8.1.10-2.el8 (FEDORA-EPEL-2019-4a03f02662)
 Environmental Modules System in Lua

Update Information:

Lmod is a Lua based module system that easily handles the MODULEPATH
Hierarchical problem.  Environment Modules provide a convenient way to
dynamically change the users' environment through modulefiles. This includes
easily adding or removing directories to the PATH environment variable.
Modulefiles for library packages provide environment variables that specify
where the library and header files can be found.




 aalib-1.4.0-0.37.rc5.el8 (FEDORA-EPEL-2019-a3ef98719a)
 ASCII art library

Update Information:

Build for EPEL-8

References:

  [ 1 ] Bug #1739171 - aalib for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1739171




 byobu-5.129-2.el8 (FEDORA-EPEL-2019-2094d4b039)
 Light-weight, configurable window manager built upon GNU screen

Update Information:

- new upstream release 5.129

References:

  [ 1 ] Bug #1737882 - [RFE] build byobu for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1737882




 clustershell-1.8.2-1.el8 (FEDORA-EPEL-2019-02802715e7)
 Python framework for efficient cluster administration

Update Information:

First EPEL-8 package from upstream release 1.8.2 with only the Python 3
subpackage (python3-clustershell).
https://clustershell.readthedocs.io/en/v1.8.2/release.html




 cros-guest-tools-1.0-0.16.20190815git4e1b573.el8 (FEDORA-EPEL-2019-fddc7bd2c8)
 Chromium OS integration meta package

Update Information:

Update to master git4e1b573




 dar-2.6.5-2.el8 (FEDORA-EPEL-2019-f293a48a05)
 Software for making/restoring incremental CD/DVD backups

Update Information:

add in epel8




 hdf-4.2.14-5.el8 (FEDORA-EPEL-2019-1119f99a1e)
 A general purpose library and file format for storing scientific data

Update Information:

HDF4 is a general purpose library and file format for storing scientific data.
HDF4 can store two primary objects: datasets and groups. A dataset is
essentially a multidimensional array of data elements, and a group is a
structure for organizing objects in an HDF4 file. Using these two basic objects,
one can create and store almost any kind of scientific data structure, such as
images, arrays of vectors, and structured and unstructured grids. You can also
mix and match them in HDF4 files according to your needs.




 libxsmm-1.13-2.el8 (FEDORA-EPEL-2019-0c18fabd97)
 Small dense or sparse matrix multiplications and convolutions for x86_64

Update Information:

Initial version for EPEL8

Re: Unresponsive SIG Leader

[Kevin Fenzi]

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 and is no longer valid [1]. I would like to
> know how, if possible, to take over as the leader of the group. It hasn't
> gotten much love in the last several years and it shows... :) Please let me
> know how to proceed from here.
> 
> [0] https://fedoraproject.org/wiki/BobJensen
> [1] https://wireless2.fcc.gov/UlsApp/UlsSearch/license.jsp?licKey=2818099

I'd say just start doing things. If he comes back he can join in,
otherwise you just move forward. :)

kevin




signature.asc
Description: OpenPGP digital signature
___
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: Let's revisit the FTBFS policy

[Adam Williamson]

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 still think that if somebody would need to keep package unretired for 1.5+ 
> years, they have options:
> 
>   - let it be retired, unretire, retag (as in: "I don't give a damn")
>   - request an exception with proper reasons (as in: "I have proper reasons")
> 
> Just being able to let the package rot for 3+ releases is not good enough 
> reason 
> IMHO.

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!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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: Requesting F31 branches

[Gwyn Ciesla via devel]

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 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 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 <
> > > zebo...@gmail.com> wrote:
> > > 

> > > > 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.
> > > > 

> > > > > 

> > 

> > Mohan is on vacation this week. Is there anyone else with privileges to do
> > this?
> 

> I can, but... Gwyn: can you just carry the patch locally until it's updated?
> 

> It's pretty small:
> 

> https://pagure.io/fedscm-admin/c/0e81652245fe1a55b78a0f8cb2a49ba5f03e3606?branch=master
> 

> That will unblock everyone while I keep fighting fires...
> 

> kevin
> 

> 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



signature.asc
Description: OpenPGP digital signature
___
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: Requesting F31 branches

[Kevin Fenzi]

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 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 <
>> zebo...@gmail.com> wrote:
>>
>>> 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.

>>
>>
> Mohan is on vacation this week. Is there anyone else with privileges to do
> this?

I can, but... Gwyn: can you just carry the patch locally until it's updated?

It's pretty small:

https://pagure.io/fedscm-admin/c/0e81652245fe1a55b78a0f8cb2a49ba5f03e3606?branch=master

That will unblock everyone while I keep fighting fires...

kevin



signature.asc
Description: OpenPGP digital signature
___
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: Requesting F31 branches

[Stephen Gallagher]

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 Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, August 15, 2019 11:26 AM, Robert-André Mauchin <
> zebo...@gmail.com> wrote:
>
> > 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.
> > >
>
>
Mohan is on vacation this week. Is there anyone else with privileges to do
this?
___
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: RFC: Drop lz4-static

[Japheth Cleaver]

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
reason than it eliminates ten lines from the specfile.  The question was
whether there is any pressing reason to refrain from removing it.

  - J<


Compression libraries are an area where it's common to have special 
cases that need to bootstrap or otherwise provide a service outside of a 
sane/guaranteed dynamic library environment. As others have mentioned, 
this could mean early boot for RH-style systems, but it could be for any 
other reason for a specific site. zlib-static, bzip2-static, and 
xz-static have existed for forever, and lz4 should continue to follow 
suit. (And https://bugzilla.redhat.com/show_bug.cgi?id=1212209 would be 
nice, since the subject is up.)


If it's removed for the .spec (not just not included in a distro, but 
removed), then those who'd like to be able to use the package have to 
maintain a new local fork. That's not ideal.


-jc
___
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: Requesting F31 branches

[Gwyn Ciesla via devel]

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  
wrote:

> 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 love
> > -d. bowie
> 

> Any idea when this would be fixed?
> 

> Best regards,
> 

> Robert-André^
> 

> 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



signature.asc
Description: OpenPGP digital signature
___
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

spot pushed to perl-DateTime-Calendar-Julian (f31). "update to 0.101"

[notifications]

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
+++ b/.gitignore
@@ -1,2 +1,3 @@
 /DateTime-Calendar-Julian-0.04.tar.gz
 /DateTime-Calendar-Julian-0.100.tar.gz
+/DateTime-Calendar-Julian-0.101.tar.gz
diff --git a/perl-DateTime-Calendar-Julian.spec 
b/perl-DateTime-Calendar-Julian.spec
index 8e7b33e..d79e567 100644
--- a/perl-DateTime-Calendar-Julian.spec
+++ b/perl-DateTime-Calendar-Julian.spec
@@ -1,8 +1,8 @@
 Name:  perl-DateTime-Calendar-Julian
-Version:   0.100
-Release:   4%{?dist}
-License:   GPL+ or Artistic 
-Summary:   Julian Calendar support for DateTime.pm 
+Version:   0.101
+Release:   1%{?dist}
+License:   GPL+ or Artistic
+Summary:   Julian Calendar support for DateTime.pm
 Url:   https://metacpan.org/release/DateTime-Calendar-Julian
 Source:
https://cpan.metacpan.org/authors/id/P/PI/PIJLL/DateTime-Calendar-Julian-%{version}.tar.gz
 BuildArch: noarch
@@ -38,6 +38,9 @@ make test
 %{_mandir}/man3/DateTime::Calendar::Julian.3pm*
 
 %changelog
+* Thu Aug 15 2019 Tom Callaway  - 0.101-1
+- update to 0.101
+
 * Fri Jul 26 2019 Fedora Release Engineering  - 
0.100-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
 
diff --git a/sources b/sources
index 6b27bed..cb4e098 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (DateTime-Calendar-Julian-0.100.tar.gz) = 
6105ad299e9c0c42d8641289e60bc0f81429c5e237cf423aa88bfe08da46a38c07de9963289f5eaaae1cbfed1e9450923ca99fffc3824682e9f713827bc4a61f
+SHA512 (DateTime-Calendar-Julian-0.101.tar.gz) = 
3ff1d30358972d0f7f95cf9e88478d7c7e77aa61544ecf69096e13287d5ee2aa953744b341714b944caf437ac253f3e832f544847a5db584740c168078b14986



https://src.fedoraproject.org/rpms/perl-DateTime-Calendar-Julian/c/067bde8a3f3a3c470e4f5a3766c3ac3861a0e415?branch=f31
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

spot pushed to perl-DateTime-Calendar-Julian (master). "update to 0.101"

[notifications]

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
+++ b/.gitignore
@@ -1,2 +1,3 @@
 /DateTime-Calendar-Julian-0.04.tar.gz
 /DateTime-Calendar-Julian-0.100.tar.gz
+/DateTime-Calendar-Julian-0.101.tar.gz
diff --git a/perl-DateTime-Calendar-Julian.spec 
b/perl-DateTime-Calendar-Julian.spec
index 8e7b33e..d79e567 100644
--- a/perl-DateTime-Calendar-Julian.spec
+++ b/perl-DateTime-Calendar-Julian.spec
@@ -1,8 +1,8 @@
 Name:  perl-DateTime-Calendar-Julian
-Version:   0.100
-Release:   4%{?dist}
-License:   GPL+ or Artistic 
-Summary:   Julian Calendar support for DateTime.pm 
+Version:   0.101
+Release:   1%{?dist}
+License:   GPL+ or Artistic
+Summary:   Julian Calendar support for DateTime.pm
 Url:   https://metacpan.org/release/DateTime-Calendar-Julian
 Source:
https://cpan.metacpan.org/authors/id/P/PI/PIJLL/DateTime-Calendar-Julian-%{version}.tar.gz
 BuildArch: noarch
@@ -38,6 +38,9 @@ make test
 %{_mandir}/man3/DateTime::Calendar::Julian.3pm*
 
 %changelog
+* Thu Aug 15 2019 Tom Callaway  - 0.101-1
+- update to 0.101
+
 * Fri Jul 26 2019 Fedora Release Engineering  - 
0.100-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
 
diff --git a/sources b/sources
index 6b27bed..cb4e098 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (DateTime-Calendar-Julian-0.100.tar.gz) = 
6105ad299e9c0c42d8641289e60bc0f81429c5e237cf423aa88bfe08da46a38c07de9963289f5eaaae1cbfed1e9450923ca99fffc3824682e9f713827bc4a61f
+SHA512 (DateTime-Calendar-Julian-0.101.tar.gz) = 
3ff1d30358972d0f7f95cf9e88478d7c7e77aa61544ecf69096e13287d5ee2aa953744b341714b944caf437ac253f3e832f544847a5db584740c168078b14986



https://src.fedoraproject.org/rpms/perl-DateTime-Calendar-Julian/c/067bde8a3f3a3c470e4f5a3766c3ac3861a0e415?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1741574] Upgrade perl-DateTime-Calendar-Julian to 0.101

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1741574

Tom "spot" Callaway  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2019-08-15 17:07:03



--- Comment #1 from Tom "spot" Callaway  ---
0.101 in rawhide.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: Requesting F31 branches

[Robert-André Mauchin]

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 love
> -d. bowie

Any idea when this would be fixed?

Best regards,

Robert-André^

___
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: EPEL 8 not finding buildroot overrides

[Orion Poplawski]

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 with this is above my fedora permissions.  I cannot
> do a koji regen-repo.
> 
> On Wed, Aug 14, 2019 at 5:54 PM Richard Shaw  wrote:
>>
>> Here's the link...
>>
>> https://bodhi.fedoraproject.org/overrides/hdf5-1.10.5-3.el8
>>
>> Which is showing as active.
>>
>> Thanks,
>> Richard

Sometimes things go awry...  What I've found is that expiring the override and
then re-submitting it (with a later date as required) often works.  I just did
this with the hdf5 update and it appears to be working now.

- Orion


-- 
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic 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

Re: unable to branch to epel8

[Robert-André Mauchin]

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, but the branch definitely isn't in git.  An example is
> .  Can someone
> tell me what to do about that?
> 
> Also, I don't get any notifications from pagure (as with various other
> -- most? -- services), despite turning on anything relevant-looking in
> the notifications app.  I've asked several times about lack of
> notifications with no luck or suggestions how to debug it.  Can anyone
> make any suggestions now?
> 
> I'm increasingly un-motivated to do maintenance particularly because of
> continual infrastructure problems.


The PDC is the Product Definition Center:

> The Product Definition Center is repository and API for storing and querying 
metadata related to packages, product releases, engineering processes and 
artifacts which are required to support automation of release engineering 
workflows (or productization processes). It aims to support the development of 
automation that ties in the different tools to streamline productization 
processes and create more efficient workflows.

https://pdc.fedoraproject.org/

Your package has already a EPEL8 branch in the PDC:
https://pdc.fedoraproject.org/rest_api/v1/component-branches/?
global_component=procenv

If the branch has not been created in dist-git, you can create it manually:

git checkout -b epel8
git push --set-upstream origin epel8

Best regards,

Robert-André

___
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] What to do about missing gcc-objc from RHEL8?

[Orion Poplawski]

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 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic 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

Re: ppc64le Rawhide VM issues

[Scott Talbert]

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 aren't working properly. Like "dnf".


Can't help you with qemu, but just wanted to point out that as a packager, 
you do have access to a ppc64le machine, see:


https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers

Scott
___
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

ppc64le Rawhide VM issues

[Greg Hellings]

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".

My qemu boot command is currently:
qemu-system-ppc64 -m 2048 -smp 2 -machine pseries -cpu power9 -hda  -cdrom 

I can login to the system, run some basic commands such as "cat", "ls",
"cd", etc. However, running slightly more intense commands like "dnf" and
"df" result in errors like this:
"Illegal instruction (4) at 7fffb3a018e0 nip 7fffb3a018e0 lr 7fffb3a03f2c
code 1 in libc-2.30.so[7fffb39b+1f]"

I'm not sure if this is a bug in Rawhide or if it is a bug in how I'm
launching the VM. Google has come up dry on further info than where I
currently am in both regards.

Thanks - Greg
___
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

Taskjuggler COPR and its relevance

[Ankur Sinha]

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 fork:
https://src.fedoraproject.org/fork/ankursinha/rpms/rubygem-taskjuggler/

Given that upstream isn't active, I don't want to un-retire it just yet.
I'm not proficient in Ruby either so if something breaks and upstream
doesn't fix it, I won't be able to do much either. Out of curiosity:

- are any folks using Taskjuggler or has it now been obsoleted by all
  the fancy web based project management tools out there? If that's the
  case, could you suggest an open-source alternative that has feature
  parity with TJ?

- if it is not obsolete, are there any Ruby folks that would consider
  poking upstream and helping them keep it alive?

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


signature.asc
Description: PGP signature
___
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: bootctl: no entry could be determined as default (Was: Upgrade to F30 gone wrong)

[Dridi Boukelmoune]

> 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 bootloaders the spec
looks reasonable. Now I'm wondering why Fedora doesn't implement the
interface. Is it only a matter of someone driving the change? Was
there some push-back? Or is it more complicated because it needs to
involve the installer and a dozen other components?

Dridi
___
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: when will bodhi (updates) recognize fc31/f31 updates

[Alexander Bokovoy]

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: 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 generate update
>request: Cannot find release associated with build:
>nfs-ganesha-2.8.2-5.fc31, tags: ['f31']
My understanding is that F31 doesn't need bodhi right now -- all
packages built for it appear in the distro, as with rawhide before.

Branched will get bodhi activated later this month.



Well, it's confusing (to me anyway), because before branching, new
f31/rawhide builds showed up automatically as "stable" in bodhi.

And now new f32/rawhide builds show up automatically as "stable."

Making me wonder what is status of the new f31 build(s) I've just done?
They don't show up in bodhi at all.

Yes, Bodhi activation for a Branched is marked in the schedule
separately. This was noted in the mass branching email:

--
Bodhi is currently not active for Fedora 31, it will be enabled in
couple of weeks time when we hit Beta change freeze point in the Fedora
31 schedule[1].

[1] https://fedoraproject.org/wiki/Releases/31/Schedule
--

A confusion is probably because at the same time Gating in Rawhide was
introduced. Gating in Rawhide relies on Bodhi, so there is Bodhi for
F32. I think we could have made Bodhi for F31 with automated acceptance
of the packages more visible but it might have been postponed to the
"Bodhi activation point" altogether.

--
/ Alexander Bokovoy
___
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: when will bodhi (updates) recognize fc31/f31 updates

[Kaleb Keithley]

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
> associated
> >with build: nfs-ganesha-2.8.2-5.fc31, tags: ['f31']
> >
> >fedpkg update gets: Could not execute update: Could not generate update
> >request: Cannot find release associated with build:
> >nfs-ganesha-2.8.2-5.fc31, tags: ['f31']
> My understanding is that F31 doesn't need bodhi right now -- all
> packages built for it appear in the distro, as with rawhide before.
>
> Branched will get bodhi activated later this month.
>

Well, it's confusing (to me anyway), because before branching, new
f31/rawhide builds showed up automatically as "stable" in bodhi.

And now new f32/rawhide builds show up automatically as "stable."

Making me wonder what is status of the new f31 build(s) I've just done?
They don't show up in bodhi at all.

--

Kaleb
___
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: when will bodhi (updates) recognize fc31/f31 updates

[Alexander Bokovoy]

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 gets: Could not execute update: Could not generate update
request: Cannot find release associated with build:
nfs-ganesha-2.8.2-5.fc31, tags: ['f31']

My understanding is that F31 doesn't need bodhi right now -- all
packages built for it appear in the distro, as with rawhide before.

Branched will get bodhi activated later this month.

--
/ Alexander Bokovoy
___
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

when will bodhi (updates) recognize fc31/f31 updates

[Kaleb Keithley]

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 generate update
request: Cannot find release associated with build:
nfs-ganesha-2.8.2-5.fc31, tags: ['f31']

Thanks

--

Kaleb
___
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: Let's revisit the FTBFS policy

[Gerald Henriksen]

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 a security
risk.

If you can't just fix the security issue and rebuild, but instead have
to also fix the issue(s) that prevent the package from rebuilding this
could cause delays in getting a security update out.
___
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: EPEL 8 not finding buildroot overrides

[Troy Dawson]

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 cannot
do a koji regen-repo.

On Wed, Aug 14, 2019 at 5:54 PM Richard Shaw  wrote:
>
> Here's the link...
>
> https://bodhi.fedoraproject.org/overrides/hdf5-1.10.5-3.el8
>
> Which is showing as active.
>
> Thanks,
> Richard
> ___
> 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
___
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

[EPEL-devel] Re: how to use epel8-playground?

[Troy Dawson]

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
re-requesting them.

  fedpkg request-branch epel8

But make sure that it does *two* issues.  If there is only one issue,
then something is wrong with your fedpkg.

On Wed, Aug 14, 2019 at 3:25 PM Dave Dykstra  wrote:
>
> Hi Troy!
>
> I created my branch for singularity from epel8, but that wouldn't make a
> difference, would it?  When I do fedpkg push from epel8-playground I get
>
> Current branch cannot be pushed anywhere!
> Counting objects: 5, done.
> Compressing objects: 100% (2/2), done.
> Writing objects: 100% (3/3), 327 bytes | 0 bytes/s, done.
> Total 3 (delta 1), reused 0 (delta 0)
> remote: Unspecified ref refs/heads/epel8-playground is blocked
> remote: Denied push for ref 'refs/heads/epel8-playground' for user 'dwd'
> remote: All changes have been rejected
> To ssh://d...@pkgs.fedoraproject.org/rpms/singularity.git
>  ! [remote rejected] HEAD -> epel8-playground (pre-receive hook declined)
> error: failed to push some refs to 
> 'ssh://d...@pkgs.fedoraproject.org/rpms/singularity.git'
> Could not execute push: Failed to execute command.
>
> Dave
>
> On Mon, Aug 12, 2019 at 02:47:08PM -0700, Troy Dawson wrote:
> > Looks like you need at least fedpkg-1.37-3.el7 for it to work with the
> > playground stuff, so you should be good.
> > When I did the branches for KDE (about 350 of them) there were 6 that
> > didn't properly branch to epel8-playground.
> > They *said* they were branched, but they weren't.
> > I was able to push and create a branch though, because everything else
> > was setup.
> >
> >   fedpkg switch-branch f30
> >   git checkout -b epel8-playground
> >   fedpkg push
> >
> > I did f30 instead of master because that's the version we wanted for
> > KDE.  You can do that from master if you want.
> >
> > Troy
> >
> > On Mon, Aug 12, 2019 at 2:17 PM Dave Dykstra  wrote:
> > >
> > > Hi Kevin,
> > >
> > > I have fedpkg-1.37-4.el7, the latest version.  My yum log shows I
> > > updated it from 1.37-2 on August 6 an hour and a half before I started
> > > this thread.  If I recall correctly I saw an instruction somewhere that
> > > said to update it, and I did that before my initial attempt.
> > >
> > > Dave
> > >
> > > On Sun, Aug 11, 2019 at 10:01:47AM -0700, Kevin Fenzi wrote:
> > > > On 8/8/19 11:40 AM, Dave Dykstra wrote:
> > > > > Stephen,
> > > > >
> > > > > The package is singularity.
> > > > >
> > > > > The term "branch" in this context is not very clear to me.  All I know
> > > > > is that there's no git branch on 
> > > > > pkgs.fedoraproject.org/rpms/singularity;
> > > > > I don't know about other systems.
> > > >
> > > > What version of fedpkg do you have there?
> > > >
> > > > It might be the version is too old to understand the epel8-playground
> > > > request?
> > > >
> > > > kevin
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > > ___
> > > > 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
> > > ___
> > > 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
> > ___
> > 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
___
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

[Bug 1739463] perldoc -f '<>' complains about pod errors

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1739463

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Pod-Perldoc-3.28.01-44
   ||1.fc32



--- Comment #3 from Petr Pisar  ---
I developed a fix and posted it to the upstream. I've also applied it to Fedora
32. If nobody complains, I will apply it to the older Fedoras later.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1740157] Upgrade perl-IO-Compress-Lzma to 2.087

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1740157

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|CLOSED  |NEW
 Resolution|RAWHIDE |---
   Keywords||Reopened



--- Comment #2 from Jitka Plesnikova  ---
The build perl-IO-Compress-Lzma-2.087-1.fc31 is not tagged in f31/f32

$ koji -q list-tagged --latest f32 perl-IO-Compress-Lzma
perl-IO-Compress-Lzma-2.086-3.fc31f32   releng

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: Let's revisit the FTBFS policy

[Miro Hrončok]

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: +420777974800
IRC: mhroncok
___
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: Let's revisit the FTBFS policy

[Vít Ondruch]

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 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
>>> toxic by some.
>> Only if they're present to notice. In the end, they're late and it was fixed 
>> for them, or at least someone cares for their work, so they should be... 
>> grateful?
>>
>>>  > According to compose report from 20190811 [1], I guess it was ~570
>>>  > packages. How many of them had associated FTBFS BZs in "ASSIGNED" state
>>>  > and for which version of Fedora? This would be interesting statistics to
>>>  > know. My guess is that it was 100 BZs at most, but probably much lower
>>>  > number.
>>>
>>> "for which version of Fedora" doesn't apply really. Most of the bugs were
>>> just
>>> "rawhide" since the latest rawhide -> 30 only happened partially.
>>>
>>> The status data should be visible in Bugzilla, however no idea how to query
>>> them
>>> grammatically:
>>>
>>>   - get CLOSED EOL bugzillas blocking the F30FTBFS tracker
>> This should be it:
>>   
>> https://bugzilla.redhat.com/buglist.cgi?bug_id=1674516_id_type=anddependson_status=CLOSED_id=10414793_format=advanced=EOL
>
>
> So this lists 656 components for F30.
>
> There are 16 components for F29:
>
> https://bugzilla.redhat.com/buglist.cgi?bug_id=1602938_id_type=anddependson_status=CLOSED_id=10415022_format=advanced=EOL
>
>
>
>>>   - fetch their previous state
>>>   (this is visible in the bug, but no idea how to query it)
>> Sorry, I have no idea for this one.
>>
>
> Ah, you beat me to do this:
>
>
> F30 - 41 components:
>
> https://bugzilla.redhat.com/buglist.cgi?bug_id=1674516_id_type=anddependson_status=CLOSED=bug_status=OP_id=10414961=changedfrom_format=advanced=EOL=ASSIGNED
>
>
> F29 - 2 components:
>
> https://bugzilla.redhat.com/buglist.cgi?bug_id=1602938_id_type=anddependson_status=CLOSED=bug_status=OP_id=10414961=changedfrom_format=advanced=EOL=ASSIGNED
>
>
> F28 - 25 components: 
>
> https://bugzilla.redhat.com/buglist.cgi?bug_id=1555378_id_type=anddependson_status=CLOSED=bug_status=OP_id=10414961=changedfrom_format=advanced=EOL=ASSIGNED
>
>
> Interestingly enough, some people who complains the most about the
> process are too busy to even switch the component to assigned ...
>

Checking more of the tickets, I want to apologize for the last remark,
which was not necessary.


Vít


>
> Vít
>
>
> ___
> 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

Re: Why retire Python 2 packages and games that still work to end user ?

[Miro Hrončok]

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 Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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

[Bug 1741574] New: Upgrade perl-DateTime-Calendar-Julian to 0.101

[bugzilla]

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: tcall...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
tcall...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 0.100 version. Upstream released 0.101. When you have
free time, please upgrade it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[Bug 1741573] New: Upgrade perl-Data-ICal to 0.23

[bugzilla]

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
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: c...@wpi.edu, perl-devel@lists.fedoraproject.org,
rc040...@freenet.de, xav...@bachelot.org
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 0.22 version. Upstream released 0.23. When you have free
time, please upgrade it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: Let's revisit the FTBFS policy

[Vít Ondruch]

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
>>> 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
>> toxic by some.
> Only if they're present to notice. In the end, they're late and it was fixed 
> for them, or at least someone cares for their work, so they should be... 
> grateful?
>
>>  > According to compose report from 20190811 [1], I guess it was ~570
>>  > packages. How many of them had associated FTBFS BZs in "ASSIGNED" state
>>  > and for which version of Fedora? This would be interesting statistics to
>>  > know. My guess is that it was 100 BZs at most, but probably much lower
>>  > number.
>>
>> "for which version of Fedora" doesn't apply really. Most of the bugs were
>> just
>> "rawhide" since the latest rawhide -> 30 only happened partially.
>>
>> The status data should be visible in Bugzilla, however no idea how to query
>> them
>> grammatically:
>>
>>   - get CLOSED EOL bugzillas blocking the F30FTBFS tracker
> This should be it:
>   
> https://bugzilla.redhat.com/buglist.cgi?bug_id=1674516_id_type=anddependson_status=CLOSED_id=10414793_format=advanced=EOL


So this lists 656 components for F30.

There are 16 components for F29:

https://bugzilla.redhat.com/buglist.cgi?bug_id=1602938_id_type=anddependson_status=CLOSED_id=10415022_format=advanced=EOL



>
>>   - fetch their previous state
>>   (this is visible in the bug, but no idea how to query it)
> Sorry, I have no idea for this one.
>

Ah, you beat me to do this:


F30 - 41 components:

https://bugzilla.redhat.com/buglist.cgi?bug_id=1674516_id_type=anddependson_status=CLOSED=bug_status=OP_id=10414961=changedfrom_format=advanced=EOL=ASSIGNED


F29 - 2 components:

https://bugzilla.redhat.com/buglist.cgi?bug_id=1602938_id_type=anddependson_status=CLOSED=bug_status=OP_id=10414961=changedfrom_format=advanced=EOL=ASSIGNED


F28 - 25 components: 

https://bugzilla.redhat.com/buglist.cgi?bug_id=1555378_id_type=anddependson_status=CLOSED=bug_status=OP_id=10414961=changedfrom_format=advanced=EOL=ASSIGNED


Interestingly enough, some people who complains the most about the
process are too busy to even switch the component to assigned ...


Vít

___
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: Why retire Python 2 packages and games that still work to end user ?

[Kevin Kofler]

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 (which are not getting ported upstream for whatever 
reason) to the new incompatible version?

Kevin Kofler
___
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 packages recode, python-bibtex, pybliographer

[Zoltan Kota]

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

pybliographer -- The upstream develepoment is not very active and it
depends on python2.
See the bug at https://bugzilla.redhat.com/show_bug.cgi?id=1738934

Thanks.
Zoltan
___
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: Let's revisit the FTBFS policy

[Pavel Valena]

- 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 maintainer, fixing them,
> > taking over the maintenance etc.
> 
> This part is problematic. Because it requires human action that can be seen
> as
> toxic by some.

Only if they're present to notice. In the end, they're late and it was fixed 
for them, or at least someone cares for their work, so they should be... 
grateful?

> 
>  > According to compose report from 20190811 [1], I guess it was ~570
>  > packages. How many of them had associated FTBFS BZs in "ASSIGNED" state
>  > and for which version of Fedora? This would be interesting statistics to
>  > know. My guess is that it was 100 BZs at most, but probably much lower
>  > number.
> 
> "for which version of Fedora" doesn't apply really. Most of the bugs were
> just
> "rawhide" since the latest rawhide -> 30 only happened partially.
> 
> The status data should be visible in Bugzilla, however no idea how to query
> them
> grammatically:
> 
>   - get CLOSED EOL bugzillas blocking the F30FTBFS tracker

This should be it:
  
https://bugzilla.redhat.com/buglist.cgi?bug_id=1674516_id_type=anddependson_status=CLOSED_id=10414793_format=advanced=EOL

>   - fetch their previous state
>   (this is visible in the bug, but no idea how to query it)

Sorry, I have no idea for this one.

> 
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok

Regards,
-- 
Pavel Valena
Software Engineer, Red Hat
Brno, Czech Republic
___
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: What other external trackers would you like added to Bugzilla?

[Ankur Sinha]

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: PGP signature
___
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: Let's revisit the FTBFS policy

[Miro Hrončok]

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 
toxic by some.


> According to compose report from 20190811 [1], I guess it was ~570
> packages. How many of them had associated FTBFS BZs in "ASSIGNED" state
> and for which version of Fedora? This would be interesting statistics to
> know. My guess is that it was 100 BZs at most, but probably much lower
> number.

"for which version of Fedora" doesn't apply really. Most of the bugs were just 
"rawhide" since the latest rawhide -> 30 only happened partially.


The status data should be visible in Bugzilla, however no idea how to query them 
grammatically:


 - get CLOSED EOL bugzillas blocking the F30FTBFS tracker
 - fetch their previous state
 (this is visible in the bug, but no idea how to query it)

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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

pghmcfc pushed to perl-MCE-Shared (f31). "Update to 1.844 (..more)"

[notifications]

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 MCE::Shared
- For example, constructing shared objects at the top of the script (i.e.
  MCE::Shared->scalar, MCE::Shared->cache, et cetera)
- Shared objects are accessible by Plack workers (i.e. Starman)
  - Disable internal signal handling for the shared-manager process if
spawned from inside a thread or process
  - MCE::Hobo workers exit immediately upon receiving a SIGSEGV signal; this
safegaurds IPC from stalling inside the manager process
  - Enhanced the _wait_one private function in MCE::Hobo
  - Removed Prima from the list for auto-enabling the posix_exit option; Prima
(since 1.52) is parallel safe during global cleanup
  - Reached 100% Pod coverage

---

diff --git a/perl-MCE-Shared.spec b/perl-MCE-Shared.spec
index d0a6e5e..27ecd2e 100644
--- a/perl-MCE-Shared.spec
+++ b/perl-MCE-Shared.spec
@@ -1,5 +1,5 @@
 Name:  perl-MCE-Shared
-Version:   1.843
+Version:   1.844
 Release:   1%{?dist}
 Summary:   MCE extension for sharing data, supporting threads and processes
 License:   GPL+ or Artistic
@@ -21,7 +21,7 @@ BuildRequires:perl(Carp)
 BuildRequires: perl(constant)
 BuildRequires: perl(Errno)
 BuildRequires: perl(if)
-BuildRequires: perl(MCE) >= 1.843
+BuildRequires: perl(MCE) >= 1.844
 BuildRequires: perl(MCE::Mutex)
 BuildRequires: perl(MCE::Signal)
 BuildRequires: perl(MCE::Util)
@@ -44,7 +44,7 @@ BuildRequires:perl(Test::More) >= 0.88
 # Runtime
 Requires:  perl(:MODULE_COMPAT_%(eval "$(perl -V:version)"; echo $version))
 Requires:  perl(IO::FDPass) >= 1.2
-Requires:  perl(MCE) >= 1.843
+Requires:  perl(MCE) >= 1.844
 Requires:  perl(overloading)
 Requires:  perl(POSIX)
 Requires:  perl(Storable) >= 2.04
@@ -96,6 +96,21 @@ make test
 %{_mandir}/man3/MCE::Shared::Server.3*
 
 %changelog
+* Thu Aug 15 2019 Paul Howarth  - 1.844-1
+- Update to 1.844
+  - Completed validation running Kelp and Raisin apps with MCE::Shared
+- For example, constructing shared objects at the top of the script (i.e.
+  MCE::Shared->scalar, MCE::Shared->cache, et cetera)
+- Shared objects are accessible by Plack workers (i.e. Starman)
+  - Disable internal signal handling for the shared-manager process if
+spawned from inside a thread or process
+  - MCE::Hobo workers exit immediately upon receiving a SIGSEGV signal; this
+safegaurds IPC from stalling inside the manager process
+  - Enhanced the _wait_one private function in MCE::Hobo
+  - Removed Prima from the list for auto-enabling the posix_exit option; Prima
+(since 1.52) is parallel safe during global cleanup
+  - Reached 100%% Pod coverage
+
 * Wed Jul 24 2019 Paul Howarth  - 1.843-1
 - Update to 1.843
   - Updated results in MCE::Hobo (Parallel::ForkManager-like demonstration)
diff --git a/sources b/sources
index d3c2178..b5f3462 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (MCE-Shared-1.843.tar.gz) = 
132b25d84784dec221de7e1dfaacb4f24e43e0690cb48edebc0670da27326227d4d6c889abbbf380cd1af74ac2184376266e9d6fd330923b46dac65d139c6cb7
+SHA512 (MCE-Shared-1.844.tar.gz) = 
3ea220bed2042df585842529a1de48c60ca407f2e0cce6e468aa35e85fcc6da69b5d61ea6ffb036ff9b8d67b7a325c7528f0c1dc483bf66ecb5bf4140c3d3cbb



https://src.fedoraproject.org/rpms/perl-MCE-Shared/c/9680086198dc9542bec569d9e4992e5b0c189271?branch=f31
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

pghmcfc pushed to perl-MCE-Shared (master). "Update to 1.844 (..more)"

[notifications]

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 MCE::Shared
- For example, constructing shared objects at the top of the script (i.e.
  MCE::Shared->scalar, MCE::Shared->cache, et cetera)
- Shared objects are accessible by Plack workers (i.e. Starman)
  - Disable internal signal handling for the shared-manager process if
spawned from inside a thread or process
  - MCE::Hobo workers exit immediately upon receiving a SIGSEGV signal; this
safegaurds IPC from stalling inside the manager process
  - Enhanced the _wait_one private function in MCE::Hobo
  - Removed Prima from the list for auto-enabling the posix_exit option; Prima
(since 1.52) is parallel safe during global cleanup
  - Reached 100% Pod coverage

---

diff --git a/perl-MCE-Shared.spec b/perl-MCE-Shared.spec
index d0a6e5e..27ecd2e 100644
--- a/perl-MCE-Shared.spec
+++ b/perl-MCE-Shared.spec
@@ -1,5 +1,5 @@
 Name:  perl-MCE-Shared
-Version:   1.843
+Version:   1.844
 Release:   1%{?dist}
 Summary:   MCE extension for sharing data, supporting threads and processes
 License:   GPL+ or Artistic
@@ -21,7 +21,7 @@ BuildRequires:perl(Carp)
 BuildRequires: perl(constant)
 BuildRequires: perl(Errno)
 BuildRequires: perl(if)
-BuildRequires: perl(MCE) >= 1.843
+BuildRequires: perl(MCE) >= 1.844
 BuildRequires: perl(MCE::Mutex)
 BuildRequires: perl(MCE::Signal)
 BuildRequires: perl(MCE::Util)
@@ -44,7 +44,7 @@ BuildRequires:perl(Test::More) >= 0.88
 # Runtime
 Requires:  perl(:MODULE_COMPAT_%(eval "$(perl -V:version)"; echo $version))
 Requires:  perl(IO::FDPass) >= 1.2
-Requires:  perl(MCE) >= 1.843
+Requires:  perl(MCE) >= 1.844
 Requires:  perl(overloading)
 Requires:  perl(POSIX)
 Requires:  perl(Storable) >= 2.04
@@ -96,6 +96,21 @@ make test
 %{_mandir}/man3/MCE::Shared::Server.3*
 
 %changelog
+* Thu Aug 15 2019 Paul Howarth  - 1.844-1
+- Update to 1.844
+  - Completed validation running Kelp and Raisin apps with MCE::Shared
+- For example, constructing shared objects at the top of the script (i.e.
+  MCE::Shared->scalar, MCE::Shared->cache, et cetera)
+- Shared objects are accessible by Plack workers (i.e. Starman)
+  - Disable internal signal handling for the shared-manager process if
+spawned from inside a thread or process
+  - MCE::Hobo workers exit immediately upon receiving a SIGSEGV signal; this
+safegaurds IPC from stalling inside the manager process
+  - Enhanced the _wait_one private function in MCE::Hobo
+  - Removed Prima from the list for auto-enabling the posix_exit option; Prima
+(since 1.52) is parallel safe during global cleanup
+  - Reached 100%% Pod coverage
+
 * Wed Jul 24 2019 Paul Howarth  - 1.843-1
 - Update to 1.843
   - Updated results in MCE::Hobo (Parallel::ForkManager-like demonstration)
diff --git a/sources b/sources
index d3c2178..b5f3462 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (MCE-Shared-1.843.tar.gz) = 
132b25d84784dec221de7e1dfaacb4f24e43e0690cb48edebc0670da27326227d4d6c889abbbf380cd1af74ac2184376266e9d6fd330923b46dac65d139c6cb7
+SHA512 (MCE-Shared-1.844.tar.gz) = 
3ea220bed2042df585842529a1de48c60ca407f2e0cce6e468aa35e85fcc6da69b5d61ea6ffb036ff9b8d67b7a325c7528f0c1dc483bf66ecb5bf4140c3d3cbb



https://src.fedoraproject.org/rpms/perl-MCE-Shared/c/9680086198dc9542bec569d9e4992e5b0c189271?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

unable to branch to epel8

[Dave Love]

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
.  Can someone
tell me what to do about that?

Also, I don't get any notifications from pagure (as with various other
-- most? -- services), despite turning on anything relevant-looking in
the notifications app.  I've asked several times about lack of
notifications with no luck or suggestions how to debug it.  Can anyone
make any suggestions now?

I'm increasingly un-motivated to do maintenance particularly because of
continual infrastructure problems.
___
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

pghmcfc pushed to perl-Specio (f31). "Update to 0.44 (..more)"

[notifications]

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 is much
smaller and provides the one subroutine from B we cared about (based on
GH#15)
- Use %{make_build} and %{make_install}

---

diff --git a/perl-Specio.spec b/perl-Specio.spec
index 6f4ee9b..e4837fd 100644
--- a/perl-Specio.spec
+++ b/perl-Specio.spec
@@ -5,13 +5,15 @@
 %bcond_with perl_Specio_enables_optional_test
 %endif
 
+# TODO: Use perl(XString) in preference to perl(B) if it becomes available
+
 Name:  perl-Specio
-Version:   0.43
-Release:   5%{?dist}
+Version:   0.44
+Release:   1%{?dist}
 Summary:   Type constraints and coercions for Perl
 License:   Artistic 2.0
 URL:   https://metacpan.org/release/Specio
-Source0:   
https://cpan.metacpan.org/authors/id/D/DR/DROLSKY/Specio-%{version}.tar.gz
+Source0:   
https://cpan.metacpan.org/modules/by-module/Test/Specio-%{version}.tar.gz
 BuildArch: noarch
 # Module Build
 BuildRequires: coreutils
@@ -66,6 +68,7 @@ BuildRequires:perl(namespace::autoclean)
 %endif
 # Dependencies
 Requires:  perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+Requires:  perl(B)
 Requires:  perl(Ref::Util) >= 0.112
 Requires:  perl(Sub::Util) >= 1.40
 
@@ -98,10 +101,10 @@ types.
 
 %build
 perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1 NO_PERLLOCAL=1
-make %{?_smp_mflags}
+%{make_build}
 
 %install
-make install DESTDIR=%{buildroot}
+%{make_install}
 %{_fixperms} -c %{buildroot}
 
 %check
@@ -157,6 +160,13 @@ make test
 %{_mandir}/man3/Test::Specio.3*
 
 %changelog
+* Thu Aug 15 2019 Paul Howarth  - 0.44-1
+- Update to 0.44
+  - Replaced the use of B with XString if it is installed; the latter is much
+smaller and provides the one subroutine from B we cared about (based on
+GH#15)
+- Use %%{make_build} and %%{make_install}
+
 * Fri Jul 26 2019 Fedora Release Engineering  - 
0.43-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
 
diff --git a/sources b/sources
index 1966da7..6b398b2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Specio-0.43.tar.gz) = 
6523fab79df4a66824da554ee86d6bad1953a4e542a7ef09d1b0727b7449f54e903234ba34587a52592c7397b51cd6d2ae9c555813e121aa7096d60a90998274
+SHA512 (Specio-0.44.tar.gz) = 
5292927383ff3eef3c32a81188a108c009367644117af23b31665550cc4b51d47f0bc0c6791dce3caebb27cd7a92307370f41afe62b65682205cd91b7e99cd43



https://src.fedoraproject.org/rpms/perl-Specio/c/62b9138893d3dcb030bbf9d391a818846a703377?branch=f31
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: Let's revisit the FTBFS policy

[Vít Ondruch]

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 "special" or "unique" cases. As you want. The point is
if there is no rule as retiring packages which has the last FTBFS bug in
ASSIGNED state for whatever reason, there is no rule to break. IOW
trying to define rules for this case is overkill.

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.


>
> I still think that if somebody would need to keep package unretired
> for 1.5+ years, they have options:
>
>  - let it be retired, unretire, retag (as in: "I don't give a damn")
>  - request an exception with proper reasons (as in: "I have proper
> reasons")


Yes, right, but the maintainer already have taken action, they switched
their bugs from NEW to ASSIGNED. They had to evaluate it is worth of the
action. Why we should explicitly believe they did not do it in good faith?


>
> Just being able to let the package rot for 3+ releases is not good
> enough reason IMHO.
>

There needs to be taken action prior the package is left rotting!

Actually, do you happen to know how many components were retired?
According to compose report from 20190811 [1], I guess it was ~570
packages. How many of them had associated FTBFS BZs in "ASSIGNED" state
and for which version of Fedora? This would be interesting statistics to
know. My guess is that it was 100 BZs at most, but probably much lower
number.


Vít



[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EVRBVAWCJZLSEAX33MFTSIXLOSDVPWPU/

___
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

pghmcfc pushed to perl-Specio (master). "Update to 0.44 (..more)"

[notifications]

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 is much
smaller and provides the one subroutine from B we cared about (based on
GH#15)
- Use %{make_build} and %{make_install}

---

diff --git a/perl-Specio.spec b/perl-Specio.spec
index 6f4ee9b..e4837fd 100644
--- a/perl-Specio.spec
+++ b/perl-Specio.spec
@@ -5,13 +5,15 @@
 %bcond_with perl_Specio_enables_optional_test
 %endif
 
+# TODO: Use perl(XString) in preference to perl(B) if it becomes available
+
 Name:  perl-Specio
-Version:   0.43
-Release:   5%{?dist}
+Version:   0.44
+Release:   1%{?dist}
 Summary:   Type constraints and coercions for Perl
 License:   Artistic 2.0
 URL:   https://metacpan.org/release/Specio
-Source0:   
https://cpan.metacpan.org/authors/id/D/DR/DROLSKY/Specio-%{version}.tar.gz
+Source0:   
https://cpan.metacpan.org/modules/by-module/Test/Specio-%{version}.tar.gz
 BuildArch: noarch
 # Module Build
 BuildRequires: coreutils
@@ -66,6 +68,7 @@ BuildRequires:perl(namespace::autoclean)
 %endif
 # Dependencies
 Requires:  perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+Requires:  perl(B)
 Requires:  perl(Ref::Util) >= 0.112
 Requires:  perl(Sub::Util) >= 1.40
 
@@ -98,10 +101,10 @@ types.
 
 %build
 perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1 NO_PERLLOCAL=1
-make %{?_smp_mflags}
+%{make_build}
 
 %install
-make install DESTDIR=%{buildroot}
+%{make_install}
 %{_fixperms} -c %{buildroot}
 
 %check
@@ -157,6 +160,13 @@ make test
 %{_mandir}/man3/Test::Specio.3*
 
 %changelog
+* Thu Aug 15 2019 Paul Howarth  - 0.44-1
+- Update to 0.44
+  - Replaced the use of B with XString if it is installed; the latter is much
+smaller and provides the one subroutine from B we cared about (based on
+GH#15)
+- Use %%{make_build} and %%{make_install}
+
 * Fri Jul 26 2019 Fedora Release Engineering  - 
0.43-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
 
diff --git a/sources b/sources
index 1966da7..6b398b2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Specio-0.43.tar.gz) = 
6523fab79df4a66824da554ee86d6bad1953a4e542a7ef09d1b0727b7449f54e903234ba34587a52592c7397b51cd6d2ae9c555813e121aa7096d60a90998274
+SHA512 (Specio-0.44.tar.gz) = 
5292927383ff3eef3c32a81188a108c009367644117af23b31665550cc4b51d47f0bc0c6791dce3caebb27cd7a92307370f41afe62b65682205cd91b7e99cd43



https://src.fedoraproject.org/rpms/perl-Specio/c/62b9138893d3dcb030bbf9d391a818846a703377?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: RFC: Drop lz4-static

[David Sommerseth]

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 for no other
> reason than it eliminates ten lines from the specfile.  The question was
> whether there is any pressing reason to refrain from removing it.

Sure is!  Byt I still don't think there's any benefit caring much about an
additional sub-package in such a tiny package.

In this case the changelog is actually 2/3 of the complete spec file.  And
these 10-11 lines (including blank lines) related to the -static subpackage
are roughly 14% of the "non-changelog" section of the .spec file.

But as I said earlier, for static libraries, it is harder to get some kind of
usage statistics who uses them or not, as you only need that library during
the compile time.   So combine that with the effort of reducing the spec file
with 10-11 lines, I'm not sure it's such a big difference in maintainability
or the efforts required to keep them around.

Just my 2 cents.


-- 
kind regards,

David Sommerseth
___
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: Join the new Minimization Team

[Adam Samalik]

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 the\n# symlink at /etc/krb5.conf.d/crypto-policies which will
> > not be
> > recreated.\nincludedir /etc/krb5.conf.d/\n' /etc/krb5.conf
> > fi
> > exit 0
> >
> > So... there's not actually a call to awk.  And the last version of
> > Fedora to have anything older than 1.15.1 was F28.
>
> Please CC maintainers when discussing their package.  We like it because
> it avoids us getting blindsided by requirements/changes, and sometimes
> we know things about our packages and can be helpful :)
>

Absolutely we need to engage with maintainers when debating changes. Doing
this in isolation would basically mean failure.


>
> There are two uses of awk: one at build-time, and one for the triggers.
> I assume no one cares that I need awk to build.  You're correct that the
> use for the triggers can probably go away since they're aren't any right
> now, but... does this actually matter?  Please file a bugzilla if so.
>
> > We don't supports updates from F28 to F31 (and certainly not updates
> > from F28 when it was rawhide), so the scriptlet is no longer necessary
> > at all.  It has come and gone a few times throughout history but the
> > dependency has remained.
>
> Just because something /can/ go doesn't mean it /should/.


Yep!


> A trigger
> that doesn't fire won't hurt anything, and its removal is more noise to
> filter through.  And there are often other considerations: for instance,
> the el8 spec file is branched from the Fedora one - el7 has a
> 1.15-series krb5.  The upgrade window I have to support is larger than
> what's mandated by Fedora - and that's fine!  It's not causing any
> problems for other things, so it doesn't matter to anyone but me.
>
> Thanks,
> --Robbie
> ___
> 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
>


-- 

Adam Šamalík
---
Senior Software Engineer
Red Hat
___
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: Let's revisit the FTBFS policy

[Panu Matilainen]

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 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-243-rc1

[Vít Ondruch]

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 RPM version comparison when all you have
>> to deal with is a string that represents an RPM N(E)VR(A) somehow
>> (that's 'name', 'epoch', 'version', 'release', 'arch').
> I think we should do away with NEVRA comparison entirely and just use "R",


Or we could use just "E" O:-)


Vít


> which would be an integer which would increase with each git commit and
> never reset. Third party repos which want to override the base could use
> modules to do so. (So it'd become NMRA.) There would be no need for
> complicated parsing or ordering logic, and we wouldn't need to care what the
> upstream scheme is. Upstream could use rainbow color order and everything
> would be fine. Plus, we could easily decide that _we_ need to go back to an
> older version without introducing epoch madness.
>
___
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: Better interactivity in low-memory situations

[Artem Tim]

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/
___
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: Let's revisit the FTBFS policy

[Miro Hrončok]

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 1.5+ 
years, they have options:


 - let it be retired, unretire, retag (as in: "I don't give a damn")
 - request an exception with proper reasons (as in: "I have proper reasons")

Just being able to let the package rot for 3+ releases is not good enough reason 
IMHO.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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