Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, 2020-06-16 at 23:45 +0200, Kevin Kofler wrote:
> Neal Gompa wrote:
> > You can also do "%cmake -B %{_vpath_builddir}" and that will work
> > on
> > old and new distro releases alike.
> 
> Not on really old distros, because it requires CMake 3.13 (2018-11-
> 20):
> https://cgold.readthedocs.io/en/latest/glossary/-B.html

It has been there since F29, and now oldest supported is F31.

> (The undocumented variant "%cmake -H. -B%{_vpath_builddir}" should
> work with 
> some older versions of CMake, not sure how far back, but it is not 
> documented and may break in newer CMake versions.)
> 
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7psAsACgkQEV1auJxc
Hh7QLA/+IjUXol0e9378X5q+tAMoZZnvXJDEeEeCp5TtT4SUY2kKCs5gKneCK8Gc
bQTrw2opo+pTn4TxFz/oo1RzRcP5wZ3LdmKp8w2e924tmzQAsE3LXlaS5m61zC06
S9K7kg8ANMgwBe6um5ARhgMR4F19l+nb3jvfhbn/wWCxlAK8O7mWJa01f6HLFh1z
S49JZXCd+Ivn2CqE3gDViFDU4pPsrraWU3h36ttEvYj9T7cZZnLFWdLI2dAxh5xO
GVNBkGShodo0+qCaGBzl3Ky5IJPOBZvLyekfYN3jZz0hqav/0UYMtdFzBmAlHBCv
bfz9PzTBiA+LA8M3TF1VMPaGFZO/BuGgRhJ4/tIn9f2iea9RRjK0O5kLNMxCy9Y9
7++Hvh5s0fyccnxrYI67Hop8Jwt/O1dBIVfxpdiAR0NCuwWq27Kwn1oFMLV66V4x
ISrUeGyQXhcoDmbN19CywyhklTBilu+KNo0o4D7gUcsyczrfzeGa9fBulMWZfoUa
gx9uTtsybaYtGx3L/O2Fh9XC1zkvMTBNFsXPKjHo/9u4SAwGuE91JT4OEaUhdQVq
9pmNSIy3hUgJwUr1BpiqJ+hWVGNFsjiq8cWuhmdKezUQiu9jR7gMJ7uAhcYH8Pfu
jjFSI3Kjd4g/r9RUMxNws+jI39v8IgEQU3tLjlA9l0Jb+QJU34w=
=CMj5
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, 2020-06-16 at 23:52 +0200, Kevin Kofler wrote:
> Dan Čermák wrote:
> > Or you use the new %cmake macro only in the f32, epel8 and master
> > branch and leave the other branches as they are?
> 
> That requires maintaining the branches separately and not fast-
> forwarding 
> them, but fast-forwarding is the most convenient way to maintain
> several 
> leaf packages.
> 
> We have had the discussion of whether to maintain separate specfiles
> on 
> separate branches or use conditionals many times. Both are allowed,
> and 
> different maintainers have different preferences. So trying to force 
> maintainers to do things one way rather than the other is not going
> to fly.
> 
> So I think pointing out that a specfile "simplification" can actually
> be a 
> complication in the presence of conditionals is a valid point, and
> "don't do 
> that then" is not a satisfactory answer.

As it's written in change proposal, we are going to backport
%cmake_build and %cmake_install into older Fedora so you can have same
spec file across all Fedora releases.

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

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7pr6AACgkQEV1auJxc
Hh7REA/8D+CczSJ+Pv4f6ph8lqYIH7Fh2AH7//2JwFD3gA7/AEZrL5+Eig5ZBFQq
MzEz1Q8UPn5qDGrH7/69WBrCiOigg5jjs6L2sAVmkRyXIvycueOVZtW6DQMWgmfw
Gp86SO+EHFF6csAq7bTqHFfFypyShVz9DgBZw2KqbvAhUxHx/M5ubS/WqGKEmFIs
Ro5y0gEzEp3P7fjevDG/H3J/5s11jo/zFCrO3snNtZqc3aLPR0BQqre2JOUWLjYl
YcFqKaaQXVKhSEiX3GKe9MsPqARI4b2Y/RhyCJ7SxkfgywpNAWVY9Iy+eCV6jaPe
ZGZvpa0vxaOduLkvOO7h3hYgTdtAd95uPrJHWFKJrpjCpYAC81nGnuLEXZRuKBvl
04wwPUFxlXUQALPEQvX+HQeY+XKkecjEuUpmyd5HtsYQ2oMWdB+hfa/Kc975F1Iz
2RC9uGNsnAuGQ7STMG7Gvcxx0Ik51/cdvH0DV+jjaUbBBb1WqxNaPJ79n0YTXnt0
2GYMHzC5UE9Mj05PJzfUZSwh2+hHyi4vQ7aW5z/m1fUwP+AfaenOf/8HkP2CKmUO
6wlgcQO4m2SB8mwjiVRwKmbORyBzu5G8aXs40sFXfEKOlEv6hZFsv8D6Mqry9qfy
vvdRrOx2Qn60s1Kw9TKUdhAafdzfRhL3CXIWm6etqfSsAf2sqh8=
=pqxm
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1847803] New: perl-Net-IPv6Addr-1.0 is available

[bugzilla]

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

Bug ID: 1847803
   Summary: perl-Net-IPv6Addr-1.0 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Net-IPv6Addr
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org,
sindr...@fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.0
Current version/release in rawhide: 0.96-5.fc32
URL: http://search.cpan.org/dist/Net-IPv6Addr/

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


-- 
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: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, 2020-06-16 at 15:18 +0200, Kevin Kofler wrote:
> Igor Raits wrote:
> > The correct way of doing out-of-source builds is to use `cmake -S .
> > -B
> > builddir` and not cd/pushd and other things. Sadly we can't
> > implement
> > this enforcement without breaking packages that do `cd/pushd` but
> > we
> > will fix them.
> 
> The pushd approach has been working since forever, which is why it is
> used 
> in all templates. -S and -B are more recent (and redundant)
> introductions.

Right, they have existed before -S/-B were introduced, but it does not
mean we should use old method forever just because we've used it
before. Also they are not redundant.

  cmake [options] 
  cmake [options] 
  cmake [options] -S  -B 

The former options are trying to guess whether you specify source dir
or build dir while with these options you get a consistent way of
telling them to cmake.

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

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7prksACgkQEV1auJxc
Hh7sKg/+O8f1OiUT14JlBcJQabX864VfxfnFfzv4jnS22WiXdxlZ9pv3GP6sQQed
vU+Vo0Hmq3v0Qf45qaNLx5pN8foYFD3zgTeSfTaDyCeAWvmebsiXbGEqmSXaddP5
Jdl89aAWg2UzwetYv3FrNqZkl9iVhEWLmFRBdoJ5DeVrpr3iovXM3Falu7GCsFMa
zQ8CJNB4E/r4cLQCXzUFkfQMH3hqcg/v5XmWJvLmNm3lFhw4smrbI2f7g5MydXFH
0d+3MNpE+QjqLKXpLGqtKMkq/uFhmREOakwBDwJoJ5mQz0lw5JltVOnF0T/nbJIv
T2Aqg1FK0sQF7CtsJP+dKfVfTeIRJ0VPtloF6UUiQAGgUh4/m85zgscV6UKETSoH
H7CsN26yU064wVsYG/t3N3DM40/o/H/fweA3Be8UEhb8OrrLcwt9jvbMSVOSvsjQ
UKwaBiaV7hXdC3pYrTvG2XZ/X//+jTM70yY1dV/GkBgUEvmt3CHvRtqqNAJrQEdR
//JdXbzTZkLMamRFE0CBQ5uTG5zCj2u7boG4ZFg18Y+uO/DKBjT7AVMnKE2YtfuX
c//lRTlbTgaeEGPPlqVzZo2lNKYthvyIk3Yq28Oi3mOAtmk8i3+E5lwkFP8JwYHa
X2V1qMh+yOvvZDXR0pHJY3mXKMLLzggUStNxIzUk1toxt8/2uT8=
=dOuo
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 2020-06-17 at 01:38 +0200, Kevin Kofler wrote:
> James Cassell wrote:
> > If you're doing this, might I suggest reversing the condition so
> > the new
> > way is in the "else" part, hence "default"?
> 
> The problem is that this results in a counterintuitive &&, as in:
> %if 0%{?fedora} <= 32 && 0%{?rhel} <= 8
> (by de Morgan's law, or if you want to analyze it directly, because 
> 0%{?rhel} <= 8 will always be true on Fedora).

%if (0%{?rhel} && 0%{?rhel}) <= 8 || (0%{?fedora} && 0%{?fedora} <= 32)

> > I've run into issues rebuilding packages because there was such a
> > condition from a decade ago and I didn't have %fedora defined
> > because I
> > was trying to build it for another distro. (Common issue amongst
> > the ruby
> > packages.)
> 
> Then you will always get the conditional for the oldest Fedora (no
> matter 
> what is the %if and what the %else part) because 0%{?fedora} will be
> 0, by 
> design.
> 
> The specfiles in Fedora dist-git are either only for Fedora or for
> Fedora 
> and RHEL/CentOS. They are not expected to work on any other distro.

While this is true, I know that some spec files are taken as-is to
openSUSE and Mageia. So it would be nice to have same and simple spec
files that work across multiple distributions.

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

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7prRMACgkQEV1auJxc
Hh4Hqw/+P6sboNTE3HXfqaPGiG06rzG69crm4LcDaDP2iwOHbXE43wY2+/gTNIaW
pl4hjIcoVH9ANJMQK56bvqHZYgl2z2PZ1MrlYOlAWVOi9CgDRqAX5toS6ivXiBWA
FbcDVWrYtbM/AL+Md0FFnEjjEZvAbXMBfDwAYcQc1Z/tjFHVYW0sCLg1H3XkZe21
3x3av3RH6TTrd7BQWa7DalRv5DJVbrrIqwpRwZmeiK9L2w2vJXGfkLKBQ/Tm0v87
SUZQ2OE+MrgGkF9CxW9z4rmSPzeQyNSAycL11SoyIBxXMIqnUeL/GdezK7mJaofS
PSlSz4hljSZqI+4kRbH4FMB0CSJz4xIJzGL1DAw0X8W2SzWoM69n3r7z4TQtX9Tv
jAf7MxSmY7mhDBnP6ePS5ecTOdvIQ5T0fdqUy8ATqLjnb3gq+2TVQJeF1eezHuMx
/E7OfLXczqpeg/vs0So4T91b2/lW/7zJicG+81Vw7efDHBJPMpp0YxXpQr8MOwwz
ALVG8OZU2KuYQnZ6OyJi3xB/3P2MDkPjq0G5revzmzirq6IkrB4d8CuuK8jq4gI7
wS81Re+Z0jU9oUKnT+5nUsRu6dC8iTM+j6qrCMGvhif1wgKlOM6FtR7MysZCwH34
ll+OXRvryP7QnRwacpDneh1OGxBz6JzBLXVdtsz5jWdErOFb4TQ=
=QAkM
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Intent to retire/remove lv2-artyfx-plugins

[Erich Eickmeyer]

Hi all,

I packaged lv2-artyfx-plugins for Ubuntu recently. While it was
undergoing review by the archive admins (they review all of the
copyright headers in the source files for compliance in addition to
other items, they're basically the gatekeepers of the Ubuntu
repositories), it was pointed out to me that these plugins create a
binary that is combined from sources using both GPL-3+ and GPL-2 (not
GPL-2+ as would be indicated with the "or later version" clause).

Because of this, it turns out that this package, while the source
files can be redistributed, the binaries cannot because the source
files licensed as GPL-2 (again, not GPL-2+) are not compatible with
GPL-3 since it is a later version.

So with that, I intend to retire this package, and I believe it would
be in the best interest of the project if the package can be removed
from the repositories as the binaries are basically an illegal
redistribution in many countries.

Thanks,
Erich

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

Re: New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past

[Zdenek Dohnal]

On 6/16/20 11:28 PM, Kevin Kofler wrote:
> Zdenek Dohnal wrote:
>> Do you mean GPL as a license?
> Yes. By "the GPL driver", I mean the driver itself, which is under the GPL 
> and/or compatible licenses, as opposed to the proprietary plugin.
Oh, sorry - when I read driver, I usually come up with associations like
PostScript driver, PDF driver, zjstream driver - based on what stuff
goes out of filtering chain. Professional deformation I guess :)
>
>> Either way, HP upstream makes new releases, but with not so much/any new
>> features or bugfixes. Mostly adding some new PPDs.
> This is quite unfortunate, because several printers are stuck requiring the 
> plugin because of formerly patented algorithms whose patents have since 
> expired, at least JBIG 1.
You're right. Unfortunately, upstream's responses are scarce... you can
try to approach them at
https://bugs.launchpad.net/opensuse/+source/hplip/+bug/1831091 .
>
>> Only jbig2 thing I recall is jbig2dec package which is in Fedora.
> Sorry, my mistake, it is actually JBIG 1 that is used, not JBIG 2. JBIG 1 is 
> implemented by jbigkit, which you now maintain in Fedora. It has been in 
> Fedora for 2 years now because the patent has expired. JBIG 1 is the core of 
> several of the protocols implemented by the proprietary HPLIP plugin, as 
> evidenced by the alternative drivers (foo2zjs etc.) for those printers 
> depending on jbigkit. But unfortunately, the plugin does not just implement 
> JBIG 1 directly, but large parts of the affected protocols are hidden inside 
> the plugin, so it is not straightforward to produce a drop-in replacement 
> for it.

Thanks for the explanation! I didn't know that, because I had my hands
full with other printing packages, so I haven't had time to look into
jbigkit circumstances yet.

Thanks!

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

-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C




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

[389-devel] 389 DS nightly 2020-06-17 - 95% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/06/17/report-389-ds-base-1.4.4.3-20200616gita1c8e12.fc32.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[389-devel] Please review 51160 delete ou fails

[William Brown]

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


—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Re: Fedora 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Luya Tshimbalanga]

On 2020-06-16 5:47 a.m., Neal Gompa wrote:

On Tue, Jun 16, 2020 at 8:46 AM Michael Catanzaro  wrote:

On Tue, Jun 16, 2020 at 2:03 pm, Kamil Paral  wrote:

The person proposing this Change should supply some video showcasing
this, or a very detailed description, otherwise people will have very
varying ideas of how this works and looks.

$ sudo dnf install f32-backgrounds-animated

Select the animated background in gnome-control-center and see for
yourself how it works. :) It's an XML file that describes state
transitions between static images. Usually only the colors vary,
transitioning to darker colors at night, lighter colors in the morning,
standard colors during daytime.

Fedora has supported this for as long as I remember, we just haven't
used it by default in a long time. (I think we actually shipped an
animated background by default once before a while back, though it's
been long enough that I don't remember that for certain.)


We did back in Fedora 7, if I recall correctly. :)


Thanks for that info.  Basically, the goal is to bring back the animated 
background as default.


--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
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 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Luya Tshimbalanga]

On 2020-06-16 2:33 p.m., Kevin Kofler wrote:

Michael Catanzaro wrote:

No, see the existing f32-backgrounds.spec for how the subpackaging
works. Animated backgrounds are in a separate subpackage that spins do
not need to install.

My question was whether this Change intends to change that or whether it
will stay as now. The formulation is unclear.

If the subpackaging remains as now, that is good.

 Kevin Kofler
The change applied for Fedora 33 while the current subppackages for F32 
remains as it is as answered.


--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
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 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Luya Tshimbalanga]

On 2020-06-16 8:27 a.m., Michael Catanzaro wrote:
On Tue, Jun 16, 2020 at 11:22 am, Przemek Klosowski via devel 
 wrote:

IDK how exactly it works, but I see that for instance
f31-backgrounds-animated  has  f31-backgrounds-kde  as a weak 
dependency.


Looks like the F31 package is broken, the Supplements there do not 
make sense and pull in desktop-specific subpackages improperly. This 
problem was identified before the release of F32 and the F32 package 
is fixed.
F31 packages and previous will get fixed. Recommends command will get 
applied for nearly all versions of backgrounds as update.


--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
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 33 System-Wide Change proposal: CMake to do out-of-source builds

[Kevin Kofler]

James Cassell wrote:
> If you're doing this, might I suggest reversing the condition so the new
> way is in the "else" part, hence "default"?

The problem is that this results in a counterintuitive &&, as in:
%if 0%{?fedora} <= 32 && 0%{?rhel} <= 8
(by de Morgan's law, or if you want to analyze it directly, because 
0%{?rhel} <= 8 will always be true on Fedora).

> I've run into issues rebuilding packages because there was such a
> condition from a decade ago and I didn't have %fedora defined because I
> was trying to build it for another distro. (Common issue amongst the ruby
> packages.)

Then you will always get the conditional for the oldest Fedora (no matter 
what is the %if and what the %else part) because 0%{?fedora} will be 0, by 
design.

The specfiles in Fedora dist-git are either only for Fedora or for Fedora 
and RHEL/CentOS. They are not expected to work on any other distro.

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

orphaning python-mitogen

[Carl George]

I just orphaned the python-mitogen package.  I packaged it for my last
job but I no longer use it and I'm not interested in maintaining it
anymore.  As best I can tell, nothing else in the distribution
requires or build requires it.  It's up for grabs if anyone is
interested.

-- 
Carl George
___
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 33 System-Wide Change proposal: CMake to do out-of-source builds

[James Cassell]

On Tue, Jun 16, 2020, at 9:16 AM, Kevin Kofler wrote:
> Michael Catanzaro wrote:
> > Kevin, the goal is to *simply* these packages:
> > 
> > mkdir -p %{_target_platform}
> > pushd %{_target_platform}
> > %cmake 
> > popd
> > 
> > It's four lines. We get to simplify it down to one line. Proposal
> > owners are provenpackagers and say they will try to fix affected
> > packages. Fine by me?
> 
> In the real world, it will end up as:
> 
> %if 0%{?fedora} > 32 || 0%{?rhel} > 8
> %cmake
> %else
> mkdir %{_target_platform}
> pushd %{_target_platform}
> %cmake ..
> popd
> %endif
> 

If you're doing this, might I suggest reversing the condition so the new way is 
in the "else" part, hence "default"? I've run into issues rebuilding packages 
because there was such a condition from a decade ago and I didn't have %fedora 
defined because I was trying to build it for another distro. (Common issue 
amongst the ruby packages.)

V/r,
James Cassell
___
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 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Michael Catanzaro]

On Tue, Jun 16, 2020 at 11:33 pm, Kevin Kofler  
wrote:

If the subpackaging remains as now, that is good.


So I'm not the change owner, but I think the plan is to leave the 
subpackaging as it is now in F32 (not F31 where it is wonky).


___
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 33 System-Wide Change proposal: Fedora-Retired-Packages

[Jóhann B . Guðmundsson]

On 16.6.2020 21:44, Solomon Peachy wrote:

"retired" tells you nothing more than "no longer packaged".

"packaged" does not mean "maintained by fedora".  It certianly doesn't
mean "kept up to date with upstream releases" or "kept updated with
security fixes"

And "broken" in this context means nothing more than "failed to
package/build", because "packaged" doesn't mean "it actually
works/runs".


The solution to this problem should be quite evident and that is to 
archive the "retired" components as flatpaks ( if the component is a 
desktop app ) or a as container ( if it's a server application or 
application stack ) using OCI Images and the OCI distribution mechanism 
as a deployment technology( for organization ) that is if the 
application or application stack is of any real, practical or nostalgic 
value to end users or organization which would be worth keeping.


That approach should solve both the package management issues and "if it 
ain’t broken, don’t touch it" or simply keeping it available because 
it's useful to some end user(s) dilemma along with bunch of other 
problems that affect Fedora but people seem to be expecting different 
results using the same old thinking, which lead to the same old 
approaches, to solve the same old problems.


JBG

___
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 33 Self-Contained Change proposal: Distribute .repo files for modular repositories from a separate package

[Miro Hrončok]

On 16. 06. 20 11:57, Vít Ondruch wrote:

Not mentioned that weak dependencies are disabled in Mock.


I don't understand why would the user need fedora-repos-modular automatically 
pulled into mock when they install fedora-repos there. Could you please elaborate?


--
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: Fedora 33 Self-Contained Change proposal: Distribute .repo files for modular repositories from a separate package

[James Cassell]

On Tue, Jun 16, 2020, at 5:57 AM, Vít Ondruch wrote:
> 
> Dne 16. 06. 20 v 11:04 Miro Hrončok napsal(a):
> > On 16. 06. 20 10:03, Panu Matilainen wrote:
> >> Yeah it's a hard dependency of fedora-release-common. I suppose one
> >> possibility would be adding a recommends on fedora-repos-modular to
> >> fedora-release-common, but weak dependencies have an annoying
> >> tendency to creep back in when you're not looking, a kickstart/comps
> >> defaults are nicer in that regard.
> >
> > I was originally thinking that fedora-repos should recommend
> > fedora-repos-modular, but due to the annoying nature of getting
> > recommends back on every upgrade of the related package I abandoned
> > the idea.
> >
> > Relevant dnf bugzilla:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1699672
> >
> 
> Not mentioned that weak dependencies are disabled in Mock.
> 

I can't decide whether that's a bug or a feature...


V/r,
James Cassell
___
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 33 System-Wide Change proposal: CMake to do out-of-source builds

[Kevin Kofler]

Dan Čermák wrote:
> Or you use the new %cmake macro only in the f32, epel8 and master
> branch and leave the other branches as they are?

That requires maintaining the branches separately and not fast-forwarding 
them, but fast-forwarding is the most convenient way to maintain several 
leaf packages.

We have had the discussion of whether to maintain separate specfiles on 
separate branches or use conditionals many times. Both are allowed, and 
different maintainers have different preferences. So trying to force 
maintainers to do things one way rather than the other is not going to fly.

So I think pointing out that a specfile "simplification" can actually be a 
complication in the presence of conditionals is a valid point, and "don't do 
that then" is not a satisfactory answer.

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

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Kevin Kofler]

Neal Gompa wrote:
> You can also do "%cmake -B %{_vpath_builddir}" and that will work on
> old and new distro releases alike.

Not on really old distros, because it requires CMake 3.13 (2018-11-20):
https://cgold.readthedocs.io/en/latest/glossary/-B.html

(The undocumented variant "%cmake -H. -B%{_vpath_builddir}" should work with 
some older versions of CMake, not sure how far back, but it is not 
documented and may break in newer CMake versions.)

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

[Bug 1847730] New: perl-DBIx-Class-0.082842 is available

[bugzilla]

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

Bug ID: 1847730
   Summary: perl-DBIx-Class-0.082842 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-DBIx-Class
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org,
trem...@tremble.org.uk
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.082842
Current version/release in rawhide: 0.082841-10.fc32
URL: http://search.cpan.org/dist/DBIx-Class/

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


-- 
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: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Solomon Peachy]

On Tue, Jun 16, 2020 at 08:49:57PM +, Jóhann B. Guðmundsson wrote:
> Unless the process and the approach of "If it builds let's ship it" 
> has not been changed over the years then the end user might be getting 
> a package that is not actually being maintained in the distribution 
> thus already is a security risk ( without it being flagged retired ) 
> to begin with so arguably that problem needs to be solved first or at 
> the same time as this.

Exactly!

Nearly every webapp packaged by Fedora is in this boat.

Dokuwiki was a particularly aggregious example; the packaged version was 
completely *broken* between F25 and late-F28, incompatible with the PHP7 
interpreter that Fedora shipped in those releases.

That incompatibility was a blessing of sorts, as it also meant that 
between F25 and late-F28, the multiple CVEs present in that package 
weren't exploitable.

(I actually reported this brokenness in F25.  That ticket ended up being 
 auto-closed when F27 came out, without the package getting fixed...)

> I think people first need to establish what perception and thus meaning
> people put in the words retired,broken,maintained etc. before the proper
> course of action can be taken.

"retired" tells you nothing more than "no longer packaged".

"packaged" does not mean "maintained by fedora".  It certianly doesn't 
mean "kept up to date with upstream releases" or "kept updated with 
security fixes"

And "broken" in this context means nothing more than "failed to 
package/build", because "packaged" doesn't mean "it actually 
works/runs".

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


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

Re: Orphaned 215 packages

[Jared K. Smith]

On Tue, Jun 16, 2020 at 3:41 PM Ben Rosser  wrote:

> So... this is a lot of node.js packages, and I haven't really seen any
> discussion of this on the lists. And at least some of these are possibly
> important for other nodejs packages-- notably "mocha", which I suspect is
> used in at least some packages to run unit tests (at the very least,
> several of my nodejs packages use it to run unit tests...).
>

Indeed... I'd hate to see mocha disappear.  That being said, there's a
bunch of these other packages that can probably safely be retired -- I
pulled in a couple hundred NodeJS packages in my hard-headed attempt to get
NodeRED into Fedora for the IoT team a couple of years ago, but got bogged
down in dependency nightmares and ultimately gave up.  Since then, I've
been busy with my job and grad school to really spend a lot of time
worrying about NodeJS packages in Fedora, since I'm not a NodeJS
developer.  That being said, if there are packages like mocha that really
need to be maintained to keep the NodeJS ecosystem working in Fedora, I
could probably be persuaded to pick up a few more packages.

-Jared
___
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 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Kevin Kofler]

Michael Catanzaro wrote:
> No, see the existing f32-backgrounds.spec for how the subpackaging
> works. Animated backgrounds are in a separate subpackage that spins do
> not need to install.

My question was whether this Change intends to change that or whether it 
will stay as now. The formulation is unclear.

If the subpackaging remains as now, that is good.

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

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Solomon Peachy]

On Tue, Jun 16, 2020 at 04:22:42PM -0400, Gerald Henriksen wrote:
> Given the number of cases of evil people getting access to computer
> systems, and the fallout of said attacks, any package left on a system
> after it no longer is being maintained is not only broken but a
> security risk.

"no longer packaged by fedora" is not the same as being "broken" or 
"insecure".  Just as "packaged by fedora" doesn't mean that it works or 
is kept secure.  So please, please do not conflate the two.

(Case in point: dokuwiki, which was only "secure" in the sense that it 
 was completely broken for 2-3 fedora releases, so exploiting the 
 multiple outstanding CVEs in the packaged version was impossible..)

"Security" is a process, not a state; it has to be balanced against 
"usability"

What good is a security policy that requires me to disable it to 
continue using software that I find necessary?  Or worse, a policy that 
auto-removes software I might still be using?  That is actively 
user-hostile, and you'll rapidly see instructions on how to disable it 
crop up on the inevitable "how to make your fedora system usable" 
instructions.  Right after "disable selinux" but before "enable 
freshrpms", "install google chrome", and the inevitable "sudo curl 
http://github.com/blabla | bash" at the end.

Meanwhile, let's be honest.  Is my main server more likely to get 
compromised through my use of mailgraph (dead upstream for over a decade 
and retired after F29 because nobody bothered to fix its selinux 
integration) or because one of my users had a shared password 
compromised in $massive_data_breach_du_jour?

> You as a user may wish to explicitly make the decision to ignore that
> risk and keep or re-install that software, and that is your choice.
> But it should not be the default behaviour of the distribution.

"Fedora knows better than its users" represents a massive shift in 
Fedora policy, and should be discussed as such before anyone talks about 
how to implement it.

If Fedora drops a package, that package currently gets relegated to the 
same position as any other software the user installed from non-Fedora 
sources -- which I'd wager is the overwhelming majority of 
workstation-type installs and a significant chunk of server-type 
installs too.

Upgrades still have to handle non-Fedora-supplied packages sanely, and 
the only sane, user-friendly way to handle those is to inform the user 
of the issue and let them decide what to do.  On a per-package basis, 
because no matter what the default is, it's going to be wrong when 
applied across the board.

(Of the dozen-ish Fedora installs I'm responsible for, exactly one would 
 be fine with this new policy.  Every other one, workstation and server 
 alike, is a special snowflake. Folks not running snowflake systems 
 don't do in-place OS upgrades; they spin up new instances from scratch)

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


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

Re: New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past

[Kevin Kofler]

Zdenek Dohnal wrote:
> Do you mean GPL as a license?

Yes. By "the GPL driver", I mean the driver itself, which is under the GPL 
and/or compatible licenses, as opposed to the proprietary plugin.

> Either way, HP upstream makes new releases, but with not so much/any new
> features or bugfixes. Mostly adding some new PPDs.

This is quite unfortunate, because several printers are stuck requiring the 
plugin because of formerly patented algorithms whose patents have since 
expired, at least JBIG 1.

> Only jbig2 thing I recall is jbig2dec package which is in Fedora.

Sorry, my mistake, it is actually JBIG 1 that is used, not JBIG 2. JBIG 1 is 
implemented by jbigkit, which you now maintain in Fedora. It has been in 
Fedora for 2 years now because the patent has expired. JBIG 1 is the core of 
several of the protocols implemented by the proprietary HPLIP plugin, as 
evidenced by the alternative drivers (foo2zjs etc.) for those printers 
depending on jbigkit. But unfortunately, the plugin does not just implement 
JBIG 1 directly, but large parts of the affected protocols are hidden inside 
the plugin, so it is not straightforward to produce a drop-in replacement 
for it.

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

Re: Packagers with no corresponding valid bugzilla accounts

[Jonathan Wakely]

On 16/06/20 17:15 -0400, Christopher wrote:

On Tue, Jun 16, 2020 at 11:10 AM Pierre-Yves Chibon  wrote:


On Tue, Jun 16, 2020 at 11:05:00AM -0400, Christopher wrote:
>Why aren't the packager accounts linked to their FAS account alias?
>[1]fa...@fedoraproject.org ? I've been annoyed by FAS-linked services
>trying to use my forwarding address for my account id rather than my FAS
>user id. My forwarding address is subject to change, but the FAS email
>alias is static.

Because they are two different systems and you do not need an account in one to
have an account in the other?
We do not create account on bugzilla for the alias @fp.o automatically (and I
think it's a good thing).


The original post says "If you are a packager... you must have a
bugzilla account...".
But now, you are saying that they are separate and you do not need one
when you have the other.

These two statements are in conflict. Either the bugzilla account is
required for packagers, in which case my suggestion to use the
packager's FAS email alias should suffice (in theory, at least), or it
isn't, in which case, your original post that "...packagers...must
have a bugzilla account..." is incorrect.

You said that the required bugzilla account must be "...associated
with the email address you have set in FAS." All I'm suggesting is
that this is unnecessary if they are packagers, since all packagers
already have a FAS email alias that can be used for this requirement.


I already have a bugzilla.redhat.com account, I don't want another one
for my fedoraproject.org address.

The two systems are separate, and don't need to use the same identity.

___
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: Packagers with no corresponding valid bugzilla accounts

[Christopher]

On Tue, Jun 16, 2020 at 11:10 AM Pierre-Yves Chibon  wrote:
>
> On Tue, Jun 16, 2020 at 11:05:00AM -0400, Christopher wrote:
> >Why aren't the packager accounts linked to their FAS account alias?
> >[1]fa...@fedoraproject.org ? I've been annoyed by FAS-linked services
> >trying to use my forwarding address for my account id rather than my FAS
> >user id. My forwarding address is subject to change, but the FAS email
> >alias is static.
>
> Because they are two different systems and you do not need an account in one 
> to
> have an account in the other?
> We do not create account on bugzilla for the alias @fp.o automatically (and I
> think it's a good thing).

The original post says "If you are a packager... you must have a
bugzilla account...".
But now, you are saying that they are separate and you do not need one
when you have the other.

These two statements are in conflict. Either the bugzilla account is
required for packagers, in which case my suggestion to use the
packager's FAS email alias should suffice (in theory, at least), or it
isn't, in which case, your original post that "...packagers...must
have a bugzilla account..." is incorrect.

You said that the required bugzilla account must be "...associated
with the email address you have set in FAS." All I'm suggesting is
that this is unnecessary if they are packagers, since all packagers
already have a FAS email alias that can be used for this requirement.
___
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 33 System-Wide Change proposal: Fedora-Retired-Packages

[Jóhann B . Guðmundsson]

On 16.6.2020 20:22, Gerald Henriksen wrote:

Given the number of cases of evil people getting access to computer
systems, and the fallout of said attacks, any package left on a system
after it no longer is being maintained is not only broken but a
security risk.


Unless the process and the approach of "If it builds let's ship it" has 
not been changed over the years then the end user might be getting a 
package that is not actually being maintained in the distribution thus 
already is a security risk ( without it being flagged retired ) to begin 
with so arguably that problem needs to be solved first or at the same 
time as this.


I think people first need to establish what perception and thus meaning 
people put in the words retired,broken,maintained etc. before the proper 
course of action can be taken.


JBG
___
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 33 System-Wide Change proposal: Fedora-Retired-Packages

[Jonathan Wakely]

On 16/06/20 02:24 +0200, Kevin Kofler wrote:

Ben Cotton wrote:

== Summary ==
All retired packages are obsoleted by `fedora-retired-packages`.

== Owner ==
* Name: [[User:msuchy| Miroslav Suchý]]
* Email: msu...@redhat.com


Absolute -1!

IMHO, removing working packages from users' systems just because the new
release no longer ships them is entirely unnecessary and a total disservice
to users.


== Upgrade/compatibility impact ==
During an upgrade, all retired packages will be automatically removed.

User may opt-out by:

$ cat /etc/dnf/dnf.conf
[main]
...
exclude=fedora-retired-packages



Is this actually honored by all tools, including PackageKit? (Last I
checked, PackageKit ignored dnf.conf entirely.) The opt-out needs to work
with PackageKit to be of any use.


It works with PK now:
https://bugzilla.redhat.com/show_bug.cgi?id=1338975#c5

___
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 33 System-Wide Change proposal: Fedora-Retired-Packages

[Gerald Henriksen]

On Tue, 16 Jun 2020 15:05:41 -0400, you wrote:

>User/Admin customizations are expected to be retained post-upgrade, and 
>software installed after the fact absolutely counts as a customization, 
>no matter where that software came from.

But any software installed by the user that comes from an official
Fedora repo is installed on the assumption that it is being maintained
by Fedora - that is why it is in the Fedora repo.

If the software is no longer being maintained (either due to a lack of
a packager, or because upstream has disappeared) that implied contract
is no longer true.

>And what about non-Fedora software?  That can break an upgrade too, are 
>we going to automagically remove that stuff too?  If not, Fedora will 
>still going to have to handle those upgrade failures gracefully.

Any software installed from non-Fedora sources will involve a decision
by the user to accept that it is not being supported by Fedora.

This should (although sadly likely doesn't) mean that the user pays
attention as to whether the software is being updated and supported or
not.

>But.  I cannot strongly object enough to automatically uninstalling a 
>package solely because it was retired, because "retired" does not mean 
>"broken".

Given the number of cases of evil people getting access to computer
systems, and the fallout of said attacks, any package left on a system
after it no longer is being maintained is not only broken but a
security risk.

You as a user may wish to explicitly make the decision to ignore that
risk and keep or re-install that software, and that is your choice.
But it should not be the default behaviour of the distribution.
___
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

Intent to retire python-j1m.sphinxautointerface

[Jerry James]

The package python-j1m.sphinxautointerface was added to Fedora for the
use of the python-ZODB package.  It packages a fork of
sphinxcontrib-zopeext.  A new release of ZODB is out and it drops the
fork in favor of sphinxcontrib-zopeext.  As far as I can tell, once I
update python-ZODB to use the (newly added)
python-sphinxcontrib-zopeext package, there will be no users left in
Fedora.  I intend to retire it.  If you have a reason for keeping it
in Fedora, please let me know this week and I will pass it to you
instead.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Highlights from the latest Copr release 2020-06-10

[Pavel Raiskup]

On Tuesday, June 16, 2020 8:48:32 PM CEST Ian McInerney wrote:
> ...snip...
> >
> > - There's now more fair build scheduler.  Previously, no matter whether the
> >   "background" attribute was set or not for the build - once builder was
> >   allocated for a concrete copr user - copr never terminated the builder
> >   as long as the user kept filling the build queue with new tasks (and it
> >   blocked the quota for others).  Newly, there's a limit of at most
> >   eight consecutive builds or 30 minutes for one user (sandbox) on one
> >   builder and the builder is immediately terminated - which gives a chance
> >   to assign new builders to others' tasks (which have a higher priority at
> >   that point).
> >
>
> I am confused by this scheduler part. Does this mean that any build that
> takes longer than 30 minutes will be cancelled? What about software
> packages that are larger and require more build time?

This deserved better spelling => any builder that was assigned to one user for
_more than 30 minutes_ is - after the build _is finished_ - terminated.  The
build timeout is a different configuration option (currently around 24h, and the
timeout concept should change soon so it is more flexible,
https://pagure.io/copr/copr/issue/1303 ).

Pavel

> -Ian
> 



___
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 215 packages

[Ben Rosser]

On Wed, May 13, 2020 at 3:56 AM Jamie Nguyen  wrote:

> Hi,
>
> This is a follow up for this post:
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RR2KB64SGUM7IJKBSQORQGZGUSROPFHD/
>
> Below are the packages I've orphaned. See section [d] of the linked
> email to see how many times each package is listed as Requires by
> something else.
>
> Most are Node.js packages, some still maintained via the 'nodejs-sig'
> user, though 'nodejs-sig' can't own packages so I orphaned instead.
>
>
> - compat-libuv010
> - CutyCapt
> - dateformat
> - expresso
> - jasmine-node
> - js-json
> - js-zlib
> - marked
> - mocha
> - nodejs-abbrev
> - nodejs-ain2
> - nodejs-ansi
> - nodejs-ansi-styles
> - nodejs-archy
> - nodejs-asap
> - nodejs-asn1
> - nodejs-assertplus
> - nodejs-async
> - nodejs-aws-sign
> - nodejs-basic-auth-connect
> - nodejs-batch
> - nodejs-better-assert
> - nodejs-bindings
> - nodejs-block-stream
> - nodejs-boom
> - nodejs-buffer-crc32
> - nodejs-buffer-equal
> - nodejs-bunker
> - nodejs-burrito
> - nodejs-bytes
> - nodejs-callsite
> - nodejs-chalk
> - nodejs-character-parser
> - nodejs-charm
> - nodejs-child-process-close
> - nodejs-chmodr
> - nodejs-chownr
> - nodejs-cmd-shim
> - nodejs-combined-stream
> - nodejs-commander
> - nodejs-component-emitter
> - nodejs-config-chain
> - nodejs-connect-timeout
> - nodejs-console-dot-log
> - nodejs-cookie
> - nodejs-cookiejar
> - nodejs-cookie-jar
> - nodejs-cookie-parser
> - nodejs-cookie-signature
> - nodejs-couch-login
> - nodejs-cryptiles
> - nodejs-css
> - nodejs-cssom
> - nodejs-css-parse
> - nodejs-css-stringify
> - nodejs-csurf
> - nodejs-ctype
> - nodejs-cycle
> - nodejs-debug
> - nodejs-defined
> - nodejs-delayed-stream
> - nodejs-detective
> - nodejs-diff
> - nodejs-dryice
> - nodejs-editor
> - nodejs-ejs
> - nodejs-escodegen
> - nodejs-estraverse
> - nodejs-esutils
> - nodejs-eventemitter2
> - nodejs-exit
> - nodejs-expect-dot-js
> - nodejs-express-session
> - nodejs-faye-websocket
> - nodejs-fileset
> - nodejs-findup-sync
> - nodejs-forever-agent
> - nodejs-form-data
> - nodejs-formidable
> - nodejs-fresh
> - nodejs-fstream
> - nodejs-fstream-ignore
> - nodejs-fstream-npm
> - nodejs-generic-pool
> - nodejs-getobject
> - nodejs-github-url-from-git
> - nodejs-glob
> - nodejs-grip
> - nodejs-growl
> - nodejs-grunt-compare-size
> - nodejs-grunt-contrib-concat
> - nodejs-grunt-contrib-internal
> - nodejs-grunt-contrib-uglify
> - nodejs-grunt-contrib-watch
> - nodejs-grunt-git-authors
> - nodejs-gzip-size
> - nodejs-has-color
> - nodejs-hawk
> - nodejs-hoek
> - nodejs-hooker
> - nodejs-http-signature
> - nodejs-inherits1
> - nodejs-ini
> - nodejs-iso8601
> - nodejs-isodate
> - nodejs-jasmine-reporters
> - nodejs-joose
> - nodejs-joosex-namespace-depended
> - nodejs-joosex-simplerequest
> - nodejs-jscoverage
> - nodejs-jsonfile
> - nodejs-jsonify
> - nodejs-json-stringify-safe
> - nodejs-js-yaml
> - nodejs-jwt-simple
> - nodejs-keypress
> - nodejs-lazystream
> - nodejs-lockfile
> - nodejs-markdown
> - nodejs-maxmin
> - nodejs-methods
> - nodejs-mime
> - nodejs-mimeparse
> - nodejs-minimatch
> - nodejs-minimist
> - nodejs-morgan
> - nodejs-ms
> - nodejs-muffin
> - nodejs-multiparty
> - nodejs-mute-stream
> - nodejs-nan0
> - nodejs-ncp
> - nodejs-node-int64
> - nodejs-node-uuid
> - nodejs-nopt
> - nodejs-noptify
> - nodejs-npmlog
> - nodejs-npm-user-validate
> - nodejs-oauth-sign
> - nodejs-opener
> - nodejs-optimist
> - nodejs-opts
> - nodejs-osenv
> - nodejs-package
> - nodejs-paperboy
> - nodejs-parseurl
> - nodejs-pause
> - nodejs-pkginfo
> - nodejs-pretty-bytes
> - nodejs-promise
> - nodejs-promzard
> - nodejs-proto-list
> - nodejs-pubcontrol
> - nodejs-qs
> - nodejs-range-parser
> - nodejs-read
> - nodejs-readdirp
> - nodejs-read-package-json
> - nodejs-reduce-component
> - nodejs-repl
> - nodejs-require-cs
> - nodejs-requirejs
> - nodejs-resolve
> - nodejs-response-time
> - odejs-response-time rpms
> - nodejs-retry
> - nodejs-rimraf
> - nodejs-ronn
> - nodejs-runforcover
> - nodejs-sax
> - nodejs-semver
> - nodejs-serve-index
> - nodejs-setimmediate
> - nodejs-sha
> - nodejs-shelljs
> - nodejs-showdown
> - nodejs-sigmund
> - nodejs-slide
> - nodejs-source-map
> - nodejs-stack-trace
> - nodejs-static-favicon
> - nodejs-stream-counter
> - nodejs-strip-ansi
> - nodejs-superagent
> - nodejs-supertest
> - nodejs-tar
> - nodejs-temp
> - nodejs-temporary
> - nodejs-testswarm
> - nodejs-through
> - nodejs-tiny-lr-fork
> - nodejs-transformers
> - nodejs-traverse
> - nodejs-tunnel-agent
> - nodejs-uglify-to-browserify
> - nodejs-uid-number
> - nodejs-underscore
> - nodejs-underscore-dot-string
> - nodejs-utile
> - nodejs-vhost
> - nodejs-walkdir
> - nodejs-weak-map
> - nodejs-websocket-driver
> - nodejs-which
> - nodejs-wordwrap
> - nodejs-yamlish
> - nodejs-zlib-browserify
> - nodejs-zlibjs
> - uglify-js1
> - web-assets
>

So... this is a lot of node.js packages, and I haven't really seen any
discussion of this on the lists. 

Re: Datacenter move days 3 and 4

[Scott Talbert]

Whatever you did with the koji web interface, +1000!  It is crazy fast now!

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

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Solomon Peachy]

On Tue, Jun 16, 2020 at 05:15:37PM +, Gary Buhrmaster wrote:
> I am in favor of the intention that when you upgrade,
> those packages from previous releases are removed
> automagically. 

How will you know it is going away?  When you discover the software 
missing post-upgrade?

> After an upgrade I typically expect
> the system and packages to be supported and
> maintained in the same way as if I installed new.

User/Admin customizations are expected to be retained post-upgrade, and 
software installed after the fact absolutely counts as a customization, 
no matter where that software came from.

I'm talking about stuff that got installed because the user explicitly 
asked for it, not because it got pulled in as a dependency.

And what about non-Fedora software?  That can break an upgrade too, are 
we going to automagically remove that stuff too?  If not, Fedora will 
still going to have to handle those upgrade failures gracefully.

> FD: I spend time after every upgrade to remove old
> retired packages, and not having to doing so would
> make life easier.

I spend time before every upgrade enumerating the things that are 
expected to break in the upgrade, and tackling those issues pre-upgrade 
or staging things so I can do it post-upgrade.  Getting the list of 
packages that triggere pre-upgrade failures is a big help in that regard.

After every upgrade, as well as tackling the known breakages, I also 
have to deal with the stuff that unexpectedly broke.  Which, to Fedora's 
credit, is pretty rare these days.

But.  I cannot strongly object enough to automatically uninstalling a 
package solely because it was retired, because "retired" does not mean 
"broken".

A reasonable argument for automagic removal can be made for packages 
that will break due to an unmet dependency, but ultimately the user is 
the only one who can determine if proceeding is okay or not.  And to 
determine that, they need to be suitably informed.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


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: Highlights from the latest Copr release 2020-06-10

[Ian McInerney]

...snip...
>
> - There's now more fair build scheduler.  Previously, no matter whether the
>   "background" attribute was set or not for the build - once builder was
>   allocated for a concrete copr user - copr never terminated the builder
>   as long as the user kept filling the build queue with new tasks (and it
>   blocked the quota for others).  Newly, there's a limit of at most
>   eight consecutive builds or 30 minutes for one user (sandbox) on one
>   builder and the builder is immediately terminated - which gives a chance
>   to assign new builders to others' tasks (which have a higher priority at
>   that point).
>

I am confused by this scheduler part. Does this mean that any build that
takes longer than 30 minutes will be cancelled? What about software
packages that are larger and require more build time?

-Ian
___
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 33 System-Wide Change proposal: CMake to do out-of-source builds

[Christoph Junghans]

On Mon, Jun 15, 2020 at 1:49 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
>
> == Summary ==
> %cmake macro will be adjusted (-B parameter)
> to use separate build folder (already standardized
> %{_vpath_builddir} macro). Additionally,
> %cmake_build, %cmake_install and
> %ctest macro will be created (and backported to the older
> supported Fedora releases) to perform various operations that are
> commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> etc.) way.
>
> Packages that will stop building are trivial to fix and will be
> adjusted either by maintainers or change owners.
>
> == Owner ==
> * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> Esser]], [[User:ngompa|Neal Gompa]]
> * Email: ignatenkobr...@fedoraproject.org, besse...@fedoraproject.org,
> ngomp...@gmail.com
>
> == Detailed Description ==
> Historically, software builds had a singular build configuration and
> required running the build within the project root. Nowadays, there
> are many build modes and options that can be configured in projects,
> different build settings (e.g. compiler flags) / types (release,
> debug) that can be applied and different tools that can be used to
> actually execute builds (compilers like gcc/clang, build job
> schedulers like make/ninja, and so on). Thus, CMake upstream strongly
> discourages users of doing in-source builds and recommends doing
> out-of-source builds.
>
> From cmake.1:
>
> 
> To maintain a pristine source tree, perform an out-of-source build by
> using a separate dedicated build tree. An in-source build in which the
> build tree is placed in the same directory as the source tree is also
> supported, but discouraged.
> 
>
> The other part of the change is introduction of additional macros is
> creation of set of macro that can build, install and run tests in a
> backend-agnostic, vpath-aware (out-of-source, in-source) way.
>
> === Migration ===
>
>  %cmake + %(make|ninja)_(build|install) 
>
> There are multiple paths to complete the migration:
>
> * Add -C "%{_vpath_builddir}" to the %(make|ninja)_*
> * Replace %(make|ninja)_build and
> %(make|ninja)_install with %cmake_build and
> %cmake_install respectively
> * Redefine vpath builddir %global _vpath_builddir . to
> continue performing in-source builds (and optionally converting to the
> %cmake_*)
>
> Depending on the package, one of these options may be used to adapt to
> this change.
>
>  %cmake -B builddir +
> %(make|ninja)_(build|install) -C builddir 
>
> No changes are needed.
>
> == Benefit to Fedora ==
> * Follow CMake upstream recommendations when building packages
> * Brings Fedora package builds more in-line with how upstream projects
> expect them to be built
> * Improve compatibility with other RPM distributions that already do this
> * Support backend-agnostic way of building CMake projects
>
> == Scope ==
> * Proposal owners: Implement necessary macros, try to build packages
> that BuildRequires: cmake in a side tag, analyze failures
> and fix the relevant ones (introduced by this change).
> * Other developers: While proposal owners will try to fix all affected
> packages, there might be some cases where package is already FTBFS so
> the fix can't be performed. Other package maintainers will have to fix
> the issue themselves after they fix FTBFS.
> * Release engineering: [https://pagure.io/releng/issue/9524 #9524]
> * Policies and guidelines: CMake page will be adjusted to mention
> newly created macros and the documentation about relevant VPATH macros
> needs to be restructured a bit (they are already documented on the
> Meson page, they need to be moved to the separate page and referenced
> both from CMake and Meson page).
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
> Existing packages can (and most likely will) become FTBFS, but
> proposal owners will fix as many Fedora packages as possible. However
> fixing third-party packages is not possible and out of scope.
> Third-party packagers will need to adapt based on the recommendations
> noted in this Change.
>
> == How To Test ==
> # Grab the new cmake RPM from the Koji sidetag (TBC)
> # Try to build package that uses %cmake,
> %cmake_build, %cmake_install and
> %ctest macro
>
> == User Experience ==
> The end-users (non-packagers) will not notice any changes.
>
> == Dependencies ==
> There are around 1100 RPMs in Fedora that depend on CMake at
> build-time. All proposal owners are provenpackagers so they are able
> to commit necessary fixes. No external dependencies.
>
> == Contingency Plan ==
> * Contingency mechanism: Proposal owners will adjust macros to not do
> out-of-source builds by default, but will preserve newly created macro
> (essentially to bring them to the targeted state of older supported
> Fedora releases).
> * Contingency deadline: Beta freeze.
> * Blocks release? No
>
> == Documentation ==
> The only place 

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Gary Buhrmaster]

On Mon, Jun 15, 2020 at 7:48 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>
> == Summary ==
> All retired packages are obsoleted by `fedora-retired-packages`.
>

I am in favor of the intention that when you upgrade,
those packages from previous releases are removed
automagically.  After an upgrade I typically expect
the system and packages to be supported and
maintained in the same way as if I installed new.

And if I need some package that is no longer in
Fedora, I will build it for my personal or organizational
use and accept the additional support burden
explicitly and not by accident (and I often start by
leveraging the old .src rpms from Fedora).

FD: I spend time after every upgrade to remove old
retired packages, and not having to doing so would
make life easier.
___
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 33 System-Wide Change proposal: CMake to do out-of-source builds

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, 2020-06-16 at 18:54 +0200, Dan Čermák wrote:
> Kevin Kofler  writes:
> 
> > Michael Catanzaro wrote:
> > > Kevin, the goal is to *simply* these packages:
> > > 
> > > mkdir -p %{_target_platform}
> > > pushd %{_target_platform}
> > > %cmake 
> > > popd
> > > 
> > > It's four lines. We get to simplify it down to one line. Proposal
> > > owners are provenpackagers and say they will try to fix affected
> > > packages. Fine by me?
> > 
> > In the real world, it will end up as:
> > 
> > %if 0%{?fedora} > 32 || 0%{?rhel} > 8
> > %cmake
> > %else
> > mkdir %{_target_platform}
> > pushd %{_target_platform}
> > %cmake ..
> > popd
> > %endif
> 
> Or you use the new %cmake macro only in the f32, epel8 and master
> branch and leave the other branches as they are?

Also note that %cmake_build and %cmake_install will be backported to
f32 and f31 so you won't have to care much whether it is in-source or
out-of-source. You can use those with `-B %{_vpath_builddir}` to ensure
that it will do out-of-source even on older Fedora versions, otherwise
it will behave slightly differently but this should not be a big
problem.

> > 
> > i.e. 8 lines instead of 4, and much less readable. Most specfiles
> > need to 
> > work on older distributions too.
> > 
> > Kevin Kofler
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: 
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7o/DQACgkQEV1auJxc
Hh65YhAAl2Ym9ht9817hcXRiN1cIMqRceUITnG0TYZNco0ipKbWGIEeF44g/kHw1
coQmthh4J24a5vj6/CgXGozm/InpSkwiitPfsdrZ5rjtdafk83DGeVbEpNvKPu4/
5DngvInCe3K1/W0JyyI9uA2PtXrbnW7QtZfqu7SrKarCReQSwiCFfpAwEpKgq7Ma
xK2/Sidwtz6/wohrEYMs+FEtmzq+8YbkunGza3IKmFOolGGsZNyTmHya5LFu+AuM
VOgmM6LbJdCtgHFYgV0Ag/fvK3ftkIuXPRCiGriO/VRXY1QGnrnLcJXAgdycF5Th
L9HMPKQsLXWD/CLo0dOAZSRw8ls9JQgwste3qMZuE1RimpIyO1UsbFpbEpOJsjb6
ZrYoKPfrVSYhIndfGhTthujkrwAY6lGd33D6YMN8vpZXMCqiYwRS9iJp3tREejFO
dmMsc24BiXCU3pusINakVDc8pAM1tUmP7OEIAFJkl7jLAv4sDXh1tJRyOr6RkS70
fQmvBE7UPs6zJ8wHwGmwbcOoPjemnbZUltmiXM5nIQ1o/Mqx6uP0QwCnOhOd+9tX
4w9fkxecunk0sAWFscaHWoE+wIiDMfM48FWJRKQXdRYdN5g/jeKrBqanK0N9RiI/
46xgJZyGTXmhKjAkINyEo1uw0wFHr7imKLZgmJKDTrhFQGwBReQ=
=9at0
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Gary Buhrmaster]

On Mon, Jun 15, 2020 at 7:48 PM Ben Cotton  wrote:

> == Summary ==
> %cmake macro will be adjusted (-B parameter)
> to use separate build folder (already standardized
> %{_vpath_builddir} macro). 

While there is certainly no requirement for different
distributions to work the same, as I recall (from a
long time ago creating a spec file that works on
both Fedora and Suse) Suse's cmake macro by
default has always done the equivalent of a
"mkdir build; pushd build; cmake .." which seemed
to be more reasonable as a default, and would
apparently mean that packagers that support
multiple distros have to deal with less distro
specific conditionals.

In favor.
___
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: Updated KDE available in EPEL 8

[Sérgio Basto]

On Tue, 2020-06-16 at 07:36 -0700, Troy Dawson wrote:
> On Mon, Jun 15, 2020 at 8:21 PM Sérgio Basto 
> wrote:
> > On Mon, 2020-06-15 at 10:04 -0700, Troy Dawson wrote:
> > > RHEL 8.2 and CentOS 8.2 have an updated qt5.  This updated qt5
> > > allowed
> > > us to update the KDE Plasma Desktop in EPEL8.  We are not at the
> > > following versions.
> > > 
> > > qt5 - 5.12
> > > plasma - 5.18 [1]
> > > kf5 - 5.68 / 19.12
> > > apps - 5.18 / 19.12
> > > 
> > > Installation Instructions:
> > > ### First: install epel-release
> > > rpm -Uvh
> > > https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
> > > 
> > > ### Second: Enable codeready-builder or PowerTools
> > >   subscription-manager repos --enable codeready-builder-for-rhel-
> > > 8-
> > > x86_64-rpms
> > >  If CentOS 8 do
> > >   dnf config-manager --enable PowerTools
> > >    If CentOS Stream do
> > > dnf config-manager --enable Stream-PowerTools
> > > 
> > > ### Third: install KDE
> > > dnf group install "KDE Plasma Workspaces"
> > >   or
> > > dnf group install kde-desktop
> > > (Optional) dnf group install kde-media
> > > (Optional) dnf group install kde-apps
> > > (Optional) dnf install okular
> > > 
> > > ### (Optional) Fourth: Set sddm as desktop manager
> > > ### Required if you started from a minimal install
> > > systemctl set-default graphical.target [if in multi-user.target]
> > > dnf install sddm\*
> > > systemctl enable sddm -f
> > > reboot
> > > 
> > > ### (Optional) If you installed in GNOME
> > > systemctl reload gdm
> > > 
> > > 
> > > Known Issues:
> > > Several (about 50%) settings do not work in System Settings.
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1838801
> > > Help resolving this bug would be appreciated.
> > > It is irritating, but not critical.
> > 
> > Hi,
> > I'm testing Centos 8.2 in a VM with
> > VirtualBox-guest-additions-6.1.10-3.el8.x86_64,  seems to me that
> > undefined symbol:
> > _ZN15KStandardAction25switchApplicationLanguageEPK7QObjectPKcPS0_
> > don't
> > let me start KDE [1] .
> > 
> > Any guess ?
> > 
> > Thank you
> > 
> > [1]
> > Jun 15 23:20:08 localhost sddm-greeter[1663]:
> > file:///usr/share/sddm/themes/01-breeze-fedora/Main.qml:26:1:
> > plugin
> > cannot be loaded for module "org.kde.plasma.core": Cannot load
> > library
> > /usr/lib64/qt5/qml/org/kde/plasma/core/libcorebindingsplugin.so:
> > (/lib64/libKF5XmlGui.so.5: undefined symbol:
> > _ZN15KStandardAction25switchApplicationLanguageEPK7QObjectPKcPS0_)
> > #012 import org.kde.plasma.core 2.0 as PlasmaCore #012
> > 
> 
> Is this a fresh install of CentOS 8.2 or an update of something
> older?
> How did you install kde?
> If it's a fresh install, did you do an update after the install?
> 
> Although the only virtual machines I've tried it on is KVM based
> ones,
> I don't *think*  this is a VirtualBox vs KVM issue.
> It seems to be a too-old or too-new library issue.
> 
> My guess:
> You updated from CentOS 8.1 to 8.2. 

I installed Centos 8 with CentOS-8.1.1911-x86_64-boot.iso. 
Today after doing dnf distro-sync which installed 18 Packages and
upgraded 683 Packages, it starts to work correctly .

Thank you


> You have rpm-fusion installed, and
> there is some package in rpm-fusion that hasn't been rebuilt yet.
> Whatever those packages are, are preventing a complete update to
> CentOS 8.2, and whatever isn't updated is affecting kf5-plasma from
> starting.
> It's a total guess, and I'm not meaning to pick on the rpm-fusion
> people, but since CentOS 8.2 just came out, it's possible they don't
> have everything finished yet.
> 
> Hope this helps.
> Troy
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to 
> epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
-- 
Sérgio M. B.
___
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: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Dan Čermák]

Kevin Kofler  writes:

> Michael Catanzaro wrote:
>> Kevin, the goal is to *simply* these packages:
>> 
>> mkdir -p %{_target_platform}
>> pushd %{_target_platform}
>> %cmake 
>> popd
>> 
>> It's four lines. We get to simplify it down to one line. Proposal
>> owners are provenpackagers and say they will try to fix affected
>> packages. Fine by me?
>
> In the real world, it will end up as:
>
> %if 0%{?fedora} > 32 || 0%{?rhel} > 8
> %cmake
> %else
> mkdir %{_target_platform}
> pushd %{_target_platform}
> %cmake ..
> popd
> %endif

Or you use the new %cmake macro only in the f32, epel8 and master
branch and leave the other branches as they are?

>
> i.e. 8 lines instead of 4, and much less readable. Most specfiles need to 
> work on older distributions too.
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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: Fedora 33 Self-Contained Change proposal: Distribute .repo files for modular repositories from a separate package

[Tomas Orsava]

On 6/15/20 10:10 PM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/ModularReposSubpackage

== Summary ==
Reintroduce the fedora-repos-modular package. Have the
/etc/yum.repos.d/*-modular.repo files in it instead of
fedora-repos.
We install/keep fedora-repos-modular by default, users (admins) can
uninstall it if desired. No defaults are changed.



+1 I would love to see this feature for my personal use.
___
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 33 System-Wide Change proposal: Fedora-Retired-Packages

[Jóhann B . Guðmundsson]

On 16.6.2020 12:21, Kamil Paral wrote:


I'd like Fedora systems to be transparent and honest. If some packages 
need to be removed, tell me about it, and ideally also tell me why 
(e.g. no longer maintained). If possible, tell me how to avoid it 
temporarily (it might be months or years, but unmaintained software 
will break one day unexpectedly), but be clear about the consequences. 
For general users, this information might involve just "important" 
packages (not libraries etc) - we don't do this well at present.
This approach beats "never ever removing anything, at any cost", at 
least for me.


I whole heartedly agree with your take on this but Kevin concerns are valid.

Based on my experience pushing Fedora as an Fedora ambassador to novice 
end users ( subsequently having to install/setup/and support their 
installation as a result of that ), it was enough for the desktop team 
to rearrange locations of apps in menus to scare novice end users away 
from *using* Linux ( yes not just Fedora but Linux altogether ) and them 
wanting to use windows or os-x again, something that they were 
*familiar* with and did not constantly keep changing ( which is why 
Microsoft had to reluctantly keep the old look and feel of Windows ) And 
I know first hand that the Gnome community in Fedora has never gotten 
this right because seemingly trivial changes like tidying up menu's are 
huge changes to the novice end users that operate on familiar look and 
"click here" memory.


To me this is a question of what is Fedora target audience.

It cant be novice end users since those cant install Fedora and afaik 
people cant buy hw with Fedora pre-installed and even if that option was 
available for the novice end users you would have to be a pretty good 
sales person to convince them to abandon something they are familiar 
with ( talking from a first hand experience doing exactly that ) as in 
windows or os-x. ( Arguably there always has been and still is the 
underlying expectation that Fedora users are atleast somewhat familiar 
with Linux and RHEL, basically RHEL administrators I would say )


This is also a question of what constitutes as an "unmaintained 
software" in the distribution. Is it dead upstream, is it awol package 
maintainer, is it poorly maintained packages like the maintainer that 
only appears when there is a pending RHEL release then disappears, is it 
not responding to bugs filed against his or her component etc.


But the act of removing an unmaintained application/package in the 
distribution wont scare people away from using Fedora no more than ( 
even trivial by every count ) changes that the Gnome community has 
historically done in the distribution thus a less of an issue that Kevin 
makes it out to be and leaving something installed on end users system 
can do more harm than good I would say.


Presumably this is also less of an issue as end users stop installing 
application from the distribution but instead do so with flatpaks and at 
one point application will no longer be provided in the distribution ( 
you have to install it from flatpak marketplace).


Just my 2 cents.

JBG
___
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 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Miroslav Suchý]

Dne 16. 06. 20 v 3:05 Neal Gompa napsal(a):
> So I'm confused here, does anyone know why the animated wallpapers
> don't work in KDE Plasma or any other desktop? I personally love
> animated wallpapers and I'd like to see this on my KDE Plasma desktop
> too...
> 

https://store.kde.org/p/1295389

Though, I am not using it. No personal experience.

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

libdockapp SONAME bump .2 -> 3

[Jani Juhani Sinervo]

Hey,

I'm updating libdockapp to version 0.7.3 in Rawhide. The only two
dependencies of this package are `wmacpi`, which I will take care of
rebuilding and fixing, and `wmvolman` which will remain FTBFS until the
maintainer changes it, since the libdockapp upstream has moved the
header files to its own subdirectory of /usr/include.

Regards,
Jani Sinervo
___
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 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Michael Catanzaro]

On Tue, Jun 16, 2020 at 11:22 am, Przemek Klosowski via devel 
 wrote:

IDK how exactly it works, but I see that for instance
f31-backgrounds-animated  has  f31-backgrounds-kde  as a weak 
dependency.


Looks like the F31 package is broken, the Supplements there do not make 
sense and pull in desktop-specific subpackages improperly. This problem 
was identified before the release of F32 and the F32 package is fixed.


___
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 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Przemek Klosowski via devel]

On 6/15/20 9:46 PM, Kevin Fenzi wrote:

On Mon, Jun 15, 2020 at 09:05:42PM -0400, Neal Gompa wrote:

So I'm confused here, does anyone know why the animated wallpapers
don't work in KDE Plasma or any other desktop? I personally love
animated wallpapers and I'd like to see this on my KDE Plasma desktop
too...

I think KDE does support some kind of live/dynamic wallpaper, but it's
done in a completely different way from the gnome implementation.
As far as I know there's no standard there.

Xfce has never supported live wallpapers, the code simply does not
exist.
IDK how exactly it works, but I see that for instance 
f31-backgrounds-animated  has  f31-backgrounds-kde  as a weak dependency.

___
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: Packagers with no corresponding valid bugzilla accounts

[Pierre-Yves Chibon]

On Tue, Jun 16, 2020 at 11:05:00AM -0400, Christopher wrote:
>Why aren't the packager accounts linked to their FAS account alias?
>[1]fa...@fedoraproject.org ? I've been annoyed by FAS-linked services
>trying to use my forwarding address for my account id rather than my FAS
>user id. My forwarding address is subject to change, but the FAS email
>alias is static.

Because they are two different systems and you do not need an account in one to
have an account in the other?
We do not create account on bugzilla for the alias @fp.o automatically (and I
think it's a good thing).


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 33 System-Wide Change proposal: Fedora-Retired-Packages

[Miroslav Suchý]

Dne 16. 06. 20 v 9:56 Vít Ondruch napsal(a):
> 1) It does not reflect, that this is not just about retired packages,
> but also (or mainly?) about subpackages, which we don't retire.
> 
> 2) The point (1) is closely related to -debuginfo packages topic [1]
> which I re-raised recently with not as much attention as I would like.

Both points are valid and good examples. Noted. Thank you.

> Also, I wonder what is wrong with "dnf autoremove", which is supposed to
> remove unused leaf packages, which were not explicitly installed?

On my system it does not want to remove fwupdate-libs.fc29. Hmm, it seems that 
it ignores anything else than fc32 (on my
F32 machine).

-- 
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: Packagers with no corresponding valid bugzilla accounts

[Christopher]

Why aren't the packager accounts linked to their FAS account alias?
fa...@fedoraproject.org ? I've been annoyed by FAS-linked services trying
to use my forwarding address for my account id rather than my FAS user id.
My forwarding address is subject to change, but the FAS email alias is
static.

On Sun, Jun 14, 2020, 15:03 Pierre-Yves Chibon  wrote:

> On Sun, Jun 14, 2020 at 07:09:57PM +0200, Felix Schwarz wrote:
> >
> > Am 13.06.20 um 22:10 schrieb Pierre-Yves Chibon:
> > > bpereto
> >
> > Benjamin was a previous maintainer of borgbackup. After the Python 3.9
> rebuild
> > I noticed that a new ticket was still assigned to him [1]. If I
> understood
> > your email correctly this is because there is no corresponding bugzilla
> account?
> >
> > Any idea how to fix this? There was a non-responsive maintainer process a
> > while ago and I did not hear from him ever since.
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1838161#c1
> > [2] https://pagure.io/fesco/issue/2242
>
> I've just checked the logs of the sync script and that is correct.
> Benjamin's
> lack of valid bugzilla account lead to a failure in the sync script to
> update
> borgbackup.
>
> Since Benjamin is considered MIA, I will remove his account from the
> watchers of
> borgbackup and that should fix the sync.
>
> > > @certbot-sig
> >
> > What can we do here? I'm a member of the sig but I don't know if it has
> an
> > email address.
>
> Each group has normally a mailing list associated with them in FAS, this
> is the
> email that is synced to bugzilla (which is why we recommend the mailing
> list be
> private as it will be CC'ed to bugzilla reports, including private ones).
> So in this case, it looks like no one created the bugzilla account for the
> mailing list linked to the group.
>
>
> 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
>
___
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: Updated KDE available in EPEL 8

[Troy Dawson]

On Mon, Jun 15, 2020 at 8:21 PM Sérgio Basto  wrote:
>
> On Mon, 2020-06-15 at 10:04 -0700, Troy Dawson wrote:
> > RHEL 8.2 and CentOS 8.2 have an updated qt5.  This updated qt5
> > allowed
> > us to update the KDE Plasma Desktop in EPEL8.  We are not at the
> > following versions.
> >
> > qt5 - 5.12
> > plasma - 5.18 [1]
> > kf5 - 5.68 / 19.12
> > apps - 5.18 / 19.12
> >
> > Installation Instructions:
> > ### First: install epel-release
> > rpm -Uvh
> > https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
> >
> > ### Second: Enable codeready-builder or PowerTools
> >   subscription-manager repos --enable codeready-builder-for-rhel-8-
> > x86_64-rpms
> >  If CentOS 8 do
> >   dnf config-manager --enable PowerTools
> >    If CentOS Stream do
> > dnf config-manager --enable Stream-PowerTools
> >
> > ### Third: install KDE
> > dnf group install "KDE Plasma Workspaces"
> >   or
> > dnf group install kde-desktop
> > (Optional) dnf group install kde-media
> > (Optional) dnf group install kde-apps
> > (Optional) dnf install okular
> >
> > ### (Optional) Fourth: Set sddm as desktop manager
> > ### Required if you started from a minimal install
> > systemctl set-default graphical.target [if in multi-user.target]
> > dnf install sddm\*
> > systemctl enable sddm -f
> > reboot
> >
> > ### (Optional) If you installed in GNOME
> > systemctl reload gdm
> >
> >
> > Known Issues:
> > Several (about 50%) settings do not work in System Settings.
> > https://bugzilla.redhat.com/show_bug.cgi?id=1838801
> > Help resolving this bug would be appreciated.
> > It is irritating, but not critical.
>
> Hi,
> I'm testing Centos 8.2 in a VM with
> VirtualBox-guest-additions-6.1.10-3.el8.x86_64,  seems to me that
> undefined symbol:
> _ZN15KStandardAction25switchApplicationLanguageEPK7QObjectPKcPS0_ don't
> let me start KDE [1] .
>
> Any guess ?
>
> Thank you
>
> [1]
> Jun 15 23:20:08 localhost sddm-greeter[1663]:
> file:///usr/share/sddm/themes/01-breeze-fedora/Main.qml:26:1: plugin
> cannot be loaded for module "org.kde.plasma.core": Cannot load library
> /usr/lib64/qt5/qml/org/kde/plasma/core/libcorebindingsplugin.so:
> (/lib64/libKF5XmlGui.so.5: undefined symbol:
> _ZN15KStandardAction25switchApplicationLanguageEPK7QObjectPKcPS0_)
> #012 import org.kde.plasma.core 2.0 as PlasmaCore #012
>

Is this a fresh install of CentOS 8.2 or an update of something older?
How did you install kde?
If it's a fresh install, did you do an update after the install?

Although the only virtual machines I've tried it on is KVM based ones,
I don't *think*  this is a VirtualBox vs KVM issue.
It seems to be a too-old or too-new library issue.

My guess:
You updated from CentOS 8.1 to 8.2. You have rpm-fusion installed, and
there is some package in rpm-fusion that hasn't been rebuilt yet.
Whatever those packages are, are preventing a complete update to
CentOS 8.2, and whatever isn't updated is affecting kf5-plasma from
starting.
It's a total guess, and I'm not meaning to pick on the rpm-fusion
people, but since CentOS 8.2 just came out, it's possible they don't
have everything finished yet.

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

[Bug 1847506] perl-Rose-DB-Object-0.819 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Rose-DB-Object-0.819-1.fc32.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=45792921


-- 
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 1847506] perl-Rose-DB-Object-0.819 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1697629
  --> https://bugzilla.redhat.com/attachment.cgi?id=1697629=edit
[patch] Update to 0.819 (#1847506)


-- 
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 1847506] New: perl-Rose-DB-Object-0.819 is available

[bugzilla]

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

Bug ID: 1847506
   Summary: perl-Rose-DB-Object-0.819 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Rose-DB-Object
  Keywords: FutureFeature, Triaged
  Assignee: wf...@worldbroken.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
wf...@worldbroken.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.819
Current version/release in rawhide: 0.818-1.fc33
URL: http://search.cpan.org/dist/Rose-DB-Object/

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


-- 
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: New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past

[Zdenek Dohnal]

Oh, so the link in downloading script needs to be fixed too.

Thank you for the link!

On 6/16/20 3:35 PM, Tomasz Torcz wrote:
> On Tue, Jun 16, 2020 at 03:23:10PM +0200, Zdenek Dohnal wrote:
>> And please don't try to reinstall plugin. It seems they haven't built a
>> new one yet or they aren't planning to.
>>
>> See http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/
>   Here it is:
>   https://developers.hp.com/hp-linux-imaging-and-printing/plugins
>
>
-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C




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

Re: undefined symbol: pthread_getattr_np, version GLIBC_2.32

[Florian Weimer]

* Igor Raits:

> On Tue, 2020-06-16 at 18:39 +0800, 西木野羰基 wrote:
>> Could please check what version of glibc has been installed during
>> mock build? I can;t find the logs or the build artifacts.
>> But by checking other build yesterday I can found that glibc in koji
>> build is newer than the one on my computer (fedora rawhide x86_64)
>> I think the problem is because koji is using
>> glibc-common-2.31.9000-14.fc33 for f33 and we can only get a
>> 2.31.9000-13.fc33 now.
>> Maybe wait for mirrors to update (and install new glibc) and retry?
>
> That's true, but I am surprised that this is not handled by symbol
> versioning. This function seems to exist for long long time, so why did
> it break just now?

The symbol was moved from libpthread to libc.  The new symbol version is
required so that newly linked applications depend on glibc 2.32 as the
minimum glibc version.  Without it, RPM would not generate correct
dependency information.

You do not get an RPM dependency error in rawhide because there is just
one GLIBC_2.32 symbol version, but the symbol set covered by it is still
evolving.

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

Re: Regarding behaviour of Gnome and Fedora members

[Matthew Miller]

On Fri, Jun 12, 2020 at 02:10:44PM +0200, Emmanuel Seyman wrote:
> I would propose that we keep discussions not related to the development
> of Fedora off the devel@ mailing-list.

Yeah. This is off-topic.

-- 
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: New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past

[Tomasz Torcz]

On Tue, Jun 16, 2020 at 03:23:10PM +0200, Zdenek Dohnal wrote:
> And please don't try to reinstall plugin. It seems they haven't built a
> new one yet or they aren't planning to.
> 
> See http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/

  Here it is:
  https://developers.hp.com/hp-linux-imaging-and-printing/plugins


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

Re: New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past

[Zdenek Dohnal]

On 6/16/20 3:21 PM, Kevin Kofler wrote:
> Zdenek Dohnal wrote:
>> HPLIP released a new version 3.20.6, where most models, which previously
>> required HP plugin, were set to do not require plugin anymore.
>>
>> Although requirement of HP plugin was questionable with some printer
>> models, other models may really needed it and they will not work without
>> it.
> So did they finally implement JBIG2 in the GPL driver? The patent expired a 
> couple years ago.

Do you mean GPL as a license? Either way, HP upstream makes new
releases, but with not so much/any new features or bugfixes. Mostly
adding some new PPDs.

Only jbig2 thing I recall is jbig2dec package which is in Fedora.

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

-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C




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

Re: New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past

[Kevin Kofler]

Zdenek Dohnal wrote:
> HPLIP released a new version 3.20.6, where most models, which previously
> required HP plugin, were set to do not require plugin anymore.
> 
> Although requirement of HP plugin was questionable with some printer
> models, other models may really needed it and they will not work without
> it.

So did they finally implement JBIG2 in the GPL driver? The patent expired a 
couple years ago.

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

Re: New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past

[Zdenek Dohnal]

And please don't try to reinstall plugin. It seems they haven't built a
new one yet or they aren't planning to.

See http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/

On 6/16/20 3:01 PM, Zdenek Dohnal wrote:
>
> Hi all,
>
> I'm HPLIP maintainer in Fedora and I would like to ask *the users
> which have HP printers which needed their HP plugin to test the
> scratch build* of new hplip.
>
> HPLIP released a new version 3.20.6, where most models, which
> previously required HP plugin, were set to do not require plugin anymore.
>
> Although requirement of HP plugin was questionable with some printer
> models, other models may really needed it and they will not work
> without it.
>
> Please try the following scratch builds:
>
> Rawhide:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=45790790
>
> F32:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=45790902
>
> F31:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=45790908
>
> And if the update breaks printing or scanning for you, please let the
> upstream know here:
>
> https://bugs.launchpad.net/hplip
>
>
> Thank you in advance for helping with testing!
>
>
> Zdenek
>
> -- 
> Zdenek Dohnal
> Software Engineer
> Red Hat Czech - Brno TPB-C
>
> ___
> 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

-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C



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

Re: New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past

[Zdenek Dohnal]

There isn't a sucg list, but basically you can check git log at
https://github.com/zdohnal/hplip .

On 6/16/20 3:14 PM, Tomasz Torcz wrote:
> On Tue, Jun 16, 2020 at 03:01:22PM +0200, Zdenek Dohnal wrote:
>> Hi all,
>>
>> I'm HPLIP maintainer in Fedora and I would like to ask *the users which
>> have HP printers which needed their HP plugin to test the scratch build*
>> of new hplip.
>>
>> HPLIP released a new version 3.20.6, where most models, which previously
>> required HP plugin, were set to do not require plugin anymore.
>   Is there a list of printers not requiring plugin anymore?
>   Downloading this plugin was the most cumbersome.  In line with
> Murphys's laws, I was noticing hplip was upgraded, and thus requiring
> re-downloading plugin, when I had to print/scan something urgently.
>
>
-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C




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

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Neal Gompa]

On Tue, Jun 16, 2020 at 9:17 AM Kevin Kofler  wrote:
>
> Michael Catanzaro wrote:
> > Kevin, the goal is to *simply* these packages:
> >
> > mkdir -p %{_target_platform}
> > pushd %{_target_platform}
> > %cmake 
> > popd
> >
> > It's four lines. We get to simplify it down to one line. Proposal
> > owners are provenpackagers and say they will try to fix affected
> > packages. Fine by me?
>
> In the real world, it will end up as:
>
> %if 0%{?fedora} > 32 || 0%{?rhel} > 8
> %cmake
> %else
> mkdir %{_target_platform}
> pushd %{_target_platform}
> %cmake ..
> popd
> %endif
>

You can also do "%cmake -B %{_vpath_builddir}" and that will work on
old and new distro releases alike.


-- 
真実はいつも一つ！/ 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: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Kevin Kofler]

Igor Raits wrote:
> The correct way of doing out-of-source builds is to use `cmake -S . -B
> builddir` and not cd/pushd and other things. Sadly we can't implement
> this enforcement without breaking packages that do `cd/pushd` but we
> will fix them.

The pushd approach has been working since forever, which is why it is used 
in all templates. -S and -B are more recent (and redundant) introductions.

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

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Kevin Kofler]

Michael Catanzaro wrote:
> Kevin, the goal is to *simply* these packages:
> 
> mkdir -p %{_target_platform}
> pushd %{_target_platform}
> %cmake 
> popd
> 
> It's four lines. We get to simplify it down to one line. Proposal
> owners are provenpackagers and say they will try to fix affected
> packages. Fine by me?

In the real world, it will end up as:

%if 0%{?fedora} > 32 || 0%{?rhel} > 8
%cmake
%else
mkdir %{_target_platform}
pushd %{_target_platform}
%cmake ..
popd
%endif

i.e. 8 lines instead of 4, and much less readable. Most specfiles need to 
work on older distributions too.

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

Re: New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past

[Tomasz Torcz]

On Tue, Jun 16, 2020 at 03:01:22PM +0200, Zdenek Dohnal wrote:
> Hi all,
> 
> I'm HPLIP maintainer in Fedora and I would like to ask *the users which
> have HP printers which needed their HP plugin to test the scratch build*
> of new hplip.
> 
> HPLIP released a new version 3.20.6, where most models, which previously
> required HP plugin, were set to do not require plugin anymore.

  Is there a list of printers not requiring plugin anymore?
  Downloading this plugin was the most cumbersome.  In line with
Murphys's laws, I was noticing hplip was upgraded, and thus requiring
re-downloading plugin, when I had to print/scan something urgently.


-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
___
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: undefined symbol: pthread_getattr_np, version GLIBC_2.32

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, 2020-06-16 at 18:39 +0800, 西木野羰基 wrote:
> Could please check what version of glibc has been installed during
> mock build? I can;t find the logs or the build artifacts.
> But by checking other build yesterday I can found that glibc in koji
> build is newer than the one on my computer (fedora rawhide x86_64)
> I think the problem is because koji is using
> glibc-common-2.31.9000-14.fc33 for f33 and we can only get a
> 2.31.9000-13.fc33 now.
> Maybe wait for mirrors to update (and install new glibc) and retry?

That's true, but I am surprised that this is not handled by symbol
versioning. This function seems to exist for long long time, so why did
it break just now?

> 
> Igor Raits  于2020年6月16日周二 下午6:11写道：
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Hello,
> > 
> > I built gitui in koji (f33) yesterday and tried to run it on my
> > laptop
> > with Fedora Rawhide today and it does not work:
> > 
> > gitui: symbol lookup error: gitui: undefined symbol:
> > pthread_getattr_np, version GLIBC_2.32
> > 
> > Did anybody see something similar in other applications? Any ideas
> > what's broken?
> > - --
> > Igor Raits 
> > -BEGIN PGP SIGNATURE-
> > 
> > iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oms4ACgkQEV1auJxc
> > Hh555Q/9FmgXlpDssVtTkkfG+kCk/m0wR4x2EFgXqZFx42YVTZNVnV4IfFP9JRFY
> > QNLQhgFQy4kGkbYaEfnjMgcxNr/kmPppJynDaeOB/7OoquNdtL4TNrmJlM9HHjDv
> > MNMqWzg/RRfi4Mwd7R9JaH/sszi6NrF8Z+ME3/1z6Sj4ookYcWUQUaG2oLp9+P8p
> > NVoHdD7aJZD2x5jsq5/0Hjsko3TBcJhLvQZi4xTfbYQ/NR1MW8vIg8aMuuz0HmBn
> > faNdrvZG09665Fy1d4hUQppu6vjNbyiSxZBE6xm1ApSv23wt7qqYmesnxAskB/In
> > h9uTAkfeYrGYsWT8Sagxf5FTAJoepChmlwS1ypzXHj8WmGVGt1MyjQtFClcJoCR1
> > nktVmzwMcHkstNlNAp+Jkl2fnaF8pwCBT0fKXI0DxKy+L87lvRiWvM8sumLT3yfn
> > +WMceFnNuQUEOvtHWoGdFCGW1KO5oSn/cX3R1IHkbXExP/3ftAIKCI295dPTGdzU
> > bPhtQrwHBJ/E2FArjzOlBh3N0HnNJOuR3U7CXO5XF1klOZRbRhkVDE6esH5MAUqS
> > a/AdWui56hz0sM/RlUfc0Hxj9zBDGNoZZa6d6m5vIN30AqVyqnSFxUgBdB4TxiII
> > mWzO4JtEUnNJ5bgHygfw31U8NpCzg9lMcH2/BpVUU68pomoqazI=
> > =tZrU
> > -END PGP SIGNATURE-
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: 
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oxZIACgkQEV1auJxc
Hh6raw/+JA4UnrNHd3x/adWXtrpJis3eQTy8pzFiyLIxzFZlUGS/RjVeuK77ESsO
DiphTp+9KXZ9QsWJqGlQuO1Epa1WnAYQGXZ3QEBuHgGIdphjEUePAj1+BFoAVVmK
VkRsLEvySJnyMrppWsODYMVfMt5+sHrBtCvT3HSqjoc0CfKK20WVZ8Sf3tNSm44W
twTswCRCR0B0G9oF0m99ql9AktwIKs1SbilGclpx05jGGTm1pwSS7G4RbMzEcO9i
oElH8vRrT9OifESPIIHYxnvP/2zXt3ltBNmR+1jMB8qeISeK1CKqF41q7VCHtcS8
DSPGG7kXJUQxHMlA01VAl3+kcKetPv+0y9R9g4Ymzb3vaTm3b1MlJwrfZtA3/8jv
BzeQhjFR2ANWV4tEHUvA06FJQV4kPfy7Y1adxeXD0me5VxMOvEPNmB0oCNrNDn5V
IJlHMpqWX0Bbpa34NUu744LQcM7GyaircD4whLbG4uWHqbHJ3i8rgx7XGsPeKrAj
kjhsFErKUk+R7/7/7+BFnOU29w63ZjTWxf0hhxVJ3KVrSmUQ0Xh0Fsv1flR8KzFa
lvkCMC9Wd3+uG+dFla9X2B6BDGAKkgQdmlXNeKoulz57TCP3Ai43buYzFEpFGJrD
2HUuJp+qUAlK0/0Fh/0PEzhBwtIYUZv7iwADo5EcV1UUkaWLWYg=
=tvmS
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, 2020-06-16 at 03:47 +0200, Kevin Kofler wrote:
> Neal Gompa wrote:
> > If they build a separate folder manually and are already using the
> > VPATH macros, then there's no change. If they're using a different
> > structure, we can adapt them to the standard VPATH macros, and do
> > other adjustments as needed.
> 
> The common idiom in KDE packages is:
> mkdir %{_target_platform}
> pushd %{_target_platform}
> %{cmake_kf5} ..
> popd
> 
> So:
> 1. Are you going to apply this change also to %{cmake_kf5} or just
> plain
>    %cmake?

I've just updated the change page that clarifies this question. I'm
also surprised that %cmake_kf5 does not use %cmake, but we are not
going to change this as part of this proposal and leave it for anybody
else who might want to work on that.

> 2. If a construct like this is used, I guess we will end up with a
> VPATH
>    inside %{_target_platform}? So the -debugsource package will have
> a
>    nested structure like Russian matrioshka puppets or Chinese boxes?
> 
> > Defaults matter. And upstreams complain about us not doing out of
> > tree
> > builds by default. Some projects even intentionally break in-source
> > builds and packagers shouldn't struggle to figure out how to do the
> > right thing in that circumstance.
> 
> It is unfortunate that some upstreams (including parts of KDE) are
> doing 
> this. This is a very pointless and unhelpful thing to do. I see no
> benefit 
> from disallowing in-source builds, it is just a simple special case
> and 
> normally requires no extra code to support.
> 
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oxS4ACgkQEV1auJxc
Hh6VGA/8DTF4GLhj8yAJVQNn3JA7UyrYKlx89aHpxCQVtJg3SqbnwvZVHwrl2LHx
cDhnbYt7KmzGkVkG3iapdROBXFED80zXaGm4BAOZF9YXUQyphpaker4NkIyjfksx
GE2bD77ZlzP+5bBnSWSkJ6zJtdxVf7KK81V7jOV0tD2DkDJp6VjBvJJZ009PKZha
Exe5cr1bbALT6+j4IQTjTZOAiqxpQPZasb9/5VXz7G+J79ATv3kBpueoJpShba/t
BcTzdUVihBll5jS6BJQkFUhdfjb1kjZ4YndZ7aPSPnpNJFumYEyfkKrm+yIjlkA2
aaSL5Yy0RjHB8k+Sixftvc2sCjbtU6QhRYOOyxYpXXiHnHrev09YD+H2CzR8/FMf
e829Epm2eUDmKA4JEuCWNTwpRS+KZ+ga35GhVWsBzFecSQT8pGaz2Bu9teKZevR0
pnAzlxKt6VnXBHRWj1DtcoNUQbkDNI3/Nu25XwY3GsR/jjYNUl7Z6/UgtJmuodLL
1AZ3P9okMFofcevkD5rI+QPAG2SfEOGZd4ONZBZ9PP3w1gDWM0T0BojFGXYhZ19d
GGxlYvYKf0pmcAiKuoERJ8JFKC8HFYR6Nj2MzLX4odGHAkwAdaeht1LvZVkgNeDb
Ptt0GmxIUt0i6swjXgVvvIQH1G4fTsupXd6ZTgPwQzWNvXosoc4=
=qwEu
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: systemctl status distccd

[Tomasz Torcz]

On Tue, Jun 16, 2020 at 01:59:48PM +0200, Michael J. Baars wrote:
> Hi,
> 
> Since it's awfully quiet on the initscripts-devel mailing list.

  But why this email?  The log you presented shows:

a) distccd not starting because of configuration error (configured to
listen on non-existing 192.168.0.2 address)

b) distccd service running (listening on different address)

  Do you mean that you configured distccd to start after
network-online.target and it did not start after .2 is available?
Well, first you need also Wants=network-online.target, second you need
something providing this target (like NetworkManager-wait-online.service).

  Anyway, this isall guesswork, why have you posted to -devel list?


> [root@tp02 ~]# systemctl status distccd
> ● distccd.service - Distccd A Distributed Compilation Server

> Jun 16 09:35:00 tp02.localdomain distccd[741]: (dcc_listen_by_addr) ERROR: 
> bind of 192.168.0.2:3632 failed: Cannot assign requested address
> 

> [root@tp02 mjbaars1977]# systemctl status distccd
> ● distccd.service - Distccd A Distributed Compilation Server
>  ├─ 945 /usr/bin/distccd --no-detach --daemon 
> --whitelist=/etc/distcc/clients.allow --jobs 4 --listen 192.168.0.3 --allow 
> 192.168.0.0/4


-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
___
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 33 System-Wide Change proposal: CMake to do out-of-source builds

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, 2020-06-16 at 08:37 -0400, Neal Gompa wrote:
> On Tue, Jun 16, 2020 at 6:30 AM Iñaki Ucar 
> wrote:
> > 
> > On Tue, 16 Jun 2020 at 03:09, Neal Gompa 
> > wrote:
> > > 
> > > On Mon, Jun 15, 2020 at 8:22 PM Kevin Kofler <
> > > kevin.kof...@chello.at> wrote:
> > > > 
> > > > How does this affect the many packages that already build in a
> > > > separate
> > > > build folder manually? There are even several specfile
> > > > templates that
> > > > contain the boilerplate for that.
> > > > 
> > > 
> > > If they build a separate folder manually and are already using
> > > the
> > > VPATH macros, then there's no change. If they're using a
> > > different
> > > structure, we can adapt them to the standard VPATH macros, and do
> > > other adjustments as needed.
> > 
> > What if you need several builds with several flags? E.g., something
> > like
> > 
> > %build
> > %cmake -B flag1 -DFLAG=1
> > %make_build -C flag1
> > %cmake -B flag2 -DFLAG=2
> > %make_build -C flag2
> > 
> > %install
> > %make_install -C flag1
> > %make_install -C flag2
> > 
> 
> That still works, CMake processes the _last_ -B set, just like Meson.
> So if you redefine it later, then everything still works.

Yeah, also you should consider switching from %make_build /
%make_install to the %cmake_build / %cmake_install that have -B option,
so it is consistent across all your cmake code in the spec.

> 
> 
> -- 
> 真実はいつも一つ！/ 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
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oxI0ACgkQEV1auJxc
Hh7Y8A/+Pcf+MMN79+wDAx7UymW2f5/fxq1gW7f/2KdXSpDBMNcV5xgn8V6b1Z1A
nodEQ9PoCOLv7V/q2LZlk2QGs62eQxFWIbTSpCkzCGK1EXLgh3WZ8L1fVH09KYHl
NA+eg8FjeQp4eq2wXzY4v3NYhmnJJke4W/WiiaUDZkDQIBRpJ0Wz3ivSQ7R76sH6
lwcNoaN8bGKgetv1WhyWw3BreybCQxigfDzdDHAwt22HGBo5DEkoiw5cx41gLqUO
wewpxclacLEMfy4VXkdDQqAuLdSOfwmFFBold3XSyMUm63bMSQx8lDn9bQW21y4a
etD0PuW/QnMbWiWQNZIgtNWpj1yD+igSDabDxzRQxHNRJ2Klft32JREhf49vxbha
IG0tkzfHpeVy3p7SF6VDvkeCXoqfQTKvBO0ciJA9EZF2LleufSoYOgh16Ip3ZSCU
mU6uhyPTg07dXijo0cgdEVzteLHR1+oDbxdbVldL3AKqJI+Tq9O/PQU/WcJulEtw
iBNoCQLJWaqeZyMheYtTEMq4No5zHBXnsV8Hs2l/gz5DNr7k+yugP07ne3XSPG4U
vRBMGoWNa7DcD9PNcSasQuHvlWoWNfz8/nrO7L5ec0/ss0FmIg5oIWoep/oSKZ7J
apnQ4Xqq5ktibkpyQvX811Fsy+z2ITLN144lsOqOjLF2v1ByLWQ=
=mBUP
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, 2020-06-16 at 12:16 +0200, Kevin Kofler wrote:
> Igor Raits wrote:
> > Example above will stop working,
> 
> So your change breaks hundreds of packages, exactly those that
> already do 
> what you think is the right thing.

The correct way of doing out-of-source builds is to use `cmake -S . -B
builddir` and not cd/pushd and other things. Sadly we can't implement
this enforcement without breaking packages that do `cd/pushd` but we
will fix them.

> Hence, sorry, but I am opposed to this change.
> 
> > but we definitely do not want to have build tree in
> > x86_64-redhat-linux-gnu/x86_64-redhat-linux-gnu/.
> 
> That was my point, yes (and what will happen if it does not error).

As I said it will error out. And we will fix it.

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

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oxDQACgkQEV1auJxc
Hh6ueg//SDqWyj2LAhdrwLS9yp/0pJrrfZ0NqFuhfEBKdG4uhxR0dwULeHZ257iq
uQAHo92e6SAgnDEhTl+EoAcWqoM74Bf9ladXOckY/3WaHPV4QHGKIeQhzCrlaBt0
79vNaQ02Bss7lkr6a33tqem45DNLl80vMLk66otToKSAKce5sUT/mOx6KmEkJDHu
iZykEVERRqSnAJtzgYhhpcT9T1nUVQCO0/0uJUUt1sq0Pr5S5hZPI1I/FTCod7YT
OeMOvryRaPgEMu7iuxQ9gLC1ZkwPnUQX3t8rVs4XxAzydFTIxh7iVQpN1JKvCcBp
jzkY/zY3TPNkKRIIc2oHeoSUDUQ03IT/pAAlv5zDKBpmAoN/E1ZxlYCFD92y2GsD
/VgFCYU8wJeIykWVeFuDpLKmjD1z5d9RFcd8a8tUfswglbMdSEQHNSaI8HIPcAU3
fCiXn9dAjTsujA5qcnZZXcrfGFzJTcxvhlqAjz1cJLyy8y4ogvQ8iQrW2KviF/Tc
06EJ9edPTIaLKk3JN2rq2phOzr99z//PZT/ez7Om6Jh0Ov9CR1x0y+d2DhvToOfZ
St+IjKrghPFPNTojQdMkXT5hNYJ92hn0NAGj90WmvnNvIYowGXMAZR7oDhcWcoOw
N7Ab715wgy426BtvjwzVKg/kBNmGGX4wMDbQ20M7LdJaBcCT7KM=
=lS8S
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Solomon Peachy]

On Tue, Jun 16, 2020 at 02:21:27PM +0200, Kamil Paral wrote:
> You can't say whether it's working, because it has been retired in Fedora,
> it has no maintainer, no testing, no security updates or bug fixes.

"Retired" means it has no maintainer willing to fix a package build 
error, nothing more.  It does not imply the package has been tested, or 
is receiving any sort of bug fixes or security updates.

(I can provide counterexamples of "maintained" packages in Fedora that 
 simply *did not work*, for *multiple releases*.  But it packaged 
 cleanly, so it got shipped.)

Only the final user can determine if they need a specific package or 
not.  Indeed, being installed is a pretty good indication that the user 
actually wanted it.  Do they still want it?  Only they can answer that.

Under no circumstances is it okay to remove a package without being VERY 
EXPLICIT that it is being removed due to it blocking an upgrade.

(In the past, and indeed today, this explicit user consent on upgrades 
 is required, in the form of manually removing the offending package or 
 passing --allowerasing on the DNF command line)

> Nor will broken systems or systems infected by malware because of security
> flaws. The user has freedom to ignore any of our workflows, but the
> defaults should be well-maintained and safe.

"Safe" also means "don't do things the user doesn't expect."

Auto-removing software is a *significant* change in user-visible 
behavior, and it's the non-powerusers that will be the ones impacted the 
most.

> I'd like Fedora systems to be transparent and honest. If some packages need
> to be removed, tell me about it, and ideally also tell me why (e.g. no
> longer maintained). 

Not "ideally", "must" -- because you never, never, never remove stuff 
without expliclt user consent, and the user can't meaningfully consent 
if they're not given enough information to make that determination.

This distinction is crucial -- packages being "removed" is not just part 
of every 'dnf system-upgrade' I've ever done, but also nearly every 
routine 'dnf update' (kernel packages are added/removed, not 
"upgraded").  

And that's the cmdline view; if folks use the GUI tools (ie most users) 
only "updated" packages are shown in the details, not stuff that's being 
added or removed.  How exactly is the user supposed to be informed?

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


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

New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past

[Zdenek Dohnal]

Hi all,

I'm HPLIP maintainer in Fedora and I would like to ask *the users which
have HP printers which needed their HP plugin to test the scratch build*
of new hplip.

HPLIP released a new version 3.20.6, where most models, which previously
required HP plugin, were set to do not require plugin anymore.

Although requirement of HP plugin was questionable with some printer
models, other models may really needed it and they will not work without it.

Please try the following scratch builds:

Rawhide:

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

F32:

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

F31:

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

And if the update breaks printing or scanning for you, please let the
upstream know here:

https://bugs.launchpad.net/hplip


Thank you in advance for helping with testing!


Zdenek

-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C



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

Re: Fedora 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Michael Catanzaro]

On Tue, Jun 16, 2020 at 7:46 am, Michael Catanzaro 
 wrote:
Select the animated background in gnome-control-center and see for 
yourself how it works. :) It's an XML file that describes state 
transitions between static images. Usually only the colors vary, 
transitioning to darker colors at night, lighter colors in the 
morning, standard colors during daytime.


I should add that GNOME upstream has been using animated backgrounds by 
default since... again, I don't remember, a long time. It's not a 
gimmick, it actually looks good and works well.


___
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 33 System-Wide Change proposal: CMake to do out-of-source builds

[Michael Catanzaro]

On Tue, Jun 16, 2020 at 12:16 pm, Kevin Kofler  
wrote:
So your change breaks hundreds of packages, exactly those that 
already do

what you think is the right thing.

Hence, sorry, but I am opposed to this change.


Kevin, the goal is to *simply* these packages:

mkdir -p %{_target_platform}
pushd %{_target_platform}
%cmake 
popd

It's four lines. We get to simplify it down to one line. Proposal 
owners are provenpackagers and say they will try to fix affected 
packages. Fine by me?


___
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 33 System-Wide Change proposal: Fedora-Retired-Packages

[Jiří Eischmann]

Kamil Paral píše v Út 16. 06. 2020 v 14:21 +0200:
> On Tue, Jun 16, 2020 at 12:25 PM Kevin Kofler  > wrote:
> > Kamil Paral wrote:
> > > I'll not talk about implementation, there are more suitable
> > people for
> > > that here. But I'll voice my opinion that automatically retiring
> > software
> > > from Fedora users' computers is a sane and proper thing to do. If
> > a
> > > package is removed from Fedora, it should also be removed from
> > users
> > > computers (during FN+1 upgrade). Of course, we should allow users
> > to keep
> > > it, if they want it. But the default process should happen
> > automatically,
> > > and users should opt-out of automatic retiring, instead of opt-
> > in. Only
> > > this way we can build a secure and reliable operating system.
> > > 
> > > If only power users can opt-out from retiring a package (e.g. by
> > editing
> > > dnf.conf), I don't think that's a problem. Because even though
> > general
> > > users will of course be unhappy when an application they use get
> > > permanently removed during system upgrade, they will be even more
> > unhappy
> > > when their system suddenly breaks in the future, either by
> > unresolved
> > > dependencies, or when the retired app/library causes the system
> > to not
> > > boot or breaks the desktop, because nobody at that points expects
> > and
> > > tests those software interactions. A general user can resolve a
> > missing
> > > app, but they can't resolve a broken OS. If they want to deviate
> > from the
> > > system we provide, it's reasonable to ask them to have certain
> > technical
> > > knowledge, instead of allowing them to shoot themselves in the
> > foot (even
> > > unknowingly, by not doing automatic retirement).
> > 
> > I cannot agree with these statements. I think removing working
> > software from 
> 
> You can't say whether it's working, because it has been retired in
> Fedora, it has no maintainer, no testing, no security updates or bug
> fixes.

+1
Any software which doesn't get maintenance at least on the security
level should be considered by any responsible software provider as
broken these days.

I'd also add that it creates confusion among users. I often read
questions on forums like: "I've got a package XY on my computer with
Fedora 32 upgraded from a previous version, but I cannot install the
same package on a freshly installed Fedora 32. Why?"

Jiri
___
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 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Neal Gompa]

On Tue, Jun 16, 2020 at 8:46 AM Michael Catanzaro  wrote:
>
> On Tue, Jun 16, 2020 at 2:03 pm, Kamil Paral  wrote:
> > The person proposing this Change should supply some video showcasing
> > this, or a very detailed description, otherwise people will have very
> > varying ideas of how this works and looks.
>
> $ sudo dnf install f32-backgrounds-animated
>
> Select the animated background in gnome-control-center and see for
> yourself how it works. :) It's an XML file that describes state
> transitions between static images. Usually only the colors vary,
> transitioning to darker colors at night, lighter colors in the morning,
> standard colors during daytime.
>
> Fedora has supported this for as long as I remember, we just haven't
> used it by default in a long time. (I think we actually shipped an
> animated background by default once before a while back, though it's
> been long enough that I don't remember that for certain.)
>

We did back in Fedora 7, if I recall correctly. :)


-- 
真実はいつも一つ！/ 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: Fedora 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Michael Catanzaro]

On Tue, Jun 16, 2020 at 2:41 am, Kevin Kofler  
wrote:
"select a different frame"? Does that imply that you want to ship the 
full

animated package on all spins, even those that do not support animated
backgrounds, and let each spin pick its own preferred version out of 
the

list (because all will be shipped anyway)?


No, see the existing f32-backgrounds.spec for how the subpackaging 
works. Animated backgrounds are in a separate subpackage that spins do 
not need to install.


___
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 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Michael Catanzaro]

On Tue, Jun 16, 2020 at 2:03 pm, Kamil Paral  wrote:
The person proposing this Change should supply some video showcasing 
this, or a very detailed description, otherwise people will have very 
varying ideas of how this works and looks.


$ sudo dnf install f32-backgrounds-animated

Select the animated background in gnome-control-center and see for 
yourself how it works. :) It's an XML file that describes state 
transitions between static images. Usually only the colors vary, 
transitioning to darker colors at night, lighter colors in the morning, 
standard colors during daytime.


Fedora has supported this for as long as I remember, we just haven't 
used it by default in a long time. (I think we actually shipped an 
animated background by default once before a while back, though it's 
been long enough that I don't remember that for certain.)


___
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 33 System-Wide Change proposal: CMake to do out-of-source builds

[Neal Gompa]

On Tue, Jun 16, 2020 at 6:30 AM Iñaki Ucar  wrote:
>
> On Tue, 16 Jun 2020 at 03:09, Neal Gompa  wrote:
> >
> > On Mon, Jun 15, 2020 at 8:22 PM Kevin Kofler  wrote:
> > >
> > > How does this affect the many packages that already build in a separate
> > > build folder manually? There are even several specfile templates that
> > > contain the boilerplate for that.
> > >
> >
> > If they build a separate folder manually and are already using the
> > VPATH macros, then there's no change. If they're using a different
> > structure, we can adapt them to the standard VPATH macros, and do
> > other adjustments as needed.
>
> What if you need several builds with several flags? E.g., something like
>
> %build
> %cmake -B flag1 -DFLAG=1
> %make_build -C flag1
> %cmake -B flag2 -DFLAG=2
> %make_build -C flag2
>
> %install
> %make_install -C flag1
> %make_install -C flag2
>

That still works, CMake processes the _last_ -B set, just like Meson.
So if you redefine it later, then everything still works.



-- 
真実はいつも一つ！/ 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: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Christopher Engelhard]

I can't speak to the implementation of this, but I am in favour of the
approach in general, with one caveat: I think it is important to
implement this in a way that makes it possible for users to keep
*individual* retired packages around. Blacklisting
fedora-retired-packages is too broad a brush from the user perspective,
and will make it much harder to identify problems.

A question regarding this: What would happen if an update to
fedora-retired-packages obsoletes a package that is present on my system
but listed in dnf's excludepkgs?

Christopher
___
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 33 System-Wide Change proposal: Fedora-Retired-Packages

[Neal Gompa]

On Mon, Jun 15, 2020 at 3:48 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>
> == Summary ==
> All retired packages are obsoleted by `fedora-retired-packages`.
>

This whole process is unnecessary. You're basically asking for
autoremove behavior to occur as part of a distro-sync action. This
boils down to an RFE to the DNF team to extend the distro-sync action
used by system-upgrade to optionally be able to do autoremove at the
same time, and make the system-upgrade plugin actually *do* that by
default.

Let's focus on doing it that way, instead.




--
真実はいつも一つ！/ 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: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Kamil Dudka]

On Tuesday, June 16, 2020 12:18:29 PM CEST Kevin Kofler wrote:
> Igor Raits wrote:
> 
> > Not sure if I follow, what means "can already be done with the existing
> > one"? Does it mean that you can already specify a build dir via CLI and
> > some packages already do (e.g. libsolv)?
> 
> 
> As I wrote elsewhere in the thread, most packages actually do the opposite 
> (which AFAIK has been working for much longer), cd-ing to the build dir and
> specifying the source dir using the CLI (typically "%cmake ..").

Yes.  All the cmake-based packages that I maintain upstream do exactly this.

Kamil

> Kevin Kofler

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

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Kamil Paral]

On Tue, Jun 16, 2020 at 12:25 PM Kevin Kofler 
wrote:

> Kamil Paral wrote:
> > I'll not talk about implementation, there are more suitable people for
> > that here. But I'll voice my opinion that automatically retiring software
> > from Fedora users' computers is a sane and proper thing to do. If a
> > package is removed from Fedora, it should also be removed from users
> > computers (during FN+1 upgrade). Of course, we should allow users to keep
> > it, if they want it. But the default process should happen automatically,
> > and users should opt-out of automatic retiring, instead of opt-in. Only
> > this way we can build a secure and reliable operating system.
> >
> > If only power users can opt-out from retiring a package (e.g. by editing
> > dnf.conf), I don't think that's a problem. Because even though general
> > users will of course be unhappy when an application they use get
> > permanently removed during system upgrade, they will be even more unhappy
> > when their system suddenly breaks in the future, either by unresolved
> > dependencies, or when the retired app/library causes the system to not
> > boot or breaks the desktop, because nobody at that points expects and
> > tests those software interactions. A general user can resolve a missing
> > app, but they can't resolve a broken OS. If they want to deviate from the
> > system we provide, it's reasonable to ask them to have certain technical
> > knowledge, instead of allowing them to shoot themselves in the foot (even
> > unknowingly, by not doing automatic retirement).
>
> I cannot agree with these statements. I think removing working software
> from
>

You can't say whether it's working, because it has been retired in Fedora,
it has no maintainer, no testing, no security updates or bug fixes.


> users' systems is not something we should ever do. I see it as inherently
> incompatible with our "Freedom" principle (what happened to Freedom 0, the
> right to run the software?),


Your freedom is unchanged, you can still do whatever you want with your
system. You can opt out of any process and behavior in Fedora, because full
sources are available. And not only that, we will have a way for power
users to easily opt-out. We might even have a way for general users to
opt-out, if we go the extra mile (but the extra mile is not necessary for
the purpose of this proposal, in my eyes).


> and also with "Features" (as removing an
> application obviously removes its features).


That principle doesn't say that no features will ever be removed.


> And it surely will not make you
> any "Friends" either.
>

Nor will broken systems or systems infected by malware because of security
flaws. The user has freedom to ignore any of our workflows, but the
defaults should be well-maintained and safe.

I'd like Fedora systems to be transparent and honest. If some packages need
to be removed, tell me about it, and ideally also tell me why (e.g. no
longer maintained). If possible, tell me how to avoid it temporarily (it
might be months or years, but unmaintained software will break one day
unexpectedly), but be clear about the consequences. For general users, this
information might involve just "important" packages (not libraries etc) -
we don't do this well at present.
This approach beats "never ever removing anything, at any cost", at least
for me.
___
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 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Kamil Paral]

On Tue, Jun 16, 2020 at 12:24 PM Iñaki Ucar  wrote:

> From what I found after a quick search ("gnome animated background"),
> apparently, it's a video-like effect, but the implementation comprises
> several static images (e.g., a general background and several smaller
> parts) and a file defining transitions (e.g., of those parts over that
> background).
>

The person proposing this Change should supply some video showcasing this,
or a very detailed description, otherwise people will have very varying
ideas of how this works and looks.
___
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

systemctl status distccd

[Michael J. Baars]

Hi,

Since it's awfully quiet on the initscripts-devel mailing list.

Best regards,
Mischa.




distccd.service.d.tar.xz
Description: application/xz-compressed-tar
[root@tp02 ~]# systemctl status distccd
● distccd.service - Distccd A Distributed Compilation Server
 Loaded: loaded (/usr/lib/systemd/system/distccd.service; enabled; vendor 
preset: disabled)
 Active: failed (Result: exit-code) since Tue 2020-06-16 09:35:00 CEST; 
21min ago
Process: 741 ExecStart=/usr/bin/distccd --no-detach --daemon 
--whitelist=/etc/distcc/clients.allow $OPTIONS (code=exited, status=102)
   Main PID: 741 (code=exited, status=102)
CPU: 16ms

Jun 16 09:35:00 tp02.localdomain systemd[1]: Started Distccd A Distributed 
Compilation Server.
Jun 16 09:35:00 tp02.localdomain distccd[741]: (dcc_listen_by_addr) ERROR: bind 
of 192.168.0.2:3632 failed: Cannot assign requested address
Jun 16 09:35:00 tp02.localdomain systemd[1]: distccd.service: Main process 
exited, code=exited, status=102/n/a
Jun 16 09:35:00 tp02.localdomain systemd[1]: distccd.service: Failed with 
result 'exit-code'.

[root@tp02 mjbaars1977]# systemctl status distccd
● distccd.service - Distccd A Distributed Compilation Server
 Loaded: loaded (/usr/lib/systemd/system/distccd.service; enabled; vendor 
preset: disabled)
Drop-In: /etc/systemd/system/distccd.service.d
 └─distccd.service.conf
 Active: active (running) since Tue 2020-06-16 12:47:54 CEST; 46s ago
   Main PID: 945 (distccd)
  Tasks: 5 (limit: 4488)
 Memory: 1.7M
CPU: 20ms
 CGroup: /system.slice/distccd.service
 ├─ 945 /usr/bin/distccd --no-detach --daemon 
--whitelist=/etc/distcc/clients.allow --jobs 4 --listen 192.168.0.3 --allow 
192.168.0.0/4
 ├─ 952 /usr/bin/distccd --no-detach --daemon 
--whitelist=/etc/distcc/clients.allow --jobs 4 --listen 192.168.0.3 --allow 
192.168.0.0/4
 ├─ 994 /usr/bin/distccd --no-detach --daemon 
--whitelist=/etc/distcc/clients.allow --jobs 4 --listen 192.168.0.3 --allow 
192.168.0.0/4
 ├─1038 /usr/bin/distccd --no-detach --daemon 
--whitelist=/etc/distcc/clients.allow --jobs 4 --listen 192.168.0.3 --allow 
192.168.0.0/4
 └─1056 /usr/bin/distccd --no-detach --daemon 
--whitelist=/etc/distcc/clients.allow --jobs 4 --listen 192.168.0.3 --allow 
192.168.0.0/4

Jun 16 12:47:54 tp03.localdomain systemd[1]: Started Distccd A Distributed 
Compilation Server.

___
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: Many packages unnecessarily link to libpython

[Bastien Nocera]

- Original Message -
> Hello everyone,
> 
> As of Python 3.8, python C extensions modules should not link to libpython,
> unless they embed the interpreter in their code. Relevant upstream PR:
> https://github.com/python/cpython/pull/12946
> If your package links to libpython without requiring it, it won't be possible
> to use the python3-debug binary with your python C extension, unless you
> recompile the extension against it.
> 

> hadess libpeas libplist

libpeas embeds an interpreter, so that link is expected. libplist has been 
updated
in rawhide to fix the wrong linkage, but the library name has changed, so a 
couple
of modules might need to be fixed up and rebuilt. gvfs is one of them:
https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/88

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

Technology Write For Us – Submit A Guest Post On Business, Health

[shankar publish]

Publishthispost Write For Us — Submit Guest Post Category accepted Business, 
Technology, Health, Travel, Apps, Gadgets, Social Network, Finance, Education, 
Wellness, Lifestyle. Enhance your website search engine rankings and web 
traffic using guest blogging opportunities for small business owners.
https://publishthispost.com/write-for-us-submit-guest-post/
___
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: undefined symbol: pthread_getattr_np, version GLIBC_2.32

[Florian Weimer]

* Igor Raits:

> I built gitui in koji (f33) yesterday and tried to run it on my laptop
> with Fedora Rawhide today and it does not work:
>
> gitui: symbol lookup error: gitui: undefined symbol:
> pthread_getattr_np, version GLIBC_2.32
>
> Did anybody see something similar in other applications? Any ideas
> what's broken?

The rawhide compose probably lags what's in the buildroot.  Try:

# dnf --enablerepo=local update

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

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Robbie Harwood]

Miroslav Suchý  writes:

> Will be my mom able to write something like:
>  dnf remove $(dnf list extras | awk '{print $1} | grep -v 
> "package-I-still-want")
> ?

Quite possibly.  It is safe to say most of us do not know your mother;
while your mother may be not versed in scripting, plenty of mothers are.

To be clear: I'm sure you had only the best intentions and are speaking
only about your own parent.  However, this kind of example (non-male
assumed to not understand technology) does not foster inclusion (instead
furthering a sexist stereotype).

Some phrases that can be used instead: "a regular user" (what Till
used), "nontechnical user", "non-programmer friend", "a Linux newcomer",
"the average user", etc..

Hope that helps.

Thanks,
--Robbie


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: undefined symbol: pthread_getattr_np, version GLIBC_2.32

[西木野羰基]

Could please check what version of glibc has been installed during
mock build? I can;t find the logs or the build artifacts.
But by checking other build yesterday I can found that glibc in koji
build is newer than the one on my computer (fedora rawhide x86_64)
I think the problem is because koji is using
glibc-common-2.31.9000-14.fc33 for f33 and we can only get a
2.31.9000-13.fc33 now.
Maybe wait for mirrors to update (and install new glibc) and retry?


Igor Raits  于2020年6月16日周二 下午6:11写道：
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hello,
>
> I built gitui in koji (f33) yesterday and tried to run it on my laptop
> with Fedora Rawhide today and it does not work:
>
> gitui: symbol lookup error: gitui: undefined symbol:
> pthread_getattr_np, version GLIBC_2.32
>
> Did anybody see something similar in other applications? Any ideas
> what's broken?
> - --
> Igor Raits 
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oms4ACgkQEV1auJxc
> Hh555Q/9FmgXlpDssVtTkkfG+kCk/m0wR4x2EFgXqZFx42YVTZNVnV4IfFP9JRFY
> QNLQhgFQy4kGkbYaEfnjMgcxNr/kmPppJynDaeOB/7OoquNdtL4TNrmJlM9HHjDv
> MNMqWzg/RRfi4Mwd7R9JaH/sszi6NrF8Z+ME3/1z6Sj4ookYcWUQUaG2oLp9+P8p
> NVoHdD7aJZD2x5jsq5/0Hjsko3TBcJhLvQZi4xTfbYQ/NR1MW8vIg8aMuuz0HmBn
> faNdrvZG09665Fy1d4hUQppu6vjNbyiSxZBE6xm1ApSv23wt7qqYmesnxAskB/In
> h9uTAkfeYrGYsWT8Sagxf5FTAJoepChmlwS1ypzXHj8WmGVGt1MyjQtFClcJoCR1
> nktVmzwMcHkstNlNAp+Jkl2fnaF8pwCBT0fKXI0DxKy+L87lvRiWvM8sumLT3yfn
> +WMceFnNuQUEOvtHWoGdFCGW1KO5oSn/cX3R1IHkbXExP/3ftAIKCI295dPTGdzU
> bPhtQrwHBJ/E2FArjzOlBh3N0HnNJOuR3U7CXO5XF1klOZRbRhkVDE6esH5MAUqS
> a/AdWui56hz0sM/RlUfc0Hxj9zBDGNoZZa6d6m5vIN30AqVyqnSFxUgBdB4TxiII
> mWzO4JtEUnNJ5bgHygfw31U8NpCzg9lMcH2/BpVUU68pomoqazI=
> =tZrU
> -END PGP SIGNATURE-
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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 33 System-Wide Change proposal: CMake to do out-of-source builds

[Iñaki Ucar]

On Tue, 16 Jun 2020 at 03:09, Neal Gompa  wrote:
>
> On Mon, Jun 15, 2020 at 8:22 PM Kevin Kofler  wrote:
> >
> > How does this affect the many packages that already build in a separate
> > build folder manually? There are even several specfile templates that
> > contain the boilerplate for that.
> >
>
> If they build a separate folder manually and are already using the
> VPATH macros, then there's no change. If they're using a different
> structure, we can adapt them to the standard VPATH macros, and do
> other adjustments as needed.

What if you need several builds with several flags? E.g., something like

%build
%cmake -B flag1 -DFLAG=1
%make_build -C flag1
%cmake -B flag2 -DFLAG=2
%make_build -C flag2

%install
%make_install -C flag1
%make_install -C flag2

-- 
Iñaki Úcar
___
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 33 System-Wide Change proposal: Fedora-Retired-Packages

[Kevin Kofler]

Kamil Paral wrote:
> I'll not talk about implementation, there are more suitable people for
> that here. But I'll voice my opinion that automatically retiring software
> from Fedora users' computers is a sane and proper thing to do. If a
> package is removed from Fedora, it should also be removed from users
> computers (during FN+1 upgrade). Of course, we should allow users to keep
> it, if they want it. But the default process should happen automatically,
> and users should opt-out of automatic retiring, instead of opt-in. Only
> this way we can build a secure and reliable operating system.
> 
> If only power users can opt-out from retiring a package (e.g. by editing
> dnf.conf), I don't think that's a problem. Because even though general
> users will of course be unhappy when an application they use get
> permanently removed during system upgrade, they will be even more unhappy
> when their system suddenly breaks in the future, either by unresolved
> dependencies, or when the retired app/library causes the system to not
> boot or breaks the desktop, because nobody at that points expects and
> tests those software interactions. A general user can resolve a missing
> app, but they can't resolve a broken OS. If they want to deviate from the
> system we provide, it's reasonable to ask them to have certain technical
> knowledge, instead of allowing them to shoot themselves in the foot (even
> unknowingly, by not doing automatic retirement).

I cannot agree with these statements. I think removing working software from 
users' systems is not something we should ever do. I see it as inherently 
incompatible with our "Freedom" principle (what happened to Freedom 0, the 
right to run the software?), and also with "Features" (as removing an 
application obviously removes its features). And it surely will not make you 
any "Friends" either.

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

Re: Fedora 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Iñaki Ucar]

On Tue, 16 Jun 2020 at 12:14, Jiri Vanek  wrote:
>
> On 6/16/20 9:18 AM, Kamil Paral wrote:
> > On Mon, Jun 15, 2020 at 10:12 PM Ben Cotton  > > wrote:
> >
> > https://fedoraproject.org/wiki/Changes/DefaultAnimatedBackground
> >
> > == Summary ==
> > Fedora Workstation 33 uses animate background as default.
> >
> >
> > Can somebody enlighten me what an animated background exactly means? Is it 
> > like a video/gif running
> > on your background endlessly in a loop? Or does this mean simply a 
> > wallpaper slideshow, where the
> > wallpaper changes every X minutes/hours (or possibly based on the daytime, 
> > so a different one for
> > the morning/noon/evening/night)? If the latter is correct, am I the only 
> > one who sees the term
> > "animated background" as super-confusing here?
> >
>
>
> I would like to support this qeuestion.
>
> Where  I like animated backgroundsa and am looking forward to have them done 
> right in fedora, what
> kind of animation is in the scope here?

From what I found after a quick search ("gnome animated background"),
apparently, it's a video-like effect, but the implementation comprises
several static images (e.g., a general background and several smaller
parts) and a file defining transitions (e.g., of those parts over that
background).

-- 
Iñaki Úcar
___
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 33 System-Wide Change proposal: CMake to do out-of-source builds

[Kevin Kofler]

Igor Raits wrote:
> Not sure if I follow, what means "can already be done with the existing
> one"? Does it mean that you can already specify a build dir via CLI and
> some packages already do (e.g. libsolv)?

As I wrote elsewhere in the thread, most packages actually do the opposite 
(which AFAIK has been working for much longer), cd-ing to the build dir and 
specifying the source dir using the CLI (typically "%cmake ..").

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

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Kevin Kofler]

Igor Raits wrote:
> Example above will stop working,

So your change breaks hundreds of packages, exactly those that already do 
what you think is the right thing.

Hence, sorry, but I am opposed to this change.

> but we definitely do not want to have build tree in
> x86_64-redhat-linux-gnu/x86_64-redhat-linux-gnu/.

That was my point, yes (and what will happen if it does not error).

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

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Jiri Vanek]

On 6/15/20 10:43 PM, Solomon Peachy wrote:
> On Mon, Jun 15, 2020 at 03:47:33PM -0400, Ben Cotton wrote:
>> What I propose is: As part of the retirement process we add the to
>> fedora-retired-packages:
>>   Obsoletes: foo < %{latestversion+1}
>> And during upgrade from F37->F38 the package will be removed.
> 
> Gah, no.  Just.. no.
> 
> This will silently break otherwise-working software on production 
> systems, and provide no straightforward way to get back to a working 
> state.

Not only production. An good example are games. They are dead for ages, and you 
still like to play them.

As mentioned elsewhere, some dnf --find-unmaintaned-stuff can help here.
> 
>> If the user wants to preserve the package (e.g., because it moved to
>> Copr), he simply uninstalls and protects the installation of
>> fedora-retired-packages. But that will be an informed decision.
> 
> So.. the package is dropped because it's not being maintained, yet.. 
> it's being maintained in copr?  How often does this really happen?
> 
>> The benefits are:
>>  * we do not leave unmaintained packages on a user's machine.
> 
> What about software installed from 3rd-party repositories?  What about 
> packages that were downloaded and installed directly from ISVs?
> 
>>  * We make sure that archaic packages do not break upgrade between two
>> versions of Fedora.
> 
> This is a laudable goal, but... surely a better approach is to improve 
> the diagnostics when faced with upgrade failures?  That way the user 
> will be able to make an informed choice at the time the problem would 
> have occurred, rather than having the software (which they might be 
> reliant upon) silently disappearing.
> 
> I say this as someone who has run into this problem quite often over the 
> years, including on the machine I'm using to write this email.  
> Sometimes the correct solution is to remove the old package, but other 
> times that package is in active use.
> 
> 
>  - Solomon
> 
> 
> ___
> 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
> 


-- 
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jva...@redhat.comM: +420775390109



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