Re: Intent to orphan: perl-Mail-DKIM and python-beaker

[Emmanuel Seyman]

* Miro Hrončok [04/07/2018 23:12] :
>
> Anybody who wants perl-Mail-DKIM (needed by amavisd-new, spamassassin)
> before I orphan it?

I'll take it (fas: eseyman).

Emmanuel
___
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/52OVAJAAH426RGVZNOMJ5FTIWIHRKWVW/

Re: Intent to orphan: perl-Mail-DKIM and python-beaker

[Emmanuel Seyman]

* Miro Hrončok [04/07/2018 23:12] :
>
> Anybody who wants perl-Mail-DKIM (needed by amavisd-new, spamassassin)
> before I orphan it?

I'll take it (fas: eseyman).

Emmanuel
___
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/52OVAJAAH426RGVZNOMJ5FTIWIHRKWVW/

[389-devel] 389 DS nightly 2018-07-05 - 88% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2018/07/05/report-389-ds-base-1.4.0.11-20180704gitea7e989.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/5NUPZ267PHSZEJH27GMW4NEXV7BE4WXJ/

[Bug 1598259] New: perl-Config-Perl-V-0.30 is available

[bugzilla]

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

Bug ID: 1598259
   Summary: perl-Config-Perl-V-0.30 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Config-Perl-V
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.30
Current version/release in rawhide: 0.29-2.fc28
URL: http://search.cpan.org/dist/Config-Perl-V/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/6976/

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

Fedora Rawhide-20180702.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 5/138 (x86_64), 23/24 (i386), 1/2 (arm)

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

ID: 254386  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/254386
ID: 254396  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/254396
ID: 254425  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/254425
ID: 254484  Test: x86_64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/254484
ID: 254500  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/254500

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

ID: 254397  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/254397
ID: 254398  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/254398
ID: 254401  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/254401
ID: 254418  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/254418
ID: 254419  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/254419
ID: 254434  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/254434
ID: 254435  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/254435
ID: 254521  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/254521
ID: 254523  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/254523
ID: 254524  Test: i386 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/254524
ID: 254525  Test: i386 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/254525
ID: 254526  Test: i386 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/254526
ID: 254527  Test: i386 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/254527
ID: 254528  Test: i386 universal install_blivet_btrfs
URL: https://openqa.fedoraproject.org/tests/254528
ID: 254529  Test: i386 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/254529
ID: 254530  Test: i386 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/254530
ID: 254531  Test: i386 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/254531
ID: 254532  Test: i386 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/254532
ID: 254533  Test: i386 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/254533
ID: 254534  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/254534
ID: 254535  Test: i386 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/254535
ID: 254536  Test: i386 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/254536
ID: 254537  Test: i386 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/254537
ID: 255284  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/255284

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

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

ID: 254439  Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/254439

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

ID: 254515  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/254515

Passed openQA tests: 130/138 (x86_64), 1/24 (i386)

New passes (same test did not pass in Rawhide-20180701.n.0):

ID: 254388  Test: x86_64 Server-dvd-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/254388
ID: 254400  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/254400
ID: 254457  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/254457
ID: 254467  Test: x86_64 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/254467
ID: 254502  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/254502
ID: 254507  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/254507
ID: 254511  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/254511

Skipped openQA tests: 1 of 164

Installed system changes in test x86_64 Server-boot-iso 

Intent to orphan: perl-Mail-DKIM and python-beaker

[Miro Hrončok]

Anybody who wants perl-Mail-DKIM (needed by amavisd-new, spamassassin) 
before I orphan it?


Anybody who wants python-beaker (needed by TurboGears2, python-pylons, 
previously also python-mako) before I orphan it? This one FTBFS on 
Python 3.7.


Let me know. I'll orphan the packages in a week.
--
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/JUPSAAETBRI4CKGKO56AJIGWDVAEBGBS/

Re: Your package requires Python 3.6, rebuild it!

[Miro Hrončok]

On 4.7.2018 21:51, Sérgio Basto wrote:

since 2018-07-02 14:28 [1] we don't have compose this mean build root
on copr aren't update , and we can't test it


Try adding 
http://kojipkgs.fedoraproject.org/repos/rawhide/latest/x86_64/ as a repo 
to copr. there should be no more problems like iwth the f29-python side 
tag, where packages had newer versions in rawhide still depending on 3.6.


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

Re: Your package requires Python 3.6, rebuild it!

[Sérgio Basto]

since 2018-07-02 14:28 [1] we don't have compose this mean build root 
on copr aren't update , and we can't test it 


https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-Rawhid
e/


On Wed, 2018-07-04 at 21:44 +0200, Miro Hrončok wrote:
> Hi again,
> 
> this as a reminder that you package still requires Python 3.6. It
> needs 
> a rebuild and the build is failing. Please fix it and rebuild your
> package.
> 
> If you open bugzillas, block PYTHON37.
> 
> http://bugzilla.redhat.com/show_bug.cgi?id=PYTHON37
> 
> Apologies for any false positives, this is generated with:
> 
> dnf repoquery  --disablerepo='*' --enablerepo='koji' --whatrequires 
> 'python(abi) == 3.6'
> 
> and
> 
> dnf --refresh repoquery  --disablerepo='*' --enablerepo='koji' 
> --whatrequires 'libpython3.6m.so.1.0()(64bit)'
> 
> 
> Packages known for waiting for dependencies have been removed.
> 
> 
> Maintainers by package:
> APLpysergiopr skytux
> abrt abrt-team jfilak jmilan mhabrnal mkutlak
> mmarusak 
> msuchy
> ara  dmsimard
> btestfab
> ceph branto dachary dmick ke4qqq kkeithle ktdreyer
> steve 
> stingray
> condazbyszek
> diceware kushal
> dionaea  rebus
> flannrmattes
> gcc-python-plugindmalcolm jakub
> gns3-server  athmane
> gplugin  ignatenkobrain
> kdevelop-python  dvratil jgrulich minh
> libreoffice  caolanm dtardon erack sbergmann
> moosezbyszek
> mu   churchyard kushal
> myclifale terjeros
> opencv   hguemar hhorak jmlich jridky kwizart pkajaba 
> sergiomb vjancik
> openscap-daemon  isimluk jcerny matyc mpreisle wsato
> poezio   fantom louizatakk
> prewikka totol
> pygame   jkaluza jskarvad limb
> pymoltimfenn
> pyotherside  m4rtink
> pysnmp   fab
> pystatgrab   fab heliocastro potty slankes ttorling
> python-APScheduler   pabelanger
> python-aiofiles  ignatenkobrain
> python-astroquerylupinix
> python-asttokens zbyszek
> python-backoff   bowlofeggs
> python-basemap   jspaleta limb
> python-bashate   apevec chandankumar
> python-beakerchurchyard kylev lmacken
> python-behavebesser82
> python-binaryornot   pingou
> python-blist ignatenkobrain salimma
> python-bloom cottsay rmattes
> python-catkin_tools  ankursinha cottsay rmattes
> python-cattrsbrouhaha
> python-celerybowlofeggs mrunge topdog
> python-cheetah   mikeb mskalick
> python-cu2qu athoscr
> python-cytoolz   orion
> python-django-countries bkabrda
> python-djvulibre bstinson
> python-eventlet  abbot ignatenkobrain kevin
> python-flake8-import-order zbyszek
> python-flask-restless yograterol
> python-gitlabstevetraylen
> python-gnocchiclient pkilambi
> python-http-parser   bkabrda ralph
> python-jep   raphgro
> python-jira  ishcherb ralph stevetraylen
> python-kafka pkilambi
> python-keystoneclient apevec jruzicka
> python-kubernetesamoralej
> python-lazr-smtptest abompard
> python-libcloud  dbruno sayanchowdhury
> python-line_profiler jacksonisaac
> python-llfusedfateyev maci
> python-lmiwbem   phatina
> python-magnumclient  chandankumar
> python-mdp   zbyszek
> python-mlpy  dhanesh95
> python-msrestazure   melmorabity
> python-myhdl filiperosset
> python-nibabel   ignatenkobrain
> python-oslo-db   apevec gchamoul
> python-oslo-vmware   apevec flaper87 jbernard
> python-osrf-pycommon cottsay rmattes
> python-pacpy ignatenkobrain
> python-parallel-ssh  ignatenkobrain
> python-pbkdf2jonny
> python-pecan-notario ktdreyer
> python-photutils sergiopr
> python-portalocker   ignatenkobrain
> python-pygit2pwalter
> python-pyrad cicku peter
> python-pyvo  lupinix
> python-restructuredtext-lint jujens
> python-ripe-atlas-cousteau jvcelak
> python-rpyc  bkabrda
> python-scrapyechevemaster
> python-sep   sergiopr
> python-seqdiag   dridi
> python-shade larsks pabelanger
> python-shapely   jcp volter
> python-sleekxmpp fab fantom jamielinux louizatakk
> python-slixmpp   fantom
> python-sphinx-intl   jujens
> python-sqlacodegen   ignatenkobrain
> python-statsmodels   sergiopr
> python-stem  jorti
> python-stestrchandankumar
> python-svgwrite  jujens
> python-tablibapevec hguemar ralph
> python-tblib qulogic
> python-tenacity  pkilambi
> python-tlslite   orphan
> python-toro  ignatenkobrain
> python-txaio jujens
> python-vcstools  cottsay rmattes
> python-websocketsjujens
> python3-iep  cottsay
> python3-pocketlint   clumens jkonecny vtrefny
> renderdocgicmo
> rolekit  sgallagh twoerner
> rtv 

[Bug 1529797] fusioninventory-agent-2.4.1 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
fusioninventory-agent-2.4.1-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-94a65fe084

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

Re: Packages which needlessly use %defattr

[Sergio Durigan Junior]

On Wednesday, July 04 2018, Jonny Heggheim wrote:

> On 07/04/2018 03:58 AM, Nico Kadel-Garcia wrote:
>> Yeah, but since it's many thousands of packages, I think maybe you
>> didn't have to send the whole list?
> I like that he sent the whole list, then I can search for my username
> and check if I am on the list.

FWIW, gdb should have been on the list but it isn't.  I suggest you
double-check your package even if you don't see your name on the list.

Cheers,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/
___
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/B6EYMEM2Z52MNRO6MWGVLLCPHG7VTP26/

Re: koji build error

[Federico Bruni]

Thanks, it worked.

I've used spectool to download the archive file and then used fedpkg 
new-sources as you suggested.



Il giorno mar 3 lug 2018 alle 7:33, Vascom  ha 
scritto:

You need to add source file via command
fedpkg new-sources extractpdfmark-1.0.2.tar.gz
And push changes to git repo.

src.rpm builded always as noarch because it just archive.

вт, 3 июл. 2018 г., 8:29 Federico Bruni :

Hello

I'm trying to build a package in koji for the first time.
You can see my (failed) attempt here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=27996807

I run `fedpkg build` from the directory containing this git 
repository:

https://src.fedoraproject.org/rpms/extractpdfmark


I don't understand a couple of things in build.log:

1. Why it's using --target noarch?

2. It seems it cannot find and download the sources, but it should 
work.

The real link is:
https://github.com/trueroad/extractpdfmark/releases/download/v1.0.2/extractpdfmark-1.0.2.tar.gz

Thanks in advance
Federico
___
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/PE5OCXZZVGOFYK2N3WTHLT6A2JSGM7T2/

___
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/WYHEYHRBIQFV56NCH3KDYQKWRAXVTQOY/

Re: Packages which needlessly use %defattr

[Todd Zullinger]

Jan Kratochvil wrote:
> On Wed, 04 Jul 2018 12:18:00 +0200, Zbigniew Jędrzejewski-Szmek wrote:
>> What about just doing a mass specfile update now? I think asking
>> individual maintainers to fix their packages isn't worth their
>> time. It's a safe change,
> 
> Is it? I haven't found whether this change is compatible with CentOS-6 (and 7)
> which could break them if you just build the Fedora Rawhide .spec for them.

It is.  Jason mentioned this in the initial message:

> RPM has provided a sensible default since version 4.4
> (which predates FC6 and RHEL5)

I regularly build git from rawhide, which has no %defattr,
for EL-{6,7} systems.

In case anyone might find that useful or wants to confirm
that the lack of %defattr causes no issues, the COPR's are:

https://copr.fedorainfracloud.org/coprs/g/git-maint/git/
https://copr.fedorainfracloud.org/coprs/tmz/git/

-- 
Todd
~~
Prejudice, n. A vagrant opinion without any visible means of support.
-- Ambrose Bierce, "The Devil's Dictionary"



signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/3AJR4PPZNZTN3GPOWK3G7K4NHGOBNOVA/

Re: Packages which needlessly use %defattr

[Jan Kratochvil]

On Wed, 04 Jul 2018 12:18:00 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> What about just doing a mass specfile update now? I think asking
> individual maintainers to fix their packages isn't worth their
> time. It's a safe change,

Is it? I haven't found whether this change is compatible with CentOS-6 (and 7)
which could break them if you just build the Fedora Rawhide .spec for them.


Jan
___
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/N7CSJ5AEZT2Q4O3CJ4MD4NJBJN3OD3V3/

Merging Perl 5.28 to Fedora 29

[Petr Pisar]

Hello,

Perl SIG completed Perl 5.28 upgrade
 in f29-perl side tag
that involved rebuildnig about 3000 packags. Once relengs merge the tag
back to f29 , the new Perl becomes
available.

If you encounter any broken dependencies on libperl.so.5.26() or
perl(:MODULE_COMPAT_5.26.*), it's because the package fails to build
(all the failures have been already reported) or because a package
maintainer upgraded her packages before relengs merged the side tag.
In that case feel free to rebuild the package again against the new
Perl.

-- Petr
___
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/BVAWKHQFUQSYD3YY32CGXS5Q5AVHGS2X/

Re: F29 System Wide Change: Modules for Everyone

[Richard Hughes]

On Wed, 4 Jul 2018 at 14:17, Zbigniew Jędrzejewski-Szmek
 wrote:
> - pkcon ?
> - Gnome Software ?

I've been talking internally about this. The idea is for pkcon and
GNOME Software to have a superficial view of what modules are, but not
to actually expose all the nitty-gritty detail. It's on my radar to
make this work correctly.

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

Re: F29 System Wide Change: Modules for Everyone

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jul 04, 2018 at 08:50:32AM -0400, Neal Gompa wrote:
> On Wed, Jul 4, 2018 at 7:38 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Wed, Jun 20, 2018 at 02:20:59PM -0400, Stephen Gallagher wrote:
> > > It also carries with it the implication that the supported package 
> > > managers
> > > must handle module updates correctly. (It does *not* require that they all
> > > be able to handle selecting/switching module streams, but it must honor
> > > whichever stream was set via DNF).
> >
> > I expect that getting support in all the package managers is the hard part.
> > I'm happy to see this explicitly stated in the Change page and included in
> > the Contingency section.
> >
> > What package managements softwares need to be updated apart from packagekit?
> 
> Since we're ignoring YUM, the main issue at this point is that
> modulemd isn't understood by libsolv, so handling of modules is very
> strange.

Yes, I think yum can be ignored. Removal of yum has been proposed and
is generally supported:
https://fedoraproject.org/wiki/Changes/Deprecate_YUM_3.

> > What is the current status of those changes?
> 
> With DNF 3.x, libmodulemd is used through gi for the python frontend.
> With libdnf 0.15.x, libmodulemd is linked in and we're forced to do
> our own depsolving for modules, because the solver doesn't know
> anything about them.
> 
> That said, my understanding is that the repodata format is still kind
> of up in the air, so until the module repodata format is rationalized
> to be sane w.r.t. rpm-md, then I suspect this will not get fixed.
> 
> No one I've talked to is particularly enthused with the idea of having
> YAML parsing for repodata, because of how insane YAML tends to be. And
> libsolv is intended to be mostly self-contained, so it has its own
> internal representation of rpm-md, comps, etc. YAML as input is fine,
> but we're more comfortable with the idea of the output being XML so we
> can keep using the same validated XML parser for everything. Multiple
> parsers make things much harder...
> 
> Incidentally, one of the reasons why PackageKit doesn't understand
> comps anymore is because libdnf hasn't transitioned to using libsolv
> for comps processing yet. That's something that's coming eventually,
> and with it will be a simpler API for dealing with comps groups.

Hmm, all those details… What about a checklist? ;)
- dnf ✓
- dnfdragora ?
- pkcon ?
- Gnome Software ?
- yum - (not needed)
- something else ?

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

Re: [F29 only] Dropping requirements for initscripts package from specfiles

[Peter Robinson]

On Wed, Jul 4, 2018 at 1:18 PM, Neal Gompa  wrote:
> On Wed, Jul 4, 2018 at 8:16 AM Peter Robinson  wrote:
>>
>> On Tue, Jun 19, 2018 at 3:56 PM, David Kaspar [Dee'Kej]
>>  wrote:
>> > Hello people,
>> >
>> > I'm working on making Fedora being able to function completely without the
>> > 'initscripts' package (hopefully) some day in the future. I have done some
>> > cleanup in initscripts recently, and I would like to ask maintainers of
>> > packages listed below to check if their package(s) still really need the
>> > initscripts package to function properly (for any reason).
>> >
>> > It seems that for many packages the requirement of initscripts is just a
>> > leftover from past. If the package does not need the initscripts any 
>> > longer,
>> > please remove the requirement in Rawhide (F29) and forward. (Do not 
>> > backport
>> > this change into F28 or F27, it would break things.)
>> >
>> > NOTE: In case you are depending on initscripts because of networking 
>> > scripts
>> > (ifup/ifdown, etc.), then you will need to update your specfile to depend
>> > directly on new package 'network-scripts' (instead of 'initscripts').
>>
>> It would be useful to do a similar change for chkconfig and split out
>> the alternatives binaries into a separate package as a bunch of the
>> chkconfig stuff is directly related to sys V and the initscripts
>> package.
>>
>
> Since chkconfig can be used to manipulate systemd units indirectly, I
> don't think that's quite so necessary. However, it might make sense
> for the service(8) command implementation to be subpackaged in
> initscripts so that it can be installed without the legacy stuff.

Yes, it can be, it's not necessary though and the package as it stands
contains a lot of legacy stuff and is strictly optional.
___
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/LBSAOMQ2YROGKVFVIPFBUMC4LJ4TRAXJ/

Re: F29 System Wide Change: Modules for Everyone

[Neal Gompa]

On Wed, Jul 4, 2018 at 7:38 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Jun 20, 2018 at 02:20:59PM -0400, Stephen Gallagher wrote:
> > It also carries with it the implication that the supported package managers
> > must handle module updates correctly. (It does *not* require that they all
> > be able to handle selecting/switching module streams, but it must honor
> > whichever stream was set via DNF).
>
> I expect that getting support in all the package managers is the hard part.
> I'm happy to see this explicitly stated in the Change page and included in
> the Contingency section.
>
> What package managements softwares need to be updated apart from packagekit?

Since we're ignoring YUM, the main issue at this point is that
modulemd isn't understood by libsolv, so handling of modules is very
strange.

> What is the current status of those changes?

With DNF 3.x, libmodulemd is used through gi for the python frontend.
With libdnf 0.15.x, libmodulemd is linked in and we're forced to do
our own depsolving for modules, because the solver doesn't know
anything about them.

That said, my understanding is that the repodata format is still kind
of up in the air, so until the module repodata format is rationalized
to be sane w.r.t. rpm-md, then I suspect this will not get fixed.

No one I've talked to is particularly enthused with the idea of having
YAML parsing for repodata, because of how insane YAML tends to be. And
libsolv is intended to be mostly self-contained, so it has its own
internal representation of rpm-md, comps, etc. YAML as input is fine,
but we're more comfortable with the idea of the output being XML so we
can keep using the same validated XML parser for everything. Multiple
parsers make things much harder...

Incidentally, one of the reasons why PackageKit doesn't understand
comps anymore is because libdnf hasn't transitioned to using libsolv
for comps processing yet. That's something that's coming eventually,
and with it will be a simpler API for dealing with comps groups.


--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/2HMTVKL5CE7QMDLHC77KEQXUFF4DJBFV/

Schedule for Thursday's FPC Meeting (2018-07-05 16:00 UTC)

[Miro Hrončok]

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

 Local time information (via. uitime):

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


 Links to all tickets below can be found at:

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


= Followups =

#topic #665 SSLCertificateHandling policy update
.fpc 665
https://pagure.io/packaging-committee/issue/665

#topic #693 Wiki:Packaging:RPMMacros
.fpc 693
https://pagure.io/packaging-committee/issue/693

#topic #714 let's kill file deps!
.fpc 714
https://pagure.io/packaging-committee/issue/714

#topic #719 Simplify packaging of forge-hosted projects
.fpc 719
https://pagure.io/packaging-committee/issue/719

#topic #726 Review for SELinux Independent Policy packaging Draft
.fpc 726
https://pagure.io/packaging-committee/issue/726

#topic #740 Add "%python_enable_dependency_generator" onto Python
.fpc 740
https://pagure.io/packaging-committee/issue/740

#topic #743 Add link to C/C++ build flag docs. in redhat-rpm-config
.fpc 743
https://pagure.io/packaging-committee/issue/743

#topic #759 Don't require editing of Source0 in Python spec template
.fpc 759
https://pagure.io/packaging-committee/issue/759

#topic #774 Reword "Addon Packages" a bit
.fpc 774
https://pagure.io/packaging-committee/issue/774

#topic #775 Allow to have %{?suse_version} condition in spec file
.fpc 775
https://pagure.io/packaging-committee/issue/775

#topic #777 Improved text for default services page
.fpc 777
https://pagure.io/packaging-committee/issue/777


= Open Floor =

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

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

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * 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.

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

[Bug 1597929] perl-Mojolicious-7.87 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Mojolicious-7.86 is|perl-Mojolicious-7.87 is
   |available   |available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 7.87
Current version/release in rawhide: 7.85-1.fc29
URL: https://metacpan.org/release/Mojolicious

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/5966/

-- 
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/345AJE2AKHPZN7TQXM5FK4A67IVD4QXG/

Re: [F29 only] Dropping requirements for initscripts package from specfiles

[Neal Gompa]

On Wed, Jul 4, 2018 at 8:16 AM Peter Robinson  wrote:
>
> On Tue, Jun 19, 2018 at 3:56 PM, David Kaspar [Dee'Kej]
>  wrote:
> > Hello people,
> >
> > I'm working on making Fedora being able to function completely without the
> > 'initscripts' package (hopefully) some day in the future. I have done some
> > cleanup in initscripts recently, and I would like to ask maintainers of
> > packages listed below to check if their package(s) still really need the
> > initscripts package to function properly (for any reason).
> >
> > It seems that for many packages the requirement of initscripts is just a
> > leftover from past. If the package does not need the initscripts any longer,
> > please remove the requirement in Rawhide (F29) and forward. (Do not backport
> > this change into F28 or F27, it would break things.)
> >
> > NOTE: In case you are depending on initscripts because of networking scripts
> > (ifup/ifdown, etc.), then you will need to update your specfile to depend
> > directly on new package 'network-scripts' (instead of 'initscripts').
>
> It would be useful to do a similar change for chkconfig and split out
> the alternatives binaries into a separate package as a bunch of the
> chkconfig stuff is directly related to sys V and the initscripts
> package.
>

Since chkconfig can be used to manipulate systemd units indirectly, I
don't think that's quite so necessary. However, it might make sense
for the service(8) command implementation to be subpackaged in
initscripts so that it can be installed without the legacy stuff.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/KQI7UINVC7OTYCDT3DSCRHUXVUGBMU3F/

Re: F29 Self Contained Change: Deprecate YUM 3

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jun 27, 2018 at 04:25:16PM -0400, Matthew Miller wrote:
> On Wed, Jun 27, 2018 at 02:54:07PM +0200, Björn Persson wrote:
> > > IMHO deprecate != remove, but rather mark for removal in some next 
> > > release.
> > > Should the change be called differently?
> > Especially since Yum has been called "yum-deprecated" for several
> > releases already.
> 
> How about "Replace Yum 3 with Yum 4, powered by DNF"? This would bring
> us in line with what's happening in the Enterprise Linux space.

I'd prefer to replace "powered by" with some simple non-ambiguous wording.
"powered by" might mean that yum calls dnf under the hood, or some
other complicated relationship. "YUM4/DNF" can be used to underline that
they are the same thing.

What about just calling the change "Fully replace yum3 with dnf / yum4"
and having a sentence like "DNF and YUM4 are the same thing" ?

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

Re: [F29 only] Dropping requirements for initscripts package from specfiles

[Peter Robinson]

On Tue, Jun 19, 2018 at 3:56 PM, David Kaspar [Dee'Kej]
 wrote:
> Hello people,
>
> I'm working on making Fedora being able to function completely without the
> 'initscripts' package (hopefully) some day in the future. I have done some
> cleanup in initscripts recently, and I would like to ask maintainers of
> packages listed below to check if their package(s) still really need the
> initscripts package to function properly (for any reason).
>
> It seems that for many packages the requirement of initscripts is just a
> leftover from past. If the package does not need the initscripts any longer,
> please remove the requirement in Rawhide (F29) and forward. (Do not backport
> this change into F28 or F27, it would break things.)
>
> NOTE: In case you are depending on initscripts because of networking scripts
> (ifup/ifdown, etc.), then you will need to update your specfile to depend
> directly on new package 'network-scripts' (instead of 'initscripts').

It would be useful to do a similar change for chkconfig and split out
the alternatives binaries into a separate package as a bunch of the
chkconfig stuff is directly related to sys V and the initscripts
package.

Peter

> I've opened bug reports for each of the packages listed here, and created a
> tracking BZ for it:
> https://bugzilla.redhat.com/show_bug.cgi?id=1592330
>
> List of packages still depending on initscripts (some of them were already
> fixed):
>  3proxy
>  barry
>  boomaga-selinux
>  Canna
>  clamsmtp
>  conmux
>  crossfire-selinux
>  cyphesis
>  device-mapper-multipath
>  dpm-xrootd
>  ebnetd-common
>  exim
>  exim-clamav
>  foghorn
>  freeipa-client
>  glpi
>  groonga-munin-plugins
>  groonga-server-gqtp
>  iipsrv
>  isdn4k-utils
>  kbd
>  libstoragemgmt
>  mailman-3
>  nightview-server
>  node
>  ntop
>  numad
>  omniORB
>  openslp-server
>  os-net-config
>  pcp
>  pcsc-cyberjack
>  pgbouncer
>  plymouth
>  ppp
>  pure-ftpd-selinux
>  ratbox-services
>  sagator-core
>  spacewalk-config
>  spamassassin
>  spawn-fcgi
>  sslogger
>  systemtap-initscript
>  systemtap-server
>  tigervnc-server-minimal
>  torque-mom
>  torque-scheduler
>  torque-server
>  trafficserver
>  varnish
>  vdsm
>  vhostmd
>  vpnc
>  vte
>  vte291
>  vte3
>  wine-desktop
>  xboxdrv
>
> Thank you, and best regards! :)
>
> David Kaspar [Dee'Kej]
> Associate Software Engineer
> Brno, Czech Republic
>
> RED HAT | TRIED. TESTED. TRUSTED.
> Every airline in the Fortune 500 relies on Red Hat.
> Find out why at Trusted | 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/MRI2HG2WTDJ2BGZTZMZ3JLUMKGEFWM6P/
>
___
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/I4DLROLUEUAAOUZFBKS3XGXYI5UYGGOJ/

Re: F29 System Wide Change: Modules for Everyone

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jun 20, 2018 at 02:20:59PM -0400, Stephen Gallagher wrote:
> It also carries with it the implication that the supported package managers
> must handle module updates correctly. (It does *not* require that they all
> be able to handle selecting/switching module streams, but it must honor
> whichever stream was set via DNF).

I expect that getting support in all the package managers is the hard part. 
I'm happy to see this explicitly stated in the Change page and included in
the Contingency section.

What package managements softwares need to be updated apart from packagekit?
What is the current status of those changes?

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

glibc license updates

[Florian Weimer]

I updated the License tag in the RPM file to match reality more closely:

# In general, GPLv2+ is used by programs, LGPLv2+ is used for
# libraries.
#
# LGPLv2+ with exceptions is used for things that are linked directly
# into dynamically linked programs and shared libraries (e.g. crt
# files, lib*_nonshared.a).  Historically, this exception also applies
# to parts of libio.
#
# GPLv2+ with exceptions is used for parts of the Arm unwinder.
#
# GFDL is used for the documentation.
#
# Some other licenses are used in various places (BSD, Inner-Net,
# ISC, Public Domain).
#
# HSRL and FSFAP are only used in test cases, which currently do not
# ship in binary RPMs, so they are not listed here.  MIT is used for
# scripts/install-sh, which does not ship, either.
#
# GPLv3+ is used by manual/texinfo.tex, which we do not use.
#
# LGPLv3+ is used by some Hurd code, which we do not build.
#
# LGPLv2 is used in one place (time/timespec_get.c, by mistake), but
# it is not actually compiled, so it does not matter for libraries.
License: LGPLv2+ and LGPLv2+ with exceptions and GPLv2+ and GPLv2+ with 
exceptions and BSD and Inner-Net and ISC and Public Domain and GFDL


This a substantial change from what we had documented before, but the 
actual licensing conditions themselves are unchanged.


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

Heads up: /usr/bin/python moved to a separate package

[Miro Hrončok]

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

It has been done.

If you hit problems with automatic bytecompilation, see 
https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package#Effect_on_automatic_bytecompilation


If you hit problems with python macros, see 
https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package#Effect_on_.25_python_and_other_ambiguous_RPM_macros


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

Heads up: /usr/bin/python moved to a separate package

[Miro Hrončok]

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

It has been done.

If you hit problems with automatic bytecompilation, see 
https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package#Effect_on_automatic_bytecompilation


If you hit problems with python macros, see 
https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package#Effect_on_.25_python_and_other_ambiguous_RPM_macros


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-annou...@lists.fedoraproject.org/message/YDLLWHWZS6SH6ANEWRPNBL7YFYVWEZZU/
___
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/YDLLWHWZS6SH6ANEWRPNBL7YFYVWEZZU/

Re: Packages which needlessly use %defattr

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jul 03, 2018 at 02:02:16PM -0500, Jason L Tibbitts III wrote:
> I ran the find-needless-defattr command from
> https://pagure.io/fedora-misc-package-utilities to find specfiles which
> include a non-default-changing %defattr as the first line of a %files
> section.  This found 2513 packages.  Because this number is so large, I
> was not able to verify each result manually but I did check a random
> sample of 50 packages and found the results to be correct.

> Since this
> change is so simple, I may begin doing automated cleanup once F29
> branches but feel free to fix your packages at any time.  Since I am
> running this against the nightly specfile tarball, a rebuild is not
> needed for the script to notice that a package has been fixed.

What about just doing a mass specfile update now? I think asking
individual maintainers to fix their packages isn't worth their
time. It's a safe change, just announce it, and patch all 2513
packages a week later, without building. Also, there's no reason imho
to delay this until after branching, now is very good time for this
kind of fix.

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

Re: What is the criterion for Python 3.7 side tag merge?

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jul 03, 2018 at 04:33:37PM -0600, William Moreno wrote:
> >
> >
> > OK. I'll ask releng to merge on Monday.
> >
> >
> Was it merged?

Yep.

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/3PP34SFZUKLC2IA6QWVW7YS54ZGMCN2O/

Re: Perl 5.28 upgrade

[Petr Pisar]

On Tue, Jun 26, 2018 at 07:47:59AM +0200, Jitka Plesnikova wrote:
> Perl 5.28 change was discussed on FESCO meeting and was accepted.
> Perl 5.28 was released on June 23 2018 and mass rebuild can start.
> 
> I have required `f29-perl' build-root for this purpose and it was created.
> 
> I will start the rebuild later today and you can be notified via mail about
> commits/builds in next days.
> 
> Please do not build anything into `f29-perl'. Boot-strapping core modules
> is very peculiar. I also track all changes. You can do your upgrades into
> rawhide freely in parallel.
> 
> You can check status on Perl 5.28 change page
> 
> 
We have successfully built all packages except ten of them. I requested to
merge f29-perl tag back into f29 tag
 recently. Once rel-engs
do that, Perl 5.28.0 will become available in Fedora 29. If you built your
Perl package in the mean time, you would have to rebuild your package after
the merge again.

-- Petr


signature.asc
Description: PGP signature
___
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/GABZ7ZN7MV65XYIRUDGA2CYXYVSM4IOU/

Re: Packages which needlessly use %defattr

[Jonny Heggheim]

Hi Nico.


On 07/04/2018 03:58 AM, Nico Kadel-Garcia wrote:
> Yeah, but since it's many thousands of packages, I think maybe you
> didn't have to send the whole list?
I like that he sent the whole list, then I can search for my username
and check if I am on the list.

> It's been useful for legibility, even it's no longer recommended. Is
> it really hurting anyone at this point? And is it worth the thousands
> of .spec file changes to aggressively clear?
I like to use other packages for inspiration on how things are solved,
so it would be helpful for me that packages are tend to follow good
practices.
 
> Also, it's not trivia to tell people "oh, my script is pretty safe,
> but you should please check many thousands of packages for me!!!" How
> about, instead, posting the script so we can check the syntax first?
There are no need for snide remarks, what about just asking for the script?


Peace, Jonny



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