Re: how to replace ssl with ssh2 in kqoauth

[Tomas Mraz]

On Thu, 2017-11-30 at 13:49 +, Martin Gansser wrote:
> Is it possible to compile kQOAuth [1] with ssh2 by using openssl, as
> it always comes to conflict between compat-openssl10 and openssl. 
> I have already searched in the sources of kqoauth for the places
> where ssl is referenced.
> 
> $ grep -r ssl *
> 
> kqoauthutils.cpp:#include 
> kqoauthutils.cpp:#include 
> kqoauthutils.cpp:#include 
> kqoauthutils.cpp:#include 
> kqoauthutils.h:#include 
> Makefile:LIBS  = $(SUBLIBS) -lssl -lcrypto -lQt5Gui
> -lQt5Network -lQt5Core -lGL -lpthread 
> src.pro:LIBS += -lssl -lcrypto
> 
> i tink it isn't enough only to replace -lssl with -lssh2
> 
> [1] http://pkgs.fedoraproject.org/cgit/rpms/kqoauth-qt5.git/tree/kqoa
> uth-qt5.spec
> 
> Have somebody a idea ?

What you're trying to achieve simply cannot work. OpenSSL (where libssl
is from) and libssh2 have completely different purpose.

If there is a problem with conflict of compat-openssl10 and openssl the
solution is to make the thing that requires compat-openssl10 ported to 
new openssl API and thus make it require openssl.

Compat-openssl10-devel will be removed at the latest by Fedora 29 and
anything that requires it will be no longer buildable.

-- 
Tomáš Mráz
Red Hat

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

 * Google and NSA associates, this message is none of your business.
 * Please leave it alone, and consider whether your actions are
 * authorized by the contract with Red Hat, or by the US constitution.
 * If you feel you're being encouraged to disregard the limits built
 * into them, remember Edward Snowden and Wikileaks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Schedule for Friday's FESCo Meeting (2017-12-01)

[Zbigniew Jędrzejewski-Szmek]

On Thu, Nov 30, 2017 at 02:05:52PM -0800, Kevin Fenzi wrote:
> Following is the list of topics that will be discussed in the
> FESCo meeting Friday at 16:00UTC in #fedora-meeting on
> irc.freenode.net.
> 
> To convert UTC to your local time, take a look at
>   http://fedoraproject.org/wiki/UTCHowto
> 
> or run:
>   date -d '2017-12-01 16:00 UTC'
> 
> Links to all issues below can be found at:
> https://pagure.io/fesco/report/meeting_agenda
> 
> = Followups =
> 
> #topic #1663 How strongly should we recommend systemd sandboxing features?
> .fesco 1663
> https://pagure.io/fesco/issue/1663

Hi,

would it be possible to move this down a bit in the agenda?
I have an overlapping meeting 15:30-16:30 UTC...

Zbyszek

> = New business =
> 
> #topic #1792 bodhi enablement and Beta freeze need to be the same day
> .fesco 1792
> https://pagure.io/fesco/issue/1794
> 
> #topic #1790 Proposal for 3 week freeze
> .fesco 1790
> https://pagure.io/fesco/issue/1790
> 
> #topic #1761 Update of "Fedora Release Live Cycle" and "Changes/ Policy"
> .fesco 1761
> https://pagure.io/fesco/issue/1761
> 
> #topic #1767 F28 Self Contained Changes
> .fesco 1767
> https://pagure.io/fesco/issue/1767
> 
> #topic #1795 F28 System Wide Change: time-1.8
> .fesco 1795
> https://pagure.io/fesco/issue/1795
> 
> #topic #1796 Mandatory Release notes for Changes
> .fesco 1796
> https://pagure.io/fesco/issue/1796
> 
> #topic #1798 F28 System Wide Change: Improved Laptop Battery Life
> .fesco 1798
> https://pagure.io/fesco/issue/1798
> 
> = Open Floor =
> 
> For more complete details, please visit each individual
> issue.  The report of the agenda items can be found at
> https://pagure.io/fesco/report/meeting_agenda
> 
> If you would like to add something to this agenda, you can
> reply to this e-mail, file a new issue at
> https://pagure.io/fesco, e-mail me directly, or bring it
> up at the end of the meeting, during the open floor topic. Note
> that added topics may be deferred until the following meeting.
> 




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

Fedora-Modular 27-20171201.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Docker_base docker x86_64
Server dvd arm

Failed openQA tests: 18/94 (x86_64), 4/19 (i386)

Old failures (same test failed in 27-20171130.n.1):

ID: 177670  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/177670
ID: 177676  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/177676
ID: 177690  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/177690
ID: 177694  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/177694
ID: 177696  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/177696
ID: 177697  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/177697
ID: 177741  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/177741
ID: 177742  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/177742
ID: 177743  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/177743
ID: 177744  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/177744
ID: 177746  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/177746
ID: 177747  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/177747
ID: 177748  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/177748
ID: 177749  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/177749
ID: 177750  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/177750
ID: 177751  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/177751
ID: 177752  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/177752
ID: 177756  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/177756
ID: 177757  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/177757
ID: 177765  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/177765
ID: 177766  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/177766
ID: 19  Test: i386 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/19

Passed openQA tests: 68/94 (x86_64), 15/19 (i386)

New passes (same test did not pass in 27-20171130.n.1):

ID: 177719  Test: x86_64 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/177719
ID: 177760  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/177760

Skipped openQA tests: 3 of 113

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
System load changed from 0.02 to 0.13
Previous test data: https://openqa.fedoraproject.org/tests/177515#downloads
Current test data: https://openqa.fedoraproject.org/tests/177672#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Modular 27 compose report: 20171201.n.0 changes

[Fedora Branched Report]

OLD: Fedora-Modular-27-20171130.n.1
NEW: Fedora-Modular-27-20171201.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0.00 B
Size of dropped packages:0.00 B
Size of upgraded packages:   0.00 B
Size of downgraded packages: 0.00 B

Size change of upgraded packages:   0.00 B
Size change of downgraded packages: 0.00 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

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

[Fedocal] Reminder meeting : Nomination & Campaign period in progress

[jkurik]

Dear all,

You are kindly invited to the meeting:
   Nomination & Campaign period in progress on 2017-12-02 from 00:00:00 to 
00:00:00 UTC
   

The meeting will be about:
The Nomination & Campaign period for the next elections is still in progress. 
These elections will take place on December 2017:

- FESCo (Engineering) (5 seats) [1]
- Fedora Council (2 seats) [2]
- Mindshare (2 seats) [3]

Please stay tuned with the Questionnaire [4] and the CommBlog [5] where 
responses are posted!

[1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations

[2] https://fedoraproject.org/wiki/Council/Nominations

[3] https://fedoraproject.org/wiki/Mindshare/Nominations

[4] https://fedoraproject.org/wiki/Elections/Questionnaire

[5] https://communityblog.fedoraproject.org/


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

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

Schedule for Friday's FESCo Meeting (2017-12-01)

[Kevin Fenzi]

Following is the list of topics that will be discussed in the
FESCo meeting Friday at 16:00UTC in #fedora-meeting on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2017-12-01 16:00 UTC'

Links to all issues below can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Followups =

#topic #1663 How strongly should we recommend systemd sandboxing features?
.fesco 1663
https://pagure.io/fesco/issue/1663

= New business =

#topic #1792 bodhi enablement and Beta freeze need to be the same day
.fesco 1792
https://pagure.io/fesco/issue/1794

#topic #1790 Proposal for 3 week freeze
.fesco 1790
https://pagure.io/fesco/issue/1790

#topic #1761 Update of "Fedora Release Live Cycle" and "Changes/ Policy"
.fesco 1761
https://pagure.io/fesco/issue/1761

#topic #1767 F28 Self Contained Changes
.fesco 1767
https://pagure.io/fesco/issue/1767

#topic #1795 F28 System Wide Change: time-1.8
.fesco 1795
https://pagure.io/fesco/issue/1795

#topic #1796 Mandatory Release notes for Changes
.fesco 1796
https://pagure.io/fesco/issue/1796

#topic #1798 F28 System Wide Change: Improved Laptop Battery Life
.fesco 1798
https://pagure.io/fesco/issue/1798

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.



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-Modular 27-20171130.n.1 compose check report

[Fedora compose checker]

Missing expected images:

Docker_base docker x86_64
Server dvd arm

Failed openQA tests: 20/94 (x86_64), 4/19 (i386)

ID: 177513  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/177513
ID: 177519  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/177519
ID: 177533  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/177533
ID: 177537  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/177537
ID: 177539  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/177539
ID: 177540  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/177540
ID: 177562  Test: x86_64 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/177562
ID: 177584  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/177584
ID: 177585  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/177585
ID: 177586  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/177586
ID: 177587  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/177587
ID: 177589  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/177589
ID: 177590  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/177590
ID: 177591  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/177591
ID: 177592  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/177592
ID: 177593  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/177593
ID: 177594  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/177594
ID: 177595  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/177595
ID: 177599  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/177599
ID: 177600  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/177600
ID: 177603  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/177603
ID: 177608  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/177608
ID: 177609  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/177609
ID: 177622  Test: i386 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/177622

Passed openQA tests: 66/94 (x86_64), 15/19 (i386)

Skipped openQA tests: 3 of 113
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Modular bikeshed compose report: changes

[Fedora Rawhide Report]

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

Fedora 27 RC 1.6 compose check report

[Fedora compose checker]

Missing expected images:

Workstation live i386
Kde live i386

Failed openQA tests: 7/135 (x86_64), 1/2 (arm)

ID: 165589  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/165589
ID: 165612  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/165612
ID: 165630  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/165630
ID: 165636  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/165636
ID: 165642  Test: arm Minimal-raw_xz-raw.xz base_services_start_arm
URL: https://openqa.fedoraproject.org/tests/165642
ID: 165651  Test: x86_64 Workstation Ostree-dvd_ostree-iso 
base_services_start
URL: https://openqa.fedoraproject.org/tests/165651
ID: 165663  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/165663
ID: 177624  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/177624

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

ID: 165664  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/165664
ID: 165666  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/165666
ID: 165676  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/165676
ID: 165703  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/165703
ID: 165711  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/165711

Passed openQA tests: 121/135 (x86_64), 22/22 (i386), 1/2 (arm)

Skipped openQA tests: 1 of 159
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Self Introduction: Jaroslav Prokop

[Jaroslav Prokop]

Hi everyone,
 
my name is Jaroslav, Jarek for short, I am 16 years old student, I live and 
study in Brno, Czech Republic.
I am beginner in the world of programming, right now I am working on becoming 
rpm packager.
For now I will be packaging ruby software and I am building my first Fedora 
packages [1] [2].
I am not experienced much and still pretty young, but I am working my way to 
knowledge, but I am glad I can give my part to this awesome open source project.
If you´re interested to know more about me, we could do some Q&A.
 
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1517000
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1516328
 
--
GPG:
https://paste.fedoraproject.org/paste/EhUSQh4Y2MLh8HGj~DADvw

 
Regards,
Jaroslav Prokop


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

Fedora Modular 27 compose report: 20171130.n.1 changes

[Fedora Branched Report]

OLD: Fedora-Modular-27-20171130.n.0
NEW: Fedora-Modular-27-20171130.n.1

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0.00 B
Size of dropped packages:0.00 B
Size of upgraded packages:   0.00 B
Size of downgraded packages: 0.00 B

Size change of upgraded packages:   0.00 B
Size change of downgraded packages: 0.00 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

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

Re: Which Fedora/EPEL is targeted by packaging guidelines?

[Vít Ondruch]

Dne 30.11.2017 v 16:39 Matthew Miller napsal(a):
> On Thu, Nov 30, 2017 at 04:33:07PM +0100, Vít Ondruch wrote:
>> The EPEL number you are presenting are bit unrelated number. You should
>> compare how many "enhancement" and "bugfix" updates were submitted in
>> EPEL versus Fedora (and actually you can't evaluate Fedora correctly
>> since there are no updates in Rawhide). In my domain (Ruby packages),
>> there are plenty of changes in packages in Fedora, mainly in Rawhide,
>> less in stable releases. In EPEL, there typically happens just one
>> single import and then the package stays in that state forever.
> How so? I'm not counting updates — these connection counts show
> repodata queries, so they happen even if there are no updates. My point
> here wasn't amount of change, but number of users.

For me it matters how many times I have to touch the package in Rawhide
and how many times in other branches. If I have in .spec file the
conditionals for older branches but in reality I don't touch them,
because I don't update the old branches, then the conditionals are not
just useless but harmful, because they make the .spec file less
readable, they prevent automated changes in packages etc. This way we
just build technical debt.


>
> That said, I think EPEL _and_ Fedora OS users would benefit from being
> able to choose between having frequently updated Ruby packages _or_ the
> "single import, stays in that state barring a serious security issue"
> without having that choice be dependent on the base operating system.
>
>

But then comes upstream which says "ah, we don't support Ruby from RHEL
7 anymore, just because we don't test it" and they put some version
restriction somewhere. Then it is not EPEL or Fedora choice. This
inevitably happens during the RHEL lifecycle and again, since that
moment the conditions in .spec file are useless and just builds the
technical debt.


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

Re: How to manage a fork

[Matthew Miller]

On Thu, Nov 30, 2017 at 11:05:52AM -0500, Pavel Valena wrote:
> > That is, can i push new release with 'fedpkg' or make additional changes
> > to original RPMs? If not, are they useful for what?
> You use them to create pull-requests to the original repo. See
> https://docs.pagure.org/pagure/usage/pull_requests.html

It'd be pretty awesome to have a button to build in copr from a fork.

-- 
Matthew Miller

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

Re: Which Fedora/EPEL is targeted by packaging guidelines?

[Stephen John Smoogen]

On 30 November 2017 at 03:49, Vít Ondruch  wrote:
> Hi all,
>
> Reading logs from yesterdays FPC meeting [1], I think we should discuss
> what is actually purpose of packaging guidelines and which version of
> Fedora/EPEL/RHEL they actually targets.
>
>
> Apparently, there are two camps of packagers in Fedora/EPEL. Those who want:
>
> 1) single version of .spec file to cover the whole Red Hat ecosystem.
>
> 2) clean .spec file following the latest and greatest packaging practices.
>
>
> I personally belong to the group (2) and that is for several reasons:
>
> a) I use Rawhide on daily basis and I develop only for Rawhide. If I do
> changes in older Fedoras, then it is typically just bug fixes and
> honestly, that does not happen often (I am POC of ~200 packages and I
> submitted just 40 updates during last year [2]). And in fact, this is
> official philosophy of updates [3], not just mine.
>
> b) I spent time developing features which should simplify packaging (for
> example in F27+, the RPM %setup macro can expand the .gem packages) and
> I want to use these technologies to simplify my life and life of others.
>
> c) As a proven packager and person who typically does rebuild of Ruby
> packages, I really hate the branched .spec files where nobody knows what
> was the purpose of the branches, most of the branches are for obsolete
> and unsupported releases etc. It is quite hard to apply any improvements
> into such packages. Moreover it is not realistic to test them. If they
> were maintained, it would be different story, but the reality is different.
>
>
> Don't get me wrong, I understand that there are packagers who has just
> handful of packages and it is better for them to maintain just single
> .spec file with all the branches and I don't mind them as long as the
> packages are really actively maintained. But this approach just don't
> scale and should be exception and not recommended practice.
>
>
> To sum this up, my take on packaging guidelines is that *the guidelines
> should document the most recent practices available in Rawhide and this
> should be documented*. Covering all the exceptions necessary for older
> Fedoras (not even mentioning RHEL/EPEL) makes the guidelines unreadable
> and what is worse, they slow down entire development of Fedora.
>

Honestly, I think the RHEL/EPEL part of your conversation is a Red
Herring (aka not the real point).

You are wanting people to follow your method of packaging everything
because it makes your job easier. The problem is that other packagers
want you to follow their method and that makes your job harder. EPEL
versions stand out like a sore thumb of wanting that but even the
differences between getting something working in F25 and F28 can be
quite a bunch of %if strings which makes your job harder. On the other
hand, other people aren't interested in Rawhide and want all that.

The problem is an age old one and one that comes up after every couple
of releases. I think the EPEL group have tried a lot of different
solutions which try to help on this

1. If a package is not maintainable to the developer, stop maintaining
it. At the moment, it will be removed from usage. People wanting it
can get it from various archives.
2. Tibbs has gone through several herculian efforts to backport as
much of the new FPC macros and such to older EPEL's so that newer
schemes can work.
3. We are open to suggestions of what maintainers and developers want
or do not want out of the repository.

>
> Vít
>
>
>
> [1]
> https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org/message/QDQ42LRLCP5NOIFSAMUDMP6ZUH3AAHKN/
>
> [2] https://bodhi.fedoraproject.org/updates/?user=vondruch
>
> [3] https://pagure.io/packaging-committee/issue/710
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: How to manage a fork

[Pavel Valena]

- Original Message -
> From: "Pavel Valena" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, November 30, 2017 5:02:49 PM
> Subject: Re: How to manage a fork
> 
> - Original Message -
> > From: "Vít Ondruch" 
> > To: devel@lists.fedoraproject.org
> > Sent: Thursday, November 30, 2017 2:55:50 PM
> > Subject: Re: How to manage a fork
> > 
> > 
> > 
> > Dne 30.11.2017 v 13:48 Pierre-Yves Chibon napsal(a):
> > > On Thu, Nov 30, 2017 at 10:15:14AM +0100, Vít Ondruch wrote:
> > >>Dne 29.11.2017 v 20:06 Kevin Fenzi napsal(a):
> > >>
> > >>  On 11/29/2017 10:53 AM, Matthew Miller wrote:
> > >>
> > >>  On Wed, Nov 29, 2017 at 06:52:00PM +0100, Brian Exelbierd wrote:
> > >>
> > >>  As as you have a fork, my understanding is that you should just use
> > >>  traditional gut commands. I’m not aware of a fork being used for much
> > >>  more than spec PRs.
> > >>
> > >>  Or traditional _git_ commands -- whatever. :)
> > >>
> > >>  Personally, I find that when working with forks of something where I'm
> > >>  a casual contributor, I end up doing this a lot:
> > >>
> > >>git remote add upstream https://pagure.io/fedora-docs/quick-docs
> > >>
> > >>git fetch upstream
> > >>git reset --hard upstream/master
> > >>
> > >>
> > >>  (repeat last two steps)
> > >>
> > >>  I'm sure places like github have docs on this too, but pagure also
> > >>  does:
> > >>
> > >>  https://docs.pagure.org/pagure/usage/forks.html
> > >>
> > >>Sorry to say that, but I consider this page ill advised. E.g.
> > >>suggesting
> > >>to do:
> > >>
> > >>~~~
> > >>
> > >>  $ git clone ssh://g...@pagure.io/forks/jcline/pagure.git
> > >>
> > >>~~~
> > >>
> > >>is totally wrong IMO.
> > > That is most definitively just your opinion :)
> > >
> > > I know many people seeing it the other way around. They fork their repo,
> > > potentially add upstream as another remote, push to their fork, open
> > > their
> > > PR
> > > and practically will only pull from upstream if upstream asks them to
> > > rebase or
> > 
> > And that is the major problem with that approach. In this case upstream
> > has often to tell something to people submitting their PR and just
> > because the plain "git pull" can't do the right and natural thing.
> > People then start their branches from obsolete master etc.
> 
> AFAIK this is not a problem anymore (as long as upstreams' `master` is
> `forward-only`, because GH rebases seamlessly for you.

Note that I've not tested this with pagure, but it would make definitely a good 
RFE.

Pavel

> 
> Pavel
> 
> > 
> > If you clone the upstream repository, then you never have to pull
> > anything from your fork. You are using the fork in "push only" mode.
> > 
> > > if they need to do another change.
> > >
> > >> I would go as far as saying you should never "git
> > >>clone" forked repository. You should always "git clone" the upstream
> > >>and
> > >>then add the remote for your fork if you need.
> > > It's really potato vs potato, clone your fork and add upstream as a
> > > remote
> > > or
> > > clone upstream and add your fork as a remote, at the end what matters is
> > > that
> > > you know which approach you used (and if you don't git remote -v will
> > > tell
> > > you)
> > > and know how to work with it.
> > 
> > Not really, it is matter of attitude. Clone of upstream is always good
> > to have. Just for observing the project or to prepare source tarball or
> > whatever else. Fork itself is useless unless you want to contribute.
> > 
> > 
> > Vít
> > 
> >
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to manage a fork

[Pavel Valena]

- Original Message -
> From: "Antonio Trande" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Thursday, November 30, 2017 4:50:24 PM
> Subject: Re: How to manage a fork
> 
> On 29/11/2017 13:03, Antonio Trande wrote:
> > Hi all.
> > 
> > I have created a fork on https://src.fedoraproject.org/ but i don't know
> > how to manage it.
> > Can i use 'fedpkg'?
> > Documentation?
> > 
> > 
> 
> Maybe, i was unclear with my question.
> 
> If i create a fork of **https://src.fedoraproject.org/rpms/hdf5** like
> *https://src.fedoraproject.org/fork/sagitter/rpms/hdf5**, can i use the
> fork like it was the original project?
> That is, can i push new release with 'fedpkg' or make additional changes
> to original RPMs? If not, are they useful for what?

You use them to create pull-requests to the original repo. See

https://docs.pagure.org/pagure/usage/pull_requests.html

Pavel

> 
> --
> ---
> Antonio Trande
> Fedora Project
> mailto 'sagitter at fedoraproject dot org'
> GPG key: 0x5E212EE1D35568BE
> GPG key server: https://keys.fedoraproject.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to manage a fork

[Pavel Valena]

- Original Message -
> From: "Vít Ondruch" 
> To: devel@lists.fedoraproject.org
> Sent: Thursday, November 30, 2017 2:55:50 PM
> Subject: Re: How to manage a fork
> 
> 
> 
> Dne 30.11.2017 v 13:48 Pierre-Yves Chibon napsal(a):
> > On Thu, Nov 30, 2017 at 10:15:14AM +0100, Vít Ondruch wrote:
> >>Dne 29.11.2017 v 20:06 Kevin Fenzi napsal(a):
> >>
> >>  On 11/29/2017 10:53 AM, Matthew Miller wrote:
> >>
> >>  On Wed, Nov 29, 2017 at 06:52:00PM +0100, Brian Exelbierd wrote:
> >>
> >>  As as you have a fork, my understanding is that you should just use
> >>  traditional gut commands. I’m not aware of a fork being used for much
> >>  more than spec PRs.
> >>
> >>  Or traditional _git_ commands -- whatever. :)
> >>
> >>  Personally, I find that when working with forks of something where I'm
> >>  a casual contributor, I end up doing this a lot:
> >>
> >>git remote add upstream https://pagure.io/fedora-docs/quick-docs
> >>
> >>git fetch upstream
> >>git reset --hard upstream/master
> >>
> >>
> >>  (repeat last two steps)
> >>
> >>  I'm sure places like github have docs on this too, but pagure also does:
> >>
> >>  https://docs.pagure.org/pagure/usage/forks.html
> >>
> >>Sorry to say that, but I consider this page ill advised. E.g.
> >>suggesting
> >>to do:
> >>
> >>~~~
> >>
> >>  $ git clone ssh://g...@pagure.io/forks/jcline/pagure.git
> >>
> >>~~~
> >>
> >>is totally wrong IMO.
> > That is most definitively just your opinion :)
> >
> > I know many people seeing it the other way around. They fork their repo,
> > potentially add upstream as another remote, push to their fork, open their
> > PR
> > and practically will only pull from upstream if upstream asks them to
> > rebase or
> 
> And that is the major problem with that approach. In this case upstream
> has often to tell something to people submitting their PR and just
> because the plain "git pull" can't do the right and natural thing.
> People then start their branches from obsolete master etc.

AFAIK this is not a problem anymore (as long as upstreams' `master` is 
`forward-only`, because GH rebases seamlessly for you.

Pavel

> 
> If you clone the upstream repository, then you never have to pull
> anything from your fork. You are using the fork in "push only" mode.
> 
> > if they need to do another change.
> >
> >> I would go as far as saying you should never "git
> >>clone" forked repository. You should always "git clone" the upstream
> >>and
> >>then add the remote for your fork if you need.
> > It's really potato vs potato, clone your fork and add upstream as a remote
> > or
> > clone upstream and add your fork as a remote, at the end what matters is
> > that
> > you know which approach you used (and if you don't git remote -v will tell
> > you)
> > and know how to work with it.
> 
> Not really, it is matter of attitude. Clone of upstream is always good
> to have. Just for observing the project or to prepare source tarball or
> whatever else. Fork itself is useless unless you want to contribute.
> 
> 
> Vít
> 
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to manage a fork

[Antonio Trande]

On 29/11/2017 13:03, Antonio Trande wrote:
> Hi all.
> 
> I have created a fork on https://src.fedoraproject.org/ but i don't know
> how to manage it.
> Can i use 'fedpkg'?
> Documentation?
> 
> 

Maybe, i was unclear with my question.

If i create a fork of **https://src.fedoraproject.org/rpms/hdf5** like
*https://src.fedoraproject.org/fork/sagitter/rpms/hdf5**, can i use the
fork like it was the original project?
That is, can i push new release with 'fedpkg' or make additional changes
to original RPMs? If not, are they useful for what?

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/



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

Re: Which Fedora/EPEL is targeted by packaging guidelines?

[Matthew Miller]

On Thu, Nov 30, 2017 at 04:33:07PM +0100, Vít Ondruch wrote:
> The EPEL number you are presenting are bit unrelated number. You should
> compare how many "enhancement" and "bugfix" updates were submitted in
> EPEL versus Fedora (and actually you can't evaluate Fedora correctly
> since there are no updates in Rawhide). In my domain (Ruby packages),
> there are plenty of changes in packages in Fedora, mainly in Rawhide,
> less in stable releases. In EPEL, there typically happens just one
> single import and then the package stays in that state forever.

How so? I'm not counting updates — these connection counts show
repodata queries, so they happen even if there are no updates. My point
here wasn't amount of change, but number of users.

That said, I think EPEL _and_ Fedora OS users would benefit from being
able to choose between having frequently updated Ruby packages _or_ the
"single import, stays in that state barring a serious security issue"
without having that choice be dependent on the base operating system.


-- 
Matthew Miller

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

Re: Which Fedora/EPEL is targeted by packaging guidelines?

[Vít Ondruch]

Dne 30.11.2017 v 16:15 Richard Shaw napsal(a):
> On Thu, Nov 30, 2017 at 8:18 AM, Kevin Kofler  > wrote:
>
> Vít Ondruch wrote:
> > Apparently, there are two camps of packagers in Fedora/EPEL.
> Those who
> > want:
> >
> > 1) single version of .spec file to cover the whole Red Hat
> ecosystem.
> >
> > 2) clean .spec file following the latest and greatest packaging
> practices.
>
> I am actually inbetween: I want a single version of the .spec file
> to cover
> all Fedora releases (and I care a lot about that, since I will
> push updates
> to all releases if they do not contain any breaking changes that
> break user
> expectations), but I do NOT want to support the ancient EL
> releases (which
> is a pleonasm, i.e., even the most recent EL is ancient by Fedora
> standards).
>
>
> I pretty much fall into camp #1 as well. Most of the packages I
> maintain are end user applications and there's usually no reason to
> NOT update all supported releases of Fedora and EPEL, so my workflow
> is generally:
>
> 1. Update rawhide (pseudo branch "n") and make sure the build
> completes before doing any other builds.
> 2. fedpkg switch-branch 
> 3. git merge master

This is big and old-school hammer. If you did "git cherry-pick" instead,
you could get most of the changes you did in master without the
branches. Also, merging means that you get into older (or EPEL) branches
stuff like changelogs from mass rebuild, which should not be there IMO.

You would be surprised, that by cherry-picking, I am able to get most of
the Fedora changes into Red Hat Software Collections although the .spec
files might differ in places significantly mainly due to SCL macros.


Vít

> && git push && fedpkg build --nowait
> 4. Wash / rinse / repeat 2 & 3 for each supported branch.
>
> I also do the same for libraries for MINOR non-abi breaking releases.
>
> Thanks,
> Richard
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

Re: Which Fedora/EPEL is targeted by packaging guidelines?

[Vít Ondruch]

Dne 30.11.2017 v 16:02 Matthew Miller napsal(a):
> On Thu, Nov 30, 2017 at 09:49:14AM +0100, Vít Ondruch wrote:
>> Apparently, there are two camps of packagers in Fedora/EPEL. Those who want:
>> 1) single version of .spec file to cover the whole Red Hat ecosystem.
>> 2) clean .spec file following the latest and greatest packaging practices.
>
> Here's my take: how much impact on the world do you want to have? Are
> you doing this just for yourself, or to help other people? With that in
> mind, take a look at the relative use in the world of Fedora and EPEL:
>
>   https://twitter.com/mattdm/status/936243506355621888
>
> and considering the velociraptor's comment, my anecdotal sense is that
> use of NAT and proxies at large institutions using enterprise distros
> _probably_ makes the red EPEL line even higher.
>
> For those of you who prefer ASCII art to graphics, here's an
> approximation of this chart:
> e
>e
>   e
> ee
>   ee
>   
>eee
>  ee
>  
>  
>     f
>  feeffff
> fe   
>  fff   ee
> eee
> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017
>
>
> Particularly in the last few years, Fedora as an OS is doing well. But
> use of EPEL by our downstreams is growning even more dramatically. Of
> course, I want Fedora OS growth, but the impact we have is _way_ beyond
> that, and I'd really like us to think of _Fedora_ as beyond just the
> base OS, too.
>
> I definitely get the point, though, about it being annoying to have to
> carry ancient kludges for ten years, or to not be able to take
> advantage of new packaging technologies until the downstreams have
> caught up. I don't discount the impact we have by making improvements
> that eventually trickle down, too — we make our downstreams better with
> our fast-moving development work as well as by providing a universe of
> additional software.
>
> We *could* decide to just focus on one at the exclusion of the other —
> drop EPEL and just work on the latest rolling release stuff. Or, we
> could say that we need to dial back the packaging improvements and make
> everyone focus on ecosystem compatibility.
>
> Instead, I'd like to focus effort on bringing the stuff we need to the
> enterprise distributions more quickly. And I think we need to figure
> out how to make Fedora/EPEL packages on EL without needing to promise
> an EL-equivalent maintenance period — that's not reasonable for many
> Fedora packagers.
>
> But we can make this better. Let's work with the downstreams to that.
> And, let's use automation to identify and correct problem areas.
> (Hopefully not surprisingly, this is one of my top requests for the
> whole Modularity effort. It should make this *easy*.)
>

The EPEL number you are presenting are bit unrelated number. You should
compare how many "enhancement" and "bugfix" updates were submitted in
EPEL versus Fedora (and actually you can't evaluate Fedora correctly
since there are no updates in Rawhide). In my domain (Ruby packages),
there are plenty of changes in packages in Fedora, mainly in Rawhide,
less in stable releases. In EPEL, there typically happens just one
single import and then the package stays in that state forever.

And actually, this is the biggest downside of entire EPEL, it is not
obvious if EPEL should have the most recent packages or stick with one
version forever. And while you might say that the package should follow
upstream and be updated to the same version as in Fedora, this effort
typically fails as soon as Fedora diverges too far. And then the Rawhide
developers have to still deal with EPEL macros which are not useful for
Fedora and not even for EPEL.

So I agree on the point that "we need to figure out how to make
Fedora/EPEL packages on EL without needing to promise
an EL-equivalent maintenance period". But disagree with "that's not
reasonable for many Fedora packagers.", because this is in turn not
reasonable for EPEL itself, since new versions of RHEL inherits from Fedora.


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

Re: Which Fedora/EPEL is targeted by packaging guidelines?

[Richard Shaw]

On Thu, Nov 30, 2017 at 8:18 AM, Kevin Kofler 
wrote:

> Vít Ondruch wrote:
> > Apparently, there are two camps of packagers in Fedora/EPEL. Those who
> > want:
> >
> > 1) single version of .spec file to cover the whole Red Hat ecosystem.
> >
> > 2) clean .spec file following the latest and greatest packaging
> practices.
>
> I am actually inbetween: I want a single version of the .spec file to cover
> all Fedora releases (and I care a lot about that, since I will push updates
> to all releases if they do not contain any breaking changes that break user
> expectations), but I do NOT want to support the ancient EL releases (which
> is a pleonasm, i.e., even the most recent EL is ancient by Fedora
> standards).


I pretty much fall into camp #1 as well. Most of the packages I maintain
are end user applications and there's usually no reason to NOT update all
supported releases of Fedora and EPEL, so my workflow is generally:

1. Update rawhide (pseudo branch "n") and make sure the build completes
before doing any other builds.
2. fedpkg switch-branch 
3. git merge master && git push && fedpkg build --nowait
4. Wash / rinse / repeat 2 & 3 for each supported branch.

I also do the same for libraries for MINOR non-abi breaking releases.

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

Re: Which Fedora/EPEL is targeted by packaging guidelines?

[Matthew Miller]

On Thu, Nov 30, 2017 at 09:49:14AM +0100, Vít Ondruch wrote:
> Apparently, there are two camps of packagers in Fedora/EPEL. Those who want:
> 1) single version of .spec file to cover the whole Red Hat ecosystem.
> 2) clean .spec file following the latest and greatest packaging practices.


Here's my take: how much impact on the world do you want to have? Are
you doing this just for yourself, or to help other people? With that in
mind, take a look at the relative use in the world of Fedora and EPEL:

  https://twitter.com/mattdm/status/936243506355621888

and considering the velociraptor's comment, my anecdotal sense is that
use of NAT and proxies at large institutions using enterprise distros
_probably_ makes the red EPEL line even higher.

For those of you who prefer ASCII art to graphics, here's an
approximation of this chart:
e
   e
  e
ee
  ee
  
   eee
 ee
 
 
    f
 feeffff
fe   
 fff   ee
eee
2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017


Particularly in the last few years, Fedora as an OS is doing well. But
use of EPEL by our downstreams is growning even more dramatically. Of
course, I want Fedora OS growth, but the impact we have is _way_ beyond
that, and I'd really like us to think of _Fedora_ as beyond just the
base OS, too.

I definitely get the point, though, about it being annoying to have to
carry ancient kludges for ten years, or to not be able to take
advantage of new packaging technologies until the downstreams have
caught up. I don't discount the impact we have by making improvements
that eventually trickle down, too — we make our downstreams better with
our fast-moving development work as well as by providing a universe of
additional software.

We *could* decide to just focus on one at the exclusion of the other —
drop EPEL and just work on the latest rolling release stuff. Or, we
could say that we need to dial back the packaging improvements and make
everyone focus on ecosystem compatibility.

Instead, I'd like to focus effort on bringing the stuff we need to the
enterprise distributions more quickly. And I think we need to figure
out how to make Fedora/EPEL packages on EL without needing to promise
an EL-equivalent maintenance period — that's not reasonable for many
Fedora packagers.

But we can make this better. Let's work with the downstreams to that.
And, let's use automation to identify and correct problem areas.
(Hopefully not surprisingly, this is one of my top requests for the
whole Modularity effort. It should make this *easy*.)

-- 
Matthew Miller

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

Fedora Rawhide-20171130.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Server dvd i386
Workstation live i386
Server boot i386
Kde live i386

Failed openQA tests: 84/126 (x86_64), 1/2 (arm)

New failures (same test did not fail in Rawhide-20171129.n.0):

ID: 177307  Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/177307
ID: 177309  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/177309
ID: 177319  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/177319

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

ID: 177278  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/177278
ID: 177279  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/177279
ID: 177281  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/177281
ID: 177282  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/177282
ID: 177284  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/177284
ID: 177288  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/177288
ID: 177289  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/177289
ID: 177300  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/177300
ID: 177304  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/177304
ID: 177315  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/177315
ID: 177316  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/177316
ID: 177321  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/177321
ID: 177323  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/177323
ID: 177332  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/177332
ID: 177334  Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/177334
ID: 177335  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/177335
ID: 177337  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/177337
ID: 177338  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/177338
ID: 177339  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/177339
ID: 177340  Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/177340
ID: 177341  Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/177341
ID: 177342  Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/177342
ID: 177343  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/177343
ID: 177344  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/177344
ID: 177345  Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/177345
ID: 177346  Test: x86_64 universal install_multi
URL: https://openqa.fedoraproject.org/tests/177346
ID: 177347  Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/177347
ID: 177348  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/177348
ID: 177349  Test: x86_64 universal install_simple_free_space
URL: https://openqa.fedoraproject.org/tests/177349
ID: 177350  Test: x86_64 universal install_multi_empty
URL: https://openqa.fedoraproject.org/tests/177350
ID: 177351  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/177351
ID: 177352  Test: x86_64 universal install_delete_partial
URL: https://openqa.fedoraproject.org/tests/177352
ID: 177353  Test: x86_64 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/177353
ID: 177354  Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/177354
ID: 177355  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/177355
ID: 177356  Test: x86_64 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/177356
ID: 177357  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/177357
ID: 177358  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/177358

Re: Cannot find cause for ARM build failing

[Michael Cronenworth]

On 11/28/2017 02:06 AM, Florian Weimer wrote:

This changed:

https://source.winehq.org/git/wine.git/commitdiff/644f497e87c51f1a1c62b26ea9f588e7bc97d13b 



aapcs-vfp is incompatible with variadic functions on mainline GCC. Maybe Wine 
upstream assumes that you use a patched GCC to build it?


You will have to ask them what the intent is behind this change. I doubt that 
Fedora's Wine intends to run any Windows ARM binaries.  So you should be able to 
just drop the upstream patch. 


Thanks for the tip, Florian.

The native Wine source doesn't use variadic functions, but the Wine-staging patches 
introduce them.


@Sebastian, have you received any reports for this issue?

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

Re: How to manage a fork

[Todd Zullinger]

Vít Ondruch wrote:

Dne 30.11.2017 v 13:48 Pierre-Yves Chibon napsal(a):
It's really potato vs potato, clone your fork and add upstream as a 
remote or clone upstream and add your fork as a remote, at the end 
what matters is that you know which approach you used (and if you 
don't git remote -v will tell you) and know how to work with it.


Not really, it is matter of attitude. Clone of upstream is always 
good to have. Just for observing the project or to prepare source 
tarball or whatever else.


If you clone from the fork and add the upstream as a remote, you have 
a clone of the upstream. All that really differs is which one is named 
origin.  And that's only the default remote name.  It's easy to change 
that during clone with the --origin option or later with git remote 
rename.


Depending on the audience and their familiarity with git, it may be 
easier to explain one method or the other.  But in terms of what data 
the git repository contains, they're essentially identical.



Fork itself is useless unless you want to contribute.


That's precisely the audience for the forks documentation, as far as I 
can see.  The documentation states that in the second sentence. :)


I don't particularly think it's needed, but perhaps someone who does 
would want to submit something like this to the documentation:


 8< 
diff --git i/doc/usage/forks.rst w/doc/usage/forks.rst
index 362280d4..dfc46412 100644
--- i/doc/usage/forks.rst
+++ w/doc/usage/forks.rst
@@ -42,6 +42,12 @@ example::
This lets you pull in changes that the upstream repository makes after you
forked. Consult Git's documentation for more details.

+Alternatively, if you already have a clone of the upstream, you can add your
+fork as a remote.  For example::
+
+$ cd pagure
+$ git remote add -f my-fork ssh://g...@pagure.io/forks/jcline/pagure.git
+

Pushing Changes
---
 8< 

And if there is some reasonable documentation online which further 
explains the benefits of each approach it might be worth adding as a 
link below.  For all I know, the ProGit "Distributed Workflows" page 
which is referenced at the beginning of the Pagure forks documentation 
covers this.


--
Todd
~~
Stress is when you wake up screaming and you realize you weren't
sleeping.



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

Re: remote X connections

[Ray Strode]

 gdm-3.26.2.1-3.fc27

   Update ID: FEDORA-2017-e8628817ff
Content Type: rpm
 Release: Fedora 27
  Status: pending
Type: bugfix
   Karma: 0
   Autokarma: True  [-3, 3]
 Request: testing
   Notes: Add buildrequires for X server so DisableTcp config option works
: properly.
   Submitter: rstrode
   Submitted: 2017-11-30 14:31:29
Comments: bodhi - 2017-11-30 14:31:29 (karma 0)
  This update has been submitted for testing by
  rstrode.

  https://bodhi.fedoraproject.org/updates/FEDORA-2017-e8628817ff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Which Fedora/EPEL is targeted by packaging guidelines?

[Kevin Kofler]

Vít Ondruch wrote:
> Apparently, there are two camps of packagers in Fedora/EPEL. Those who
> want:
> 
> 1) single version of .spec file to cover the whole Red Hat ecosystem.
> 
> 2) clean .spec file following the latest and greatest packaging practices.

I am actually inbetween: I want a single version of the .spec file to cover 
all Fedora releases (and I care a lot about that, since I will push updates 
to all releases if they do not contain any breaking changes that break user 
expectations), but I do NOT want to support the ancient EL releases (which 
is a pleonasm, i.e., even the most recent EL is ancient by Fedora 
standards).

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

Re: How to manage a fork

[Pierre-Yves Chibon]

On Thu, Nov 30, 2017 at 02:55:50PM +0100, Vít Ondruch wrote:
> 
> 
> Dne 30.11.2017 v 13:48 Pierre-Yves Chibon napsal(a):
> > On Thu, Nov 30, 2017 at 10:15:14AM +0100, Vít Ondruch wrote:
> >>Dne 29.11.2017 v 20:06 Kevin Fenzi napsal(a):
> >>
> >>  On 11/29/2017 10:53 AM, Matthew Miller wrote:
> >>
> >>  On Wed, Nov 29, 2017 at 06:52:00PM +0100, Brian Exelbierd wrote:
> >>
> >>  As as you have a fork, my understanding is that you should just use
> >>  traditional gut commands. I’m not aware of a fork being used for much
> >>  more than spec PRs.
> >>
> >>  Or traditional _git_ commands -- whatever. :)
> >>
> >>  Personally, I find that when working with forks of something where I'm
> >>  a casual contributor, I end up doing this a lot:
> >>
> >>git remote add upstream https://pagure.io/fedora-docs/quick-docs
> >>
> >>git fetch upstream
> >>git reset --hard upstream/master 
> >>
> >>
> >>  (repeat last two steps)
> >>
> >>  I'm sure places like github have docs on this too, but pagure also does:
> >>
> >>  https://docs.pagure.org/pagure/usage/forks.html
> >>
> >>Sorry to say that, but I consider this page ill advised. E.g. suggesting
> >>to do:
> >>
> >>~~~
> >>
> >>  $ git clone ssh://g...@pagure.io/forks/jcline/pagure.git
> >>
> >>~~~
> >>
> >>is totally wrong IMO.
> > That is most definitively just your opinion :)
> >
> > I know many people seeing it the other way around. They fork their repo,
> > potentially add upstream as another remote, push to their fork, open their 
> > PR
> > and practically will only pull from upstream if upstream asks them to 
> > rebase or
> 
> And that is the major problem with that approach. In this case upstream
> has often to tell something to people submitting their PR and just
> because the plain "git pull" can't do the right and natural thing.
> People then start their branches from obsolete master etc.
> 
> If you clone the upstream repository, then you never have to pull
> anything from your fork. You are using the fork in "push only" mode.
> 
> > if they need to do another change.
> >
> >> I would go as far as saying you should never "git
> >>clone" forked repository. You should always "git clone" the upstream and
> >>then add the remote for your fork if you need.
> > It's really potato vs potato, clone your fork and add upstream as a remote 
> > or
> > clone upstream and add your fork as a remote, at the end what matters is 
> > that
> > you know which approach you used (and if you don't git remote -v will tell 
> > you)
> > and know how to work with it.
> 
> Not really, it is matter of attitude. Clone of upstream is always good
> to have. Just for observing the project or to prepare source tarball or
> whatever else. Fork itself is useless 

> unless you want to contribute.

Which is exactly what this documentation is about :)

Anyway, no point in arguing further I believe. If you think the documentation
can be improved the sources are in the ``doc`` folder in pagure's sources and
suggestions are welcome :)


Pierre


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

Re: How to manage a fork

[Josh Boyer]

On Thu, Nov 30, 2017 at 8:55 AM, Vít Ondruch  wrote:
>
>
> Dne 30.11.2017 v 13:48 Pierre-Yves Chibon napsal(a):
>> On Thu, Nov 30, 2017 at 10:15:14AM +0100, Vít Ondruch wrote:
>>>Dne 29.11.2017 v 20:06 Kevin Fenzi napsal(a):
>>>
>>>  On 11/29/2017 10:53 AM, Matthew Miller wrote:
>>>
>>>  On Wed, Nov 29, 2017 at 06:52:00PM +0100, Brian Exelbierd wrote:
>>>
>>>  As as you have a fork, my understanding is that you should just use
>>>  traditional gut commands. I’m not aware of a fork being used for much
>>>  more than spec PRs.
>>>
>>>  Or traditional _git_ commands -- whatever. :)
>>>
>>>  Personally, I find that when working with forks of something where I'm
>>>  a casual contributor, I end up doing this a lot:
>>>
>>>git remote add upstream https://pagure.io/fedora-docs/quick-docs
>>>
>>>git fetch upstream
>>>git reset --hard upstream/master
>>>
>>>
>>>  (repeat last two steps)
>>>
>>>  I'm sure places like github have docs on this too, but pagure also does:
>>>
>>>  https://docs.pagure.org/pagure/usage/forks.html
>>>
>>>Sorry to say that, but I consider this page ill advised. E.g. suggesting
>>>to do:
>>>
>>>~~~
>>>
>>>  $ git clone ssh://g...@pagure.io/forks/jcline/pagure.git
>>>
>>>~~~
>>>
>>>is totally wrong IMO.
>> That is most definitively just your opinion :)
>>
>> I know many people seeing it the other way around. They fork their repo,
>> potentially add upstream as another remote, push to their fork, open their PR
>> and practically will only pull from upstream if upstream asks them to rebase 
>> or
>
> And that is the major problem with that approach. In this case upstream
> has often to tell something to people submitting their PR and just
> because the plain "git pull" can't do the right and natural thing.
> People then start their branches from obsolete master etc.
>
> If you clone the upstream repository, then you never have to pull
> anything from your fork. You are using the fork in "push only" mode.
>
>> if they need to do another change.
>>
>>> I would go as far as saying you should never "git
>>>clone" forked repository. You should always "git clone" the upstream and
>>>then add the remote for your fork if you need.
>> It's really potato vs potato, clone your fork and add upstream as a remote or
>> clone upstream and add your fork as a remote, at the end what matters is that
>> you know which approach you used (and if you don't git remote -v will tell 
>> you)
>> and know how to work with it.
>
> Not really, it is matter of attitude. Clone of upstream is always good
> to have. Just for observing the project or to prepare source tarball or
> whatever else. Fork itself is useless unless you want to contribute.

This is going to be a pointless never ending debate.  Git is flexible
enough to let you do this in multiple ways, people are going to have
their preferences.  Just agree to disagree and move on.

I mean, come on.  It took years for vim to win the editor wars.  We
don't have time to waste on another debate like that ;)

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

Re: How to manage a fork

[Matthew Miller]

On Thu, Nov 30, 2017 at 02:55:50PM +0100, Vít Ondruch wrote:
> Not really, it is matter of attitude. Clone of upstream is always good
> to have. Just for observing the project or to prepare source tarball or
> whatever else. Fork itself is useless unless you want to contribute.

I can see the sense in this workflow -- it might be nice to have
documentation for both, and perhaps even showing instructions for
cloning the original and setting the remote for the fork when viewing a
fork.

I bet Pierre would accept patches.



-- 
Matthew Miller

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

Re: How to manage a fork

[Vít Ondruch]

Dne 30.11.2017 v 13:48 Pierre-Yves Chibon napsal(a):
> On Thu, Nov 30, 2017 at 10:15:14AM +0100, Vít Ondruch wrote:
>>Dne 29.11.2017 v 20:06 Kevin Fenzi napsal(a):
>>
>>  On 11/29/2017 10:53 AM, Matthew Miller wrote:
>>
>>  On Wed, Nov 29, 2017 at 06:52:00PM +0100, Brian Exelbierd wrote:
>>
>>  As as you have a fork, my understanding is that you should just use
>>  traditional gut commands. I’m not aware of a fork being used for much
>>  more than spec PRs.
>>
>>  Or traditional _git_ commands -- whatever. :)
>>
>>  Personally, I find that when working with forks of something where I'm
>>  a casual contributor, I end up doing this a lot:
>>
>>git remote add upstream https://pagure.io/fedora-docs/quick-docs
>>
>>git fetch upstream
>>git reset --hard upstream/master 
>>
>>
>>  (repeat last two steps)
>>
>>  I'm sure places like github have docs on this too, but pagure also does:
>>
>>  https://docs.pagure.org/pagure/usage/forks.html
>>
>>Sorry to say that, but I consider this page ill advised. E.g. suggesting
>>to do:
>>
>>~~~
>>
>>  $ git clone ssh://g...@pagure.io/forks/jcline/pagure.git
>>
>>~~~
>>
>>is totally wrong IMO.
> That is most definitively just your opinion :)
>
> I know many people seeing it the other way around. They fork their repo,
> potentially add upstream as another remote, push to their fork, open their PR
> and practically will only pull from upstream if upstream asks them to rebase 
> or

And that is the major problem with that approach. In this case upstream
has often to tell something to people submitting their PR and just
because the plain "git pull" can't do the right and natural thing.
People then start their branches from obsolete master etc.

If you clone the upstream repository, then you never have to pull
anything from your fork. You are using the fork in "push only" mode.

> if they need to do another change.
>
>> I would go as far as saying you should never "git
>>clone" forked repository. You should always "git clone" the upstream and
>>then add the remote for your fork if you need.
> It's really potato vs potato, clone your fork and add upstream as a remote or
> clone upstream and add your fork as a remote, at the end what matters is that
> you know which approach you used (and if you don't git remote -v will tell 
> you)
> and know how to work with it.

Not really, it is matter of attitude. Clone of upstream is always good
to have. Just for observing the project or to prepare source tarball or
whatever else. Fork itself is useless unless you want to contribute.


Vít



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

how to replace ssl with ssh2 in kqoauth

[Martin Gansser]

Is it possible to compile kQOAuth [1] with ssh2 by using openssl, as it always 
comes to conflict between compat-openssl10 and openssl. 
I have already searched in the sources of kqoauth for the places where ssl is 
referenced.

$ grep -r ssl *

kqoauthutils.cpp:#include 
kqoauthutils.cpp:#include 
kqoauthutils.cpp:#include 
kqoauthutils.cpp:#include 
kqoauthutils.h:#include 
Makefile:LIBS  = $(SUBLIBS) -lssl -lcrypto -lQt5Gui -lQt5Network 
-lQt5Core -lGL -lpthread 
src.pro:LIBS += -lssl -lcrypto

i tink it isn't enough only to replace -lssl with -lssh2

[1] 
http://pkgs.fedoraproject.org/cgit/rpms/kqoauth-qt5.git/tree/kqoauth-qt5.spec

Have somebody a idea ?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: remote X connections

[Jan Kratochvil]

On Thu, 30 Nov 2017 13:39:16 +0100, Christian Groessler wrote:
> This is handled by conditional compilation in gdm (depending on a
> HAVE_XSERVER_THAT_DEFAULTS_TO_LOCAL_ONLY define).

gdm ignores DisallowTCP=false on F22
https://bugzilla.redhat.com/show_bug.cgi?id=1226084

FYI I had a problem with it around those versions F-22..F-24 but it does work
for me for several releases now incl. F-27.


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

Re: remote X connections

[Michal Schmidt]

On 11/30/2017 01:39 PM, Christian Groessler wrote:
> This is handled by conditional compilation in gdm (depending on a
> HAVE_XSERVER_THAT_DEFAULTS_TO_LOCAL_ONLY define).
> 
> The setting for this define is determined in configure.ac, lines[...]
>  if $PKG_CONFIG --atleast-version=1.17 xorg-server; then 
> AC_DEFINE([HAVE_XSERVER_THAT_DEFAULTS_TO_LOCAL_ONLY], [], [XServer
> disables tcp access by default]) fi[...]
> On my system, running the test above returns correct results:
> 
> $ pkg-config --atleast-version=1.17 xorg-server ; echo $? 0 $
> 
> 
> I've build the gdm RPM from source on my local machine, installed it,
> and, hey, now everything works as expected.
> 
> So I guess that the machine used to build the official packages still
> has an old X server installed. If that's true, could this be fixed?

Looks like gdm is missing BuildRequires: pkgconfig(xorg-server)
Please report a bug for gdm in Bugzilla.

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

Re: How to manage a fork

[Pierre-Yves Chibon]

On Thu, Nov 30, 2017 at 10:15:14AM +0100, Vít Ondruch wrote:
>Dne 29.11.2017 v 20:06 Kevin Fenzi napsal(a):
> 
>  On 11/29/2017 10:53 AM, Matthew Miller wrote:
> 
>  On Wed, Nov 29, 2017 at 06:52:00PM +0100, Brian Exelbierd wrote:
> 
>  As as you have a fork, my understanding is that you should just use
>  traditional gut commands. I’m not aware of a fork being used for much
>  more than spec PRs.
> 
>  Or traditional _git_ commands -- whatever. :)
> 
>  Personally, I find that when working with forks of something where I'm
>  a casual contributor, I end up doing this a lot:
> 
>git remote add upstream https://pagure.io/fedora-docs/quick-docs
> 
>git fetch upstream
>git reset --hard upstream/master 
> 
> 
>  (repeat last two steps)
> 
>  I'm sure places like github have docs on this too, but pagure also does:
> 
>  https://docs.pagure.org/pagure/usage/forks.html
> 
>Sorry to say that, but I consider this page ill advised. E.g. suggesting
>to do:
> 
>~~~
> 
>  $ git clone ssh://g...@pagure.io/forks/jcline/pagure.git
> 
>~~~
> 
>is totally wrong IMO.

That is most definitively just your opinion :)

I know many people seeing it the other way around. They fork their repo,
potentially add upstream as another remote, push to their fork, open their PR
and practically will only pull from upstream if upstream asks them to rebase or
if they need to do another change.

> I would go as far as saying you should never "git
>clone" forked repository. You should always "git clone" the upstream and
>then add the remote for your fork if you need.

It's really potato vs potato, clone your fork and add upstream as a remote or
clone upstream and add your fork as a remote, at the end what matters is that
you know which approach you used (and if you don't git remote -v will tell you)
and know how to work with it.


Pierre


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

remote X connections

[Christian Groessler]

Hi,

recently I've updated from FC24 to FC27. Since then remote X connections 
don't work anymore. For my environment I'm typically starting an xterm 
shell from another computer displaying on my workstation.


When using "gdm", remote X access is en-/disabled with the "DisallowTCP" 
setting in "/etc/gdm/custom.conf".


Now, there is a trap door. Xorg changed the default for remote 
connections a few releases ago.
Old releases listened on the network unless "-nolisten tcp" was 
specified. Newer releases only listen on the network

if "-listen tcp" is specified on the command line to start the X server.

This means that gdm either needs to add "-nolisten tcp" (old server, 
DisallowTCP=true) or "-listen tcp" (new server, DisallowTCP=false)

to the X server command line.

This is handled by conditional compilation in gdm (depending on a 
HAVE_XSERVER_THAT_DEFAULTS_TO_LOCAL_ONLY define).


The setting for this define is determined in configure.ac, lines


dnl 
---

dnl - Check if Xorg is new enough to require '-listen tcp' (1.17)
dnl 
---


if $PKG_CONFIG --atleast-version=1.17 xorg-server; then
   AC_DEFINE([HAVE_XSERVER_THAT_DEFAULTS_TO_LOCAL_ONLY], [], [XServer 
disables tcp access by default])

fi


Now, my installed gdm seems to think that my Xserver doesn't default to 
"local only". If I set DisallowTCP to true, it adds
a "-nolisten tcp" parameter to the X command line. While it shouldn't 
add anything in this case. If I set DisallowTCP to false
it doesn't add anything to the command line (where it should add 
"-listen tcp").


On my system, running the test above returns correct results:


$ pkg-config --atleast-version=1.17 xorg-server ; echo $?
0
$


I've build the gdm RPM from source on my local machine, installed it, 
and, hey, now everything works as expected.


So I guess that the machine used to build the official packages still 
has an old X server installed. If that's true,

could this be fixed?

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

Re: [Fedora-packaging] Which Fedora/EPEL is targeted by packaging guidelines?

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2017-11-30 at 09:49 +0100, Vít Ondruch wrote:
> Hi all,
> 
> Reading logs from yesterdays FPC meeting [1], I think we should discuss
> what is actually purpose of packaging guidelines and which version of
> Fedora/EPEL/RHEL they actually targets.
> 
> 
> Apparently, there are two camps of packagers in Fedora/EPEL. Those who want:
> 
> 1) single version of .spec file to cover the whole Red Hat ecosystem.
> 
> 2) clean .spec file following the latest and greatest packaging practices.

I'm one of these people too.

> 
> I personally belong to the group (2) and that is for several reasons:
> 
> a) I use Rawhide on daily basis and I develop only for Rawhide. If I do
> changes in older Fedoras, then it is typically just bug fixes and
> honestly, that does not happen often (I am POC of ~200 packages and I
> submitted just 40 updates during last year [2]). And in fact, this is
> official philosophy of updates [3], not just mine.
> 
> b) I spent time developing features which should simplify packaging (for
> example in F27+, the RPM %setup macro can expand the .gem packages) and
> I want to use these technologies to simplify my life and life of others.
> 
> c) As a proven packager and person who typically does rebuild of Ruby
> packages, I really hate the branched .spec files where nobody knows what
> was the purpose of the branches, most of the branches are for obsolete
> and unsupported releases etc. It is quite hard to apply any improvements
> into such packages. Moreover it is not realistic to test them. If they
> were maintained, it would be different story, but the reality is different.
> 
> 
> Don't get me wrong, I understand that there are packagers who has just
> handful of packages and it is better for them to maintain just single
> .spec file with all the branches and I don't mind them as long as the
> packages are really actively maintained. But this approach just don't
> scale and should be exception and not recommended practice.
> 
> 
> To sum this up, my take on packaging guidelines is that *the guidelines
> should document the most recent practices available in Rawhide and this
> should be documented*. Covering all the exceptions necessary for older
> Fedoras (not even mentioning RHEL/EPEL) makes the guidelines unreadable
> and what is worse, they slow down entire development of Fedora.

If we want to have compatibility, then we need to improve RPM (e.g. by
introducing new macro). All ruby/python/nodejs/rust packages look same, except
for versions and some special hacks for packages. Tibbs and Panu were proposing
some ideas how to make it better, so probably we should look into that
direction.

> 
> Vít
> 
> 
> 
> [1]
> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.o
> rg/message/QDQ42LRLCP5NOIFSAMUDMP6ZUH3AAHKN/
> 
> [2] https://bodhi.fedoraproject.org/updates/?user=vondruch
> 
> [3] https://pagure.io/packaging-committee/issue/710
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlof29IACgkQaVcUvRu8
X0z38A//Upax+T95Mgw6nHOug1rC9zeGat5Rc5tYKTmheJlCLTeBV7blXTNhHDG3
8sjYqox1cq9t9ouz+MQ5V37Y0ArVONKA0PI9lVVc88JKjFkwCSiaJEMqNAJZTapN
dJbixuU5YQktleX6YaRjI2onets24U7wDQlsUn3TLaYufR6YotNJPq+zhG+HTnmR
O74C+N57HEL2byGDIYJuf5fXFdWKVdX954tjMS0dXDJTe5pri7636dkEbqe5H3E2
SgsAVxN8cmBM02Wi6l2KyjwpDqK8Z9jQSd29jeqDnQGDK+9x6oA7HVrXdTeO5oBA
jgwjP5/ue7TeNQz16LI6BMrehaxU4hluIAJ7SWc4dQ4uCQqcJ1FdbGz3BAd+5JT9
77Lg3XImG+rzTWhPnR+yTEDCXbdabiJNmau4TJPbtxfY8UeWRX4TvippZO6CVrVc
IgpNuwyA0dWQKJ80RVC4FPpg2sVyjFkl0BooGQsh6nttpDMFMmwUnJUYQs3s1egL
42CGTzWjIaW6IgvfJYD5Qkz05zjM6VOBA+AmaHbtHfGTLv7BN5WStctA4kEIOb76
PpQeU6MIcc1NsPA+TLSr76i6DbeO7hx570OAOI6QxtqIrKceZu+iiZaG6qh73V/H
1Ev6wnvtZ7BrQBSM/SlbXbucU6vF8WlSqkuR1yScLjoDsbsLaIc=
=NURy
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Re: Which Fedora/EPEL is targeted by packaging guidelines?

[Vít Ondruch]

Dne 30.11.2017 v 10:35 nicolas.mail...@laposte.net napsal(a):
> Hi,
>
> I totally agree with the spirit, but that would require Red Hat taking a more 
> active role in backporting package tooling to RHEL/EPEL.
>
> Latest guidelines are always more efficient for everyone (Red Hat employees 
> includes), but all too often they can't be applied to EPEL because no one at 
> Red Hat pushed the corresponding rpm, mock, rpmdevtools, macro updates to 
> RHEL or EPEL :(
>
> The more packages Fedora ships the more inefficient it is to require 
> RHEL/EPEL packagers to use old guidelines in every spec files to avoid 
> tooling backports.
>
> Regards,
>

I think things are changing in Fedora as well as in Red Hat.

Fedora is more agile especially in regard of RPM development, but on the
other hand Red Hat will be always lacking behind due to RPM being
crucial piece of RHEL. On the other hand RHEL is more agile then it used
to be especially due to RHSCL. But also in other aspects, such as
rebases of key packages such as OpenSSL or even Kernel.

OTOH, speaking as a Ruby maintainer in Red Hat, the agility does not
make the situation with guidelines easier, since we cannot anymore say:
"Ah, EPEL7 was based on F19, so apply F19 guidelines". This is simply
because Ruby in RHEL 7.4 newly supports the same set of macros as Fedora
Rawhide, but does not support the provide/require generators due to RHEL
7 RPM limitations. And frankly, should I go to FPC asking for approving
(backward compatible) guideline changes due to change in RHEL? That does
not make any sense.

However, one day, if/when next RHEL comes, I want to see RHEL using the
latest and greatest technologies available in Fedora. I hope I can
generalize this into everybody in Red Hat. And this is another reason
why the guidelines should cover only Rawhide and should promote the most
recent technologies. If we are not going to use/promote the latest
advancements, there would be actually no reason for next RHEL at all. We
could just stay in distribution stone age forever.


Vít


[1] https://pagure.io/packaging-committee/issue/710
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Which Fedora/EPEL is targeted by packaging guidelines?

[Vít Ondruch]

Dne 30.11.2017 v 09:49 Vít Ondruch napsal(a):
> Hi all,
>
> Reading logs from yesterdays FPC meeting [1], I think we should discuss
> what is actually purpose of packaging guidelines and which version of
> Fedora/EPEL/RHEL they actually targets.
>
>
> Apparently, there are two camps of packagers in Fedora/EPEL. Those who want:
>
> 1) single version of .spec file to cover the whole Red Hat ecosystem.
>
> 2) clean .spec file following the latest and greatest packaging practices.
>
>
> I personally belong to the group (2) and that is for several reasons:
>
> a) I use Rawhide on daily basis and I develop only for Rawhide. If I do
> changes in older Fedoras, then it is typically just bug fixes and
> honestly, that does not happen often (I am POC of ~200 packages and I
> submitted just 40 updates during last year [2]). And in fact, this is
> official philosophy of updates [3], not just mine.
>
> b) I spent time developing features which should simplify packaging (for
> example in F27+, the RPM %setup macro can expand the .gem packages) and
> I want to use these technologies to simplify my life and life of others.
>
> c) As a proven packager and person who typically does rebuild of Ruby
> packages, I really hate the branched .spec files where nobody knows what
> was the purpose of the branches, most of the branches are for obsolete
> and unsupported releases etc. It is quite hard to apply any improvements
> into such packages. Moreover it is not realistic to test them. If they
> were maintained, it would be different story, but the reality is different.
>
>
> Don't get me wrong, I understand that there are packagers who has just
> handful of packages and it is better for them to maintain just single
> .spec file with all the branches and I don't mind them as long as the
> packages are really actively maintained. But this approach just don't
> scale and should be exception and not recommended practice.
>
>
> To sum this up, my take on packaging guidelines is that *the guidelines
> should document the most recent practices available in Rawhide and this
> should be documented*. Covering all the exceptions necessary for older
> Fedoras (not even mentioning RHEL/EPEL) makes the guidelines unreadable
> and what is worse, they slow down entire development of Fedora.
>
>
> Vít
>
>
>
> [1]
> https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org/message/QDQ42LRLCP5NOIFSAMUDMP6ZUH3AAHKN/
>
> [2] https://bodhi.fedoraproject.org/updates/?user=vondruch
>
> [3] https://pagure.io/packaging-committee/issue/710

Ups, messed up the link ^^. This is the correct one:

https://fedoraproject.org/wiki/Updates_Policy#Philosophy

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

Re: /usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/libQxtWidgets-qt5.so: undefined reference to `vtable for QxtApplication'

[Martin Gansser]

In the directory src/widgets there is a file widgets.pri (which is included by 
widgets.pro)
At line 124 it checks for pre Qt5 and then adds qxtapplication.h to the headers 
list. Hence for Qt5 it is not pre-processed by moc.

I have moved line 125: HEADERS += qxtapplication.h to after line 130: } 

--- a/src/widgets/widgets.pri.orig  2017-11-30 08:31:04.069021373 +0100
+++ b/src/widgets/widgets.pri   2017-11-30 08:31:31.692021595 +0100
@@ -122,12 +122,12 @@
 # Native event filter support is implemented in QCoreApplication for Qt5
 # and QxtApplication is not required anymore
 lessThan(QT_MAJOR_VERSION, 5) {
-HEADERS  += qxtapplication.h
 HEADERS  += qxtapplication_p.h
 unix:!macx:SOURCES += x11/qxtapplication_x11.cpp
 macx:SOURCES += mac/qxtapplication_mac.cpp
 win32:SOURCES += win/qxtapplication_win.cpp
 }
+HEADERS  += qxtapplication.h
 HEADERS  += qxtglobalshortcut.h
 HEADERS  += qxtglobalshortcut_p.h
 HEADERS  += qxtscreen.h
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Which Fedora/EPEL is targeted by packaging guidelines?

[nicolas . mailhot]

Hi,

I totally agree with the spirit, but that would require Red Hat taking a more 
active role in backporting package tooling to RHEL/EPEL.

Latest guidelines are always more efficient for everyone (Red Hat employees 
includes), but all too often they can't be applied to EPEL because no one at 
Red Hat pushed the corresponding rpm, mock, rpmdevtools, macro updates to RHEL 
or EPEL :(

The more packages Fedora ships the more inefficient it is to require RHEL/EPEL 
packagers to use old guidelines in every spec files to avoid tooling backports.

Regards,

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

Re: How to manage a fork

[Vít Ondruch]

Dne 29.11.2017 v 20:06 Kevin Fenzi napsal(a):
> On 11/29/2017 10:53 AM, Matthew Miller wrote:
>> On Wed, Nov 29, 2017 at 06:52:00PM +0100, Brian Exelbierd wrote:
>>> As as you have a fork, my understanding is that you should just use
>>> traditional gut commands. I’m not aware of a fork being used for much
>>> more than spec PRs.
>> Or traditional _git_ commands -- whatever. :)
>>
>> Personally, I find that when working with forks of something where I'm
>> a casual contributor, I end up doing this a lot:
>>
>>   git remote add upstream https://pagure.io/fedora-docs/quick-docs
>>
>>   git fetch upstream
>>   git reset --hard upstream/master  
>>
>>
>> (repeat last two steps)
> I'm sure places like github have docs on this too, but pagure also does:
>
> https://docs.pagure.org/pagure/usage/forks.html

Sorry to say that, but I consider this page ill advised. E.g. suggesting
to do:

~~~

$ git clone ssh://g...@pagure.io/forks/jcline/pagure.git

~~~

is totally wrong IMO. I would go as far as saying you should never "git
clone" forked repository. You should always "git clone" the upstream and
then add the remote for your fork if you need.

The main reason is because you want to follow your upstream. You want to
be able to "git pull" from the master branch and get the latest and
greatest. That is where the development happens. Your fork is mostly
just tool enabling you to send PR and that happens typically just once
in a while if ever.


Vít


>
> There's one big gotcha to note with forks on src.fedoraproject.org:
> You have to be in the packager group to push changes to anything there
> (including forks) at least for now. We want to change this, but it will
> require a fair bit of shifting things around.
>
> You can still of course make a copy of the repo on any other public
> place (pagure.io, github, gitlab, etc) and file "remote pull requests"
> in the mean time.
>
>> Because I don't really want to keep a long-lived fork with local
>> changes and differences and merge. Possibly fedpkg could grow something
>> smart around this?
> Possibly. It's also worth noting that some people use a workflow like:
>
> * fork project
> * make changes, submit PR
> * delete fork
>
> that way the next time you can just refork it and be set.
>
> kevin
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Which Fedora/EPEL is targeted by packaging guidelines?

[Vít Ondruch]

Hi all,

Reading logs from yesterdays FPC meeting [1], I think we should discuss
what is actually purpose of packaging guidelines and which version of
Fedora/EPEL/RHEL they actually targets.


Apparently, there are two camps of packagers in Fedora/EPEL. Those who want:

1) single version of .spec file to cover the whole Red Hat ecosystem.

2) clean .spec file following the latest and greatest packaging practices.


I personally belong to the group (2) and that is for several reasons:

a) I use Rawhide on daily basis and I develop only for Rawhide. If I do
changes in older Fedoras, then it is typically just bug fixes and
honestly, that does not happen often (I am POC of ~200 packages and I
submitted just 40 updates during last year [2]). And in fact, this is
official philosophy of updates [3], not just mine.

b) I spent time developing features which should simplify packaging (for
example in F27+, the RPM %setup macro can expand the .gem packages) and
I want to use these technologies to simplify my life and life of others.

c) As a proven packager and person who typically does rebuild of Ruby
packages, I really hate the branched .spec files where nobody knows what
was the purpose of the branches, most of the branches are for obsolete
and unsupported releases etc. It is quite hard to apply any improvements
into such packages. Moreover it is not realistic to test them. If they
were maintained, it would be different story, but the reality is different.


Don't get me wrong, I understand that there are packagers who has just
handful of packages and it is better for them to maintain just single
.spec file with all the branches and I don't mind them as long as the
packages are really actively maintained. But this approach just don't
scale and should be exception and not recommended practice.


To sum this up, my take on packaging guidelines is that *the guidelines
should document the most recent practices available in Rawhide and this
should be documented*. Covering all the exceptions necessary for older
Fedoras (not even mentioning RHEL/EPEL) makes the guidelines unreadable
and what is worse, they slow down entire development of Fedora.


Vít



[1]
https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org/message/QDQ42LRLCP5NOIFSAMUDMP6ZUH3AAHKN/

[2] https://bodhi.fedoraproject.org/updates/?user=vondruch

[3] https://pagure.io/packaging-committee/issue/710

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

F28 Self Contained Change: OpenLDAP: Drop TCP wrappers support

[Jan Kurik]

= Proposed Self Contained Change: OpenLDAP: Drop TCP wrappers support =
https://fedoraproject.org/wiki/Changes/OpenLDAPDropTCPWrappersSupport

Change owner(s):
* Matus Honek 

As per [1], TCP wrappers are being deprecated in Fedora. Also, as per
[2], upstream discourages its usage in favour of other means of
protection (e.g. firewall). After this change OpenLDAP will no longer
be affected by TCP wrappers configuration.
[1] https://fedoraproject.org/wiki/Changes/Deprecate_TCP_wrappers
[2] https://www.openldap.org/doc/admin24/security.html#TCP%20Wrappers



== Detailed Description ==
After this change, OpenLDAP will not be configured with
--enable-wrappers resulting in potential TCP wrappers configuration
having no effect on OpenLDAP (i.e. slapd binary executable). Please,
use other means of protection for the OpenLDAP server.


== Scope ==
* Proposal owners:
Remove dependency of OpenLDAP on TCP wrappers. See [4].

* Other developers:
None

* Release engineering:
Part of #7029 [ https://pagure.io/releng/issue/7029 ]

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

* Policies and guidelines:
N/A

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org