Re: [Test-Announce] Fedora 26 Candidate Beta-1.4 Available Now!

[Christian Dersch]

What is "an older i686-netbook"?

On 06/01/2017 08:21 AM, Ralf Corsepius wrote:

On 06/01/2017 06:28 AM, rawh...@fedoraproject.org wrote:

According to the schedule [1], Fedora 26 Candidate Beta-1.4 is now
available for testing.


Trying Fedora-Workstation-netinst-i386-26_Beta-1.4.iso on an older 
i686-netbook fails with this:

...
[Failed] Failed to start Switch Root
See 'systemctl status initrd-switch-root.service' for details
...
Entering emergency mode
...

In "emergency mode":
# systemctl status initrd-switch-root.service
Failed to map properties: Bad message

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

Re: [Test-Announce] Fedora 26 Candidate Beta-1.4 Available Now!

[Ralf Corsepius]

On 06/01/2017 06:28 AM, rawh...@fedoraproject.org wrote:

According to the schedule [1], Fedora 26 Candidate Beta-1.4 is now
available for testing.


Trying Fedora-Workstation-netinst-i386-26_Beta-1.4.iso on an older 
i686-netbook fails with this:

...
[Failed] Failed to start Switch Root
See 'systemctl status initrd-switch-root.service' for details
...
Entering emergency mode
...

In "emergency mode":
# systemctl status initrd-switch-root.service
Failed to map properties: Bad message

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Test-Announce] Fedora 26 Candidate Beta-1.4 Available Now!

[rawhide]

According to the schedule [1], Fedora 26 Candidate Beta-1.4 is now
available for testing. Please help us complete all the validation
testing! For more information on release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

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

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_26_Beta_1.4_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_26_Beta_1.4_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_26_Beta_1.4_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_26_Beta_1.4_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_26_Beta_1.4_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_26_Beta_1.4_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_26_Beta_1.4_Security_Lab

All Beta priority test cases for each of these test pages [2] must
pass in order to meet the Beta Release Criteria [3].

Help is available on #fedora-qa on irc.freenode.net [4], or on the
test list [5].

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1] http://fedorapeople.org/groups/schedule/f-26/f-26-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_26_Beta_Release_Criteria
[4] irc://irc.freenode.net/fedora-qa
[5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: not all that qualified...

[Alexander Ploumistos]

On Thu, Jun 1, 2017 at 5:40 AM, Christopher  wrote:
> I've looked at that wiki page before, and found it a bit of an information
> overload.

I don't think anyone would argue with that.

> There's tons of information about the general process, but it's
> not exactly an easy-to-follow step-by-step checklist. It has a lot of
> information about what to do, but not much about how to do it.

Some time ago, I stumbled upon that page, which I believe is more like
what you are looking for:
https://fedoraproject.org/wiki/Packaging_tricks

Do pay attention to he introductory paragraph.

And of course, one could always glance at the reviews of approved
packages, to get a better idea of the whole process.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: not all that qualified...

[Christopher]

On Wed, May 31, 2017 at 10:36 PM Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:

> On Thu, Jun 1, 2017 at 5:29 AM, Christopher 
> wrote:
> > Do you have a link to an explanation of the automated fedora-review
> process, and/or some of these step-by-step checklists you mention?
>
> Plenty of links to follow in there:
> https://fedoraproject.org/wiki/Package_Review_Process
>
>
I've looked at that wiki page before, and found it a bit of an information
overload. There's tons of information about the general process, but it's
not exactly an easy-to-follow step-by-step checklist. It has a lot of
information about what to do, but not much about how to do it. I think that
might be why some people have reservations about trying to help out with
reviews.



> And this is the main tool:
> https://pagure.io/FedoraReview
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: not all that qualified...

[Alexander Ploumistos]

On Thu, Jun 1, 2017 at 5:29 AM, Christopher  wrote:
> Do you have a link to an explanation of the automated fedora-review process, 
> and/or some of these step-by-step checklists you mention?

Plenty of links to follow in there:
https://fedoraproject.org/wiki/Package_Review_Process

And this is the main tool:
https://pagure.io/FedoraReview
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: not all that qualified...

[Christopher]

On Wed, May 31, 2017 at 9:04 PM Susi Lehtola 
wrote:

> On 05/31/2017 05:19 PM, Christopher wrote:
> > On Wed, May 31, 2017 at 6:44 PM David Muse  > > wrote:
> >
> > Hello all,
> >
> > I have a fairly large package that needs review:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1415612
> >
> > and I've been offered a few review swaps for it, but the trouble is,
> I
> > don't really feel well qualified to review packages yet.  I only
> > maintain one other package (a pre-requisite for that one above) and
> it's
> > super simple.
> >
> > Should I just jump in anyway?  How is this kind of thing usually
> > resolved?
> >
> > At the risk of turning this into a "me too" thread, I want to thank you
> > for asking this question. I'm in the same situation. I'm not comfortable
> > reviewing packages yet. I'm sure there are others as well. So, on behalf
> > of all us in this same situation, thanks for asking. I look forward to
> > the advice that (hopefully) follows, from those more experienced.
>
> Sounds like a Catch-22: you can't get experience without reviewing
> packages, but you don't want to review until you have more experience.
>
> However, this is exactly why we have the sponsor system in place. I've
> found it a good system that the sponsor should ask for a few informal
> reviews from their sponsoree candidates, and the sponsor then does the
> formal review, checking if the sponsoree missed anything.
>
> Reviewing is nowadays a much simpler task than what it used to be,
> thanks to the automated fedora-review process. It handles a lot of
> things for you, but you still do have to go through some checklists by
> hand.
>
>
Do you have a link to an explanation of the automated fedora-review
process, and/or some of these step-by-step checklists you mention?


> I would suggest you do an informal review, and ask your sponsor, or
> people on the list to check it for you.
> --
> Susi Lehtola
> Fedora Project Contributor
> jussileht...@fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: not all that qualified...

[Susi Lehtola]

On 05/31/2017 05:19 PM, Christopher wrote:
On Wed, May 31, 2017 at 6:44 PM David Muse > wrote:


Hello all,

I have a fairly large package that needs review:
https://bugzilla.redhat.com/show_bug.cgi?id=1415612

and I've been offered a few review swaps for it, but the trouble is, I
don't really feel well qualified to review packages yet.  I only
maintain one other package (a pre-requisite for that one above) and it's
super simple.

Should I just jump in anyway?  How is this kind of thing usually
resolved?

At the risk of turning this into a "me too" thread, I want to thank you 
for asking this question. I'm in the same situation. I'm not comfortable 
reviewing packages yet. I'm sure there are others as well. So, on behalf 
of all us in this same situation, thanks for asking. I look forward to 
the advice that (hopefully) follows, from those more experienced.


Sounds like a Catch-22: you can't get experience without reviewing 
packages, but you don't want to review until you have more experience.


However, this is exactly why we have the sponsor system in place. I've 
found it a good system that the sponsor should ask for a few informal 
reviews from their sponsoree candidates, and the sponsor then does the 
formal review, checking if the sponsoree missed anything.


Reviewing is nowadays a much simpler task than what it used to be, 
thanks to the automated fedora-review process. It handles a lot of 
things for you, but you still do have to go through some checklists by hand.


I would suggest you do an informal review, and ask your sponsor, or 
people on the list to check it for you.

--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1457584] New: perl-Module-CoreList-5.20170531 is available

[bugzilla]

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

Bug ID: 1457584
   Summary: perl-Module-CoreList-5.20170531 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Module-CoreList
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-de...@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 5.20170531
Current version/release in rawhide: 5.20170530-1.fc27
URL: http://search.cpan.org/dist/Module-CoreList/

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

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

Re: not all that qualified...

[Christopher]

On Wed, May 31, 2017 at 6:44 PM David Muse 
wrote:

> Hello all,
>
> I have a fairly large package that needs review:
> https://bugzilla.redhat.com/show_bug.cgi?id=1415612
>
> and I've been offered a few review swaps for it, but the trouble is, I
> don't really feel well qualified to review packages yet.  I only
> maintain one other package (a pre-requisite for that one above) and it's
> super simple.
>
> Should I just jump in anyway?  How is this kind of thing usually resolved?
>
> Thanks,
>
> David
> david.m...@firstworks.com
>
>


At the risk of turning this into a "me too" thread, I want to thank you for
asking this question. I'm in the same situation. I'm not comfortable
reviewing packages yet. I'm sure there are others as well. So, on behalf of
all us in this same situation, thanks for asking. I look forward to the
advice that (hopefully) follows, from those more experienced.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Rsyslog log format change proposal

[Jason L Tibbitts III]

> "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:

ZJ> I you post the code somewhere, I could have a look.

It's in the upstream "journal" branch of the denyhosts source:

https://github.com/denyhosts/denyhosts/tree/journal

https://github.com/denyhosts/denyhosts/commit/d0d66a2890d50a460ecd20ee0b10702fec18eaeb

The meat is in DenyHosts/deny_hosts.py.  The code is mostly a mess
because it's an attempt to cram journal processing into an existing main
loop, and a lot of the diff is just reindentation.  My intent was to
make sure the simple approach worked first and then refactor things to
make it less unpleasant.

Really all it's doing is "self.__journal = journal.Reader()", then
adding some match clauses with disjunctions in between, and maybe
loading a saved cursor and seeking to it.  The main loop is just doing
"for entry in self.__journal:", but after running for some long period
of time (usually days) that ends up blocking forever waiting for the
next entry.

The code to deal with the journal really is trivial when compared to
polling to see if a logfile has changed, and then opening and seeking
and everything.  It's just that, well, it would simply stop working.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Rsyslog log format change proposal

[Zbigniew Jędrzejewski-Szmek]

On Wed, May 31, 2017 at 02:15:21PM -0500, Jason L Tibbitts III wrote:
> > "TT" == Tomasz Torcz  writes:
> 
> TT> fail2ban works with journal.  BTW, sshguard (which is similar to
> TT> fail2ban) works woth journal, too.
> 
> Denyhosts doesn't use the journal, though I have a branch which does.
> Sadly I never could figure out why iterating over a journal.Reader()
> object will sometimes simply hang forever without returning any new
> entries, and so my patches never went upstream.

I you post the code somewhere, I could have a look.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

not all that qualified...

[David Muse]

Hello all,

I have a fairly large package that needs review:
https://bugzilla.redhat.com/show_bug.cgi?id=1415612

and I've been offered a few review swaps for it, but the trouble is, I 
don't really feel well qualified to review packages yet.  I only 
maintain one other package (a pre-requisite for that one above) and it's 
super simple.


Should I just jump in anyway?  How is this kind of thing usually resolved?

Thanks,

David
david.m...@firstworks.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Schedule for Thursday's FPC Meeting (2017-06-01 16:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2017-06-01 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. uitime):

= Day: Thursday ==
2017-06-01 09:00 PDT  US/Pacific
2017-06-01 12:00 EDT  --> US/Eastern <--
2017-06-01 16:00 UTC  UTC   
2017-06-01 17:00 BST  Europe/London 
2017-06-01 18:00 CEST Europe/Paris  
2017-06-01 18:00 CEST Europe/Berlin 
2017-06-01 21:30 IST  Asia/Calcutta 
 New Day: Friday -
2017-06-02 00:00 +08  Asia/Singapore
2017-06-02 00:00 HKT  Asia/Hong_Kong
2017-06-02 01:00 JST  Asia/Tokyo
2017-06-02 02:00 AEST Australia/Brisbane

 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

= New business =

#topic #686 Avoid using names with `python-` prefix in requires 
.fpc 686
https://pagure.io/packaging-committee/issue/686

#topic #687 Repository config/COPr policy conflicts with FESCo policy  
.fpc 687
https://pagure.io/packaging-committee/issue/687


#topic #688 Council banned weak fwd deps to third party repos
.fpc 688
https://pagure.io/packaging-committee/issue/688

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Retired mod_auth_kerb in Fedora master

[Michael McLean]

Thanks for the prod. I've filed an issue and PR with Koji upstream. Feel
free to comment there

https://pagure.io/koji/issue/443
https://pagure.io/koji/pull-request/444

Granted, Fedora has their own spec for koji, so that will need to change as
well. cc:Dennis


On Wed, May 31, 2017 at 10:19 AM, Joe Orton  wrote:

> Hi, I've retired mod_auth_kerb in the master branch.  mod_auth_kerb has
> been unmaintained for many years.  mod_auth_gssapi is now available and
> is an up-to-date, maintained replacement.  Koji is the only dependency,
> let me or Simo know if you want help adjusting the koji-web
> configuration.
>
> Regards, Joe
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Rsyslog log format change proposal

[Jason L Tibbitts III]

> "TT" == Tomasz Torcz  writes:

TT> fail2ban works with journal.  BTW, sshguard (which is similar to
TT> fail2ban) works woth journal, too.

Denyhosts doesn't use the journal, though I have a branch which does.
Sadly I never could figure out why iterating over a journal.Reader()
object will sometimes simply hang forever without returning any new
entries, and so my patches never went upstream.

In any case, it doesn't care about the format of the timestamps, though
someone could have configured custom regexps.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Orphaning rubygem-ruby-ole

[Vít Ondruch]

Hi all,

I don't have any use for rubygem-ruby-ole, so I orphaned the package.


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Test-Announce] Re: Fedora 26 Candidate Beta-1.3 Available Now!

[Adam Williamson]

On Wed, 2017-05-31 at 10:46 +0200, Christian Dersch wrote:
> As I'm its maintainer I also want to point out that Beta-1.3 is also
> missing the x86_64 build of the Astronomy Lab, there was some random (?)
> mirror issue, the Lab is not broken.
> 
> Snipped from anaconda-packaging.log:
> 
> 03:44:25,447 WARN packaging: Failed to download
> 'python3-xlrd-0.9.4-5.fc26.noarch.rpm': 3 - Status code: 408 for
> http://kojipkgs.fedoraproject.org/compose/26/Fedora-26-20170530.0/compose/Everything/x86_64/os/Packages/p/python3-xlrd-0.9.4-5.fc26.noarch.rpm
> 03:44:25,448 WARN packaging: Failed to download
> 'python3-xlrd-0.9.4-5.fc26.noarch.rpm': 1 - No more mirrors to try - All
> mirrors were already tried without success
> 
> Lab just build fine on i386, also x86_64 built fine @daily f26 compose
> 
> Beta 1.3 Astronomy i386 (success):
> https://koji.fedoraproject.org/koji/taskinfo?taskID=19788000
> 
> Beta 1.3 Astronomy x86_64 (failed):
> https://koji.fedoraproject.org/koji/taskinfo?taskID=19787999
> 
> Daily build 20170529 x86_64 (success):
> https://koji.fedoraproject.org/koji/taskinfo?taskID=19766604
> 
> So I'd strongly prefer a 1.4 build as a random failure @build
> infrastructure (which is not the maintainers fault), should not block
> any build to be part of a (alpha/beta/final) release.

A 1.4 is in fact happening right now for unrelated reasons - let's hope
your spin shows up in it :) Sorry for the trouble.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 Self Contained Change: Making sudo pip Safe (Again)

[Björn 'besser82' Esser]

Am 31.05.2017 um 16:20 schrieb Jan Kurik:

= Proposed Self Contained Change: Making sudo pip Safe (Again) =
https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe

Change owner(s):
* Michal Cyprian 
* Petr Viktorin 
* Tomas Orsava 
* Miro Hroncok 


At the present time, running sudo pip3 in Fedora is not safe. Pip
shares its installation directory with dnf, can remove dnf-managed
files and generally break the Python 3 interpreter. We propose a
series of measures that will make it safe to use.


== Detailed Description ==
The danger of using sudo pip3 stems from the fact that both Python dnf
packages and sudo pip3 install modules to the same location, namely
/usr/lib/pythonX.Y/site-packages.

We aim to move the working directory for sudo pip3 to a more
appropriate location: /usr/local/lib/pythonX.Y/site-packages, and
modify the Python 3 interpreter in Fedora to scan both above mentioned
locations when importing modules. In addition, system-python—a
stripped down version of Python 3 for use by system tools—will not
read the sudo pip3 install location, making it more secure by being
less susceptible to interference by user-downloaded modules.

 From the technical standpoint, this will be accomplished by changing
the install prefix setting of the distutils install command in the
/usr/bin/python3 executable from /usr/ to /usr/local. pip3 and
distutils will thereafter use this prefix when determining where to
install modules. In addition, the paths
/usr/local/lib/pythonX.Y/site-packages and
/usr/local/lib64/pythonX.Y/site-packages will be added to the front of
the sys.path variable so that modules are imported preferentially from
there. These settings, however, will not be modified for the
system-python binary, the /usr/bin/python3 executable when running
with -I option specified, nor when an RPM build is detected.
Therefore, Python RPM packages will continue to be built with the
correct installation path for system modules.

The purpose of this change is not to make sudo pip a standard way to
install Python packages. Virtual environments and pip3 install --user
should still be the prefered options. Nevertheless, sudo pip is far
too prevalent an instruction in various guides and installation notes
throughout the Internet that there is little hope of changing users'
behaviour in this regard.


== Scope ==
* Proposal owners:
Modify the distutils install command as described above.
Modify the site.py script to add additional paths to sys.path when it is needed.

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
https://pagure.io/releng/issue/6820

* List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
Not needed for this Change


+1 for this proposal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 Self Contained Change: Making sudo pip Safe (Again)

[Jan Kurik]

= Proposed Self Contained Change: Making sudo pip Safe (Again) =
https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe

Change owner(s):
* Michal Cyprian 
* Petr Viktorin 
* Tomas Orsava 
* Miro Hroncok 


At the present time, running sudo pip3 in Fedora is not safe. Pip
shares its installation directory with dnf, can remove dnf-managed
files and generally break the Python 3 interpreter. We propose a
series of measures that will make it safe to use.


== Detailed Description ==
The danger of using sudo pip3 stems from the fact that both Python dnf
packages and sudo pip3 install modules to the same location, namely
/usr/lib/pythonX.Y/site-packages.

We aim to move the working directory for sudo pip3 to a more
appropriate location: /usr/local/lib/pythonX.Y/site-packages, and
modify the Python 3 interpreter in Fedora to scan both above mentioned
locations when importing modules. In addition, system-python—a
stripped down version of Python 3 for use by system tools—will not
read the sudo pip3 install location, making it more secure by being
less susceptible to interference by user-downloaded modules.

From the technical standpoint, this will be accomplished by changing
the install prefix setting of the distutils install command in the
/usr/bin/python3 executable from /usr/ to /usr/local. pip3 and
distutils will thereafter use this prefix when determining where to
install modules. In addition, the paths
/usr/local/lib/pythonX.Y/site-packages and
/usr/local/lib64/pythonX.Y/site-packages will be added to the front of
the sys.path variable so that modules are imported preferentially from
there. These settings, however, will not be modified for the
system-python binary, the /usr/bin/python3 executable when running
with -I option specified, nor when an RPM build is detected.
Therefore, Python RPM packages will continue to be built with the
correct installation path for system modules.

The purpose of this change is not to make sudo pip a standard way to
install Python packages. Virtual environments and pip3 install --user
should still be the prefered options. Nevertheless, sudo pip is far
too prevalent an instruction in various guides and installation notes
throughout the Internet that there is little hope of changing users'
behaviour in this regard.


== Scope ==
* Proposal owners:
Modify the distutils install command as described above.
Modify the site.py script to add additional paths to sys.path when it is needed.

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
https://pagure.io/releng/issue/6820

* List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
Not needed for this Change


-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Retired mod_auth_kerb in Fedora master

[Joe Orton]

Hi, I've retired mod_auth_kerb in the master branch.  mod_auth_kerb has 
been unmaintained for many years.  mod_auth_gssapi is now available and 
is an up-to-date, maintained replacement.  Koji is the only dependency, 
let me or Simo know if you want help adjusting the koji-web 
configuration.

Regards, Joe
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Test-Announce] Re: Fedora 26 Candidate Beta-1.3 Available Now!

[Christian Dersch]

On 05/31/2017 02:22 PM, Matthew Miller wrote:

On Wed, May 31, 2017 at 10:46:10AM +0200, Christian Dersch wrote:

So I'd strongly prefer a 1.4 build as a random failure @build
infrastructure (which is not the maintainers fault), should not block
any build to be part of a (alpha/beta/final) release.

I think ultimately we need a way to get these out of lockstep with the
main release. We should be able to build and publish Spins/Labs on
their own cycles (ideally without human intervention required from
rel-eng).

How much use do you see of the Astronomy Spin as bootable media or its
own install? For some, this really makes sense (the desktops, the
security lab) but it seems like maybe Astronomy might be better as a
curated software set in GNOME Software?



I think of that in addition, because that makes much sense, just a lack 
of time right now. But the live media are very useful, e.g. at 
conferences to present it without the need to install anything. So I see 
this also as some kind of marketing. Also got some nice feedback from 
both amateur and professional astronomers at universities.


For building and publishing spins/labs in own cycles: I completely agree 
with you


Greetings,
Christian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Test-Announce] Re: Fedora 26 Candidate Beta-1.3 Available Now!

[Matthew Miller]

On Wed, May 31, 2017 at 10:46:10AM +0200, Christian Dersch wrote:
> So I'd strongly prefer a 1.4 build as a random failure @build
> infrastructure (which is not the maintainers fault), should not block
> any build to be part of a (alpha/beta/final) release.

I think ultimately we need a way to get these out of lockstep with the
main release. We should be able to build and publish Spins/Labs on
their own cycles (ideally without human intervention required from
rel-eng).

How much use do you see of the Astronomy Spin as bootable media or its
own install? For some, this really makes sense (the desktops, the
security lab) but it seems like maybe Astronomy might be better as a
curated software set in GNOME Software?

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Rsyslog log format change proposal

[Tomasz Torcz]

On Tue, May 30, 2017 at 10:37:02PM +0200, Till Maas wrote:
> On Mon, May 29, 2017 at 07:21:07PM +0200, Björn 'besser82' Esser wrote:
> 
> > Does this qualify to be a system-wide change?  To me this looks like a
> > self-contained change, since I don't see any other packages or processes in
> > need for adjustment, but rsyslog itself.
> > 
> > Please correct me, if I'm mistaking.
> 
> Besides logwatch that was already mentioned, there is also logcheck that
> parses logfiles and will break. Other tools might be things like
> fail2ban or denyhosts that scan logs for failed login attempts to block
> IP addresses.

  fail2ban works with journal.  BTW, sshguard (which is similar to fail2ban)
works woth journal, too.

-- 
Tomasz TorczTo co nierealne -- tutaj jest normalne.
xmpp: zdzich...@chrome.pl  Ziomale na życie mają tu patenty specjalne.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: retiring git-annex

[Jens-Ulrik Petersen]

I created a git-annex copr:

https://copr.fedorainfracloud.org/coprs/petersen/git-annex/
​
Jens
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Orphaning rubygem-configuration

[Vít Ondruch]

Hi all,

I have orphaned rubygem-configuration in F26+.

This package was previously required by rubygem-launchy, but it is not
needed anymore. Therefore I orphaned F26+, but keep the F2{4,5} till
their EOL. Feel free to pick the package if you have any use for it or
let it be garbage collected, since the upstream seems to be abandoned
anyway.


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Test-Announce] Re: Fedora 26 Candidate Beta-1.3 Available Now!

[Christian Dersch]

As I'm its maintainer I also want to point out that Beta-1.3 is also
missing the x86_64 build of the Astronomy Lab, there was some random (?)
mirror issue, the Lab is not broken.

Snipped from anaconda-packaging.log:

03:44:25,447 WARN packaging: Failed to download
'python3-xlrd-0.9.4-5.fc26.noarch.rpm': 3 - Status code: 408 for
http://kojipkgs.fedoraproject.org/compose/26/Fedora-26-20170530.0/compose/Everything/x86_64/os/Packages/p/python3-xlrd-0.9.4-5.fc26.noarch.rpm
03:44:25,448 WARN packaging: Failed to download
'python3-xlrd-0.9.4-5.fc26.noarch.rpm': 1 - No more mirrors to try - All
mirrors were already tried without success

Lab just build fine on i386, also x86_64 built fine @daily f26 compose

Beta 1.3 Astronomy i386 (success):
https://koji.fedoraproject.org/koji/taskinfo?taskID=19788000

Beta 1.3 Astronomy x86_64 (failed):
https://koji.fedoraproject.org/koji/taskinfo?taskID=19787999

Daily build 20170529 x86_64 (success):
https://koji.fedoraproject.org/koji/taskinfo?taskID=19766604

So I'd strongly prefer a 1.4 build as a random failure @build
infrastructure (which is not the maintainers fault), should not block
any build to be part of a (alpha/beta/final) release.

Greetings,
Christian


On 05/31/2017 09:50 AM, Adam Williamson wrote:
> On Wed, 2017-05-31 at 06:57 +, rawh...@fedoraproject.org wrote:
>> According to the schedule [1], Fedora 26 Candidate Beta-1.3 is now
>> available for testing. Please help us complete all the validation
>> testing! For more information on release validation testing, see:
>> https://fedoraproject.org/wiki/QA:Release_validation_test_plan
> Note that I messed up the compose request for this a bit and it's
> definitely missing some FEs that should've been in it and *may* be
> missing a blocker fix. So there may well be a 1.4. I'll update in the
> morning. Sorry!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Orphan: mupdf/jbig2dec

[Zdenek Dohnal]

On 05/31/2017 08:32 AM, Rémi Verschelde wrote:
> 2017-05-31 8:24 GMT+02:00 Zdenek Dohnal :
>> On 05/30/2017 01:19 PM, Dridi Boukelmoune wrote:
>>> On Tue, May 30, 2017 at 1:05 PM, Pavel Zhukov
>>>  wrote:
 Hello.
 Due to many CVEs and low quality/security of these packages  as well as 
 Windows oriented upstream I'm going to orphan both jbig2dec and mupdf 
 packages in Fedora/EPEL.
 Sometimes the build doesn't reach stable branch just because it's 
 deprecated by new build with new CVE.
 Feel free to take them.
>>> It sounds more like something to retire instead, at least on Fedora...
>> At least mupdf is needed in cups-filters as BuildRequire - cups-filters
>> uses it in pdftopdf filter, so abandoning it would resolve in more
>> difficult PDF printing in Fedora. And as I can see jbig2dec is in
>> BuildRequires for mupdf, I should take it.
> For what it's worth, I briefly maintained mupdf in Mageia before
> deciding to drop it from Cauldron (our development release) for the
> same reasons that Pavel mentioned.
>
> If you want to keep mupdf, I would advise to patch away the mujstest
> program, which is the one affected by most CVEs against mupdf over the
> last couple of years. Without mupdf, you'd be down to patching
> security vulnerabilities every 2 months instead of every 2 weeks... :)
I disabled mupdf in cups-filters - problem solved. We can retire it at
least from the view of cups-filters.
>
> Regards,
> Rémi
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

-- 
Zdenek Dohnal
Associate Software Engineer
Brno, Purkyňova 99, Czech Republic
RED HAT | TRIED. TESTED. TRUSTED.

Every telecommunications Company in the Fortune Global 500 relies on Red Hat.

Find out why at Trusted | Red Hat




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Test-Announce] Re: Fedora 26 Candidate Beta-1.3 Available Now!

[Adam Williamson]

On Wed, 2017-05-31 at 06:57 +, rawh...@fedoraproject.org wrote:
> According to the schedule [1], Fedora 26 Candidate Beta-1.3 is now
> available for testing. Please help us complete all the validation
> testing! For more information on release validation testing, see:
> https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Note that I messed up the compose request for this a bit and it's
definitely missing some FEs that should've been in it and *may* be
missing a blocker fix. So there may well be a 1.4. I'll update in the
morning. Sorry!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org