[Bug 1828234] perl-Date-Holidays-DE-2.05 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Date-Holidays-DE-2.05- |perl-Date-Holidays-DE-2.05-
   |1.fc31  |1.fc31
   |perl-Date-Holidays-DE-2.05- |perl-Date-Holidays-DE-2.05-
   |1.fc32  |1.fc32
   ||perl-Date-Holidays-DE-2.05-
   ||1.el8



--- Comment #15 from Fedora Update System  ---
FEDORA-EPEL-2020-36162c5f0c has been pushed to the Fedora EPEL 8 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
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 1834480] perl-FFI-CheckLib-0.27 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-2020-12cd8fc8b8 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-12cd8fc8b8`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-12cd8fc8b8

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


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

[389-devel] 389 DS nightly 2020-05-13 - 93% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/05/13/report-389-ds-base-1.4.4.2-20200512gitd45d8bd.fc31.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

Re: Re-Launching the Java SIG

[Gerald Henriksen]

On Tue, 12 May 2020 15:58:39 -0500, you wrote:

>As someone who has been burned due to Fedora's goody little two shoes 
>policies, I'd kindly ask that Fedora take a hike and not package the 
>software at all.

The only way to make sure that the stuff included with Fedora is open
source is to build it from source - simply grabbing a binary provided
by an upstream means upstream could slip in some closed source
portions or have such a complex and undocumented build system that the
project may as well be closed source because no one else can build it.
___
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 1835063] New: perl-Mail-DKIM-1.20200513.1 is available

[bugzilla]

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

Bug ID: 1835063
   Summary: perl-Mail-DKIM-1.20200513.1 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Mail-DKIM
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, ky...@kylev.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.20200513.1
Current version/release in rawhide: 0.58-2.fc32
URL: http://search.cpan.org/dist/Mail-DKIM/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/11868/


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

4.4+ squashfs-tools in rawhide

[Bruno Wolff III]

I finally built 4.4 for rawhide. We already had back-ported zstd, but this 
gives us reproducible builds and a few other things.


I'm noting this here, because squashfs-tools is used for some important 
stuff and in the case it breaks something I wanted people to know 
that it might be due to this update. I did run the squash / unsquash 
tests successfully, so I'm not expecting anything to break.


I'm currently not planning on doing builds for f31 or f32. But will 
consider it if there is demand.

___
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: Re-Launching the Java SIG

[Philip Rhoades]

Ty,


On 2020-05-13 06:58, Ty Young wrote:

On 5/12/20 5:55 AM, Felix Schwarz wrote:

Am 12.05.20 um 12:32 schrieb Ty Young:
Right, I figured it was some Fedora policy and not up to you. I 
suppose I
should have been more clear there. Sorry for any confusion, it was 
aimed at

the Fedora project as a whole as this is a Fedora issue.
This is not a Fedora issue but a consequence of Fedora's core values. 
You not
agree with it but "building from source" is so fundamental that it 
does not

make sense to even start a discussion about it on fedora-devel.

I suggest you read up on the rationale behind that policy (which is 
why I

linked the policy document in the first place).

I understand that missing components/features due to the source 
requirement
are annoying but Fedora (and other distros) decided to take the "high 
road"
here and actually fix stuff instead of shipping whatever upstream came 
up with.



As someone who has been burned due to Fedora's goody little two shoes
policies, I'd kindly ask that Fedora take a hike and not package the
software at all.



That should be "little goody two shoes policies" . .

P.
--
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  p...@pricom.com.au
___
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: CPE Weekly: 2020-05-11

[clime]

On Tue, 12 May 2020 at 16:28, Clement Verna  wrote:
>
> On Mon, 11 May 2020 at 12:55, Clement Verna  wrote:
>>
>>
>>
>> On Mon, 11 May 2020 at 11:03, Fabio Valentini  wrote:
>>>
>>> On Mon, May 11, 2020 at 10:42 AM Aoife Moloney  wrote:
>>> > ## GitForge Updates
>>> > * We are tracking our progress here (nothing new added yet, fyi)
>>> > https://fedoraproject.org/wiki/Git_forge_update
>>> > * And the council are tracking the community issues in this ticket
>>> > https://pagure.io/Fedora-Council/tickets/issue/292
>>> > * I have an  Office hours IRC meeting slot on #fedora-meeting-1 @
>>> > 1400-1500 UTC every Thursday. Feel free to stop by and say hi! We can
>>> > talk about Gitforge, or not :)
>>>
>>> I'm wondering, is actually anything happening here?
>>
>>
>> Yes, I am still gathering the "pain points". I am going to open a ticket in 
>> the GitLab tracker (http://gitlab.com/gitlab-org/gitlab) this week, so that 
>> all the discussions about what we are asking will be public.
>
>
> Hey so we now have a public issue[0] with GitLab that we are going to use to 
> drive the conversation. So if you are interested I highly encourage you to 
> follow that issue. Also this is currently focusing on the very basic features 
> of dist-git in purpose once we have a better idea on how these features looks 
> like in GitLab, we will be able to take a look at the rest of our needs.
>
> Hope that helps
>
> PS: If there is anything that you feel should be mentioned in the ticket, 
> please feel free to tell me about it so that I can look at editing the ticket.
>
> [0] - https://gitlab.com/gitlab-org/gitlab/-/issues/217350

Clement, thank you for your open approach. It's a welcomed change (I
mean considering what we have seen from CPE leaders so far).

>
>>
>>
>>>
>>> The "progress" being tracked in the wiki has been "nothing yet" since
>>> the wiki page was announced a few weekly reports ago, and the linked
>>> council ticket has not been updated in 2-3 weeks either :/
>>>
>>>
>>> Fabio
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct: 
>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives: 
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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: Is dist-git a good place for work?

[clime]

On Fri, 8 May 2020 at 21:13, David Cantrell  wrote:
>
> On Mon, May 04, 2020 at 05:05:02PM +0200, Tomas Tomecek wrote:
> >Let’s talk about dist-git, as a place where we work. For us,
> >packagers, it’s a well-known place. Yet for newcomers, it may take a
> >while to learn all the details. Even though we operate with projects
> >in a dist-git repository, the layout doesn’t resemble the respective
> >upstream project.
> >
> >There is a multitude of tasks we tend to perform in a dist-git repo:
> >* Bumping a release field for sake of a rebuild.
> >* Updating to the latest upstream release.
> >* Resolving CVEs.
> >* Fixing bugs by…
> >  * Changing a spec file.
> >  * Pulling a commit from upstream.
> >  * Or even backporting a commit.
> >* And more...
> >
> >For some tasks, the workflow is just fine and pretty straightforward.
> >But for the other, it’s very gruesome - the moment you need to touch
> >patch files, the horror comes in. The fact that we operate with patch
> >files, in a git repository, is just mind-boggling to me.
> >
> >Luckily, we have tooling which supports the repository layout -
> >`fedpkg prep`, `srpm` or `mockbuild` are such handy commands - you can
> >easily inspect the source tree or make sure your local change builds.
> >
> >Where am I getting with this?
> >
> >Over the years there have been multiple tools created to improve the
> >development experience:
> >rdopkg [r], rpkg-util [ru], tito [t] and probably much much more (e.g.
> >the way Fedora kernel developers work on kernel [k]).
> >
> >In the packit project, we work in source-git repositories. These are
> >pretty much upstream repositories combined with Fedora downstream
> >packaging files. An example: I recently added a project called nyancat
> >[n] to Fedora. I have worked [w] on packaging the project in the
> >GitHub repo and then just pushed the changes to dist-git using packit
> >tooling. These source-git repositories can live anywhere: we have
> >support for GitHub right now and are working on supporting pagure.
> >
> >Would there be an interest within the community, as opt-in, to have
> >such source-git repositories created for respective dist-git
> >repositories? The idea is that you would work in the source-git repo
> >and then let packit handle synchronization with a respective dist-git
> >repo. Our aim is to provide the contribution experience you have in
> >GitHub when working on your packages. Dist-git would still be the
> >authoritative source and a place where official builds are done - the
> >source-git repo would work as a way to collaborate. We also don’t have
> >plans right now to integrate packit into fedpkg.
> >
> >The main reason I am sending this is to gather feedback from all of
> >you whether there is an interest in such a workflow. We don’t have
> >concrete plans for Fedora right now but based on your feedback we
> >could.
>
> Tomas,
>
> This is an interesting idea and it is a direction I would like to see dist-git
> move.  I do not think it's possible to find a one size fits all approach since
> every package has and needs varying workflows.  And we should be flexible to
> let teams and developers do what they need to do.  For me, moving spec files
> upstream does not seem that appealing from a package maintenance standpoint.
> I still like the clear distinction between the upstream project and the
> 'Fedora bits' that make it a package we ship.  But that might not be the case
> for every package.
>
> I have read through this thread as of 3pm Boston time on 08-May and there's a
> lot of great feedback.  I wanted to offer my own thoughts on what I'd like to
> see related to this topic:
>
> WHAT I WANT TO BE ABLE TO DO:
>
> * View Fedora's dist-git repos as authoritative for packages built for
>Fedora.  That is, I want to see a package on my Fedora system and be able 
> to
>visit its dist-git repo to see how it's packaged.
>
> * Make the lookaside cache optional.  For SourceX lines, I want to be able to
>specify a git URL to a specific tag.  fedpkg should use git archive to
>include that in the SRPM.  e.g.:
>
>Source0: https://github.com/rpminspect/rpminspect/archive/v0.12
>
> * If we offer the above, honor signed git tags for verification at build time.
>
> * Make PatchX lines optional.  In dist-git, I should be able to set a remote
>pointing to the upstream repo.  Then do the Fedora work on the appropriate
>Fedora branch.  SourceX should still become a tarball using git archive and
>the tag.  Patches should be automatically generated for SRPM construction
>using git format-patch or something comparing the Fedora dist-git branch
>with the remote branch.  Multiple remotes should be possible should new and
>old versions of the upstream project need to be supported.  Fedora dist-git
>branches should know their remote.
>
> * I still want to be able to do 'fedpkg srpm' and get a standalone
>ready-to-build SRPM file that I can carry around.
>
> * Possibly 

Re: Is dist-git a good place for work?

[clime]

On Tue, 12 May 2020 at 23:06, Ken Dreyer  wrote:
>
> On Tue, May 12, 2020 at 1:45 AM clime  wrote:
> >
> > Ken, would it be, please, possible to provide links to the patch
> > branches and mentioned dist-git repos. I would like to have a closer
> > look.
>
> Sure. I can't share the links to the RH Ceph Storage dist-git repos,
> so I will give one example where I used rdopkg in Fedora recently.
>
> Here is an example where I bumped the version of a Python package and
> included some cherry-picked patches:
>
> https://src.fedoraproject.org/rpms/python-jenkins-job-builder/c/78b70d24cf65a4c7a100d3e56358ae22d3a6eaf6?branch=master
>
> At first glance, the two new patches I included there look like the
> output from "git-format-patch", and that is because rdopkg wraps
> git-format-patch for some operations. rdopkg automatically inserted
> those into the .spec file, and it also formats them with some
> compatibility options to preserve the .patch file formats between RHEL
> 7's Git 1.8.3.1 + RHEL 8's Git 2.18.2 + Fedora's Git, so that it does
> not matter what OS the packager is running.
>
> So that's the change in "master" (dist-git's rawhide branch), and
> there is a corresponding "master-patches" branch to go along with
> that:
>
> https://fedorapeople.org/cgit/ktdreyer/public_git/python-jenkins-job-builder.git/?h=master-patches
>
> In my dist-git clone on my laptop, I have three remotes, set up like this:
>
> $ git remote -v
> origin
> ssh://ktdre...@pkgs.fedoraproject.org/rpms/python-jenkins-job-builder
> (fetch)
> origin
> ssh://ktdre...@pkgs.fedoraproject.org/rpms/python-jenkins-job-builder
> (push)
> patches
> ssh://fedorapeople.org/home/fedora/ktdreyer/public_git/python-jenkins-job-builder.git
> (fetch)
> patches
> ssh://fedorapeople.org/home/fedora/ktdreyer/public_git/python-jenkins-job-builder.git
> (push)
> upstreamhttps://opendev.org/jjb/jenkins-job-builder.git (fetch)
> upstreamhttps://opendev.org/jjb/jenkins-job-builder.git (push)
>
> "rdopkg new-version" will update to the latest upstream version for
> me. Specifically it looks at the upstream repo, finds the latest Git
> tag, parses that tag string into a number, writes that number into the
> .spec file, downloads and uploads the new upstream tarball, etc. It
> will also rebase my "patches" branch for me and edit the Patch entries
> as necessary.
>
> I haven't done that today for the sake of this example, but at some
> point in the future I will run "rdopkg new-version", and it will pull
> in 3.3.0 and eliminate those two patches, since they're both included
> in version 3.3.0 upstream.
>
> In fact, you can try it on your computer if you set up the Git clones
> like I've done above. If you run "rdopkg new-version", then rdopkg
> will rewrite the "master-patches" branch, and then prompt you to
> force-push this to the "patches" remote. You won't have SSH access to
> push to my fedorapeople.org repo, so just imagine that is a team repo
> where many people on my team can push :) This just a really simple
> example with two patches in one small package.

Thanks a lot!

> Ceph we do this at a slightly different point of time. We use
> "rdopkg tag-patches" to save each of the "patches" refs that we've
> translated into patch series in dist-git. Each Git tag is the NVR of
> the package.

When you do rdopkg new-version and you are asked to force push, is
also the current master-patches HEAD tagged with the current package
NVR?

Somewhere I was expecting to see a lot of NVR tags for past sate of
master-patches (i assume, you could have also f32-patches,
f31-patches, epel8-patches, ... ?) but I don't see those tags :) that
would form the mentioned "history of histories".

Thanks again
clime

>
> - Ken
> ___
> 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: Retired packages with maintainers

[Kevin Fenzi]

On Tue, May 12, 2020 at 03:13:42PM +0200, Pierre-Yves Chibon wrote:
> On Tue, May 12, 2020 at 02:51:03PM +0200, Miro Hrončok wrote:
> > On 12. 05. 20 8:49, Pierre-Yves Chibon wrote:
> > > Finally, does everyone agree about the original request: "remove all 
> > > maintainers
> > > of retired packages"? Or should we bring this to FESCo?
> > 
> > If the procedure is "remove all maintainers if all branches are retired or
> > EOL" than yes, this is a good thing. However, not sure if worth spending
> > energy on. What are the benefits over status quo?
> 
> Someone asked us to look into this, so I did, briefly.
> I am also very happy to close the ticket as "Won't fix" and move on :)

I think it might be worth it... it makes it more clear how many packages
someone maintains and what their status is. 

kevin


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: Orphaned packages looking for new maintainers

[Kevin Fenzi]

On Mon, May 11, 2020 at 09:55:45PM +0200, Dominique Martinet wrote:
> Hi,
> 
> Miro Hrončok wrote on Mon, May 11, 2020 at 07:42:09PM +0200:
> > Request package ownership via the *Take* button in he left column on
> > https://src.fedoraproject.org/rpms/
> >
> > waypipe   orphan   5 weeks 
> > ago
> 
> I would be interested in taking waypipe. The project is still active
> upstream[1] (FTBS[2] in fedora had already been fixed there), does work
> as of right now (tested on fedora32), and it is generally something I
> would consider useful... There just aren't many wayland applications one
> would want to "ssh -X" into yet, but as long as upstream is active I
> would support it.
> 
> 
> I'm not a maintainer though, so can't just hit "take".
> What would the procedure be for that? Wait until it gets orphaned next
> week and submit it again as a new package?
> 
> In the off-chance it might get revived without going through the orphan
> process, I've submitted remote PRs on pagure, both on fedora 32
> branch[3] and master[4] ; the simple koji test succeeded in both.
> 
> [1] https://gitlab.freedesktop.org/mstoeckl/waypipe/-/commits/master
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1800245
> [3] https://src.fedoraproject.org/rpms/waypipe/pull-request/2 (f32)
> [4] https://src.fedoraproject.org/rpms/waypipe/pull-request/1 (master)
> 
> 
> 
> FWIW, looking at the requirements on the "Join the package collection
> maintainers" page[5], I do have all required accounts, introduced myself
> in 2015[6] so just took a bit of time to follow through, and can
> probably beg for a sponsor or two if required (added an ex-coworker in
> Cc who is an active packager, and who would probably vouch for me if
> required. Hi Stéphane!); I just don't see anything about starting from
> an orphaned package. If anyone is on centos lists, I'm also very grumpy,
> but don't speak up much unless I have good reasons to.)
> [5] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
> [6] 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/WFMUCQO65M3YGE2NTV4WUXVNN6UBLLN7/

Hey Dominique. If you haven't found a sponsor yet, drop me an email off
list and I can probibly sponsor you. Thanks for stepping up to maintain
some packages. :) 

kevin


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: New set of questions for FESCo candidates?

[Dan Čermák]

Zbigniew Jędrzejewski-Szmek  writes:

> On Mon, May 11, 2020 at 04:55:03PM -0400, Ben Cotton wrote:
>> On Mon, May 11, 2020 at 4:39 PM Kevin Fenzi  wrote:
>> 
>> > If we just make it an essay with suggestions of what to include, I think
>> > it might be more engaging than just a sentence or two on specific
>> > questions.
>> >
>> > Thinking about it from an editorial perspective, the questionnaire format
>> results in what will likely be more readable posts than a longer essay. The
>> current format does sometimes result in a sentence or two, but a lot of the
>> answers are a paragraph or two. So I'm not sure the end result would be a
>> much different amount of content; some people are going to give shorter
>> replies no matter the form. The other good thing about the current format
>> is that it makes the answers more directly comparable.
>> 
>> That said, I do like the idea of a more free-form response as a way to see
>> how candidates think. I suppose I can toss both at FESCo and let them make
>> the choice. :-)
>
> I'd vote for Nirik's proposal over a fixed set of questions...

I actually like that idea as well, as every candidate can highlight
their own focus better that way.


Cheers,

Dan


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: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

[E.N. virgo]

[…] 
This is getting out of hand, so I logged straight into the web client.
> Ok, I understand what's happening.  Your email client doesn't recognize 
> the in-reply-to option from the url. 
Exactly; I will enquire and send a bug report.
> Why are replying from there instead of using your email client normally?
I set this list to send digests instead of individual messages; 
so, I was using other means to get to the in-reply-to field.
> 
> You can't do it that way.  It has to be a header.  For example, if you 
> look at the source of my previous reply to you, there's this header:
> In-Reply-To: <1854295.N2a68q8abs@pandora>
> So my email client matches that to your email and can link them together.
___
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: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

[virgo]

> From: Samuel Sieb 
> […]
> Are you actually using the Pandora email client?  It's still being =
> developed?  Unfortunately, it appears to not create any of the proper =
> headers.
No, I am not using that.

The thing is, any post at lists.fedoraproject.org/archives/… has a clickable 
“⤣ Reply” URL at the bottom. I clicked on each one of that and typed in my 
replies; that it is how the correct headers were lost.

For this message, I instead inspected the HTML source, manually copied the 
`href` value, and am using that to see if the email will be well threaded. If 
all goes well, I will file a bug against my email client through the 
appropriate channels.

P.S. A moment ago, I failed again at not creating new threads. In any case, 
this will be my last attempt.
___
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: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

[Samuel Sieb]

On 5/12/20 3:01 PM, virgo wrote:

From: Samuel Sieb 
[…]
Please fix your email client.  Every reply you send starts a new thread.

I saw that, my apologies.

Are you actually using the Pandora email client?  It's still being =
developed?  Unfortunately, it appears to not create any of the proper =
headers.

No, I am not using that.


Right, now I see that that's your hostname.
I was thinking it was the client because the only header appeared to be:
Message-ID: <6859652.rBftSncOlI@pandora>
but now I realize that the hostname makes more sense and I see the 
routing shows that.



The thing is, any post on  has a
“⤣ Reply” clickable URL at the bottom. I clicked on every one of that and
typed in my replies; that it is how the correct headers were lost.


Ok, I understand what's happening.  Your email client doesn't recognize 
the in-reply-to option from the url.  Why are replying from there 
instead of using your email client normally?



For this message, I instead inspected the HTML source and manually copied the
`href` value, hoping the email will be well threaded. If all goes well, I will
file a bug against my email client through the appropriate channels.


You can't do it that way.  It has to be a header.  For example, if you 
look at the source of my previous reply to you, there's this header:

In-Reply-To: <1854295.N2a68q8abs@pandora>
So my email client matches that to your email and can link them together.
___
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: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

[virgo]

> From: Samuel Sieb 
> […]
> Please fix your email client.  Every reply you send starts a new thread.
I saw that, my apologies.
> Are you actually using the Pandora email client?  It's still being =
> developed?  Unfortunately, it appears to not create any of the proper =
> headers.
No, I am not using that.

The thing is, any post on  has a 
“⤣ Reply” clickable URL at the bottom. I clicked on every one of that and 
typed in my replies; that it is how the correct headers were lost.

For this message, I instead inspected the HTML source and manually copied the 
`href` value, hoping the email will be well threaded. If all goes well, I will 
file a bug against my email client through the appropriate channels.
___
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: Is dist-git a good place for work?

[Ken Dreyer]

On Tue, May 12, 2020 at 1:45 AM clime  wrote:
>
> Ken, would it be, please, possible to provide links to the patch
> branches and mentioned dist-git repos. I would like to have a closer
> look.

Sure. I can't share the links to the RH Ceph Storage dist-git repos,
so I will give one example where I used rdopkg in Fedora recently.

Here is an example where I bumped the version of a Python package and
included some cherry-picked patches:

https://src.fedoraproject.org/rpms/python-jenkins-job-builder/c/78b70d24cf65a4c7a100d3e56358ae22d3a6eaf6?branch=master

At first glance, the two new patches I included there look like the
output from "git-format-patch", and that is because rdopkg wraps
git-format-patch for some operations. rdopkg automatically inserted
those into the .spec file, and it also formats them with some
compatibility options to preserve the .patch file formats between RHEL
7's Git 1.8.3.1 + RHEL 8's Git 2.18.2 + Fedora's Git, so that it does
not matter what OS the packager is running.

So that's the change in "master" (dist-git's rawhide branch), and
there is a corresponding "master-patches" branch to go along with
that:

https://fedorapeople.org/cgit/ktdreyer/public_git/python-jenkins-job-builder.git/?h=master-patches

In my dist-git clone on my laptop, I have three remotes, set up like this:

$ git remote -v
originssh://ktdre...@pkgs.fedoraproject.org/rpms/python-jenkins-job-builder
(fetch)
originssh://ktdre...@pkgs.fedoraproject.org/rpms/python-jenkins-job-builder
(push)
patches
ssh://fedorapeople.org/home/fedora/ktdreyer/public_git/python-jenkins-job-builder.git
(fetch)
patches
ssh://fedorapeople.org/home/fedora/ktdreyer/public_git/python-jenkins-job-builder.git
(push)
upstreamhttps://opendev.org/jjb/jenkins-job-builder.git (fetch)
upstreamhttps://opendev.org/jjb/jenkins-job-builder.git (push)

"rdopkg new-version" will update to the latest upstream version for
me. Specifically it looks at the upstream repo, finds the latest Git
tag, parses that tag string into a number, writes that number into the
.spec file, downloads and uploads the new upstream tarball, etc. It
will also rebase my "patches" branch for me and edit the Patch entries
as necessary.

I haven't done that today for the sake of this example, but at some
point in the future I will run "rdopkg new-version", and it will pull
in 3.3.0 and eliminate those two patches, since they're both included
in version 3.3.0 upstream.

In fact, you can try it on your computer if you set up the Git clones
like I've done above. If you run "rdopkg new-version", then rdopkg
will rewrite the "master-patches" branch, and then prompt you to
force-push this to the "patches" remote. You won't have SSH access to
push to my fedorapeople.org repo, so just imagine that is a team repo
where many people on my team can push :) This just a really simple
example with two patches in one small package.

- Ken
___
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 1823526] bugzilla fails to build with Sphinx 3.0.0

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|ita...@ispbrasil.com.br |emman...@seyman.fr




-- 
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: Re-Launching the Java SIG

[Ty Young]

On 5/12/20 5:55 AM, Felix Schwarz wrote:

Am 12.05.20 um 12:32 schrieb Ty Young:

Right, I figured it was some Fedora policy and not up to you. I suppose I
should have been more clear there. Sorry for any confusion, it was aimed at
the Fedora project as a whole as this is a Fedora issue.

This is not a Fedora issue but a consequence of Fedora's core values. You not
agree with it but "building from source" is so fundamental that it does not
make sense to even start a discussion about it on fedora-devel.

I suggest you read up on the rationale behind that policy (which is why I
linked the policy document in the first place).

I understand that missing components/features due to the source requirement
are annoying but Fedora (and other distros) decided to take the "high road"
here and actually fix stuff instead of shipping whatever upstream came up with.



As someone who has been burned due to Fedora's goody little two shoes 
policies, I'd kindly ask that Fedora take a hike and not package the 
software at all.



Other software developers SHOULD NEVER have to deal with bug reports 
from Fedora or any other distro because  they want to modify software 
instead of taking what was already made, breaking things as a result. 
This isn't the first time a Linux distro has done this either, IIRC, 
there was an issue with Debian and the developer of the Xscreensaver 
software too.



At worst all you're doing is angering people who want to support Linux 
and at best hurting yourselves. Stop it.





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

[Bug 1834997] New: perl-Test-Smoke-1.76 is available

[bugzilla]

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

Bug ID: 1834997
   Summary: perl-Test-Smoke-1.76 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Test-Smoke
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.76
Current version/release in rawhide: 1.74-1.fc32
URL: http://search.cpan.org/dist/Test-Smoke/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/3418/


-- 
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: LibRaw 0.20 Beta; soname bump

[Gwyn Ciesla via devel]

-- 
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 Tuesday, May 12, 2020 8:24 AM, Gwyn Ciesla via devel 
 wrote:

> ‐‐‐ Original Message ‐‐‐
> On Tuesday, May 12, 2020 5:14 AM, Miro Hrončok mhron...@redhat.com wrote:
> 

> > On 12. 05. 20 0:12, Miro Hrončok wrote:
> 

> > > On 11. 05. 20 22:33, Gwyn Ciesla via devel wrote:
> 

> > > > I'm building LibRaw 0.20 Beta 1 for rawhide, along with all direct 
> > > > consumers,
> > > > in a multi-stage chain build, today, including the following:
> > > > deepin-image-viewer
> > > > elementary-photos
> > > > freeimage
> > > > gthumb
> > > > indi-gphoto
> > > > krita
> > > > luminance-hdr
> > > > photoqt
> > > > shotwell
> > > > efl
> > > > entangle
> > > > gegl04
> > > > ImageMagick
> > > > kf5-libkdcraw
> > > > libpasraw
> > > > nomacs
> > > > OpenImageIO
> > > > rapid-photo-downloader
> > > > siril
> > > > blender
> > > > luxcorerender
> 

> > > I'm getting a lot of broken deps like this:
> > > Problem: package emacs-1:26.3-3.fc33.x86_64 requires
> > > libMagickCore-6.Q16.so.6()(64bit), but none of the providers can be 
> > > installed
> 

> > > -   package emacs-1:26.3-3.fc33.x86_64 requires 
> > > libMagickWand-6.Q16.so.6()(64bit),
> > > but none of the providers can be installed
> > > 

> 

> > > -   conflicting requests
> > > -   nothing provides libraw_r.so.19()(64bit) needed by
> > > ImageMagick-libs-1:6.9.10.86-2.fc32.x86_64
> > > 

> 

> > > 

> 

> > > I see this build was cancelled:
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=44387471
> 

> > I've hit rebuild again:
> 

> > https://koji.fedoraproject.org/koji/taskinfo?taskID=44410327
> 

> Thank you! My apologies, this all worked in my testing, I'll use a side tag 
> next time.
> 

> -G
> 


Everything is now rebuild, except for elementary-photos and shotwell, which are 
failing for a reason I don't totally understand yet; they build on local 
rawhide and in mock but not koji. Investigating.
> > 

> 

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

> 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: Retired packages with maintainers

[Vít Ondruch]

Dne 12. 05. 20 v 20:26 Vít Ondruch napsal(a):
> Dne 12. 05. 20 v 14:51 Miro Hrončok napsal(a):
>> On 12. 05. 20 8:49, Pierre-Yves Chibon wrote:
>>> Finally, does everyone agree about the original request: "remove all
>>> maintainers
>>> of retired packages"? Or should we bring this to FESCo?
>> If the procedure is "remove all maintainers if all branches are
>> retired or EOL" than yes, this is a good thing. However, not sure if
>> worth spending energy on. What are the benefits over status quo?
>>
> For example to be able to see if some packager is active or not? Why the
> Pagure user page [1] should show that somebody maintains some package
> while it is actually not true? In this specific case, there are listed 4
> EOL packages.

Forget to mention, that this page is overview also for myself, if I
should something let go.

And also, since we have lost the ability to manage user privileges per
branch, it is not possible to retire package and remove yourself from
it, because then it would not be possible to maintain the stable
branches. There should be other mechanism to remove the maintainers once
the last branch gets EOL, but there is non AFAIK.


Vít


>
> If you think it is not worth spending the time to provide the correct
> information, then maybe this whole page should be removed from Pagure,
> because it has no value ATM.
>
>
>
> [1] https://src.fedoraproject.org/user/skottler/projects
>
> ___
> 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

[389-devel] please review: PR 51095 - remove more unnecessary slapi entry dups

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/51085

--

389 Directory Server Development Team
___
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

Re: Retired packages with maintainers

[Vít Ondruch]

Dne 12. 05. 20 v 14:51 Miro Hrončok napsal(a):
> On 12. 05. 20 8:49, Pierre-Yves Chibon wrote:
>> Finally, does everyone agree about the original request: "remove all
>> maintainers
>> of retired packages"? Or should we bring this to FESCo?
>
> If the procedure is "remove all maintainers if all branches are
> retired or EOL" than yes, this is a good thing. However, not sure if
> worth spending energy on. What are the benefits over status quo?
>

For example to be able to see if some packager is active or not? Why the
Pagure user page [1] should show that somebody maintains some package
while it is actually not true? In this specific case, there are listed 4
EOL packages.

If you think it is not worth spending the time to provide the correct
information, then maybe this whole page should be removed from Pagure,
because it has no value ATM.



[1] https://src.fedoraproject.org/user/skottler/projects

___
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 rubygem-echoe

[Athos Ribeiro]

Hi,

I am orphaning rubygem-echoe.

The upstream project is dead, some of its dependencies upstreams are
dead and it's past time to let it go.

Regards,

Athos
___
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: Non-responsive maintainer: pcpa

[Athos Ribeiro]

On Sat, May 09, 2020 at 09:57:18PM -0400, Neal Gompa wrote:

Hello all,


Hi Neal,


I've been trying to get python-flask-babel[0] updated to v1.0.0 via
PR[1]. Unfortunately, pcpa hasn't been responding to pings in the PR
or emails.

I've also filed the requisite non-responsive maintainer check bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1833723

Does anyone know how to get in touch with him?


I am Cc'ing Paulo in another email address here.


[0]: https://src.fedoraproject.org/rpms/python-flask-babel
[1]: https://src.fedoraproject.org/rpms/python-flask-babel/pull-request/5

--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

[Samuel Sieb]

Please fix your email client.  Every reply you send starts a new thread.
Are you actually using the Pandora email client?  It's still being 
developed?  Unfortunately, it appears to not create any of the proper 
headers.


On 5/12/20 7:09 AM, virgo wrote:
___
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: Re-Launching the Java SIG

[John W. Himpel]

On Mon, 2020-05-11 at 21:45 +0200, Fabio Valentini wrote:
> This past weekend I finally decided to jump off the cliff and attempt
> to re-launch the Java SIG. It seems there's some interest in keeping
> the Java stack maintained, it's just not focused or organized right
> now.
> 
> What we did when starting the Stewardship SIG seems to have worked
> out
> pretty well, so I'm trying to follow in those footsteps here:
> 
> - new proper FAS / pkgdb group: java-maint-sig ("java-sig" is
> occupied
> by an old, unused bot account)
> - new private mailing list: java-maint-sig (for RHBZ bugs - so,
> possibly, also CVEs - hence, private)
> - tracking project on pagure: https://pagure.io/java-maint-sig (for
> maintenance scripts, tracking tickets, awesome package dashboards,
> etc.)
> 
> There's already a public fedora mailing list for Java (java-devel),
> and and IRC channel (#fedora-java on freenode.net), which we will
> continue to use. Sadly, the existing wiki page for the Java SIG is
> hopelessly outdated, so I'm tempted to just scrap it and point
> readers
> to the pagure tracking project once it's set up beyond a basic README
> file.
> 
> Major upcoming projects for the "new" Java Package Maintainers group
> include:
> 
> - managing OpenJDK 11 / Java 11 transition for hundreds of Java
> packages in fedora 33
> - starting to transition well-maintained Java packages from the
> Stewardship SIG back into Java SIG
> - possibly porting packages from gradle to maven to fix build issues
> and broken dependencies
> - transitioning from old java.net / JavaEE projects to the new ones
> now under the eclipse-ee4j umbrella
> 
> I know that - among others - the PKI team, Neuro SIG, and Eclipse
> maintainers depend on parts of the java stack for their packages, so
> I
> hope that we can work together with them on these things, as well.
> 
> So, if you're interested, please consider joining this group effort.
> I'll get new members set up with the FAS group / pagure project /
> mailing list.
> 
> Let's make this happen.
> Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

I'm basically an developer of jee applications. Not sure how much I can
assist, but will do whatever I can to help.

fas account: jwhimpel

Thanks for doing 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: [fedora-java] Re: Re-Launching the Java SIG

[Fabio Valentini]

On Tue, May 12, 2020 at 6:17 PM Igor Raits
 wrote:
> Count me in! I don't think I can help much, but at least can give some
> suggestions.
>
> > Let's make this happen.
>
> Good luck, Fabio!

Thanks! Every bit of help counts.
You should now be all set with FAS group / pagure project / mailing
list subscription.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Re-Launching the Java SIG

[Fabio Valentini]

On Tue, May 12, 2020 at 5:43 PM Markku Korkeala  wrote:
> Great, really appreciate your work.

Thank you!

> Count me in! I'm relatively new to fedora and rpm packaging, but got ~20
> years of working with Java and my packages depends on the Java
> ecosystem. FAS account: korkeala.
>
> Markku.

Great! You should be all set now. Group membership should show up at
https://src.fedoraproject.org/group/java-maint-sig after logging out
and back in.

Glad to have you on board!

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Re-Launching the Java SIG

[Andrew Haley]

On 5/12/20 11:55 AM, Felix Schwarz wrote:
>
> Am 12.05.20 um 12:32 schrieb Ty Young:
>> Right, I figured it was some Fedora policy and not up to you. I suppose I
>> should have been more clear there. Sorry for any confusion, it was aimed at
>> the Fedora project as a whole as this is a Fedora issue.
>
> This is not a Fedora issue but a consequence of Fedora's core values. You not
> agree with it but "building from source" is so fundamental that it does not
> make sense to even start a discussion about it on fedora-devel.

Yes, exactly. It's not a Java thing, it's a free software thing. If
we just grab binaries how do we know that they respect the basic
freedoms?

> I suggest you read up on the rationale behind that policy (which is
> why I linked the policy document in the first place).
>
> I understand that missing components/features due to the source
> requirement are annoying but Fedora (and other distros) decided to
> take the "high road" here and actually fix stuff instead of shipping
> whatever upstream came up with.

Quite. The high road is never the easy road. Thank you.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
___
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: Re-Launching the Java SIG

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, 2020-05-11 at 21:45 +0200, Fabio Valentini wrote:
> This past weekend I finally decided to jump off the cliff and attempt
> to re-launch the Java SIG. It seems there's some interest in keeping
> the Java stack maintained, it's just not focused or organized right
> now.
> 
> What we did when starting the Stewardship SIG seems to have worked
> out
> pretty well, so I'm trying to follow in those footsteps here:
> 
> - new proper FAS / pkgdb group: java-maint-sig ("java-sig" is
> occupied
> by an old, unused bot account)
> - new private mailing list: java-maint-sig (for RHBZ bugs - so,
> possibly, also CVEs - hence, private)
> - tracking project on pagure: https://pagure.io/java-maint-sig (for
> maintenance scripts, tracking tickets, awesome package dashboards,
> etc.)
> 
> There's already a public fedora mailing list for Java (java-devel),
> and and IRC channel (#fedora-java on freenode.net), which we will
> continue to use. Sadly, the existing wiki page for the Java SIG is
> hopelessly outdated, so I'm tempted to just scrap it and point
> readers
> to the pagure tracking project once it's set up beyond a basic README
> file.
> 
> Major upcoming projects for the "new" Java Package Maintainers group
> include:
> 
> - managing OpenJDK 11 / Java 11 transition for hundreds of Java
> packages in fedora 33
> - starting to transition well-maintained Java packages from the
> Stewardship SIG back into Java SIG
> - possibly porting packages from gradle to maven to fix build issues
> and broken dependencies
> - transitioning from old java.net / JavaEE projects to the new ones
> now under the eclipse-ee4j umbrella
> 
> I know that - among others - the PKI team, Neuro SIG, and Eclipse
> maintainers depend on parts of the java stack for their packages, so
> I
> hope that we can work together with them on these things, as well.
> 
> So, if you're interested, please consider joining this group effort.
> I'll get new members set up with the FAS group / pagure project /
> mailing list.

Count me in! I don't think I can help much, but at least can give some
suggestions.

> Let's make this happen.

Good luck, Fabio!

> Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl66y7cACgkQEV1auJxc
Hh43Gg/+NzTe/eeGyuWQnKkPwiImM0wgg3ZUEMftfURWLFLpK3zNYBK1jH2hNKHY
VA7d3NB4DhTtDAwQUVtFCmcfTuoLpZeKvvlaK5T8z0jIRqBEaHJx8NAqQFhnYw0q
NGjvogdsQMW1uFbnBJrxD3o2CIXwonmE4va204vOLMybF+jSw/1s6GlLVZgX6PsL
lSGIfmYWyf5UVUUwhP4zfzKZy56EEIOVjN+gq0ZdywPQyEfz+lpbKsBdCjL/Gwf7
wMJm0Y+tO/J/jyeTQ7WPnJUbwL6YHcb+iDOSZqGBvfxp8bRa7k3lFbKdgKZzV+hs
5q9xYlNatpaH+axMwpBvDch31yZ7OemFxv39Kx70LP+HZqKYokDR8MNQr80bIynt
jSa11wxzmOu5QjQJclORVdik/KsdjL/2MHCA4tFj/NFWQz2lIDX1wMCxIvmTyz3O
NsOLGT/Cc8ZfFCCMnC/i0TtUcyytNurB9t4CK8RzwNeqVT7VeeZs+q/OHjlsedA5
orooA6ovd9B+w7hajlvn/cdvWVFuAq3GYZm/DQaaklZCSxYpBZrUYxS3tJbmOqhR
4gch4aQoiLWEKUeV/G52UvRfky0B1ke7d7w3mscBB+43/Vxlsps4/PT1yt7/psNX
gwrVyfplA15ZRcoXB8HVimzCV9YownNcHAFdtNBdt3Aq3/UADpk=
=jv6E
-END 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: Re-Launching the Java SIG

[Markku Korkeala]

On 5/11/20 10:45 PM, Fabio Valentini wrote:
> This past weekend I finally decided to jump off the cliff and attempt
> to re-launch the Java SIG. It seems there's some interest in keeping
> the Java stack maintained, it's just not focused or organized right
> now
Great, really appreciate your work.

> 
> So, if you're interested, please consider joining this group effort.
> I'll get new members set up with the FAS group / pagure project / mailing 
> list.

Count me in! I'm relatively new to fedora and rpm packaging, but got ~20
years of working with Java and my packages depends on the Java
ecosystem. FAS account: korkeala.

Markku.



> Let's make this happen.
> Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Benjamin Lowry]

On Mon, 2020-05-11 at 19:42 +0200, Miro Hrončok wrote:
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know
> for sure
> that the package should be retired, please do so now with a proper
> reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
> Note: If you received this mail directly you (co)maintain one of the
> affected
> packages or a package that depends on one. Please adopt the affected
> package or
> retire your depending package to avoid broken dependencies, otherwise
> your
> package will be retired when the affected package gets retired.
> 
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/
I've adopted flatbuffers. -ben


signature.asc
Description: This is a digitally signed message part
___
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: Re-Launching the Java SIG

[Zbigniew Jędrzejewski-Szmek]

On Tue, May 12, 2020 at 10:53:32AM -0400, Omair Majid wrote:
> Hi,
> 
> A bit of a tangential question:
> 
> Zbigniew Jędrzejewski-Szmek  writes:
> 
> > So maybe just nuke the outdated parts (member lists, "state of affairs"
> > content), and keep the rest?
> 
> My wiki-foo sucks. Is there some way to automatically generate a list of
> members on the wiki from a FAS group?

Maybe just link to some appropriate page (src.fp.o?). I don't think we
need to duplicate this information on the wiki.

Zbyszek
___
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: New set of questions for FESCo candidates?

[Zbigniew Jędrzejewski-Szmek]

On Mon, May 11, 2020 at 04:55:03PM -0400, Ben Cotton wrote:
> On Mon, May 11, 2020 at 4:39 PM Kevin Fenzi  wrote:
> 
> > If we just make it an essay with suggestions of what to include, I think
> > it might be more engaging than just a sentence or two on specific
> > questions.
> >
> > Thinking about it from an editorial perspective, the questionnaire format
> results in what will likely be more readable posts than a longer essay. The
> current format does sometimes result in a sentence or two, but a lot of the
> answers are a paragraph or two. So I'm not sure the end result would be a
> much different amount of content; some people are going to give shorter
> replies no matter the form. The other good thing about the current format
> is that it makes the answers more directly comparable.
> 
> That said, I do like the idea of a more free-form response as a way to see
> how candidates think. I suppose I can toss both at FESCo and let them make
> the choice. :-)

I'd vote for Nirik's proposal over a fixed set of questions...

Zbyszek
___
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: Summary/Minutes from today's FESCo Meeting (2020-05-11)

[Zbigniew Jędrzejewski-Szmek]

On Mon, May 11, 2020 at 09:11:32PM -0500, Chris Adams wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> > Yep. There's also /run/systemd/resolve/resolv.conf, where systemd-resolved
> > always exposes a list (with the limitations described above).
> 
> I wasn't aware of that file... to me, that's a rather obscure location
> (and I didn't find it mentioned anywhere in the change proposal).  I
> think having it (or at least having it symlinked to by something) in the
> more "usual" location, /etc, would be better.  Something like
> /etc/resolv.conf.upstream?  I don't know, I'm really bad at naming
> things. :)
The file is created dynamically at runtime, so symlinking from /etc has
the downside that you'd get a dangling symlink if systemd-resolved is not
running. The name would be "new" anyway, and we can document the name
under /run just as well as any name under /etc. So I don't think adding
a symlink in /etc/ is useful.

I added the following to the Change page:
https://fedoraproject.org/w/index.php?title=Changes%2Fsystemd-resolved=revision=576142=576137

> And while I get that the multi-VPN thing is an important use case, I'd
> also wager it's a fairly small use case, so not super important to the
> people that want to query "real" DNS servers (which I grant is also a
> small use case, but I'm just saying it's definitely non-zero and worth
> considering).
Right. Sadly dig doesn't seem to have an option to specify resolv.conf
path, and host also doesn't. I guess it would be a useful addition esp.
in case of dig.

> Even better would be a standard location (and maybe even defaulting it
> to be symlinked to /etc/resolv.conf if systemd-resolved is not in use),
> plus trying to get upstreams for common utilities like "dig" to learn
> about the alternate (at least with an easy-to-use option).
If systemd-resolved is not in use, then most likely you want something
else to manage that file, e.g. NetworkManager. In other words, if
systemd-resolved is not "on", then we want to fall back to what we do
currently, and we don't want systemd-resolved to touch that file at
all.

Zbyszek
___
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: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

[virgo]

> > On 12/05/2020 15:06, virgo wrote:
> > 
> > ...
> > 
> >  Let’s say I want to compile `pandoc` with modifications of my own and
> > 
> > many non-
> > 
> >  default compiler options. At the same time, on the same machine, I still
> >  want
> >  to do other stuff. `cgexec` et al. helped a lot to cap the memory and CPU
> >  usage of tasks like that, without needing container and virtual machines
> >  setups. Nowadays, I am into `systemd-nspawn` because it requires minimal
> >  configuration from my end. It is still a hammer deployed to kill an ant.
> >  In pages like>
> >  
> >  `systemd.resource-control(5)`, one can read:
> >   See the New Control Group Interfaces[1] for an introduction on how
> >   to
> >  
> >  **make use of resource control APIs from programs.**
> >  
> >  Great! But I do not know how to make programs consuming those APIs. The
> >  tools
> >  talked about in this thread helped a lot and I am searching for
> >  replacement
> >  that would fit with my low-proficiency in Devops.
> 
> Well the easy way is not to use any programmatic APIs but just
> 
> use systemd-run instead, for example:
>systemd-run --user --scope -p MemoryHigh=1M make
> 
> Will run make with the MemoryHigh property (documented on the
> man page you mentioned) set to a specified value.
Okay, I think that clear things up: the impediment I had was the `units` 
vocabulary found everywhere and my reluctance to create service files. What I 
take from your message is that fields that can be found inside a unit can also 
be passed on the CLI to systemd-run. I will try that.

Once again, thank you, and Lennart, and Petr, I never doubt people around 
these corners would have **the** solutions!
___
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: Re-Launching the Java SIG

[Omair Majid]

Hi,

A bit of a tangential question:

Zbigniew Jędrzejewski-Szmek  writes:

> So maybe just nuke the outdated parts (member lists, "state of affairs"
> content), and keep the rest?

My wiki-foo sucks. Is there some way to automatically generate a list of
members on the wiki from a FAS group?

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
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: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

[Tom Hughes via devel]

On 12/05/2020 15:06, virgo wrote:


Let’s say I want to compile `pandoc` with modifications of my own and many non-
default compiler options. At the same time, on the same machine, I still want
to do other stuff. `cgexec` et al. helped a lot to cap the memory and CPU usage
of tasks like that, without needing container and virtual machines setups.
Nowadays, I am into `systemd-nspawn` because it requires minimal configuration
from my end. It is still a hammer deployed to kill an ant. In pages like
`systemd.resource-control(5)`, one can read:

 See the New Control Group Interfaces[1] for an introduction on how to
**make use of resource control APIs from programs.**

Great! But I do not know how to make programs consuming those APIs. The tools
talked about in this thread helped a lot and I am searching for replacement
that would fit with my low-proficiency in Devops.


Well the easy way is not to use any programmatic APIs but just
use systemd-run instead, for example:

  systemd-run --user --scope -p MemoryHigh=1M make

Will run make with the MemoryHigh property (documented on the
man page you mentioned) set to a specified value.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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: Is dist-git a good place for work?

[Stephen John Smoogen]

On Tue, 12 May 2020 at 09:47, Tomas Tomecek  wrote:
>
> I haven't responded here for a few days - that doesn't mean I stopped
> caring, quite the opposite, I've read every single response but the
> thread grew so big that I wasn't able to keep up replying.
>
> Given all your valuable feedback, we are aiming to come with a plan,
> how to provide repositories with unpacked sources ( = source-git)
> within Fedora. The next steps for our team are to write the plan down
> and then submit it as a Fedora 33 change. While we'll be working on
> the plan, we'd review this thread in-depth and reach out to specific
> comments ad-hoc.
>

I would like to put some constraints on trying to make this a Fedora
33 change. You are going to need to retool parts of koji and other
build tools to work with these repositories. You are going to need
additional disk space which needs to be spec'd out to exist and how it
is going to do. You are possibly going to need other changes to PDC
(dead software), bodhi, builders and such.

The majority of Fedora infrastructure will be moving from one
datacenter to another in June and I do not expect us to be back to
'normal' until mid to late August to add new items. This means the
work to do this has to either land in the next 30 days or in September
before the checkmark that all changes are done. Infrastructure is
already going to be implementing items for the ELN and upgrading
various other dead software to newer versions to try and get past the
EL6 deadline.

With this in mind, I think this would make a better Fedora 34 change
versus something you can get done in 2-3 months.




> Thank you for taking your time,
> Tomas
>
> On Mon, May 4, 2020 at 5:05 PM Tomas Tomecek  wrote:
> >
> > Let’s talk about dist-git, as a place where we work. For us,
> > packagers, it’s a well-known place. Yet for newcomers, it may take a
> > while to learn all the details. Even though we operate with projects
> > in a dist-git repository, the layout doesn’t resemble the respective
> > upstream project.
> >
> > There is a multitude of tasks we tend to perform in a dist-git repo:
> > * Bumping a release field for sake of a rebuild.
> > * Updating to the latest upstream release.
> > * Resolving CVEs.
> > * Fixing bugs by…
> >   * Changing a spec file.
> >   * Pulling a commit from upstream.
> >   * Or even backporting a commit.
> > * And more...
> >
> > For some tasks, the workflow is just fine and pretty straightforward.
> > But for the other, it’s very gruesome - the moment you need to touch
> > patch files, the horror comes in. The fact that we operate with patch
> > files, in a git repository, is just mind-boggling to me.
> >
> > Luckily, we have tooling which supports the repository layout -
> > `fedpkg prep`, `srpm` or `mockbuild` are such handy commands - you can
> > easily inspect the source tree or make sure your local change builds.
> >
> > Where am I getting with this?
> >
> > Over the years there have been multiple tools created to improve the
> > development experience:
> > rdopkg [r], rpkg-util [ru], tito [t] and probably much much more (e.g.
> > the way Fedora kernel developers work on kernel [k]).
> >
> > In the packit project, we work in source-git repositories. These are
> > pretty much upstream repositories combined with Fedora downstream
> > packaging files. An example: I recently added a project called nyancat
> > [n] to Fedora. I have worked [w] on packaging the project in the
> > GitHub repo and then just pushed the changes to dist-git using packit
> > tooling. These source-git repositories can live anywhere: we have
> > support for GitHub right now and are working on supporting pagure.
> >
> > Would there be an interest within the community, as opt-in, to have
> > such source-git repositories created for respective dist-git
> > repositories? The idea is that you would work in the source-git repo
> > and then let packit handle synchronization with a respective dist-git
> > repo. Our aim is to provide the contribution experience you have in
> > GitHub when working on your packages. Dist-git would still be the
> > authoritative source and a place where official builds are done - the
> > source-git repo would work as a way to collaborate. We also don’t have
> > plans right now to integrate packit into fedpkg.
> >
> > The main reason I am sending this is to gather feedback from all of
> > you whether there is an interest in such a workflow. We don’t have
> > concrete plans for Fedora right now but based on your feedback we
> > could.
> >
> >
> > [r] https://github.com/softwarefactory-project/rdopkg
> > [ru] https://pagure.io/rpkg-util
> > [t] https://github.com/rpm-software-management/tito
> > [k] 
> > https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/JW4P7FINXXXTOEAHMDTZBVGYZUZMVTWX/#3MLMOTUG5B4F32XIM2YRL3FKVUJNYVRF
> > [n] https://github.com/TomasTomecek/nyancat
> > [w] https://github.com/TomasTomecek/nyancat/pull/2
> >
> >
> > Cheers,
> > Tomas
> 

Re: CPE Weekly: 2020-05-11

[Clement Verna]

On Mon, 11 May 2020 at 12:55, Clement Verna 
wrote:

>
>
> On Mon, 11 May 2020 at 11:03, Fabio Valentini 
> wrote:
>
>> On Mon, May 11, 2020 at 10:42 AM Aoife Moloney 
>> wrote:
>> > ## GitForge Updates
>> > * We are tracking our progress here (nothing new added yet, fyi)
>> > https://fedoraproject.org/wiki/Git_forge_update
>> > * And the council are tracking the community issues in this ticket
>> > https://pagure.io/Fedora-Council/tickets/issue/292
>> > * I have an  Office hours IRC meeting slot on #fedora-meeting-1 @
>> > 1400-1500 UTC every Thursday. Feel free to stop by and say hi! We can
>> > talk about Gitforge, or not :)
>>
>> I'm wondering, is actually anything happening here?
>>
>
> Yes, I am still gathering the "pain points". I am going to open a ticket
> in the GitLab tracker (http://gitlab.com/gitlab-org/gitlab) this week, so
> that all the discussions about what we are asking will be public.
>

Hey so we now have a public issue[0] with GitLab that we are going to use
to drive the conversation. So if you are interested I highly encourage you
to follow that issue. Also this is currently focusing on the very basic
features of dist-git in purpose once we have a better idea on how these
features looks like in GitLab, we will be able to take a look at the rest
of our needs.

Hope that helps

PS: If there is anything that you feel should be mentioned in the ticket,
please feel free to tell me about it so that I can look at editing the
ticket.

[0] - https://gitlab.com/gitlab-org/gitlab/-/issues/217350


>
>
>> The "progress" being tracked in the wiki has been "nothing yet" since
>> the wiki page was announced a few weekly reports ago, and the linked
>> council ticket has not been updated in 2-3 weeks either :/
>>
>
>> Fabio
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

[virgo]

> On Di, 12.05.20 14:21, Fedora Development ML
> (devel(a)lists.fedoraproject.org) wrote:
> 
> ...
> 
> cgroupsv2 is built around a single-writer scheme. That means any
> section of the tree shall only have a singler writer, i.e. one
> subsystem 'owning' it. On systemd systems the root of the tree is
> owned by systemd, it's the single writer of it. Other software may
> read from the tree but not make changes to it.
> 
> You can ask systemd for a delegated subtree of the main cgroup tree
> however. You can do this via Delegate=yes in a service file, or by
> doing "systemd-run --scope -p Delegate=yes -t /bin/bash" on the
> command line. If you do that you get your own subtree in which you can
> do whatever you want, and systemd will not step on your toes.
> 
> Making changes to the top-level cgroup tree, i.e. stepping into
> systemd's explicitly owned territory means voiding your warranty
> though.
> 
> This design choice is made by the cgroupsv2 subsystem in the kernel
> btw, it's not something systemd came up with.
> 
> It's documented here in all detail:
>  https://systemd.io/CGROUP_DELEGATION
> 
> hence, if libcgroups wants to do cgroup stuff it really needs to ask
> systemd for delegation first (or be invoked inside a service where
> something else asked for it). If it doesn't then it's simply broken.
Thank you for the explanation. The page you linked is more than clear upfront:

Intended audience: hackers working on userspace subsystems that require 
direct cgroup access, such as container managers and similar.

I will keep that in mind.

> 
> In general, I am not sure why one would even want the cgroup tools on
> a systemd system though. 
I just wrote something along those lines to Tom, the onus is on me to catch-up 
and leverage what is available.

> We should provide most of it natively anyway,
> though possibly in a different manner.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
___
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: Re-Launching the Java SIG

[Alex Scheel]

- Original Message -
> From: "Fabio Valentini" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, May 12, 2020 9:44:33 AM
> Subject: Re: Re-Launching the Java SIG
> 
> On Tue, May 12, 2020 at 3:34 PM Alex Scheel  wrote:
> >
> > Obviously count us in, Fabio :-)
> 
> *Us* means the three guys from the Dogtag PKI team? :)

Yeah, but mostly expect Dinesh and I :)

> 
> > Do we need a two-step bootstrap process? A first (offline) step where we
> > run
> > gradle-wrapper and fetch all the resources, put all online dependencies
> > into a
> > SRPM/lookaside cache and "finish" the bootstrap build in Koji (giving us a
> > bootstrapped version which works) and then replacing _all_ assets with
> > versions
> > built using the bootstrapped gradle and finally rebuilding gradle?
> >
> > It'd be hell to set up the first time (two .specs?) and hell to make sure
> > we
> > get every package at the right version. But theoretically possible? :-)
> >
> >
> > But it might allow us to skip incremental bootstrap from a really old
> > gradle
> > version and might even get us a process which works for future bootstraps.
> 
> That's an innocent thought :) I'm afraid it won't work though.
> Do you think gradle is downloading source code for its dependencies?
> Nope, it only downloads prebuilt JARs.

Right -- I wasn't suggesting that it'd download source code. Merely that a
binary-JAR-bootstrapped Gradle could be used to (re)-build all of the
libraries it needed (from source this time!) and then re-build itself
(using those source-built libraries and building a new gradle from
source).

The internet-downloaded JARs could be put into lookaside and the SRPM
could pull them, put them in the right location, and finish the initial
Gradle build. Koji would finish the build and the resulting gradle would
be available for us to use.

IIRC the restriction on source code builds of packages can be waived for
bootstrap-only builds. So for initial build of gradle, we're fine using
the binary wrapper as long as we fully replace it with source-only builds.

Someone with a more recent understanding of packaging policy can weigh
in here though.

> 
> So the build script loads a prebuilt gradle-wraper.jar (that's shipped
> with the gradle sources) that then in turn downloads more prebuilt
> JARs from the gradle repository to satisfy gradle's build dependencies
> which are then used to actually build full gradle ...

Right :) So we'd take all of those new downloads and put them into
lookaside and ship a SPRM that finishes the build based off of those
internet-downloaded JARs. This satisifies Koji's no-internet policy
while giving us a (hopefully) useful Gradle build system as output.

> ___
> 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: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

[virgo]

> On Tue, May 12, 2020 at 12:47:51PM +, virgo wrote:
> ...
> 
>  > I recommend you to ask the question about v2 support on Fedora
> 
> Bugzilla for=
> 
>  >  the
>  > 
>  > libcgroup package
>  >   > =3Dlibcgroup=3DFedora_format=3Dadvanced>.
>  
>  Prior to the top post, I went through the Bugzilla tickets, with these
>  parameters:
>  
>  * component=libcgroup
>  * order=changeddate DESC
>  * product=Fedora
>  * query_format=advanced
>  
>  and the hits dating back to 2015[fn:1] were just a dozen, none making
>  mention
>  of v2. So, I am not sure whether opening feature requests would help.
> 
> Fedora uses systemd that enforces cgroup v2. If libcgroup package is not
> compatible with cgroup v2, then libcgroup package is not compatible with
> Fedora and this is a bug and should be reported to the Fedora's Bugzilla.
> 
> ...
> 
>  By the way, what would you and (and others) recommend as a
> 
> replacement for
> 
>  libcgroup-tools?[fn:2]
> 
> No idea. I don't use cgroups for anything on purpose. As far as I know,
> cgroups membership in Fedora is defined by systemd's logind. Whether it
> suits
> your needs, I have no idea. I also think it's possible to manage the
> membership manually by editing files in cgroup2 pseudo file system.
Duly noted, thank you for your time.
> 
> -- Petr
___
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: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

[virgo]

> On 12/05/2020 14:13, Petr Pisar wrote:
> ...
> 
>  On Tue, May 12, 2020 at 12:47:51PM +, virgo wrote:
> >> I recommend you to ask the question about v2 support on Fedora Bugzilla
> >> for=
> >> 
> >>   the
> >> 
> >> libcgroup package
> 
>  
> >> =3Dlibcgroup=3DFedora_format=3Dadvanced>.
> > 
> > Prior to the top post, I went through the Bugzilla tickets, with these
> > parameters:
> > 
> > * component=libcgroup
> > * order=changeddate DESC
> > * product=Fedora
> > * query_format=advanced
> > 
> > and the hits dating back to 2015[fn:1] were just a dozen, none making
> > mention
> > of v2. So, I am not sure whether opening feature requests would help.
>  
>  Fedora uses systemd that enforces cgroup v2. If libcgroup package is not
>  compatible with cgroup v2, then libcgroup package is not compatible with
>  Fedora and this is a bug and should be reported to the Fedora's Bugzilla.
> 
> That's not really true. Fedora now defaults to v2 but you can still
> choose to boot to v1 instead and systemd still supports both.
Yes, that is well documented. I am not desperate to the point of fiddling with 
kernel boot options, though.
> 
> > By the way, what would you and (and others) recommend as a
> 
> replacement for
> 
> > libcgroup-tools?[fn:2]
>  
>  No idea. I don't use cgroups for anything on purpose. As far as I know,
>  cgroups membership in Fedora is defined by systemd's logind. Whether it
>  suits
>  your needs, I have no idea. I also think it's possible to manage the
>  membership manually by editing files in cgroup2 pseudo file system.
> 
> Yes as I understand it you're not supposed to fiddle with cgroups
> manually, you're supposed to use systemd-run or something and let
> systemd do the necessary.
> 
> It would probably help if the original user described what his goal
> was rather than the low level details of how he achieved that with
> cgroups v1.
Let’s say I want to compile `pandoc` with modifications of my own and many non-
default compiler options. At the same time, on the same machine, I still want 
to do other stuff. `cgexec` et al. helped a lot to cap the memory and CPU usage 
of tasks like that, without needing container and virtual machines setups. 
Nowadays, I am into `systemd-nspawn` because it requires minimal configuration 
from my end. It is still a hammer deployed to kill an ant. In pages like 
`systemd.resource-control(5)`, one can read:

See the New Control Group Interfaces[1] for an introduction on how to 
**make use of resource control APIs from programs.**

Great! But I do not know how to make programs consuming those APIs. The tools 
talked about in this thread helped a lot and I am searching for replacement 
that would fit with my low-proficiency in Devops.

That said, I read somewhere about user units, I am under the impression those 
would help. Somewhere on my computer, there already many tools to accomplish 
all of I need and beyond, the issue is that I have not yet met documentation 
dumbed down enough to make me see the light.
> 
> Tom
> 
> --
> Tom Hughes (tom(a)compton.nu)
> http://compton.nu/
___
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: Orphaned packages looking for new maintainers

[José Abílio Matos]

On Monday, 11 May 2020 19.31.39 WEST Miro Hrončok wrote:
> Any code contribution to make the output work better is appreciated, but
> unfortunately, I am not available to work on this, sorry 

Where is the code?

I search for it without success. :-)
-- 
José Abílio

___
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: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

[Lennart Poettering]

On Di, 12.05.20 14:21, Fedora Development ML (devel@lists.fedoraproject.org) 
wrote:

> > > By the way, what would you and (and others) recommend as a replacement for
> > > libcgroup-tools?[fn:2]
> >
> > No idea. I don't use cgroups for anything on purpose. As far as I know,
> > cgroups membership in Fedora is defined by systemd's logind. Whether it 
> > suits
> > your needs, I have no idea. I also think it's possible to manage the
> > membership manually by editing files in cgroup2 pseudo file system.
>
> Yes as I understand it you're not supposed to fiddle with cgroups
> manually, you're supposed to use systemd-run or something and let
> systemd do the necessary.

cgroupsv2 is built around a single-writer scheme. That means any
section of the tree shall only have a singler writer, i.e. one
subsystem 'owning' it. On systemd systems the root of the tree is
owned by systemd, it's the single writer of it. Other software may
read from the tree but not make changes to it.

You can ask systemd for a delegated subtree of the main cgroup tree
however. You can do this via Delegate=yes in a service file, or by
doing "systemd-run --scope -p Delegate=yes -t /bin/bash" on the
command line. If you do that you get your own subtree in which you can
do whatever you want, and systemd will not step on your toes.

Making changes to the top-level cgroup tree, i.e. stepping into
systemd's explicitly owned territory means voiding your warranty
though.

This design choice is made by the cgroupsv2 subsystem in the kernel
btw, it's not something systemd came up with.

It's documented here in all detail:

 https://systemd.io/CGROUP_DELEGATION

hence, if libcgroups wants to do cgroup stuff it really needs to ask
systemd for delegation first (or be invoked inside a service where
something else asked for it). If it doesn't then it's simply broken.

In general, I am not sure why one would even want the cgroup tools on
a systemd system though. We should provide most of it natively anyway,
though possibly in a different manner.

Lennart

--
Lennart Poettering, Berlin
___
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: Re-Launching the Java SIG

[Fabio Valentini]

On Tue, May 12, 2020 at 3:34 PM Alex Scheel  wrote:
>
> Obviously count us in, Fabio :-)

*Us* means the three guys from the Dogtag PKI team? :)

> Do we need a two-step bootstrap process? A first (offline) step where we run
> gradle-wrapper and fetch all the resources, put all online dependencies into a
> SRPM/lookaside cache and "finish" the bootstrap build in Koji (giving us a
> bootstrapped version which works) and then replacing _all_ assets with 
> versions
> built using the bootstrapped gradle and finally rebuilding gradle?
>
> It'd be hell to set up the first time (two .specs?) and hell to make sure we
> get every package at the right version. But theoretically possible? :-)
>
>
> But it might allow us to skip incremental bootstrap from a really old gradle
> version and might even get us a process which works for future bootstraps.

That's an innocent thought :) I'm afraid it won't work though.
Do you think gradle is downloading source code for its dependencies?
Nope, it only downloads prebuilt JARs.

So the build script loads a prebuilt gradle-wraper.jar (that's shipped
with the gradle sources) that then in turn downloads more prebuilt
JARs from the gradle repository to satisfy gradle's build dependencies
which are then used to actually build full gradle ...
___
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: Is dist-git a good place for work?

[Tomas Tomecek]

I haven't responded here for a few days - that doesn't mean I stopped
caring, quite the opposite, I've read every single response but the
thread grew so big that I wasn't able to keep up replying.

Given all your valuable feedback, we are aiming to come with a plan,
how to provide repositories with unpacked sources ( = source-git)
within Fedora. The next steps for our team are to write the plan down
and then submit it as a Fedora 33 change. While we'll be working on
the plan, we'd review this thread in-depth and reach out to specific
comments ad-hoc.

Thank you for taking your time,
Tomas

On Mon, May 4, 2020 at 5:05 PM Tomas Tomecek  wrote:
>
> Let’s talk about dist-git, as a place where we work. For us,
> packagers, it’s a well-known place. Yet for newcomers, it may take a
> while to learn all the details. Even though we operate with projects
> in a dist-git repository, the layout doesn’t resemble the respective
> upstream project.
>
> There is a multitude of tasks we tend to perform in a dist-git repo:
> * Bumping a release field for sake of a rebuild.
> * Updating to the latest upstream release.
> * Resolving CVEs.
> * Fixing bugs by…
>   * Changing a spec file.
>   * Pulling a commit from upstream.
>   * Or even backporting a commit.
> * And more...
>
> For some tasks, the workflow is just fine and pretty straightforward.
> But for the other, it’s very gruesome - the moment you need to touch
> patch files, the horror comes in. The fact that we operate with patch
> files, in a git repository, is just mind-boggling to me.
>
> Luckily, we have tooling which supports the repository layout -
> `fedpkg prep`, `srpm` or `mockbuild` are such handy commands - you can
> easily inspect the source tree or make sure your local change builds.
>
> Where am I getting with this?
>
> Over the years there have been multiple tools created to improve the
> development experience:
> rdopkg [r], rpkg-util [ru], tito [t] and probably much much more (e.g.
> the way Fedora kernel developers work on kernel [k]).
>
> In the packit project, we work in source-git repositories. These are
> pretty much upstream repositories combined with Fedora downstream
> packaging files. An example: I recently added a project called nyancat
> [n] to Fedora. I have worked [w] on packaging the project in the
> GitHub repo and then just pushed the changes to dist-git using packit
> tooling. These source-git repositories can live anywhere: we have
> support for GitHub right now and are working on supporting pagure.
>
> Would there be an interest within the community, as opt-in, to have
> such source-git repositories created for respective dist-git
> repositories? The idea is that you would work in the source-git repo
> and then let packit handle synchronization with a respective dist-git
> repo. Our aim is to provide the contribution experience you have in
> GitHub when working on your packages. Dist-git would still be the
> authoritative source and a place where official builds are done - the
> source-git repo would work as a way to collaborate. We also don’t have
> plans right now to integrate packit into fedpkg.
>
> The main reason I am sending this is to gather feedback from all of
> you whether there is an interest in such a workflow. We don’t have
> concrete plans for Fedora right now but based on your feedback we
> could.
>
>
> [r] https://github.com/softwarefactory-project/rdopkg
> [ru] https://pagure.io/rpkg-util
> [t] https://github.com/rpm-software-management/tito
> [k] 
> https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/JW4P7FINXXXTOEAHMDTZBVGYZUZMVTWX/#3MLMOTUG5B4F32XIM2YRL3FKVUJNYVRF
> [n] https://github.com/TomasTomecek/nyancat
> [w] https://github.com/TomasTomecek/nyancat/pull/2
>
>
> Cheers,
> Tomas
___
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: Re-Launching the Java SIG

[Alex Scheel]

Obviously count us in, Fabio :-)

- Original Message -
> From: "Fabio Valentini" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, May 12, 2020 6:39:04 AM
> Subject: Re: Re-Launching the Java SIG
> 
> On Tue, May 12, 2020 at 12:34 PM Ty Young  wrote:
> > Right, I figured it was some Fedora policy and not up to you. I suppose
> > I should have been more clear there. Sorry for any confusion, it was
> > aimed at the Fedora project as a whole as this is a Fedora issue.
> 
> I am aware that Arch is just packaging up the binary release artifacts
> published by the gradle project.
> But that's just never going to fly for fedora.
> 
> Arch is also the only distro I looked at that does this, everybody
> else (at least debian, ubuntu, OpenSUSE) is stuck at an ancient
> version, if gradle is available at all.
> 
> > FWIW, I can compile 6.4 just fine on Arch Linux using the Github source
> > code via:
> >
> >
> > ./gradlew allZip
> 
> Now try doing that offline and without using the pre-built
> gradle/wrapper/gradle-wrapper.jar :)
> You'll be surprised how much junk the build process still needs to download.

Do we need a two-step bootstrap process? A first (offline) step where we run
gradle-wrapper and fetch all the resources, put all online dependencies into a
SRPM/lookaside cache and "finish" the bootstrap build in Koji (giving us a
bootstrapped version which works) and then replacing _all_ assets with versions
built using the bootstrapped gradle and finally rebuilding gradle?

It'd be hell to set up the first time (two .specs?) and hell to make sure we
get every package at the right version. But theoretically possible? :-)


But it might allow us to skip incremental bootstrap from a really old gradle
version and might even get us a process which works for future bootstraps.



- Alex

> 
> Fabio
> 
> > >
> > > Felix
> > > ___
> > > 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
> ___
> 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: LibRaw 0.20 Beta; soname bump

[Gwyn Ciesla via devel]

‐‐‐ Original Message ‐‐‐
On Tuesday, May 12, 2020 5:14 AM, Miro Hrončok  wrote:

> On 12. 05. 20 0:12, Miro Hrončok wrote:
> 

> > On 11. 05. 20 22:33, Gwyn Ciesla via devel wrote:
> > 

> > > I'm building LibRaw 0.20 Beta 1 for rawhide, along with all direct 
> > > consumers,
> > > in a multi-stage chain build, today, including the following:
> > > deepin-image-viewer
> > > elementary-photos
> > > freeimage
> > > gthumb
> > > indi-gphoto
> > > krita
> > > luminance-hdr
> > > photoqt
> > > shotwell
> > > efl
> > > entangle
> > > gegl04
> > > ImageMagick
> > > kf5-libkdcraw
> > > libpasraw
> > > nomacs
> > > OpenImageIO
> > > rapid-photo-downloader
> > > siril
> > > blender
> > > luxcorerender
> > 

> > I'm getting a lot of broken deps like this:
> > Problem: package emacs-1:26.3-3.fc33.x86_64 requires
> > libMagickCore-6.Q16.so.6()(64bit), but none of the providers can be 
> > installed
> > 

> > -   package emacs-1:26.3-3.fc33.x86_64 requires 
> > libMagickWand-6.Q16.so.6()(64bit),
> > but none of the providers can be installed
> > 

> > -   conflicting requests
> > -   nothing provides libraw_r.so.19()(64bit) needed by
> > ImageMagick-libs-1:6.9.10.86-2.fc32.x86_64
> > 

> > 

> > I see this build was cancelled:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=44387471
> 

> I've hit rebuild again:
> 

> https://koji.fedoraproject.org/koji/taskinfo?taskID=44410327
> 


Thank you! My apologies, this all worked in my testing, I'll use a side tag 
next time.

-G

> -
> 

> 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



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: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

[Tom Hughes via devel]

On 12/05/2020 14:13, Petr Pisar wrote:

On Tue, May 12, 2020 at 12:47:51PM +, virgo wrote:

I recommend you to ask the question about v2 support on Fedora Bugzilla for=

  the

libcgroup package
.

Prior to the top post, I went through the Bugzilla tickets, with these
parameters:

* component=libcgroup
* order=changeddate DESC
* product=Fedora
* query_format=advanced

and the hits dating back to 2015[fn:1] were just a dozen, none making mention
of v2. So, I am not sure whether opening feature requests would help.


Fedora uses systemd that enforces cgroup v2. If libcgroup package is not
compatible with cgroup v2, then libcgroup package is not compatible with
Fedora and this is a bug and should be reported to the Fedora's Bugzilla.


That's not really true. Fedora now defaults to v2 but you can still
choose to boot to v1 instead and systemd still supports both.


By the way, what would you and (and others) recommend as a replacement for
libcgroup-tools?[fn:2]


No idea. I don't use cgroups for anything on purpose. As far as I know,
cgroups membership in Fedora is defined by systemd's logind. Whether it suits
your needs, I have no idea. I also think it's possible to manage the
membership manually by editing files in cgroup2 pseudo file system.


Yes as I understand it you're not supposed to fiddle with cgroups
manually, you're supposed to use systemd-run or something and let
systemd do the necessary.

It would probably help if the original user described what his goal
was rather than the low level details of how he achieved that with
cgroups v1.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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: Retired packages with maintainers

[Pierre-Yves Chibon]

On Tue, May 12, 2020 at 02:51:03PM +0200, Miro Hrončok wrote:
> On 12. 05. 20 8:49, Pierre-Yves Chibon wrote:
> > Finally, does everyone agree about the original request: "remove all 
> > maintainers
> > of retired packages"? Or should we bring this to FESCo?
> 
> If the procedure is "remove all maintainers if all branches are retired or
> EOL" than yes, this is a good thing. However, not sure if worth spending
> energy on. What are the benefits over status quo?

Someone asked us to look into this, so I did, briefly.
I am also very happy to close the ticket as "Won't fix" and move on :)


Pierre
___
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: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

[Petr Pisar]

On Tue, May 12, 2020 at 12:47:51PM +, virgo wrote:
> > I recommend you to ask the question about v2 support on Fedora Bugzilla for=
> > 
> >  the
> > 
> > libcgroup package
> >  > =3Dlibcgroup=3DFedora_format=3Dadvanced>.
> Prior to the top post, I went through the Bugzilla tickets, with these 
> parameters:
> 
> * component=libcgroup
> * order=changeddate DESC
> * product=Fedora
> * query_format=advanced
> 
> and the hits dating back to 2015[fn:1] were just a dozen, none making mention 
> of v2. So, I am not sure whether opening feature requests would help.

Fedora uses systemd that enforces cgroup v2. If libcgroup package is not
compatible with cgroup v2, then libcgroup package is not compatible with
Fedora and this is a bug and should be reported to the Fedora's Bugzilla.

> By the way, what would you and (and others) recommend as a replacement for 
> libcgroup-tools?[fn:2]

No idea. I don't use cgroups for anything on purpose. As far as I know,
cgroups membership in Fedora is defined by systemd's logind. Whether it suits
your needs, I have no idea. I also think it's possible to manage the
membership manually by editing files in cgroup2 pseudo file system.

-- Petr


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: Retired packages with maintainers

[Miro Hrončok]

On 12. 05. 20 8:49, Pierre-Yves Chibon wrote:

Finally, does everyone agree about the original request: "remove all maintainers
of retired packages"? Or should we bring this to FESCo?


If the procedure is "remove all maintainers if all branches are retired or EOL" 
than yes, this is a good thing. However, not sure if worth spending energy on. 
What are the benefits over status quo?


--
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: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

[virgo]

> Date: Tue, 12 May 2020 13:00:13 +0200
> From: Petr Pisar 
> Subject: Re: Transitioning scripts relying on libcgroup-tools to the
>  cgroup’s unified hierarchy (v2)
> 
[…]
> cgcreate tool comes from libcgroup-tools-0:0.42.2-1.fc32 package that comes
> from libcgroup project sources, and libcgroup does not yet support cgroup v=
> 2.
> 
> A quick search of WWW shows that
> 
> :
> 30 October 2019, 04:38:42
> The libcgroup devs are currently discussing plans to implement v2 cgroup
> support
> 
>  project had a last release on 2014-01-13.
> A thread on its devel list
>  from 2019-10-14
> still discusses v2 support as in-progress.
> 
> Fedora packages a fork (or a new upstream) from  up/libcgroup>.
Right! I had relied on the output of `dnf info libcgroup` to posit about 
upstream, I should read SPEC files, too. Thank you for the clarification.
> I recommend you to ask the question about v2 support on Fedora Bugzilla for=
> 
>  the
> 
> libcgroup package
>  =3Dlibcgroup=3DFedora_format=3Dadvanced>.
Prior to the top post, I went through the Bugzilla tickets, with these 
parameters:

* component=libcgroup
* order=changeddate DESC
* product=Fedora
* query_format=advanced

and the hits dating back to 2015[fn:1] were just a dozen, none making mention 
of v2. So, I am not sure whether opening feature requests would help.  I 
cannot offer code contributions because of illiteracy in C.

By the way, what would you and (and others) recommend as a replacement for 
libcgroup-tools?[fn:2]  The WWW is not very helpful when it comes to v2, maybe 
because not so many other distributions have made the switch.
> -- Petr

Thanks for your reply.

[fn:1] Around the time Cgroups v2 were released, [[per this page]][https://
www.kernel.org/doc/Documentation/cgroup-v2.txt].

[fn:2] There are container technologies, of course, but IMHO that is another 
level of tools not really suitable for simple scripting.

___
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: Retired packages with maintainers

[Pierre-Yves Chibon]

On Tue, May 12, 2020 at 02:08:12PM +0200, Igor Raits wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Tue, 2020-05-12 at 08:49 +0200, Pierre-Yves Chibon wrote:
> > Good Morning Everyone,
> > 
> > A little while ago we have received the request on the infra issue
> > tracker to
> > remove all maintainers of retired packages [1].
> > 
> > So today I decided to look at what this would look like and wrote a
> > script that
> > queries PDC for the list of all branches on all projects [2], gather
> > from it a
> > list of all the packages that are retired on all their branches (so
> > all branches
> > are ``active=false``).
> > For each of these retired project, it queries dist-git to find out if
> > they still
> > have maintainers in addition to the ``orphan`` user.
> > 
> > The outcome of this script can be found there:
> > 
> >   
> > https://pingou.fedorapeople.org/retired_packages_with_maintainers.log
> > 
> > 
> > Some stats about this:
> > - 881 RPM packages are retired and still have maintainers (out of
> > 4322 retired
> >   RPMs).
> > - 662 of them are not orphaned
> > - 42 modules are retired and still have maintainers (out of 42
> > retired modules).
> > - all of them are not orphaned
> > - 2 containers are retired and still have maintainers (out of 3
> > retired
> >   containers).
> > - all of them are not orphaned
> > 
> > Which brings a couple of questions:
> > - Do we have a documented way to mark modules as orphaned or retired?
> 
> Not really, usually this requires releng ticket which most of people
> don't ever create.
> 
> > - Should we orphan all the RPM packages that are retired but not
> > orphaned?
> 
> Doesn't that mean that we will add them back to repos? For me retired
> means that they are not in repos anymore, so what would orphaning
> exactly mean? Or is this just about marking it as "orphaned-retired" in
> dist-git?

To pick an example: denyhosts still has Jason as POC while all its branches are
set as "active=False" in PDC.
So by orphaning the package, I mean setting the "orphan" user as POC for it.

> > Finally, does everyone agree about the original request: "remove all
> > maintainers
> > of retired packages"? Or should we bring this to FESCo?
> 
> I think this is good idea to remove all maintainers from retired
> packages because they essentially can't do anything with them anyway.
> 
> But beware of EPEL-only packages.

The script checks *all* branches in PDC and ensure that they are all
"active=False". So if a package still has active branches in EPEL it should not
show in the list here.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [fedora-java] Re-Launching the Java SIG

[Fabio Valentini]

On Tue, May 12, 2020 at 1:02 PM Aleksandar Kurtakov  wrote:
> Good luck with that! As someone that has been part of the Java SIG since day 
> 0 I wish you make Fedora even better workstation for Java developer than we 
> ever managed.

Thank you! You're welcome to (re-)join the effort, we'd be lucky to
have experienced packagers like you.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: Revise FESCo voting policy

[Aleksandra Fedorova]

Hi,

On Tue, May 12, 2020 at 10:19 AM Vít Ondruch  wrote:
>
>
> Dne 11. 05. 20 v 19:40 Aleksandra Fedorova napsal(a):
> > Hi,
> >
> > On Mon, May 11, 2020 at 5:52 PM Stephen Gallagher  
> > wrote:
> >> During today's FESCo meeting, we encountered an unusual voting
> >> situation for the first time: Four FESCo members voted in favor (+1)
> >> of a measure and five FESCo members opted to abstain (0) for various
> >> reasons. However, the FESCo voting policy currently reads: "A majority
> >> of the committee (that is, five out of nine) is required to pass a
> >> proposal in a meeting." As a result, we were actually at an impasse
> >> until two of the FESCo members opted to change their votes to +1 to
> >> resolve the confusion.
> >>
> >> It was subsequently suggested that we revise the policy to avoid this
> >> pitfall in the future. I volunteered to put together a proposal for
> >> how this could work and send it to the Fedora Development list for
> >> discussion. I propose the following changes to the FESCo voting
> >> policy:
> >>
> >> * To pass any measure, a majority — defined as the greater of half the
> >> eligible votes (rounded up) — must vote in favor of the measure. The
> >> standard set of eligible votes is one vote per FESCo member. No
> >> measure may pass without at least one vote in favor.
> >>
> >> * Abstaining from a vote (aka "voting 0") is considered to have
> >> removed that FESCo member's vote from the set of eligible votes. This
> >> must be done explicitly and is never to be assumed from lack of
> >> communication.
> >>
> >> A practical effect of the new abstention rule is that if two FESCo
> >> members abstain, the measure would then require only a +4 vote to
> >> pass. (A single abstention would still require a +5 vote).
> > I don't like this idea.
> >
> > I think if FESCo members don't have enough data or understanding to
> > vote on the topic, this means that FESCo needs to put more effort in
> > it.
> >
> > Find some subject matter experts in the community, make additional
> > steps to learn the subject.
> > Or, when topic has no technical foundation but more of the personal
> > preference, bring it for a full community vote.
> >
> > In the end FESCo supposed to channel the community voice.
> > If FESCo can not make a decision, it means delegation of the decision
> > to FESCo by community failed. So let's go back to community?
> >
> > So how about the alternative:
> > if FESCo can't come up with the decision, it announces the stalled
> > decision to fedora-announce and requests help. Better summary, more
> > arguments, etc..
> >
> > This would encourage people who are against the change to participate.
>
>
> I agree with Aleksandra up until here.
>
>
> > And if there are no such people to provide convincing arguments
> > against the change in a reasonable time frame, than FESCo decides in
> > favor of the submitter.
>
>
> I disagree here. If such proposal does not have enough support, then it
> should not be accepted and should be revisited/abandoned/rejected. I
> cannot imagine any even hypothetical situation where the opposite was
> beneficial.

The proposal has at least support of its owners, who stepped in and
spent some time describing the idea.

If there are no convincing reasons against this proposal, then it is
their opinion, which matters. They have an idea, and they are willing
to do the job and take the responsibility.
I don't see the reason to block it then.

Given that "change is out of scope of Fedora" and "support is very
limited and the risk is too high" still can be a convincing reason to
reject the change in some cases. But then it must be stated
explicitly.

> 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

-- 
Aleksandra Fedorova
bookwar
___
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 1820714] perl-WWW-Search-2.519 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-WWW-Search-2.519-1.fc3
   ||3
 Resolution|--- |RAWHIDE
   Assignee|xav...@bachelot.org |jples...@redhat.com
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-05-12 12:17:00




-- 
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: Is dist-git a good place for work?

[Richard Shaw]

On Thu, May 7, 2020 at 3:54 PM clime  wrote:

> 
>
> > In the rare occasion that I need to make downstream-only changes with
> > patches, I usually just explode the upstream tarball, run "git init",
> > then "git add .", "git commit -m import", apply my changes, and then
> > do "git diff --patch > ../00-my-changes.patch" (if it's just one
> > commit), or "git format-patch -o ../" if there are multiple commits,
> > and then delete the exploded sources again.
>
> In any case, I think this functionality could be included in
> rpkg/fedpkg...?
>
> If there are no objections, I will open a ticket for this.
>

It took me a bit to figure it out but I use quilt instead. It doesn't
perfectly integrate with rpmbuild/dist-git but it works well enough.

There are two big nits I have...
1. If one patch fails to apply it stops there, so I have to go in and
fix/refresh it, then back out, rm -rf the source directory, and re-quilt
setup .
2. If you don't have any patches yet they are only generated in
/patches and not created in the dist-git directory.

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: Retired packages with maintainers

[Fabio Valentini]

On Tue, May 12, 2020 at 2:03 PM Pierre-Yves Chibon  wrote:
>
> Good Morning Everyone,
>
> A little while ago we have received the request on the infra issue tracker to
> remove all maintainers of retired packages [1].
>
> So today I decided to look at what this would look like and wrote a script 
> that
> queries PDC for the list of all branches on all projects [2], gather from it a
> list of all the packages that are retired on all their branches (so all 
> branches
> are ``active=false``).
> For each of these retired project, it queries dist-git to find out if they 
> still
> have maintainers in addition to the ``orphan`` user.

Hey pingou,

I've been wondering about the same thing a while back.

> - Do we have a documented way to mark modules as orphaned or retired?

I think we do. I seem to remember seeing "dead.module" files in some
module repositories I looked at ...

> - Should we orphan all the RPM packages that are retired but not orphaned?

I think removing maintainers from packages where all branches are
inactive is a good idea. Those only add noise when querying anything,
in my experience.
I'd support an automatic / scripted procedure to remove all
maintainers from all-branches-retired packages, if you decide to bring
this to FESCo :)

So long as we make sure that if any branch is still not retired we
don't modify the maintainer list, I'm all for it.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Retired packages with maintainers

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, 2020-05-12 at 08:49 +0200, Pierre-Yves Chibon wrote:
> Good Morning Everyone,
> 
> A little while ago we have received the request on the infra issue
> tracker to
> remove all maintainers of retired packages [1].
> 
> So today I decided to look at what this would look like and wrote a
> script that
> queries PDC for the list of all branches on all projects [2], gather
> from it a
> list of all the packages that are retired on all their branches (so
> all branches
> are ``active=false``).
> For each of these retired project, it queries dist-git to find out if
> they still
> have maintainers in addition to the ``orphan`` user.
> 
> The outcome of this script can be found there:
> 
>   
> https://pingou.fedorapeople.org/retired_packages_with_maintainers.log
> 
> 
> Some stats about this:
> - 881 RPM packages are retired and still have maintainers (out of
> 4322 retired
>   RPMs).
> - 662 of them are not orphaned
> - 42 modules are retired and still have maintainers (out of 42
> retired modules).
> - all of them are not orphaned
> - 2 containers are retired and still have maintainers (out of 3
> retired
>   containers).
> - all of them are not orphaned
> 
> Which brings a couple of questions:
> - Do we have a documented way to mark modules as orphaned or retired?

Not really, usually this requires releng ticket which most of people
don't ever create.

> - Should we orphan all the RPM packages that are retired but not
> orphaned?

Doesn't that mean that we will add them back to repos? For me retired
means that they are not in repos anymore, so what would orphaning
exactly mean? Or is this just about marking it as "orphaned-retired" in
dist-git?

> Finally, does everyone agree about the original request: "remove all
> maintainers
> of retired packages"? Or should we bring this to FESCo?

I think this is good idea to remove all maintainers from retired
packages because they essentially can't do anything with them anyway.

But beware of EPEL-only packages.

> 
> Thanks for your inputs,
> 
> Pierre
> 
> 
> [1] https://pagure.io/fedora-infrastructure/issue/8600
> [2] https://pdc.fedoraproject.org/extras/active_branches.json (8+Mb
> file)
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to 
> devel-announce-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-annou...@lists.fedoraproject.org
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl66kawACgkQEV1auJxc
Hh6Z4A/+P6Ihd/JDAVT940mdtO5ajMBCDCLnh1pRoluxIqAejSTX39zzTekbzGBJ
KDmKhwiBmrEuPFHxbTuTAFZmxYnuNOey0AT2EHuO3EZ0VFQafaTiMvM5fEB5a1G7
PHFTNeKloXzi21KtB6SOuHuKxEo0NySjb7ZRlLppp/QKbiYApgQ9smiHYPX6dHLX
f04+X7Fjx0WFXvSpqgnHCjyNajRH3I70riulHj0VQ0904aWc3Ou9dyGezFtUXKph
11NXn2KWs56ixbjwiW4X3EcXGFVgoGD8+ZIYq6MJBdHiI5F87oiJ0YK+Q0JQsymR
T/fTXo/7di2t529XGU/4AOFD89iDWMwHmgwDMSZvD8bRJAMuxB3OmRcrLZE5dIe2
kp9hLOp4iXBX4kFy2lEAdW4hch933OD8Pad4lGhKDLWusAgOOZuHAvwc4nbQaEiu
KaUTSiARnajm5WXj0hJLcS2mtNCgDMis3tW+Vk8LYn8u3pbO53YkyZiYWoOs1ued
JaD7waOix8GYDsM002NA5RR6shCJQQKz1Eow6I3eY1rmWw6bpQPGco1Yoli7GDgt
RKc3KjuZOHFPfkXLaqVI8/rx7Mg4PkwEyXtJ+OY0arsM2LpvXaYjgGfe+pkDvndE
10Dk9rc/w6yc1o+EotUcTm/2hZPlxd9BUOaYWr0kftJvqjysOnc=
=YyUb
-END 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

Retired packages with maintainers

[Pierre-Yves Chibon]

Good Morning Everyone,

A little while ago we have received the request on the infra issue tracker to
remove all maintainers of retired packages [1].

So today I decided to look at what this would look like and wrote a script that
queries PDC for the list of all branches on all projects [2], gather from it a
list of all the packages that are retired on all their branches (so all branches
are ``active=false``).
For each of these retired project, it queries dist-git to find out if they still
have maintainers in addition to the ``orphan`` user.

The outcome of this script can be found there:

  https://pingou.fedorapeople.org/retired_packages_with_maintainers.log


Some stats about this:
- 881 RPM packages are retired and still have maintainers (out of 4322 retired
  RPMs).
- 662 of them are not orphaned
- 42 modules are retired and still have maintainers (out of 42 retired modules).
- all of them are not orphaned
- 2 containers are retired and still have maintainers (out of 3 retired
  containers).
- all of them are not orphaned

Which brings a couple of questions:
- Do we have a documented way to mark modules as orphaned or retired?
- Should we orphan all the RPM packages that are retired but not orphaned?


Finally, does everyone agree about the original request: "remove all maintainers
of retired packages"? Or should we bring this to FESCo?


Thanks for your inputs,

Pierre


[1] https://pagure.io/fedora-infrastructure/issue/8600
[2] https://pdc.fedoraproject.org/extras/active_branches.json (8+Mb file)
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-annou...@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

Retired packages with maintainers

[Pierre-Yves Chibon]

Good Morning Everyone,

A little while ago we have received the request on the infra issue tracker to
remove all maintainers of retired packages [1].

So today I decided to look at what this would look like and wrote a script that
queries PDC for the list of all branches on all projects [2], gather from it a
list of all the packages that are retired on all their branches (so all branches
are ``active=false``).
For each of these retired project, it queries dist-git to find out if they still
have maintainers in addition to the ``orphan`` user.

The outcome of this script can be found there:

  https://pingou.fedorapeople.org/retired_packages_with_maintainers.log


Some stats about this:
- 881 RPM packages are retired and still have maintainers (out of 4322 retired
  RPMs).
- 662 of them are not orphaned
- 42 modules are retired and still have maintainers (out of 42 retired modules).
- all of them are not orphaned
- 2 containers are retired and still have maintainers (out of 3 retired
  containers).
- all of them are not orphaned

Which brings a couple of questions:
- Do we have a documented way to mark modules as orphaned or retired?
- Should we orphan all the RPM packages that are retired but not orphaned?


Finally, does everyone agree about the original request: "remove all maintainers
of retired packages"? Or should we bring this to FESCo?


Thanks for your inputs,

Pierre


[1] https://pagure.io/fedora-infrastructure/issue/8600
[2] https://pdc.fedoraproject.org/extras/active_branches.json (8+Mb file)
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org

Re: Pinging spin or labs maintainers in failed composes tickets

[Miro Hrončok]

On 11. 05. 20 20:03, Miro Hrončok wrote:

On 11. 05. 20 19:53, Mohan Boddu wrote:

Sorry for the late reply, compose-tracker uses the toml file

https://pagure.io/releng/compose-tracker/blob/master/f/compose_tracker.py#_151

And the PR is merged and it should work.


Thanks for confirmation.


It worked \o/

https://pagure.io/releng/failed-composes/issue/1425

--
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 1829906] Upgrade perl-Net-OpenSSH to 0.79

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Net-OpenSSH-0.79-1.fc3
   ||3
 Resolution|--- |RAWHIDE
   Assignee|steve.tray...@cern.ch   |jples...@redhat.com
Last Closed||2020-05-12 10:41:58




-- 
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: Re-Launching the Java SIG

[Severin Gehwolf]

On Mon, 2020-05-11 at 21:45 +0200, Fabio Valentini wrote:
> This past weekend I finally decided to jump off the cliff and attempt
> to re-launch the Java SIG. It seems there's some interest in keeping
> the Java stack maintained, it's just not focused or organized right
> now.
> 
> What we did when starting the Stewardship SIG seems to have worked
> out
> pretty well, so I'm trying to follow in those footsteps here:
> 
> - new proper FAS / pkgdb group: java-maint-sig ("java-sig" is
> occupied
> by an old, unused bot account)
> - new private mailing list: java-maint-sig (for RHBZ bugs - so,
> possibly, also CVEs - hence, private)
> - tracking project on pagure: https://pagure.io/java-maint-sig (for
> maintenance scripts, tracking tickets, awesome package dashboards,
> etc.)
> 
> There's already a public fedora mailing list for Java (java-devel),
> and and IRC channel (#fedora-java on freenode.net), which we will
> continue to use. Sadly, the existing wiki page for the Java SIG is
> hopelessly outdated, so I'm tempted to just scrap it and point
> readers
> to the pagure tracking project once it's set up beyond a basic README
> file.
> 
> Major upcoming projects for the "new" Java Package Maintainers group
> include:
> 
> - managing OpenJDK 11 / Java 11 transition for hundreds of Java
> packages in fedora 33
> - starting to transition well-maintained Java packages from the
> Stewardship SIG back into Java SIG
> - possibly porting packages from gradle to maven to fix build issues
> and broken dependencies
> - transitioning from old java.net / JavaEE projects to the new ones
> now under the eclipse-ee4j umbrella
> 
> I know that - among others - the PKI team, Neuro SIG, and Eclipse
> maintainers depend on parts of the java stack for their packages, so
> I
> hope that we can work together with them on these things, as well.
> 
> So, if you're interested, please consider joining this group effort.
> I'll get new members set up with the FAS group / pagure project /
> mailing list.
> 
> Let's make this happen.

Thanks Fabio!

I'll be happy to join and will try to liaise as we continue to look
after the OpenJDK packages themselves.

Cheers,
Severin
___
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: Re-Launching the Java SIG

[Ty Young]

On 5/12/20 5:39 AM, Fabio Valentini wrote:

On Tue, May 12, 2020 at 12:34 PM Ty Young  wrote:

Right, I figured it was some Fedora policy and not up to you. I suppose
I should have been more clear there. Sorry for any confusion, it was
aimed at the Fedora project as a whole as this is a Fedora issue.

I am aware that Arch is just packaging up the binary release artifacts
published by the gradle project.
But that's just never going to fly for fedora.


Well, guess I now know why no one wants to package software for Fedora.



Arch is also the only distro I looked at that does this, everybody
else (at least debian, ubuntu, OpenSUSE) is stuck at an ancient
version, if gradle is available at all.


Honestly? Good. Those LInux distros, including Fedora, need taken down a 
few pegs. 3rd party software developers cannot nor will they always bend 
a knee to extreme constraints that are not otherwise required to build 
on any other platform or run properly on supported platforms. Linux 
distros need to learn to play nice with other people.






FWIW, I can compile 6.4 just fine on Arch Linux using the Github source
code via:


./gradlew allZip

Now try doing that offline and without using the pre-built
gradle/wrapper/gradle-wrapper.jar :)
You'll be surprised how much junk the build process still needs to download.


Not a shocker. Gradle breaks backwards compatibility all the time, 
forcing projects to always use the wrapper. If using pre-builts isn't 
allowed Gradle will never be buildable, at least not consistently.




Fabio


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

___
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: [fedora-java] Re-Launching the Java SIG

[Aleksandar Kurtakov]

On Mon, May 11, 2020 at 10:46 PM Fabio Valentini 
wrote:

> This past weekend I finally decided to jump off the cliff and attempt
> to re-launch the Java SIG. It seems there's some interest in keeping
> the Java stack maintained, it's just not focused or organized right
> now.
>
> What we did when starting the Stewardship SIG seems to have worked out
> pretty well, so I'm trying to follow in those footsteps here:
>
> - new proper FAS / pkgdb group: java-maint-sig ("java-sig" is occupied
> by an old, unused bot account)
> - new private mailing list: java-maint-sig (for RHBZ bugs - so,
> possibly, also CVEs - hence, private)
> - tracking project on pagure: https://pagure.io/java-maint-sig (for
> maintenance scripts, tracking tickets, awesome package dashboards,
> etc.)
>
> There's already a public fedora mailing list for Java (java-devel),
> and and IRC channel (#fedora-java on freenode.net), which we will
> continue to use. Sadly, the existing wiki page for the Java SIG is
> hopelessly outdated, so I'm tempted to just scrap it and point readers
> to the pagure tracking project once it's set up beyond a basic README
> file.
>
> Major upcoming projects for the "new" Java Package Maintainers group
> include:
>
> - managing OpenJDK 11 / Java 11 transition for hundreds of Java
> packages in fedora 33
> - starting to transition well-maintained Java packages from the
> Stewardship SIG back into Java SIG
> - possibly porting packages from gradle to maven to fix build issues
> and broken dependencies
> - transitioning from old java.net / JavaEE projects to the new ones
> now under the eclipse-ee4j umbrella
>
> I know that - among others - the PKI team, Neuro SIG, and Eclipse
> maintainers depend on parts of the java stack for their packages, so I
> hope that we can work together with them on these things, as well.
>
> So, if you're interested, please consider joining this group effort.
> I'll get new members set up with the FAS group / pagure project / mailing
> list.
>

Good luck with that! As someone that has been part of the Java SIG since
day 0 I wish you make Fedora even better workstation for Java developer
than we ever managed.


>
> Let's make this happen.
> Fabio
> ___
> java-devel mailing list -- java-de...@lists.fedoraproject.org
> To unsubscribe send an email to java-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/java-de...@lists.fedoraproject.org
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
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: LibRaw 0.20 Beta; soname bump

[Aleksandra Fedorova]

On Tue, May 12, 2020 at 12:21 PM Aleksandra Fedorova  wrote:
>
> Hi,
>
> On Tue, May 12, 2020 at 12:05 PM Miro Hrončok  wrote:
> >
> > On 12. 05. 20 10:46, Daniel P. Berrangé wrote:
> > > Are we ever going to get gating on rawhide, so that soname bumps are 
> > > blocked
> > > from entering the dist until rebuilds of deps are ready ?
> >
> > We wanted to, Taskotron was able to figure this out, but was recently EOLed,
> > before a viable alternative existed in Fedora CI (it still doesn't exist).
> >
> > https://pagure.io/fesco/issue/2343
>
> Inn Fedora CI SIG we are working on the updated version of the
> rpmdeplint test, see [1].

And I forgot the links

https://teams.fedoraproject.org/project/ci/epic/68 for the pipelines
and
https://github.com/fedora-ci/rpmdeplint-pipeline for rpmdeplint
pipeline specifically.

-- 
Aleksandra Fedorova
bookwar
___
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: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

[Petr Pisar]

On Tue, May 12, 2020 at 09:03:22AM +, virgo wrote:
> The issue is that I upgraded my computer to Fedora 32 from version 30, and 
> broke some scripts in the process; they were relying on cgroup v1.
[...]
> how to use the `cgcreate` command and the like under libcgroup v2?

cgcreate tool comes from libcgroup-tools-0:0.42.2-1.fc32 package that comes
from libcgroup project sources, and libcgroup does not yet support cgroup v2.

A quick search of WWW shows that
:

30 October 2019, 04:38:42
The libcgroup devs are currently discussing plans to implement v2 cgroup
support

 project had a last release on 2014-01-13.
A thread on its devel list
 from 2019-10-14
still discusses v2 support as in-progress.

Fedora packages a fork (or a new upstream) from 
.
I recommend you to ask the question about v2 support on Fedora Bugzilla for the
libcgroup package
.

-- Petr


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: Re-Launching the Java SIG

[Felix Schwarz]

Am 12.05.20 um 12:32 schrieb Ty Young:
> Right, I figured it was some Fedora policy and not up to you. I suppose I
> should have been more clear there. Sorry for any confusion, it was aimed at
> the Fedora project as a whole as this is a Fedora issue.

This is not a Fedora issue but a consequence of Fedora's core values. You not
agree with it but "building from source" is so fundamental that it does not
make sense to even start a discussion about it on fedora-devel.

I suggest you read up on the rationale behind that policy (which is why I
linked the policy document in the first place).

I understand that missing components/features due to the source requirement
are annoying but Fedora (and other distros) decided to take the "high road"
here and actually fix stuff instead of shipping whatever upstream came up with.

Felix
___
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: Re-Launching the Java SIG

[Vitaly Zaitsev via devel]

On 12.05.2020 10:35, Ty Young wrote:
> JUST PACKAGE THE PRE-COMPILED BUILDS!!!

No. Please read Fedora packaging guidelines. All packages **must** be
built from sources.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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: Re-Launching the Java SIG

[Fabio Valentini]

On Tue, May 12, 2020 at 12:34 PM Ty Young  wrote:
> Right, I figured it was some Fedora policy and not up to you. I suppose
> I should have been more clear there. Sorry for any confusion, it was
> aimed at the Fedora project as a whole as this is a Fedora issue.

I am aware that Arch is just packaging up the binary release artifacts
published by the gradle project.
But that's just never going to fly for fedora.

Arch is also the only distro I looked at that does this, everybody
else (at least debian, ubuntu, OpenSUSE) is stuck at an ancient
version, if gradle is available at all.

> FWIW, I can compile 6.4 just fine on Arch Linux using the Github source
> code via:
>
>
> ./gradlew allZip

Now try doing that offline and without using the pre-built
gradle/wrapper/gradle-wrapper.jar :)
You'll be surprised how much junk the build process still needs to download.

Fabio

> >
> > Felix
> > ___
> > 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
___
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: Re-Launching the Java SIG

[Ty Young]

On 5/12/20 3:48 AM, Felix Schwarz wrote:

Am 12.05.20 um 10:35 schrieb Ty Young:

JUST PACKAGE THE PRE-COMPILED BUILDS!!!

Don't take me as rude but this is not possible.

This is documented in Fedora's packaging policies:
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries



Right, I figured it was some Fedora policy and not up to you. I suppose 
I should have been more clear there. Sorry for any confusion, it was 
aimed at the Fedora project as a whole as this is a Fedora issue.



FWIW, I can compile 6.4 just fine on Arch Linux using the Github source 
code via:



./gradlew allZip





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

[Bug 1834195] perl-Set-Crontab missing from epel8 repository metadata

[bugzilla]

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



--- Comment #4 from Petr Pisar  ---
I checked http://mirror.xnet.co.nz/pub/epel/8/Everything/x86_64/ and it works
for me:

# dnf --disableexcludes=all --disablerepo=\*
--repofrompath=0,http://mirror.xnet.co.nz/pub/epel/8/Everything/x86_64/
--enablerepo=0 list perl-Set-Crontab
Added 0 repo from http://mirror.xnet.co.nz/pub/epel/8/Everything/x86_64/
Last metadata expiration check: 0:03:01 ago on Tue 12 May 2020 12:21:05 PM
CEST.
Available Packages
perl-Set-Crontab.noarch   
1.03-23.el80

What do you have in a DNF cache? You call the repository "epel", so the cache
should be stored under that name:

# ls -1 /var/cache/dnf/epel-*/repodata/*-primary.xml.gz
/var/cache/dnf/epel-7a16a556fa830aea/repodata/f67703d4685fe54b584f64dd96d6de7b2ac0e62ec463f1cfe0edfd8f1aa3918f-primary.xml.gz
/var/cache/dnf/epel-debuginfo-5f67037558fb2804/repodata/30794dba6e89530a2a8dcac713630f6ce72bd7c9ce2681026dd95e36163aeb0f-primary.xml.gz
/var/cache/dnf/epel-fafd94c310c51e1e/repodata/894cf5692655e6208a7ede191e35e2bc7aacaa83b876f4e2a8c3735ead1e7b06-primary.xml.gz
/var/cache/dnf/epel-playground-766b072374ad8e05/repodata/f461e389647721e7b7bf4bfd676c959bad337c5312a993b2cacbb3f10b1e8adb-primary.xml.gz
/var/cache/dnf/epel-playground-debuginfo-2ee68f63ceca78c3/repodata/c2ae2ff1a3ed0a2e4d8832f1a4faff97e780a69066dfdd9688717ac7711198c6-primary.xml.gz
/var/cache/dnf/epel-source-ba14841798a189d3/repodata/3edeb5f274fde929dffb330332f62a101734c1229639f03290cf23d6dcd45aa0-primary.xml.gz
/var/cache/dnf/epel-testing-5940ef4b3ab6481f/repodata/93a907c073ce60bf4edbb3d19fb0f488e1769c27a7d47d896869dbfd9a705f3c-primary.xml.gz
/var/cache/dnf/epel-testing-6a55fbde0b6e266c/repodata/09d45e72dad67e5fabdd607f7a3d638381341836f68dd6ddb45a750f31338bcd-primary.xml.gz
/var/cache/dnf/epel-testing-debuginfo-aec431fd5e71ee61/repodata/af1e6436eb958c2f2bc926b2dfbc627501bbd254822bc1f045db98d2fb8f5377-primary.xml.gz

# zcat
/var/cache/dnf/epel-7a16a556fa830aea/repodata/f67703d4685fe54b584f64dd96d6de7b2ac0e62ec463f1cfe0edfd8f1aa3918f-primary.xml.gz
| grep perl-Set-Crontab
  perl-Set-Crontab
  
perl-Set-Crontab-1.03-23.el8.src.rpm
  


-- 
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 1832203] Upgrade perl-Type-Tiny to 1.010002

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Type-Tiny-1.010002-1.f
   ||c33,
   ||perl-Type-Tiny-1.010002-1.f
   ||c32,
   ||perl-Type-Tiny-1.010002-1.f
   ||c31
 Resolution|--- |RAWHIDE
Last Closed||2020-05-12 10:23:07




-- 
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: LibRaw 0.20 Beta; soname bump

[Aleksandra Fedorova]

Hi,

On Tue, May 12, 2020 at 12:05 PM Miro Hrončok  wrote:
>
> On 12. 05. 20 10:46, Daniel P. Berrangé wrote:
> > Are we ever going to get gating on rawhide, so that soname bumps are blocked
> > from entering the dist until rebuilds of deps are ready ?
>
> We wanted to, Taskotron was able to figure this out, but was recently EOLed,
> before a viable alternative existed in Fedora CI (it still doesn't exist).
>
> https://pagure.io/fesco/issue/2343

Inn Fedora CI SIG we are working on the updated version of the
rpmdeplint test, see [1].
Unfortunately, this work was delayed by Community Shift cluster
migration as we need to look for a better home for the Jenkins master
now.

The current plan is to deploy a temporary Jenkins master on whatever
infrastructure we find, and start running the pipeline from there.

The rpmdeplint is the first pipeline we'd like to get running. As it
is the most simple one.

Then we have a prototype for Koschei integration, which can test
sidetag-based gating events.
And generally we would like to be able to create new pipelines from
basically any script.

I'll post an update as soon as Jenkins situation is resolved.

>
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/message/OXK6BKUPCOMNGWWLWL4GDQGGJIWNZCR6/
>
> > It seems we have some automated process detecting this, as I received a
> > bug report this morning warning me that entangle was broken by LibRaw
> > soname bump
>
> Those are scripts run by people who care. Possibly Igor this time.
>
> --
> 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

-- 
Aleksandra Fedorova
bookwar
___
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: LibRaw 0.20 Beta; soname bump

[Miro Hrončok]

On 12. 05. 20 0:12, Miro Hrončok wrote:

On 11. 05. 20 22:33, Gwyn Ciesla via devel wrote:
I'm building LibRaw 0.20 Beta 1 for rawhide, along with all direct consumers, 
in a multi-stage chain build, today, including the following:


deepin-image-viewer
elementary-photos
freeimage
gthumb
indi-gphoto
krita
luminance-hdr
photoqt
shotwell
efl
entangle
gegl04
ImageMagick
kf5-libkdcraw
libpasraw
nomacs
OpenImageIO
rapid-photo-downloader
siril
blender
luxcorerender


I'm getting a lot of broken deps like this:

Problem: package emacs-1:26.3-3.fc33.x86_64 requires 
libMagickCore-6.Q16.so.6()(64bit), but none of the providers can be installed
- package emacs-1:26.3-3.fc33.x86_64 requires libMagickWand-6.Q16.so.6()(64bit), 
but none of the providers can be installed

- conflicting requests
- nothing provides libraw_r.so.19()(64bit) needed by 
ImageMagick-libs-1:6.9.10.86-2.fc32.x86_64


I see this build was cancelled:
https://koji.fedoraproject.org/koji/taskinfo?taskID=44387471


I've hit rebuild again:

https://koji.fedoraproject.org/koji/taskinfo?taskID=44410327


--
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: LibRaw 0.20 Beta; soname bump

[Miro Hrončok]

On 12. 05. 20 10:46, Daniel P. Berrangé wrote:

Are we ever going to get gating on rawhide, so that soname bumps are blocked
from entering the dist until rebuilds of deps are ready ?


We wanted to, Taskotron was able to figure this out, but was recently EOLed, 
before a viable alternative existed in Fedora CI (it still doesn't exist).


https://pagure.io/fesco/issue/2343

https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/message/OXK6BKUPCOMNGWWLWL4GDQGGJIWNZCR6/


It seems we have some automated process detecting this, as I received a
bug report this morning warning me that entangle was broken by LibRaw
soname bump


Those are scripts run by people who care. Possibly Igor this time.

--
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: Proposal: Revise FESCo voting policy

[Miro Hrončok]

On 12. 05. 20 10:27, Vít Ondruch wrote:

Actually, it should be also useful if position of each abstaining FESCo
member was explained. Because for myself, I can interpret 5 people
abstaining just as a lack of understanding of the issue and nothing else.


For me, it was that. I wasn't able to grasp the change proposal quickly, would 
need to dedicate more time to it and I prioritized other things, abstaining as 
in: "I trust other members understand this issue better than me and they will 
decide the good way."


However, it turned out that there was simply too many of 0 votes, hence I bit 
the bullet and decided to vote in favor, trusting the change owners they know 
what they are doing.


--
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 (master). "Update to 1.869 (..more)"

[notifications]

Notification time stamped 2020-05-12 09:47:49 UTC

From a7a5a6881425f233e91b4c6ba70b125f564d13da Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: May 12 2020 09:46:59 +
Subject: Update to 1.869


- New upstream release 1.869
  - Disabled unicode testing for MCE::Shared::Cache on Perl 5.10.1; testing
for keys containing unicode is failing on RedHat 6.x but passing in
meta::cpan (smoke tests)
  - Share array and hash deeply: only when using the TIE interface; this
resolves an edge case for the OO interface and passing nested items during
construction
  - Bumped MCE dependency to 1.868

---

diff --git a/perl-MCE-Shared.spec b/perl-MCE-Shared.spec
index 59cffcf..10010b6 100644
--- a/perl-MCE-Shared.spec
+++ b/perl-MCE-Shared.spec
@@ -1,5 +1,5 @@
 Name:  perl-MCE-Shared
-Version:   1.868
+Version:   1.869
 Release:   1%{?dist}
 Summary:   MCE extension for sharing data, supporting threads and processes
 License:   GPL+ or Artistic
@@ -92,6 +92,16 @@ make test
 %{_mandir}/man3/MCE::Shared::Server.3*
 
 %changelog
+* Tue May 12 2020 Paul Howarth  - 1.869-1
+- Update to 1.869
+  - Disabled unicode testing for MCE::Shared::Cache on Perl 5.10.1; testing
+for keys containing unicode is failing on RedHat 6.x but passing in
+meta::cpan (smoke tests)
+  - Share array and hash deeply: only when using the TIE interface; this
+resolves an edge case for the OO interface and passing nested items during
+construction
+  - Bumped MCE dependency to 1.868
+
 * Mon May 11 2020 Paul Howarth  - 1.868-1
 - Update to 1.868
   - Bug fix for UTF-8 issues during inter-process communication
diff --git a/sources b/sources
index 31f16ac..9facb14 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (MCE-Shared-1.868.tar.gz) = 
48a4989a91f207ee399d73d083a6b2344ab4ecd1716ca2f46414e0bf74585d866b3e285d0254bbe4b8bba9a41ede7fd6898bfa1411305f4677a05767a2903544
+SHA512 (MCE-Shared-1.869.tar.gz) = 
08c9664d7a96f52a32bd44a7540370c812e770e8f5547dc5c040fd203e32a1955d35dd7e9170e7db08a4a0acb3bbc1670a1f412a91cdaa6f1bafe77e4a3305d5



https://src.fedoraproject.org/rpms/perl-MCE-Shared/c/a7a5a6881425f233e91b4c6ba70b125f564d13da?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

[389-devel] Please review: PR #51075 - Issue 50610 - memory leak in dbscan and changelog encryption

[Simon Pichugin]

Hi team,
please, check my memory leaks fix:
https://pagure.io/389-ds-base/pull-request/51075

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

Re: Proposal: Revise FESCo voting policy

[Zbigniew Jędrzejewski-Szmek]

On Tue, May 12, 2020 at 10:27:26AM +0200, Vít Ondruch wrote:
> 
> Dne 12. 05. 20 v 10:18 Vít Ondruch napsal(a):
> > Dne 11. 05. 20 v 19:40 Aleksandra Fedorova napsal(a):
> >> Hi,
> >>
> >> On Mon, May 11, 2020 at 5:52 PM Stephen Gallagher  
> >> wrote:
> >>> During today's FESCo meeting, we encountered an unusual voting
> >>> situation for the first time: Four FESCo members voted in favor (+1)
> >>> of a measure and five FESCo members opted to abstain (0) for various
> >>> reasons. However, the FESCo voting policy currently reads: "A majority
> >>> of the committee (that is, five out of nine) is required to pass a
> >>> proposal in a meeting." As a result, we were actually at an impasse
> >>> until two of the FESCo members opted to change their votes to +1 to
> >>> resolve the confusion.
> >>>
> >>> It was subsequently suggested that we revise the policy to avoid this
> >>> pitfall in the future. I volunteered to put together a proposal for
> >>> how this could work and send it to the Fedora Development list for
> >>> discussion. I propose the following changes to the FESCo voting
> >>> policy:
> >>>
> >>> * To pass any measure, a majority — defined as the greater of half the
> >>> eligible votes (rounded up) — must vote in favor of the measure. The
> >>> standard set of eligible votes is one vote per FESCo member. No
> >>> measure may pass without at least one vote in favor.
> >>>
> >>> * Abstaining from a vote (aka "voting 0") is considered to have
> >>> removed that FESCo member's vote from the set of eligible votes. This
> >>> must be done explicitly and is never to be assumed from lack of
> >>> communication.
> >>>
> >>> A practical effect of the new abstention rule is that if two FESCo
> >>> members abstain, the measure would then require only a +4 vote to
> >>> pass. (A single abstention would still require a +5 vote).
> >> I don't like this idea.
> >>
> >> I think if FESCo members don't have enough data or understanding to
> >> vote on the topic, this means that FESCo needs to put more effort in
> >> it.
Yes.

> >> Find some subject matter experts in the community, make additional
> >> steps to learn the subject.
> >> Or, when topic has no technical foundation but more of the personal
> >> preference, bring it for a full community vote.
> >>
> >> In the end FESCo supposed to channel the community voice.
> >> If FESCo can not make a decision, it means delegation of the decision
> >> to FESCo by community failed. So let's go back to community?
> >>
> >> So how about the alternative:
> >> if FESCo can't come up with the decision, it announces the stalled
> >> decision to fedora-announce and requests help.
> 
> 
> Actually, it should be also useful if position of each abstaining FESCo
> member was explained. Because for myself, I can interpret 5 people
> abstaining just as a lack of understanding of the issue and nothing else.

+1

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

Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

[virgo]

Greetings,

I am very aware this is not the place for user questions. This is also where 
the likelihood of an answer /at all/ are the highest. So, please bear with me; 
at the bottom[fn:1] are all the other places where I tried to find hints 
before posting here.

The issue is that I upgraded my computer to Fedora 32 from version 30, and 
broke some scripts in the process; they were relying on cgroup v1. The system-
wide change proposal submitted for Fedora 31[fn:2] and the associated release 
notes[fn:3], along with many other locations on the inter-webs, all seemed to 
indicate that adaptation to v2 would pass through systemd. The broken scripts 
do not invoke (not directly, strictly speaking) systemd at all. This citation 
is from the aforementioned release notes:

#+BEGIN_QUOTE
The tools or scripts should not require any changes, if they utilized the 
`systemd` interfaces.
#+END_QUOTE


Here is an example of how I wrote the scripts:


#+BEGIN_EG1 Bash
# Configuring a group
TGT='foo'
GRP='woe'
let M=(500 * 1024 * 1024)
let C=25

cgcreate \
-a "${TGT}:${TGT}" \
-t "${TGT}:${TGT}" \
-g memory:"${GRP}" \
-g cpu:"${GRP}"

printf "%d" "$M" > \ 
/sys/fs/cgroup/memory/"$GRP"/memory.limit_in_bytes

printf "%d" "$C" > \
/sys/fs/cgroup/cpu/"$GRP"/cpu.cfs_quota_us

# Using the new group
cgexec --sticky -g "memory,cpu:${GRP}" 
#+END_EG1


That does not cut it anymore. The furthest I went to trying something else is 
editing this file:


#+BEGIN_EG2  /etc/cgconfig.conf
group woe {
perm {
task {
uid = foo;
gid = foo;
}
}

memory {
memory.high = 524288000;
}

cpu {
cpu.max = 050 100;
}
}
#+END_EG2


I believed that after a system reboot, systemd would create the cgroup `foo`. 
But nothing I could see/test happened. So, here is where your help would be 
greatly appreciated: how to use the `cgcreate` command and the like under 
libcgroup v2? Alternatively, if the way is by configuration files, where to 
create them and how to enforce what they stipulate? I do not mind *reading* 
literature on the subject, provided the assumed audience is a lay-user, not a 
kernel/container… developer.

Thanks in advance.

...
[fn:1] So far, to no avail,
1. I scanned various pages at [[licgroup’s upstream]][https://sourceforge.net/
projects/libcg/];
2. re-read some manuals;
3. posted at users@l.f.o;
4. went to places on the web…

[fn:2] Unified hierarchy proposal[[https://fedoraproject.org/wiki/Changes/
CGroupsV2]]

[fn:3] Release notes [[https://pagure.io/fork/quiet/fedora-docs/release-notes/
blob/06f98a01f9bbb437b0e51b2cba69ed2735483fa9/f/modules/release-notes/pages/
sysadmin/Kernel.adoc]]

___
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 1834195] perl-Set-Crontab missing from epel8 repository metadata

[bugzilla]

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



--- Comment #3 from Peter Ajamian  ---
I'm using http://mirror.xnet.co.nz/pub/epel/8/Everything/x86_64/.  I also
checked with
http://ucmirror.canterbury.ac.nz/linux/fedora/fedora-epel/8/Everything/x86_64/
and https://download-ib01.fedoraproject.org/pub/epel/8/Everything/x86_64/ and
it's doing the same thing with all three.  Maybe it's something in my config?


Peter


-- 
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: Re-Launching the Java SIG

[Ankur Sinha]

On Tue, May 12, 2020 03:35:55 -0500, Ty Young wrote:
> 
> On 5/12/20 2:50 AM, Fabio Valentini wrote:
> > > What about packaging gradle instead? (In the cases I looked into,
> > > porting from gradle to maven would be rewriting the build system from
> > > scratch. Assuming that we have tens and will have hundreds of packages
> > > with gradle, in the long term it seems better to support gradle, even
> > > in some partial form, than to rewrite build systems of hundreds of
> > > packages...).
> > Uh. We tried. Multiple times. It just won't work, like, ever again. I
> > wrote a longer response here:
> > https://discussion.fedoraproject.org/t/re-launching-the-java-sig/19688/3
> > So, you are welcome to try, but I bet you'll end up in the long line
> > of packagers who failed to make it work.
> 
> 
> JUST PACKAGE THE PRE-COMPILED BUILDS!!!

Ty, please stop.

-- 
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: Re-Launching the Java SIG

[Felix Schwarz]

Hey Fabio,

thank you very much for your work.

I can't take on more Fedora work but still wanted to express my gratitude :-)

Felix
___
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: Re-Launching the Java SIG

[Felix Schwarz]

Am 12.05.20 um 10:35 schrieb Ty Young:
> JUST PACKAGE THE PRE-COMPILED BUILDS!!!

Don't take me as rude but this is not possible.

This is documented in Fedora's packaging policies:
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries

Felix
___
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: LibRaw 0.20 Beta; soname bump

[Daniel P . Berrangé]

On Tue, May 12, 2020 at 12:12:01AM +0200, Miro Hrončok wrote:
> On 11. 05. 20 22:33, Gwyn Ciesla via devel wrote:
> > I'm building LibRaw 0.20 Beta 1 for rawhide, along with all direct
> > consumers, in a multi-stage chain build, today, including the following:
> > 
> > deepin-image-viewer
> > elementary-photos
> > freeimage
> > gthumb
> > indi-gphoto
> > krita
> > luminance-hdr
> > photoqt
> > shotwell
> > efl
> > entangle
> > gegl04
> > ImageMagick
> > kf5-libkdcraw
> > libpasraw
> > nomacs
> > OpenImageIO
> > rapid-photo-downloader
> > siril
> > blender
> > luxcorerender
> 
> I'm getting a lot of broken deps like this:
> 
> Problem: package emacs-1:26.3-3.fc33.x86_64 requires
> libMagickCore-6.Q16.so.6()(64bit), but none of the providers can be
> installed
> - package emacs-1:26.3-3.fc33.x86_64 requires
> libMagickWand-6.Q16.so.6()(64bit), but none of the providers can be
> installed
> - conflicting requests
> - nothing provides libraw_r.so.19()(64bit) needed by
> ImageMagick-libs-1:6.9.10.86-2.fc32.x86_64
> 
> I see this build was cancelled:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=44387471
> 
> Could you please do such bumps in a side tag to avoid disruption?

Are we ever going to get gating on rawhide, so that soname bumps are blocked
from entering the dist until rebuilds of deps are ready ?

It seems we have some automated process detecting this, as I received a
bug report this morning warning me that entangle was broken by LibRaw
soname bump

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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: Re-Launching the Java SIG

[Ty Young]

On 5/12/20 2:50 AM, Fabio Valentini wrote:

What about packaging gradle instead? (In the cases I looked into,
porting from gradle to maven would be rewriting the build system from
scratch. Assuming that we have tens and will have hundreds of packages
with gradle, in the long term it seems better to support gradle, even
in some partial form, than to rewrite build systems of hundreds of
packages...).

Uh. We tried. Multiple times. It just won't work, like, ever again. I
wrote a longer response here:
https://discussion.fedoraproject.org/t/re-launching-the-java-sig/19688/3
So, you are welcome to try, but I bet you'll end up in the long line
of packagers who failed to make it work.



JUST PACKAGE THE PRE-COMPILED BUILDS!!!



__
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

[Bug 1834480] perl-FFI-CheckLib-0.27 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2020-12cd8fc8b8 has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-12cd8fc8b8


-- 
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 1834480] perl-FFI-CheckLib-0.27 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
 CC|ppi...@redhat.com   |
   Fixed In Version||perl-FFI-CheckLib-0.27-1.fc
   ||33
   Doc Type|--- |If docs needed, set a value



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for Fedora ≥ 32.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@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-de...@lists.fedoraproject.org

Re: Proposal: Revise FESCo voting policy

[Vít Ondruch]

Dne 12. 05. 20 v 10:18 Vít Ondruch napsal(a):
> Dne 11. 05. 20 v 19:40 Aleksandra Fedorova napsal(a):
>> Hi,
>>
>> On Mon, May 11, 2020 at 5:52 PM Stephen Gallagher  
>> wrote:
>>> During today's FESCo meeting, we encountered an unusual voting
>>> situation for the first time: Four FESCo members voted in favor (+1)
>>> of a measure and five FESCo members opted to abstain (0) for various
>>> reasons. However, the FESCo voting policy currently reads: "A majority
>>> of the committee (that is, five out of nine) is required to pass a
>>> proposal in a meeting." As a result, we were actually at an impasse
>>> until two of the FESCo members opted to change their votes to +1 to
>>> resolve the confusion.
>>>
>>> It was subsequently suggested that we revise the policy to avoid this
>>> pitfall in the future. I volunteered to put together a proposal for
>>> how this could work and send it to the Fedora Development list for
>>> discussion. I propose the following changes to the FESCo voting
>>> policy:
>>>
>>> * To pass any measure, a majority — defined as the greater of half the
>>> eligible votes (rounded up) — must vote in favor of the measure. The
>>> standard set of eligible votes is one vote per FESCo member. No
>>> measure may pass without at least one vote in favor.
>>>
>>> * Abstaining from a vote (aka "voting 0") is considered to have
>>> removed that FESCo member's vote from the set of eligible votes. This
>>> must be done explicitly and is never to be assumed from lack of
>>> communication.
>>>
>>> A practical effect of the new abstention rule is that if two FESCo
>>> members abstain, the measure would then require only a +4 vote to
>>> pass. (A single abstention would still require a +5 vote).
>> I don't like this idea.
>>
>> I think if FESCo members don't have enough data or understanding to
>> vote on the topic, this means that FESCo needs to put more effort in
>> it.
>>
>> Find some subject matter experts in the community, make additional
>> steps to learn the subject.
>> Or, when topic has no technical foundation but more of the personal
>> preference, bring it for a full community vote.
>>
>> In the end FESCo supposed to channel the community voice.
>> If FESCo can not make a decision, it means delegation of the decision
>> to FESCo by community failed. So let's go back to community?
>>
>> So how about the alternative:
>> if FESCo can't come up with the decision, it announces the stalled
>> decision to fedora-announce and requests help.


Actually, it should be also useful if position of each abstaining FESCo
member was explained. Because for myself, I can interpret 5 people
abstaining just as a lack of understanding of the issue and nothing else.


Vít


>>  Better summary, more
>> arguments, etc..
>>
>> This would encourage people who are against the change to participate.
>
> I agree with Aleksandra up until here.
>
>
>> And if there are no such people to provide convincing arguments
>> against the change in a reasonable time frame, than FESCo decides in
>> favor of the submitter.
>
> I disagree here. If such proposal does not have enough support, then it
> should not be accepted and should be revisited/abandoned/rejected. I
> cannot imagine any even hypothetical situation where the opposite was
> beneficial.
>
>
> 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: Re-Launching the Java SIG

[Fabio Valentini]

On Tue, May 12, 2020 at 10:15 AM Ankur Sinha  wrote:
>
> On Tue, May 12, 2020 09:50:30 +0200, Fabio Valentini wrote:
> > >
> > > Yep, count me in.
> >
> > Thanks. I'll get your memberships set up. :)
>
> Thank you for starting this off, and thank you for taking care of the
> Java packages in the meantime too. We really appreciate it. Please count
> me in also. :)

Good morning!

I suspected that you would be interested as well :)
You'll see your new group memberships shortly (possibly log out and
back in with src.fedoraproject.org).

Fabio

> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) | 
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
> ___
> 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: Proposal: Revise FESCo voting policy

[Vít Ondruch]

Dne 11. 05. 20 v 19:40 Aleksandra Fedorova napsal(a):
> Hi,
>
> On Mon, May 11, 2020 at 5:52 PM Stephen Gallagher  wrote:
>> During today's FESCo meeting, we encountered an unusual voting
>> situation for the first time: Four FESCo members voted in favor (+1)
>> of a measure and five FESCo members opted to abstain (0) for various
>> reasons. However, the FESCo voting policy currently reads: "A majority
>> of the committee (that is, five out of nine) is required to pass a
>> proposal in a meeting." As a result, we were actually at an impasse
>> until two of the FESCo members opted to change their votes to +1 to
>> resolve the confusion.
>>
>> It was subsequently suggested that we revise the policy to avoid this
>> pitfall in the future. I volunteered to put together a proposal for
>> how this could work and send it to the Fedora Development list for
>> discussion. I propose the following changes to the FESCo voting
>> policy:
>>
>> * To pass any measure, a majority — defined as the greater of half the
>> eligible votes (rounded up) — must vote in favor of the measure. The
>> standard set of eligible votes is one vote per FESCo member. No
>> measure may pass without at least one vote in favor.
>>
>> * Abstaining from a vote (aka "voting 0") is considered to have
>> removed that FESCo member's vote from the set of eligible votes. This
>> must be done explicitly and is never to be assumed from lack of
>> communication.
>>
>> A practical effect of the new abstention rule is that if two FESCo
>> members abstain, the measure would then require only a +4 vote to
>> pass. (A single abstention would still require a +5 vote).
> I don't like this idea.
>
> I think if FESCo members don't have enough data or understanding to
> vote on the topic, this means that FESCo needs to put more effort in
> it.
>
> Find some subject matter experts in the community, make additional
> steps to learn the subject.
> Or, when topic has no technical foundation but more of the personal
> preference, bring it for a full community vote.
>
> In the end FESCo supposed to channel the community voice.
> If FESCo can not make a decision, it means delegation of the decision
> to FESCo by community failed. So let's go back to community?
>
> So how about the alternative:
> if FESCo can't come up with the decision, it announces the stalled
> decision to fedora-announce and requests help. Better summary, more
> arguments, etc..
>
> This would encourage people who are against the change to participate.


I agree with Aleksandra up until here.


> And if there are no such people to provide convincing arguments
> against the change in a reasonable time frame, than FESCo decides in
> favor of the submitter.


I disagree here. If such proposal does not have enough support, then it
should not be accepted and should be revisited/abandoned/rejected. I
cannot imagine any even hypothetical situation where the opposite was
beneficial.


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: Re-Launching the Java SIG

[Ankur Sinha]

On Tue, May 12, 2020 09:50:30 +0200, Fabio Valentini wrote:
> >
> > Yep, count me in.
> 
> Thanks. I'll get your memberships set up. :)

Thank you for starting this off, and thank you for taking care of the
Java packages in the meantime too. We really appreciate it. Please count
me in also. :)


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