[389-devel] 389 DS nightly 2018-06-08 - 61% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2018/06/08/report-389-ds-base-1.4.0.9-20180607gitcfb7dc2.fc28.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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/LA4IQ6X6E7BYFMWMQQW7O2NDKXYTVEFR/

Re: F29 System Wide Change: Hide the grub menu

[Gerald B. Cox]

On Thu, Jun 7, 2018 at 2:07 AM, Hans de Goede  wrote:

>
>
> A question to you (and the Fedora community in general) where
> should the documentation for this live ? I would like to have
> something longer lived then the Changes wiki page or the
> release notes.
>

If it were me, I would put it in:

1.  The release notes for F29
2.  The System Administrator's Guide for F29 and all subsequent releases
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MQF6VLWQN4OKFSD3HJEOJS7GKG2NETCP/

Ending development of Hubs

[Jim Perrin]

Earlier in the year, the Fedora Infrastructure team had a hackathon.
Among other work during the event, we made adjustments to app
development and ownership to keep the team working efficiently. For
example, we retired the separate Jenkins instance in Fedora
infrastructure since it’s redundant.

We also decided, after discussion around the team and with the FPL, to
cease active development of Hubs. This was a difficult decision but
allows the team to put more effort and resources into supporting our
core applications. The code for Hubs will continue to live here and of
course it remains 100% free and open source: https://pagure.io/fedora-hubs

I realized we did not publicly state the end of the development for
Hubs, so I’m correcting that oversight with this announcement. I’m proud
of the work the team has done on Hubs over the years while trying to
balance multiple priorities. However, with limited time and resources,
it’s more important that the Infrastructure team focus on core tasks
that support the Fedora community such as development, automation and
testing.


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

[389-devel] please review: Tickets 49703, 49740, 49741 - Cockpit UI Fixes

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/49770
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/KPLHZGVPAWQXF6GTXLWIXAEJWRGPI4OP/

[Bug 1588760] CVE-2018-12015 perl: Directory traversal in Archive::Tar

[bugzilla]

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

Pedro Sampaio  changed:

   What|Removed |Added

 Blocks||1588762



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/AXBVONHDCWOGXF7Q3RKRWT6WCEJX2KRM/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[John Florian]

On 06/07/2018 08:44 AM, Tomas Mraz wrote:

On Tue, 2018-06-05 at 16:34 -0400, John Florian wrote:

On 06/05/2018 12:25 PM, Tomas Mraz wrote:

On Tue, 2018-06-05 at 16:11 +, Christian Stadelmann wrote:

"Fallback option" always smells like "protocol downgrade attack".
This would undermine the idea of a crypto policy. Anyway,
implementing it seems way out of scope for the crypto policy.

Yes, a fallback option is a no-way. You can switch the system
policy to
LEGACY, however that does not necessarily mean that some very old
legacy HW will start to work with Firefox or another web browser,
because with newer versions of the browsers and newer versions of
TLS/crypto libraries some very old and insecure algorithm and
protocol
support is being also removed.


Makes sense, but what is the best way to deal with such old HW if
you're
stuck with it?  I don't want to compromise my workstation for all my
normal needs just to deal with some ancient embedded https server,
but
it would kind of suck to have to boot some old live image just to do
some routine config change.  It seems the industry has room for
improvement here.

Use a virtual machine with some old live image for such insecure
communication?

I do not think any "improvement" that involves changing the defaults to
be more lenient even if accompanied with some big warning when such old
insecure connection is established would be a good idea. Оnly if the
users really have to boot some old live image or do some similar
unpleasant task it will really force the old HW out of production where
it should belong. Or we can forget about security based on
cryptographic protocols altogether.

Note that we are talking about SSLv2, MD4 or similar long long time ago
obsolete stuff. Not things that were just "recently" found as insecure.


Oh!  I didn't realize the proposal was covering stuff /that/ old. 
Somehow TLS 1.1 just didn't equate in my memory with that era. Thank you 
Tomas for the clarification.


Also, I just found this neat[0] table that seems to present a good 
high-level view of the various TLS levels.


[0] https://en.wikipedia.org/wiki/Transport_Layer_Security#Cipher
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5BEYIJLDWIHXQVTUZRQ6AN3RKASFOP2Z/

[Bug 1588760] CVE-2018-12015 perl: Directory traversal in Archive::Tar

[bugzilla]

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

Pedro Sampaio  changed:

   What|Removed |Added

 CC||hho...@redhat.com,
   ||jor...@redhat.com,
   ||perl-maint-l...@redhat.com
 Whiteboard|impact=low,public=20180607, |impact=low,public=20180607,
   |reported=20180607,source=cv |reported=20180607,source=cv
   |e,cvss3=3.3/CVSS:3.0/AV:L/A |e,cvss3=3.3/CVSS:3.0/AV:L/A
   |C:L/PR:N/UI:R/S:U/C:N/I:L/A |C:L/PR:N/UI:R/S:U/C:N/I:L/A
   |:N,cwe=CWE-22,fedora-all/pe |:N,cwe=CWE-22,fedora-all/pe
   |rl=affected,rhel-5/perl=not |rl=affected,rhel-5/perl=new
   |affected,rhel-6/perl=notaff |,rhel-6/perl=new,rhel-7/per
   |ected,rhel-7/perl=notaffect |l=new,rhel-8/perl=new,rhscl
   |ed,rhel-8/perl=affected,rhs |-3/rh-perl526-perl=new,rhsc
   |cl-3/rh-perl526-perl=affect |l-3/rh-perl524-perl=new,rhs
   |ed,rhscl-3/rh-perl524-perl= |cl-3/rh-perl520-perl=new
   |affected,rhscl-3/rh-perl520 |
   |-perl=wontfix   |



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/KQSONIXZWTDQDZZYVZP7GVVNBETJABLP/

[Bug 1588760] CVE-2018-12015 perl: Directory traversal in Archive::Tar

[bugzilla]

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

Pedro Sampaio  changed:

   What|Removed |Added

 Whiteboard|impact=low,public=20180607, |impact=low,public=20180607,
   |reported=20180607,source=cv |reported=20180607,source=cv
   |e,cvss3=3.3/CVSS:3.0/AV:L/A |e,cvss3=3.3/CVSS:3.0/AV:L/A
   |C:L/PR:N/UI:R/S:U/C:N/I:L/A |C:L/PR:N/UI:R/S:U/C:N/I:L/A
   |:N,cwe=CWE-22,fedora-all/pe |:N,cwe=CWE-22,fedora-all/pe
   |rl=affected |rl=affected,rhel-5/perl=not
   ||affected,rhel-6/perl=notaff
   ||ected,rhel-7/perl=notaffect
   ||ed,rhel-8/perl=affected,rhs
   ||cl-3/rh-perl526-perl=affect
   ||ed,rhscl-3/rh-perl524-perl=
   ||affected,rhscl-3/rh-perl520
   ||-perl=wontfix



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/PFZGRSSP3UGSKGQPA4M2U5AHRWYF3Y4P/

[Bug 1588761] CVE-2018-12015 perl: Directory traversal in Archive::Tar [ fedora-all]

[bugzilla]

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

Pedro Sampaio  changed:

   What|Removed |Added

 Blocks||1588760 (CVE-2018-12015)




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1588760
[Bug 1588760] CVE-2018-12015 perl: Directory traversal in Archive::Tar
-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/IVBA7UNCUBHXM7QGOOS7U272JIBXUOKH/

[Bug 1588761] New: CVE-2018-12015 perl: Directory traversal in Archive:: Tar [fedora-all]

[bugzilla]

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

Bug ID: 1588761
   Summary: CVE-2018-12015 perl: Directory traversal in
Archive::Tar [fedora-all]
   Product: Fedora
   Version: 28
 Component: perl
  Keywords: Security, SecurityTracking
  Severity: low
  Priority: low
  Assignee: jples...@redhat.com
  Reporter: psamp...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: al...@redhat.com, caillon+fedoraproj...@gmail.com,
iarn...@gmail.com, jples...@redhat.com, ka...@ucw.cz,
mbar...@fastmail.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
psab...@redhat.com, rhug...@redhat.com,
sandm...@redhat.com, tcall...@redhat.com




This is an automatically created tracking bug!  It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of fedora-all.

For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.

For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs

When submitting as an update, use the fedpkg template provided in the next
comment(s).  This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.

Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.

NOTE: this issue affects multiple supported versions of Fedora. While only
one tracking bug has been filed, please correct all affected versions at
the same time.  If you need to fix the versions independent of each other,
you may clone this bug as appropriate.

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/2VEJEDN2AZKCK2TU6HNB47W3SUBHUJ5T/

[Bug 1588761] CVE-2018-12015 perl: Directory traversal in Archive::Tar [ fedora-all]

[bugzilla]

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



--- Comment #1 from Pedro Sampaio  ---
Use the following template to for the 'fedpkg update' request to submit an
update for this issue as it contains the top-level parent bug(s) as well as
this tracking bug.  This will ensure that all associated bugs get updated
when new packages are pushed to stable.

=

# bugfix, security, enhancement, newpackage (required)
type=security

# testing, stable
request=testing

# Bug numbers: 1234,9876
bugs=1588760,1588761

# Description of your update
notes=Security fix for [PUT CVEs HERE]

# Enable request automation based on the stable/unstable karma thresholds
autokarma=True
stable_karma=3
unstable_karma=-3

# Automatically close bugs when this marked as stable
close_bugs=True

# Suggest that users restart after update
suggest_reboot=False

==

Additionally, you may opt to use the bodhi web interface to submit updates:

https://bodhi.fedoraproject.org/updates/new

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/KTAJBT2GMJQU32GNSGRX6OXMGGSKAREP/

[Bug 1588760] CVE-2018-12015 perl: Directory traversal in Archive::Tar

[bugzilla]

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

Pedro Sampaio  changed:

   What|Removed |Added

 Depends On||1588761



--- Comment #1 from Pedro Sampaio  ---
Created perl tracking bugs for this issue:

Affects: fedora-all [bug 1588761]


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1588761
[Bug 1588761] CVE-2018-12015 perl: Directory traversal in Archive::Tar
[fedora-all]
-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/MRBI7WRRLJKM32OJV3Q3OLWUQSIDGSZM/

[Bug 1588760] New: CVE-2018-12015 perl: Directory traversal in Archive:: Tar

[bugzilla]

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

Bug ID: 1588760
   Summary: CVE-2018-12015 perl: Directory traversal in
Archive::Tar
   Product: Security Response
 Component: vulnerability
  Keywords: Security
  Severity: low
  Priority: low
  Assignee: security-response-t...@redhat.com
  Reporter: psamp...@redhat.com
CC: al...@redhat.com, caillon+fedoraproj...@gmail.com,
iarn...@gmail.com, jples...@redhat.com, ka...@ucw.cz,
mbar...@fastmail.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
psab...@redhat.com, rhug...@redhat.com,
sandm...@redhat.com, tcall...@redhat.com



In Perl through 5.26.2, the Archive::Tar module allows remote attackers to
bypass a directory-traversal protection mechanism, and overwrite arbitrary
files, via an archive file containing a symlink and a regular file with the
same name.

References:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900834

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/YMABH5BL4IJAZWE5NUXUIA5NWMWIUTSZ/

Re: Fedora Elections May 2018 - Voting period of FESCo elections has started

[Justin Forbes]

On Thu, Jun 7, 2018 at 11:15 AM, Tomasz Kłoczko
 wrote:
> On 7 June 2018 at 03:17, Jan Kurik  wrote:
> [..]
>>
>> [2.1] Justin Forbes:
>>
>> https://communityblog.fedoraproject.org/fesco-election-interview-justin-forbes-jforbes/
>> [2.2] Stephen Gallagher:
>>
>> https://communityblog.fedoraproject.org/fesco-election-interview-stephen-gallagher-sgallagh/
>> [2.3] Till Maas:
>>
>> https://communityblog.fedoraproject.org/fesco-election-interview-till-maas-till/
>> [2.4] Randy Barlow:
>>
>> https://communityblog.fedoraproject.org/fesco-election-interview-randy-barlow-bowlofeggs/
>> [2.5] Petr Šabata:
>>
>> https://communityblog.fedoraproject.org/fesco-election-interview-petr-sabata-psabata-contyk/
>
>
> 3 out of 5 candidates as most important feature which seems they want to
> push forward encircles Modularity.
> Doesn't matter that rpm never been designed in mind to handle cohabitation
> packages in different variants.
> What now Modularity offers is +1.5y behind original schedule and still in
> most of the cases it does not work.
> No one points on things like discussion on:
> - common specs coding style
> - cutting number of %iffings (and use instead SCM branches which git offers)
> - cutting legacy tails like still using tons of scriptlets which can be
> easily cleaned of remove dependencies on initscripts and maaany more like
> this which could make at least @core solid fundamentals other features
> - cutting number of dependencies (how many years ago was first discussion
> about use --as-needed in linker options?)
> - caring about quite basic security (look decision about add ~/.local/bin to
> the $PATH and complete kind of "desinteressement" about remove
> /usr/local/{bin,sbin} from already used $PATH which widely opens hell gates
> for malwares).
>
No one has said modularity is the *only* issue, but it is a big change
that Fedora is embracing.  It is important that such a large scale
change is handled in such a manner that existing users aren't left on
the sidelines.  Candidates were given only 3 questions, and 10 page
answers are pointless, people don't read them.
Security has always been a concern for Fedora, and that is not
changing.  There are several of us who start and end our day looking
at CVE lists making sure Fedora is as protected as possible. We have
implemented and continued to champion things like SE Linux and secure
boot upstream. Sure, they might not start out as elegant as we would
like, but they are constantly improved. Compiler flags are changed to
support more secure features as they are introduced, and I expect to
see work around IMA and other security initiatives going forward.
Security is not a big new initiative for Fedora, it has been an
important cornerstone for years.
FESCo doesn't exist for members to do what they want, it is a service
position, FESCo exists to serve the community. If you think FESCo
should be addressing some issues differently, file a ticket, file a
change request.  A lot of the things mentioned here don't fall into
the FESCo realm though, and would be best handled by the packaging
committee.

> Second most important goal on which candidates are focused is how internal
> Fedora infrastructure works.
>
> No one of the candidates seems is aware that people are leaving Fedora boat
> (look on distrowatch.com or
> https://w3techs.com/technologies/details/os-linux/all/all and few other
> similars stats) not because Modularity still doesn't work (and will never
> work as no one will not change some fundamental bits in rpm). Most of the
> candidates seems are completely unaware that end users of they work (binary
> packages) simple don't care about how all Fedora stuff is build but HOW IT
> WORKS.
>
There is less attrition than these sites mentioned show. There was a
large decline in users after the Gnome 3 switch, and things have been
getting better since.  It would be nice of those metrics were more
readily available and not just occasionally pulled out when an issue
arises and someone thinks to ask. There used to be a page.  And the
Fedora model is less suited to the web server space than some others
because of how quickly we move. I would expect there are several
Fedora users who are hosting sites on centos just because they don't
have to upgrade it yearly.
And yes, there is a lot of concern with how it works. things like CI
and some of the infrastructure improvements have a lot more impact on
insuring that better quality packages land in the hands of users.
That is their entire purpose. It takes time and infrastructure to get
those initiatives up and running, but the only reason those
initiatives exist is to get better quality, functional packages into
the hands of users.


> On top of this more and more decisions in Fedora seems are made in less and
> less transparent and well technically justified way.
>
> Personally I don't see any GoodEnough(tm) candidate on which I can vote ..
> candidate with descent own expertise of what is now Fedora Achilles heel ..

Re: equivalent of Debian config-package?

[Stephen John Smoogen]

On 7 June 2018 at 12:11, Dave Love  wrote:
> Stephen John Smoogen  writes:
>


>> 4. System administration/configuration management is 99% "I have a
>> solution I endure and I don't have time to re-engineer it." and 1% "Oh
>> I think I want to write my own configuration management toolkit
>> because I can't endure what I am doing now." You are going to get
>> pushback from any site you are proposing this to until you show it is
>> useful for them.
>
> I'm not convinced I need Unix system management explaining after so
> long, or how my department works.

I missed the mark in what I was trying to explain as I should not have
used "you"

The part I was talking about is that there have been several "lets do
configuration management in rpms" little side projects. They ran into
problems because every site does things their own way and no one liked
how someone else did it.

Some people expect that the configurations are idempotent and
reversible. This means that rpm -e lab01-config brings the box back to
original state.
Other people expect that the configurations are interactive by the
user which can be done via debs but not rpm.
Others have made site wide decisions on language so ruby/perl/python
must be how the tool has to be written.
Then there are the disagreements on philosophies of RPMs altering
other RPMs with %pre/%post %trigger rules for updates of those
packages.

I have had to do each of the above at one point or another and it
usually made whatever tool I built only work at that site. What I have
seen done recently is that people were putting a puppet or ansible
config set in an rpm and then requiring that tool. It would then run a
"recipe"  in %post or via a cron job and would run a unset recipe in a
%preun. Still a bit racy but worked for small configs. It was still
site specific as how those recipes lined up were authors "how I expect
the world to be" versus some generic version.



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HLYCW24X3BZVHDLKEQJP2G5EZXX6LBLF/

[EPEL-devel] Re: Bug report for dbus-c++-devel

[Anssi Johansson]

Anssi Johansson kirjoitti 7.6.2018 klo 20.27:

Richard Grainger kirjoitti 7.6.2018 klo 12.00:

Hi all

I've put in a bug report against an epel package here:
https://bugzilla.redhat.com/show_bug.cgi?id=1585753

Typically, how long does it take for someone to look at these?


The dbus-c++ packages were built in March 2014. Perhaps the dependencies 
have changed since then, causing the errors? Perhaps it builds better 
with CentOS 7.0.1406.


I also wonder about the "high" priority of your bug. Why do you need to 
compile the rpm yourself? Is "yum install dbus-c++-devel" not possible?


Apart from that, providing hints for how to fix the compilation would no 
doubt speed up resolving the bug.


Yes, this does build cleanly with CentOS 7.0.1406. I think I'll leave it 
to others to determine what exactly broke the compilation between 7.0 
and 7.5.


Perhaps dbus-c++ needs to be rebased to be compilable on 7.5, but that 
in turn may cause other issues.

___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/T6PPLLKNGGBPW2CAEBHIGJ5GUT2ZM3BV/

[EPEL-devel] Re: Bug report for dbus-c++-devel

[Anssi Johansson]

Richard Grainger kirjoitti 7.6.2018 klo 12.00:

Hi all

I've put in a bug report against an epel package here:
https://bugzilla.redhat.com/show_bug.cgi?id=1585753

Typically, how long does it take for someone to look at these?


The dbus-c++ packages were built in March 2014. Perhaps the dependencies 
have changed since then, causing the errors? Perhaps it builds better 
with CentOS 7.0.1406.


I also wonder about the "high" priority of your bug. Why do you need to 
compile the rpm yourself? Is "yum install dbus-c++-devel" not possible?


Apart from that, providing hints for how to fix the compilation would no 
doubt speed up resolving the bug.

___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/ODSMWOQYWJZROOKSO25CGUWREZAQYXJS/

Re: Fedora Elections May 2018 - Voting period of FESCo elections has started

[Josh Boyer]

On Thu, Jun 7, 2018 at 12:15 PM Tomasz Kłoczko  wrote:
>
> On 7 June 2018 at 03:17, Jan Kurik  wrote:
> [..]
>>
>> [2.1] Justin Forbes:
>> https://communityblog.fedoraproject.org/fesco-election-interview-justin-forbes-jforbes/
>> [2.2] Stephen Gallagher:
>> https://communityblog.fedoraproject.org/fesco-election-interview-stephen-gallagher-sgallagh/
>> [2.3] Till Maas:
>> https://communityblog.fedoraproject.org/fesco-election-interview-till-maas-till/
>> [2.4] Randy Barlow:
>> https://communityblog.fedoraproject.org/fesco-election-interview-randy-barlow-bowlofeggs/
>> [2.5] Petr Šabata:
>> https://communityblog.fedoraproject.org/fesco-election-interview-petr-sabata-psabata-contyk/
>
>
> 3 out of 5 candidates as most important feature which seems they want to push 
> forward encircles Modularity.
> Doesn't matter that rpm never been designed in mind to handle cohabitation 
> packages in different variants.
> What now Modularity offers is +1.5y behind original schedule and still in 
> most of the cases it does not work.
> No one points on things like discussion on:
> - common specs coding style
> - cutting number of %iffings (and use instead SCM branches which git offers)
> - cutting legacy tails like still using tons of scriptlets which can be 
> easily cleaned of remove dependencies on initscripts and maaany more like 
> this which could make at least @core solid fundamentals other features
> - cutting number of dependencies (how many years ago was first discussion 
> about use --as-needed in linker options?)
> - caring about quite basic security (look decision about add ~/.local/bin to 
> the $PATH and complete kind of "desinteressement" about remove 
> /usr/local/{bin,sbin} from already used $PATH which widely opens hell gates 
> for malwares).
>
> Second most important goal on which candidates are focused is how internal 
> Fedora infrastructure works.
>
> No one of the candidates seems is aware that people are leaving Fedora boat 
> (look on distrowatch.com or 
> https://w3techs.com/technologies/details/os-linux/all/all and few other 
> similars stats) not because Modularity still doesn't work (and will never 
> work as no one will not change some fundamental bits in rpm). Most of the 
> candidates seems are completely unaware that end users of they work (binary 
> packages) simple don't care about how all Fedora stuff is build but HOW IT 
> WORKS.
>
> On top of this more and more decisions in Fedora seems are made in less and 
> less transparent and well technically justified way.
>
> Personally I don't see any GoodEnough(tm) candidate on which I can vote .. 
> candidate with descent own expertise of what is now Fedora Achilles heel .. 
> sad :(

Run for FESCo yourself or otherwise work to fix what you think are the
problem areas.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UYW56UDEYWVJMQJTIPRGA7ZD73IA2WGH/

[Bug 1550526] Upgrade perl-Image-ExifTool to 10.80

[bugzilla]

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



--- Comment #11 from Fedora Update System  ---
perl-Image-ExifTool-11.00-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-f9bc440553

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/2H3IHVXNQK6ZQ7C5MGLUFVT5OGW4LNBQ/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

[DJ Delorie]

Michal Schorm  writes:
> Can someone explain me *real quick* what is the multilib good for? - or
> more precisely, why whould anone run 32-bit software on x86_64 OS?

Among other reasons, 32-bit code can be smaller and faster than 64-bit
code for some applications.  When trying to stuff many containers or VMs
into one server, disk and memory space might be overriding
considerations.  There might be old code that isn't 64-bit aware yet,
and the cost of fixing it might not be justified, especially if there's
an on-disk data format that's 32-bit-centric, or if the authors are
unavailable.  Building only 32-bit code cuts your QA time in half if you
have to support both 32 and 64 bit hosts.  You might have optimizations
written in 32-bit assembly, or libraries that are only available as
32-bit versions.  Or you may rely on someone else's 32-bit code that is
closed source, or abandoned.

That doesn't even touch on the continued need for 32-bit embedded
platforms, where 32-bit things on a 64-bit host can be used as a "cross
development" system.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RIYC4LS42YI3JVSGRDW5UUDYIWSZQBOM/

Re: /etc/profile.d/lang.sh -- still needed?

[Kevin Fenzi]

On 06/07/2018 06:50 AM, Jan Pokorný wrote:
> On 14/05/18 17:19 +0200, David Kaspar [Dee'Kej] wrote:
>> does anybody know if the files /etc/profile.d/lang.{csh,sh}
>> are still used these days, and what for?
>> Do we still need them in Fedora?
>> Should they be installed by default these days?
>>
>> Any info is appreciated! :)
> 
> Frankly, had no idea about that file but apparently it's needed (or
> something to that effect) so as to have non-ascii characters rendered
> correctly in the terminal-within-WM settings (sway + urxvt256c-ml).
> I am not sure what the cause was, could be just missing
> LANG=en_US.UTF-8 in the environment -- no idea what's the
> intended authoritative "automagic" source for that otherwise.
> Or does it mean one shouldn't trust the distribution for
> this common convenience anymore?
> 
> Please be more considerate even to Rawhide package consumers next time
> around and coordinate file migrations between packages properly.
> I can see that these files were moved to setup package, but alas,
> that hasn't been rebuilt yet.  Perhaps versioned dependency or even
> path-based one would be justified in this case to prevent unexpected
> regressions.

setup was rebuilt... but I untagged it from f29 due to:
https://bugzilla.redhat.com/show_bug.cgi?id=1585321

(new initscripts conflicted with chkconfig, then when I untagged that
the old initscripts conflicted with setup).

I just tagged it back in.

So, please direct any ire at me, not David.
It was coordinated, just got sidetracked.

kevin



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

Re: Fedora Elections May 2018 - Voting period of FESCo elections has started

[Tomasz Kłoczko]

On 7 June 2018 at 03:17, Jan Kurik  wrote:
[..]

> [2.1] Justin Forbes:
> https://communityblog.fedoraproject.org/fesco-election-interview-justin-
> forbes-jforbes/
> [2.2] Stephen Gallagher:
> https://communityblog.fedoraproject.org/fesco-election-interview-stephen-
> gallagher-sgallagh/
> [2.3] Till Maas:
> https://communityblog.fedoraproject.org/fesco-
> election-interview-till-maas-till/
> [2.4] Randy Barlow:
> https://communityblog.fedoraproject.org/fesco-election-interview-randy-
> barlow-bowlofeggs/
> [2.5] Petr Šabata:
> https://communityblog.fedoraproject.org/fesco-election-interview-petr-
> sabata-psabata-contyk/


3 out of 5 candidates as most important feature which seems they want to
push forward encircles Modularity.
Doesn't matter that rpm never been designed in mind to handle cohabitation
packages in different variants.
What now Modularity offers is +1.5y behind original schedule and still in
most of the cases it does not work.
No one points on things like discussion on:
- common specs coding style
- cutting number of %iffings (and use instead SCM branches which git offers)
- cutting legacy tails like still using tons of scriptlets which can be
easily cleaned of remove dependencies on initscripts and maaany more like
this which could make at least @core solid fundamentals other features
- cutting number of dependencies (how many years ago was first discussion
about use --as-needed in linker options?)
- caring about quite basic security (look decision about add ~/.local/bin
to the $PATH and complete kind of "desinteressement" about remove
/usr/local/{bin,sbin} from already used $PATH which widely opens hell gates
for malwares).

Second most important goal on which candidates are focused is how internal
Fedora infrastructure works.

No one of the candidates seems is aware that people are leaving Fedora boat
(look on distrowatch.com or
https://w3techs.com/technologies/details/os-linux/all/all and few other
similars stats) not because Modularity still doesn't work (and will never
work as no one will not change some fundamental bits in rpm). Most of the
candidates seems are completely unaware that end users of they work (binary
packages) simple don't care about how all Fedora stuff is build but HOW IT
WORKS.

On top of this more and more decisions in Fedora seems are made in less and
less transparent and well technically justified way.

Personally I don't see any GoodEnough(tm) candidate on which I can vote ..
candidate with descent own expertise of what is now Fedora Achilles heel ..
sad :(

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NAYDBONKLTQWVUE6BZHOGYJFGYWXPCAH/

Re: equivalent of Debian config-package?

[Dave Love]

Neal Gompa  writes:

> The reason Ansible is used is because we have no current equivalent
> facilities to do delayed script execution or diversion of
> configuration files. Both are functions required for Debian-style
> configuration packages. Feel free to file an issue with rpm upstream[1]
> to figure out a good way to support configuration packages if you want it.

OK, thanks, though it sounds as if there's enough in recent rpm to
kludge it, and it's not likely to get much interest.

> On the flip side, because these facilities haven't existed for so long
> and the RPM ecosystem largely rejected interactive script hooks in
> RPMs, most packages ship with "working defaults" and are trivially
> reconfigurable through external automation tools, which is why mass
> provisioning and configuration management systems work so well for RPM
> based systems.

OK, but the application isn't specifically mass provisioning and
configuration.  It needs to be applicable to somewhat-random,
more-or-less autonomous existing installations which are already
expected to pull (rather problematically-written) packages from a
"local" repository.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7NL6ZKIP6LHCHB6XHXH5BKLC5CLIVKCG/

Re: equivalent of Debian config-package?

[Dave Love]

devzero2000  writes:

> Il gio 31 mag 2018, 13:42 Neal Gompa  ha scritto:
>
>> On Thu, May 31, 2018 at 6:54 AM Dave Love 
>> wrote:
>> >
>> > Is there any existing system for rpm like the Debian one
>> >  for building local
>> > configuration packages?  If not, would it be feasible to implement one?
>>
>> No such thing currently exists, because an equivalent to `dpkg-divert`
>> does not exist in RPM.
>>
>> It is technically possible to implement such a mechanism, but it does
>> not exist right now.
>>
>> A toy WIP never completed is here :
>>
>
> https://github.com/yersinia/rpm-gen-rpm-configuration

Thanks, though it doesn't look as if it would do what I was after.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2G7PRQGFKNJGZPCXWX4VOQSJ7V6USDY2/

Re: equivalent of Debian config-package?

[Dave Love]

Stephen John Smoogen  writes:

> 1. Do not strip out who you are replying to. There are hundreds of
> people on this list and people come in at different times... and I am
> not sure who "You" was.

Apologies, it was a mistake due to Gnus configuration and replying
through Gmane; I understand mail lists.

> 2. Saying that Fedora/RH isn't interested by 1-2 comments is like me
> walking into Debian lists getting 1 person saying "noone would ever
> use Ansible" and assuming they speak for all of Debian.

I was responding to the project leader commenting on the Fedora answer,
but I put it too strongly while suffering from a strong virus.

> 4. System administration/configuration management is 99% "I have a
> solution I endure and I don't have time to re-engineer it." and 1% "Oh
> I think I want to write my own configuration management toolkit
> because I can't endure what I am doing now." You are going to get
> pushback from any site you are proposing this to until you show it is
> useful for them.

I'm not convinced I need Unix system management explaining after so
long, or how my department works.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/S54D5F776JQ4GG6T5BYDHJ34OOATVALH/

Re: equivalent of Debian config-package?

[Dave Love]

Josh Boyer  writes:

>> I guess we disagree about what the problem is, but it's unfortunate if
>> Fedora/RH isn't interested in the sort of environment for which
>> config-package was developed.
>
> Can you elaborate more on what that environment is?

A fairly large university (not as big as MIT) with on-campus and
off-campus systems, already installed or not, and centrally-managed or
not..

> I read the
> website you linked to, but I still don't understand how this wouldn't
> be similarly solved with Ansible.

Doubtless it could be done with Ansible, but than you have to bootstrap
and maintain Ansible as well as the rest of it, and worry about a
competing Ansible on some centrally-managed systems.

[If I was managing a bunch of centrally-managed on-campus systems like
teaching "clusters", I'd just use a stateless image, as for an HPC
cluster, and as used to work on such systems with ~zero resources other
than AFS knowledge.]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3LBAZWXDE2W4MFDK43BQL2IMKOAOMN2R/

[Bug 1588602] xsnow is a component on the Fedora product in bugzilla.redhat.com

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 CC|perl-devel@lists.fedoraproj |ppi...@redhat.com
   |ect.org |



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/G4VVCZOOPSLGAMNTTFLKKR47GFSR6HKG/

[Bug 1588602] xsnow is a component on the Fedora product in bugzilla.redhat.com

[bugzilla]

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



--- Comment #3 from jamie  ---
Thank you :).

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/FET4XTF4HGQ5IXUEEE62S2EKOPXVW5X2/

[Bug 1588602] xsnow is a component on the Fedora product in bugzilla.redhat.com

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 CC||kh...@redhat.com,
   ||qg...@redhat.com
  Component|bugzilla|Creating/Changing Bugs
Version|27  |4.4
   Assignee|ita...@ispbrasil.com.br |hss-ied-b...@redhat.com
Product|Fedora  |Bugzilla
Summary|xsnow is a  |xsnow is a component on the
   |competent(bugzilla.redhat.c |Fedora product in
   |om) |bugzilla.redhat.com
 QA Contact|extras...@fedoraproject.org |tools-b...@redhat.com



--- Comment #2 from Emmanuel Seyman  ---
> I am trying to report a bug with this Bugzilla, if this is not the right 
> place for this, please inform me and I will bring this there. 

Close. Bugs in bugzilla.redhat.com should be filed against the 'Bugzilla'
product. Moving this bug there...

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/J2RXKHATEAVXQIBZIPLLL5IE6POFYHHF/

[Bug 1588602] xsnow is a competent(bugzilla.redhat.com)

[bugzilla]

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



--- Comment #1 from jamie  ---
'Ngo Than' says xsnow is part of Fedora but rpmfusion. For more info read here:
https://bugzilla.redhat.com/show_bug.cgi?id=1526669.

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/KYT7EHWTIGMF6LMSBM2KT2PEBYDPMYZP/

[Bug 1588602] New: xsnow is a competent(bugzilla.redhat.com)

[bugzilla]

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

Bug ID: 1588602
   Summary: xsnow is a competent(bugzilla.redhat.com)
   Product: Fedora
   Version: 27
 Component: bugzilla
  Severity: low
  Assignee: ita...@ispbrasil.com.br
  Reporter: jamie.march...@sympatico.ca
QA Contact: extras...@fedoraproject.org
CC: bazanlui...@gmail.com, emman...@seyman.fr,
ita...@ispbrasil.com.br,
perl-devel@lists.fedoraproject.org



I am trying to report a bug with this Bugzilla, if this is not the right place
for this, please inform me and I will bring this there. 

Description of problem:
xnsow is a 'Component' 

Version-Release number of selected component (if applicable):
I don't know. 

How reproducible:
It is always true 

Steps to Reproduce:
1. Select 'xsnow' from the 'component' dropdown. 
2.
3.

Actual results:
Xsnow should not be on the list, according to too 'Ngo Than' 

Expected results:
It is on the list. 

Additional info:
Read my note at the top.

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/MOUS2IXHNZVV2Z5MYRRUIQGWE6YIDOPY/

Re: F29 Self Contained Change: User PATH Prioritization

[mcatanzaro]

On Thu, Jun 7, 2018 at 4:59 AM, Zbigniew Jędrzejewski-Szmek 
 wrote:

I'm pretty sure ~/bin should be moved too. All the same considerations
apply to ~/bin as to ~/.local/bin, and having one at the beginning and
one at the end would be rather strange.


Yes, surely it makes no sense to change one but not the other. Thanks 
for pointing this out, Zbigniew.


Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PUXMP6ZPEKACSCQ7AXECPE4SJOR3VY2K/

[Bug 1588542] New: Useless dependency on perl(Test::Perl::Critic)

[bugzilla]

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

Bug ID: 1588542
   Summary: Useless dependency on perl(Test::Perl::Critic)
   Product: Fedora
   Version: rawhide
 Component: perl-XML-TreeBuilder
  Assignee: rland...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jfe...@redhat.com, perl-devel@lists.fedoraproject.org,
rland...@redhat.com



Created attachment 1448729
  --> https://bugzilla.redhat.com/attachment.cgi?id=1448729=edit
Proposed fix

perl-XML-TreeBuilder does not execute author's tests at build time, thus
modules like Test::Perl::Critic are not used and they should not be listed as
build-requires.

Attached patch fixes the list of dependencies.

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/4T5IZLHRA4M4EHVCJNTTRKCV76KJSQT5/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

[Stephen John Smoogen]

On 7 June 2018 at 09:07, Michal Schorm  wrote:
> On Thu, Jun 7, 2018 at 2:41 PM, Richard Shaw  wrote:
>>
>> On Thu, Jun 7, 2018 at 4:51 AM Michal Schorm  wrote:
>>>
>>> Can someone explain me *real quick* what is the multilib good for? - or
>>> more precisely, why whould anone run 32-bit software on x86_64 OS?
>>
>> In my case, there are a couple of games that are either older, or just not
>> provided in 64bit so I need a few 32bit libraries in order for the kids to
>> play them.
>
>
> That's what the SRPMs are good aren't hey?
> Shouldn't be much trouble to recompile them fo x86_64.
> Or run the apps / games in virtualized environment. (Not something I'd do
> with latest games, but for sokoban from 1986 shouldn't run into performance
> problems :) )
>
> Am I right?
>
> ( I'm not trying to argue. Just to understand the reasons properly. )

Going outside the entertainment, schools which use Fedora are usually
tied to some 10+ year old 32 bit software that they need for an
engineering project.. but it is also tied with a newer 64 bit
application. While it isn't a Fedora thing, many payroll and finance
systems are a similar mixture of 32 bit old apps and 64 bit new ones.
This means that our downstream (RHEL) has a vested interested in
making sure that works so puts people on it to figure it out.

Software is like words. Language smiths like to spend time and come up
with new words which mean exactly what they are wanting to do. The
people actually needing something done, tend to just stick several
words together and get on with their lives.

>
> --
>
> Michal Schorm
> Associate Software Engineer
> Core Services - Databases Team
> Red Hat
>
> On Thu, Jun 7, 2018 at 2:41 PM, Richard Shaw  wrote:
>>
>> On Thu, Jun 7, 2018 at 4:51 AM Michal Schorm  wrote:
>>>
>>> Can someone explain me *real quick* what is the multilib good for? - or
>>> more precisely, why whould anone run 32-bit software on x86_64 OS?
>>
>>
>> In my case, there are a couple of games that are either older, or just not
>> provided in 64bit so I need a few 32bit libraries in order for the kids to
>> play them.
>>
>> 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://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Z4SWOROXAIRLSPKL7WZHWUAQJZSCPW7I/
>>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FB62VQV5X2DRG6LVKGW663JDNA6HSBPQ/
>



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5WTKQGYMB3CVOGHWDWSRJGFX4XSXHHAM/

Re: /etc/profile.d/lang.sh -- still needed?

[Jan Pokorný]

On 14/05/18 17:19 +0200, David Kaspar [Dee'Kej] wrote:
> does anybody know if the files /etc/profile.d/lang.{csh,sh}
> are still used these days, and what for?
> Do we still need them in Fedora?
> Should they be installed by default these days?
> 
> Any info is appreciated! :)

Frankly, had no idea about that file but apparently it's needed (or
something to that effect) so as to have non-ascii characters rendered
correctly in the terminal-within-WM settings (sway + urxvt256c-ml).
I am not sure what the cause was, could be just missing
LANG=en_US.UTF-8 in the environment -- no idea what's the
intended authoritative "automagic" source for that otherwise.
Or does it mean one shouldn't trust the distribution for
this common convenience anymore?

Please be more considerate even to Rawhide package consumers next time
around and coordinate file migrations between packages properly.
I can see that these files were moved to setup package, but alas,
that hasn't been rebuilt yet.  Perhaps versioned dependency or even
path-based one would be justified in this case to prevent unexpected
regressions.

-- 
Poki


pgpyas6nvH69Q.pgp
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YRYWSUCNRO3C2CYZW5FJFAW3ZQ7NEMJ4/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

[Richard Shaw]

On Thu, Jun 7, 2018 at 8:17 AM Richard Shaw  wrote:

> The other is The Dark Mod, which is open source but they're still using
> the DOOM 3 graphics engine IIRC and their buildsystem which is still 32bit
> only.
>

HAH! Writing this caused me to google it and apparently with the latest
release there is now a 64bit version. Haven't downloaded or tested yet, but
that's one less reason.

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/A5R4TNDFG27DHO3OXDLTB7E4VLIQB6EB/

Re: F29 System Wide Change: i686 Is For x86-64

[Josh Boyer]

On Thu, Jun 7, 2018 at 6:19 AM Jan Pazdziora  wrote:
>
> On Mon, Jun 04, 2018 at 10:35:34AM +0200, Jan Kurik wrote:
> > = Proposed System Wide Change: i686 Is For x86-64 =
> > https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64
> >
> >
> > Owner(s):
> >   * Florian Weimer 
> >
> >
> > Fedora builds its i686 packages for use on x86-64 systems as multi-lib RPMs.
> >
> >
> >
> > == Detailed description ==
> > Currently, the i686 RPM packages are built in such a way that they are
> > compatible with very old i686 systems, such as the Pentium III.  The
> > only addition over the i686/Pentium Pro baseline is a requirement to
> > support long NOPs, for Intel CET.  However, the majority of
> > installations of i686 packages is for use on x86_64 systems, as
> > multi-lib RPMs.  Furthermore, there are reports that the i686 kernel
> > does not run stable on old hardware which is not x86-64-capable (
> > https://lists.fedoraproject.org/archives/list/x...@lists.fedoraproject.org/thread/ZHV6I4IEO7GRYAZ4TUMO5VH2ZHLCNJZQ/
> > ).
> > This proposal suggests to accept this reality and build the i686
> > packages in such a way that they require the ISA level of (early)
> > x86-64 CPUs.
> >
> >
> > == Scope ==
> > * Proposal owners:
> > Adjust the redhat-rpm-config, gcc, and glibc packages to switch to the
> > new compiler flags. Except for mstackrealign, there is substantial
> > experience with this configuration downstream.
> >
> > * Other developers:
> > Other developers can enable SSE2 optimization in their packages if
> > they want, where this has been a compile-time option only.
> >
> > * Release engineering:
> > https://pagure.io/releng/issues/7543 #7543
> >
> > ** List of deliverables: TBD
> >
> > * Policies and guidelines:
> > i686 is no longer a primary architecture. The Packaging Guidelines do
> > not currently require support for non-SSE2 x86 systems, so no change
> > is required there.
>
> Could the title and nature of this proposed change be modified to
>
> Dropping support for non-SSE2 x86 systems
>
> rather than removing i686 from primary architectures and implying that
> we no longer do i686-only distribution? Reading this thread, the
> SSE2/non-SSE2 distinction is where the change is aiming anyway, isn't
> it?

i686 is already no longer a primary architecture.  We do not block
releases on i686-only issues, which is the only distinction "primary"
has these days.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2DIXN64HYE23JHNV3IICMEIBIBBTZJVN/

[Bug 1588216] perl-CPAN-Perl-Releases-3.60 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.60-1.fc28 has been pushed to the Fedora 28 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-2018-5097a314fc

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/PJZ57WTXREV3UQ4M6QZEIJDMGNR2DJQF/

[Bug 1585345] perl-Date-Manip-6.72 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Date-Manip-6.72-1.fc28 has been pushed to the Fedora 28 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-2018-31163f509e

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/3EB3XFQGQV5VXIT6NXHLK3DRCIUYSQIP/

[Bug 1588217] perl-CPANPLUS-0.9176 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-CPANPLUS-0.917.600-1.fc28 has been pushed to the Fedora 28 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-2018-fbc1841618

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/LWV4G22R3F4RMDPTRPZX7CKMU3BN3BR3/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

[Richard Shaw]

On Thu, Jun 7, 2018 at 8:09 AM Michal Schorm  wrote:

> On Thu, Jun 7, 2018 at 2:41 PM, Richard Shaw  wrote:
>
>> On Thu, Jun 7, 2018 at 4:51 AM Michal Schorm  wrote:
>>
>>> Can someone explain me *real quick* what is the multilib good for? - or
>>> more precisely, why whould anone run 32-bit software on x86_64 OS?
>>>
>> In my case, there are a couple of games that are either older, or just
>> not provided in 64bit so I need a few 32bit libraries in order for the kids
>> to play them.
>>
>
> That's what the SRPMs are good aren't hey?
> Shouldn't be much trouble to recompile them fo x86_64.
> Or run the apps / games in virtualized environment. (Not something I'd do
> with latest games, but for sokoban from 1986 shouldn't run into performance
> problems :) )
>
> Am I right?
>

If there was a SRPM available it probably would have already been done :)

One is Neverwinter Nights which they released a 32bit linux binary for, but
obviously not FOSS.

The other is The Dark Mod, which is open source but they're still using the
DOOM 3 graphics engine IIRC and their buildsystem which is still 32bit only.

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BUOVDBQHYDLU5X7RRLH3ZQXD3C7NAOHE/

[Bug 1587982] perl-CPANPLUS-Dist-Build-0.90 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-CPANPLUS-Dist-Build-0.90-1.fc28 has been pushed to the Fedora 28 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-2018-dbcbe02783

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/IZWB7T53XDHKEEZAXRASEKO7MZYNCDFJ/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

[Michal Schorm]

On Thu, Jun 7, 2018 at 2:41 PM, Richard Shaw  wrote:

> On Thu, Jun 7, 2018 at 4:51 AM Michal Schorm  wrote:
>
>> Can someone explain me *real quick* what is the multilib good for? - or
>> more precisely, why whould anone run 32-bit software on x86_64 OS?
>>
> In my case, there are a couple of games that are either older, or just not
> provided in 64bit so I need a few 32bit libraries in order for the kids to
> play them.
>

That's what the SRPMs are good aren't hey?
Shouldn't be much trouble to recompile them fo x86_64.
Or run the apps / games in virtualized environment. (Not something I'd do
with latest games, but for sokoban from 1986 shouldn't run into performance
problems :) )

Am I right?

( I'm not trying to argue. Just to understand the reasons properly. )

--

Michal Schorm
Associate Software Engineer
Core Services - Databases Team
Red Hat

On Thu, Jun 7, 2018 at 2:41 PM, Richard Shaw  wrote:

> On Thu, Jun 7, 2018 at 4:51 AM Michal Schorm  wrote:
>
>> Can someone explain me *real quick* what is the multilib good for? - or
>> more precisely, why whould anone run 32-bit software on x86_64 OS?
>>
>
> In my case, there are a couple of games that are either older, or just not
> provided in 64bit so I need a few 32bit libraries in order for the kids to
> play them.
>
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.
> fedoraproject.org/message/Z4SWOROXAIRLSPKL7WZHWUAQJZSCPW7I/
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FB62VQV5X2DRG6LVKGW663JDNA6HSBPQ/

Re: Elections for Council - May 2018 - Result announcement

[Matthew Miller]

On Thu, Jun 07, 2018 at 04:34:10AM +0200, Jan Kurik wrote:
> The elections for Council - May 2018 [1] have concluded, and the
> results are shown below.

Welcome, Till! And, thank you Nick for your work on the Council over
the last year. I really appreciate the perspective and thoughtfulness
you brought to the role.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NPHL3CNZU5TWUYC7VSKLACVWW3C7MH5R/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Tomas Mraz]

On Tue, 2018-06-05 at 16:34 -0400, John Florian wrote:
> On 06/05/2018 12:25 PM, Tomas Mraz wrote:
> > On Tue, 2018-06-05 at 16:11 +, Christian Stadelmann wrote:
> > > "Fallback option" always smells like "protocol downgrade attack".
> > > This would undermine the idea of a crypto policy. Anyway,
> > > implementing it seems way out of scope for the crypto policy.
> > 
> > Yes, a fallback option is a no-way. You can switch the system
> > policy to
> > LEGACY, however that does not necessarily mean that some very old
> > legacy HW will start to work with Firefox or another web browser,
> > because with newer versions of the browsers and newer versions of
> > TLS/crypto libraries some very old and insecure algorithm and
> > protocol
> > support is being also removed.
> > 
> 
> Makes sense, but what is the best way to deal with such old HW if
> you're 
> stuck with it?  I don't want to compromise my workstation for all my 
> normal needs just to deal with some ancient embedded https server,
> but 
> it would kind of suck to have to boot some old live image just to do 
> some routine config change.  It seems the industry has room for 
> improvement here.

Use a virtual machine with some old live image for such insecure
communication?

I do not think any "improvement" that involves changing the defaults to
be more lenient even if accompanied with some big warning when such old
insecure connection is established would be a good idea. Оnly if the
users really have to boot some old live image or do some similar
unpleasant task it will really force the old HW out of production where
it should belong. Or we can forget about security based on
cryptographic protocols altogether.

Note that we are talking about SSLv2, MD4 or similar long long time ago
obsolete stuff. Not things that were just "recently" found as insecure.
-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QJRRPYEIHGADBY3U6I3OPGZD7JY733XV/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

[Richard Shaw]

On Thu, Jun 7, 2018 at 4:51 AM Michal Schorm  wrote:

> Can someone explain me *real quick* what is the multilib good for? - or
> more precisely, why whould anone run 32-bit software on x86_64 OS?
>

In my case, there are a couple of games that are either older, or just not
provided in 64bit so I need a few 32bit libraries in order for the kids to
play them.

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Z4SWOROXAIRLSPKL7WZHWUAQJZSCPW7I/

fwupd license change

[Richard Hughes]

Hi all,

Just a small unimportant notice that I'm required to do: fwupd changed
license from "GPLv2+ AND LGPLv2+" to just "LGPLv2+". The library was
always the LGPL bit, so this doesn't affect any other things linking
to libfwupd.

Richard.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/63XDYX74R73YLX6CMYI4RPCTVEEJLFZU/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Tomas Mraz]

On Wed, 2018-06-06 at 12:05 +, Petr Pisar wrote:
> On 2018-06-05, John Florian  wrote:
> > Makes sense, but what is the best way to deal with such old HW if
> > you're 
> > stuck with it?  I don't want to compromise my workstation for all
> > my 
> > normal needs just to deal with some ancient embedded https server,
> > but 
> > it would kind of suck to have to boot some old live image just to
> > do 
> > some routine config change.  It seems the industry has room for 
> > improvement here.
> 
> Firefox has a white list for domain names:
> security.tls.insecure_fallback_hosts.

I do not think this actually works at all even with the current FF and
Fedora.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TQIQG62DVHQMIVTGTSVEJN2ILC67JN7V/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Tomas Mraz]

On Tue, 2018-06-05 at 11:54 -0500, mcatanz...@gnome.org wrote:
> On Fri, Jun 1, 2018 at 6:40 AM, Jan Kurik  wrote:
> > and weak
> > Diffie-Hellman key exchange sizes (1024 bit)
> 
> What size is currently required by upstream Firefox and Chrome?
> 
> The most recent reference I could find is 
> https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/W
> yGIpevBV1s 
> which suggests they are still using 1024.

Yes, they are using 1024 bits as minimum now.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FY6FMRZPQMSDOSZADTOAIWD4VPXVCANW/

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  60  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-5aca1d385d   
remctl-3.14-1.el6
  57  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-dd6e4a3f0b   
python34-3.4.8-1.el6
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-fca9555db1   
cobbler-2.6.11-7.git95749a6.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-1ceee884b4   
prosody-0.10.2-1.el6


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

python-regex-2018.06.06-1.el6
singularity-2.5.1-1.el6

Details about builds:



 python-regex-2018.06.06-1.el6 (FEDORA-EPEL-2018-b3eeed24fc)
 Alternative regular expression module, to replace re

Update Information:

Update to the latest released version.

ChangeLog:

* Wed Jun  6 2018 Thomas Moschny  - 2018.06.06-1
- Update to 2018.06.06.




 singularity-2.5.1-1.el6 (FEDORA-EPEL-2018-029b32bcf4)
 Application and environment virtualization

Update Information:

This rebases singularity from 2.2.1 to 2.5.1, which should include all
corresponding updates (n.b. a request for rebase permission has been put into
FESCo; hence auto-push has been disabled until they approve).  Please test for
functionality and backward compatibility issues, particularly around the runtime
components.

ChangeLog:

* Fri May  4 2018 Dave Dykstra  - 2.5.1-1
- Update to upstream version 2.5.1
* Fri Apr 27 2018 Dave Dykstra  - 2.5.0-1
- Update to upstream version 2.5.0
* Mon Apr 16 2018 Dave Dykstra  - 2.4.6-1
- Update to upstream version 2.4.6

References:

  [ 1 ] Bug #1585620 - singularity: Multiple security vulnerabilities fixed in 
2.5.0 [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1585620
  [ 2 ] Bug #1585619 - singularity: Multiple security vulnerabilities fixed in 
2.5.0 [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1585619
  [ 3 ] Bug #1452572 - singularity: Switch to Python 3
https://bugzilla.redhat.com/show_bug.cgi?id=1452572
  [ 4 ] Bug #1457856 - singularity-2.5.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1457856

___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/JXYSM377LZKR3RYOYUVZ7OIDNYR5G6AC/

[Bug 1588216] perl-CPAN-Perl-Releases-3.60 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.60-1.fc27 has been pushed to the Fedora 27 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-2018-4baa5782c3

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/3WPHSUFNA3Y4S4OGFOTQRDH536UUCUG4/

[Bug 1588217] perl-CPANPLUS-0.9176 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-CPANPLUS-0.917.600-1.fc27 has been pushed to the Fedora 27 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-2018-5cf59516c6

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/JI6N6RGRHV25IE3VLF2GRZOBUXQFPRWO/

[Bug 1587982] perl-CPANPLUS-Dist-Build-0.90 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-CPANPLUS-Dist-Build-0.90-1.fc27 has been pushed to the Fedora 27 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-2018-1c841646c0

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/FM4ZQHL6US2KSTHVUF32Y7DC4QSA3BAU/

Re: Detecting building package on rawhide

[Miroslav Suchý]

Dne 6.6.2018 v 14:24 Jan Pazdziora napsal(a):
> What would people recommend to distinguish rawhide from non-rawhide?
> For now I'm running the builds in copr but eventually I'd like for
> it to work in koji as well.

There is nothing I can recommend. But if you asked for a hack...:

 * if /etc/yum.repos.d/fedora-rawhide.repo exists, it is rawhide
 * else if grep 'enabled=1' /etc/yum.repos.d/fedora-updates-testing.repo then 
it is branched rawhide (F29) which was not
released yet. When there is a release this repo is disabled.

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/D7OFEIU7PDXPH3OOKHPM4A2HELKIV4QF/

Re: F29 Self Contained Change: User PATH Prioritization

[Miro Hrončok]

On 7.6.2018 11:59, Zbigniew Jędrzejewski-Szmek wrote:

Currently if user is installing his own tools with installers like


s/his/their/g


done



There should be '''no security concerns''' due to this change because
any user is already able to add executables and to alter its own PATH,


s/its/their/


done


(Note that whether we move $HOME/bin or not has not yet been decided.)
Note that this change will only affect new user accounts, we cannot
change PATH for already existing accounts without crazy and undesired
hacks.


I'm pretty sure ~/bin should be moved too. All the same considerations
apply to ~/bin as to ~/.local/bin, and having one at the beginning and
one at the end would be rather strange.


done

--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WLCIMDENEOAASHKD2D36D47KMFGZHBXT/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

[Tom Hughes]

Because sometimes the software I'm developing needs to link with
a proprietary library that is only available as 32 bit library.

It's a lot rarer than it used to be but there are still a few
databases that I work with that don't have 64 bit libraries.

Or indeed just because our customers want a 32 bit version of
our software so we have to be able to build and test it, though
we're on the verge of trying to drop most 32 bit support now.

Tom

On 07/06/18 10:50, Michal Schorm wrote:
Can someone explain me *real quick* what is the multilib good for? - or 
more precisely, why whould anone run 32-bit software on x86_64 OS?


 From what I googled, it look like everyone does it yet nobody explains 
why :D


--

Michal Schorm
Associate Software Engineer
Core Services - Databases Team
Red Hat

On Wed, Jun 6, 2018 at 8:09 PM, Florian Weimer > wrote:


On 06/04/2018 06:55 PM, Jeff Backus wrote:

Thanks for the insight. Yes, I can see the advantages. However,
have things really gotten so bad that it justifies ejecting part
of the community?


The cost of i686 support is not insignificant.  Most of that happens
upstream (like features only getting accepted when there's an
i386/i686 implementation).  There's little we can do about that, but:

In fedora, we are also a point of contact for weird bugs which
someone needs to triage.  I really don't want to do that, but due to
the lack of secondary architectures, I'm often forced to because
i686 breakage brings development on architectures which I actually
care about to a halt.

I can justify this work if it helps downstream (so that we can be
confident that customers will be able to run their legacy software
going forward).  But with the current divergence in build flags, it
is fairly questionable whether my work can deliver such a benefit,
and that is frustrating.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org

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

Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html

List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines

List Archives:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SJ57YLA5XHOYJAAZR3RZBSOPOR4KEO53/






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




--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QFRPSYOVWJS7IZ3PRXV2NYU6F5MVWA65/

Re: F29 System Wide Change: i686 Is For x86-64

[Jan Pazdziora]

On Mon, Jun 04, 2018 at 10:35:34AM +0200, Jan Kurik wrote:
> = Proposed System Wide Change: i686 Is For x86-64 =
> https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64
> 
> 
> Owner(s):
>   * Florian Weimer 
> 
> 
> Fedora builds its i686 packages for use on x86-64 systems as multi-lib RPMs.
> 
> 
> 
> == Detailed description ==
> Currently, the i686 RPM packages are built in such a way that they are
> compatible with very old i686 systems, such as the Pentium III.  The
> only addition over the i686/Pentium Pro baseline is a requirement to
> support long NOPs, for Intel CET.  However, the majority of
> installations of i686 packages is for use on x86_64 systems, as
> multi-lib RPMs.  Furthermore, there are reports that the i686 kernel
> does not run stable on old hardware which is not x86-64-capable (
> https://lists.fedoraproject.org/archives/list/x...@lists.fedoraproject.org/thread/ZHV6I4IEO7GRYAZ4TUMO5VH2ZHLCNJZQ/
> ).
> This proposal suggests to accept this reality and build the i686
> packages in such a way that they require the ISA level of (early)
> x86-64 CPUs.
> 
> 
> == Scope ==
> * Proposal owners:
> Adjust the redhat-rpm-config, gcc, and glibc packages to switch to the
> new compiler flags. Except for mstackrealign, there is substantial
> experience with this configuration downstream.
> 
> * Other developers:
> Other developers can enable SSE2 optimization in their packages if
> they want, where this has been a compile-time option only.
> 
> * Release engineering:
> https://pagure.io/releng/issues/7543 #7543
> 
> ** List of deliverables: TBD
> 
> * Policies and guidelines:
> i686 is no longer a primary architecture. The Packaging Guidelines do
> not currently require support for non-SSE2 x86 systems, so no change
> is required there.

Could the title and nature of this proposed change be modified to

Dropping support for non-SSE2 x86 systems

rather than removing i686 from primary architectures and implying that
we no longer do i686-only distribution? Reading this thread, the
SSE2/non-SSE2 distinction is where the change is aiming anyway, isn't
it?

-- 
Jan Pazdziora
Senior Principal Software Engineer, Security Engineering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5G4KWIBDQ25V6XLR4NIUXOST3D7B2SVH/

Re: Detecting building package on rawhide

[Jan Pazdziora]

On Wed, Jun 06, 2018 at 02:48:25PM +0200, Florian Weimer wrote:
> On 06/06/2018 02:24 PM, Jan Pazdziora wrote:
> > Checking rpm --showrc, I can see rawhide sets %{fedora} to 29 and
> > there does not seem any mention of rawhide in the showrc output.
> > 
> > What would people recommend to distinguish rawhide from non-rawhide?
> 
> The mass rebuild, if there is any, happens before rawhide turns into
> non-rawhide, so there is simply no distinction whatsoever, and there cannot
> be.

OK, thanks.

-- 
Jan Pazdziora
Senior Principal Software Engineer, Security Engineering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/O2IYAYDCJEQJTLSDV5UG6CBWHWS65ESU/

Re: F29 Self Contained Change: User PATH Prioritization

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jun 07, 2018 at 11:08:55AM +0200, Jan Kurik wrote:
> = Proposed Self Contained Change: User PATH Prioritization =
> https://fedoraproject.org/wiki/Changes/UserPathPrioritization
> 
> 
> Owner(s):
>   * Sorin Sbarnea 
>   * Till Maas 
>   * Miro Hrončok 
> 
> 
> Changing user PATH '''~/.local/bin''' to be moved to the top of the
> PATH list instead of the end. This will bring Fedora in sync with
> other distributions which already fixed this issues (Debian/Ubuntu)
> and will allow users to install and use their own command line tools,
> also fixing multiple bugs where user installed tools cannot be
> accessed because the system installed ones took precedence.

"allow" is not the right word here. What about "make it easier to"?
> 
> == Detailed description ==
> Currently if user is installing his own tools with installers like

s/his/their/g

> (pip), they will be installed inside ~/.local/bin but if the same CLI
> tools are installed at system level the user would not be able to use
> his own tools because the system one would be picked instead. This
> happens because .bashrc file adds user PATH to the end instead of the
> top of PATH list variable.
> Same problem was happening with other distributions but they fixed it
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839155 Debian bug)
> Example: "pip install --user virtualenv" would install virtualenv at
> user level, adding ~/.local/bin/virtualenv executable. Still, if
> virtualenv happens to be installed at system level, this would
> currently be used instead of user installed one. On the other hand,
> python itself already knows to prefer user installed modules which
> means that "python -m virtualenv" will call user installed module
> instead of the system one.
> This may result in undefined behavior, where user installs foo, than
> run foo, but /usr/bin/foo is run and that import from Python modules
> in home. Those modules might have different API.
> If we change the order and to assure the user folders do take
> precedence, we would assure that python modules and shell scripts
> would use the same modules, avoiding weird bugs where what you call is
> not what you installed.
> The issue is not unique to pip installed and applies to any tools that
> are installed in de facto default XDG folder locations.
> There should be '''no security concerns''' due to this change because
> any user is already able to add executables and to alter its own PATH,

s/its/their/

> which means that if someone wants to trick a user to use another
> executable, they are already able to do that. This has already been
> proved several times in the
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/OXXC5NOZP37W2F6GHV6P5E6K22QHOBNJ/
> initial discussions about this change.
> The change itself technically is in /etc/skel/.bash_profile from bash.
> Currently:
> PATH=$PATH:$HOME/.local/bin:$HOME/bin
> After the change:
> PATH=$HOME/.local/bin:$HOME/bin:$PATH
> (Note that whether we move $HOME/bin or not has not yet been decided.)
> Note that this change will only affect new user accounts, we cannot
> change PATH for already existing accounts without crazy and undesired
> hacks.

I'm pretty sure ~/bin should be moved too. All the same considerations
apply to ~/bin as to ~/.local/bin, and having one at the beginning and
one at the end would be rather strange.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZS2SC2VMSGIHJWWKK3SREJDXTTPZBN5E/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

[Michal Schorm]

Can someone explain me *real quick* what is the multilib good for? - or
more precisely, why whould anone run 32-bit software on x86_64 OS?

>From what I googled, it look like everyone does it yet nobody explains why
:D

--

Michal Schorm
Associate Software Engineer
Core Services - Databases Team
Red Hat

On Wed, Jun 6, 2018 at 8:09 PM, Florian Weimer  wrote:

> On 06/04/2018 06:55 PM, Jeff Backus wrote:
>
> Thanks for the insight. Yes, I can see the advantages. However, have
>> things really gotten so bad that it justifies ejecting part of the
>> community?
>>
>
> The cost of i686 support is not insignificant.  Most of that happens
> upstream (like features only getting accepted when there's an i386/i686
> implementation).  There's little we can do about that, but:
>
> In fedora, we are also a point of contact for weird bugs which someone
> needs to triage.  I really don't want to do that, but due to the lack of
> secondary architectures, I'm often forced to because i686 breakage brings
> development on architectures which I actually care about to a halt.
>
> I can justify this work if it helps downstream (so that we can be
> confident that customers will be able to run their legacy software going
> forward).  But with the current divergence in build flags, it is fairly
> questionable whether my work can deliver such a benefit, and that is
> frustrating.
>
> Thanks,
> Florian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.or
> g/archives/list/devel@lists.fedoraproject.org/message/SJ57YL
> A5XHOYJAAZR3RZBSOPOR4KEO53/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FDDNDJI2ONZXFCSA7QQLOSFBBPO34GHZ/

F29 Self Contained Change: User PATH Prioritization

[Jan Kurik]

= Proposed Self Contained Change: User PATH Prioritization =
https://fedoraproject.org/wiki/Changes/UserPathPrioritization


Owner(s):
  * Sorin Sbarnea 
  * Till Maas 
  * Miro Hrončok 


Changing user PATH '''~/.local/bin''' to be moved to the top of the
PATH list instead of the end. This will bring Fedora in sync with
other distributions which already fixed this issues (Debian/Ubuntu)
and will allow users to install and use their own command line tools,
also fixing multiple bugs where user installed tools cannot be
accessed because the system installed ones took precedence.



== Detailed description ==
Currently if user is installing his own tools with installers like
(pip), they will be installed inside ~/.local/bin but if the same CLI
tools are installed at system level the user would not be able to use
his own tools because the system one would be picked instead. This
happens because .bashrc file adds user PATH to the end instead of the
top of PATH list variable.
Same problem was happening with other distributions but they fixed it
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839155 Debian bug)
Example: "pip install --user virtualenv" would install virtualenv at
user level, adding ~/.local/bin/virtualenv executable. Still, if
virtualenv happens to be installed at system level, this would
currently be used instead of user installed one. On the other hand,
python itself already knows to prefer user installed modules which
means that "python -m virtualenv" will call user installed module
instead of the system one.
This may result in undefined behavior, where user installs foo, than
run foo, but /usr/bin/foo is run and that import from Python modules
in home. Those modules might have different API.
If we change the order and to assure the user folders do take
precedence, we would assure that python modules and shell scripts
would use the same modules, avoiding weird bugs where what you call is
not what you installed.
The issue is not unique to pip installed and applies to any tools that
are installed in de facto default XDG folder locations.
There should be '''no security concerns''' due to this change because
any user is already able to add executables and to alter its own PATH,
which means that if someone wants to trick a user to use another
executable, they are already able to do that. This has already been
proved several times in the
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/OXXC5NOZP37W2F6GHV6P5E6K22QHOBNJ/
initial discussions about this change.
The change itself technically is in /etc/skel/.bash_profile from bash.
Currently:
PATH=$PATH:$HOME/.local/bin:$HOME/bin
After the change:
PATH=$HOME/.local/bin:$HOME/bin:$PATH
(Note that whether we move $HOME/bin or not has not yet been decided.)
Note that this change will only affect new user accounts, we cannot
change PATH for already existing accounts without crazy and undesired
hacks.



== Scope ==
* Proposal owners:
change /etc/skel/.bash_profile to have local folders before the system
ones in default PATH

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

* Release engineering:
https://pagure.io/releng/issue/7554 #7554

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

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

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/C3FCEWZR42MWLZQWFKDRS75F3OSOBB3K/

Re: F29 System Wide Change: Hide the grub menu

[Hans de Goede]

Hi,

On 04-06-18 21:17, Adam Williamson wrote:

On Thu, 2018-05-31 at 12:43 +0200, Jan Kurik wrote:

= Proposed System Wide Change: Hide the grub menu =
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu


We (QA) would like to note that the "How to test" section of this
Change seems heavily under-developed:

"1. Install Fedora in a fresh vm or select reclaim diskspace -> delete
all in the installer (od a single os install).
2. Boot the system the grub menu should not show
3. (Re)boot press F8 repeatedly when the firmware / vendor logo shows,
you should now get the grub menu"

I mean, that doesn't even consider testing that the change is *not*
applied when doing a "multi OS" install, which is explicitly part of
the Change. As a *bare minimum*, that needs to be covered.


You are completely right. I've updated the wiki page:
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu

To reflect all the discussed changes (Workstation only, only hide the
menu after a boot which sets the boot + shutdown success flags,
make it easier to unhide the menu) and I've updated.

And I've updated the test plan both to reflect the discussed changes
and to address your concerns.


It also doesn't cover other situations. One brought up at our QA
meeting was - what happens if you install Fedora first and then another
Linux distribution second?

The Change as a whole doesn't seem to consider what should happen in
this case, which seems like an omission; obviously if there *is* an
expected outcome in this case, the "How to test" section should cover
testing it.


The outcome will depend on how grub2-mkconfig's detects this, assuming
it correctly detects this other Linux as another OS then the auto-hide
feature will be disabled. Note that if Fedora's grub is to be used
after installing another Linux then grub2-mkconfig needs to be re-run
to get menu entries for the new Linux. So this is a scenario which
will always require manual setup. At which point manually calling:

sudo grub2-editenv - unset menu_auto_hide

To disable the auto-hide feature should not be a problem. Note that
as Peter suggested the feature is now controlled by an environment
variable, so it can be easily turned on/off by doing:

sudo grub2-editenv - set menu_auto_hide=1
sudo grub2-editenv - unset menu_auto_hide

Without needing to generate grub.cfg (and potentially loosing
manual changes there).

We do need to document this properly. As said before, I promise
I will write docs for this once things have settled a bit.

A question to you (and the Fedora community in general) where
should the documentation for this live ? I would like to have
something longer lived then the Changes wiki page or the
release notes.

Regards,

Hans
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AWJZRRO37DXQGSOB3EPCK3J7K5JZRSB4/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Miro Hrončok]

On 7.6.2018 10:37, Miro Hrončok wrote:

On 7.6.2018 10:21, Sorin Sbarnea wrote:
Now that we have a change proposal, how to continue? To get it 
accepted or rejected, is there a way/process that we need to follow?


Mark the change ready for wrangler.


I've just did.

--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YHNSK7ZUTGBJW5HDHX63HV2FMR4TUE6M/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Miro Hrončok]

On 7.6.2018 10:21, Sorin Sbarnea wrote:

Now that we have a change proposal, how to continue? To get it accepted or 
rejected, is there a way/process that we need to follow?


Mark the change ready for wrangler.

--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/G35X7MP6V4D5P6274DVUMHPOE5TYRXZK/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Sorin Sbarnea]

Well said, there is no catchy name for this (virtual) security threat. We will 
have to let one of those that oppose this proposal to find a caching name 
(PATHEXIT?), maybe even build a paper explaining how to mitigate it.

I am bit disappointed because other distributions fixed it, even twice after a 
temporary regression due to a mistake. We never did it.

Now that we have a change proposal, how to continue? To get it accepted or 
rejected, is there a way/process that we need to follow?

Should we maybe add a section to the document with supporters and opposers 
where people can record themselves?

Thanks
Sorin


signature.asc
Description: Message signed with OpenPGP
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VXFYSGI372TMRE5YRATKR4SKV4LXOMDV/

[Bug 1588216] perl-CPAN-Perl-Releases-3.60 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.60-1.fc27 has been submitted as an update to Fedora
27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-4baa5782c3

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/D7FR2HLR3RKBUEG6P2K6LY6K2MS2T344/

Seek a sponsor for new package : pcb-rnd (PCB layout editor)

[Alain Vigne]

Hi,
I am Alain, a French EE engineer using Fedora 28 and EDA open source tools,
as an hobby.

I am part of the pcb-rnd developer upstream
http://repo.hu/projects/pcb-rnd/
and was able to produce a .spec file + SRPM rpm file, and COPR successful
build:
https://copr.fedorainfracloud.org/coprs/avigne/pcb-rnd/

Now, I am looking for a sponsor to get this package into Fedora. I filled
this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1581240

I volunteer to be the package maintainer, have read the guidelines and
acknowledge responsibilities requested for such a task.
My FAS username is: avigne

This package could also be part of FEL (Fedora Electronic Lab) spin, to be
revived ?

Hoping for some positive feed-back...
Best regards
-- 
Alain V.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IYS7CQZDC4SNALZYKCXNGEAUTJT44HN3/

[Bug 1588216] perl-CPAN-Perl-Releases-3.60 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.60-1.fc28 has been submitted as an update to Fedora
28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-5097a314fc

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/TP5NPN4LM4KX5DZHM7Q52MHRJ2K4GKZE/

[Bug 1588216] perl-CPAN-Perl-Releases-3.60 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-CPAN-Perl-Releases-3.6
   ||0-1.fc29



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/ZGLDM37LGL2HQ7SGKDQFCW3GRCQGJDR5/

[Bug 1588217] perl-CPANPLUS-0.9176 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-CPANPLUS-0.917.600-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-fbc1841618

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/TUHOSGQNRBJQ4CSNDD4ASRYVL2S5XZCU/

[Bug 1588217] perl-CPANPLUS-0.9176 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-CPANPLUS-0.917.600-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-5cf59516c6

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/NCUOGYXDIY3BLIF53OHWHQZ7WDGCQUEI/

[Bug 1585345] perl-Date-Manip-6.72 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Date-Manip-6.72-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-31163f509e

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/GRS3ITEIGLAJ62TA6FKCWXX7DR72AYR5/

[Bug 1588217] perl-CPANPLUS-0.9176 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-CPANPLUS-0.917.600-1.f
   ||c29



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

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

[Bug 1588242] perl-PAR-Packer-1.044 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-PAR-Packer-1.044-1.fc2
   ||9
 Resolution|--- |RAWHIDE
Last Closed||2018-06-07 03:34:59



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/NTQJ64VUVGNPPPM37GUOPDA3X4VOK5EY/