[389-devel] Please Review - remove intentional string leak in rust

[William Brown]

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

https://pagure.io/389-ds-base/issue/51175



—
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: Bundled compiler conundrum

[Tom Stellard]

On 06/25/2020 08:01 PM, Michael Cronenworth wrote:
> Hi,
> 
> Wine has soft-dependencies on two additional pieces of software to provide a 
> "full" experience.
> 
> * wine-gecko - Gecko web browser engine for Wine
> * wine-mono - .NET for Wine
> 
> I package both for Wine. They're typically updated at most a couple times per 
> year. Usually the updates bring with them problems that require major time to 
> fix. A FTBFS for wine-gecko took about two years to fix, but that was an 
> extreme case. Both packages use the MinGW (GCC-based) toolchain to compile 
> and we're lucky enough to also carry that toolchain in Fedora. We may be the 
> only distro to compile from source as other distros carry the binary that 
> upstream provides.
> 
> The bi-weekly Wine update last week brought with it a minor version 
> (5.0.0->5.1.0) wine-mono update. The update itself is not minor. The tarball 
> is now bundling a Clang LLVM-based MinGW toolchain in binary form that is 
> also required to compile the package. My first effort at stripping it out to 
> use our Fedora MinGW toolchain doesn't work with the Clang style CFLAGS they 
> have switched to. Before I spend more time de-bundling:
> 

Are you tying to build with mingw-gcc?  What errors are you getting?

-Tom

> I know bundled libraries are allowed, but what about bundled compilers?
> 
> I have not talked to upstream (Wine) on this change yet. I don't believe 
> upstream Mono, that Wine bases this code on, requires Clang.
> 
> Thanks,
> Michael
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/06/26/report-389-ds-base-1.4.4.3-20200625git98a8287.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

Re: Bundled compiler conundrum

[Omair Majid]

Michael Cronenworth  writes:

> The bi-weekly Wine update last week brought with it a minor version 
> (5.0.0->5.1.0)
> wine-mono update. The update itself is not minor. The tarball is now bundling 
> a
> Clang LLVM-based MinGW toolchain in binary form that is also required to 
> compile the
> package. My first effort at stripping it out to use our Fedora MinGW toolchain
> doesn't work with the Clang style CFLAGS they have switched to. Before I 
> spend more
> time de-bundling:
>
> I know bundled libraries are allowed, but what about bundled compilers?

If I am readying your question correctly, it's not just that wine
bundles compilers and libraries, it's that wine bundles pre-built
binaries of compilers and libraries.

As I understand it, bundling and use of pre-built binaries are two
different issues.

Bundling is allowed.

My reading of the packaging guidelines says using pre-bulit binaries is
not allowed at all:

"""
When you encounter prebuilt binaries in a package you MUST:

 -  Remove all pre-built program binaries and program libraries in %prep
prior to the building of the package. Examples include, but are not
limited to, *.class, *.dll, *.DS_Store, *.exe, *.jar, *.o, *.pyc,
*.pyo, *.egg, *.so, *.swf files.
"""

And

"""
Some software (usually related to compilers or cross-compiler
environments) cannot be built without the use of a previous toolchain or
development environment (open source). If you have a package which meets
this criteria, contact the Fedora Packaging Committee for approval.
Please note that this exception, if granted, is limited to only the
initial build of the package. You may bootstrap this build with a
"bootstrap" pre-built binary, but after this is complete, you must
immediately increment Release, drop the "bootstrap" pre-built binary,
and build completely from source. Bootstrapped packages containing
pre-built "bootstrap" binaries must not be pushed as release packages or
updates under any circumstances.
"""

https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Bundled compiler conundrum

[Michael Cronenworth]

Hi,

Wine has soft-dependencies on two additional pieces of software to provide a "full" 
experience.


* wine-gecko - Gecko web browser engine for Wine
* wine-mono - .NET for Wine

I package both for Wine. They're typically updated at most a couple times per year. 
Usually the updates bring with them problems that require major time to fix. A FTBFS 
for wine-gecko took about two years to fix, but that was an extreme case. Both 
packages use the MinGW (GCC-based) toolchain to compile and we're lucky enough to 
also carry that toolchain in Fedora. We may be the only distro to compile from 
source as other distros carry the binary that upstream provides.


The bi-weekly Wine update last week brought with it a minor version (5.0.0->5.1.0) 
wine-mono update. The update itself is not minor. The tarball is now bundling a 
Clang LLVM-based MinGW toolchain in binary form that is also required to compile the 
package. My first effort at stripping it out to use our Fedora MinGW toolchain 
doesn't work with the Clang style CFLAGS they have switched to. Before I spend more 
time de-bundling:


I know bundled libraries are allowed, but what about bundled compilers?

I have not talked to upstream (Wine) on this change yet. I don't believe upstream 
Mono, that Wine bases this code on, requires Clang.


Thanks,
Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1841308] remove hardcoded requirement for Crypt::Random

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Crypt-PWSafe3-1.22-14.
   ||el8
 Resolution|--- |ERRATA
Last Closed||2020-06-26 01:52:04



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Adam Williamson]

On Thu, 2020-06-25 at 22:30 -0300, Sergio Belkin wrote:
> 
> Well, I strongy disagree whit this move.
> In fact on of the things that I hate of Debian/Ubuntu is the choice of nano
> and the poor version that they offer by default of vi.
> More friendly for end-users? Really?
> Please thinking so, the end-user use GUI's. Nano has no any significative
> advantage over vi and even lesser over vim. What's the wrong with vim?
> Really I don't understand.
> If one end-user wants to use a text editor, he will find kate, gedit and
> the like better options. If you don't like a modal editor, propose a better
> option not a mediocre one. For example, micro is a non-modal editor but
> more powerful that nano.
> If has no real benefit, please could you reconsider it and let the
> community give his voice?
> Thanks in advance.
> SB

This isn't about an editor someone *chooses* to use.

It's about that moment quite soon after you start using Linux, when
you're puzzling your way through something at a console, and something
you do triggers the default editor.

If you are unfortunate enough that the default editor is vi, what
happens next is you spend half an hour trying to figure out what the
*hell* is going on, followed by - depending how much you've learned
about Linux so far, and whether you're at a VT or a desktop terminal -
killing or closing the terminal from somewhere else, or just hard
rebooting the system. (I had literally exactly this experience myself,
back in the year 2000 or so.)

Nothing in vi's default view (if launched with a file, which is what
happens in this case) tells you you need to press 'insert' in order to
actually edit anything. Nothing in vi's default view tells you you have
to type the entirely cryptic sequence ":wq" to save and exit (or gives
you any clue how to exit at all). Nothing in vi's default view even
*tells you that what you're looking at is a text editor called vi*.
vi's intro page tells you a lot of this stuff, but in this scenario you
don't *see* its intro page.

nano's default view:

1. tells you you are in an app called 'GNU nano'
2. actually intuitively works as a text editor - you can move around
the file and use the backspace and delete keys and type stuff
3. provides a handy reference of key combos you can use to get help,
save the file, and exit. Yes, you have to know that ^O means "ctrl+O",
but figuring that out is a lot easier than working out how to drive vi
from scratch.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Adam Williamson]

On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote:
> What about to provide a prompt to the user telling them the difference
> between editors?
> For example, when a new user to fedora first invokes git commit
> without $EDITOR set, a program named fedora-default-editor comes up
> and asks: Which editor do you like?
> User can do his or hers choice and the choice will be remembered by
> setting $EDITOR in his or hers ~/.bashrc
> 
> The fedora-default-editor can be a small script that shows user all
> the difference and set $EDITOR for the user.

It's a nice idea, but the problem with things like this is they
*always* introduce bugs, and often wind up being unmaintained, because
keeping them working is kind of a thankless task.

IMHO it's better to keep things simple and just pick a default. And the
default should definitely be nano. :D
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Samuel Sieb]

On 6/25/20 4:48 PM, Alexander Ploumistos wrote:

On Fri, Jun 26, 2020 at 1:40 AM Peter Hutterer  wrote:


disclaimer: I'm using zsh, not bash but it has the same issue. But IMO you
can't really blame it - how is the completion to know that you want to
install an RPM in the current directory? The correct way would be
 dnf install ./some
and that completes immediately (on zsh). Does that work on bash?


It does. However, if you're trying to avoid typing a path for dnf, you
always get a space right after the folder name when you hit  and
you need to delete it if you want to move further down the tree. For
me that's one of the most annoying things with bash completion for
dnf.


But regardless, that's something to fix in the dnf bash completion 
scripts, not a reason to completely disable completion as the earlier 
poster said.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Make nano the default editor

[Sergio Belkin]

El jue., 25 jun. 2020 a las 21:45, Qiyu Yan ()
escribió:

> What about to provide a prompt to the user telling them the difference
> between editors?
> For example, when a new user to fedora first invokes git commit
> without $EDITOR set, a program named fedora-default-editor comes up
> and asks: Which editor do you like?
> User can do his or hers choice and the choice will be remembered by
> setting $EDITOR in his or hers ~/.bashrc
>
> The fedora-default-editor can be a small script that shows user all
> the difference and set $EDITOR for the user.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>

Well, I strongy disagree whit this move.
In fact on of the things that I hate of Debian/Ubuntu is the choice of nano
and the poor version that they offer by default of vi.
More friendly for end-users? Really?
Please thinking so, the end-user use GUI's. Nano has no any significative
advantage over vi and even lesser over vim. What's the wrong with vim?
Really I don't understand.
If one end-user wants to use a text editor, he will find kate, gedit and
the like better options. If you don't like a modal editor, propose a better
option not a mediocre one. For example, micro is a non-modal editor but
more powerful that nano.
If has no real benefit, please could you reconsider it and let the
community give his voice?
Thanks in advance.
SB
-- 
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1850928] perl-Module-Load-Conditional-0.72 is available

[bugzilla]

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



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

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1850935] perl-Archive-Tar-2.38 is available

[bugzilla]

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



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

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Preparing for ocaml 4.11

[Stephen J. Turnbull]

Jerry James writes:

 > My experience is that the build dependencies in the opam files are of
 > high quality, but that test and documentation dependencies are often
 > omitted.  We could add those manually, so that may not be a big deal.

If you add them manually, maybe upstream would accept a patch based on
that addition?  That could contribute to better support going forward.

Steve

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

[Bug 1850767] Add perl-DateTime-Set to EPEL8 / co-maintainer request

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2020-1a69cd3a87 has been pushed to the Fedora EPEL 8 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1a69cd3a87

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1850928] perl-Module-Load-Conditional-0.72 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1850935] perl-Archive-Tar-2.38 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a32cbcaa37   
tcpreplay-4.3.3-1.el8
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-232e4f7411   
python-django-2.2.13-1.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-18fb909316   
znc-1.8.1-1.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3c9503ab68   
libmp4v2-2.1.0-0.21.trunkREV507.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f64e687c3f   
lynis-3.0.0-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c047cbdfd0   
hostapd-2.9-4.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4d185f6e16   
alpine-2.23-2.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

chromium-83.0.4103.116-2.el8
gnucobol-3.1-3.el8
libconfuse-3.3-1.el8
libxsmm-1.16-2.el8
perl-DateTime-Set-0.3900-12.el8
perl-Set-Infinite-0.65-29.el8
python-catkin_pkg-0.4.22-1.el8
python-rosinstall_generator-0.1.21-1.el8
resalloc-3.3-1.el8
snapd-2.45.1-1.el8
trojan-1.16.0-4.el8

Details about builds:



 chromium-83.0.4103.116-2.el8 (FEDORA-EPEL-2020-6e0d8564ec)
 A WebKit (Blink) powered web browser

Update Information:

Update to 83.0.4103.116. Fixes CVE-2020-6509.    Black Lives Matter. Saying
this does not mean that other lives do not matter. It should not be
controversial to say this. If I say Chromium updates matter, it does not mean
that other Fedora packages do not matter, it means that a Chromium update is
needed to fix this giant pile of severe security vulnerabilities, here, today,
now:  CVE-2020-6463 CVE-2020-6465 CVE-2020-6466 CVE-2020-6467 CVE-2020-6468
CVE-2020-6469 CVE-2020-6470 CVE-2020-6471 CVE-2020-6472 CVE-2020-6473
CVE-2020-6474 CVE-2020-6475 CVE-2020-6476 CVE-2020-6478 CVE-2020-6479
CVE-2020-6480 CVE-2020-6481 CVE-2020-6482 CVE-2020-6483 CVE-2020-6484
CVE-2020-6485 CVE-2020-6486 CVE-2020-6487 CVE-2020-6488 CVE-2020-6489
CVE-2020-6490 CVE-2020-6491 CVE-2020-6505 CVE-2020-6506 CVE-2020-6507  In making
that analogy, I do not intend to trivialize BLM. In no way do I mean to compare
the lives of people to a silly web browser update. People are infinitely
important than software.  But since I'm here to push this software update out, I
am also choosing to say clearly and unambiguously that Black Lives Matter.
Open Source proves that many voices, many contributions, together can change the
world. It depends on it. This is my voice.

ChangeLog:

* Tue Jun 23 2020 Tom Callaway  - 83.0.4103.116-2
- do not force ozone into x11
* Tue Jun 23 2020 Tom Callaway  - 83.0.4103.116-1
- update to 83.0.4103.116
* Thu Jun 18 2020 Tom Callaway  - 83.0.4103.106-1
- update to 83.0.4103.106
- remove duplicate ServiceWorker fix
- add fix to work around gcc bug on aarch64
- disable python byte compiling (we do not need it)
* Tue Jun 16 2020 Tom Callaway  - 83.0.4103.97-5
- add ServiceWorker fix
* Mon Jun 15 2020 Tom Callaway  - 83.0.4103.97-4
- use old cups handling on epel7
- fix skia attribute overrides with gcc
* Wed Jun 10 2020 Tom Callaway  - 83.0.4103.97-3
- fix issue on epel7 where linux/kcmp.h does not exist
* Mon Jun  8 2020 Tom Callaway  - 83.0.4103.97-2
- more fixes from gentoo
* Sun Jun  7 2020 Tom Callaway  - 83.0.4103.97-1
- update to 83.0.4103.97
* Tue Jun  2 2020 Tom Callaway  - 83.0.4103.61-1
- update to 83.0.4103.61
- conditionalize and disable remoting

References:

  [ 1 ] Bug #1837877 - CVE-2020-6465 chromium-browser: Use after free in reader 
mode
https://bugzilla.redhat.com/show_bug.cgi?id=1837877
  [ 2 ] Bug #1837878 - CVE-2020-6466 chromium-browser: Use after free in media
https://bugzilla.redhat.com/show_bug.cgi?id=1837878
  [ 3 ] Bug #1837879 - CVE-2020-6467 chromium-browser: Use after free in WebRTC
https://bugzilla.redhat.com/show_bug.cgi?id=1837879
  [ 4 ] Bug #1837880 - CVE-2020-6468 chromium-browser: Type Confusion in V8
https://bugzilla.redhat.com/show_bug.cgi?id=1837880
  [ 5 ] Bug #1837882 - CVE-2020-6470 chromium-browser: Insufficient validation 
of untrusted input in clipboard
https://bugzilla.redhat.com/show_bug.cgi?id=1837882
  [ 6 ] Bug #1837883 - CVE-2020-6471 chromium-browser: Insufficient policy 
enforcement in developer tools
https://bugzilla.redhat.com/show_bug.cgi?id=1837883
  [ 7 ] Bug #1837884 - CVE-2020-6472 chromium-browser: Insufficient policy 
enforcement in developer tools
https://bugzilla.redhat.com/show_bug.cgi?id=1837884
  [ 8 ] Bug #1837885 - CVE-2020-6473 chromium-browser: Insufficient policy 
enforcement in Blink
 

[Bug 1846729] perl-CPAN-2.28 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-CPAN-2.28-1.fc33   |perl-CPAN-2.28-1.fc33
   |perl-CPAN-2.28-1.fc32   |perl-CPAN-2.28-1.fc32
   ||perl-CPAN-2.28-1.fc31



--- Comment #7 from Fedora Update System  ---
FEDORA-2020-b8ab59e2b6 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1846509] perl-Devel-Gladiator-0.08 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Devel-Gladiator-0.08-1 |perl-Devel-Gladiator-0.08-1
   |.fc33   |.fc33
   |perl-Devel-Gladiator-0.08-1 |perl-Devel-Gladiator-0.08-1
   |.fc32   |.fc32
   ||perl-Devel-Gladiator-0.08-1
   ||.fc31



--- Comment #7 from Fedora Update System  ---
FEDORA-2020-1c4961b88b has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1818509] perl-Tk-804.035 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1818509
Bug 1818509 depends on bug 1803711, which changed state.

Bug 1803711 Summary: perl-Tk-804.034-9.fc33 FTBFS: t/entry.t test fails
https://bugzilla.redhat.com/show_bug.cgi?id=1803711

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




-- 
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 1849996] perl-ExtUtils-MakeMaker-7.46 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-ExtUtils-MakeMaker-7.4 |perl-ExtUtils-MakeMaker-7.4
   |6-1.fc33|6-1.fc33
   ||perl-ExtUtils-MakeMaker-7.4
   ||6-1.fc32
 Resolution|--- |ERRATA
Last Closed||2020-06-26 00:46:28



--- Comment #6 from Fedora Update System  ---
FEDORA-2020-cd0ff64b3c has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1803711] perl-Tk-804.034-9.fc33 FTBFS: t/entry.t test fails

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Tk-804.035-1.fc33  |perl-Tk-804.035-1.fc33
   ||perl-Tk-804.035-1.fc32
 Resolution|--- |ERRATA
Last Closed||2020-06-26 00:45:54



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1818509] perl-Tk-804.035 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Tk-804.035-1.fc33  |perl-Tk-804.035-1.fc33
   ||perl-Tk-804.035-1.fc32
 Resolution|--- |ERRATA
Last Closed||2020-06-26 00:45:57



--- Comment #5 from Fedora Update System  ---
FEDORA-2020-a726a87414 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Qiyu Yan]

What about to provide a prompt to the user telling them the difference
between editors?
For example, when a new user to fedora first invokes git commit
without $EDITOR set, a program named fedora-default-editor comes up
and asks: Which editor do you like?
User can do his or hers choice and the choice will be remembered by
setting $EDITOR in his or hers ~/.bashrc

The fedora-default-editor can be a small script that shows user all
the difference and set $EDITOR for the user.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Make nano the default editor

[Matthew Miller]

On Thu, Jun 25, 2020 at 08:50:23PM +0200, Jan Kratochvil wrote:
> This is another step trying to make Fedora end-user friendly while the
> only effect is making it hostile to developers. As Fedora will never be
> used by end-users as it conflicts with Fedora's foundation Freedom. With
> each such step it takes more and more effort to make a new Fedora
> installation usable by a developer (setenforce 0, dnf remove
> bash-completion, remove rhgb quiet etc.).

Fedora, the Project, has a lot of developers involved. Some of us are
interested in making things just for our own use -- that's fine. Others are
very interested in making solutions that are actually used by these
end-users -- and it turns out they're reasonably successful, because we
actually *have* plenty of non-developer end users.

But, if you don't like our offerings that are targetted that way, I suggest
you make a spin or remix that has all of defaults _you_ want. Make it appeal
to the specific developer audience you have in mind with the things that
make sense to you, and see who else is interested in collaborating on it.


-- 
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: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Alexander Ploumistos]

On Fri, Jun 26, 2020 at 1:40 AM Peter Hutterer  wrote:
>
> disclaimer: I'm using zsh, not bash but it has the same issue. But IMO you
> can't really blame it - how is the completion to know that you want to
> install an RPM in the current directory? The correct way would be
> dnf install ./some
> and that completes immediately (on zsh). Does that work on bash?

It does. However, if you're trying to avoid typing a path for dnf, you
always get a space right after the folder name when you hit  and
you need to delete it if you want to move further down the tree. For
me that's one of the most annoying things with bash completion for
dnf.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Make nano the default editor

[Peter Hutterer]

On Thu, Jun 25, 2020 at 11:38:13PM +0200, Jan Kratochvil wrote:
> On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote:
> > I'm not sure why you think end-users can't use a free OS.
> 
> First steps of end-users is to install Chrome, Spotify and VirtualBox.
> So there is left no advantage of a Free OS.
> 
> 
> > I've run with SELinux enabled for years, rarely if ever causes problems
> > for typical stuff.
> 
> Sooner or later something does not work. I do not want to open this can of
> worms whether SELinux yes or not, it may be a good idea but IMNSHO it is not
> for a development machine.
> 
> 
> > I have no idea why you'd remove a useful tool like bash-completion.  It
> > has lots of things useful for developers.
> 
> I agree the idea of bash-completion is nice. But it is so severly incomplete
> it is more a burden than help. Unfortunately I no longer remember all the bugs
> I faced before I started removing it years ago but a simple one is:
> 
> $ wget -O somepackage.rpm https://...
> $ dnf install som
> 
> $ dnf install sombok-

disclaimer: I'm using zsh, not bash but it has the same issue. But IMO you
can't really blame it - how is the completion to know that you want to
install an RPM in the current directory? The correct way would be
dnf install ./some
and that completes immediately (on zsh). Does that work on bash?

Cheers,
   Peter

 
> > Unless you are doing kernel development, why do you care what the kernel
> > messages say?  On my systems, they go by too fast to read anyway.
> 
> When it locks up (during updating firmware on my Athlon machine) I see just
> a black screen. When I reboot without rhgb/quiet the problem is not
> reproducible as it happens only rarely. There are many reasons why kernels
> sometimes fail to boot, why to give up on troubleshooting?
> 
> 
> Jan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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: Make nano the default editor

[Samuel Sieb]

On 6/25/20 4:11 PM, Chris Murphy wrote:

On Thu, Jun 25, 2020 at 3:38 PM Jan Kratochvil
 wrote:


On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote:

Unless you are doing kernel development, why do you care what the kernel
messages say?  On my systems, they go by too fast to read anyway.


When it locks up (during updating firmware on my Athlon machine) I see just
a black screen. When I reboot without rhgb/quiet the problem is not
reproducible as it happens only rarely. There are many reasons why kernels
sometimes fail to boot, why to give up on troubleshooting?


I think we need more complete bug reports about these kinds of
problems, and fix them, rather than default to showing startup scroll.
I don't have this problem very often and I use rawhide kernels. And
where I run stable kernels I can't even remember the last time I
needed to see the startup scroll for troubleshooting. It's easy to get
it unhidden though - hit Esc.


I agree with your points, but pressing ESC only reverses the "rhgb" 
part, the kernel output is still "quiet".

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Make nano the default editor

[Chris Murphy]

On Thu, Jun 25, 2020 at 3:38 PM Jan Kratochvil
 wrote:
>
> On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote:
> > I'm not sure why you think end-users can't use a free OS.
>
> First steps of end-users is to install Chrome, Spotify and VirtualBox.
> So there is left no advantage of a Free OS.

They are popular but by no means universal. I don't install any of
those three things.


> I agree the idea of bash-completion is nice. But it is so severly incomplete
> it is more a burden than help. Unfortunately I no longer remember all the bugs
> I faced before I started removing it years ago but a simple one is:
>
> $ wget -O somepackage.rpm https://...
> $ dnf install som
> 
> $ dnf install sombok-

You're right this is bad - i mistype things all the time and yet hit
tab and it just stalls out and is faster to command C three times and
start over.


>
>
> > Unless you are doing kernel development, why do you care what the kernel
> > messages say?  On my systems, they go by too fast to read anyway.
>
> When it locks up (during updating firmware on my Athlon machine) I see just
> a black screen. When I reboot without rhgb/quiet the problem is not
> reproducible as it happens only rarely. There are many reasons why kernels
> sometimes fail to boot, why to give up on troubleshooting?

I think we need more complete bug reports about these kinds of
problems, and fix them, rather than default to showing startup scroll.
I don't have this problem very often and I use rawhide kernels. And
where I run stable kernels I can't even remember the last time I
needed to see the startup scroll for troubleshooting. It's easy to get
it unhidden though - hit Esc.


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

[Bug 1851257] New: perl-File-Map-0.67 is available

[bugzilla]

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

Bug ID: 1851257
   Summary: perl-File-Map-0.67 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-File-Map
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.67
Current version/release in rawhide: 0.66-5.fc32
URL: http://search.cpan.org/dist/File-Map/

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


-- 
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: Preparing for ocaml 4.11

[Jerry James]

On Thu, Jun 25, 2020 at 4:16 AM Dan Čermák
 wrote:
> %generate_buildrequires could be used to parse the opam file from the
> tarball and extract the dependent opam packages from the depends:
> array. E.g. the following:

I've been thinking along those lines as well.  More automation would be great.

> The hypothetical opam2spec would be certainly also a huge improvement,
> as I think that most ocaml packages could be completely autogenerated.

My experience is that the build dependencies in the opam files are of
high quality, but that test and documentation dependencies are often
omitted.  We could add those manually, so that may not be a big deal.

I have found myself copying lots of boilerplate from spec file to spec
file while adding packages.  I think I've only encountered a few
variations, which seem to be centered around the chosen build tool:
- dune
- topkg
- ocamlbuild
- ocamlc/ocamlopt

with increasing entropy as you go down the list. :-)

> But as you already said, the devil is most likely in the details, so
> maybe we should start collecting ideas and potential pitfalls first? I
> have therefore also cc'd Olaf, who takes care of Ocaml in
> openSUSE. I would hope that we can coordinate our efforts, as Olaf has
> some pretty nice ocaml macros that automatically generate file lists for
> the subpackages (thereby already simplifying packaging quite a bit).

By all means, let's draw from the experiences of those who have
traveled this road already.  Olaf, thanks for chiming in.  I'm eager
to learn from your experiences.

I'm glad the idea of opam2spec was brought up.  I've been thinking
about that, and a couple of other tools:

Tool 1: visualize package dependencies

The idea is to pull dependency information from upstream sources [1],
then draw a graph representing the dependencies.  We distinguish
between different kinds of dependencies:
- build
- documentation
- test
and further distinguish each dependency as "required" or "optional".
The graph uses colors, line styles, or both to distinguish between the
various dependency types.

I want an option to highlight dependency loops (perhaps cycling
through them one at a time if there is more than one).  There sure are
a lot of those in the OCaml world (when testing and documentation
dependencies are included).

Finally, I want the tool to help me visualize the effects of various
strategies for breaking loops.  That is, I want the tool to
automatically find some way of breaking loops so that a directed
acyclic graph is produced.  For example, I might say that when loops
are broken, the edges to remove are chosen to minimize the number of
edge removals, and use this preference order on the edge types (from
most preferred to least preferred type to remove):
- optional test
- required test
- optional documentation
- required documentation
- optional build
- required build

The tool should make it easy for me to select different orderings of
the preferred types, and give me a count of the number of removed
edges in each case.  Finding a minimal set of edges to remove makes
this an expensive operation in the general case, but I expect that the
typical use of such a tool would be on a few hundred nodes at most,
which shouldn't be a big deal on modern computers.

This tool will help me decide which dependencies should be hidden
behind a %bcond_with of one kind or another.  In particular, I'm
interested in using %bcond_with bootstrap because of the next tool.

Tool 2: compute a build order

Such a tool has been mentioned on this mailing list a number of times.
Richard Jones has a script that does this for OCaml, but I think it
could be generalized to RPM packages in general with some effort.  It
would work something like this:

Stage 1: read spec files (possibly specified as a list of checked-out
git repositories, like Richard's script) to generate two lists per
input:
- BuildRequires when --with-bootstrap is given
- BuildRequires when --without-bootstrap is given
If the two lists are identical, then discard the --with-bootstrap list.

Stage 2: Depsolve to convert each list into a list of package names;
i.e. convert logical, file, and boolean dependencies into explicit
package names.  If there are two lists, check again if they are
identical (they shouldn't be, but let's be careful), and discard the
--with-bootstrap list if so.

Stage 3: Construct a graph with one node for each list, labeled with
the name of the package/spec file from which the list was generated.
If it is a --with-bootstrap list, then give the node type BOOTSTRAP,
otherwise give it type NORMAL.

Stage 4: For each list L and each package P in L, if there are no
nodes in the graph corresponding to P, then use repoquery to get a
list of --without-bootstrap BuildRequires for P.  Make a node for P
and give it type DONOTBUILD.

Stage 5: For each node N in the graph, if N's list of BuildREquires
contains another node M in the graph, then add an edge from M to N.
If there are both BOOTSTRAP and 

Re: Please BuildRequire python3-setuptools explicitly

[Artur Iwicki]

> suve   copydeps dnstwist python-ssdeep
Fixed in rawhide (just dist-git, didn't run the builds). Should there be a new 
release for any of these, I'll fix it for F32/31, too.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: wireguard kmod package

[Neal Gompa]

On Thu, Jun 25, 2020 at 6:04 PM Joe Doss  wrote:
>
>
>
> On June 25, 2020 4:50:12 PM Justin Forbes  wrote:
>
>> On Thu, Jun 25, 2020 at 6:33 AM Leigh Scott  wrote:
>>>
>>>
 From what I understood of the thread it's purely removing the akmod
 and the new kernels have the module so how does it break their VPNs?
>>>
>>>
>>> If you remove akmod-wireguard it will also remove the wireguard package 
>>> which will cause the VPN to stop functioning.
>>> Wireguard/wireguard-tools is required for a working VPN.
>>
>>
>> That would be a rather serious flaw in the wireguard tools package to
>> have a dep on akmod-wireguard when it has been upstream and included
>> in the Fedora kernel-modules package for a few months at this point.
>
>
> wirerguard-tools has no dep on akmod-wireguard? Unless I'm misunderstanding 
> the point you are trying to make here?

The Fedora wireguard-tools package would probably have a conditional
dep for the wireguard ko if it was going to have any at all:

Requires: (kmod(wireguard.ko) if kernel)

That makes it nice in containers and still ensures that if there is a
kernel installed, the kmod would be present.


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

[Joe Doss]

On June 25, 2020 4:50:12 PM Justin Forbes  wrote:


On Thu, Jun 25, 2020 at 6:33 AM Leigh Scott  wrote:



From what I understood of the thread it's purely removing the akmod
and the new kernels have the module so how does it break their VPNs?


If you remove akmod-wireguard it will also remove the wireguard package 
which will cause the VPN to stop functioning.

Wireguard/wireguard-tools is required for a working VPN.


That would be a rather serious flaw in the wireguard tools package to
have a dep on akmod-wireguard when it has been upstream and included
in the Fedora kernel-modules package for a few months at this point.


wirerguard-tools has no dep on akmod-wireguard? Unless I'm misunderstanding 
the point you are trying to make here?


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Packager Dashboard available for testing

[Iñaki Ucar]

Yesterday I fixed a FTBFS, but it's still showing in my dashboard. I
suppose that it takes some time to update, but how long should I
expect it to show there until I should suspect that there's some bug?

Iñaki

On Wed, 24 Jun 2020 at 11:20, Josef Skladanka  wrote:
>
> Iñaki,
>
> looking at your dashboard overview, my guess would be that only one of
> the packages has any bugs/updates/prs/... since we "know" you have six
> packages (shown in the header), but only one is shown in the
> dashboard. So according to our information, the other five packages
> just don't need any attention.
>
> If the data is incomplete, please report a bug showing what's missing
> so we can investigate.
> Thank you,
>
> josef
>
> On Wed, Jun 24, 2020 at 11:06 AM Iñaki Ucar  wrote:
> >
> > Congrats for the great work!
> >
> > One question. I don't have many packages, but I only see one of them. Why?
> >
> > Iñaki
> >
> > On Tue, 23 Jun 2020 at 18:35, Josef Skladanka  wrote:
> > >
> > > Hi,
> > >
> > > We'd like to announce public testing of the Packager Dashboard - a new
> > > service for Fedora package maintainers aiming to provide all relevant
> > > data: FTBFS/FTI status (from both Bugzilla, Koschei and health check),
> > > orphan warnings, bugzillas, pull requests, active overrides and
> > > updates - at a single place in an easy to read and filter way.
> > >
> > > The Dashboard is now available: https://packager.fedorainfracloud.org/
> > >
> > > Packager Dashboard leverages caching in the Oraculum backend to
> > > significantly speed-up loading times with comparison to querying all
> > > the relevant resources separately. We, of course, can't cache the
> > > entire Bugzilla, Pagure, Bodhi... so we only cache data for users who
> > > visit Packager Dashboard at least once per 14 days. Please keep in
> > > mind that the first load for a “new” user might take a while. Most of
> > > the data sources are refreshed every hour.
> > >
> > > You can use the Dashboard for individual accounts as well as for FAS 
> > > groups.
> > >
> > > We'd love to hear your feedback. Please keep in mind that this is
> > > testing deployment - it's currently running on a server with very
> > > limited resources and we're aiming for production deployment on
> > > CommuniShift during this summer.
> > >
> > > Feel free to provide ideas or bug reports at
> > > https://pagure.io/fedora-qa/packager_dashboard or simply send an email
> > > reply to this thread with all kinds of feedback.
> > >
> > > I'd like to mention the other people who made this possible:
> > >  - Miro Hrončok (churchyard) - Original idea
> > > 
> > > and ideas for data to display
> > >  - František Zatloukal - Backend 
> > >  - Lukáš Brabec - Frontend 
> > > 
> > >
> > > Josef
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct: 
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: 
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> >
> >
> >
> > --
> > Iñ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
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Iñ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: wireguard kmod package

[Ian McInerney]

On Thu, Jun 25, 2020 at 10:49 PM Justin Forbes  wrote:

> ...snip...
>


> That would be a rather serious flaw in the wireguard tools package to
> have a dep on akmod-wireguard when it has been upstream and included
> in the Fedora kernel-modules package for a few months at this point.
>
>
The wireguard-tools package in the Fedora repo doesn't have a dependency on
any kmods/akmods [1]. The old package that was in RPMFusion (called just
wireguard) pulled in the kmod. Also, it appears that all of the RPMFusion
packages were retired in F32, so they don't exist in F32+.

-Ian

https://src.fedoraproject.org/rpms/wireguard-tools/blob/master/f/wireguard-tools.spec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1851246] New: perl-constant-tiny: FTBFS with Perl 5.32

[bugzilla]

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

Bug ID: 1851246
   Summary: perl-constant-tiny: FTBFS with Perl 5.32
   Product: Fedora
   Version: rawhide
   URL: https://koschei.fedoraproject.org/package/perl-constan
t-tiny
Status: NEW
 Component: perl-constant-tiny
  Assignee: ppi...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
   Link ID: CPAN 131757
Classification: Fedora



Description of problem:
Package perl-constant-tiny fails to build from source in Fedora rawhide with
perl 5.32.

Attempt to reload constant.pm aborted.
Compilation failed in require at t/constant.t line 16.
BEGIN failed--compilation aborted at t/constant.t line 16.
# Looks like your test exited with 255 before it could output anything.
t/constant.t .. 
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 95/95 subtests


-- 
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: Make nano the default editor

[Jan Kratochvil]

On Thu, 25 Jun 2020 21:58:28 +0200, Jonathan Wakely wrote:
> try 'ls $HOME/' without the direxpand
> option set, and tell me what on earth that is for.

It works as expected, what is the problem? Using ctrl-e instead of direxpand
but keeping there $HOME/ may be what one wants.


> the only thing I absolutely insist on
> changing on a new Fedora install is to disable abrt. No, I don't want
> to report it to bugzilla every time a unit test or quick hacked
> together piece of code terminates abnormally.

ABRT primarily crashes machine used for development.
I gave up on reopening the Bug after it always gets EOL-closed unfixed:
-fsanitize=address locks up abrt-hook-ccpp
https://bugzilla.redhat.com/show_bug.cgi?id=1164548


Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: wireguard kmod package

[Justin Forbes]

On Thu, Jun 25, 2020 at 6:33 AM Leigh Scott  wrote:
>
> > From what I understood of the thread it's purely removing the akmod
> > and the new kernels have the module so how does it break their VPNs?
>
> If you remove akmod-wireguard it will also remove the wireguard package which 
> will cause the VPN to stop functioning.
> Wireguard/wireguard-tools is required for a working VPN.

That would be a rather serious flaw in the wireguard tools package to
have a dep on akmod-wireguard when it has been upstream and included
in the Fedora kernel-modules package for a few months at this point.

Either way, the kernel certainly isn't going to obsolete a package
from a non fedora repository, and kernel modules don't exist in the
fedora repositories, so there isn't much that we can do from the
fedora end.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Make nano the default editor

[Ian McInerney]

On Thu, Jun 25, 2020 at 9:58 PM Kamil Dudka  wrote:

> ...snip...
>
> Gentoo Linux uses the /etc/env.d tree to globally set environment
> variables:
>
> https://devmanual.gentoo.org/tasks-reference/environment/index.html
>
> It worked there long time before systemd was invented.  But clearing this
> up in Fedora would ask for a separate system-wide change I guess...
>
> Kamil
>

Isn't /etc/profile.d more inline with the FHS though? The FHS calls out
/etc/profile as being the "systemwide initialization file for sh shell
logins," so the profile.d directory would be the natural extension to that.
I don't see a mention of an env or evn.d in the FHS at all.

-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

[Bug 1851243] perl-Test-Fake-HTTPD: FTBFS in Fedora rawhide

[bugzilla]

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



--- Comment #1 from Jitka Plesnikova  ---
The failed build in rawhide
https://koji.fedoraproject.org/koji/taskinfo?taskID=46160192


-- 
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 1851243] New: perl-Test-Fake-HTTPD: FTBFS in Fedora rawhide

[bugzilla]

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

Bug ID: 1851243
   Summary: perl-Test-Fake-HTTPD: FTBFS in Fedora rawhide
   Product: Fedora
   Version: rawhide
   URL: https://koschei.fedoraproject.org/package/perl-Test-Fa
ke-HTTPD
Status: NEW
 Component: perl-Test-Fake-HTTPD
  Assignee: de...@fateyev.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Description of problem:
Package perl-Test-Fake-HTTPD fails to build from source in Fedora rawhide. I
found the issue during perl 5.32 rebuild, but the build failed also with perl
5.30 with the error:

Can't accepted on 127.0.0.1:36691 at /usr/share/perl5/vendor_perl/Test/TCP.pm
line 100.
# No tests run!
# No tests run!
#   Failed test 'No tests run for subtest "run_https_server"'
#   at t/11_https.t line 44.
cannot open port: 127.0.0.1:36691 at /usr/share/perl5/vendor_perl/Test/TCP.pm
line 53.
#   Failed test 'No tests run for subtest "run_https_server"'
#   at t/11_https.t line 44.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 255 just after 2.
t/11_https.t  
Dubious, test returned 255 (wstat 65280, 0xff00)

Version-Release number of selected component (if applicable):
0.08-10.fc32

Steps to Reproduce:
koji build --scratch f33 perl-Test-Fake-HTTPD-0.08-10.fc32.src.rpm

Additional info:
This package is tracked by Koschei. See:
https://koschei.fedoraproject.org/package/perl-Test-Fake-HTTPD


-- 
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: Make nano the default editor

[Jan Kratochvil]

On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote:
> I'm not sure why you think end-users can't use a free OS.

First steps of end-users is to install Chrome, Spotify and VirtualBox.
So there is left no advantage of a Free OS.


> I've run with SELinux enabled for years, rarely if ever causes problems
> for typical stuff.

Sooner or later something does not work. I do not want to open this can of
worms whether SELinux yes or not, it may be a good idea but IMNSHO it is not
for a development machine.


> I have no idea why you'd remove a useful tool like bash-completion.  It
> has lots of things useful for developers.

I agree the idea of bash-completion is nice. But it is so severly incomplete
it is more a burden than help. Unfortunately I no longer remember all the bugs
I faced before I started removing it years ago but a simple one is:

$ wget -O somepackage.rpm https://...
$ dnf install som

$ dnf install sombok-


> Unless you are doing kernel development, why do you care what the kernel
> messages say?  On my systems, they go by too fast to read anyway.

When it locks up (during updating firmware on my Athlon machine) I see just
a black screen. When I reboot without rhgb/quiet the problem is not
reproducible as it happens only rarely. There are many reasons why kernels
sometimes fail to boot, why to give up on troubleshooting?


Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1851240] New: perl-App-a2p-1.013 is available

[bugzilla]

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

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



Latest upstream release: 1.013
Current version/release in rawhide: 1.012-2.fc32
URL: http://search.cpan.org/dist/App-a2p/

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


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

Fwd: %forgemeta support for `git` tasks in checked-out code?

[Pavel Raiskup]

Just forwarding this question to more appropriate list.

--  Forwarded Message  --

Subject: %forgemeta support for `git` tasks in checked-out code?
Date: Thursday, June 25, 2020, 6:42:42 PM CEST
From: PGNet Dev 
To: copr-de...@lists.fedorahosted.org

I'm building a package using multiple sources.

I'm using $forgemeta to get/manage sources, as per example here:


https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_multiple_sources_example

One of my sources pulls from upstream scm (github), and needs a subsequent 'git 
submodule--init'.

Is seems that what %forgemeta pulls/tars/expands is not initilialize git repo; 
rather, just the relevant target's files.

E.g., for a given scm source (here, ngx_brotli), the %forgemeta pull unpacks

tree -L 1 -a ngx_brotli
ngx_brotli
├── config
├── CONTRIBUTING.md
├── deps
├── filter
├── .gitmodules
├── LICENSE
├── README.md
├── script
├── static
└── .travis.yml

note, no ".git" folder, and no ability as is to `git submodule --init` in the 
tree.

otoh, a `git clone` of the same source results, as expected, in

tree -L 1 -a ngx_brotli  
ngx_brotli
├── config
├── CONTRIBUTING.md
├── deps
├── filter
!!  ├── .git
├── .gitmodules
├── LICENSE
├── README.md
├── script
├── static
└── .travis.yml

currently, to workaround this, I DISABLE the forge for the source in question, 
and do the pull & submodule init in %prep,

e.g., this spec

%global forgeurl0 https://github.com/nginx/nginx
Version:  1.19.0
%global tag0  release-%{version}

%global forgeurl1 https://github.com/openresty/headers-more-nginx-module
%global tag1  master

# DISABLE global forgeurl1 https://github.com/google/ngx_brotli
%global tag2  master

%forgemeta -i -z 0
%forgemeta -i -z 1
# DISABLE forgemeta -i -z 2

Name:   %{name}
%define dist%{scm0}
Release:%{dist}
Summary:%{name}
License:BSD
URL:%{forgeurl0}

Source0:%{forgesource0}
Source1:%{forgesource1}
Source2:
https://github.com/google/ngx_brotli/archive/master/ngx_brotli-master.tar.gz
...

%prep
pushd .
cd %{_sourcedir}
rm -rf ngx_brotli
git clone https://github.com/google/ngx_brotli
cd ngx_brotli
git submodule update --init
cd ..
tar --remove-files -czf ngx_brotli.tar.gz ngx_brotli
popd

%setup -T -b 0 -n  nginx-%{tag0}
%setup -T -b 1 -n  headers-more-nginx-module-%{tag1}
...

%build
export DESTDIR=%{buildroot}
cd %{_builddir}/%{name}-%{tag0}
...

%install
cd %{_builddir}/%{name}-%{tag0}
make install DESTDIR=%{buildroot} INSTALLDIRS=vendor
...

appears to work, and the `git submodule --init` is taken care of correctly.

but, it's messy.

_is_ there a %forgemeta alternative to the manual git clone that will 
init/unpack the source _as_ a repo, allowing the submodule task to be exec'd?

this isn't, of course, ONLY a COPR question, but one of rpmbuild more generally.

_my_ goal _is_ to get it working on COPR, eventually.

that said, if this^ belongs on some other list, let me know.
___
copr-devel mailing list -- copr-de...@lists.fedorahosted.org
To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/copr-de...@lists.fedorahosted.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: Make nano the default editor

[Kamil Dudka]

On Thursday, June 25, 2020 10:27:06 PM CEST Michael Catanzaro wrote:
> On Thu, Jun 25, 2020 at 8:40 pm, Ian McInerney 
>  wrote:
> 
> > Are you sure this will work? I just ran a test, and putting a new 
> > config file inside /usr/lib/environment.d only works for Gnome, and 
> > doesn't work for Mate, Cinnamon or SSH (tested by opening a terminal 
> > in the respective session and examining the environment variables). 
> > From what I gather in [1], systemd is not a standard way of 
> > interacting with the user's environment variables, and only Gnome has 
> > decided to use it. So this method of implementing this change seems 
> > to be making the default editor for Gnome be nano and not changing 
> > the defaults for anyone else.
> 
> 
> Erm... well, no. Plan foiled?
> 
> The goal of using /usr/lib/environment.d was to avoid setting more 
> environment variables in random places in various shell scripts. But if 
> that only works in GNOME, I guess it's not a great solution after all.

Gentoo Linux uses the /etc/env.d tree to globally set environment variables:

https://devmanual.gentoo.org/tasks-reference/environment/index.html

It worked there long time before systemd was invented.  But clearing this
up in Fedora would ask for a separate system-wide change I guess...

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Make nano the default editor

[James Cassell]

On Thu, Jun 25, 2020, at 4:03 PM, Neal Gompa wrote:
> On Thu, Jun 25, 2020 at 3:41 PM Ian McInerney  
> wrote:
> >>
> >> ...snip...
> >> == Scope ==
> >> * Proposal owners:
> >> ** Modify comps to include nano Fedora wide.
> >> ** Create a new subpackage of nano, called
> >> nano-editor.
> >> ** nano-editor to include
> >> /usr/lib/environment.d/10-nano.conf, which sets
> >> $EDITOR to nano.
> >>
> >> With this approach, if nano is uninstalled, the
> >> configuration will be removed with it. At the same time, installing
> >> nano on its own won't install the conf.
> >>
> >
> > Are you sure this will work? I just ran a test, and putting a new config 
> > file inside /usr/lib/environment.d only works for Gnome, and doesn't work 
> > for Mate, Cinnamon or SSH (tested by opening a terminal in the respective 
> > session and examining the environment variables). From what I gather in 
> > [1], systemd is not a standard way of interacting with the user's 
> > environment variables, and only Gnome has decided to use it. So this method 
> > of implementing this change seems to be making the default editor for Gnome 
> > be nano and not changing the defaults for anyone else.
> >
> 
> We might want to do this as a profile.d snippet for all the major
> shells: bash/ksh, zsh, csh, and fish. That should work basically
> everywhere, afaik.
> 

I'd be -1 on the change, but if it's going to happen anyway, it should 
absolutely be done via an /etc/profile.d entry.  Most likely would be 
sufficient to have /etc/profile.d/nano.{sh,csh} to cover most or all the shells 
out there, IIUC.  I'd have never looked for this in /usr/lib/environment.d -- 
in fact, today is the first time I'd heard of this directory!


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: Bodhi too eager to push updates to stable?

[Kevin Fenzi]

On Thu, Jun 25, 2020 at 08:18:27PM +0200, Tomasz Torcz wrote:
> On Thu, Jun 25, 2020 at 06:10:23PM -, Artur Iwicki wrote:
> > Isn't this how bodhi always worked? One week (two weeks for EPEL) and
> > if doesn't get negative karma, it gets pushed - no matter if it's an
> > enhancement, or a bugfix, or a security update.
> 
>   I don't think so. I remember my updates sitting in testing for weeks.
> Not that I find it worrisome. If my package is so niche that no one tests
> it, then no one will be impacted if the update is now or month later.

Just a sidenote, but do note that doesn't mean no one has tested it. 
We don't know if anyone tested it or not, but there are definitely folks
who run with updates-testing enabled and just report negative karma on
things that break but ignore other updates.

kevin


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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Michael Catanzaro]

On Thu, Jun 25, 2020 at 8:40 pm, Ian McInerney 
 wrote:
Are you sure this will work? I just ran a test, and putting a new 
config file inside /usr/lib/environment.d only works for Gnome, and 
doesn't work for Mate, Cinnamon or SSH (tested by opening a terminal 
in the respective session and examining the environment variables). 
From what I gather in [1], systemd is not a standard way of 
interacting with the user's environment variables, and only Gnome has 
decided to use it. So this method of implementing this change seems 
to be making the default editor for Gnome be nano and not changing 
the defaults for anyone else.


Erm... well, no. Plan foiled?

The goal of using /usr/lib/environment.d was to avoid setting more 
environment variables in random places in various shell scripts. But if 
that only works in GNOME, I guess it's not a great solution after all.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Please BuildRequire python3-setuptools explicitly

[Jerry James]

On Tue, Jun 23, 2020 at 10:26 AM Tomas Hrnciar  wrote:
> python-zodbpicklejjames
> sympycbm jjames jussilehtola orion

I fixed these two in Rawhide, and also fixed a python 3.9 bug in sympy
and an endianness bug in python-gmpy2 en passant.
-- 
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: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Ian McInerney]

On Thu, Jun 25, 2020 at 9:04 PM Neal Gompa  wrote:

> On Thu, Jun 25, 2020 at 3:41 PM Ian McInerney 
> wrote:
> >>
> >> ...snip...
> >> == Scope ==
> >> * Proposal owners:
> >> ** Modify comps to include nano Fedora wide.
> >> ** Create a new subpackage of nano, called
> >> nano-editor.
> >> ** nano-editor to include
> >> /usr/lib/environment.d/10-nano.conf, which sets
> >> $EDITOR to nano.
> >>
> >> With this approach, if nano is uninstalled, the
> >> configuration will be removed with it. At the same time, installing
> >> nano on its own won't install the conf.
> >>
> >
> > Are you sure this will work? I just ran a test, and putting a new config
> file inside /usr/lib/environment.d only works for Gnome, and doesn't work
> for Mate, Cinnamon or SSH (tested by opening a terminal in the respective
> session and examining the environment variables). From what I gather in
> [1], systemd is not a standard way of interacting with the user's
> environment variables, and only Gnome has decided to use it. So this method
> of implementing this change seems to be making the default editor for Gnome
> be nano and not changing the defaults for anyone else.
> >
>
> We might want to do this as a profile.d snippet for all the major
> shells: bash/ksh, zsh, csh, and fish. That should work basically
> everywhere, afaik.
>

Yes, that sounds like a better plan. I think that is also where most people
would think to look for this first.

-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: Make nano the default editor

[Neal Gompa]

On Thu, Jun 25, 2020 at 3:41 PM Ian McInerney  wrote:
>>
>> ...snip...
>> == Scope ==
>> * Proposal owners:
>> ** Modify comps to include nano Fedora wide.
>> ** Create a new subpackage of nano, called
>> nano-editor.
>> ** nano-editor to include
>> /usr/lib/environment.d/10-nano.conf, which sets
>> $EDITOR to nano.
>>
>> With this approach, if nano is uninstalled, the
>> configuration will be removed with it. At the same time, installing
>> nano on its own won't install the conf.
>>
>
> Are you sure this will work? I just ran a test, and putting a new config file 
> inside /usr/lib/environment.d only works for Gnome, and doesn't work for 
> Mate, Cinnamon or SSH (tested by opening a terminal in the respective session 
> and examining the environment variables). From what I gather in [1], systemd 
> is not a standard way of interacting with the user's environment variables, 
> and only Gnome has decided to use it. So this method of implementing this 
> change seems to be making the default editor for Gnome be nano and not 
> changing the defaults for anyone else.
>

We might want to do this as a profile.d snippet for all the major
shells: bash/ksh, zsh, csh, and fish. That should work basically
everywhere, afaik.



-- 
真実はいつも一つ！/ 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: Make nano the default editor

[Jonathan Wakely]

On 25/06/20 13:34 -0600, Chris Murphy wrote:

On Thu, Jun 25, 2020 at 12:50 PM Jan Kratochvil
 wrote:


On Thu, 25 Jun 2020 19:18:59 +0200, Ben Cotton wrote:
> In contrast, Nano offers the kind of graphical text editing experience
> that people are used to,

This is another step trying to make Fedora end-user friendly while the only
effect is making it hostile to developers.


This is hyperbole. All of the working group members are developers and
the change was approved +9 to -1. The idea the vast majority of the
working group wants to make Fedora hostile to themselves is nonsense.

I use vi out of habit (I learned it when I was young and in college
... and I'll skip the rest of the story) not because I like it. It's
almost a comedy show if you haven't already been indoctrinated. I
never recommend it. It would be like recommending teletype, which by
the way is a neat skill to have, but to make it the default
everywhere? Come on.

A better strategy is to appeal to the broader community that in fact
vim users really need it to be the default editor because changing the
default is harder than figuring out how to quit vim.


As Fedora will never be used by> end-users as it conflicts with Fedora's 
foundation Freedom. With each such
step it takes more and more effort to make a new Fedora installation usable by
a developer (setenforce 0, dnf remove bash-completion, remove rhgb quiet etc.).


dnf remove bash-completion makes Fedora *more* usable? :head explodes:


dnf remove bash-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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Chris Murphy]

On Thu, Jun 25, 2020 at 1:58 PM Chris Murphy  wrote:
>
> On Thu, Jun 25, 2020 at 1:48 PM Michael Catanzaro  
> wrote:
> >
> > On Thu, Jun 25, 2020 at 2:45 pm, Michael Catanzaro
> >  wrote:
> > > Yes. I already fixed the wiki page to clarify that we don't need to
> > > install nano, but I forgot to clarify that we will install
> > > nano-editor by default.
> >
> > BTW maybe nano-editor is not the best name for the subpackage,
> > considering it will not include the nano text editor, but rather a conf
> > snippet to set $EDITOR. Any alternative naming proposals?
>
> nano-default ?

We're using zram-generator-defaults for this.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1527737

Which is better? default or defaults? I don't have a preference.


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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Chris Murphy]

On Thu, Jun 25, 2020 at 1:48 PM Michael Catanzaro  wrote:
>
> On Thu, Jun 25, 2020 at 2:45 pm, Michael Catanzaro
>  wrote:
> > Yes. I already fixed the wiki page to clarify that we don't need to
> > install nano, but I forgot to clarify that we will install
> > nano-editor by default.
>
> BTW maybe nano-editor is not the best name for the subpackage,
> considering it will not include the nano text editor, but rather a conf
> snippet to set $EDITOR. Any alternative naming proposals?

nano-default ?

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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jonathan Wakely]

On 25/06/20 20:50 +0200, Jan Kratochvil wrote:

On Thu, 25 Jun 2020 19:18:59 +0200, Ben Cotton wrote:

In contrast, Nano offers the kind of graphical text editing experience
that people are used to,


This is another step trying to make Fedora end-user friendly while the only
effect is making it hostile to developers. As Fedora will never be used by
end-users as it conflicts with Fedora's foundation Freedom. With each such
step it takes more and more effort to make a new Fedora installation usable by
a developer (setenforce 0, dnf remove bash-completion, remove rhgb quiet etc.).


As a developer, I don't disable any of those.

Bash's own built-in completion causes me more issues than
bash-completion does, try 'ls $HOME/' without the direxpand
option set, and tell me what on earth that is for.

Apart from sshd settings (which can now be set in
/etc/ssh/ssh_config.d - hoorah!) the only thing I absolutely insist on
changing on a new Fedora install is to disable abrt. No, I don't want
to report it to bugzilla every time a unit test or quick hacked
together piece of code terminates abnormally.

Anyway, I find it hard to believe that serious developers are
unable/unwilling to set their own choice of EDITOR. A systemwide
default EDITOR=nano shouldn't cause them any real difficulty.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Make nano the default editor

[Adam Williamson]

On Thu, 2020-06-25 at 14:47 -0500, Michael Catanzaro wrote:
> On Thu, Jun 25, 2020 at 2:45 pm, Michael Catanzaro 
>  wrote:
> > Yes. I already fixed the wiki page to clarify that we don't need to 
> > install nano, but I forgot to clarify that we will install 
> > nano-editor by default.
> 
> BTW maybe nano-editor is not the best name for the subpackage, 
> considering it will not include the nano text editor, but rather a conf 
> snippet to set $EDITOR. Any alternative naming proposals?

nano-make-systemwide-default

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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Michael Catanzaro]

On Thu, Jun 25, 2020 at 2:45 pm, Michael Catanzaro 
 wrote:
Yes. I already fixed the wiki page to clarify that we don't need to 
install nano, but I forgot to clarify that we will install 
nano-editor by default.


BTW maybe nano-editor is not the best name for the subpackage, 
considering it will not include the nano text editor, but rather a conf 
snippet to set $EDITOR. Any alternative naming proposals?


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Make nano the default editor

[Michael Catanzaro]

On Thu, Jun 25, 2020 at 12:40 pm, Samuel Sieb  wrote:
"nano" is already included by default.  Did you mean this to say 
you'll

include the new "nano-editor" package by default?


Yes. I already fixed the wiki page to clarify that we don't need to 
install nano, but I forgot to clarify that we will install nano-editor 
by default.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Make nano the default editor

[Jerry James]

On Thu, Jun 25, 2020 at 1:21 PM Adam Williamson
 wrote:
> My only regret is that I have but one +1 to give to this proposal!

Wait, wait, wait.  Aren't you Canadian?

I don't really care much one way or the other about the proposal.
I've learned enough vi to get by.  I'll give nano a try and change the
default if I don't like it.
-- 
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: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Ian McInerney]

>
> ...snip...
> == Scope ==
> * Proposal owners:
> ** Modify comps to include nano Fedora wide.
> ** Create a new subpackage of nano, called
> nano-editor.
> ** nano-editor to include
> /usr/lib/environment.d/10-nano.conf, which sets
> $EDITOR to nano.
>
> With this approach, if nano is uninstalled, the
> configuration will be removed with it. At the same time, installing
> nano on its own won't install the conf.
>
>
Are you sure this will work? I just ran a test, and putting a new config
file inside /usr/lib/environment.d only works for Gnome, and doesn't work
for Mate, Cinnamon or SSH (tested by opening a terminal in the respective
session and examining the environment variables). From what I gather in
[1], systemd is not a standard way of interacting with the user's
environment variables, and only Gnome has decided to use it. So this method
of implementing this change seems to be making the default editor for Gnome
be nano and not changing the defaults for anyone else.

-Ian

[1] https://github.com/systemd/systemd/issues/7641
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Make nano the default editor

[Samuel Sieb]

On 6/25/20 10:18 AM, Ben Cotton wrote:

** Modify comps to include nano Fedora wide.


"nano" is already included by default.  Did you mean this to say you'll 
include the new "nano-editor" package by default?



** Create a new subpackage of nano, called
nano-editor.
** nano-editor to include
/usr/lib/environment.d/10-nano.conf, which sets
$EDITOR to nano.

With this approach, if nano is uninstalled, the
configuration will be removed with it. At the same time, installing
nano on its own won't install the conf.


I understand that lots of people prefer a simple editor, so I'm fine 
with this change given that I can revert it by removing that one extra 
package.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Make nano the default editor

[Tomasz Torcz]

On Thu, Jun 25, 2020 at 01:34:33PM -0600, Chris Murphy wrote:
> On Thu, Jun 25, 2020 at 12:50 PM Jan Kratochvil
>  wrote:
> >
> > On Thu, 25 Jun 2020 19:18:59 +0200, Ben Cotton wrote:
> > > In contrast, Nano offers the kind of graphical text editing experience
> > > that people are used to,
> >
> > This is another step trying to make Fedora end-user friendly while the only
> > effect is making it hostile to developers.
> 
> This is hyperbole. All of the working group members are developers and
> the change was approved +9 to -1. The idea the vast majority of the
> working group wants to make Fedora hostile to themselves is nonsense.

  They are not true Scotsmen^Wdevelopers.

-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Make nano the default editor

[Chris Murphy]

On Thu, Jun 25, 2020 at 12:50 PM Jan Kratochvil
 wrote:
>
> On Thu, 25 Jun 2020 19:18:59 +0200, Ben Cotton wrote:
> > In contrast, Nano offers the kind of graphical text editing experience
> > that people are used to,
>
> This is another step trying to make Fedora end-user friendly while the only
> effect is making it hostile to developers.

This is hyperbole. All of the working group members are developers and
the change was approved +9 to -1. The idea the vast majority of the
working group wants to make Fedora hostile to themselves is nonsense.

I use vi out of habit (I learned it when I was young and in college
... and I'll skip the rest of the story) not because I like it. It's
almost a comedy show if you haven't already been indoctrinated. I
never recommend it. It would be like recommending teletype, which by
the way is a neat skill to have, but to make it the default
everywhere? Come on.

A better strategy is to appeal to the broader community that in fact
vim users really need it to be the default editor because changing the
default is harder than figuring out how to quit vim.

>As Fedora will never be used by> end-users as it conflicts with Fedora's 
>foundation Freedom. With each such
> step it takes more and more effort to make a new Fedora installation usable by
> a developer (setenforce 0, dnf remove bash-completion, remove rhgb quiet 
> etc.).

dnf remove bash-completion makes Fedora *more* usable? :head explodes:

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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Fabio Valentini]

On Thu, Jun 25, 2020 at 8:50 PM Jan Kratochvil
 wrote:
>
> On Thu, 25 Jun 2020 19:18:59 +0200, Ben Cotton wrote:
> > In contrast, Nano offers the kind of graphical text editing experience
> > that people are used to,
>
> This is another step trying to make Fedora end-user friendly while the only
> effect is making it hostile to developers. As Fedora will never be used by
> end-users as it conflicts with Fedora's foundation Freedom. With each such
> step it takes more and more effort to make a new Fedora installation usable by
> a developer (setenforce 0, dnf remove bash-completion, remove rhgb quiet 
> etc.).

I must be a very weird (fedora) developer. I have never done any of
those three things :)

FWIW, I embrace the "EDITOR=nano by default" change so hard that I
need to be careful not to squeeze too hard.

Setting nano as default editor (or installing it on Server Edition) is
the first thing I do on every fresh fedora install. Still, every time
vi(m) opens for some reason, I feel like being thrown into cold water
(or into an exam situation, unprepared) - I still don't know any vi
commands other than :q, :q!, and :wq after more than a decade of using
as my primary OS.

Once a FESCo ticket exists for this Change, it'll have my +1 vote.
Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Chris Adams]

Once upon a time, Jan Kratochvil  said:
> This is another step trying to make Fedora end-user friendly while the only
> effect is making it hostile to developers.

I've been setting $EDITOR and $VISUAL for ages (since long before Fedora
existed, probably since before Red Hat existed).

> As Fedora will never be used by
> end-users as it conflicts with Fedora's foundation Freedom.

I'm not sure why you think end-users can't use a free OS.

> With each such
> step it takes more and more effort to make a new Fedora installation usable by
> a developer (setenforce 0, dnf remove bash-completion, remove rhgb quiet 
> etc.).

I've run with SELinux enabled for years, rarely if ever causes problems
for typical stuff.

I have no idea why you'd remove a useful tool like bash-completion.  It
has lots of things useful for developers.

Unless you are doing kernel development, why do you care what the kernel
messages say?  On my systems, they go by too fast to read anyway.
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Adam Williamson]

On Thu, 2020-06-25 at 13:18 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/UseNanoByDefault
> 
> == Summary ==
> 
> Let's make Fedora more approachable, by having a default editor that
> doesn't require specialist knowledge to use.

My only regret is that I have but one +1 to give to this proposal!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Ariadne Conill]

Hello,

On Thursday, June 25, 2020 12:50:23 PM MDT Jan Kratochvil wrote:
> On Thu, 25 Jun 2020 19:18:59 +0200, Ben Cotton wrote:
>
> > In contrast, Nano offers the kind of graphical text editing experience
> > that people are used to,
>
>
> This is another step trying to make Fedora end-user friendly while the only
> effect is making it hostile to developers.

I'm a developer who has written, amongst other things, Fedora's implementation  
of pkg-config, the IRC software powering the IRC network Fedora uses to  
coordinate its efforts, various patches to software shipping in Fedora.

I use nano to write these programs.  I use nano, quite happily, as my editor  
of choice since it was first released.  Before that, I used pico and FreeBSD's  
ee editor.

I suspect many new developers are using graphical editors such as VS Code and  
gedit.  Using vi or emacs does not imply any sense of development skill or  
authority -- if you like those editors, that is your choice, but that does not  
mean that they are a sensible choice for users new to the system who did not  
originally learn with them.  I learned how to program using Borland TurboC on  
MS-DOS back in the 90s, and nano is a much closer match to that workflow than a 
 
modal editor such as vim, which is why I happily use nano.

Ariadne


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Need help to contact: digimer mbartos, ignotusp

[Pierre-Yves Chibon]

On Thu, Jun 25, 2020 at 12:37:41PM -0400, Digimer wrote:
> digimer here, sorry, I'm not sure why my address was rejected. I can
> also be reached at 'mke...@alteeve.ca'.

Could you update it in FAS and check if whichever account you use in FAS has a
corresponding bugzilla account?

Thanks!

Pierre

> On 2020-06-25 9:08 a.m., Pierre-Yves Chibon wrote:
> > Good Morning Everyone,
> > 
> > As announced on devel-announce [1] I have sent an email to each account 
> > listed
> > on dist-git to be either point of contact or included in the CC list of 
> > tickets
> > opened on bugzilla.
> > 
> > The following emails to the following account came back with and error:
> > - digimer  (error: Recipient address rejected: alteeve.ca)
> >   - Maintains: rpms/kronosnet
> > - mbartos  (error: Recipient address rejected: Access denied)
> >   - Maintains: rpms/libee, rpms/libestr, rpms/liblognorm
> > - ignotusp (error:  No such user!)
> >   - Maintains: rpms/wicd-kde
> > 
> > Does anyone know how to contact these persons?
> > 
> > If we have no way to contact them, we may have to ask FESCo to consider them
> > unresponsive.
> > 
> > Thanks in advance for your help!
> > 
> > Pierre
> > 
> > 
> > [1]: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VBMMXJT2M5TMWSH3DT3DY6VBPELSTQFV/
> > 
> > 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > 
> 
> 
> -- 
> Digimer
> Papers and Projects: https://alteeve.com/w/
> "I am, somehow, less interested in the weight and convolutions of
> Einstein’s brain than in the near certainty that people of equal talent
> have lived and died in cotton fields and sweatshops." - Stephen Jay Gould
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 24. 06. 20 v 4:40 Przemek Klosowski via devel napsal(a):
> dnf -C list extras

How do I skip packages which are installed from @@commandline? Is there 
anything else than "grep -v"?

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Solomon Peachy]

On Thu, Jun 25, 2020 at 08:50:23PM +0200, Jan Kratochvil wrote:
> This is another step trying to make Fedora end-user friendly while the only
> effect is making it hostile to developers. As Fedora will never be used by

How does changing the default editor make Fedora hostile to developers?

(I suspect you have a rather narrow definition of "developer" here...)

> such step it takes more and more effort to make a new Fedora 
> installation usable by a developer (setenforce 0, dnf remove 
> bash-completion

That's an odd position to take; bash-completion is quite useful, far 
more so for "developers" than "normal" folks whose command line 
interaction is limited to pasting things in from random web pages or 
"curl | bash" invocations.

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

[Samuel Sieb]

On 6/24/20 12:03 PM, Iñaki Ucar wrote:

Thanks. I found another tutorial (from RedHat) which basically says:

1. Implement your service, give it a new SELinux type and run it.
2. Collect all the complaints from SELinux.
3. Use audit2allow to convert them to rules.
4. Repeat until you don't get any more complaints.

And I cannot believe my eyes. Is this *really* the way to implement
SELinux policies? It seems like a joke to me. Isn't there any notion
of inheritance or something like that? Like, I want my type to have


I suppose that's the "easy" way.  The better way would be to figure out 
what permissions and transitions your service needs and write the rules 
for that.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Make nano the default editor

[Jan Kratochvil]

On Thu, 25 Jun 2020 19:18:59 +0200, Ben Cotton wrote:
> In contrast, Nano offers the kind of graphical text editing experience
> that people are used to,

This is another step trying to make Fedora end-user friendly while the only
effect is making it hostile to developers. As Fedora will never be used by
end-users as it conflicts with Fedora's foundation Freedom. With each such
step it takes more and more effort to make a new Fedora installation usable by
a developer (setenforce 0, dnf remove bash-completion, remove rhgb quiet etc.).


Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: SELinux question

[Miroslav Suchý]

Dne 24. 06. 20 v 21:03 Iñaki Ucar napsal(a):
> 3. Use audit2allow to convert them to rules.
> 4. Repeat until you don't get any more complaints.
> 
> And I cannot believe my eyes. Is this *really* the way to implement
> SELinux policies? It seems like a joke to me.

No. It is a bit complicated. You should run audit2allow with -R option.
And you should actually review what audit2allow produce. But otherwise... yes, 
it is that simple.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1851062] perl-Module-Signature-0.86 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
   Doc Type|--- |If docs needed, set a value



--- Comment #3 from Paul Howarth  ---
Pushed to git in Rawhide, I'll build it once Perl 5.32 lands in Rawhide (or
Jitka can build it straight into the side tag if preferred).


-- 
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: Please BuildRequire python3-setuptools explicitly

[Robbie Harwood]

Tomas Hrnciar  writes:

> We would like to kindly ask you to add explicit BuildRequires for
> python3-setuptools to packages where setuptools is used. It will help
> us with testing new versions of setuptools in the future or with
> decoupling Python and setuptools. Today, if we want to know if a
> package is using setuptools, we have to do `fedpkg prep` and use grep
> to search for setuptools. Using a repoquery is much more convenient.
>
> python-kdcproxy  rharwood

Done in python-kdcproxy-0.4.2-5.fc33.

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: Avoiding the automatic /usr/bin/python3 dep

[Miroslav Suchý]

Dne 25. 06. 20 v 16:06 Igor Raits napsal(a):
> I think removing that dependency is simply wrong. It essentially means
> that one would not be able to use those scripts without dependency
> being installed.

Simply removing is wrong. But I see nothing bad on moving it to Recommends or 
even Suggests. It is not required when you
are able to do most of common operations without the dependency.

-- 
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: Bodhi too eager to push updates to stable?

[Adam Williamson]

On Thu, 2020-06-25 at 20:18 +0200, Tomasz Torcz wrote:
> On Thu, Jun 25, 2020 at 06:10:23PM -, Artur Iwicki wrote:
> > Isn't this how bodhi always worked? One week (two weeks for EPEL) and
> > if doesn't get negative karma, it gets pushed - no matter if it's an
> > enhancement, or a bugfix, or a security update.
> 
>   I don't think so. I remember my updates sitting in testing for weeks.
> Not that I find it worrisome. If my package is so niche that no one tests
> it, then no one will be impacted if the update is now or month later.

It hasn't "always" been like this, it was added I think two or three
years back, in response to one of the periodic long arguments about
whether the rules and defaults are too strict or not strict enough.

> > When creating an update from the web panel, you can un-check the
> > "Auto-request stable based on time?" box to disable this. When doing
> > this from the command-line... hm, I don't see any field in the
> > template that'd allow to change this. Time to file a feature request?
> 
>   I'm only using “fedpkg update” and there is no time based option in
> template.

I guess the option to set it was never added to that tool, only to the
web UI. It should probably be added there I guess.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bodhi too eager to push updates to stable?

[Adam Williamson]

On Thu, 2020-06-25 at 19:58 +0200, Tomasz Torcz wrote:
> Hi,
> 
>   I'm really surprised by Bodhi behaviour with this update:
>   https://bodhi.fedoraproject.org/updates/FEDORA-2020-6010469bfb
>  (ladvd-1.1.2-7.fc32, Fix SELinux AVC denials)
> 
>   I've set Stable Karma to +3.  Update was pushed to testing,
> gathered exactly zero reviews with +/- karma. After a week,
> with 0 karma, update was pushed to stable.
>   Should it work that way?

That is the default for non-critical-path updates, yes. When you create
an update there are options for auto-push based on karma (with a
default of +3) and time (with a default of 7 days for non-critpath, 14
days for critpath). You can entirely disable or change the criteria for
either or both mechanisms.

You should not be able to set the required karma or time below the
floors specified for the relevant update type in the update policy,
though I haven't checked lately to see if there are any bugs in this.
There definitely have been before. :D You can certainly require *more*
karma or a *longer* wait, though.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bodhi too eager to push updates to stable?

[Tomasz Torcz]

On Thu, Jun 25, 2020 at 06:10:23PM -, Artur Iwicki wrote:
> Isn't this how bodhi always worked? One week (two weeks for EPEL) and
> if doesn't get negative karma, it gets pushed - no matter if it's an
> enhancement, or a bugfix, or a security update.

  I don't think so. I remember my updates sitting in testing for weeks.
Not that I find it worrisome. If my package is so niche that no one tests
it, then no one will be impacted if the update is now or month later.

> When creating an update from the web panel, you can un-check the
> "Auto-request stable based on time?" box to disable this. When doing
> this from the command-line... hm, I don't see any field in the
> template that'd allow to change this. Time to file a feature request?

  I'm only using “fedpkg update” and there is no time based option in
template.

-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Make nano the default editor

[Alexander Ploumistos]

On Thu, Jun 25, 2020 at 7:20 PM Ben Cotton  wrote:
>
> Let's make Fedora more approachable, by having a default editor that
> doesn't require specialist knowledge to use.

One could argue that this adds to the experience!


> (These arguments would apply
> just as well if git picked Vim. vi is like hard mode for Vim, with
> fewer features, missing syntax highlighting, and no indication of what
> mode you are in. Even Vim users may feel lost and bewildered when
> using vi.)

Not really and that's because we ship vim-minimal with sane defaults,
unlike other distros.


> In contrast, Nano offers the kind of graphical text editing experience
> that people are used to, and therefore doesn't require specialist
> knowledge to use.

Who are these people?


> It is already installed across most Fedora Editions
> and Spins.




> * More in line with the default editor of other distributions.

It has been a nice and welcome point of difference.

Oh, 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: Bodhi too eager to push updates to stable?

[Artur Iwicki]

Isn't this how bodhi always worked? One week (two weeks for EPEL) and if 
doesn't get negative karma, it gets pushed - no matter if it's an enhancement, 
or a bugfix, or a security update.

When creating an update from the web panel, you can un-check the "Auto-request 
stable based on time?" box to disable this. When doing this from the 
command-line... hm, I don't see any field in the template that'd allow to 
change this. Time to file a feature request?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Bodhi too eager to push updates to stable?

[Tomasz Torcz]

Hi,

  I'm really surprised by Bodhi behaviour with this update:
  https://bodhi.fedoraproject.org/updates/FEDORA-2020-6010469bfb
 (ladvd-1.1.2-7.fc32, Fix SELinux AVC denials)

  I've set Stable Karma to +3.  Update was pushed to testing,
gathered exactly zero reviews with +/- karma. After a week,
with 0 karma, update was pushed to stable.
  Should it work that way?

-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Make nano the default editor

[Randy Barlow]

On 6/25/20 1:18 PM, Ben Cotton wrote:

Let's make Fedora more approachable, by having a default editor that
doesn't require specialist knowledge to use.


I would like to counter propose that we make ed the default editor :P
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Upcoming Fedora 33 Change proposal deadlines

[Ben Cotton]

If, like me, you're surprised that it's suddenly the end of June, you
may appreciate this reminder of upcoming Fedora 33 deadlines.

On Wed, Jun 10, 2020 at 1:56 PM Ben Cotton  wrote:
>
> * 2020-06-30: Proposal deadline for Changes requiring mass rebuild
> * 2020-06-30: Proposal deadline for System-Wide Changes
> * 2020-07-21: Proposal deadline for Self-Contained Changes
>
> For the full schedule, see
> https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Re: Upcoming Fedora 33 Change proposal deadlines

[Ben Cotton]

If, like me, you're surprised that it's suddenly the end of June, you
may appreciate this reminder of upcoming Fedora 33 deadlines.

On Wed, Jun 10, 2020 at 1:56 PM Ben Cotton  wrote:
>
> * 2020-06-30: Proposal deadline for Changes requiring mass rebuild
> * 2020-06-30: Proposal deadline for System-Wide Changes
> * 2020-07-21: Proposal deadline for Self-Contained Changes
>
> For the full schedule, see
> https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 33 Self-Contained Change proposal: Deprecate python-pytoml

[Ben Cotton]

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

== Summary ==
The {{package|python-pytoml}} ({{package|python3-pytoml}}) package
will be 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/
deprecated] in [[Releases/33|Fedora 33]]. Pytoml is deprecated
upstream in favor of [https://pypi.org/project/toml/ toml]
({{package|python-toml}}), but existing Fedora packages depend on it,
so we cannot remove it yet. Packagers are encouraged to work with
upstream to switch to {{package|python-toml}}, but
{{package|python-pytoml}} remains available until it is a leaf
package, it will be removed then (possibly not yet in Fedora 33).

== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhron...@redhat.com


== Detailed Description ==
The {{package|python-pytoml}} package is
[https://pypi.org/project/pytoml/ deprecated upstream]:

> The pytoml project is no longer being actively maintained. Consider using the 
> [https://pypi.org/project/toml/ toml] package instead.

We'd like to drop it from Fedora, but several packages still require
it. Before we attempt to remove the package, we need to stop new
packages to (Build)Require {{package|python3-pytoml}}, hence we want
to have it 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/
deprecated].

Packagers are encouraged to switch to {{package|python3-toml}} with
upstream involvement. Downstream patches to switch from pytoml to toml
are not encouraged.

Note that repoquery gives many packages that BuildRequire
{{package|python3-toml}}:

 $ repoquery --repo=rawhide{,-source} --whatrequires python3-pytoml
 ilua-0:0.2.1-1.fc33.src
 pyproject-rpm-macros-0:0-15.fc33.noarch
 pyproject-rpm-macros-0:0-15.fc33.src
 python-black-0:19.10~b0-3.fc33.src
 python-chaospy-0:3.2.12-1.fc33.src
 python-copr-0:1.102-1.fc33.src
 python-decopatch-0:1.4.6-3.fc33.src
 python-elementpath-0:1.4.0-4.fc33.src
 python-flit-0:2.3.0-3.fc33.src
 python-latexcodec-0:2.0.1-1.fc33.src
 python-makefun-0:1.6.11-3.fc33.src
 python-numpoly-0:0.2.3-2.fc33.src
 python-openqa_client-0:4.1.0-2.fc33.src
 python-pint-0:0.13-1.fc33~bootstrap.src
 python-pybtex-docutils-0:0.2.2-4.fc33.src
 python-pytest-cases-0:1.11.1-3.fc33.src
 python-pytest-harvest-0:1.7.2-3.fc33.src
 python-pytest-steps-0:1.7.2-2.fc33.src
 python-readthedocs-sphinx-ext-0:2.0.0-1.fc33.src
 python-requests-download-0:0.1.2-3.fc33.src
 python-sphinx-copybutton-0:0.2.12-1.fc33.src
 python-sphinxcontrib-bibtex-0:1.0.0-4.fc33.src
 python-wikitcms-0:2.6.3-2.fc33.src
 python-xmlschema-0:1.0.18-3.fc33.src
 python-xmlsec-0:1.3.8-1.fc33.src
 python3-flit-0:2.3.0-3.fc33.noarch
 python3-flit-core-0:2.3.0-3.fc33.noarch

But many of them are only there because the dependency was generated
by {{package|pyproject-rpm-macros}} BuildRequires generator which was
since already updated to use {{package|python3-toml}}. When rebuilt
with updated {{package|pyproject-rpm-macros}}, the dependency will be
replaced with {{package|python3-toml}}.

 $ repoquery --repo=rawhide{,-source} --whatrequires pyproject-rpm-macros
 ansible-lint-0:4.2.0-4.fc33.src
 ilua-0:0.2.1-1.fc33.src
 python-PyGithub-0:1.51-2.fc33.src
 python-black-0:19.10~b0-3.fc33.src
 python-chaospy-0:3.2.12-1.fc33.src
 python-copr-0:1.102-1.fc33.src
 python-decopatch-0:1.4.6-3.fc33.src
 python-elementpath-0:1.4.0-4.fc33.src
 python-latexcodec-0:2.0.1-1.fc33.src
 python-makefun-0:1.6.11-3.fc33.src
 python-numpoly-0:0.2.3-2.fc33.src
 python-openqa_client-0:4.1.0-2.fc33.src
 python-pep517-0:0.7.0-4.fc33.src
 python-pint-0:0.13-1.fc33~bootstrap.src
 python-pybtex-docutils-0:0.2.2-4.fc33.src
 python-pytest-cases-0:1.11.1-3.fc33.src
 python-pytest-harvest-0:1.7.2-3.fc33.src
 python-pytest-steps-0:1.7.2-2.fc33.src
 python-readthedocs-sphinx-ext-0:2.0.0-1.fc33.src
 python-requests-download-0:0.1.2-3.fc33.src
 python-sphinx-copybutton-0:0.2.12-1.fc33.src
 python-sphinxcontrib-bibtex-0:1.0.0-4.fc33.src
 python-tox-current-env-0:0.0.2-5.fc33.src
 python-wikitcms-0:2.6.3-2.fc33.src
 python-xmlschema-0:1.0.18-3.fc33.src
 python-xmlsec-0:1.3.8-1.fc33.src

The only really affected package is {{package|python-flit}}. Upstream
already discusses the transition:
https://github.com/takluyver/flit/issues/255

Once all dependencies are removed, we plan to retire
{{package|python-pytoml}}, whether it will be in Fedora 33 or later.

== Feedback ==
The intent was announced at
https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/MOAHRKMZRFNR34WHPICHCP6MR3IWY4FW/
but there was no feedback. The primary point of contact for the
{{package|python-pytoml}} and {{package|python-toml}} packages is on
board.

== Benefit to Fedora ==
An upstream deprecated package will not be depended upon by new packages.

== Scope ==
* Proposal owners: Deprecate {{package|python3-pytoml}}. Work with
flit upstream to make the transition as well. Once the dependency is
removed from flit, rebuild remaining packages using
{{package|pyproject-rpm-macros}} 

Fedora 33 System-Wide Change proposal: Make nano the default editor

[Ben Cotton]

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

== Summary ==

Let's make Fedora more approachable, by having a default editor that
doesn't require specialist knowledge to use.

== Owner ==
* Name: [[User:chrismurphy| Chris Murphy]]
* Email:  chrismur...@fedoraproject.org


== Detailed Description ==

Users are exposed to the default editor when they use commands that
call it. The main example here is something like git
commit.

Fedora does not currently have a default terminal text editor, because
the $EDITOR environment variable is unset by default. But a common
scenario where users wind up in a terminal text editor is when using
'git commit'. By default, git picks vi. You need to spend time
learning how to use it, for even basic editing tasks. This increases
the barrier to entry for those who are switching to Fedora and don't
know how to use vi. It also makes things hard for those who don't
particularly want to learn how to use vi. (These arguments would apply
just as well if git picked Vim. vi is like hard mode for Vim, with
fewer features, missing syntax highlighting, and no indication of what
mode you are in. Even Vim users may feel lost and bewildered when
using vi.)

In contrast, Nano offers the kind of graphical text editing experience
that people are used to, and therefore doesn't require specialist
knowledge to use. It is already installed across most Fedora Editions
and Spins. This proposal will make Nano the default editor, while
continuing to install vim-minimal (which provides vi, but
not Vim). People will still be able to call vi if they
want to edit a file. It will also obviously be possible to change the
default editor to vi or Vim, for those who want it.

Why make Nano default and vi optional, rather than the other way
round? Because Nano is the option that everyone can use.

== Feedback ==

Pending ...

== Benefit to Fedora ==

* Makes the default editor across all of Fedora more approachable.
* Nano is also mostly self-documenting, by displaying common keyboard
shortcuts on-screen.
* More in line with the default editor of other distributions.

== Scope ==
* Proposal owners:
** Modify comps to include nano Fedora wide.
** Create a new subpackage of nano, called
nano-editor.
** nano-editor to include
/usr/lib/environment.d/10-nano.conf, which sets
$EDITOR to nano.

With this approach, if nano is uninstalled, the
configuration will be removed with it. At the same time, installing
nano on its own won't install the conf.

* Other developers: N/A

* Release engineering: [https://pagure.io/releng/issue/9522 #9522]

* Policies and guidelines: N/A

* Trademark approval: N/A

== Upgrade/compatibility impact ==

Will not apply to upgrades.

== How To Test ==

Run export EDITOR="/usr/bin/nano".

== User Experience ==

Users running git commit will be able to just type their
commit message, rather than having to learn about insert mode, and
they'll be able to cut and paste without having to learn special
shortcuts.

== Dependencies ==

No additional dependencies are required.

== Contingency Plan ==
The contingency plan is to revert the change by removing the
nano-editor package.

* Contingency deadline: probably the beta? It's an easy change to revert.
* Blocks release? If the change breaks the redirection to an editor,
it should block the release. However, this is unlikely.
* Blocks product? Potentially all.

== Documentation ==
As part of this change, it would be good to add instructions for
changing the default editor to the
[https://docs.fedoraproject.org/en-US/quick-docs/ quick docs].


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Fedora 33 Self-Contained Change proposal: Deprecate python-pytoml

[Ben Cotton]

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

== Summary ==
The {{package|python-pytoml}} ({{package|python3-pytoml}}) package
will be 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/
deprecated] in [[Releases/33|Fedora 33]]. Pytoml is deprecated
upstream in favor of [https://pypi.org/project/toml/ toml]
({{package|python-toml}}), but existing Fedora packages depend on it,
so we cannot remove it yet. Packagers are encouraged to work with
upstream to switch to {{package|python-toml}}, but
{{package|python-pytoml}} remains available until it is a leaf
package, it will be removed then (possibly not yet in Fedora 33).

== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhron...@redhat.com


== Detailed Description ==
The {{package|python-pytoml}} package is
[https://pypi.org/project/pytoml/ deprecated upstream]:

> The pytoml project is no longer being actively maintained. Consider using the 
> [https://pypi.org/project/toml/ toml] package instead.

We'd like to drop it from Fedora, but several packages still require
it. Before we attempt to remove the package, we need to stop new
packages to (Build)Require {{package|python3-pytoml}}, hence we want
to have it 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/
deprecated].

Packagers are encouraged to switch to {{package|python3-toml}} with
upstream involvement. Downstream patches to switch from pytoml to toml
are not encouraged.

Note that repoquery gives many packages that BuildRequire
{{package|python3-toml}}:

 $ repoquery --repo=rawhide{,-source} --whatrequires python3-pytoml
 ilua-0:0.2.1-1.fc33.src
 pyproject-rpm-macros-0:0-15.fc33.noarch
 pyproject-rpm-macros-0:0-15.fc33.src
 python-black-0:19.10~b0-3.fc33.src
 python-chaospy-0:3.2.12-1.fc33.src
 python-copr-0:1.102-1.fc33.src
 python-decopatch-0:1.4.6-3.fc33.src
 python-elementpath-0:1.4.0-4.fc33.src
 python-flit-0:2.3.0-3.fc33.src
 python-latexcodec-0:2.0.1-1.fc33.src
 python-makefun-0:1.6.11-3.fc33.src
 python-numpoly-0:0.2.3-2.fc33.src
 python-openqa_client-0:4.1.0-2.fc33.src
 python-pint-0:0.13-1.fc33~bootstrap.src
 python-pybtex-docutils-0:0.2.2-4.fc33.src
 python-pytest-cases-0:1.11.1-3.fc33.src
 python-pytest-harvest-0:1.7.2-3.fc33.src
 python-pytest-steps-0:1.7.2-2.fc33.src
 python-readthedocs-sphinx-ext-0:2.0.0-1.fc33.src
 python-requests-download-0:0.1.2-3.fc33.src
 python-sphinx-copybutton-0:0.2.12-1.fc33.src
 python-sphinxcontrib-bibtex-0:1.0.0-4.fc33.src
 python-wikitcms-0:2.6.3-2.fc33.src
 python-xmlschema-0:1.0.18-3.fc33.src
 python-xmlsec-0:1.3.8-1.fc33.src
 python3-flit-0:2.3.0-3.fc33.noarch
 python3-flit-core-0:2.3.0-3.fc33.noarch

But many of them are only there because the dependency was generated
by {{package|pyproject-rpm-macros}} BuildRequires generator which was
since already updated to use {{package|python3-toml}}. When rebuilt
with updated {{package|pyproject-rpm-macros}}, the dependency will be
replaced with {{package|python3-toml}}.

 $ repoquery --repo=rawhide{,-source} --whatrequires pyproject-rpm-macros
 ansible-lint-0:4.2.0-4.fc33.src
 ilua-0:0.2.1-1.fc33.src
 python-PyGithub-0:1.51-2.fc33.src
 python-black-0:19.10~b0-3.fc33.src
 python-chaospy-0:3.2.12-1.fc33.src
 python-copr-0:1.102-1.fc33.src
 python-decopatch-0:1.4.6-3.fc33.src
 python-elementpath-0:1.4.0-4.fc33.src
 python-latexcodec-0:2.0.1-1.fc33.src
 python-makefun-0:1.6.11-3.fc33.src
 python-numpoly-0:0.2.3-2.fc33.src
 python-openqa_client-0:4.1.0-2.fc33.src
 python-pep517-0:0.7.0-4.fc33.src
 python-pint-0:0.13-1.fc33~bootstrap.src
 python-pybtex-docutils-0:0.2.2-4.fc33.src
 python-pytest-cases-0:1.11.1-3.fc33.src
 python-pytest-harvest-0:1.7.2-3.fc33.src
 python-pytest-steps-0:1.7.2-2.fc33.src
 python-readthedocs-sphinx-ext-0:2.0.0-1.fc33.src
 python-requests-download-0:0.1.2-3.fc33.src
 python-sphinx-copybutton-0:0.2.12-1.fc33.src
 python-sphinxcontrib-bibtex-0:1.0.0-4.fc33.src
 python-tox-current-env-0:0.0.2-5.fc33.src
 python-wikitcms-0:2.6.3-2.fc33.src
 python-xmlschema-0:1.0.18-3.fc33.src
 python-xmlsec-0:1.3.8-1.fc33.src

The only really affected package is {{package|python-flit}}. Upstream
already discusses the transition:
https://github.com/takluyver/flit/issues/255

Once all dependencies are removed, we plan to retire
{{package|python-pytoml}}, whether it will be in Fedora 33 or later.

== Feedback ==
The intent was announced at
https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/MOAHRKMZRFNR34WHPICHCP6MR3IWY4FW/
but there was no feedback. The primary point of contact for the
{{package|python-pytoml}} and {{package|python-toml}} packages is on
board.

== Benefit to Fedora ==
An upstream deprecated package will not be depended upon by new packages.

== Scope ==
* Proposal owners: Deprecate {{package|python3-pytoml}}. Work with
flit upstream to make the transition as well. Once the dependency is
removed from flit, rebuild remaining packages using
{{package|pyproject-rpm-macros}} 

Fedora 33 System-Wide Change proposal: Make nano the default editor

[Ben Cotton]

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

== Summary ==

Let's make Fedora more approachable, by having a default editor that
doesn't require specialist knowledge to use.

== Owner ==
* Name: [[User:chrismurphy| Chris Murphy]]
* Email:  chrismur...@fedoraproject.org


== Detailed Description ==

Users are exposed to the default editor when they use commands that
call it. The main example here is something like git
commit.

Fedora does not currently have a default terminal text editor, because
the $EDITOR environment variable is unset by default. But a common
scenario where users wind up in a terminal text editor is when using
'git commit'. By default, git picks vi. You need to spend time
learning how to use it, for even basic editing tasks. This increases
the barrier to entry for those who are switching to Fedora and don't
know how to use vi. It also makes things hard for those who don't
particularly want to learn how to use vi. (These arguments would apply
just as well if git picked Vim. vi is like hard mode for Vim, with
fewer features, missing syntax highlighting, and no indication of what
mode you are in. Even Vim users may feel lost and bewildered when
using vi.)

In contrast, Nano offers the kind of graphical text editing experience
that people are used to, and therefore doesn't require specialist
knowledge to use. It is already installed across most Fedora Editions
and Spins. This proposal will make Nano the default editor, while
continuing to install vim-minimal (which provides vi, but
not Vim). People will still be able to call vi if they
want to edit a file. It will also obviously be possible to change the
default editor to vi or Vim, for those who want it.

Why make Nano default and vi optional, rather than the other way
round? Because Nano is the option that everyone can use.

== Feedback ==

Pending ...

== Benefit to Fedora ==

* Makes the default editor across all of Fedora more approachable.
* Nano is also mostly self-documenting, by displaying common keyboard
shortcuts on-screen.
* More in line with the default editor of other distributions.

== Scope ==
* Proposal owners:
** Modify comps to include nano Fedora wide.
** Create a new subpackage of nano, called
nano-editor.
** nano-editor to include
/usr/lib/environment.d/10-nano.conf, which sets
$EDITOR to nano.

With this approach, if nano is uninstalled, the
configuration will be removed with it. At the same time, installing
nano on its own won't install the conf.

* Other developers: N/A

* Release engineering: [https://pagure.io/releng/issue/9522 #9522]

* Policies and guidelines: N/A

* Trademark approval: N/A

== Upgrade/compatibility impact ==

Will not apply to upgrades.

== How To Test ==

Run export EDITOR="/usr/bin/nano".

== User Experience ==

Users running git commit will be able to just type their
commit message, rather than having to learn about insert mode, and
they'll be able to cut and paste without having to learn special
shortcuts.

== Dependencies ==

No additional dependencies are required.

== Contingency Plan ==
The contingency plan is to revert the change by removing the
nano-editor package.

* Contingency deadline: probably the beta? It's an easy change to revert.
* Blocks release? If the change breaks the redirection to an editor,
it should block the release. However, this is unlikely.
* Blocks product? Potentially all.

== Documentation ==
As part of this change, it would be good to add instructions for
changing the default editor to the
[https://docs.fedoraproject.org/en-US/quick-docs/ quick docs].


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: intent to update eccodes

[Troy Dawson]

I agree with Jeff.
It looks good, go for it.

On Thu, Jun 25, 2020 at 8:49 AM Jeff Sheltren  wrote:
>
> Hi Jos, seems fine to me; I'd say go for it!
>
> -Jeff
>
> On Wed, Jun 24, 2020 at 12:58 PM Jos de Kloe  wrote:
>>
>> Hi,
>>
>> I received a user request to update eccodes, see:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1850633
>>
>> Currently EPEL7 and EPEL8 have version 2.14 that was published by
>> upstream last October.
>> The latest upstream version is 2.18 and is, as far as I can tell fully
>> backwards compatible with 2.14.
>> However, it does contain a number of bug-fixes and additions.
>>
>> When I look at the update pol;icy:
>> https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Some_examples_of_what_package_updates_that_are_fine_or_not
>> then my guess would be that it is okay to perform this update, since the
>> update is in my eyes minor.
>> The update policy on this page mentions ABI compatibility but does not
>> mention what to do if an ABI change is backward compatible.
>>
>> So since knowing is better than guessing, before putting effort in to
>> this, I would like to ask on this mailing list if my interpretation is
>> correct.
>>
>> Jos de Kloe.
>
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Packagers with no corresponding valid bugzilla accounts

[Kevin Fenzi]

On Thu, Jun 25, 2020 at 03:56:42PM +0200, Felix Schwarz wrote:
> 
> Am 25.06.20 um 14:55 schrieb Pierre-Yves Chibon:
> > Here is an updated list:
> > 
> > @certbot-sig
> > 
> > Please do try to fix this soon!
> 
> I'd love to but unfortunately I'm only a user for the certbot sig and even
> though I think I'm probably the de-facto maintainer of the certbot stack now I
> was not really successful in getting responses from other sig members (trying
> for ~6 months now). Also I only learned about the sig mailing lists via this
> thread here (but I'm not subscribed there and I don't know how to fix that).
> 
> Is there a "non-functional sig" process?

File an infra ticket and we will get you access to the list at least...

kevin


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

Re: Need help to contact: digimer mbartos, ignotusp

[Digimer]

digimer here, sorry, I'm not sure why my address was rejected. I can
also be reached at 'mke...@alteeve.ca'.

Madi

On 2020-06-25 9:08 a.m., Pierre-Yves Chibon wrote:
> Good Morning Everyone,
> 
> As announced on devel-announce [1] I have sent an email to each account listed
> on dist-git to be either point of contact or included in the CC list of 
> tickets
> opened on bugzilla.
> 
> The following emails to the following account came back with and error:
> - digimer  (error: Recipient address rejected: alteeve.ca)
>   - Maintains: rpms/kronosnet
> - mbartos  (error: Recipient address rejected: Access denied)
>   - Maintains: rpms/libee, rpms/libestr, rpms/liblognorm
> - ignotusp (error:  No such user!)
>   - Maintains: rpms/wicd-kde
> 
> Does anyone know how to contact these persons?
> 
> If we have no way to contact them, we may have to ask FESCo to consider them
> unresponsive.
> 
> Thanks in advance for your help!
> 
> Pierre
> 
> 
> [1]: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VBMMXJT2M5TMWSH3DT3DY6VBPELSTQFV/
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 


-- 
Digimer
Papers and Projects: https://alteeve.com/w/
"I am, somehow, less interested in the weight and convolutions of
Einstein’s brain than in the near certainty that people of equal talent
have lived and died in cotton fields and sweatshops." - Stephen Jay Gould
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: apt-cacher-ng not working on CentOS 7

[Nicolas Kovacs]

Le 25/06/2020 à 16:56, Sérgio Basto a écrit :
> also [1] could help it says that you need create a directory 
> 
> also the package is orphan and was retired on F33 , I may take it ,if
> have an easy fix ... 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1738884

Worked like a charm.

Thanks very much (also to Scott Talbert who answered earlier).

My sandbox installation (CentOS 7 server, OpenSUSE Leap 15 clients) is
beginning to work nicely.

Cheers,

Niki

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
Mob. : 06 51 80 12 12
___
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 1850767] Add perl-DateTime-Set to EPEL8 / co-maintainer request

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2020-1a69cd3a87 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1a69cd3a87


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

[EPEL-devel] Re: intent to update eccodes

[Jeff Sheltren]

Hi Jos, seems fine to me; I'd say go for it!

-Jeff

On Wed, Jun 24, 2020 at 12:58 PM Jos de Kloe  wrote:

> Hi,
>
> I received a user request to update eccodes, see:
> https://bugzilla.redhat.com/show_bug.cgi?id=1850633
>
> Currently EPEL7 and EPEL8 have version 2.14 that was published by
> upstream last October.
> The latest upstream version is 2.18 and is, as far as I can tell fully
> backwards compatible with 2.14.
> However, it does contain a number of bug-fixes and additions.
>
> When I look at the update pol;icy:
>
> https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Some_examples_of_what_package_updates_that_are_fine_or_not
> then my guess would be that it is okay to perform this update, since the
> update is in my eyes minor.
> The update policy on this page mentions ABI compatibility but does not
> mention what to do if an ABI change is backward compatible.
>
> So since knowing is better than guessing, before putting effort in to
> this, I would like to ask on this mailing list if my interpretation is
> correct.
>
> Jos de Kloe.
>
___
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: Avoiding the automatic /usr/bin/python3 dep

[Richard Hughes]

On Thu, 25 Jun 2020 at 14:57, Miro Hrončok  wrote:
> What you need is to disable is the "shebang dependency generator" from RPM. 
> The
> easiest way is to use:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/
>  %global __requires_exclude ^%{python3}$

Works perfectly, thanks!

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

Re: Default editor for LXQt spin

[Raphael Groner]

Hi Zamir,

thanks and no problem. I even forgot about this issue.

Regards

Raphael


Am 24.06.20 um 14:47 schrieb Zamir SUN:



On 12/11/18 7:52 AM, Raphael Groner wrote:

Hi,

writing to general devel list intentionally. No idea if all members
of lxqt-sig list can read here, too and especially @zsun.



Hi Raphael

I'm realy sorry, there are too many emails in devel so when I am not
on cc list it's high chance that I will miss emails. I happen to see
this just now because I was searching hard for something in the list
(and it's already 18 months old email).


Is there any sense why @lxqt-sig is member of packaging for
featherpad? LXQt SIG decided to have enki in the spin as the default
editor. Featherpad is not part of LXQt upstream.

@lupinix Could you remove lxqt-sig from the members in pagure?


I see I am the owner of this package at the moment (not sure why/when,
but I guess it's lupinix moved it to me sometime ago). So I just
removed @lxqt-sig from the committer.

I just added you as committer in case you still want to commit to that
package.

HTH.



Regards, Raphael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
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: apt-cacher-ng not working on CentOS 7

[Sérgio Basto]

On Thu, 2020-06-25 at 09:15 -0400, Scott Talbert wrote:
> On Thu, 25 Jun 2020, Nicolas Kovacs wrote:
> 
> > Hi,
> > 
> > I've been using the nifty apt-cacher-ng package cache successfully
> > on Debian.
> > 
> > Now I'd like to run it on our local server running CentOS 7. I
> > installed the
> > package from EPEL, but the service fails to start.
> > 
> > On Debian, running apt-cacher-ng is a matter of installing it,
> > firing it up and
> > then pointing clients to the proxy.
> > 
> > Any idea why the service is failing on CentOS ?
> 
> Unfortunately, it appears there is currently no maintainer for the
> package 
> in Fedora.
> 
> It sounds like this problem has been known for a while:
> https://bugzilla.redhat.com/show_bug.cgi?id=1734712

also [1] could help it says that you need create a directory 

also the package is orphan and was retired on F33 , I may take it ,if
have an easy fix ... 

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

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

[Bug 1850915] Add perl-DateTime-Format-Natural to EPEL8

[bugzilla]

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

Fedora Admin user for bugzilla script actions 
 changed:

   What|Removed |Added

   Assignee|jples...@redhat.com |ppi...@redhat.com



--- Comment #2 from Fedora Admin user for bugzilla script actions 
 ---
This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.


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