date:20191203

[389-devel] 389 DS nightly 2019-12-04 - 95% PASS

2019-12-03 Thread vashirov

https://fedorapeople.org/groups/389ds/ci/nightly/2019/12/04/report-389-ds-base-1.4.2.4-20191204gitff75058.fc31.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[Bug 1778463] [RFE] EPEL-8 branch for perl-Data-Float

2019-12-03 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-Data-Float-0.013-7.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f1d32085d8

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

[389-devel] please review: PR 50765 - Port readnsstate to CLI and healthcheck

2019-12-03 Thread Mark Reynolds


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

--

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

[EPEL-devel] Re: "python3" vs "python%{python3_pkgversion}"

2019-12-03 Thread Orion Poplawski


On 12/2/19 4:54 PM, Kevin Fenzi wrote:

On Tue, Dec 03, 2019 at 12:38:01AM +0100, Miro Hrončok wrote:

On 02. 12. 19 23:09, Ken Dreyer wrote:

On Mon, Dec 2, 2019 at 11:47 AM Neal Gompa  wrote:


On Mon, Dec 2, 2019 at 1:34 PM Ken Dreyer  wrote:


Hi folks,

In EPEL 7 we have some packages with "python34" and "python36"
prefixes in their names. I guess this is a consequence of using the
%{python3_pkgversion} macro over time.

Now that RHEL 7 has Python 3.6, and we want to deprecate Python 3.4 in
EPEL 7, I'm wondering about this.

If I'm introducing a Python 3 subpackage in a new build today, should
I name this sub-package "python3-foo" or
"python%{python3_pkgversion}-foo" ?



The subpackage should be "python%{python3_pkgversion}-foo" and you
should also make sure you have "%{?python_provide:%python_provide
python%{python3_pkgversion}-foo}" in the subpackage declaration too.


This is confusing to me, and it diverges from what Fedora does. Can we
just reduce this down to "python3-" now that RHEL 7 has python3, and
we'll probably never put another Python version into EPEL 7?


We **can** but we **haven't yet**. IMHO doing it in random packages is wrong.

Currently, python36-foo is form EPEL (and if done right, provides python3-foo).
OTOH python3-bar is from RHEL (and if done right, provides python36-bar).

They both provide both names, but from first glance, the origin of the
package is obvious. I kinda like that.

If we decide to redo this, it will be a lot of boring work for no clear benefit.
If we decide to only allow it for new packages, it would be a mess.

That said, technically:

  - it works either way
  - there is no real EPEL packaging guideline forcing one way or the other


I think we should encourage people to just use python3-foo now, but I
agree it would be a lot of work to try and convert everything to do
that.

The orig reason was so we could move python stacks forward since we were
maintaining them in epel. Since python 3.6 is in rhel and rhel7 is past
the point where I would expect many changes, I think 3.6 is here to
stay, so we dont really need it anymore. It's just extra noise that
makes spec files less readable now.

kevin


I'd like to see some broader discussion about what we might face in the 
future with RHEL8 and how we might handle that.  I'm also not so sure 
that there won't be some kind of push for python 3.8 in EL7 at some 
point since EOL is 6/30/2024.



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



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

Subject: Self Introduction Blaise Pabon

2019-12-03 Thread Blaise Pabon

Hi everybody,

I'm a relatively new contributor, although I have been watching from the
sidelines since 1993.

A few years ago (as penance for 15 years in sales) I got back into an ops
position doing release management and I became a pythonista... the
community is wonderful.

I'm a strong advocate for community and inclusion and you may have read
some of my opinions in the comm-ops discourse.

Now, I would like to help adopt some orphan packages. I'm very busy in real
life so I want to be moderate in my commitments.
I think I will start with:
https://src.fedoraproject.org/rpms/python-sanic/blob/master/f/python-sanic.spec

because I have some experience with the upstream project and they are such
great people that I would like to see their work well represented in Fedora.

Please feel free to contact me for any reason whatsoever. I live in the
Santa Cruz Mountains and I love to have guests (as long as they don't mind
the dogs).

Cheers,
Blaise

PGP: 8FFC 1948 1B91 952C C26C  79F8 95F8 AB09 5428 8CEB
-- 
LinkedIn   |  Quora
  |  Github

“If you want to go fast, go alone. If you want to go far, go
together.” --African
proverb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1749126] perl-Glib-Object-Introspection should depend on perl-Gtk3

2019-12-03 Thread bugzilla

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

Sergio Monteiro Basto  changed:

   What|Removed |Added

 CC||ser...@serjux.com



--- Comment #6 from Sergio Monteiro Basto  ---
perl-gtk3 depends on perl-Glib-Object-Introspection to build

-- 
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 1759801] please build perl-gtk3 for epel 8

2019-12-03 Thread bugzilla

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

Sergio Monteiro Basto  changed:

   What|Removed |Added

 Depends On||1778302




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1778302
[Bug 1778302] please build perl-Glib for EPEL8
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1778302] please build perl-Glib for EPEL8

2019-12-03 Thread bugzilla

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

Sergio Monteiro Basto  changed:

   What|Removed |Added

 Blocks||1759801




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1759801
[Bug 1759801] please build perl-gtk3 for epel 8
-- 
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 1759801] please build perl-gtk3 for epel 8

2019-12-03 Thread bugzilla

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



--- Comment #5 from Sergio Monteiro Basto  ---
I tried a scratch build on epel8-playground [1]  and failed with missing
packages [2]

[1] 
https://koji.fedoraproject.org/koji/taskinfo?taskID=39426113

[2]
DEBUG util.py:596:  No matching package to install: 'perl(Cairo::GObject) >=
1.000'
DEBUG util.py:596:  No matching package to install: 'perl(Glib)'
DEBUG util.py:596:  No matching package to install:
'perl(Glib::Object::Introspection) >= 0.043'
DEBUG util.py:596:  No matching package to install:
'perl(Glib::Object::Subclass)'

-- 
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: RFC: Branch requests from non-maintainers

2019-12-03 Thread Kevin Kofler

Peter Robinson wrote:
> We already have a process for that. They reach out to the maintainer
> to be a co-maintainer at which point they can request the branches and
> do the builds.

The process we already have is actually:
https://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL#The_procedure_for_getting_a_package_in_EPEL
which does not require bothering the maintainer who is explicitly not 
interested in EPEL with this bureaucracy.

I do not want to have to care about EPEL branches for my packages and I will 
not approve any comaintainership requests for that sole purpose. I do not 
see why I should have to. Whoever wants the package for EPEL should just be 
allowed to request and own the branch without wasting my time.

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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-03 Thread Kevin Kofler

Lennart Poettering wrote:
> The problem is that sshd's PAM implementation doesn't allow PAM
> modules to ask questions in login sessions which are authenticated via
> authorized_keys instead of PAM. Because if we could ask questions
> then, we could simply ask the user for the passphrase to derive the
> LUKS key from if we need. That would mean that if you SSH login if you
> already are logged in locally, then logins would be instant, but if
> you SSH login otherwise then you'd get a prompt for the pw first.

I think a proper SSH integration would actually store a LUKS keyfile 
encrypted with the SSH public key somewhere in .ssh, and on login, send that 
to the client, have that decrypt it with the SSH private key and send it 
back, and use the decrypted key to unlock the LUKS partition.

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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-03 Thread Kevin Kofler

John M. Harris Jr wrote:
> however with Plasma, my desktop environment doesn't have to be loaded at
> all in order for me to ssh in.

This depends (even in the absence of disk encryption) on where you have told 
plasma-nm to store your WPA (or 802.11x etc.) credentials (unless you are 
using an entirely open network). (The credential storage strategy is 
configurable in plasma-nm.)

If the credentials are stored in system-wide unencrypted storage, you can 
SSH in immediately. If they are stored in your KWallet, you have to log in 
first so that plasma-nm knows what wallet to unlock, and if you use the 
default setup, so that the KWallet PAM module can use your login password to 
unlock your wallet. (You can also have an entirely passwordless KWallet, but 
even that would not help you in this case because NM would still not know 
where to look for your credentials. You need to have plasma-nm running, and 
as the correct user, to get working KWallet NM integration.) And if you use 
a non-empty KWallet password that is not your login password, you also have 
to enter that, of course.

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

[Bug 1772833] Add perl-DepGen-Perl-Tests to EPEL 8

2019-12-03 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2019-12-04 01:55:52



--- Comment #4 from Fedora Update System  ---
perl-DepGen-Perl-Tests-0.1.2-11.el8, perl-RPM2-1.4-10.el8 has been pushed to
the Fedora EPEL 8 stable repository. If problems still persist, 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 1772831] Add perl-RPM2 to EPEL8

2019-12-03 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2019-12-04 01:55:50



--- Comment #4 from Fedora Update System  ---
perl-DepGen-Perl-Tests-0.1.2-11.el8, perl-RPM2-1.4-10.el8 has been pushed to
the Fedora EPEL 8 stable repository. If problems still persist, 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 1772833] Add perl-DepGen-Perl-Tests to EPEL 8

2019-12-03 Thread bugzilla

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

Bug 1772831 Summary: Add perl-RPM2 to EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1772831

   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

Re: Help with rubygem packaging

2019-12-03 Thread Leigh Scott

Thank you for the examples and hints

> 2. Adding %check section, as Jaroslav said.
> Note that we do not use "bundler" ("bundle" command) and
> "rake"
> command in RPM *.spec file.
> 
 I have removed bundler and rake from linked-list, the test doesn't seem to run 
anything

+ pushd ./usr/share/gems/gems/linked-list-0.0.13
~/rpmbuild/BUILD/linked-list-0.0.13/usr/share/gems/gems/linked-list-0.0.13 
~/rpmbuild/BUILD/linked-list-0.0.13
+ sed -i '/bundler/ s/^/#/' Rakefile
+ ruby -Ilib:. -e 'Dir.glob "test/**/test_*.rb", (:require)'
Run options: --seed 28775

# Running:



Fabulous run in 0.000872s, 0. runs/s, 0. assertions/s.

0 runs, 0 assertions, 0 failures, 0 errors, 0 skips
+ popd


> 3. Following *.spec files might be useful to refer.
> 
> https://src.fedoraproject.org/rpms/rubygem-listen/blob/master/f/rubygem-l...
>   with Ruby C-extention.
> https://src.fedoraproject.org/rpms/rubygem-rake/blob/master/f/rubygem-rak...
>   without Ruby C-extension.

Looks like %check for hrx is a no go due to missing dep that isn't present in 
the repo

+ pushd ./usr/share/gems/gems/hrx-1.0.0
~/rpmbuild/BUILD/hrx-1.0.0/usr/share/gems/gems/hrx-1.0.0 
~/rpmbuild/BUILD/hrx-1.0.0
+ ln -s /home/leigh/rpmbuild/BUILD/spec spec
+ rspec -rspec_helper spec

An error occurred while loading ./spec/archive_spec.rb.
Failure/Error: require 'rspec/temp_dir'
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-03 Thread Chris Murphy

On Tue, Dec 3, 2019 at 12:05 AM John M. Harris Jr  wrote:
>
> > It's not just an issue for systemd-homed, this problem applies to any
> > user home encryption implementation when the user has not first
> > authenticated/unlocked their user home. e.g. if you install with /home
> > encrypted in Anaconda, in fact your boot stops at plymouth in the
> > initramfs so sshd is thwarted from even starting in the first place;
> > and even if GNOME Shell's login were to be enhanced to do this unlock,
> > still requires unlock.
>
> That is simply not the case. I don't know what you're referring to with "if
> you install with /home encrypted in Anaconda",

Anaconda custom partitioning has a per mount point encryption option.
I can LUKS encrypt only the volume mounted at /home. And if I do this,
startup is inhibited at a plymouth prompt for a passphrase, the same
as if I check the earlier "encrypt my data" option at Destination
Installation - which is the FDE layout.

sshd doesn't startup until after this. You can't ssh into your system
before user home is unlocked. There is at least a chance of this with
systemd-homed even if it's not yet implemented.

>or why GNOME Shell would have
> anything to ssh, however with Plasma, my desktop environment doesn't have to
> be loaded at all in order for me to ssh in.

That's because you are physically present to type in a passphrase
during boot. And that exposes all user data as plaintext too, in the
FDE case. The only thing protecting user data are discretionary access
controls.

The reason for a full desktop environment stack being available at
LUKS unlock time has to do with various UX problems with the much more
limited initramfs+plymouth environment. This is elaborated on in the
Workstation WG issue I referenced. An open question is to what degree
we run into those same kinds of problems with remote login.

>
> > Basically you have to choose between user home security (or more
> > specifically privacy) and remote logins. However, there are some ideas
> > that could possibly work around this, to varying degrees of
> > inelegance, which I'll gratuitously copy from a related Workstation WG
> > issue [1].
>
> You really don't. It's pretty much there by default, and there's not a lot
> that I have to change from a default Plasma install. Doing an Anaconda guided
> LVM full disk encryption setup is sufficient to protect data at rest.

It's a valid argument that when a user is not logged in, their data
should be at rest and encrypted. systemd-homed is one possible way to
address that, not necessarily the only way, but for sure the current
options in the installer don't address it.

--
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: RFC: Branch requests from non-maintainers

2019-12-03 Thread Peter Robinson

On Mon, Dec 2, 2019 at 2:04 PM Mat Booth  wrote:
>
> On Mon, 2 Dec 2019 at 12:56, Igor Gnatenko  
> wrote:
>>
>> Hello,
>>
>> 3 months ago, Miro opened releng ticket[0] raising question whether
>> non-maintainers (of some specific packages) being able to request
>> branches.
>>
>> However, it never went anywhere outside of that ticket.
>>
>> I'd like to ask people on this mailing list a few questions. Let's say
>> we have some theoretical package and it has only one maintainer in
>> src.fp.o.
>>
>> * Should any other packager (not that maintainer) be able to request
>> new branches on that repo?
>
>
> Is there a problem with adding such other packagers as comaintainers if they 
> want to maintain such a branch?
>
> For example: I am not at all interested in EPEL branches, but if someone 
> wants to maintain an EPEL branch of my package, I have absolutely no problem 
> with adding them as a co-maintainer.

We already have a process for that. They reach out to the maintainer
to be a co-maintainer at which point they can request the branches and
do the builds.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Help with rubygem packaging

2019-12-03 Thread Jun Aruga

> https://bugzilla.redhat.com/show_bug.cgi?id=1779403
> https://bugzilla.redhat.com/show_bug.cgi?id=1779404

I checked your uploaded *.spec files now a little bit.
I see that you are using "rake" in your rubygem-linked-list.spec,
and there is no %check section in your rubygem-hrx.spec.

> Note that we do not use "bundler" ("bundle" command) and "rake"
command in RPM *.spec file.

I am understanding that the reasons not using bundle and rake command
in the RPM *.spec file are

1. to simplify the build dependency tree.
2. to debug the unit tests easily if you face an issue in the unit test logic.
  "bundle" and "rake" sometimes make you harder to debug, as they have
their own issues.

So, referring the Ruby guideline page - minitest and rspec test cases,
your *.spec files could be like this.
https://docs.fedoraproject.org/en-US/packaging-guidelines/Ruby/#_testing_frameworks_usage


## rubygem-linked-list.spec

```
...
BuildRequires: rubygem(minitest)
...
%check
pushd .%{gem_instdir}
ruby -e 'Dir.glob "./test/**/*_test.rb", (:require)'
popd
```

## rubygem-hrx.spec

```
...
BuildRequires: rubygem(rspec)
...
%check
pushd .%{gem_instdir}
rspec -Ilib spec
popd
```


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

Re: js-jquery - Re: List of long term FTBFS packages to be retired in February (beta)

2019-12-03 Thread Sérgio Basto

On Tue, 2019-12-03 at 19:34 +, Sérgio Basto wrote:
> On Tue, 2019-12-03 at 08:18 +, Tom Hughes wrote:
> > Ben Rosser was working on sorting out grunt. In fact I believe he
> > took the first of those at least.
> 
> OK then I taking nodejs-load-grunt-tasks [1]

I need a provenpackager that do : 
git checkout f31 && git merge master && fedpkg push && fedpkg build on
[1] to be able to build nodejs-load-grunt-tasks on F31 .

Thanks

[1]
https://src.fedoraproject.org/rpms/nodejs-locate-path/pull-request/1


> [1]
> https://pagure.io/releng/issue/9077
> 
> > Tom
> > 
> > On 03/12/2019 07:45, Vít Ondruch wrote:
> > > According to [1], these are the packages which need to be
> > > preserved
> > > to
> > > keep js-jquery around:
> > > 
> > > 
> > > nodejs-grunt-legacy-util
> > > 
> > > nodejs-load-grunt-tasks
> > > 
> > > nodejs-raw-body
> > > 
> > > 
> > > Vít
> > > 
> > > 
> > > [1] https://churchyard.fedorapeople.org/orphans-2019-12-02.txt
> > > 
> > > 
> > > Dne 03. 12. 19 v 2:24 Sérgio Basto napsal(a):
> > > > I will take nodejs-dateformat .
> > > > Do you have a list of what more packages we have to keep?
> > > > 
> > > > 
> > > > On Mon, 2019-12-02 at 15:52 +0100, Raphael Groner wrote:
> > > > > Thanks a lot.
> > > > > 
> > > > > Am 02.12.19 um 15:20 schrieb Tom Hughes:
> > > > > …
> > > > > > As I explained the other day js-jquery was dependent on a
> > > > > > nodejs module (a normal one, not modularised) which was
> > > > > > failing to build and which I have now fixed.
> > > > > …
> > > > > ___
> > > > > devel mailing list -- devel@lists.fedoraproject.org
> > > > > To unsubscribe send an email to 
> > > > > devel-le...@lists.fedoraproject.org
> > > > > Fedora Code of Conduct:
> > > > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > > List Guidelines:
> > > > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > > List Archives:
> > > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to 
> > > devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct: 
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: 
> > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: 
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > > 
> > 
> > -- 
> > Tom Hughes (t...@compton.nu)
> > http://compton.nu/
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: 
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> -- 
> Sérgio M. B.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-03 Thread Chris Murphy

On Mon, Dec 2, 2019 at 11:58 PM John M. Harris Jr  wrote:
>
> On Monday, December 2, 2019 12:46:30 PM MST Chris Murphy wrote:
> > It's almost 2020, and I shouldn't have to pick and choose between
> > remote access and securing user data at rest by default.
>
> You don't have to. Data at rest would mean that your system is powered off, or
> suspended to disk. You can have that now with full disk encryption, just as I
> do. Depending on your system, you can actually encrypt the entire disk such
> that you don't even have a partition table. I do this with my X200 Tablet,
> where GRUB is loaded from flash, which decrypts my disk, and then mounts ZFS
> mountpoints, swaps on a ZFS zdev.

OK you just took a 90 degree turn, detouring the line of discussion,
which was your premise that systemd-homed is pointless if the user
can't ssh into it. There is no difference between a systemd-homed
encrypted user home, and FDE, in this respect. Someone must type in a
passphrase to unlock the volume that contains the user home you want
access to it with ssh, in both cases. In your case you have to
physically type that passphrase when you startup, at plymouth. In the
systemd-homed case, login and crypto home unlock are tied together.

I actually prefer the idea that'd if I'm not logged in, my data is
considered at rest and crypto home is locked, in contrast to how FDE
does it which treats my data as not at rest even though I'm not logged
in at all.

Trying to get back on track with this thread though, if systemd-homed
is available by the time startup reaches rescue.target, does this
somewhat confuse the distinction of whatever multi-user.target is,
which would then rather be more like manyservices.target in contrast
to fewservices.target? I also don't know if systemd-homed is simple
enough that it's a good idea to make it available by rescue.target.
But then, also what about emergency.target which is even more
rudimentary and likewise requires root?

systemd.debug-shell=1 does provide a root shell on tty9, by the time
rescue.target is reached. And in that shell I can extract
rdsosreport.txt or a full journal among other things, and get running
again. It's admittedly obscure knowledge though.

-- 
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: Help with rubygem packaging

2019-12-03 Thread Jun Aruga

Hi Leigh,
Thank you for contributing the rubygem-* packages.

Let me comment for your *.spec files.

I recommend to compare the *.spec file generated by gem2rpm with your
*.spec file, and align basically.
The gem2rpm guides you.

How to do it (For example in case of Fedora 30)

```
$ sudo dnf install rubygem-gem2rpm

$ rpm -q rubygem-gem2rpm
rubygem-gem2rpm-1.0.1-3.fc30.noarch

$ gem fetch hrx

$ ls -l hrx-1.0.0.gem

$ gem2rpm hrx-1.0.0.gem > rubygem-hrx.spec
```

If you find some improvements for generated spec file, you can report it here.
https://github.com/fedora-ruby/gem2rpm

2. Adding %check section, as Jaroslav said.
Note that we do not use "bundler" ("bundle" command) and "rake"
command in RPM *.spec file.

3. Following *.spec files might be useful to refer.

https://src.fedoraproject.org/rpms/rubygem-listen/blob/master/f/rubygem-listen.spec
  with Ruby C-extention.
https://src.fedoraproject.org/rpms/rubygem-rake/blob/master/f/rubygem-rake.spec
  without Ruby C-extension.

"gem unpack" is useful to see the files in the *.gem file.
As hrx-1.0.0.gem and linked-list-0.0.13.gem are including the unit
test files in it,
Possibly "Source0" is good enough. Note above 2 *.spec files use
"Source1" too, as gem file does not include the unit test files.

```
$ gem unpack hrx-1.0.0.gem
Unpacked gem: '/home/jaruga/doc/memo/20191203_review_rubygem_pkgs/hrx-1.0.0'
```

Happy building!

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

Re: Help with rubygem packaging

2019-12-03 Thread Leigh Scott

Thanks, I didn't know about gem2rpm.

Reviews submitted (needed for sassc tests).

https://bugzilla.redhat.com/show_bug.cgi?id=1779403
https://bugzilla.redhat.com/show_bug.cgi?id=1779404
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned camlp4 dependencies (was: Re: Orphaned packages looking for new maintainers)

2019-12-03 Thread Richard W.M. Jones

On Mon, Dec 02, 2019 at 11:42:19PM -0500, Yaakov Selkowitz wrote:
> On Mon, 2019-12-02 at 19:49 +, Richard W.M. Jones wrote:
> > On Mon, Dec 02, 2019 at 07:15:27PM +0100, Miro Hrončok wrote:
> > > ocaml-bin-protorphan   2 
> > > weeks ago
> > > ocaml-bisect  orphan   2 
> > > weeks ago
> > > ocaml-bitstring   orphan   2 
> > > weeks ago
> > > ocaml-derivingorphan   2 
> > > weeks ago
> > > ocaml-json-static orphan   2 
> > > weeks ago
> > > ocaml-mikmatchorphan   2 
> > > weeks ago
> > > ocaml-openin  orphan   2 
> > > weeks ago
> > > ocaml-pa-monadorphan   2 
> > > weeks ago
> > > ocaml-pgocaml orphan   2 
> > > weeks ago
> > > ocaml-sexplib orphan   2 
> > > weeks ago
> > > ocaml-type-conv   orphan   2 
> > > weeks ago
> > > ocamldsortorphan   2 
> > > weeks ago
> > 
> > These were deliberately orphaned so are not really looking for new
> > maintainers.  However if anyone does decide to take them on be sure to
> > read this email carefully first:
> > 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/G2JBIWB423ECYGBXZ3QCPR7NQ66XGXTU/
> 
> Note that a week and a half later there was a 4.08+1 release of camlp4.

I added that to Fedora.  The larger point is still true - camlp4 is
dead upstream and we're not expecting it to be available in the
soon-to-be-packaged 4.09, or later versions, and so anything depending
on it will have to be replaced sooner or later.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 update spam (was: [Fedora Update] [comment] nbdkit-1.17.1-2.fc32)

2019-12-03 Thread Richard W.M. Jones

I understood the message the first time, so I didn't need to be
emailed 147 times (so far) about it.

Is there something I can do to stop this spam?

On Tue, Dec 03, 2019 at 10:15:06PM +, upda...@fedoraproject.org wrote:
> The following comment has been added to the nbdkit-1.17.1-2.fc32 update:
> 
> bodhi - 2019-12-03 22:15:06.936646 (karma: 0)
> This update cannot be pushed to stable. These builds nbdkit-1.17.1-2.fc32 
> have a more recent build in koji's f32 tag.
> 
> To reply to this comment, please visit the URL at the bottom of this mail
> 
> 
>  FEDORA-2019-d9458cbc80
> 
> Release: Fedora 32
>  Status: testing
>Type: unspecified
>Severity: unspecified
>   Karma: 0
>   Notes: Automatic update for nbdkit-1.17.1-2.fc32.
>   Submitter: rjones
>   Submitted: 2019-12-03 14:49:59.532812
>Comments: bodhi - 2019-12-03 22:15:06.936646 (karma 0)
>  This update cannot be pushed to stable. These builds
>  nbdkit-1.17.1-2.fc32 have a more recent build in
>  koji's f32 tag.
>  bodhi - 2019-12-03 22:15:06.528197 (karma 0)
>  This update can be pushed to stable now if the
>  maintainer wishes
>  bodhi - 2019-12-03 14:52:01.913376 (karma 0)
>  This update's test gating status has been changed to
>  'ignored'.
>  bodhi - 2019-12-03 14:52:01.843651 (karma 0)
>  This update's test gating status has been changed to
>  'waiting'.
>  bodhi - 2019-12-03 14:49:59.536128 (karma 0)
>  This update was automatically created
> 
>   https://bodhi.fedoraproject.org/updates/FEDORA-2019-d9458cbc80


Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.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: Help with rubygem packaging

2019-12-03 Thread Jaroslav Prokop


Hi,

great to see someone taking up on some rubygems!

to the packages, the rubygem-linked-list as mentioned by Fabio have 
binaries that will probably have name conflicts with some other packages.


Secondly rubygem-hrx should not have `Requires: rubygem(linked-list)`[0] 
because that dependency is automatically generated from package's 
gemspec. So rubygem-thor will get pulled in as well as a result.


I highly recommend running the test suite in %check section[1], since 
ruby cannot catch some basic stuff at compile time (because there is no 
compilation :) ) unlike with let's say Java.


Also I think you can submit package review requests with the state it is 
in and there we can help you with each package in their own bug threads, 
even if you have no experience.


Cheers,

Jarek


[0] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Ruby/#_rubygems


[1] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Ruby/#_running_test_suites


On 03/12/2019 19:08, Leigh Scott wrote:

Hi,

Can someone  check these specfiles before I submit review requests please?
I have zero experience with packaging rubygem packaes.

https://leigh123linux.fedorapeople.org/pub/SPECS/rubygem-hrx.spec
https://leigh123linux.fedorapeople.org/pub/SPECS/rubygem-linked-list.spec

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

Fedora-Rawhide-20191203.n.1 compose check report

2019-12-03 Thread Fedora compose checker

No missing expected images.

Compose FAILS proposed Rawhide gating check!
5 of 43 required tests failed, 1 result missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 10/161 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-Rawhide-20191202.n.0):

ID: 492875  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/492875
ID: 492884  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/492884

Old failures (same test failed in Fedora-Rawhide-20191202.n.0):

ID: 492725  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/492725
ID: 492740  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/492740
ID: 492741  Test: x86_64 Server-dvd-iso server_cockpit_default **GATING**
URL: https://openqa.fedoraproject.org/tests/492741
ID: 492753  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/492753
ID: 492766  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/492766
ID: 492791  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/492791
ID: 492796  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/492796
ID: 492810  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/492810
ID: 492886  Test: x86_64 KDE-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/492886

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

New soft failures (same test not soft failed in Fedora-Rawhide-20191202.n.0):

ID: 492727  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/492727
ID: 492751  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/492751
ID: 492867  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/492867
ID: 492868  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/492868

Old soft failures (same test soft failed in Fedora-Rawhide-20191202.n.0):

ID: 492719  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/492719
ID: 492720  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/492720
ID: 492728  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/492728
ID: 492768  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/492768
ID: 492803  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/492803
ID: 492833  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/492833
ID: 492834  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/492834
ID: 492866  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/492866

Passed openQA tests: 135/161 (x86_64)

New passes (same test not passed in Fedora-Rawhide-20191202.n.0):

ID: 492888  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/492888
ID: 492897  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/492897

Skipped gating openQA tests: 1/161 (x86_64)

Old skipped gating tests (same test skipped in Fedora-Rawhide-20191202.n.0):

ID: 492739  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/492739

Skipped non-gating openQA tests: 4 of 163

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
Used swap changed from 5 MiB to 6 MiB
System load changed from 0.68 to 0.30
Previous test data: https://openqa.fedoraproject.org/tests/491832#downloads
Current test data: https://openqa.fedoraproject.org/tests/492761#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
Used swap changed from 5 MiB to 6 MiB
Previous test data: https://openqa.fedoraproject.org/tests/491833#downloads
Current test data: https://openqa.fedoraproject.org/tests/492762#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
Used mem changed from 800 MiB to 996 MiB
1 services(s) added since previous compose: pcscd.service
System load changed from 2.33 to 2.74
Average CPU usage changed from 2.28571429 to 78.5
Previous test data: https://openqa.fedoraproject.org/tests/491848#downloads
Current test

Re: Help with rubygem packaging

2019-12-03 Thread Fabio Valentini

On Tue, Dec 3, 2019 at 7:08 PM Leigh Scott  wrote:
>
> Hi,
>
> Can someone  check these specfiles before I submit review requests please?
> I have zero experience with packaging rubygem packaes.
>
> https://leigh123linux.fedorapeople.org/pub/SPECS/rubygem-hrx.spec
> https://leigh123linux.fedorapeople.org/pub/SPECS/rubygem-linked-list.spec
>
> Best regards
> Leigh

Hi Leigh,

Those two packages look like two pretty standard rubygem packages
(probably coming from manually sanitized gem2rpm output?).
The only strange things I see at first glance are the two binaries
that are shipped with linked-list: "setup" and "console" (and usually,
ruby scripts are copied to _bindir, not moved).
Are these binaries / scripts really necessary? The package will
conflict with some other, already existing fedora packages due to the
overly generic names for these binaries.

Fabio

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

[Bug 1779326] EPEL 8 build of perl-switch?

2019-12-03 Thread bugzilla

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



--- Comment #3 from Tom "spot" Callaway  ---
It is in the 8.1 package manifest. You might need to file a RHEL support ticket
here.

-- 
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 1779326] EPEL 8 build of perl-switch?

2019-12-03 Thread bugzilla

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



--- Comment #2 from Erinn Looney-Triggs  ---
Tom,
Can you double check that 1% cause I am having a tough time finding it:
[root@localhost ~]# yum search perl-Switch
Updating Subscription Management repositories.
No matches found.

Looking at the packages listed through the access portal it doesn't appear
either:
https://access.redhat.com/downloads/content/479/ver=/rhel---8/8.1/x86_64/packages

Perhaps there is something I am not understanding or perhaps we have a bug
against RHEL here?

-Erinn

-- 
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: js-jquery - Re: List of long term FTBFS packages to be retired in February (beta)

2019-12-03 Thread Ben Rosser

On Tue, Dec 3, 2019 at 3:18 AM Tom Hughes  wrote:
>
> Ben Rosser was working on sorting out grunt. In fact I believe he
> took the first of those at least.
>
> Tom
>
> On 03/12/2019 07:45, Vít Ondruch wrote:
> > According to [1], these are the packages which need to be preserved to
> > keep js-jquery around:
> >
> >
> > nodejs-grunt-legacy-util
> >
> > nodejs-load-grunt-tasks
> >
> > nodejs-raw-body

Yes, I started it awhile ago and made some progress. I think it's
still broken though; I lost track of where I'd gotten to. :(

I had fixed legacy-util but didn't own it; I've just claimed the
package in Pagure. Rawhide has the latest version.

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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-03 Thread Przemek Klosowski via devel


On 12/3/19 1:57 AM, John M. Harris Jr wrote:

On Monday, December 2, 2019 12:46:30 PM MST Chris Murphy wrote:

It's almost 2020, and I shouldn't have to pick and choose between
remote access and securing user data at rest by default.

You don't have to. Data at rest would mean that your system is powered off, or
suspended to disk. You can have that now with full disk encryption, just as I
do. Depending on your system, you can actually encrypt the entire disk such
that you don't even have a partition table. I do this with my X200 Tablet,
where GRUB is loaded from flash, which decrypts my disk, and then mounts ZFS
mountpoints, swaps on a ZFS zdev.


I think Chris is referring to the fact that you have to be there when 
the encrypted system is restarted, to type the decryption key/password. 
The dilemma is this: if the decryption is automatic, it doesn't really 
protect the data at rest, because the boot process is not secured like 
it is on Android or IOS, and therefore the intruders could get in and 
access the now-unencrypted disk.


It is conceivable  to set up some sort of location-based decryption, 
where you would not have to give the password if the system is on a 
known network, authenticating through a trusted interface to a known 
host, but it's not a solved problem.

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

Re: js-jquery - Re: List of long term FTBFS packages to be retired in February (beta)

2019-12-03 Thread Sérgio Basto

On Tue, 2019-12-03 at 08:18 +, Tom Hughes wrote:
> Ben Rosser was working on sorting out grunt. In fact I believe he
> took the first of those at least.

OK then I taking nodejs-load-grunt-tasks [1]

[1]
https://pagure.io/releng/issue/9077

> Tom
> 
> On 03/12/2019 07:45, Vít Ondruch wrote:
> > According to [1], these are the packages which need to be preserved
> > to
> > keep js-jquery around:
> > 
> > 
> > nodejs-grunt-legacy-util
> > 
> > nodejs-load-grunt-tasks
> > 
> > nodejs-raw-body
> > 
> > 
> > Vít
> > 
> > 
> > [1] https://churchyard.fedorapeople.org/orphans-2019-12-02.txt
> > 
> > 
> > Dne 03. 12. 19 v 2:24 Sérgio Basto napsal(a):
> > > I will take nodejs-dateformat .
> > > Do you have a list of what more packages we have to keep?
> > > 
> > > 
> > > On Mon, 2019-12-02 at 15:52 +0100, Raphael Groner wrote:
> > > > Thanks a lot.
> > > > 
> > > > Am 02.12.19 um 15:20 schrieb Tom Hughes:
> > > > …
> > > > > As I explained the other day js-jquery was dependent on a
> > > > > nodejs module (a normal one, not modularised) which was
> > > > > failing to build and which I have now fixed.
> > > > …
> > > > ___
> > > > devel mailing list -- devel@lists.fedoraproject.org
> > > > To unsubscribe send an email to 
> > > > devel-le...@lists.fedoraproject.org
> > > > Fedora Code of Conduct:
> > > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > List Guidelines:
> > > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > List Archives:
> > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: 
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > 
> 
> -- 
> Tom Hughes (t...@compton.nu)
> http://compton.nu/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: "python3" vs "python%{python3_pkgversion}"

2019-12-03 Thread Kevin Fenzi

On Mon, Dec 02, 2019 at 07:10:48PM -0500, Neal Gompa wrote:
> 
> We should probably consider rebuilding all the Python 3 packages in
> EPEL7 no matter what so that the python3.6dist() Provides get
> generated, though. The dependency generator was backported to EL7 and
> is used with the Python 3 stack. It just isn't very useful yet because
> not all the packages were rebuilt after python3 was introduced in RHEL
> 7. Though why the --majorver-provides switch was removed from the
> attr, I don't know.
> 
> After that, we can backport the %python_enable_dependency_generator
> macro to EPEL7...

Yeah, this would be good to do.

Is anyone willing to drive this? :) 

kevin


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

[Test-Announce] Fedora 32 Rawhide 20191203.n.1 nightly compose nominated for testing

2019-12-03 Thread rawhide

Announcing the creation of a new nightly release validation test event
for Fedora 32 Rawhide 20191203.n.1. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
pungi - 20191129.n.0: pungi-4.1.40-4.fc32.src, 20191203.n.1: 
pungi-4.1.41-1.fc32.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/32

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191203.n.1_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191203.n.1_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191203.n.1_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191203.n.1_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191203.n.1_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191203.n.1_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191203.n.1_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-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/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1779326] EPEL 8 build of perl-switch?

2019-12-03 Thread bugzilla

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

Tom "spot" Callaway  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |NOTABUG
   Doc Type|--- |If docs needed, set a value
Last Closed||2019-12-03 19:25:57



--- Comment #1 from Tom "spot" Callaway  ---
I'm 99% sure this is still in RHEL 8:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/package_manifest/index

-- 
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 1779252] perltidy-20191203 is available

2019-12-03 Thread bugzilla

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perltidy-20191203-1.fc32
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2019-12-03 18:59:27



--- Comment #2 from Paul Howarth  ---
Build done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=39424402

-- 
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: js-jquery - Re: List of long term FTBFS packages to be retired in February (beta)

2019-12-03 Thread Jared K. Smith

I have taken nodejs-raw-body and am pushing an updated version to rawhide
now.

-Jared

On Tue, Dec 3, 2019 at 2:53 AM Vít Ondruch  wrote:

> According to [1], these are the packages which need to be preserved to
> keep js-jquery around:
>
>
> nodejs-grunt-legacy-util
>
> nodejs-load-grunt-tasks
>
> nodejs-raw-body
>
>
> Vít
>
>
> [1] https://churchyard.fedorapeople.org/orphans-2019-12-02.txt
>
>
> Dne 03. 12. 19 v 2:24 Sérgio Basto napsal(a):
> > I will take nodejs-dateformat .
> > Do you have a list of what more packages we have to keep?
> >
> >
> > On Mon, 2019-12-02 at 15:52 +0100, Raphael Groner wrote:
> >> Thanks a lot.
> >>
> >> Am 02.12.19 um 15:20 schrieb Tom Hughes:
> >> …
> >>> As I explained the other day js-jquery was dependent on a
> >>> nodejs module (a normal one, not modularised) which was
> >>> failing to build and which I have now fixed.
> >> …
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >> Fedora Code of Conduct:
> >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines:
> >> https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives:
> >>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1779326] New: EPEL 8 build of perl-switch?

2019-12-03 Thread bugzilla

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

Bug ID: 1779326
   Summary: EPEL 8 build of perl-switch?
   Product: Fedora
   Version: 31
  Hardware: All
OS: Linux
Status: NEW
 Component: perl-Switch
  Severity: low
  Assignee: tcall...@redhat.com
  Reporter: erinn.looneytri...@gmail.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
tcall...@redhat.com
  Target Milestone: ---
Classification: Fedora



It appears RH has dropped the perl-Switch package from RHEL, any chance you
folks could package it for EPEL 8?

Thanks,
-Erinn

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

Help with rubygem packaging

2019-12-03 Thread Leigh Scott

Hi,

Can someone  check these specfiles before I submit review requests please?
I have zero experience with packaging rubygem packaes.

https://leigh123linux.fedorapeople.org/pub/SPECS/rubygem-hrx.spec
https://leigh123linux.fedorapeople.org/pub/SPECS/rubygem-linked-list.spec

Best regards
Leigh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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] [Fedocal] Reminder meeting : EPEL Steering Co

2019-12-03 Thread smooge

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Co on 2019-12-04 from 18:00:00 to 19:00:00 GMT
   At freenode@fedora-meeting

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting. A general agenda is the 
following:

#meetingname EPEL
#topic Intros
#topic Old Business
#topic EPEL-6
#topic EPEL-7
#topic EPEL-8
#topic Openfloor
#endmeeting




Source: https://apps.fedoraproject.org/calendar/meeting/9364/

___
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: copr builders moved to F31, with more builders

2019-12-03 Thread Pavel Raiskup

On Monday, December 2, 2019 8:28:46 AM CET Pavel Raiskup wrote:
> With a great help of fedora infra (Kevin) we were able to add a new set of
> builders for x86_64 architecture, so the build queue processing should be
> faster now.  Also, the new machines should be a bit faster (while we still
> keep the old machines), so please be prepared that the x86_64 builder set
> is not that homogeneous as before.  There's currently no way to pick VM
> from one or another set.

I also added a few more aarch64 builders now, so .. the same warning
applies to that architecture.

Pavel


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

2019-12-03 Thread Miro Hrončok


On 03. 12. 19 18:16, Richard Shaw wrote:
On Tue, Dec 3, 2019 at 10:22 AM Miro Hrončok > wrote:


On 03. 12. 19 17:04, Richard Shaw wrote:

 > Technically Qt5/PySide2 doesn't support Python 3.8 (even though it
builds) and
 > don't plan to until the release of 5.14.
At the same time, technically, Fedora 32 is not yet released.


Which is why I haven't worried about it (as long as it builds), but the 
requirement that Fedora Rawhide package NEVR > N-1 could be an issue if the 
builds start to fail and we end up waiting on a future release for a fix.


Rawhide is allowed to lag temporaril

https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_rawhide_is_allowed_to_lag_temporarily

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

Re: Fedora 33 System-Wide Change proposal: Python 3.9

2019-12-03 Thread Richard Shaw

On Tue, Dec 3, 2019 at 10:22 AM Miro Hrončok  wrote:

> On 03. 12. 19 17:04, Richard Shaw wrote:
>
> > Technically Qt5/PySide2 doesn't support Python 3.8 (even though it
> builds) and
> > don't plan to until the release of 5.14.
> At the same time, technically, Fedora 32 is not yet released.
>

Which is why I haven't worried about it (as long as it builds), but the
requirement that Fedora Rawhide package NEVR > N-1 could be an issue if the
builds start to fail and we end up waiting on a future release for a fix.

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: Looking for a co-maintainer for timew: will sponsor + mentor

2019-12-03 Thread Ankur Sinha

On Tue, Dec 03, 2019 16:50:12 +0100, Igor Gnatenko wrote:
> Hey,
> 
> Add me as maintainer. I maintain taskwarrior which is very related :)

Thanks---added you as co-maintainer now. I see taskwarrior has enough
maintainers, but I use taskwarrior + timewarrior every day, so I can
help with taskwarrior if needed too :)

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


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

Re: Looking for a co-maintainer for timew: will sponsor + mentor

2019-12-03 Thread Ankur Sinha

On Tue, Dec 03, 2019 21:03:41 +0530, Aniket Pradhan wrote:
> Hello Ankur!
> 
> timewarrior seems like an interesting tool, and would love to co-maintain it.

Awesome---added you as co-maintainer. Let's discuss how to go about
updating it etc. on IRC sometime.

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


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

Logs from Open/Public NeuroFedora team meeting: 1600 UTC on Tuesday, 3rd December

2019-12-03 Thread Ankur Sinha

Hello,

Please find the logs of the meeting below. Links to meetbot pages:

- logs (HTML): 
https://meetbot.fedoraproject.org/fedora-neuro/2019-12-03/neurofedora.2019-12-03-16.00.log.html
- minutes (HTML): 
https://meetbot.fedoraproject.org/fedora-neuro/2019-12-03/neurofedora.2019-12-03-16.00.html

The next meeting will be next Tuesday.

===
#fedora-neuro: NeuroFedora - 2019-12-03
===

Meeting started by FranciscoD at 16:00:22 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-neuro/2019-12-03/neurofedora.2019-12-03-16.00.log.html
 .

Meeting summary
---
* Agenda for today's meeting  (FranciscoD, 16:01:04)
  * Introductions and roll call  (FranciscoD, 16:01:13)
  * Tasks from last meeting:

https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2019-11-12-15.59.html
(FranciscoD, 16:01:24)
  * Pagure tickets:

https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting
(FranciscoD, 16:01:34)
  * Bugs: https://tinyurl.com/neurofedora-bugs  (FranciscoD, 16:01:44)
  * Neuroscience of the week:
https://pagure.io/neuro-sig/NeuroFedora/issue/318  (FranciscoD,
16:01:55)
  * Next meeting chair, time  (FranciscoD, 16:02:00)
  * Open floor  (FranciscoD, 16:02:04)

* Introductions and roll call  (FranciscoD, 16:02:13)
  * ankursinha, FranciscoD, BST(UTC+0), packager, join, neurofedora,
etc.  (FranciscoD, 16:02:34)
  * major, IST(GMT+5.5), packager, neurofedora, lots more  (FranciscoD,
16:03:16)

* Tasks from last meeting:
  
https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2019-11-12-15.59.html
  (FranciscoD, 16:05:59)
  * major work on python-fsl* updates: DONE  (FranciscoD, 16:06:22)
  * major update and send out FOSDEM abstract: DONE + SUBMITTED
(FranciscoD, 16:06:38)
  * bt0 will work on
https://bugzilla.redhat.com/show_bug.cgi?id=1768267 (update
fastavro): PENDING, but major has taken over the bug so WIP
(FranciscoD, 16:07:18)
  * ACTION: major work on fastavro:
https://bugzilla.redhat.com/show_bug.cgi?id=1768267  (FranciscoD,
16:08:13)
  * Pagure tickets marked "next meeting":

https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting
(FranciscoD, 16:09:01)

* Issue #250: Figure out badges rule to award badge automatically to
  pagure group members - NeuroFedora - Pagure.io  (FranciscoD, 16:09:55)
  * https://pagure.io/neuro-sig/NeuroFedora/issue/250  (FranciscoD,
16:10:05)
  * FranciscoD pinged https://pagure.io/fedora-badges/issue/678 again
(FranciscoD, 16:11:22)

* Issue #301: NeuroFedora brochure - NeuroFedora - Pagure.io
  (FranciscoD, 16:11:48)
  * https://pagure.io/neuro-sig/NeuroFedora/issue/301  (FranciscoD,
16:11:56)
  * Requested the design team for review here:
https://pagure.io/design/issue/661 : no responses received there yet
(FranciscoD, 16:12:20)
  * ACTION: FranciscoD tag
https://pagure.io/neuro-sig/NeuroFedora/issue/301 as "future
meeting"  (FranciscoD, 16:12:52)
  * ACTION: FranciscoD tag
https://pagure.io/neuro-sig/NeuroFedora/issue/250 as "future
meeting"  (FranciscoD, 16:13:17)

* Issue #307: NeuroFedora at FOSDEM 2020. - NeuroFedora - Pagure.io
  (FranciscoD, 16:13:27)
  * https://pagure.io/neuro-sig/NeuroFedora/issue/307  (FranciscoD,
16:13:31)
  * major 's funding request for FOSDEM:
https://pagure.io/mindshare/issue/166#comment-614164  (FranciscoD,
16:20:47)
  * ACTION: major privately e-mail FranciscoD their mailing address
(FranciscoD, 16:21:30)
  * ACTION: FranciscoD carry NeuroFedora stickers to India and send them
to major  (FranciscoD, 16:21:52)
  * major submitted NeuroFedora abstract to FOSDEM: waiting on decision
(FranciscoD, 16:23:24)
  * ACTION: FranciscoD  update ticket with these details  (FranciscoD,
16:23:37)

* Issue #323: New neurofed...@lists.fp.o mailing list for discussions
  only? - NeuroFedora - Pagure.io  (FranciscoD, 16:23:58)
  * https://pagure.io/neuro-sig/NeuroFedora/issue/323  (FranciscoD,
16:24:05)
  * ACTION: FranciscoD follow up witn infra about new ML  (FranciscoD,
16:24:49)

* Bugs: https://tinyurl.com/neurofedora-bugs  (FranciscoD, 16:25:25)
  * No extremely urgent bugs  (FranciscoD, 16:27:45)

* Neuroscience of the week:
  https://pagure.io/neuro-sig/NeuroFedora/issue/318  (FranciscoD,
  16:28:16)
  * major suggested How Does the Brain Work With Half of it Removed?
Pretty Well, Actually | Discover Magazine -

https://www.discovermagazine.com/mind/how-does-the-brain-work-with-half-of-it-removed-pretty-well-actually
(FranciscoD, 16:28:39)

* Next meeting: time and chair  (FranciscoD, 16:32:32)
  * major will chair next meeting: same time on Tuesday  (FranciscoD,
16:33:56)
  * ACTION: major send out reminder on Monday  (FranciscoD, 16:34:05)

* Open Floor  (FranciscoD, 16:34:31)

Meeting ended at 16:43:27 UTC.




Action Items

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-03 Thread Michael Catanzaro

On Tue, Dec 3, 2019 at 9:07 am, Lennart Poettering 
 wrote:

Also note that on Fedora Workstation we default to suspend-on-idle
these days. i.e. when you don't actually work on the laptop the laptop
is suspended and not reachable via SSH at all, hence adding
systemd-homed doesn't make anything worse in that regard...


Hi,

A clarification. This is true upstream, but in Fedora it is only true 
for laptops on battery power. Desktops and laptops that are plugged in 
do not suspend on idle (unless you have changed the settings from our 
defaults).


It would be unusual to SSH into a laptop on battery power unless you 
are physically present in the room (since it could run out of power).


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

Re: Fedora 33 System-Wide Change proposal: Python 3.9

2019-12-03 Thread Miro Hrončok


On 03. 12. 19 17:04, Richard Shaw wrote:

It doesn't look like there are too many API breakages


Yet :(

but my only concern is 
that some of the upstreams for packages I maintain haven't caught up with 3.8 yet.


That is a problem we will be fighting constantly. We expect Fedora to drive 
upstream support of new Python versions.


Technically Qt5/PySide2 doesn't support Python 3.8 (even though it builds) and 
don't plan to until the release of 5.14.

At the same time, technically, Fedora 32 is not yet released.

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

[389-devel] please review: PR 50760 - Enable CLI arg completion

2019-12-03 Thread Mark Reynolds


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

--

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

Re: Potential module for wxGTK3.1 unstable series / Audacity

2019-12-03 Thread Matt Domsch

CubicSDR (Ham Radio panadapter spectrum visualizer using inexpensive
receivers) upstream moved to wxWidgets 3.1 over 18 months ago.  While I had
some success in backing out some specific changes that let it compile with
wxGTK 3.0, upstream has moved on considerably since then, making extensive
use of wxGLAttributes in various calls, which is far harder to back out.
Furthermore, upstream won't look at issues on older releases. [1]   Lending
some urgency are multiple abrt-reported segfaults, including on F30 and F31
[2].  Either a wxGTK 3.1 package in the main repos, or in copr, will be
needed to make this package usable again.


[1] https://github.com/cjcliffe/CubicSDR/issues/726
[2]
https://retrace.fedoraproject.org/faf/summary/?component_names=CubicSDR=2019-01-01%3A2019-12-03=m

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

2019-12-03 Thread Richard Shaw

It doesn't look like there are too many API breakages but my only concern
is that some of the upstreams for packages I maintain haven't caught up
with 3.8 yet.

Technically Qt5/PySide2 doesn't support Python 3.8 (even though it builds)
and don't plan to until the release of 5.14.

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: Looking for a co-maintainer for timew: will sponsor + mentor

2019-12-03 Thread Igor Gnatenko

Hey,

Add me as maintainer. I maintain taskwarrior which is very related :)

On Tue, Dec 3, 2019, 16:28 Ankur Sinha  wrote:

> Hello,
>
> I am looking for a co-maintainer to help maintain timew
> (timewarrior[1]). The package is not very complex. There is only one bug
> against timew at the moment:
>
> 1775965 – timew-1.2.0 is available:
> https://bugzilla.redhat.com/show_bug.cgi?id=1775965
>
> Since I'm focussing on Neuroscience tools, I'd like to be able to share
> the maintenance responsibilities for other general tools.
>
> I am also happy to sponsor and mentor if someone wants to join the
> packagers group[2]. I will help you gain/learn (among other skills)[3]:
>
> - a good understanding of the Free Software Philosophy.
> - a good understanding of the Fedora community's philosophy.
> - a good understanding of the Fedora community's code of conduct.
> - a good understanding of how source code is licensed.
> - a good understanding of the packaging guidelines.
> - a good understanding of the package review process.
> - a good understanding of the package maintainer policies.
> - a good understanding of how rpms are built.
>
> [1] https://timewarrior.net/
> [2]
> https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer
> [3] https://fedoraproject.org/wiki/User:Ankursinha/PackagerSponsor
>
> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) |
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 33 System-Wide Change proposal: Python 3.9

2019-12-03 Thread Ben Cotton

https://fedoraproject.org/wiki/Changes/Python3.9

Note that this is for Fedora *33*

== Summary ==
Update the Python stack in Fedora from Python 3.8 to Python 3.9.

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


== Detailed Description ==

We would like to upgrade Python to 3.9 in Fedora 33 thus we are proposing
this plan early.

See the upstream notes at [
https://www.python.org/dev/peps/pep-0596/#features-for-3-9 Features for
3.9] and [https://docs.python.org/3.9/whatsnew/3.9.html What's new in 3.9].

=== Important dates and plan ===

* 2019-06-04: Python 3.9 development begins
* 2019-11-19: Python 3.9.0 alpha 1
** Package it as {{package|python39}} for testing purposes
** Start the bootstrap procedure in Copr
** Do a mass rebuild against every future release in Copr
* 2019-12-16: Python 3.9.0 alpha 2
* 2020-01-13: Python 3.9.0 alpha 3
* 2020-02-11: Branch Fedora 32, Rawhide becomes future Fedora 33
** The earliest point when we can start rebuilding in Koji side-tag
* 2020-02-17: Python 3.9.0 alpha 4
* 2020-03-16: Python 3.9.0 alpha 5
* 2020-04-13: Python 3.9.0 alpha 6
* 2020-05-18: Python 3.9.0 beta 1
** No new features beyond this point
** The ideal point when we can start rebuilding in Koji
* 2020-05-30: Expected side tag-merge (optimistic)
* 2020-06-08: Python 3.9.0 beta 2
* 2020-05-18: Expected side tag-merge (realistic)
* 2020-06-29: Python 3.9.0 beta 3
* 2020-07-18: Expected side tag-merge (pessimistic)
* 2020-07-20: Python 3.9.0 beta 4
* 2020-07-22: Fedora 33 Mass Rebuild
** The mass rebuild happens with fourth beta. We might need to rebuild
Python packages later in exceptional case.
** If the Koji side-tag is not merged yet at this point, we defer the
change to Fedora 34.
* 2020-08-10: Python 3.9.0 candidate 1
** This serves as "final" for our purposes.
* 2020-08-11: Branch Fedora 33, Rawhide becomes future Fedora 34
* 2020-08-11: Fedora 33 Change Checkpoint: Completion deadline (testable)
* 2020-08-25: Fedora Beta Freeze
** If rebuild with 3.9.0rc1 is needed, we should strive to do it before the
freeze - there is a window of 2 weeks.
* 2020-09-14: Python 3.9.0 candidate 2
* 2020-09-15: Fedora 33 Beta Release (Preferred Target)
** Beta will likely be released with 3.9.0rc1.
* 2020-09-22: Fedora 33 Beta Target date #1
* 2020-10-05: Python 3.9.0 final
* 2020-10-06: Fedora 33 Final Freeze
** We'll update to 3.9.0 final using a freeze exception.
* 2020-10-20: Fedora 33 Preferred Final Target date
* 2020-10-27: Fedora 33 Final Target date #1


(From [https://www.python.org/dev/peps/pep-0596/#schedule Python 3.9
Release Schedule] and [
https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html Fedora 33
Release Schedule].)

The schedule is somewhat tight for Fedora 33, but Python's [
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/AKA3USBKFYKUQDSGDK4FNDYYWMKM7XKX/
annual release cycle was adapted for Fedora], hence we have a better chance
of making it in time. In the future, it is expected that Python will be
upgraded on a similar schedule in every odd-numbered Fedora release.

Note that upstream's "release candidates" are frozen except for blocker
bugs. Since we can and will backport blocker fixes between Fedora and
upstream, we essentially treat the Release Candidate as the final release.

=== Notes from the previous upgrade ===

There are notes from the previous upgrade available, so this upgrade may go
smoother: [[SIGs/Python/UpgradingPython]]

== Benefit to Fedora ==
Fedora aims to showcase the latest in free and open source software - we
should have the most recent release of Python 3. Packages in Fedora can use
the new features from 3.9.

There's also a benefit to the larger Python ecosystem: by building Fedora's
packages against 3.9 while it's still in development, we can catch critical
bugs before the final 3.9.0 release.

== Scope ==

We will coordinate the work in a side tag and merge when ready.

* Proposal owners:
*# Introduce {{package|python39}} for all Fedoras
*# Prepare stuff in Copr as explained in description.
*# Retire {{package|python39}} from F32+
*# Update  {{package|python3}} to what was in {{package|python39}}
*#* Mass rebuild all the packages that BR
{{package|python3}}/{{package|python3-devel}}/... (3000+ listed in [
http://fedora.portingdb.xyz/ Python 3 Porting Database for Fedora])
*# Reintroduce {{package|python38}} from Fedora 31. Update it to have all
fixes and enhancements from {{package|python3}} in Fedora 32 (or 33 before
this change)

* Other developers: Maintainers of packages that fail to rebuild during the
rebuilds will be asked, using e-mail and bugzilla, to fix or remove their
packages from the distribution. If any issues appear, they should be
solvable either by communicating with the respective upstreams first and/or
applying downstream patches. Also the package maintainers should have a
look at: [
https://docs.python.org/3.9/whatsnew/3.9.html#porting-to-python-3-9 Porting
to

Fedora 33 System-Wide Change proposal: Python 3.9

2019-12-03 Thread Ben Cotton

https://fedoraproject.org/wiki/Changes/Python3.9

Note that this is for Fedora *33*

== Summary ==
Update the Python stack in Fedora from Python 3.8 to Python 3.9.

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


== Detailed Description ==

We would like to upgrade Python to 3.9 in Fedora 33 thus we are proposing
this plan early.

See the upstream notes at [
https://www.python.org/dev/peps/pep-0596/#features-for-3-9 Features for
3.9] and [https://docs.python.org/3.9/whatsnew/3.9.html What's new in 3.9].

=== Important dates and plan ===

* 2019-06-04: Python 3.9 development begins
* 2019-11-19: Python 3.9.0 alpha 1
** Package it as {{package|python39}} for testing purposes
** Start the bootstrap procedure in Copr
** Do a mass rebuild against every future release in Copr
* 2019-12-16: Python 3.9.0 alpha 2
* 2020-01-13: Python 3.9.0 alpha 3
* 2020-02-11: Branch Fedora 32, Rawhide becomes future Fedora 33
** The earliest point when we can start rebuilding in Koji side-tag
* 2020-02-17: Python 3.9.0 alpha 4
* 2020-03-16: Python 3.9.0 alpha 5
* 2020-04-13: Python 3.9.0 alpha 6
* 2020-05-18: Python 3.9.0 beta 1
** No new features beyond this point
** The ideal point when we can start rebuilding in Koji
* 2020-05-30: Expected side tag-merge (optimistic)
* 2020-06-08: Python 3.9.0 beta 2
* 2020-05-18: Expected side tag-merge (realistic)
* 2020-06-29: Python 3.9.0 beta 3
* 2020-07-18: Expected side tag-merge (pessimistic)
* 2020-07-20: Python 3.9.0 beta 4
* 2020-07-22: Fedora 33 Mass Rebuild
** The mass rebuild happens with fourth beta. We might need to rebuild
Python packages later in exceptional case.
** If the Koji side-tag is not merged yet at this point, we defer the
change to Fedora 34.
* 2020-08-10: Python 3.9.0 candidate 1
** This serves as "final" for our purposes.
* 2020-08-11: Branch Fedora 33, Rawhide becomes future Fedora 34
* 2020-08-11: Fedora 33 Change Checkpoint: Completion deadline (testable)
* 2020-08-25: Fedora Beta Freeze
** If rebuild with 3.9.0rc1 is needed, we should strive to do it before the
freeze - there is a window of 2 weeks.
* 2020-09-14: Python 3.9.0 candidate 2
* 2020-09-15: Fedora 33 Beta Release (Preferred Target)
** Beta will likely be released with 3.9.0rc1.
* 2020-09-22: Fedora 33 Beta Target date #1
* 2020-10-05: Python 3.9.0 final
* 2020-10-06: Fedora 33 Final Freeze
** We'll update to 3.9.0 final using a freeze exception.
* 2020-10-20: Fedora 33 Preferred Final Target date
* 2020-10-27: Fedora 33 Final Target date #1


(From [https://www.python.org/dev/peps/pep-0596/#schedule Python 3.9
Release Schedule] and [
https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html Fedora 33
Release Schedule].)

The schedule is somewhat tight for Fedora 33, but Python's [
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AKA3USBKFYKUQDSGDK4FNDYYWMKM7XKX/
annual release cycle was adapted for Fedora], hence we have a better chance
of making it in time. In the future, it is expected that Python will be
upgraded on a similar schedule in every odd-numbered Fedora release.

Note that upstream's "release candidates" are frozen except for blocker
bugs. Since we can and will backport blocker fixes between Fedora and
upstream, we essentially treat the Release Candidate as the final release.

=== Notes from the previous upgrade ===

There are notes from the previous upgrade available, so this upgrade may go
smoother: [[SIGs/Python/UpgradingPython]]

== Benefit to Fedora ==
Fedora aims to showcase the latest in free and open source software - we
should have the most recent release of Python 3. Packages in Fedora can use
the new features from 3.9.

There's also a benefit to the larger Python ecosystem: by building Fedora's
packages against 3.9 while it's still in development, we can catch critical
bugs before the final 3.9.0 release.

== Scope ==

We will coordinate the work in a side tag and merge when ready.

* Proposal owners:
*# Introduce {{package|python39}} for all Fedoras
*# Prepare stuff in Copr as explained in description.
*# Retire {{package|python39}} from F32+
*# Update  {{package|python3}} to what was in {{package|python39}}
*#* Mass rebuild all the packages that BR
{{package|python3}}/{{package|python3-devel}}/... (3000+ listed in [
http://fedora.portingdb.xyz/ Python 3 Porting Database for Fedora])
*# Reintroduce {{package|python38}} from Fedora 31. Update it to have all
fixes and enhancements from {{package|python3}} in Fedora 32 (or 33 before
this change)

* Other developers: Maintainers of packages that fail to rebuild during the
rebuilds will be asked, using e-mail and bugzilla, to fix or remove their
packages from the distribution. If any issues appear, they should be
solvable either by communicating with the respective upstreams first and/or
applying downstream patches. Also the package maintainers should have a
look at: [
https://docs.python.org/3.9/whatsnew/3.9.html#porting-to-python-3-9 Porting
to

Re: Looking for a co-maintainer for timew: will sponsor + mentor

2019-12-03 Thread Aniket Pradhan

Hello Ankur!

timewarrior seems like an interesting tool, and would love to co-maintain
it.



On Tue, 3 Dec, 2019, 8:53 pm Ankur Sinha,  wrote:

> Hello,
>
> I am looking for a co-maintainer to help maintain timew
> (timewarrior[1]). The package is not very complex. There is only one bug
> against timew at the moment:
>
> 1775965 – timew-1.2.0 is available:
> https://bugzilla.redhat.com/show_bug.cgi?id=1775965
>
> Since I'm focussing on Neuroscience tools, I'd like to be able to share
> the maintenance responsibilities for other general tools.
>
> I am also happy to sponsor and mentor if someone wants to join the
> packagers group[2]. I will help you gain/learn (among other skills)[3]:
>
> - a good understanding of the Free Software Philosophy.
> - a good understanding of the Fedora community's philosophy.
> - a good understanding of the Fedora community's code of conduct.
> - a good understanding of how source code is licensed.
> - a good understanding of the packaging guidelines.
> - a good understanding of the package review process.
> - a good understanding of the package maintainer policies.
> - a good understanding of how rpms are built.
>
> [1] https://timewarrior.net/
> [2]
> https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer
> [3] https://fedoraproject.org/wiki/User:Ankursinha/PackagerSponsor
>
> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) |
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Looking for a co-maintainer for timew: will sponsor + mentor

2019-12-03 Thread Ankur Sinha

Hello,

I am looking for a co-maintainer to help maintain timew
(timewarrior[1]). The package is not very complex. There is only one bug
against timew at the moment:

1775965 – timew-1.2.0 is available: 
https://bugzilla.redhat.com/show_bug.cgi?id=1775965

Since I'm focussing on Neuroscience tools, I'd like to be able to share
the maintenance responsibilities for other general tools.

I am also happy to sponsor and mentor if someone wants to join the
packagers group[2]. I will help you gain/learn (among other skills)[3]:

- a good understanding of the Free Software Philosophy.
- a good understanding of the Fedora community's philosophy.
- a good understanding of the Fedora community's code of conduct.
- a good understanding of how source code is licensed.
- a good understanding of the packaging guidelines.
- a good understanding of the package review process.
- a good understanding of the package maintainer policies.
- a good understanding of how rpms are built.

[1] https://timewarrior.net/
[2] 
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer
[3] https://fedoraproject.org/wiki/User:Ankursinha/PackagerSponsor

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


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

[Bug 1779252] New: perltidy-20191203 is available

2019-12-03 Thread bugzilla

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

Bug ID: 1779252
   Summary: perltidy-20191203 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perltidy
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: lxt...@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 20191203
Current version/release in rawhide: 20190915-1.fc32
URL: http://search.cpan.org/dist/Perl-Tidy/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/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/3553/

-- 
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 1779252] perltidy-20191203 is available

2019-12-03 Thread bugzilla

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



--- Comment #1 from Upstream Release Monitoring 
 ---
An HTTP error occurred downloading the package's new Source URLs: Getting
https://cpan.metacpan.org/modules/by-module/Perl/Perl-Tidy-20191203.tar.gz to
./Perl-Tidy-20191203.tar.gz

-- 
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: dist-git bugzilla sync script being fixed

2019-12-03 Thread Orion Poplawski


On 11/29/19 10:17 AM, Pierre-Yves Chibon wrote:

Good Morning Everyone™,

we have recently spent some time refactoring, improving and fixing the script
that syncs the default assignee and CC list from dist-git to Bugzilla.

Since the script was broken for some time, we felt that it needs some validation
before we run it live (which will still require some work).
We have uploaded the results at:
https://pingou.fedorapeople.org/distgit_bugzilla_sync.log
(Note that this only shows what would be updated.)

We'd appreciate it if you could take some time and check the changes affecting
you and report any issues you might find.
An easy way to do this is downloading the file and grepping for your FAS
username.


Thanks in advance for your help,
Pierre


I see a lot of entries like:

[EDITCOMP] Fedora/cfitsio  initialcclist changed from `['orion', 
'sergiopr', 'And 1 more']` to FAS name(s) `['mmahut', 'orion', 'sergiopr']`


I suspect you need to fix the bugzilla query to return the full 
initiallcclist to avoid the 'And X more' entry.


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



smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1779180] perl-DBD-Mock-1.53 is available

2019-12-03 Thread bugzilla

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-DBD-Mock-1.53-1.fc32
 Resolution|--- |RAWHIDE
Last Closed||2019-12-03 13:50:13



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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-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 1779180] perl-DBD-Mock-1.53 is available

2019-12-03 Thread bugzilla

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

Petr Pisar  changed:

   What|Removed |Added

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



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

[Bug 1779180] perl-DBD-Mock-1.53 is available

2019-12-03 Thread bugzilla

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



--- Comment #1 from Upstream Release Monitoring 
 ---
An HTTP error occurred downloading the package's new Source URLs: Getting
https://cpan.metacpan.org/modules/by-module/DBD/DBD-Mock-1.53.tar.gz to
./DBD-Mock-1.53.tar.gz

-- 
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 1779180] New: perl-DBD-Mock-1.53 is available

2019-12-03 Thread bugzilla

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

Bug ID: 1779180
   Summary: perl-DBD-Mock-1.53 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-DBD-Mock
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jan.pra...@gmail.com, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.53
Current version/release in rawhide: 1.52-1.fc32
URL: http://search.cpan.org/dist/DBD-Mock/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/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/2805/

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

Firefox crashes at Rawhide

2019-12-03 Thread Martin Stransky

Just FYI, Firefox is recently crashing on Rawhide due to two independent 
issues as rawhide gets all builds automatically:


1) PGO mis-compilation/Firefox bug 
(https://bugzilla.redhat.com/show_bug.cgi?id=1779082). Please use 'npgo' 
builds from koji.


2) glibc update (https://bugzilla.mozilla.org/show_bug.cgi?id=1600574#c8)
You can disable e10s as a workaround (set MOZ_FORCE_DISABLE_E10S=1 or 
browser.tabs.remote.autostart at about:config)


--
Martin Stransky
Software Engineer / Red Hat, Inc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1779106] perl-Coro-Multicore-1.04 is available

2019-12-03 Thread bugzilla

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Coro-Multicore-1.04-1.
   ||fc32
 Resolution|--- |RAWHIDE
Last Closed||2019-12-03 12:18:18



--- Comment #3 from Petr Pisar  ---
This release postpone initializing AnyEvent in order to unbreak loading
Coro::MultiCore before a fork. This should fix some issues, but it breaks an
expectation when AnyEvent is available. Therefore I will push it only into
Rawhide.

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

[Bug 1779067] perl-Test-Simple-1.302170 is available

2019-12-03 Thread bugzilla

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

Paul Howarth  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-Test-Simple-1.302170-1
   ||.fc32
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2019-12-03 11:29:23



-- 
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 1779106] perl-Coro-Multicore-1.04 is available

2019-12-03 Thread bugzilla

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

Petr Pisar  changed:

   What|Removed |Added

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



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

Re: RFC: Branch requests from non-maintainers

2019-12-03 Thread Pierre-Yves Chibon

On Tue, Dec 03, 2019 at 11:27:33AM +0100, Fabio Valentini wrote:
>On Tue, Dec 3, 2019, 10:42 Pierre-Yves Chibon <[1]pin...@pingoured.fr>
>wrote:
> 
>  On Mon, Dec 02, 2019 at 11:25:13PM +0100, Fabio Valentini wrote:
>  >    On Mon, Dec 2, 2019, 22:44 Kevin Kofler
>  <[1][2]kevin.kof...@chello.at> wrote:
>  >
>  >      Igor Gnatenko wrote:
>  >      > * Should any other packager (not that maintainer) be able to
>  request
>  >      > new branches on that repo?
>  >      > * Should provenpackager be able to do the same request?
>  >
>  >      Since I do not give a darn about what happens to my packages on
>  EPEL, I
>  >      am
>  >      fine with anybody requesting EPEL branches for them as long as
>  they do
>  >      the
>  >      work and don't expect me to do anything to those branches (which
>  is not
>  >      going to happen).
>  >
>  >    I think this might be a good time point out that it's actually
>  possible to
>  >    override the default assignee for a component for EPEL bugs (also
>  for
>  >    fedora) in bugzilla by adding this override in the
>  >    releng/fedora-scm-requests repo for the respective package, like
>  here:
>  >   
>  
> [2][3]https://pagure.io/releng/fedora-scm-requests/blob/master/f/rpms/jackson-databind
>  >    (Note that lef was actually deemed non-responsive some months back,
>  so
>  >    this is probably not a good example of a package where this split
>  >    responsibility "worked".)
> 
>  Just a note on that subject, we're actively working on getting ride of
>  this git
>  repo and move this back to dist-git as well :)
> 
>Hi Pierre,
>That's good to hear, the current workflow is a bit involved.
>Do you plan to store this data in a file in each dist-git branch, or in a
>file containing the whole information on a separate, non-buildable orphan
>(semantic overload here ...) git branch? I think the latter would have the
>benefit of not interfering with dist-git contents at all, while still
>being stored in the same repo.

The idea is to store this in the database on pagure, no git repo involved.


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

[Bug 1779106] perl-Coro-Multicore-1.04 is available

2019-12-03 Thread bugzilla

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Coro-Multicore-1.04-1.fc29.src.rpm for rawhide failed
http://koji.fedoraproject.org/koji/taskinfo?taskID=39421629

-- 
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: RFC: Branch requests from non-maintainers

2019-12-03 Thread Fabio Valentini

On Tue, Dec 3, 2019, 10:42 Pierre-Yves Chibon  wrote:

> On Mon, Dec 02, 2019 at 11:25:13PM +0100, Fabio Valentini wrote:
> >On Mon, Dec 2, 2019, 22:44 Kevin Kofler <[1]kevin.kof...@chello.at>
> wrote:
> >
> >  Igor Gnatenko wrote:
> >  > * Should any other packager (not that maintainer) be able to
> request
> >  > new branches on that repo?
> >  > * Should provenpackager be able to do the same request?
> >
> >  Since I do not give a darn about what happens to my packages on
> EPEL, I
> >  am
> >  fine with anybody requesting EPEL branches for them as long as they
> do
> >  the
> >  work and don't expect me to do anything to those branches (which is
> not
> >  going to happen).
> >
> >I think this might be a good time point out that it's actually
> possible to
> >override the default assignee for a component for EPEL bugs (also for
> >fedora) in bugzilla by adding this override in the
> >releng/fedora-scm-requests repo for the respective package, like here:
> >[2]
> https://pagure.io/releng/fedora-scm-requests/blob/master/f/rpms/jackson-databind
> >(Note that lef was actually deemed non-responsive some months back, so
> >this is probably not a good example of a package where this split
> >responsibility "worked".)
>
> Just a note on that subject, we're actively working on getting ride of
> this git
> repo and move this back to dist-git as well :)
>

Hi Pierre,

That's good to hear, the current workflow is a bit involved.

Do you plan to store this data in a file in each dist-git branch, or in a
file containing the whole information on a separate, non-buildable orphan
(semantic overload here ...) git branch? I think the latter would have the
benefit of not interfering with dist-git contents at all, while still being
stored in the same repo.

Fabio


> As for the issue discussed in this thread, this sounds like a fairly easy
> change
> to add to: https://pagure.io/fedscm-admin/.
> Could someone open a ticket there? (Do not allow non-maintainer to request
> a
> branch on a package)
> The workflow becoming: if you want an epel branch created, talk to the
> current
> maintainer, get them to give you commit on the package and then request the
> branch via fedpkg.
>
>
> Thanks,
> Pierre
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1779106] New: perl-Coro-Multicore-1.04 is available

2019-12-03 Thread bugzilla

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

Bug ID: 1779106
   Summary: perl-Coro-Multicore-1.04 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Coro-Multicore
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.04
Current version/release in rawhide: 1.03-3.fc31
URL: http://search.cpan.org/dist/Coro-Multicore/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/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/7655/

-- 
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 1779106] perl-Coro-Multicore-1.04 is available

2019-12-03 Thread bugzilla

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



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

-- 
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: RFC: Branch requests from non-maintainers

2019-12-03 Thread Miro Hrončok


On 03. 12. 19 10:41, Pierre-Yves Chibon wrote:

As for the issue discussed in this thread, this sounds like a fairly easy change
to add to: https://pagure.io/fedscm-admin/.
Could someone open a ticket there? (Do not allow non-maintainer to request a
branch on a package)


https://pagure.io/releng/issue/8844 is open and links to a fedscm-admin PR.

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

Re: Major rewrite of project

2019-12-03 Thread Petr Stodulka


As Fabio wrote, just I add that you can opene PR in pagure,
which is good way to show people the changes and get some
feedback (as well, creating copr build should be done too).

On 02. 12. 19 13:08, Tomas Korbar wrote:

Thanks for help Fabio.

On Mon, Dec 2, 2019 at 12:10 PM Fabio Valentini mailto:decatho...@gmail.com>> wrote:

On Mon, Dec 2, 2019, 11:45 Tomas Korbar mailto:tkor...@redhat.com>> wrote:

Hi,
I would like to ask you a question. If upstream of your package does 
major rewrite of it, then what is the proper process to rebase such package? 
I'm maintainer of cheat [0] which has been rewritten in go. I suppose i need a 
new package review but then if the new spec passes review am i supposed to 
replace the spec of old package entirely or preserve changelog and add new 
entry with description of what happened + link to the review?


Hi Tomas,

You don't need to go through package review again, since it's not a new 
package. So just update it to the new version, and keep the old changelog.

However, if you want feedback on the new packaging before pushing it to 
fedora, you could publish the .spec file and submit the new version to a COPR 
repo first, so users can look at it, test it, and give you comments. I do it 
like this for my packages when they have major changes.

It would be another matter if the new version is installable alongside the 
old version, then you could package both of them separately, but I guess that's 
not the case here.

Fabio

[0] - https://github.com/cheat/cheat
___
devel mailing list -- devel@lists.fedoraproject.org 

To unsubscribe send an email to devel-le...@lists.fedoraproject.org 

Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org 

To unsubscribe send an email to devel-le...@lists.fedoraproject.org 

Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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



--
Petr Stodulka
OS & Application Modernization
IRC nicks: pstodulk, skytak
Senior Software Engineer
Red Hat Czech s.r.o.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: dist-git bugzilla sync script being fixed

2019-12-03 Thread Pierre-Yves Chibon

On Mon, Dec 02, 2019 at 06:26:32PM -0500, Elliott Sales de Andrade wrote:
> On Mon, 2 Dec 2019 at 08:22, Pierre-Yves Chibon  wrote:
> >
> > Good Morning Everyone™,
> >
> > we have recently spent some time refactoring, improving and fixing the 
> > script
> > that syncs the default assignee and CC list from dist-git to Bugzilla.
> >
> > Since the script was broken for some time, we felt that it needs some 
> > validation
> > before we run it live (which will still require some work).
> > We have uploaded the results at:
> > https://pingou.fedorapeople.org/distgit_bugzilla_sync.log
> > (Note that this only shows what would be updated.)
> >
> > We'd appreciate it if you could take some time and check the changes 
> > affecting
> > you and report any issues you might find.
> > An easy way to do this is downloading the file and grepping for your FAS
> > username.
> 
> [EDITCOMP] Fedora/python-Fiona  initialowner changed  to FAS name(s) `orphan`
> [EDITCOMP] Fedora/python-Fiona  initialcclist changed from
> `['@python-sig', 'qulogic']` to FAS name(s) `['orphan']`
> 
> Need to double-check this, because python-Fiona is retired, and I'm
> not an owner of, or CC'd on, it. But I *am* an owner of python-fiona,
> which is not orphaned.

You are correct:
https://src.fedoraproject.org/rpms/python-Fiona is retired and thus will be
moved to orphan in bugzilla.
while: https://pagure.io/fedscm-admin/ is still active and according to the
script will not be touched:
[NOCHANGE] python-fiona/Fedora

And I've just double checked, both exists in bugzilla currently.


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

[Bug 1779067] perl-Test-Simple-1.302170 is available

2019-12-03 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



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

-- 
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: RFC: Branch requests from non-maintainers

2019-12-03 Thread Pierre-Yves Chibon

On Mon, Dec 02, 2019 at 11:25:13PM +0100, Fabio Valentini wrote:
>On Mon, Dec 2, 2019, 22:44 Kevin Kofler <[1]kevin.kof...@chello.at> wrote:
> 
>  Igor Gnatenko wrote:
>  > * Should any other packager (not that maintainer) be able to request
>  > new branches on that repo?
>  > * Should provenpackager be able to do the same request?
> 
>  Since I do not give a darn about what happens to my packages on EPEL, I
>  am
>  fine with anybody requesting EPEL branches for them as long as they do
>  the
>  work and don't expect me to do anything to those branches (which is not
>  going to happen).
> 
>I think this might be a good time point out that it's actually possible to
>override the default assignee for a component for EPEL bugs (also for
>fedora) in bugzilla by adding this override in the
>releng/fedora-scm-requests repo for the respective package, like here:
>
> [2]https://pagure.io/releng/fedora-scm-requests/blob/master/f/rpms/jackson-databind
>(Note that lef was actually deemed non-responsive some months back, so
>this is probably not a good example of a package where this split
>responsibility "worked".) 

Just a note on that subject, we're actively working on getting ride of this git
repo and move this back to dist-git as well :)

As for the issue discussed in this thread, this sounds like a fairly easy change
to add to: https://pagure.io/fedscm-admin/.
Could someone open a ticket there? (Do not allow non-maintainer to request a
branch on a package)
The workflow becoming: if you want an epel branch created, talk to the current
maintainer, get them to give you commit on the package and then request the
branch via fedpkg.


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

Re: Reproducible builds/bootstrap

2019-12-03 Thread Pablo Sebastián Greco



On 30/11/19 23:23, Kevin Fenzi wrote:

On Sat, Nov 30, 2019 at 02:20:42PM -0700, Chris Murphy wrote:

On Sat, Nov 30, 2019 at 12:46 PM Kevin Fenzi  wrote:

On Wed, Nov 27, 2019 at 02:43:48PM -0700, Chris Murphy wrote:

On Wed, Nov 27, 2019 at 12:18 PM Neal Gompa  wrote:

...snip...

I'd love to explore using Btrfs for doing it. I have no idea how to
get started with that...

Before Btrfs specific, I'd ask how much compression configurability is
needed in the compose system and where? That relates to plain squashfs
images as well as hypothetical Btrfs images. Is there any advantage to
having Rawhide use zstd:3 since these nightlies are throw away? These
would be much faster to create and use than xz or zstd:16, but the ISO
size would be a lot bigger, maybe 25% bigger. And then for branched
nightlies, RCs, and releases, use zstd:16 or even zstd:19? Could the
granularity be compress=low,medium,high? And that is then translated
by lmc or even the installer, into the specific level numbers? This is
in effect the question I'm posing here:
https://pagure.io/releng/issue/8581#comment-613760

I think we should just use the same everywhere, or we risk testing
something that is not actually what we ship.

I'm definitely advocating testing what will be shipped:
Test and ship zstd:3 for Rawhide
Test and ship zstd:16 for branched (nightlies, RC, release)

I'd casually estimate zstd:3 is 2x faster to create the image than
zstd:16 - but since the compose system is typically throwing something
like 32 cores at these tasks, it may not substantially reduce the
overall compose time.

Yeah, but then we aren't using Rawhide to test the thing that will go
into the next branched. So, say there's some zstd bug or a size issue or
something we don't catch in rawhide and then have to figure out months
later in branched. I'd really prefer we just use the same for both.

kevin
What I'm looking for mainly, as a first step, is to get reproducibility 
at binary level, not at rpm level (maybe after that).
Apart from that, the most important part is the bootstrap, because that 
would require regenerating Fedora, or at least a subset of key packages, 
like gcc, glibc, without using any of the current binaries.


I'll be conducting a few tests over the next weeks and reporting back, 
but if this is an interesting thing to tackle for Fedora as a whole, it 
would be good to know which would be the first steps.


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

Fedora-Cloud-31-20191203.0 compose check report

2019-12-03 Thread Fedora compose checker

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1778463] [RFE] EPEL-8 branch for perl-Data-Float

2019-12-03 Thread bugzilla

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



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2019-f1d32085d8 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f1d32085d8

-- 
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 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-03 Thread Lennart Poettering

On Di, 03.12.19 01:29, John M. Harris Jr (joh...@splentity.com) wrote:

> > The problem is that sshd's PAM implementation doesn't allow PAM
> > modules to ask questions in login sessions which are authenticated via
> > authorized_keys instead of PAM. Because if we could ask questions
> > then, we could simply ask the user for the passphrase to derive the
> > LUKS key from if we need. That would mean that if you SSH login if you
> > already are logged in locally, then logins would be instant, but if
> > you SSH login otherwise then you'd get a prompt for the pw first.
>
> Is the key's passphrase always going to be based on the user's password with
> systed-homed? Is there a mechanism to use a separate password?

In theory the infrastructure would allow that, but systemd-homed's
idea is really to unify authentication, and make disk encryption part
of the user account an implementation detail. Hence, in systemd-homed
you can have N passwords and M PKCS#11 tokens (i.e. yubikeys) and
these translate to N+M keyslots on the LUKS volume, so that any
supplied password or any supplied yubikey unlocks the whole stack.

(And N and M can individually be zero, but N+M must be > 0)

(And systemd-homed also supports ext4 encryption as backend, as well
as unencrypted backends, and authentication works the same there
except that the keys are never propagated to any storage backend
because the storage backend has no interest in cryptographic key
material)

Lennart

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

[Bug 1773105] perl-HTTP-Cookies-6.08 is available

2019-12-03 Thread bugzilla

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version|perl-HTTP-Cookies-6.07-1.fc |perl-HTTP-Cookies-6.08-1.fc
   |32  |32
 Resolution|--- |RAWHIDE
Last Closed||2019-12-03 08:35:39



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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-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 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-03 Thread John M. Harris Jr

On Tuesday, December 3, 2019 1:18:57 AM MST Lennart Poettering wrote:
> systemd-homed integrates with sshd's AuthorizedKeysCommand and
> supplies any SSH keys assoicated with the user account directly to SSH
> without anyone needing access ~/.ssh/. i.e. integration with SSH is
> actually already in place.

Excellent, that's what I mentioned in the other subthread. Does this use 
sssd's existing AuthorizedKeysCommand, or would it interfere with it?

> The problem is that sshd's PAM implementation doesn't allow PAM
> modules to ask questions in login sessions which are authenticated via
> authorized_keys instead of PAM. Because if we could ask questions
> then, we could simply ask the user for the passphrase to derive the
> LUKS key from if we need. That would mean that if you SSH login if you
> already are logged in locally, then logins would be instant, but if
> you SSH login otherwise then you'd get a prompt for the pw first.

Is the key's passphrase always going to be based on the user's password with 
systed-homed? Is there a mechanism to use a separate password?

-- 
John M. Harris, Jr.
Splentity

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1779067] perl-Test-Simple-1.302170 is available

2019-12-03 Thread bugzilla

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Test-Simple-1.302170-1.fc29.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=39419379

-- 
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 1779067] New: perl-Test-Simple-1.302170 is available

2019-12-03 Thread bugzilla

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

Bug ID: 1779067
   Summary: perl-Test-Simple-1.302170 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Test-Simple
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.302170
Current version/release in rawhide: 1.302169-1.fc32
URL: http://search.cpan.org/dist/Test-Simple/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/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/11977/

-- 
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 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-03 Thread Lennart Poettering

On Mo, 02.12.19 12:39, Chris Murphy (li...@colorremedies.com) wrote:

> Basically you have to choose between user home security (or more
> specifically privacy) and remote logins. However, there are some
> ideas that could possibly work around this, to varying degrees of
> inelegance, which I'll gratuitously copy from a related Workstation
> WG issue [1].
>
> 1. Enhance openssh's PAM support
> 2. Stub account to ssh into, whereby the user is prompted to
> authenticate+unlock the real account; and now ssh into the real
> account.
> 3. Same as 2 but maybe it's possible to bind mount the real home dir
> over the stub home dir, eliminating the 2nd login? (Vaguely recall
> reading about this somewhere, maybe Ubuntu's use of ecryptfs based
> home, now since deprecated in favor of LUKS)
> 4. If based on any fscrypt implementation, exclude ~/.ssh/ from
> encryption

systemd-homed integrates with sshd's AuthorizedKeysCommand and
supplies any SSH keys assoicated with the user account directly to SSH
without anyone needing access ~/.ssh/. i.e. integration with SSH is
actually already in place.

The problem is that sshd's PAM implementation doesn't allow PAM
modules to ask questions in login sessions which are authenticated via
authorized_keys instead of PAM. Because if we could ask questions
then, we could simply ask the user for the passphrase to derive the
LUKS key from if we need. That would mean that if you SSH login if you
already are logged in locally, then logins would be instant, but if
you SSH login otherwise then you'd get a prompt for the pw first.

Lennart

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

[Bug 1779067] perl-Test-Simple-1.302170 is available

2019-12-03 Thread bugzilla

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



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

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

Re: js-jquery - Re: List of long term FTBFS packages to be retired in February (beta)

2019-12-03 Thread Tom Hughes


Ben Rosser was working on sorting out grunt. In fact I believe he
took the first of those at least.

Tom

On 03/12/2019 07:45, Vít Ondruch wrote:

According to [1], these are the packages which need to be preserved to
keep js-jquery around:


nodejs-grunt-legacy-util

nodejs-load-grunt-tasks

nodejs-raw-body


Vít


[1] https://churchyard.fedorapeople.org/orphans-2019-12-02.txt


Dne 03. 12. 19 v 2:24 Sérgio Basto napsal(a):

I will take nodejs-dateformat .
Do you have a list of what more packages we have to keep?


On Mon, 2019-12-02 at 15:52 +0100, Raphael Groner wrote:

Thanks a lot.

Am 02.12.19 um 15:20 schrieb Tom Hughes:
…

As I explained the other day js-jquery was dependent on a
nodejs module (a normal one, not modularised) which was
failing to build and which I have now fixed.

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

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




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

[Bug 1779065] New: Upgrade perl-Config-Model to 2.137

2019-12-03 Thread bugzilla

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

Bug ID: 1779065
   Summary: Upgrade perl-Config-Model to 2.137
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Config-Model
  Assignee: david.hanneq...@gmail.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: david.hanneq...@gmail.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



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

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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-12-03 Thread Lennart Poettering

On Mo, 02.12.19 10:44, John M. Harris Jr (joh...@splentity.com) wrote:

> On Monday, December 2, 2019 9:48:05 AM MST Przemek Klosowski via devel wrote:
> > On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote:
> > >> Mabee systemd-homed is in
> > >> a position to solve this by having early enough authentication
> > >> capability by rescue.target time that any admin user can login?
> > >
> > > Actually, it may. Things are confusing here, because systemd-homed is
> > > implemented together with changes to how user metadata querying is done:
> > > instead of using dbus, a brokerless and much simpler varlink query is
> > > used.
> > > That last part is what would be relevant to early-boot logins, because
> > > less services need to be up to bring up the user session.
> >
> > There's one tricky feature of homed : remote login (ssh) is only
> > possible after an initial local login. It is OK for his intended use (a
> > personal laptop/tablet client), except for corner cases like a remotely
> > accessed personal desktop in the basement that might get rebooted e.g.
> > for updates, resulting in an accidental lockout.
>
> Basically, systemd-homed is useless for any power user, but might be useful
> for people just getting into GNU/Linux, who don't use ssh yet or don't have
> more than one system.

You can SSH into a systemd-homed account just fine, you just need to
unlock the home directory once first, for example by logging in
locally. The key to unlock the home directory needs to come from
somewhere, hence a PAM authentication has to take place once, so that
systemd-homed can derive the LUKS key once from the pw you
enter. However, if you never authenticated via PAM (but via ssh
authorized keys only) then there's no pw to unlock the volume with.

It's exactly the same as with LUKS encrypted traditional /home or root
btw, except that the unlocking is moved a bit later: i.e. things are
just much worse there, because you have to enter the pw at boot
already and thus your secrets are already unlocked when you haven't
even logged in.

Also note that on Fedora Workstation we default to suspend-on-idle
these days. i.e. when you don't actually work on the laptop the laptop
is suspended and not reachable via SSH at all, hence adding
systemd-homed doesn't make anything worse in that regard...

Lennart

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

91 matches

Mail list logo