[Bug 1829089] perl-Module-CoreList-5.20200428 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
FEDORA-2020-eb269aa65e has been pushed to the Fedora 31 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-eb269aa65e`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-eb269aa65e

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

[Bug 1829102] perl-CPAN-Perl-Releases-5.20200428 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
FEDORA-2020-51484a5980 has been pushed to the Fedora 31 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-51484a5980`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-51484a5980

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

[Bug 1829119] perl-RT-Client-REST-0.57 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
FEDORA-2020-a611ef944a has been pushed to the Fedora 31 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-a611ef944a`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-a611ef944a

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

[Bug 1829102] perl-CPAN-Perl-Releases-5.20200428 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
FEDORA-2020-2330b48960 has been pushed to the Fedora 30 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-2330b48960`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-2330b48960

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

[Bug 1829089] perl-Module-CoreList-5.20200428 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
FEDORA-2020-ead5206668 has been pushed to the Fedora 30 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-ead5206668`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-ead5206668

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

[Bug 1829119] perl-RT-Client-REST-0.57 is available

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
FEDORA-2020-0ee23e1a1d has been pushed to the Fedora 30 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-0ee23e1a1d`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-0ee23e1a1d

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

Re: Orphaned packages looking for new maintainers (anaconda also affected)

[Markku Korkeala]

On 4/27/20 1:39 PM, 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
>
> maven-release jcapik, orphan   2
> weeks ago

Hi,

I took maven-release as my package depends on it. Seems like
updated dependencies broke the build, I'll see if that can be fixed

I'll see if I can take some other java packages as well to prevent
them all being retired.
 

Best wishes,
Markku

___
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 1829089] perl-Module-CoreList-5.20200428 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-2020-e9eb62e871 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-e9eb62e871`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-e9eb62e871

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

[Bug 1829119] perl-RT-Client-REST-0.57 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #7 from Fedora Update System  ---
FEDORA-2020-35ae08b351 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-35ae08b351`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-35ae08b351

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

[Bug 1829102] perl-CPAN-Perl-Releases-5.20200428 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-2020-0caffaf370 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-0caffaf370`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-0caffaf370

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

Re: Backports of fixes from F32 -> F31?

[Ty Young]

On 4/29/20 8:04 PM, Josh Boyer wrote:

Sure, that's valid.  Although for installations contained to just
Fedora content, the upgrade from release to release has been downright
boring (that's a good thing).  It's almost equivalent to a reboot.

Perhaps there are other reasons, like some third party software not
working on F32, for example.  I'm generally curious about how people
actually use our distributions and what prevents them from just
drinking from the firehose.



Besides rpm-ostree still being bugged as of Fedora 32? Outside of Fedora 
workstation no one seems to care what state other spins/versions of 
Fedora are released in. You can't tell me third-part repos not 
incrementing with the Fedora version isn't release blocking...



Or the fact that Fedora breaks third-party software by doing things few, 
if any, Linux distro do like running X. Org as non-root?





josh
___
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] 389 DS nightly 2020-04-30 - 88% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/04/30/report-389-ds-base-1.4.4.1-20200429gitc7da66e.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: Retired packages in Fedora are now disabled in bugzilla

[Michel Alexandre Salim]

On 4/29/20 5:26 PM, Kevin Fenzi wrote:

It seems that if I try and file a bug against 0install, I still get to pick
all of 30, 31, 32, and rawhide under Version. Is this expected?


Unfortunately yes. Bugzilla can only disable a component for bugs, not
specific versions of a component.


If this is a bug I can file a ticket. This is a bugbear -- the package has
"install" in the word and most of the bugs filed against it (and still being
filed) are misclassified from Anaconda.


Well, when f30 goes eol it should be able to be closed right?


Right, waiting a month is fine. Thanks for confirming this is expected.

--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: Broken %python_provide macro for Koji's epel8-playground target?

[Michel Alexandre Salim]

On 4/29/20 6:58 PM, Michel Alexandre Salim wrote:


 sh-4.4# rpm -q python-rpm-macros
python-rpm-macros-3-37.el8.noarch
```

Is the epel8-playground builder somehow using an different version of 
python-rpm-macros? Happy to file a bug if I know where this should go.


root.log says epel8-playground is fetching python-rpm-macros-3-38, while 
my Mock is using 3-37, but if the CentOS AppStream build is comparable 
to the RHEL build, the only difference is this:


❯ diff -ru 37 38
diff -ru 37/usr/lib/rpm/macros.d/macros.python 
38/usr/lib/rpm/macros.d/macros.python
--- 37/usr/lib/rpm/macros.d/macros.python   2020-04-29 
19:49:02.558205301 -0700
+++ 38/usr/lib/rpm/macros.d/macros.python   2020-04-29 
19:49:13.547141007 -0700

@@ -5,7 +5,7 @@
 # the macro
 %py_build() %{expand:\\\
   CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}" 
LDFLAGS="${LDFLAGS:-${RPM_LD_FLAGS}}"\\\
-  %{__python} %{py_setup} %{?py_setup_args} build 
--executable="%{__python2} %{py_shbang_opts}" %{?*}
+  %{__python} %{py_setup} %{?py_setup_args} build 
--executable="%{__python} %{py_shbang_opts}" %{?*}

   sleep 1
 }

Intrigued,

--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Backports of fixes from F32 -> F31?

[Alexander Ploumistos]

On Thu, Apr 30, 2020 at 3:05 AM Josh Boyer  wrote:
> Perhaps there are other reasons, like some third party software not
> working on F32, for example.  I'm generally curious about how people
> actually use our distributions and what prevents them from just
> drinking from the firehose.

Well, since you've asked…

I am using our cloud images to spin VMs deployed in ~okeanos[0], with
the caveat that VMs spun in the "Global" network are deleted every 6
months. Also, it's not possible to upload custom images, they have to
be created withing the system. I'm sure everyone appreciates how much
fun there is to be had in configuring users, web servers, VPN servers,
digital certificates, SELiniux policies, iptables rules etc. from
scratch twice a year. They offer a tool[1] to make an image of a
running system, which unfortunately is written in Python2. As far as I
can tell, this ties together some technologies for which Fedora/Red
Hat have been upstream (e.g. supermin) with some other homegrown
tools[2]. I had warned them a couple of years ago that Python2 was
going the way of the dodo, but judging from their git instances,
scattered over several different services[3,4], there hasn't been an
attempt to port it to Python3 - not somewhere public at least. This
being an understaffed public organization, I'm not very optimistic.

At some point after an upgrade to F31, I made a huge blunder and lost
my backup F30 images. I tried porting their stack to Python3 myself,
but I realized that it would take me an amount of time that I can't
afford to spend on that, so I rebuilt all of our related packages that
had dropped their python2 bindings and subpackages, namely
python2-virtualenv and a bunch of libvirt and libguestfs stuff. While
this was much less work, it certainly wasn't trivial and I couldn't
get more recent versions of these packages to build in F32 and F33. By
the way, I'm extremely grateful to all you people in the kernel team
for bringing kernel 5.6 to F31 (mainly for wireguard). Anyway, as
things stand right now, I don't think I'll be able to invest the time
and do that whole dance in order to update my images again before F33
or more likely F34. A sort of messy, middle-ground solution would be
to keep around the F31 images indefinitely and upgrade them to newer
versions, while taking backups.

Oh and if anyone can provide me with a low hassle alternative, I'm game.


0. https://okeanos-global.grnet.gr/
1. https://www.synnefo.org/docs/snf-image-creator/latest/index.html
2. https://github.com/grnet/kamaki
3. https://code.grnet.gr/git/snf-image-creator
4. https://github.com/grnet/snf-image-creator/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] EPEL 8 python builds broken

[Orion Poplawski]

python38-rpm-macros brought into EPEL8.2 buildroot causing problems.  See:

https://pagure.io/epel/issue/103

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



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

[EPEL-devel] Broken %python_provide macro for Koji's epel8-playground target?

[Michel Alexandre Salim]

python-mimeparse fails to build in Koji for the epel8-playground target:

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

from build.log (as an aside, Koji often prompts to look at root.log even 
when that's not where the error lies, weird):


  error: line 48: Unknown tag: %python_provide: ERROR: 
python3-mimeparse not recognized.


but builds fine with the same spec for epel8:

  https://koji.fedoraproject.org/koji/buildinfo?buildID=1492466

Interestingly, building in mock with the epelplayground-8-x86_64 
configuration works!


fedpkg srpm
mock -r epelplayground-8-x86_64 ./python-mimeparse-1.6.0-13.el8.src.rpm

In Mock, the macro expansion works fine:

```
 sh-4.4# rpm -E '%python_provide python3-mimeparse'

 sh-4.4# rpm -q python-rpm-macros
python-rpm-macros-3-37.el8.noarch
```

Is the epel8-playground builder somehow using an different version of 
python-rpm-macros? Happy to file a bug if I know where this should go.


Thanks,

--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Lloyd Kvam]

On Thu, 2020-04-30 at 00:38 +0200, Miro Hrončok wrote:
> On 29. 04. 20 21:42, Lloyd Kvam wrote:
> > > What you say is true. I still don't agree that "python3.9" as a package 
> > > name
> > > annoys humans.
> > 
> > I am not a package pro, but simply reading along as an interested human 
> > user. To me, adding
> > periods in package names can be confusing.
> 
> My sentence was about "python3.9" not being more annoying than "python-3.9".
> 
> I wonder, why do you consider periods in names confusing?

It's mostly when I am trying to relate program names, package names, and 
package file names.
And I am also using Ubuntu which has its own Debian quirks and many dots. I'll 
adjust.

> 
> We have around ~100 source package names with dot. Most of them have 
> versions, e.g.:

I know. I am not sure that's an argument for more dots. We're only one hundred 
or so names from
being dot-free would be an alternate take.

> 
> clang9.0
> dotnet3.1
> freerdp1.2
> llvm5.0
> llvm6.0
> llvm9.0
> jboss-jsf-2.1-api
> jboss-jsf-2.2-api
> jboss-jsp-2.2-api
> jboss-jsp-2.3-api
> 
> Some use dot as a separator, e.g.:
> 
> R-R.utils
> R-data.table
> R-futile.logger
> R-futile.options
> R-gamlss.dist
> R-lambda.r
> R-statnet.common
> openoffice.org-diafilter
> python-boolean.py
> 
Why openoffice.org-diafilter rather than openoffice-diafilter?

Most days I can blissfully type dnf upgrade and I'm fairly oblivious to all the 
effort that
goes into making this work. Watching a list like this lets me see the hard work 
that goes into
making my life much easier.

> > I will adjust to whatever you decide to do, and I am not informed enough to 
> > want a vote in
> > how
> > this decision comes down, but I do not see an advantage to this sort of 
> > change.
> 
> The biggest advantage I see is getting closer to upstream.

Which is more important than my aversion to dots. I'll say again that I will 
adjust as
necessary. Make the decision that will work for you.

And thanks for all your efforts packaging up so much great software.



> The command that the user executes is "python3.9", not "python39".
> 
> I know no other place in the Python ecosystem where Python 3.9 is called 
> "python39" than the names of RPM packages (or other Linux distro packages).
> 
> I've googled "python36", "python37" etc. and all I could find was 
> Fedora/RHEL/CentOS related (or AUR). We have invented that naming ourselves 
> and 
> we don't like being different :)
> 
> (There is the "py39" short identifier used e.g. in tox, but not "python39".)
> 
-- 
Lloyd Kvam
Venix
DLSLUG/GNHLUG library
http://dlslug.org/library.html
http://www.librarything.com/catalog/dlslug
http://www.librarything.com/catalog/dlslug=stamp
http://www.librarything.com/rss/recent/dlslug


___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org

Re: Backports of fixes from F32 -> F31?

[Josh Boyer]

On Wed, Apr 29, 2020 at 5:20 PM Adam Williamson
 wrote:
>
> On Wed, 2020-04-29 at 16:59 -0400, Josh Boyer wrote:
> > On Wed, Apr 29, 2020 at 4:24 PM Alex Scheel  wrote:
> > > Let's try this with the right Florian...
> > >
> > >
> > > Sorry!
> > >
> > > - Original Message -
> > > > From: "Alex Scheel" 
> > > > To: "Florian Weimer" 
> > > > Cc: "Development discussions related to Fedora" 
> > > > 
> > > > Sent: Wednesday, April 29, 2020 4:02:48 PM
> > > > Subject: Backports of fixes from F32 -> F31?
> > > >
> > > > Hi Florian,
> > > >
> > > > I've hit numerous bugs in GNOME in F31. Some of these are fixed in F32,
> > > > such as this one against mutter:
> > > >
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1770296
> > > >
> > > >
> > > > Could we get some of these fixes backported? I've not heard from you on
> > > > this bug at all, despite a needinfo request since March.
> >
> > Just a curious observation/question.  Backports can often be time
> > consuming and expensive.  Is there something preventing you from
> > upgrading to Fedora 32?
>
> I don't know about Alex, but in general, upgrading can also be time

That's why I was asking Alex :)

> consuming and expensive, so some of our users prefer to only upgrade
> every second release. There will be people who will keep running 31
> until 33 comes out.

Sure, that's valid.  Although for installations contained to just
Fedora content, the upgrade from release to release has been downright
boring (that's a good thing).  It's almost equivalent to a reboot.

Perhaps there are other reasons, like some third party software not
working on F32, for example.  I'm generally curious about how people
actually use our distributions and what prevents them from just
drinking from the firehose.

josh
___
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 in Fedora are now disabled in bugzilla

[Kevin Fenzi]

On Wed, Apr 29, 2020 at 02:06:06PM -0700, Michel Alexandre Salim wrote:
> 
> 
> On 4/29/20 10:14 AM, Pierre-Yves Chibon wrote:
> > Good Morning Everyone,
> > 
> > This is something that was asked a while ago and that we finally tackled. 
> > If a
> > package is retired in Fedora, it will now be "disabled" in bugzilla, 
> > meaning no
> > one can open new bugs against it.
> > 
> > The script doing this ensures that the package is retired on all active 
> > branches
> > before proceeding, so that if the package is retired on master and F32, the
> > component remains enable in bugzilla for F31 (and F30).
> 
> Thank you so much! I have a package in this state (0install):
> - retired in master before F31 is branched
> - no F31 and F32 branch
> - still marked as active for F30
> 
> It seems that if I try and file a bug against 0install, I still get to pick
> all of 30, 31, 32, and rawhide under Version. Is this expected?

Unfortunately yes. Bugzilla can only disable a component for bugs, not
specific versions of a component. 

> If this is a bug I can file a ticket. This is a bugbear -- the package has
> "install" in the word and most of the bugs filed against it (and still being
> filed) are misclassified from Anaconda.

Well, when f30 goes eol it should be able to be closed right?

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

[EPEL-devel] Re: epel8-playground target ignores build overrides?

[Michel Alexandre Salim]

On 4/29/20 4:12 PM, Michel Alexandre Salim wrote:

On 4/29/20 3:06 AM, Petr Pisar wrote:

That's probably because of Carl George  deleted the
package.cfg configuration from epel8 branch to mirror the builds into
epel8-buildroot:

commit dd46fcc88a92241e2aa776208cf7ef0dddbab541
Author: Carl George 
Date:   Fri Apr 24 01:06:33 2020 -0500

 Revert ""Adding package.cfg file""

 This reverts commit 6a8c5775eb802cc8acfb93dfbe7e00d8e92a24a3.

Ah indeed. Carl was trying to make it easier to merge changes from 
master and wanted to back out my diff that erroneously stripped the 
changelog, but package.cfg should probably stay there.


I'm restoring that commit.

Digging deeper -- now python-testtools doesn't build in epel8-playground 
because python-testscenarios somehow is missing an epel8-playground 
branch. Oh joy.


I reissued `fedpkg request-branch` and that somehow generates *two* 
tickets and I had to close the epel8 one since the branch already 
exists. Hoping this works:


  https://pagure.io/releng/fedora-scm-requests/issue/24661

Thanks,

--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Adam Williamson]

On Thu, 2020-04-30 at 01:10 +0200, Miro Hrončok wrote:
> On 30. 04. 20 1:07, Neal Gompa wrote:
> > > my usual mistake is where I do a stupid programming and do something like
> > > 
> > > ls -1 | awk '{split($0,a,"."); print a[1]}' | whatever I needed for just 
> > > the names of rpms
> > > 
> > > which for most packages will give me the Name-Ver[.sion removed]. it is 
> > > lazy script programming but it works often enough that my brain wants it 
> > > to work all the time than doing something like
> > > 
> > > ls -1 *rpm | xargs rpm --qf='%{NAME}\n' -qp | whatever i needed for just 
> > > the names of the rpms.
> > > 
> > Splitting on the second to last dash of an rpm file name will*always*
> > give you the name on the left side, and the version-release on the
> > right side, so I usually do a split that way.
> 
> I have this in my PATH (called pkgname):
> 
> #!/usr/bin/python3
> import fileinput
> 
> 
> for line in fileinput.input():
>  print('-'.join(line.split('-')[:-2]))

how about:

print(line.rsplit("-", 2)[0])

?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: epel8-playground target ignores build overrides?

[Michel Alexandre Salim]

On 4/29/20 3:06 AM, Petr Pisar wrote:

That's probably because of Carl George  deleted the
package.cfg configuration from epel8 branch to mirror the builds into
epel8-buildroot:

commit dd46fcc88a92241e2aa776208cf7ef0dddbab541
Author: Carl George 
Date:   Fri Apr 24 01:06:33 2020 -0500

 Revert ""Adding package.cfg file""

 This reverts commit 6a8c5775eb802cc8acfb93dfbe7e00d8e92a24a3.

Ah indeed. Carl was trying to make it easier to merge changes from 
master and wanted to back out my diff that erroneously stripped the 
changelog, but package.cfg should probably stay there.


I'm restoring that commit.

Thanks,

--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Miro Hrončok]

On 30. 04. 20 1:07, Neal Gompa wrote:

my usual mistake is where I do a stupid programming and do something like

ls -1 | awk '{split($0,a,"."); print a[1]}' | whatever I needed for just the 
names of rpms

which for most packages will give me the Name-Ver[.sion removed]. it is lazy 
script programming but it works often enough that my brain wants it to work all 
the time than doing something like

ls -1 *rpm | xargs rpm --qf='%{NAME}\n' -qp | whatever i needed for just the 
names of the rpms.


Splitting on the second to last dash of an rpm file name will*always*
give you the name on the left side, and the version-release on the
right side, so I usually do a split that way.


I have this in my PATH (called pkgname):

#!/usr/bin/python3
import fileinput


for line in fileinput.input():
print('-'.join(line.split('-')[:-2]))

--
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: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Neal Gompa]

On Wed, Apr 29, 2020 at 7:04 PM Stephen John Smoogen  wrote:
>
>
>
> On Wed, 29 Apr 2020 at 18:44, Miro Hrončok  wrote:
>>
>> On 29. 04. 20 21:42, Lloyd Kvam wrote:
>> >> What you say is true. I still don't agree that "python3.9" as a package 
>> >> name
>> >> annoys humans.
>> > I am not a package pro, but simply reading along as an interested human 
>> > user. To me, adding
>> > periods in package names can be confusing.
>>
>> My sentence was about "python3.9" not being more annoying than "python-3.9".
>>
>> I wonder, why do you consider periods in names confusing?
>>
>> We have around ~100 source package names with dot. Most of them have 
>> versions, e.g.:
>>
>> clang9.0
>
>
> The standard confusing part is if you are used to seeing a . only in the 
> version or release parts.. you scan down and see
>
> dotnet3.1-3.1.2-40
>
> my usual mistake is where I do a stupid programming and do something like
>
> ls -1 | awk '{split($0,a,"."); print a[1]}' | whatever I needed for just the 
> names of rpms
>
> which for most packages will give me the Name-Ver[.sion removed]. it is lazy 
> script programming but it works often enough that my brain wants it to work 
> all the time than doing something like
>
> ls -1 *rpm | xargs rpm --qf='%{NAME}\n' -qp | whatever i needed for just the 
> names of the rpms.
>

Splitting on the second to last dash of an rpm file name will *always*
give you the name on the left side, and the version-release on the
right side, so I usually do a split that way. :)






--
真実はいつも一つ！/ 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

Re: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Stephen John Smoogen]

On Wed, 29 Apr 2020 at 18:44, Miro Hrončok  wrote:

> On 29. 04. 20 21:42, Lloyd Kvam wrote:
> >> What you say is true. I still don't agree that "python3.9" as a package
> name
> >> annoys humans.
> > I am not a package pro, but simply reading along as an interested human
> user. To me, adding
> > periods in package names can be confusing.
>
> My sentence was about "python3.9" not being more annoying than
> "python-3.9".
>
> I wonder, why do you consider periods in names confusing?
>
> We have around ~100 source package names with dot. Most of them have
> versions, e.g.:
>
> clang9.0
>

The standard confusing part is if you are used to seeing a . only in the
version or release parts.. you scan down and see

dotnet3.1-3.1.2-40

my usual mistake is where I do a stupid programming and do something like

ls -1 | awk '{split($0,a,"."); print a[1]}' | whatever I needed for just
the names of rpms

which for most packages will give me the Name-Ver[.sion removed]. it is
lazy script programming but it works often enough that my brain wants it to
work all the time than doing something like

ls -1 *rpm | xargs rpm --qf='%{NAME}\n' -qp | whatever i needed for just
the names of the rpms.



> dotnet3.1
> freerdp1.2
> llvm5.0
> llvm6.0
> llvm9.0
> jboss-jsf-2.1-api
> jboss-jsf-2.2-api
> jboss-jsp-2.2-api
> jboss-jsp-2.3-api
>
> Some use dot as a separator, e.g.:
>
> R-R.utils
> R-data.table
> R-futile.logger
> R-futile.options
> R-gamlss.dist
> R-lambda.r
> R-statnet.common
> openoffice.org-diafilter
> python-boolean.py
>
>
> > I will adjust to whatever you decide to do, and I am not informed enough
> to want a vote in how
> > this decision comes down, but I do not see an advantage to this sort of
> change.
>
> The biggest advantage I see is getting closer to upstream.
>
> The command that the user executes is "python3.9", not "python39".
>
> I know no other place in the Python ecosystem where Python 3.9 is called
> "python39" than the names of RPM packages (or other Linux distro packages).
>
> I've googled "python36", "python37" etc. and all I could find was
> Fedora/RHEL/CentOS related (or AUR). We have invented that naming
> ourselves and
> we don't like being different :)
>
> (There is the "py39" short identifier used e.g. in tox, but not
> "python39".)
>
> --
> 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
>


-- 
Stephen J Smoogen.
___
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

Non-responsive maintainer check for hubbitus

[David Schwörer]

Hi,

Does anybody know how to contact Pavel Alexeev (fas: hubbitus) ?

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

Last comment on the most recent ticket on bugzilla:
   #1737349 2019-09-08 pahan
   #1215344 2016-01-01 pahan
   #1200038 2015-10-04 pahan
   #1130101 2014-09-09 pahan

List of open bugs:
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=pahan%40hubbitus.info_to1=1=substring_id=11024552_format=advanced

Kind Regards,
David
___
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: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Miro Hrončok]

On 29. 04. 20 21:42, Lloyd Kvam wrote:

What you say is true. I still don't agree that "python3.9" as a package name
annoys humans.

I am not a package pro, but simply reading along as an interested human user. 
To me, adding
periods in package names can be confusing.


My sentence was about "python3.9" not being more annoying than "python-3.9".

I wonder, why do you consider periods in names confusing?

We have around ~100 source package names with dot. Most of them have versions, 
e.g.:

clang9.0
dotnet3.1
freerdp1.2
llvm5.0
llvm6.0
llvm9.0
jboss-jsf-2.1-api
jboss-jsf-2.2-api
jboss-jsp-2.2-api
jboss-jsp-2.3-api

Some use dot as a separator, e.g.:

R-R.utils
R-data.table
R-futile.logger
R-futile.options
R-gamlss.dist
R-lambda.r
R-statnet.common
openoffice.org-diafilter
python-boolean.py



I will adjust to whatever you decide to do, and I am not informed enough to 
want a vote in how
this decision comes down, but I do not see an advantage to this sort of change.


The biggest advantage I see is getting closer to upstream.

The command that the user executes is "python3.9", not "python39".

I know no other place in the Python ecosystem where Python 3.9 is called 
"python39" than the names of RPM packages (or other Linux distro packages).


I've googled "python36", "python37" etc. and all I could find was 
Fedora/RHEL/CentOS related (or AUR). We have invented that naming ourselves and 
we don't like being different :)


(There is the "py39" short identifier used e.g. in tox, but not "python39".)

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org

Re: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Miro Hrončok]

On 29. 04. 20 21:42, Lloyd Kvam wrote:

What you say is true. I still don't agree that "python3.9" as a package name
annoys humans.

I am not a package pro, but simply reading along as an interested human user. 
To me, adding
periods in package names can be confusing.


My sentence was about "python3.9" not being more annoying than "python-3.9".

I wonder, why do you consider periods in names confusing?

We have around ~100 source package names with dot. Most of them have versions, 
e.g.:

clang9.0
dotnet3.1
freerdp1.2
llvm5.0
llvm6.0
llvm9.0
jboss-jsf-2.1-api
jboss-jsf-2.2-api
jboss-jsp-2.2-api
jboss-jsp-2.3-api

Some use dot as a separator, e.g.:

R-R.utils
R-data.table
R-futile.logger
R-futile.options
R-gamlss.dist
R-lambda.r
R-statnet.common
openoffice.org-diafilter
python-boolean.py



I will adjust to whatever you decide to do, and I am not informed enough to 
want a vote in how
this decision comes down, but I do not see an advantage to this sort of change.


The biggest advantage I see is getting closer to upstream.

The command that the user executes is "python3.9", not "python39".

I know no other place in the Python ecosystem where Python 3.9 is called 
"python39" than the names of RPM packages (or other Linux distro packages).


I've googled "python36", "python37" etc. and all I could find was 
Fedora/RHEL/CentOS related (or AUR). We have invented that naming ourselves and 
we don't like being different :)


(There is the "py39" short identifier used e.g. in tox, but not "python39".)

--
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: Retired packages in Fedora are now disabled in bugzilla

[Miro Hrončok]

On 30. 04. 20 0:14, Miro Hrončok wrote:

On 29. 04. 20 21:11, Pierre-Yves Chibon wrote:

On Wed, Apr 29, 2020 at 08:25:42PM +0200, Miro Hrončok wrote:

On 29. 04. 20 20:24, Pierre-Yves Chibon wrote:
We may need/want to track this in another script than this one. Could you 
open a

ticket for this? I know there is some automation once a package is retired, so
that may be one place where we could do this.
Or we'll have to find another place for this.


I can. What tracker, infra or releng?


Either one is fine, pick your favorite one :)


Oh now, if I pick infra, will releng like me less?


Joking, joking, only to realize I already picked releng 10 months ago:

https://pagure.io/releng/issue/8478

Oh look, there is a code in there, I must have been on fire that day.

--
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: Retired packages in Fedora are now disabled in bugzilla

[Miro Hrončok]

On 29. 04. 20 21:11, Pierre-Yves Chibon wrote:

On Wed, Apr 29, 2020 at 08:25:42PM +0200, Miro Hrončok wrote:

On 29. 04. 20 20:24, Pierre-Yves Chibon wrote:

We may need/want to track this in another script than this one. Could you open a
ticket for this? I know there is some automation once a package is retired, so
that may be one place where we could do this.
Or we'll have to find another place for this.


I can. What tracker, infra or releng?


Either one is fine, pick your favorite one :)


Oh now, if I pick infra, will releng like me less?

--
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: Block discard on more things

[Chris Adams]

Once upon a time, James Cassell  said:
> On Tue, Apr 28, 2020, at 6:51 PM, Chris Adams wrote:
> > Now that Fedora 32 has fstrim.timer enabled by default... how about
> > discards for the things that fstrim doesn't get?  Two main things I know
> > of:
> > 
> > - swap: Do discard at swapon time by setting "discard=once" in
> >   /etc/fstab would be somewhat similar to the periodic fstrim call.  I
> >   don't know how much impact the "discard=pages" option might have (the
> >   man page says it is asynchronous, but it might make low-memory
> >   situations worse).
> 
> Seems reasonable.

I guess this would be a change to anaconda (since it writes /etc/fstab)?
Anybody else have any thoughts on this, should I just go file an RFE bug
against anaconda, ??

> > - logical volumes: Set "issue_discards = 1" in /etc/lvm/lvm.conf so that
> >   removed LVs get discarded.
> 
> Could foreclose data recovery in case LV was removed entirely, so I'd leave 
> it to fstrim.timer on the eventual filesystem.

That requires that a filesystem is created in the empty space.  But I
can also see your point in that discarding immediately may be an issue.

I use a script to create a temporary LV on a PV with free PEs and that
supports discard and then remove it with issue_discards=1... would
something like that be sensible to run along side fstrim.timer?

-- 
Chris Adams 
___
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: Backports of fixes from F32 -> F31?

[Adam Williamson]

On Wed, 2020-04-29 at 16:59 -0400, Josh Boyer wrote:
> On Wed, Apr 29, 2020 at 4:24 PM Alex Scheel  wrote:
> > Let's try this with the right Florian...
> > 
> > 
> > Sorry!
> > 
> > - Original Message -
> > > From: "Alex Scheel" 
> > > To: "Florian Weimer" 
> > > Cc: "Development discussions related to Fedora" 
> > > 
> > > Sent: Wednesday, April 29, 2020 4:02:48 PM
> > > Subject: Backports of fixes from F32 -> F31?
> > > 
> > > Hi Florian,
> > > 
> > > I've hit numerous bugs in GNOME in F31. Some of these are fixed in F32,
> > > such as this one against mutter:
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1770296
> > > 
> > > 
> > > Could we get some of these fixes backported? I've not heard from you on
> > > this bug at all, despite a needinfo request since March.
> 
> Just a curious observation/question.  Backports can often be time
> consuming and expensive.  Is there something preventing you from
> upgrading to Fedora 32?

I don't know about Alex, but in general, upgrading can also be time
consuming and expensive, so some of our users prefer to only upgrade
every second release. There will be people who will keep running 31
until 33 comes out.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Backports of fixes from F32 -> F31?

[Artem Tim]

You need @fmuellner i suppose. :)
___
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 in Fedora are now disabled in bugzilla

[Michel Alexandre Salim]

On 4/29/20 10:14 AM, Pierre-Yves Chibon wrote:

Good Morning Everyone,

This is something that was asked a while ago and that we finally tackled. If a
package is retired in Fedora, it will now be "disabled" in bugzilla, meaning no
one can open new bugs against it.

The script doing this ensures that the package is retired on all active branches
before proceeding, so that if the package is retired on master and F32, the
component remains enable in bugzilla for F31 (and F30).


Thank you so much! I have a package in this state (0install):
- retired in master before F31 is branched
- no F31 and F32 branch
- still marked as active for F30

It seems that if I try and file a bug against 0install, I still get to 
pick all of 30, 31, 32, and rawhide under Version. Is this expected?


If this is a bug I can file a ticket. This is a bugbear -- the package 
has "install" in the word and most of the bugs filed against it (and 
still being filed) are misclassified from Anaconda.


Thanks,

--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
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: Backports of fixes from F32 -> F31?

[Josh Boyer]

On Wed, Apr 29, 2020 at 4:24 PM Alex Scheel  wrote:
>
> Let's try this with the right Florian...
>
>
> Sorry!
>
> - Original Message -
> > From: "Alex Scheel" 
> > To: "Florian Weimer" 
> > Cc: "Development discussions related to Fedora" 
> > 
> > Sent: Wednesday, April 29, 2020 4:02:48 PM
> > Subject: Backports of fixes from F32 -> F31?
> >
> > Hi Florian,
> >
> > I've hit numerous bugs in GNOME in F31. Some of these are fixed in F32,
> > such as this one against mutter:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1770296
> >
> >
> > Could we get some of these fixes backported? I've not heard from you on
> > this bug at all, despite a needinfo request since March.

Just a curious observation/question.  Backports can often be time
consuming and expensive.  Is there something preventing you from
upgrading to Fedora 32?

josh
___
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: Backports of fixes from F32 -> F31?

[Florian Weimer]

* Alex Scheel:

> Hi Florian,
>
> I've hit numerous bugs in GNOME in F31. Some of these are fixed in F32,
> such as this one against mutter:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1770296
>
>
> Could we get some of these fixes backported? I've not heard from you on
> this bug at all, despite a needinfo request since March.

I'm another Florian.  I'm not involved in GNOME development at all,
sorry.

Florian
___
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 51061 - unable to set sslVersionMin to TLS1.0

[Mark Reynolds]

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

--

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 in Fedora are now disabled in bugzilla

[Pierre-Yves Chibon]

On Wed, Apr 29, 2020 at 10:24:03PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> Hi!
> 
> On Wednesday, 29 April 2020 at 19:14, Pierre-Yves Chibon wrote:
> > Good Morning Everyone,
> > 
> > This is something that was asked a while ago and that we finally tackled. 
> > If a
> > package is retired in Fedora, it will now be "disabled" in bugzilla, 
> > meaning no
> > one can open new bugs against it.
> 
> What's the process of enabling bugzilla back if a package is unretired?

It should be automated since it will appear as active in Fedora (in PDC to be
exact), so the script should notice that the is_active status in bugzilla
differs from the retire status in Fedora and adjust accordingly.


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: Retired packages in Fedora are now disabled in bugzilla

[Dominik 'Rathann' Mierzejewski]

Hi!

On Wednesday, 29 April 2020 at 19:14, Pierre-Yves Chibon wrote:
> Good Morning Everyone,
> 
> This is something that was asked a while ago and that we finally tackled. If a
> package is retired in Fedora, it will now be "disabled" in bugzilla, meaning 
> no
> one can open new bugs against it.

What's the process of enabling bugzilla back if a package is unretired?

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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: Backports of fixes from F32 -> F31?

[Alex Scheel]

Let's try this with the right Florian...


Sorry!

- Original Message -
> From: "Alex Scheel" 
> To: "Florian Weimer" 
> Cc: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, April 29, 2020 4:02:48 PM
> Subject: Backports of fixes from F32 -> F31?
> 
> Hi Florian,
> 
> I've hit numerous bugs in GNOME in F31. Some of these are fixed in F32,
> such as this one against mutter:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1770296
> 
> 
> Could we get some of these fixes backported? I've not heard from you on
> this bug at all, despite a needinfo request since March.
> 
> 
> Thanks,
> 
> - Alex
> ___
> 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

Backports of fixes from F32 -> F31?

[Alex Scheel]

Hi Florian,

I've hit numerous bugs in GNOME in F31. Some of these are fixed in F32,
such as this one against mutter:

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


Could we get some of these fixes backported? I've not heard from you on
this bug at all, despite a needinfo request since March.


Thanks,

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

Re: RFC: Feature macros (aka USE flags)

[Colin Walters]

On Mon, Apr 27, 2020, at 7:19 AM, Petr Šabata wrote:

> Details in the gist:
> https://gist.github.com/contyk/0f0585c57976ca18a293b3566408

How about s/use/globalbuildopt/ ?

___
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: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Lloyd Kvam]

On Wed, 2020-04-29 at 19:57 +0200, Miro Hrončok wrote:
> What you say is true. I still don't agree that "python3.9" as a package name 
> annoys humans.

I am not a package pro, but simply reading along as an interested human user. 
To me, adding
periods in package names can be confusing. 

I will adjust to whatever you decide to do, and I am not informed enough to 
want a vote in how
this decision comes down, but I do not see an advantage to this sort of change.

[also I am not subscribed to all of the lists where emails are getting sent]

-- 
Lloyd Kvam
Venix
DLSLUG/GNHLUG library
http://dlslug.org/library.html
http://www.librarything.com/catalog/dlslug
http://www.librarything.com/catalog/dlslug=stamp
http://www.librarything.com/rss/recent/dlslug


___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org

Re: Retired packages in Fedora are now disabled in bugzilla

[Pierre-Yves Chibon]

On Wed, Apr 29, 2020 at 08:25:42PM +0200, Miro Hrončok wrote:
> On 29. 04. 20 20:24, Pierre-Yves Chibon wrote:
> > We may need/want to track this in another script than this one. Could you 
> > open a
> > ticket for this? I know there is some automation once a package is retired, 
> > so
> > that may be one place where we could do this.
> > Or we'll have to find another place for this.
> 
> I can. What tracker, infra or releng?

Either one is fine, pick your favorite one :)


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 32 is available now!

[Matthew Miller]

On Wed, Apr 29, 2020 at 05:57:48PM +0200, Miroslav Suchý wrote:
> In fact, we do that in branching time. And you can enable building for F32
> in settings. And if you check the "Follow branching" option in settings,
> then we automatically enable new version of Fedora for you at branching
> time.

Thanks Miroslav! Much appreciated!

-- 
Matthew Miller

Fedora Project Leader
___
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: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Nicolas Mailhot via devel]

Le mercredi 29 avril 2020 à 19:57 +0200, Miro Hrončok a écrit :
> And I don't understand what kind of automation are we
> talking about that needs to parse the "3.9" part and figure out it is
> a "qualifier".

It mostly hits you in the package creation code. The Go macro code will
just dump -qualifier- in the name without bothering with arcane testing
for example. 

-- 
Nicolas Mailhot
___
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 in Fedora are now disabled in bugzilla

[Miro Hrončok]

On 29. 04. 20 20:24, Pierre-Yves Chibon wrote:

We may need/want to track this in another script than this one. Could you open a
ticket for this? I know there is some automation once a package is retired, so
that may be one place where we could do this.
Or we'll have to find another place for this.


I can. What tracker, infra or releng?

--
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: Retired packages in Fedora are now disabled in bugzilla

[Pierre-Yves Chibon]

On Wed, Apr 29, 2020 at 07:32:01PM +0200, Miro Hrončok wrote:
> On 29. 04. 20 19:14, Pierre-Yves Chibon wrote:
> > This is something that was asked a while ago and that we finally tackled. 
> > If a
> > package is retired in Fedora, it will now be "disabled" in bugzilla, 
> > meaning no
> > one can open new bugs against it.
> 
> Thanks!
> 
> Can we please also close all the open Bugzillas for a specific version when
> a package is retired on that version? I do it when I retire packages because
> they were orphaned for 6+, but if they are retired for other reasons, the
> Bugzillas remain open.

We may need/want to track this in another script than this one. Could you open a
ticket for this? I know there is some automation once a package is retired, so
that may be one place where we could do this.
Or we'll have to find another place for this.

Thanks,
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: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Nicolas Mailhot via devel]

Le mercredi 29 avril 2020 à 19:43 +0200, Miro Hrončok a écrit :
> On 29. 04. 20 19:37, Nicolas Mailhot wrote:
> > Le mercredi 29 avril 2020 à 19:18 +0200, Miro Hrončok a écrit :
> > 
> > > All [compat packages] MUST include the base name suffixed by
> > > either:
> > Well we are not creating a compat package here and not adding an
> > hyphen
> > creates an artificial numeric/non numeric special case.
> > 
> > But, I see someone formalised the special case in compat
> > guidelines,
> > ignoring distribution history that showed versionned naming could
> > easily be done without special cases that annoys humans and break
> > automation and scripts for years afterwards, therefore, do as you
> > want.
> 
> I don't agree that "python3.9" as a package name annoys humans or
> break  automation scripts. How does it?

As soon as you have a different naming convention for numeric and non
numeric qualifiers all the code that manipulates your package names
must test if the qualifier is numeric or not, to add the hyphen or not.

It is much simpler to just assume - everywhere, without
testing  in any way.

That’s why

%package XXX

will create foo-XXX by default, and not ask you to split hairs and test
if XXX is numeric or not (yes the hyphen separator is built in rpm core
logic)

-- 
Nicolas Mailhot
___
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: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Nicolas Mailhot via devel]

Le mercredi 29 avril 2020 à 19:57 +0200, Miro Hrončok a écrit :

> Such automation is broken anyway, because it cannot tell if python-
> requests is a 
> Python library or a Python "qualifier".

It is no more broken than automation that "knows" test means 
 is a version. Of course before you apply such automation you
start by filtering package names in some way. What you do *not* want to
do is use two different processing patterns instead of one.

-- 
Nicolas Mailhot
___
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: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Miro Hrončok]

On 29. 04. 20 19:50, Nicolas Mailhot wrote:

I don't agree that "python3.9" as a package name annoys humans or
break  automation scripts. How does it?

As soon as you have a different naming convention for numeric and non
numeric qualifiers all the code that manipulates your package names
must test if the qualifier is numeric or not, to add the hyphen or not.

It is much simpler to just assume - everywhere, without
testing  in any way.

That’s why

%package XXX

will create foo-XXX by default, and not ask you to split hairs and test
if XXX is numeric or not (yes the hyphen separator is built in rpm core
logic)


What you say is true. I still don't agree that "python3.9" as a package name 
annoys humans. And I don't understand what kind of automation are we talking 
about that needs to parse the "3.9" part and figure out it is a "qualifier".


Such automation is broken anyway, because it cannot tell if python-requests is a 
Python library or a Python "qualifier".


--
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: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Miro Hrončok]

On 29. 04. 20 19:50, Nicolas Mailhot wrote:

I don't agree that "python3.9" as a package name annoys humans or
break  automation scripts. How does it?

As soon as you have a different naming convention for numeric and non
numeric qualifiers all the code that manipulates your package names
must test if the qualifier is numeric or not, to add the hyphen or not.

It is much simpler to just assume - everywhere, without
testing  in any way.

That’s why

%package XXX

will create foo-XXX by default, and not ask you to split hairs and test
if XXX is numeric or not (yes the hyphen separator is built in rpm core
logic)


What you say is true. I still don't agree that "python3.9" as a package name 
annoys humans. And I don't understand what kind of automation are we talking 
about that needs to parse the "3.9" part and figure out it is a "qualifier".


Such automation is broken anyway, because it cannot tell if python-requests is a 
Python library or a Python "qualifier".


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org

Re: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Miro Hrončok]

On 29. 04. 20 19:37, Nicolas Mailhot wrote:

Le mercredi 29 avril 2020 à 19:18 +0200, Miro Hrončok a écrit :


All [compat packages] MUST include the base name suffixed by either:

Well we are not creating a compat package here and not adding an hyphen
creates an artificial numeric/non numeric special case.

But, I see someone formalised the special case in compat guidelines,
ignoring distribution history that showed versionned naming could
easily be done without special cases that annoys humans and break
automation and scripts for years afterwards, therefore, do as you want.


I don't agree that "python3.9" as a package name annoys humans or break 
automation scripts. How does it?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Miro Hrončok]

On 29. 04. 20 19:37, Nicolas Mailhot wrote:

Le mercredi 29 avril 2020 à 19:18 +0200, Miro Hrončok a écrit :


All [compat packages] MUST include the base name suffixed by either:

Well we are not creating a compat package here and not adding an hyphen
creates an artificial numeric/non numeric special case.

But, I see someone formalised the special case in compat guidelines,
ignoring distribution history that showed versionned naming could
easily be done without special cases that annoys humans and break
automation and scripts for years afterwards, therefore, do as you want.


I don't agree that "python3.9" as a package name annoys humans or break 
automation scripts. How does it?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org

Re: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Nicolas Mailhot via devel]

Le mercredi 29 avril 2020 à 19:18 +0200, Miro Hrončok a écrit :

> All [compat packages] MUST include the base name suffixed by either:

Well we are not creating a compat package here and not adding an hyphen
creates an artificial numeric/non numeric special case.

But, I see someone formalised the special case in compat guidelines,
ignoring distribution history that showed versionned naming could
easily be done without special cases that annoys humans and break
automation and scripts for years afterwards, therefore, do as you want.

-- 
Nicolas Mailhot
___
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 in Fedora are now disabled in bugzilla

[Miro Hrončok]

On 29. 04. 20 19:14, Pierre-Yves Chibon wrote:

This is something that was asked a while ago and that we finally tackled. If a
package is retired in Fedora, it will now be "disabled" in bugzilla, meaning no
one can open new bugs against it.


Thanks!

Can we please also close all the open Bugzillas for a specific version when a 
package is retired on that version? I do it when I retire packages because they 
were orphaned for 6+, but if they are retired for other reasons, the Bugzillas 
remain open.


--
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: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Kalev Lember]

On Wed, Apr 29, 2020 at 4:28 PM Tomas Orsava  wrote:

> Hello everyone.
> I’m working on a change to rename pythonXY packages to pythonX.Y, e.g.
> python39 to python3.9.
>

Changing it to pythonX.Y makes sense I think. It's likely going to be a lot
of work for little gain, but I appreciate that you are taking it on!
Cleanups like this make the packaging much nicer to use in the future.

+1 from me.

-- 
Kalev
___
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: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Miro Hrončok]

On 29. 04. 20 18:51, Neal Gompa wrote:

What do you think? Do you foresee any problems?

I'm good with this plan, except for one thing I thought of we need to
address: How do we do comparisons for python versions?


In spec %ifs? I've been doing it with %python3_version_nodots. That'll work 
until there is 3.10 and later 4.0. At that point, it will break because 310 > 
40. If there is Python 4, this will be the smallest of our problems.



Will we still have a %python_version_nodots macro so that we can do
integer comparisons?


Yes. The macro has the Python version without dots. It has nothing to do with 
package names and never had.



I know that people have been abusing the
%python3_pkgversion macro for doing this (which you shouldn't be
doing!)


Oh my gods. That cannot even work, %python3_pkgversion is always 3 in Fedora. 
Are you talking EPEL? EPEL Python packaging is a spaghetti western, if people do 
this, they are on their own.


I've recently seen this in Fedora spec:

  pytest-%{python3_pkgversion}

Well, it works. In the same way this works:

  %if %{fedora} > %{python3_pkgversion}0

Don't do this. Ever.


so we need an official guideline for how to do those
comparisons.


Good point. I'll take a note.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-de...@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-de...@lists.fedoraproject.org

Re: Retired packages in Fedora are now disabled in bugzilla

[Sérgio Basto]

On Wed, 2020-04-29 at 19:19 +0200, Miro Hrončok wrote:
> On 29. 04. 20 19:14, Pierre-Yves Chibon wrote:
> > Good Morning Everyone,
> > 
> > This is something that was asked a while ago and that we finally
> > tackled. If a
> > package is retired in Fedora, it will now be "disabled" in
> > bugzilla, meaning no
> > one can open new bugs against it.
> > 
> > The script doing this ensures that the package is retired on all
> > active branches
> > before proceeding, so that if the package is retired on master and
> > F32, the
> > component remains enable in bugzilla for F31 (and F30).
> 
> [EDITCOMP] Fedora EPEL/python36  is_active changed from `True` to
> `False`
> 
> I see EPEL is also included, thanks!


Thank you for taking care of the subject, it is an awesome feature , it
will bring much organization .

Best regards,
--
Sérgio M. B.
___
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 in Fedora are now disabled in bugzilla

[Miro Hrončok]

On 29. 04. 20 19:14, Pierre-Yves Chibon wrote:

Good Morning Everyone,

This is something that was asked a while ago and that we finally tackled. If a
package is retired in Fedora, it will now be "disabled" in bugzilla, meaning no
one can open new bugs against it.

The script doing this ensures that the package is retired on all active branches
before proceeding, so that if the package is retired on master and F32, the
component remains enable in bugzilla for F31 (and F30).


[EDITCOMP] Fedora EPEL/python36  is_active changed from `True` to `False`

I see EPEL is also included, thanks!

--
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: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Miro Hrončok]

On 29. 04. 20 18:41, Nicolas Mailhot via devel wrote:

Le mercredi 29 avril 2020 à 16:27 +0200, Tomas Orsava a écrit :
Hi,


I’m working on a change to rename pythonXY packages to pythonX.Y,
e.g. python39 to python3.9.

Motivation:
When you install an additional Python interpreter, the command that
runs it contains a dot (e.g. /usr/bin/python3.9) but the package name
does not (e.g. dnf install python39).


If you go into cleanup & renaming mode, please add a '-' between python
and the version, so it is consistent with the way versionned names have
been done in the distribution for a long time.

For example, I see we have a
java-1.8.0-openjdk
java-11-openjdk
java-latest-openjdk

As you see the magic '-' makes it possible to use non-numeric version
qualifiers later without breaking naming conventions.


No, sorry.

Reason 1:

The command is named pythonX.Y, not python-X.Y and we want this consistent.

Reason 2:

The packaging guidelines say:

"""
All [compat packages] MUST include the base name suffixed by either:

* The package version, which SHOULD include the periods present in the original 
version. [...] If the base package name does not end with a digit, the version 
MUST be *directly appended* to the package name with *no intervening separator*.


* a hyphen ("-") followed by a descriptive suffix such as "stable" which 
provides some indication as to the nature of the packaged version.

"""

https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple


--
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: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Miro Hrončok]

On 29. 04. 20 18:41, Nicolas Mailhot via devel wrote:

Le mercredi 29 avril 2020 à 16:27 +0200, Tomas Orsava a écrit :
Hi,


I’m working on a change to rename pythonXY packages to pythonX.Y,
e.g. python39 to python3.9.

Motivation:
When you install an additional Python interpreter, the command that
runs it contains a dot (e.g. /usr/bin/python3.9) but the package name
does not (e.g. dnf install python39).


If you go into cleanup & renaming mode, please add a '-' between python
and the version, so it is consistent with the way versionned names have
been done in the distribution for a long time.

For example, I see we have a
java-1.8.0-openjdk
java-11-openjdk
java-latest-openjdk

As you see the magic '-' makes it possible to use non-numeric version
qualifiers later without breaking naming conventions.


No, sorry.

Reason 1:

The command is named pythonX.Y, not python-X.Y and we want this consistent.

Reason 2:

The packaging guidelines say:

"""
All [compat packages] MUST include the base name suffixed by either:

* The package version, which SHOULD include the periods present in the original 
version. [...] If the base package name does not end with a digit, the version 
MUST be *directly appended* to the package name with *no intervening separator*.


* a hyphen ("-") followed by a descriptive suffix such as "stable" which 
provides some indication as to the nature of the packaged version.

"""

https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org

Retired packages in Fedora are now disabled in bugzilla

[Pierre-Yves Chibon]

Good Morning Everyone,

This is something that was asked a while ago and that we finally tackled. If a
package is retired in Fedora, it will now be "disabled" in bugzilla, meaning no
one can open new bugs against it.

The script doing this ensures that the package is retired on all active branches
before proceeding, so that if the package is retired on master and F32, the
component remains enable in bugzilla for F31 (and F30).

The script has just completed its first run and disabled quite a few components
(not really surprising considering we had not run this in a long time), but we
wanted to share the list here in case someone spotted some irregularities.

The list can be found at:
https://pingou.fedorapeople.org/disabled_components_in_bugzilla_20200429

Please let us know, either here or via a fedora-infrastructure ticket:
https://pagure.io/fedora-infrastructure/issues if you see any issues in it,
otherwise, enjoy a bugzilla with 4k+ more disabled components across all our
products (Fedora, Fedora EPEL, Fedora Modules...).


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: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Neal Gompa]

On Wed, Apr 29, 2020 at 10:28 AM Tomas Orsava  wrote:
>
> Hello everyone.
> I’m working on a change to rename pythonXY packages to pythonX.Y, e.g. 
> python39 to python3.9.
>
> Motivation:
> When you install an additional Python interpreter, the command that runs it 
> contains a dot (e.g. /usr/bin/python3.9) but the package name does not (e.g. 
> dnf install python39).
> The name without a dot is a technical debt that we carry since (at least) the 
> python26 package in RHEL 5 for consistency. The name with the dot makes much 
> more sense to Red Hat Python maintainers.
> It’s a minor inconsistency, but we'd like to get it right in RHEL, and since 
> RHEL splits off from Fedora, it will be bugging us still in 2030+ unless we 
> fix it now. Especially with the likely coming version 3.10 the package name 
> python310 is confusing. This will also get us in sync with e.g. Debian 
> package names.
>
> Backwards compatibility:
> We plan to create new components in rawhide containing the dot (e.g. 
> python3.9) for all Python interpreters (except soon-to-be-retired python34 
> and python26) and push the git commits from pythnoXY to them to preserve the 
> history.
> The packages will Provide and Obsolete the old name without a dot (e.g. 
> python39). The current packages already provide the name with the dot, so 
> this will be just a switch between real name and virtual provide.
> Therefore any package that depends on these components will continue to work 
> just fine. And in time we’d like to fix all of those to use the new name, 
> which is backwards compatible, because it is already provided now (as a side 
> note, the packages are generally just recommended, not required).
>
> Technical details:
> There has been a recent rawhide-only change to the %python_provide macro that 
> acts on packages named `python3-foo` and adds for them a new Provide 
> `python38-foo`.
> We’d like to change this to Provide `python3.8-foo` instead.
> Since this has been rawhide-only so far, and because there’s no real reason 
> to depend on these provides yet, we don’t expect any breakage.
>
> What do you think? Do you foresee any problems?

I'm good with this plan, except for one thing I thought of we need to
address: How do we do comparisons for python versions? Will we still
have a %python_version_nodots macro so that we can do integer
comparisons? I know that people have been abusing the
%python3_pkgversion macro for doing this (which you shouldn't be
doing!), so we need an official guideline for how to do those
comparisons.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org

Re: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Neal Gompa]

On Wed, Apr 29, 2020 at 10:28 AM Tomas Orsava  wrote:
>
> Hello everyone.
> I’m working on a change to rename pythonXY packages to pythonX.Y, e.g. 
> python39 to python3.9.
>
> Motivation:
> When you install an additional Python interpreter, the command that runs it 
> contains a dot (e.g. /usr/bin/python3.9) but the package name does not (e.g. 
> dnf install python39).
> The name without a dot is a technical debt that we carry since (at least) the 
> python26 package in RHEL 5 for consistency. The name with the dot makes much 
> more sense to Red Hat Python maintainers.
> It’s a minor inconsistency, but we'd like to get it right in RHEL, and since 
> RHEL splits off from Fedora, it will be bugging us still in 2030+ unless we 
> fix it now. Especially with the likely coming version 3.10 the package name 
> python310 is confusing. This will also get us in sync with e.g. Debian 
> package names.
>
> Backwards compatibility:
> We plan to create new components in rawhide containing the dot (e.g. 
> python3.9) for all Python interpreters (except soon-to-be-retired python34 
> and python26) and push the git commits from pythnoXY to them to preserve the 
> history.
> The packages will Provide and Obsolete the old name without a dot (e.g. 
> python39). The current packages already provide the name with the dot, so 
> this will be just a switch between real name and virtual provide.
> Therefore any package that depends on these components will continue to work 
> just fine. And in time we’d like to fix all of those to use the new name, 
> which is backwards compatible, because it is already provided now (as a side 
> note, the packages are generally just recommended, not required).
>
> Technical details:
> There has been a recent rawhide-only change to the %python_provide macro that 
> acts on packages named `python3-foo` and adds for them a new Provide 
> `python38-foo`.
> We’d like to change this to Provide `python3.8-foo` instead.
> Since this has been rawhide-only so far, and because there’s no real reason 
> to depend on these provides yet, we don’t expect any breakage.
>
> What do you think? Do you foresee any problems?

I'm good with this plan, except for one thing I thought of we need to
address: How do we do comparisons for python versions? Will we still
have a %python_version_nodots macro so that we can do integer
comparisons? I know that people have been abusing the
%python3_pkgversion macro for doing this (which you shouldn't be
doing!), so we need an official guideline for how to do those
comparisons.



-- 
真実はいつも一つ！/ 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

Re: Orphaned packages looking for new maintainers (anaconda also affected)

[Michael Catanzaro]

On Wed, Apr 29, 2020 at 11:47 am, Kalev Lember  
wrote:

I agree; it's time to let GConf2 and the rest of the GNOME 2 libraries
go. If anyone disagrees and should pick it up, please only keep it for
F33 and then retire it in F34, so that we don't keep the old baggage 
in

the distro forever.


Well gconf isn't really causing any serious problems. It's not a 
security risk or anything. Applications *should* stop using it, but if 
someone else wants to take ownership of it, I think that's OK.


___
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: Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Nicolas Mailhot via devel]

Le mercredi 29 avril 2020 à 16:27 +0200, Tomas Orsava a écrit :
Hi,

> I’m working on a change to rename pythonXY packages to pythonX.Y,
> e.g. python39 to python3.9.
> 
> Motivation:
> When you install an additional Python interpreter, the command that
> runs it contains a dot (e.g. /usr/bin/python3.9) but the package name
> does not (e.g. dnf install python39).

If you go into cleanup & renaming mode, please add a '-' between python
and the version, so it is consistent with the way versionned names have
been done in the distribution for a long time.

For example, I see we have a 
java-1.8.0-openjdk
java-11-openjdk
java-latest-openjdk

As you see the magic '-' makes it possible to use non-numeric version
qualifiers later without breaking naming conventions.

Regards

-- 
Nicolas Mailhot
___
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 (anaconda also affected)

[Kevin Fenzi]

On Wed, Apr 29, 2020 at 08:02:15AM -0400, Martin Kolman wrote:
> 
> 
> - Original Message -
> > From: "Kevin Fenzi" 
> > To: "Development discussions related to Fedora" 
> > 
> > Sent: Wednesday, April 29, 2020 12:26:46 AM
> > Subject: Re: Orphaned packages looking for new maintainers (anaconda also 
> > affected)
> > 
> > On Tue, Apr 28, 2020 at 11:30:46PM +0200, Dominik 'Rathann' Mierzejewski
> > wrote:
> > > On Tuesday, 28 April 2020 at 22:15, Kevin Fenzi wrote:
> > > [...]
> > > > I'm a bit more concerned with keybinder3. That's needed by blueberry
> > > > which we use in the Xfce spin.
> > > 
> > > I care about blueberry as well, even though I use MATE.
> > > 
> > > > Leigh: You fixed the keybinder3 FTBFS, do you want to take ownership
> > > > too?
> > > > 
> > > > I guess I can take it if no one else wants to...
> > > 
> > > ... but I really wouldn't like to take on another package, I have too
> > > much on my plate maintaining what I have already.
> > 
> > ok. I went ahead and took it.
> Thanks a lot! :)
> > 
> > Co-maintainers welcome
> You can add me as a co-maintainer.

Done.

> (If there is a way to add myself in the distgit UI I have not found it. :P)

Nope. ;( 

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: RFC: Feature macros (aka USE flags)

[Miroslav Suchý]

Dne 29. 04. 20 v 18:07 Miroslav Suchý napsal(a):
> Dne 27. 04. 20 v 13:19 Petr Šabata napsal(a):
>> Based on the recent discussions around %fedora/%rhel macros and ELN,
>> and %bcond generally being confusing to work with, I came up with a
>> distribution-wide feature that defines generic feature keywords and
>> associated helper macros that packages can check in build-time
>> conditionals.
> 
> Can you provide the Suse guidelines please? The words "use", "macros" are 
> terrible for searching.
> I would like to see, how and where your proposal differ. Or if there are any 
> differences at all.


Sorry, I am blind. It is there
  https://devmanual.gentoo.org/general-concepts/use-flags/index.html
and it is inspired by Gentoo and not Suse.
-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RFC: Feature macros (aka USE flags)

[Miroslav Suchý]

Dne 27. 04. 20 v 13:19 Petr Šabata napsal(a):
> Based on the recent discussions around %fedora/%rhel macros and ELN,
> and %bcond generally being confusing to work with, I came up with a
> distribution-wide feature that defines generic feature keywords and
> associated helper macros that packages can check in build-time
> conditionals.

Can you provide the Suse guidelines please? The words "use", "macros" are 
terrible for searching.
I would like to see, how and where your proposal differ. Or if there are any 
differences at all.


-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
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 32 is available now!

[Miroslav Suchý]

Dne 28. 04. 20 v 15:55 Matthew Miller napsal(a):
> It’s here! We’re proud to announce the release of Fedora 32.
> Thanks to the hard work of thousands of Fedora community
> members and contributors, we’re celebrating yet another 
> on-time release!
> 
> Read the official announcement at:
> 
> * https://fedoramagazine.org/announcing-fedora-32/
> 
> or just go ahead and grab it from: 
> 
> * https://getfedora.org/


And because there is always somebody asking me - yes, we already added Fedora 
32 to Copr.

In fact, we do that in branching time. And you can enable building for F32 in 
settings. And if you check the "Follow
branching" option in settings, then we automatically enable new version of 
Fedora for you at branching time.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
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 1829493] New: perl-Text-Aligner-0.16 is available

[bugzilla]

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

Bug ID: 1829493
   Summary: perl-Text-Aligner-0.16 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Text-Aligner
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, jples...@redhat.com,
mmasl...@redhat.com,
perl-de...@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.16
Current version/release in rawhide: 0.15-1.fc33
URL: http://search.cpan.org/dist/Text-Aligner/

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


-- 
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: Orphaned uglify-js

[Jun Aruga]

> >FreeIPA depends on uglify-js to minimize its JS code. Do we have any
> >other alternative that doesn't change meaning of the code?
>
> I quickly hacked on to use python3-rjsmin, seems to work fine for our
> use case.

Okay. It's good to know it.

I tried to suggest bundling your uglify-js in the FreeIPA package
because seeing your solutions. :)

Here is a ticket about one more reason I removed the uglify-js
dependency from rubygem-uglifier.
https://bugzilla.redhat.com/show_bug.cgi?id=1828876
> Currently, the nodejs libraries are so intertwined, it is taking a lot of 
> effort to change the version of any specific nodejs library

Jun

-- 
Jun | He - His - Him
___
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 (anaconda also affected)

[David Cantrell]

I did an epel8 build yesterday.  I've added you to the list of maintainers.
Thanks!

On Mon, Apr 27, 2020 at 03:26:49PM -0500, Martin Jackson wrote:
I would be happy to maintain it -and it looks like it needs an epel8 
build.  (FAS: mhjacks)


Thanks,

Marty

On 4/27/20 2:13 PM, David Cantrell wrote:

On Mon, Apr 27, 2020 at 12:39:38PM +0200, Miro Hrončok wrote:

ckermit orphan   2 weeks ago


I took ownership of this one and have fixed it in rawhide.  If 
anyone really
wants to own this one, just let me know.  I have no problems turning 
it over
to someone else, but if that's no one then I will just maintain it.  
I would

like ckermit to still be available and usable in Fedora.

Thanks,


___
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


--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
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: ckermit?

[Steven A. Falco]

On 4/29/20 4:12 AM, Florian Weimer wrote:

* Steven A. Falco:


I'd like to request a rebuild for F32.  Is it sufficient to request
that here, or is there some other procedure that I should use?


I've merged the F33 change (dropping termcap-devel) and kicked off a new
build.  Please test the update and provide karma
,
so that it can ship to users.


Thanks for building it so quickly!  I've tested it and given it +1 karma.

Steve
___
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: ckermit?

[David Cantrell]

On Wed, Apr 29, 2020 at 10:12:06AM +0200, Florian Weimer wrote:

* Steven A. Falco:


I'd like to request a rebuild for F32.  Is it sufficient to request
that here, or is there some other procedure that I should use?


I've merged the F33 change (dropping termcap-devel) and kicked off a new
build.  Please test the update and provide karma
,
so that it can ship to users.


Thanks.  I took ownership of ckermit too and did a new build for rawhide and
for EPEL-8.

--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
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 uglify-js

[Alexander Bokovoy]

On ke, 29 huhti 2020, Alexander Bokovoy wrote:

On ke, 29 huhti 2020, Jun Aruga wrote:

Hi,

I orphaned the package.
https://src.fedoraproject.org/rpms/uglify-js

because

* I removed the uglify-js dependency from rubygem-uglifier.
* When I asked the co-maintainers, there was no response.
* The difficulty of the management. uglify-js requires nodejs-acorn,
which requires nodejs-rollup, which requires
nodejs-source-map-support, which is orphaned now.
https://src.fedoraproject.org/rpms/nodejs-source-map-support


FreeIPA depends on uglify-js to minimize its JS code. Do we have any
other alternative that doesn't change meaning of the code?


I quickly hacked on to use python3-rjsmin, seems to work fine for our
use case.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
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

Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9)

[Tomas Orsava]

Hello everyone.
I’m working on a change to rename pythonXY packages to pythonX.Y, e.g. 
python39 to python3.9.


*Motivation:*
When you install an additional Python interpreter, the command that runs 
it contains a dot (e.g. /usr/bin/python3.9) but the package name does 
not (e.g. dnf install python39).
The name without a dot is a technical debt that we carry since (at 
least) the python26 package in RHEL 5 for consistency. The name with the 
dot makes much more sense to Red Hat Python maintainers.
It’s a minor inconsistency, but we'd like to get it right in RHEL, and 
since RHEL splits off from Fedora, it will be bugging us still in 2030+ 
unless we fix it now. Especially with the likely coming version 3.10 the 
package name python310 is confusing. This will also get us in sync with 
e.g. Debian package names.


*Backwards compatibility:*
We plan to create new components in rawhide containing the dot (e.g. 
python3.9) for all Python interpreters (except soon-to-be-retired 
python34 and python26) and push the git commits from pythnoXY to them to 
preserve the history.
The packages will Provide and Obsolete the old name without a dot (e.g. 
python39). The current packages already provide the name with the dot, 
so this will be just a switch between real name and virtual provide.
Therefore any package that depends on these components will continue to 
work just fine. And in time we’d like to fix all of those to use the new 
name, which is backwards compatible, because it is already provided now 
(as a side note, the packages are generally just recommended, not required).


*Technical details:*
There has been a recent rawhide-only change to the %python_provide macro 
that acts on packages named `python3-foo` and adds for them a new 
Provide `python38-foo`.

We’d like to change this to Provide `python3.8-foo` instead.
Since this has been rawhide-only so far, and because there’s no real 
reason to depend on these provides yet, we don’t expect any breakage.


What do you think? Do you foresee any problems?
All the best,
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: Orphaned uglify-js

[Alexander Bokovoy]

On ke, 29 huhti 2020, Jun Aruga wrote:

Hi,

I orphaned the package.
https://src.fedoraproject.org/rpms/uglify-js

because

* I removed the uglify-js dependency from rubygem-uglifier.
* When I asked the co-maintainers, there was no response.
* The difficulty of the management. uglify-js requires nodejs-acorn,
which requires nodejs-rollup, which requires
nodejs-source-map-support, which is orphaned now.
 https://src.fedoraproject.org/rpms/nodejs-source-map-support


FreeIPA depends on uglify-js to minimize its JS code. Do we have any
other alternative that doesn't change meaning of the code?


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
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 1829102] perl-CPAN-Perl-Releases-5.20200428 is available

[bugzilla]

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



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


-- 
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 1829102] perl-CPAN-Perl-Releases-5.20200428 is available

[bugzilla]

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



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


-- 
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 1829102] perl-CPAN-Perl-Releases-5.20200428 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
FEDORA-2020-2330b48960 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-2330b48960


-- 
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: Orphaned packages looking for new maintainers (anaconda also affected)

[Martin Kolman]

- Original Message -
> From: "Kevin Fenzi" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, April 29, 2020 12:26:46 AM
> Subject: Re: Orphaned packages looking for new maintainers (anaconda also 
> affected)
> 
> On Tue, Apr 28, 2020 at 11:30:46PM +0200, Dominik 'Rathann' Mierzejewski
> wrote:
> > On Tuesday, 28 April 2020 at 22:15, Kevin Fenzi wrote:
> > [...]
> > > I'm a bit more concerned with keybinder3. That's needed by blueberry
> > > which we use in the Xfce spin.
> > 
> > I care about blueberry as well, even though I use MATE.
> > 
> > > Leigh: You fixed the keybinder3 FTBFS, do you want to take ownership
> > > too?
> > > 
> > > I guess I can take it if no one else wants to...
> > 
> > ... but I really wouldn't like to take on another package, I have too
> > much on my plate maintaining what I have already.
> 
> ok. I went ahead and took it.
Thanks a lot! :)
> 
> Co-maintainers welcome
You can add me as a co-maintainer.
(If there is a way to add myself in the distgit UI I have not found it. :P)
> 
> kevin
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
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

Orphaned uglify-js

[Jun Aruga]

Hi,

I orphaned the package.
https://src.fedoraproject.org/rpms/uglify-js

because

* I removed the uglify-js dependency from rubygem-uglifier.
* When I asked the co-maintainers, there was no response.
* The difficulty of the management. uglify-js requires nodejs-acorn,
which requires nodejs-rollup, which requires
nodejs-source-map-support, which is orphaned now.
  https://src.fedoraproject.org/rpms/nodejs-source-map-support

Cheers,
Jun

-- 
Jun | He - His - Him
___
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 (anaconda also affected)

[Miro Hrončok]

On 29. 04. 20 11:47, Kalev Lember wrote:


GConf2 is orphan, why ? no maintainers or a task force to be removed ?


GConf2 has been deprecated for well over a decade and afaik unmaintained
for nearly half a decade. Thus: please just remove it from your
dependencies and use gsettings instead (the upstream replacement).

Many packages might actually not require it at all: emacs was pulling it
in, but it works just fine without it and with gsettings instead.


Yeah, I am happy to let GConf2 go into the night... thunar-vfs depends
on it, but thats just the old vfs layer Thunar used to use kept around
for compatibility. It should go also.


I agree; it's time to let GConf2 and the rest of the GNOME 2 libraries go. If 
anyone disagrees and should pick it up, please only keep it for F33 and then 
retire it in F34, so that we don't keep the old baggage in the distro forever.


I am afraid that just orphaning the old baggage won't ever get us rid of it.

Here is what I think will happen:

 - people panic, some dependencies are removed
 - people wait 5 weeks hoping somebody picks it up
 - somebody unorphans or unretires it, not being aware of this discussion
 - nothing changes

In couple months, the package FTBFS, the maintainer doesn't have time or 
interest any more, orphans it again.


 - people panic, some dependencies are removed
 - ...

It can take years before eventually, the remaining dependents are not 
interesting to anybody and the package stays retired.


It is a vicious circle. When we want to remove stuff that is still highly 
dependent on, somebody must drive it. I've been there, done that.


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

Fedora-Cloud-31-20200429.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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

Fedora-IoT-32-20200429.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 8/8 (x86_64)

New passes (same test not passed in Fedora-IoT-32-20200428.2):

ID: 588969  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/588969
ID: 588970  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/588970
ID: 588971  Test: x86_64 IoT-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/588971
ID: 588972  Test: x86_64 IoT-dvd_ostree-iso base_reboot_unmount
URL: https://openqa.fedoraproject.org/tests/588972
ID: 588973  Test: x86_64 IoT-dvd_ostree-iso base_selinux
URL: https://openqa.fedoraproject.org/tests/588973
ID: 588974  Test: x86_64 IoT-dvd_ostree-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/588974
ID: 588975  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/588975
ID: 588976  Test: x86_64 IoT-dvd_ostree-iso base_system_logging
URL: https://openqa.fedoraproject.org/tests/588976
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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

Fedora-Cloud-32-20200429.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/1 (x86_64)
(Tests completed, but using a workaround for a known bug)

ID: 588977  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/588977
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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

Self Introduction: Iago Rubio

[Iago Rubio]

Hello,

I am Iago Rubio and I work as software developer in Spain. I have been
involved with fedora some years ago and on the FOSS movement as well.

I have had some packages on Fedora, and back in 2005 I was the upstream
developer of cssed and colorcombinate, two small projects for web
development.

I have been following the devel list for a while and I see there is much
less movement than it used to be.

I am whiling to try to get back and contribute some time to the project.

Any task you may find suitable for a "novice" and any policies and
guidelines you can point me out to get started would be very helpful.

Thanks in advance.


Iago Rubio







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

[EPEL-devel] Re: epel8-playground target ignores build overrides?

[Petr Pisar]

On Tue, Apr 28, 2020 at 09:22:56PM -0700, Michel Alexandre Salim wrote:
> My epel8 build for python-extras succeeded just fine (using python-testtools
> from a build override as a dependency -
> https://bodhi.fedoraproject.org/overrides/python-testtools-2.4.0-3.el8), but
> the epel8-playground build claims python-testtools is not available:
> 
> epel8:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1499241
> 
> epel8-playground:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=43889481
> 
> DEBUG util.py:600:  No matching package to install: 'python3-testtools'
> DEBUG util.py:600:  Not all dependencies satisfied
> DEBUG util.py:600:  Error: Some packages could not be found.
> 
> Does the playground setup not take overrides into account?
> 
playground is an independent build target and thus overrides in epel8 and
epel8-playground are independent. But you don't need to create overrides in
epel8-playground because builds there appears in a build root automatically
on next repository regeneration.

However, your problem is not in overrides. Your problem is that
python-testtools package has never been successfully built for
epel8.playground: 

https://koji.fedoraproject.org/koji/packageinfo?packageID=11850

That's probably because of Carl George  deleted the
package.cfg configuration from epel8 branch to mirror the builds into
epel8-buildroot:

commit dd46fcc88a92241e2aa776208cf7ef0dddbab541
Author: Carl George 
Date:   Fri Apr 24 01:06:33 2020 -0500

Revert ""Adding package.cfg file""

This reverts commit 6a8c5775eb802cc8acfb93dfbe7e00d8e92a24a3.

-- Petr


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

Fedora-Cloud-30-20200429.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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 (anaconda also affected)

[Daniel P . Berrangé]

On Wed, Apr 29, 2020 at 11:47:33AM +0200, Kalev Lember wrote:
> 
> On 4/28/20 22:15, Kevin Fenzi wrote:
> > On Tue, Apr 28, 2020 at 08:01:31AM +0200, Dan Čermák wrote:
> > > Sérgio Basto  writes:
> > > 
> > > > On Mon, 2020-04-27 at 12:39 +0200, Miro Hrončok wrote:
> > > > > GConf2
> > > > 
> > > > GConf2 is orphan, why ? no maintainers or a task force to be removed ?
> > > 
> > > GConf2 has been deprecated for well over a decade and afaik unmaintained
> > > for nearly half a decade. Thus: please just remove it from your
> > > dependencies and use gsettings instead (the upstream replacement).
> > > 
> > > Many packages might actually not require it at all: emacs was pulling it
> > > in, but it works just fine without it and with gsettings instead.
> > 
> > Yeah, I am happy to let GConf2 go into the night... thunar-vfs depends
> > on it, but thats just the old vfs layer Thunar used to use kept around
> > for compatibility. It should go also.
> 
> I agree; it's time to let GConf2 and the rest of the GNOME 2 libraries go.
> If anyone disagrees and should pick it up, please only keep it for F33 and
> then retire it in F34, so that we don't keep the old baggage in the distro
> forever.

...if we're talking old baggage, we've not even got rid of the
even older GTK 1.2.x packages yet :-(

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

[Bug 1829119] perl-RT-Client-REST-0.57 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
FEDORA-2020-0ee23e1a1d has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-0ee23e1a1d


-- 
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 1829119] perl-RT-Client-REST-0.57 is available

[bugzilla]

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



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


-- 
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 1829119] perl-RT-Client-REST-0.57 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
FEDORA-2020-a611ef944a has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-a611ef944a


-- 
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: Orphaned packages looking for new maintainers (anaconda also affected)

[Kalev Lember]

On 4/28/20 22:15, Kevin Fenzi wrote:

On Tue, Apr 28, 2020 at 08:01:31AM +0200, Dan Čermák wrote:

Sérgio Basto  writes:


On Mon, 2020-04-27 at 12:39 +0200, Miro Hrončok wrote:

GConf2


GConf2 is orphan, why ? no maintainers or a task force to be removed ?


GConf2 has been deprecated for well over a decade and afaik unmaintained
for nearly half a decade. Thus: please just remove it from your
dependencies and use gsettings instead (the upstream replacement).

Many packages might actually not require it at all: emacs was pulling it
in, but it works just fine without it and with gsettings instead.


Yeah, I am happy to let GConf2 go into the night... thunar-vfs depends
on it, but thats just the old vfs layer Thunar used to use kept around
for compatibility. It should go also.


I agree; it's time to let GConf2 and the rest of the GNOME 2 libraries 
go. If anyone disagrees and should pick it up, please only keep it for 
F33 and then retire it in F34, so that we don't keep the old baggage in 
the distro forever.


--
Kalev
___
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 1829119] perl-RT-Client-REST-0.57 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-RT-Client-REST-0.57-1.
   ||fc33



--- Comment #3 from Petr Pisar  ---
An enhancement release suitable for all Fedoras.


-- 
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 1829119] perl-RT-Client-REST-0.57 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value




-- 
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 1829089] perl-Module-CoreList-5.20200428 is available

[bugzilla]

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



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


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