[Fedocal] Reminder meeting : Modularity WG
Dear all, You are kindly invited to the meeting: Modularity WG on 2016-08-09 from 15:00:00 to 16:00:00 UTC At fedora-meetin...@irc.freenode.net The meeting will be about: Meeting for the Modularity Working Group. More information available at: [Modularity Working Group wiki page](https://fedoraproject.org/wiki/Modularity_Working_Group) The agenda for the meeting is available at [modularity-wg-agendas pad](http://piratepad.nl/modularity-wg-agendas). Source: https://apps.fedoraproject.org/calendar/meeting/4407/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Long live YUM!
On Mon, Aug 08, 2016 at 02:50:43PM -0600, Kevin Fenzi wrote: > On Mon, 8 Aug 2016 19:39:55 + > Zbigniew Jędrzejewski-Szmek wrote: > > ...snip... > > So, all these have their own upstreams and their own progress on moving > to python3. > > > anaconda-yum-plugins > > bodhi-client > > https://github.com/fedora-infra/bodhi/issues/637 > > > copr-frontend > > createrepo > > Unlikely I suspect to move, instead things should/can move to > createrepo_c > > > fedora-gooey-karma > > fusioninventory-agent-yum-plugin > > koji > > https://bugzilla.redhat.com/show_bug.cgi?id=1024827 Filed in 2013, the only answer is "Porting to Py3 is on my radar, but the work is complicated because we still need to support older RHEL versions" → Does this mean that no porting will be done before RHEL7 is EOL? > > mach > > Wonder what still pulls this in? > > > mash > > mirrormanager > > https://github.com/fedora-infra/mirrormanager2/issues/139 "all of those deps are all py3-ready now. All that is left is to port MM2 itself." (January 2016) So this one looks pretty good, even if there is no recent progress. I filed https://github.com/fedora-infra/mirrormanager2/pull/185 to get things going. > > mock > > nagios-plugins-check-updates > > pulp-rpm-yumplugins > > pungi > > python-dnf-plugins-extras-migrate > > python-imgcreate > > rbm > > repoview > > rpmdepsize > > snake > > subscription-manager > > system-config-kickstart > > > > On this list koji, mock, bodhi-client are important, because they > > force fedora packagers to have yum installed. Fedora infra packages > > like mirrormanager, pungi would be nice to de-yum too. > > The rest not so much I think, e.g. subscription-manager is replaced by > > dnf-plugin-subscription-manager, createrepo by createrepo_c, etc. > > Yeah, I am sure help would be welcomed in many of these places... Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [packaging] Needs advice on using ExclusiveArch or ExcludeArch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/08/16 04:05 PM, Kevin Kofler wrote: > The only impact it would have is on performance. But again, it is not > necessary nor desirable to disable runtime-detected support for vector > instructions. It is only a problem when they are used unconditionally. > > The only issue is really that SSE2 is required unconditionally, but it > doesn't look like there is much that can be done about it. This is > unfortunate, because it also breaks support for all non-x86 architectures. > But it would be a lot of work to fix that. (And looking at LuxRender, I also > see hardcoded SSE2 usage there all over the place, both in hardcoded compile > flags and in the code. So Embree is not the only problem there.) In that case, considering that embree is only available on x86_64, what will be a better alternative for acceptance in Fedora repository? > Also note that it is fine to require SSE2 (and also SSE(1) and MMX) on > x86_64. All x86_64 CPUs support SSE2 (and lower). It is only a problem on > i686 (and non non-x86 architectures where the code likely won't build at > all). > > Kevin Kofler > As tested, it turned out true these codes failed on x86_64. It looks like the only option is to make it available for Fedora 25 and above when following Fedora philosophy to say close with upstream. Awaiting for packaging review in a meanwhile: https://bugzilla.redhat.com/show_bug.cgi?id=1364618 - -- Luya Tshimbalanga Graphic & Web Designer E: l...@fedoraproject.org W: http://www.coolest-storm.net -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJXqTheAAoJEF5SgXTYomCaoNEH/itwqKrRhVvolIi+ad3GBmuT JV/8QiwLSxxyYfrry2w76I+Bk5Ojb4VsrEhM6esjHzmRkbXE8InKfelXmmGS3W/s MlmolNuVyM9Rt3rs4DEx70RfnwhTffDIOowDeYuilrQsP/XWYhRlJ+dXO2oQJJD0 c2Jng6i6l1OwbiKtAMe6nPYXPiVlbQSso/8xB9u9eLMDqB0FwVAJC9QkKsEB3UkO Bl4Lm0cDZwMKoVeVJNRfQGA5CZv17AUEt40ypMf3Epb/E2qrUVVVur+x+UtLdMeI kF4QY1BPZo0/o1xIZwOkUKCgQxBcCfRvoUrifKKwINkfe5s/Ok2LIYlOcR9qA18= =cfY9 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora 25 Alpha Freeze
Hi all, Today's an important day on the Fedora 25 schedule[1], with several significant cut-offs. First of all today is the Bodhi activation point [2]. That means that from now all Fedora 25 packages must be submitted to updates-testing and pass the relevant requirements[3] before they will be marked as 'stable' and moved to the fedora repository. Today is also the Alpha freeze[4]. This means that only packages which fix accepted blocker or freeze exception bugs[5][6] will be marked as 'stable' and included in the Alpha composes. Other builds will remain in updates-testing until the Alpha release is approved, at which point the Alpha freeze is lifted and packages can move to 'stable' as usual until the Beta freeze. Today is also the Software String freeze[7], which means that strings marked for translation in Fedora-translated projects should not now be changed for Fedora 25. Finally, today is the 'completion deadline' Change Checkpoint[8], meaning that Fedora 25 Changes must now be 'feature complete or close enough to completion that a majority of its functionality can be tested'. Regards Mohan Boddu [1] https://fedoraproject.org/wiki/Releases/25/Schedule [2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling [3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release [4] https://fedoraproject.org/wiki/Milestone_freezes [5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process [6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process [7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy [8] https://fedoraproject.org/wiki/Changes/Policy ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Rawhide and F25 issues affecting QtWebEngine/QupZilla and Chromium
I wrote: > 1. https://bugzilla.redhat.com/show_bug.cgi?id=1363914 > [abrt] qupzilla: base::debug::BreakDebugger(): qupzilla killed by SIGABRT > Apparent cause: selinux-policy > Reason: because "setenforce 0" works around it > F25 affected?: unknown This is now known to also affect F25. > 3. https://bugzilla.redhat.com/show_bug.cgi?id=1364781 > glibc 2.24 (2.23.90) breaks Chromium and QtWebEngine > Received signal 4 ILL_ILLOPN 7f58262eac90 > Apparent cause: glibc > Reason: bisecting of OpenEmbedded changes by the OpenEmbedded folks: > https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg82915.html > F25 affected?: probably yes (it has the same glibc version) And this too. So all 3 bugs affect both F25 and Rawhide. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [packaging] Needs advice on using ExclusiveArch or ExcludeArch
Luya Tshimbalanga wrote: > Igor mentioned it is possible to build embree without that instruction > which is beyond my current skills thus bringing more questions. It is possible to build Embree without SSE3 and beyond (including AVX), i.e., with only SSE2, but, as everything beyond SSE2 is runtime-detected, it is not necessary to disable it completely. > Considering the recent LuxRender required embree, won't building without > these instructions set impact such dependancy? The only impact it would have is on performance. But again, it is not necessary nor desirable to disable runtime-detected support for vector instructions. It is only a problem when they are used unconditionally. The only issue is really that SSE2 is required unconditionally, but it doesn't look like there is much that can be done about it. This is unfortunate, because it also breaks support for all non-x86 architectures. But it would be a lot of work to fix that. (And looking at LuxRender, I also see hardcoded SSE2 usage there all over the place, both in hardcoded compile flags and in the code. So Embree is not the only problem there.) Also note that it is fine to require SSE2 (and also SSE(1) and MMX) on x86_64. All x86_64 CPUs support SSE2 (and lower). It is only a problem on i686 (and non non-x86 architectures where the code likely won't build at all). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Long live YUM!
On Mon, 8 Aug 2016 19:39:55 + Zbigniew Jędrzejewski-Szmek wrote: ...snip... So, all these have their own upstreams and their own progress on moving to python3. > anaconda-yum-plugins > bodhi-client https://github.com/fedora-infra/bodhi/issues/637 > copr-frontend > createrepo Unlikely I suspect to move, instead things should/can move to createrepo_c > fedora-gooey-karma > fusioninventory-agent-yum-plugin > koji https://bugzilla.redhat.com/show_bug.cgi?id=1024827 > mach Wonder what still pulls this in? > mash > mirrormanager https://github.com/fedora-infra/mirrormanager2/issues/139 > mock > nagios-plugins-check-updates > pulp-rpm-yumplugins > pungi > python-dnf-plugins-extras-migrate > python-imgcreate > rbm > repoview > rpmdepsize > snake > subscription-manager > system-config-kickstart > > On this list koji, mock, bodhi-client are important, because they > force fedora packagers to have yum installed. Fedora infra packages > like mirrormanager, pungi would be nice to de-yum too. > The rest not so much I think, e.g. subscription-manager is replaced by > dnf-plugin-subscription-manager, createrepo by createrepo_c, etc. Yeah, I am sure help would be welcomed in many of these places... kevin pgpJ1f7htcPKK.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Long live YUM!
On Mon, Aug 08, 2016 at 11:56:20AM +0200, Marcin Juszkiewicz wrote:
> I updated my system today and noticed that one of updated packages was
> "yum". Yes, that package manager tool we were supposed to obsolete with
> switch to "dnf" few releases ago.
>
> So I decided to remove it:
>
> 11:53 root@puchatek:~# LANGUAGE=C dnf remove yum
> Dependencies resolved.
This list includes both packages that depend on yum and
packages that yum depends on (it seems you have autoremove enabled).
A better list is:
$ dnf repoquery --releasever=rawhide --alldeps --whatrequires yum --qf %{name} \
| grep -v '^yum'
anaconda-yum-plugins
bodhi-client
copr-frontend
createrepo
fedora-gooey-karma
fusioninventory-agent-yum-plugin
koji
mach
mash
mirrormanager
mock
nagios-plugins-check-updates
pulp-rpm-yumplugins
pungi
python-dnf-plugins-extras-migrate
python-imgcreate
rbm
repoview
rpmdepsize
snake
subscription-manager
system-config-kickstart
On this list koji, mock, bodhi-client are important, because they
force fedora packagers to have yum installed. Fedora infra packages
like mirrormanager, pungi would be nice to de-yum too.
The rest not so much I think, e.g. subscription-manager is replaced by
dnf-plugin-subscription-manager, createrepo by createrepo_c, etc.
Zbyszek
>
> Package ArchVersion Repository
>Size
>
> Removing:
> bodhi-client noarch 0.9.12.2-5.fc25 @rawhide 27 k
> brewkoji noarch 1.8-1.fc17@System10 k
> createrepo noarch 0.10.3-10.fc25@rawhide 301 k
> createrepo_c x86_64 0.10.0-5.fc25 @rawhide 150 k
> createrepo_c-libsx86_64 0.10.0-5.fc25 @rawhide 207 k
> drpm x86_64 0.3.0-3.fc25 @rawhide 142 k
> dumpet x86_64 2.1-12.fc24 @rawhide 38 k
> fedora-packager noarch 0.5.10.7-3.fc25 @rawhide 80 k
> fedpkg noarch 1.24-4.fc25 @rawhide 87 k
> koji noarch 1.10.1-11.fc25@rawhide 1.1 M
> livecd-tools x86_64 1:23.3-2.fc25 @rawhide 147 k
> loraxx86_64 25.12-1.fc26 @rawhide 534 k
> lorax-templates-generic x86_64 25.12-1.fc26 @rawhide 111 k
> mock noarch 1.2.18-2.fc25 @rawhide 1.2 M
> packagedb-clinoarch 2.13-2.fc25 @rawhide 222 k
> pyrpkg noarch 1.46-2.fc25 @rawhide 434 k
> python-dockerfile-parse noarch 0.0.5-5.fc25 @rawhide 67 k
> python-imgcreate x86_64 1:23.3-2.fc25 @rawhide 282 k
> python-kickstart noarch 2.31-1.fc25 @rawhide 1.7 M
> python-ordered-set noarch 2.0.0-4.fc25 @rawhide 15 k
> python-osbs-client noarch 0.24-2.fc25 @rawhide 429 k
> python2-deltarpm x86_64 3.6-17.fc25 @rawhide 44 k
> python2-iniparse noarch 0.4-20.fc25 @rawhide 113 k
> python2-pygpgme x86_64 0.3-18.fc25 @rawhide 306 k
> python2-yubico noarch 1.3.2-3.fc25 @rawhide 244 k
> python3-beaker noarch 1.5.4-14.fc25 @rawhide 355 k
> python3-mako noarch 1.0.3-3.fc25 @rawhide 755 k
> pyusbnoarch 1.0.0-2.fc25 @rawhide 405 k
> rhpkgnoarch 1.18-2.fc20 @brew 125 k
> squashfs-tools x86_64 4.3-12.fc24 @rawhide 380 k
> system-config-keyboard noarch 1.4.0-10.fc25 @rawhide 40 k
> system-config-keyboard-base noarch 1.4.0-10.fc25 @rawhide 469 k
> yum noarch 3.4.3-510.fc25@rawhide 5.6 M
> yum-langpacksnoarch 0.4.5-3.fc24 @rawhide 66 k
> yum-utilsnoarch 1.1.31-510.fc25 @rawhide 334 k
>
> Transaction Summary
>
> Remove 35 Packages
>
> Installed size: 16 M
> Is this ok [y/N]: n
> Operation aborted.
>
>
> Are there plans to migrate tools/packages to stop depending on "yum" in
> Fedora 25-26 cycles?
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [packaging] Needs advice on using ExclusiveArch or ExcludeArch
On 07/08/16 02:02 PM, Kevin Kofler wrote: > Luya Tshimbalanga wrote: >> I am currently packaging embree [0] which is required by recent release >> of LuxRender. The bad news is embree >> (https://embree.github.io/downloads.html) is only >> available for 64 bits architectures meaning all others i.e. i686[1] and >> armv7hl[2] will fail to build. >> >> Either i have to use ExclusiveArch or ExcludeArch parameter in spec >> file. Advice needed. > This software is clearly x86-only (the required SSE2 does not exist on any > other architecture) and as such should be ExclusiveArch. Whether you should > make it ExclusiveArch: x86_64 or whether you should also enable 32-bit x86 > is up for debate. It is the usual issue of upstream not supporting non-SSE2 > CPUs. Fedora i686 packages are supposed to work without SSE2 (in fact, > without ANY vector instructions, even MMX and SSE), but it is nicer to the > users to have the software available for some 32-bit x86 CPUs than for none > at all. But either way, it clearly does not make sense to enumerate all the > non-x86 architectures in ExcludeArch, ExclusiveArch is the right concept. > > Kevin Kofler > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org Thank you Kevin for the detailed explanation related to SSE2 support. In that case, I will use ExclusiveArch. Igor mentioned it is possible to build embree without that instruction which is beyond my current skills thus bringing more questions. Considering the recent LuxRender required embree, won't building without these instructions set impact such dependancy? -- Luya Tshimbalanga Graphic & Web Designer E: l...@fedoraproject.org W: http://www.coolest-storm.net signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Attempting to contact unresponsive maintainer - mnagy
On Mon, Aug 8, 2016 at 10:57 AM, Kevin Fenzi wrote: > On Wed, 27 Jul 2016 13:03:52 -0600 > Kevin Fenzi wrote: > > > Greetings, we've been told that the email addresses > > for this package maintainer is no longer valid. I'm starting the > > unresponsive maintainer policy to find out if they are still > > interested in maintaining their packages (and if so, have them update > > their email addresses in FAS). If they're not interested in > > maintaining or we can't locate them I'll have FESCo orphan the > > packages so that others can take them over. > > > > If you have a way to contact this maintainer, please let them > > know that we'd appreciate knowing what to do with their packages. > > Thanks! > > > > User mnagy - former email mg...@redhat.com > > > > Point of contact: > > > > rpms/itzam-core -- Library for creating and manipulating > > keyed-access database files ( master f25 f24 f23 el6 el5 ) > > rpms/messiggy -- Messiggy is a database of celestial objects ( master > > f25 f24 f23 el6 el5 ) > > I have no orphaned these packages and they need new points of contact. > > kevin > > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > > Both taken. -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Attempting to contact unresponsive maintainer - mnagy
On Wed, 27 Jul 2016 13:03:52 -0600 Kevin Fenzi wrote: > Greetings, we've been told that the email addresses > for this package maintainer is no longer valid. I'm starting the > unresponsive maintainer policy to find out if they are still > interested in maintaining their packages (and if so, have them update > their email addresses in FAS). If they're not interested in > maintaining or we can't locate them I'll have FESCo orphan the > packages so that others can take them over. > > If you have a way to contact this maintainer, please let them > know that we'd appreciate knowing what to do with their packages. > Thanks! > > User mnagy - former email mg...@redhat.com > > Point of contact: > > rpms/itzam-core -- Library for creating and manipulating > keyed-access database files ( master f25 f24 f23 el6 el5 ) > rpms/messiggy -- Messiggy is a database of celestial objects ( master > f25 f24 f23 el6 el5 ) I have no orphaned these packages and they need new points of contact. kevin pgpv8wx2DYWSm.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
limb changed jplesnik's package request for perl-Test-Timer in f25 from Awaiting Review to Approved
limb changed jplesnik's package request for perl-Test-Timer in f25 from Awaiting Review to Approved https://admin.fedoraproject.org/pkgdb/package/perl-Test-Timer/ -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/perl-de...@lists.fedoraproject.org
Attempting to contact unresponsive maintainer - lkardos
Greetings, we've been told that the email addresses for this package maintainer is no longer valid. I'm starting the unresponsive maintainer policy to find out if they are still interested in maintaining their packages (and if so, have them update their email addresses in FAS). If they're not interested in maintaining or we can't locate them I'll have FESCo orphan the packages so that others can take them over. If you have a way to contact this maintainer, please let them know that we'd appreciate knowing what to do with their packages. Thanks! User lkardos - former email - lkar...@redhat.com Point of contact: rpms/scl-utils -- Utilities for alternative packaging ( master f25 f24 f23 el6 el5 ) Co-maintainer: rpms/rpm -- The RPM package management system ( master f25 f24 f23 ) kevin pgpgjSr3_RZo3.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Improvements of Fedora Sponsorship process
I wanted to elaborate on one of the ideas I threw out during that discussion. We (need to|should|strive really hard to) treat new packagers more like new volunteers for fedora infrastructure. Except that we should accept that packaging is really, really hard when you don't know where to start and offer more hand-holding. The infrastructure process seems to work really well (for infrastructure, at least) and the new packager process seems to _not_ work really well, so Note that I'm assuming here that we don't have that miraculous review handling program (fresque). I know someone was working on it, and I should probably see what state it's in, but I'm way behind after being on vacation for a month. It wouldn't really alter the central point anyway. My random proposal for that is to: 1) Add more "front end" to the process (which, yeah, means more process when we already have too much process). Packagers should send an introduction and such, perhaps even before they have a package. They may need help doing that, after all, and we should be providing that help. 2) At some point, they should be assigned three (or some other reasonable number) mentors, including (if possible) one from the same region (from the ambassadors pool or one of the regional groups) just to help with language issues in case they come up. These don't have to be sponsors, but at least two should be packagers. Hopefully one is familiar with and has interest in the "type" of software they intend to package. (Python, Java, games, whatnot.) 3) They should also be assigned a sponsor from the sponsor pool, if one is not part of the mentor group. This person will oversee the process and actually give the permissions, though they don't necessarily have to do the heavy lifting. 3) These mentors should be "on hand" to assist the packager, answer questions, etc. 4) We should encourage that new packagers put their specs in pagure so that people can file pull requests against them. Probably small specs for easy packages don't need this. This conveniently gives them a base to have copr pull from, assuming I understand that functionality of copr. They'll still have to post updates to bugzilla but we might be able to automate that. 5) A whole bunch more automation to get packages checked and people pinged would of course be quite useful here. - J< -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Self Introduction: Frederico Lima
Welcome to Fedora. Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat - Original Message - From: "Frederico Lima (Projeto Fedora)" To: "devel" Sent: Friday, August 5, 2016 11:50:46 PM Subject: Self Introduction: Frederico Lima Hi, my name is Frederico Lima, fas: fredlima, I'm from Brazil I'm a new Fedora package maintainer, My package was pushed to stable repo, its name is Quake 2. https://admin.fedoraproject.org/pkgdb/package/rpms/quake2/ I use Fedora now but before I've used Suse, Slackware and Debian distros. I work as a system developer for the brazilian government using opensource software (and some not). I use Fedora 24 on my workstation, my desktop and on my laptop. Thats it, thank you for this great community. Frederico Lima fredericolima.com.br -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora 25-20160808.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Cloud_base raw-xz i386 Atomic raw-xz x86_64 Minimal raw-xz armhfp Failed openQA tests: 35/88 (x86_64), 5/17 (i386) ID: 27755 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27755 ID: 27757 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/27757 ID: 27758 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27758 ID: 27764 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/27764 ID: 27765 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27765 ID: 27766 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/27766 ID: 27767 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/27767 ID: 27768 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/27768 ID: 27769 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27769 ID: 27775 Test: i386 KDE-live-iso install_default URL: https://openqa.fedoraproject.org/tests/27775 ID: 2 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/2 ID: 27780 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/27780 ID: 27783 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27783 ID: 27787 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/27787 ID: 27789 Test: x86_64 Server-dvd-iso server_cockpit_default URL: https://openqa.fedoraproject.org/tests/27789 ID: 27805 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/27805 ID: 27807 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/27807 ID: 27808 Test: x86_64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/27808 ID: 27809 Test: x86_64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/27809 ID: 27810 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/27810 ID: 27811 Test: x86_64 universal install_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/27811 ID: 27812 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/27812 ID: 27813 Test: x86_64 universal install_ext3@uefi URL: https://openqa.fedoraproject.org/tests/27813 ID: 27814 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/27814 ID: 27815 Test: x86_64 universal install_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/27815 ID: 27816 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/27816 ID: 27818 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/27818 ID: 27819 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/27819 ID: 27820 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/27820 ID: 27821 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/27821 ID: 27822 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/27822 ID: 27823 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/27823 ID: 27824 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/27824 ID: 27825 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/27825 ID: 27826 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/27826 ID: 27827 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/27827 ID: 27840 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/27840 ID: 27844 Test: x86_64 universal install_multi@uefi URL: https://openqa.fedoraproject.org/tests/27844 ID: 27856 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/27856 ID: 27857 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/27857 Passed openQA tests: 39/88 (x86_64), 12/17 (i386) Skipped openQA tests: 12 of 105 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraprojec
rubygem-thin license change
Hi, rubygem-thin package changes from (GPLv2 or Ruby) and MIT to (GPLv2+ or Ruby) and BSD and MIT Regards, Jun Aruga -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [HEADS UP] sendmail-devel will be renamed to sendmail-milter-devel
Hi,
after some investigation, I think you are right :). Thanks! I fixed it
and a new version sendmail-8.15.2-9.fc26 is currently being built.
Regards
Ondra
On 08/05/2016 12:14 PM, Paul Howarth wrote:
Hi,
On 29/07/16 14:26, Ondřej Lysoněk wrote:
Hi,
on Friday, August 5, I will rebuild the sendmail package for rawhide,
because of a rename of sendmail-devel to sendmail-milter-devel. This is
due to [1]. Please change BuildRequires and Requires of your packages
accordingly.
List of know affected packages:
clamav
milter-greylist
milter-regex
mimedefang
opendkim
opendmarc
python-pymilter
spamass-milter
[1] https://bugzilla.redhat.com/show_bug.cgi?id=891288
I think you may have made a mistake with the obsoletes/provides for the
upgrade path.
You have:
Provides: sendmail-devel%{?_isa} = %{version}-%{release}
Obsoletes: sendmail-devel%{?_isa} < 8.15.2-8
I think it should be:
Obsoletes: sendmail-devel < 8.15.2-8
Provides: sendmail-devel = %{version}-%{release}
Provides: sendmail-devel%{?_isa} = %{version}-%{release}
Obsoletes: works on package names, not the virtual provides that include
%{?_isa}. And the provides should include the version with and without
the %{?_isa}, since that's what the original package provided and either
might be used by existing packages.
Cheers, Paul.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Reviews Weekly
Start Date: 2016-08-01 08:45:39.575096 End Date: 2016-08-08 08:45:39.575096 Jeroen van Meeuwen : 114 https://bugzilla.redhat.com/show_bug.cgi?id=1364676 nodejs-try-open https://bugzilla.redhat.com/show_bug.cgi?id=1364148 nodejs-glob-base https://bugzilla.redhat.com/show_bug.cgi?id=1364697 nodejs-leche https://bugzilla.redhat.com/show_bug.cgi?id=1364229 nodejs-currently-unhandled https://bugzilla.redhat.com/show_bug.cgi?id=1356277 nodejs-commondir https://bugzilla.redhat.com/show_bug.cgi?id=1364684 nodejs-ansi-cyan https://bugzilla.redhat.com/show_bug.cgi?id=1364127 nodejs-is-dotfile https://bugzilla.redhat.com/show_bug.cgi?id=1364199 nodejs-estraverse-fb https://bugzilla.redhat.com/show_bug.cgi?id=1364141 nodejs-glob-parent https://bugzilla.redhat.com/show_bug.cgi?id=1364180 nodejs-caching-transform https://bugzilla.redhat.com/show_bug.cgi?id=1364659 nodejs-plur https://bugzilla.redhat.com/show_bug.cgi?id=1364226 nodejs-indent-string https://bugzilla.redhat.com/show_bug.cgi?id=1347893 nodejs-del https://bugzilla.redhat.com/show_bug.cgi?id=1364177 nodejs-find-cache-dir https://bugzilla.redhat.com/show_bug.cgi?id=1364165 nodejs-object-dot-omit https://bugzilla.redhat.com/show_bug.cgi?id=1347894 nodejs-replace-ext https://bugzilla.redhat.com/show_bug.cgi?id=1359426 nodejs-clap https://bugzilla.redhat.com/show_bug.cgi?id=1364184 nodejs-lcid https://bugzilla.redhat.com/show_bug.cgi?id=1356222 nodejs-cross-spawn https://bugzilla.redhat.com/show_bug.cgi?id=1356280 nodejs-find-up https://bugzilla.redhat.com/show_bug.cgi?id=1364159 nodejs-is-glob https://bugzilla.redhat.com/show_bug.cgi?id=1364174 nodejs-pkg-dir https://bugzilla.redhat.com/show_bug.cgi?id=1364228 nodejs-read-pkg-up https://bugzilla.redhat.com/show_bug.cgi?id=1364683 nodejs-ansi-magenta https://bugzilla.redhat.com/show_bug.cgi?id=1347895 nodejs-vinyl https://bugzilla.redhat.com/show_bug.cgi?id=1359315 nodejs-array-find-index https://bugzilla.redhat.com/show_bug.cgi?id=1364213 nodejs-es6-map https://bugzilla.redhat.com/show_bug.cgi?id=1364680 nodejs-set-getter https://bugzilla.redhat.com/show_bug.cgi?id=1364077 nodejs-signal-exit https://bugzilla.redhat.com/show_bug.cgi?id=1364225 nodejs-repeating https://bugzilla.redhat.com/show_bug.cgi?id=1347883 nodejs-co-mocha https://bugzilla.redhat.com/show_bug.cgi?id=1364212 nodejs-es6-set https://bugzilla.redhat.com/show_bug.cgi?id=1364661 nodejs-interpret https://bugzilla.redhat.com/show_bug.cgi?id=1364082 nodejs-pkg-up https://bugzilla.redhat.com/show_bug.cgi?id=1356270 nodejs-append-transform https://bugzilla.redhat.com/show_bug.cgi?id=1364675 nodejs-npm-license https://bugzilla.redhat.com/show_bug.cgi?id=1364169 nodejs-extglob https://bugzilla.redhat.com/show_bug.cgi?id=1353367 nodejs-shelljs-nodecli https://bugzilla.redhat.com/show_bug.cgi?id=1364654 nodejs-detect-file https://bugzilla.redhat.com/show_bug.cgi?id=1364625 nodejs-orchestrator https://bugzilla.redhat.com/show_bug.cgi?id=1364668 nodejs-re-emitter https://bugzilla.redhat.com/show_bug.cgi?id=1364219 nodejs-has-gulplog https://bugzilla.redhat.com/show_bug.cgi?id=1364673 nodejs-package-license https://bugzilla.redhat.com/show_bug.cgi?id=1353390 nodejs-type-name https://bugzilla.redhat.com/show_bug.cgi?id=1364650 nodejs-global-prefix https://bugzilla.redhat.com/show_bug.cgi?id=1364657 nodejs-resolve-pkg https://bugzilla.redhat.com/show_bug.cgi?id=1347897 nodejs-convert-source-map https://bugzilla.redhat.com/show_bug.cgi?id=1356308 nodejs-win-spawn https://bugzilla.redhat.com/show_bug.cgi?id=1364623 nodejs-gulplog https://bugzilla.redhat.com/show_bug.cgi?id=1364682 nodejs-ansi-yellow https://bugzilla.redhat.com/show_bug.cgi?id=1364210 nodejs-esrecurse https://bugzilla.redhat.com/show_bug.cgi?id=1364078 nodejs-read-pkg https://bugzilla.redhat.com/show_bug.cgi?id=1364687 nodejs-arr-union https://bugzilla.redhat.com/show_bug.cgi?id=1364667 nodejs-ignore https://bugzilla.redhat.com/show_bug.cgi?id=1364221 nodejs-map-obj https://bugzilla.redhat.com/show_bug.cgi?id=1364182 nodejs-cliui https://bugzilla.redhat.com/show_bug.cgi?id=1356309 nodejs-invert-kv https://bugzilla.redhat.com/show_bug.cgi?id=1364677 nodejs-read-file https://bugzilla.redhat.com/show_bug.cgi?id=1364701 nodejs-uc-dot-micro https://bugzilla.redhat.com/sho
[POC-change] Fedora packages point of contact updates
Change in package status over the last 168 hours 3 packages were orphaned compat-gnutls28 [master] was orphaned by nmav Compat package with gnutls library ABI version 28 https://admin.fedoraproject.org/pkgdb/package/compat-gnutls28 pykka [f23, master, el6, f25, f24] was orphaned by jdieter Python library that provides concurrency using actor model https://admin.fedoraproject.org/pkgdb/package/pykka rubygem-git-up [f23, f24] was orphaned by jvcelak git command to fetch and rebase all branches https://admin.fedoraproject.org/pkgdb/package/rubygem-git-up 3 packages were retired compat-libuv010 [master, f25] was retired by piotrp Platform layer for node.js - compatibility library for nodejs 0.10.x https://admin.fedoraproject.org/pkgdb/package/compat-libuv010 rubygem-git-up [master, f25] was retired by vondruch, jvcelak git command to fetch and rebase all branches https://admin.fedoraproject.org/pkgdb/package/rubygem-git-up trytond-ldap-connection [master, f25] was retired by sharkcz ldap-connection module for Tryton https://admin.fedoraproject.org/pkgdb/package/trytond-ldap-connection 32 packages unorphaned -- bdii [master, f25] was unorphaned by ellert The Berkeley Database Information Index (BDII) https://admin.fedoraproject.org/pkgdb/package/bdii compat-libuv010 [f23, f24] was unorphaned by piotrp Platform layer for node.js - compatibility library for nodejs 0.10.x https://admin.fedoraproject.org/pkgdb/package/compat-libuv010 dpm-dsi [master, f25] was unorphaned by andreamanzi Disk Pool Manager (DPM) plugin for the Globus GridFTP server https://admin.fedoraproject.org/pkgdb/package/dpm-dsi globus-gatekeeper [master, f25] was unorphaned by ellert Globus Toolkit - Globus Gatekeeper https://admin.fedoraproject.org/pkgdb/package/globus-gatekeeper globus-gridftp-server [master, f25] was unorphaned by ellert Globus Toolkit - Globus GridFTP Server https://admin.fedoraproject.org/pkgdb/package/globus-gridftp-server globus-scheduler-event-generator [master, f25] was unorphaned by ellert Globus Toolkit - Scheduler Event Generator https://admin.fedoraproject.org/pkgdb/package/globus-scheduler-event-generator libart_lgpl [f23, master, f25, f24] was unorphaned by yselkowitz Library of graphics routines used by libgnomecanvas https://admin.fedoraproject.org/pkgdb/package/libart_lgpl libdv [f23, master, f25, f24] was unorphaned by sagitter Software decoder for DV format video https://admin.fedoraproject.org/pkgdb/package/libdv lightning [f23, master, f25, f24] was unorphaned by sagitter Library for generating assembly code on run time https://admin.fedoraproject.org/pkgdb/package/lightning node-gyp [f23, master, f25, f24, el6, epel7] was unorphaned by piotrp Node.js native addon build tool https://admin.fedoraproject.org/pkgdb/package/node-gyp noip [master, f25] was unorphaned by sergiomb A dynamic DNS update client https://admin.fedoraproject.org/pkgdb/package/noip nordugrid-arc [master, f25] was unorphaned by ellert Advanced Resource Connector Grid Middleware https://admin.fedoraproject.org/pkgdb/package/nordugrid-arc nordugrid-arc-gangliarc [master, f25] was unorphaned by ellert Ganglia monitoring for ARC services https://admin.fedoraproject.org/pkgdb/package/nordugrid-arc-gangliarc npm [f23, el6, epel7, f24] was unorphaned by piotrp Node.js Package Manager https://admin.fedoraproject.org/pkgdb/package/npm perl-Ace [f23, master, f25, f24] was unorphaned by jplesnik Perl module for interfacing with ACE bioinformatics databases https://admin.fedoraproject.org/pkgdb/package/perl-Ace perl-AutoClass [f23, master, f25, f24] was unorphaned by jplesnik Automatically define classes and objects for Perl https://admin.fedoraproject.org/pkgdb/package/perl-AutoClass perl-Convert-Binary-C [f23, master, f25, f24] was unorphaned by jplesnik Binary data conversion using C types https://admin.fedoraproject.org/pkgdb/package/perl-Convert-Binary-C perl-Data-Stag [f23, master, f25, f24] was unorphaned by jplesnik Perl package for Structured Tags datastructures https://admin.fedoraproject.org/pkgdb/package/perl-Data-Stag perl-GD-SVG [f23, master, f25, f24] was unorphaned by jplesnik GD::SVG enables SVG output from scripts written using GD https://admin.fedoraproject.org/pkgdb/package/perl-GD-SVG perl-Math-Derivative [f23, master, f25, f24] was unorphaned by jplesnik Numeric 1st and 2nd order differentiation https://admin.fedoraproject.org/pkgdb/package/perl-Math-Derivative perl-Math-Spline [f23, master, f25, f24] was unorphaned by jplesnik Cubic Spline Interpolation of data https://admin.fedoraproject.org/pkgdb/package/perl-Math-Spline perl-SVG [f23, mast
Re: Long live YUM!
On Mon, Aug 8, 2016 at 6:27 AM, Marcin Juszkiewicz wrote: > W dniu 08.08.2016 o 12:02, Christopher Meng pisze: >> On Monday, 8 August 2016, Marcin Juszkiewicz > >>> 11:53 root@puchatek:~# LANGUAGE=C dnf remove yum >>> Dependencies resolved. >>> >>> Package ArchVersion Repository >>>Size >>> >>> Removing: >>> bodhi-client noarch 0.9.12.2-5.fc25 @rawhide 27 k >>> brewkoji noarch 1.8-1.fc17@System10 k >> >> >> Fedora 17? > > I do not reinstall system every release. Then you need to do a "yum list extras" to check on deletable, outdated packages. > 12:26 root@puchatek:hrw# for f in `seq 16 26`;do printf "$f\t"; rpm > -qa|grep fc$f|wc -l;done > 16 0 > 17 1 > 18 0 > 19 2 > 20 3 > 21 5 > 22 18 > 23 11 > 24 1009 > 25 1845 > 26 427 > > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Can I request update of mock with fedora-25 configurations ?
>> > > Hello, >> > > After Fedora 25 Mass Branching , should be mock update with >> > > fedora- >> > > 25 >> > > configurations ? >> > > Other question where I should ask it ? bugzilla ? >> > bugzilla +1 >> Thanks, https://bugzilla.redhat.com/show_bug.cgi?id=1364754 > > Hi, > Anyone, can tell me how I generate the new file /etc/mock/*cfg for F25 > , I need this to generate config files for rpmfusion in mock-rpmfusion Copy the one from F-24 and update the spots where it says "24" to "25" is probably enough. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Can I request update of mock with fedora-25 configurations ?
On Dom, 2016-08-07 at 03:17 +0100, Sérgio Basto wrote: > On Sáb, 2016-08-06 at 20:40 -0500, Rex Dieter wrote: > > > > Sérgio Basto wrote: > > > > > > > > > > > Hello, > > > After Fedora 25 Mass Branching , should be mock update with > > > fedora- > > > 25 > > > configurations ? > > > Other question where I should ask it ? bugzilla ? > > bugzilla +1 > Thanks, https://bugzilla.redhat.com/show_bug.cgi?id=1364754 Hi, Anyone, can tell me how I generate the new file /etc/mock/*cfg for F25 , I need this to generate config files for rpmfusion in mock-rpmfusion ... Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Long live YUM!
W dniu 08.08.2016 o 12:02, Christopher Meng pisze: > On Monday, 8 August 2016, Marcin Juszkiewicz >> 11:53 root@puchatek:~# LANGUAGE=C dnf remove yum >> Dependencies resolved. >> >> Package ArchVersion Repository >>Size >> >> Removing: >> bodhi-client noarch 0.9.12.2-5.fc25 @rawhide 27 k >> brewkoji noarch 1.8-1.fc17@System10 k > > > Fedora 17? I do not reinstall system every release. 12:26 root@puchatek:hrw# for f in `seq 16 26`;do printf "$f\t"; rpm -qa|grep fc$f|wc -l;done 16 0 17 1 18 0 19 2 20 3 21 5 22 18 23 11 24 1009 25 1845 26 427 -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [HEADS UP] sendmail-devel will be renamed to sendmail-milter-devel
On 05/08/16 19:03, Ondřej Lysoněk wrote:
Hi,
this change is indeed happening only in F26 and later. There are no
plans to do the rename in earlier releases.
However, I'm not sure where the "0%{?rhel} > 7" condition in your spec
sample came from. I have no idea when the rename will get to RHEL, and I
would definitely warn about such a change.
The "0%{?rhel} > 7" was just a best guess about what might be in EL-8,
easily enough fixed if the change doesn't appear there. It helps me not
to forget about EPEL compatibility in my spec files.
Cheers, Paul.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Long live YUM!
On Mon, 8 Aug 2016 18:02:35 +0800 Christopher Meng wrote: > On Monday, 8 August 2016, Marcin Juszkiewicz > wrote: > > > I updated my system today and noticed that one of updated packages > > was "yum". Yes, that package manager tool we were supposed to > > obsolete with switch to "dnf" few releases ago. > > > > So I decided to remove it: > > > > 11:53 root@puchatek:~# LANGUAGE=C dnf remove yum > > Dependencies resolved. > > > > Package ArchVersion Repository > >Size > > > > Removing: > > bodhi-client noarch 0.9.12.2-5.fc25 @rawhide > > 27 k brewkoji noarch 1.8-1.fc17 > > @System10 k > > > Fedora 17? yep, looks like an outdated internal package, there is a new location for internal build tools. Dan -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Long live YUM!
On Monday, 8 August 2016, Marcin Juszkiewicz wrote: > I updated my system today and noticed that one of updated packages was > "yum". Yes, that package manager tool we were supposed to obsolete with > switch to "dnf" few releases ago. > > So I decided to remove it: > > 11:53 root@puchatek:~# LANGUAGE=C dnf remove yum > Dependencies resolved. > > Package ArchVersion Repository >Size > > Removing: > bodhi-client noarch 0.9.12.2-5.fc25 @rawhide 27 k > brewkoji noarch 1.8-1.fc17@System10 k Fedora 17? -- Yours sincerely, Christopher Meng http://cicku.me -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Long live YUM!
I updated my system today and noticed that one of updated packages was "yum". Yes, that package manager tool we were supposed to obsolete with switch to "dnf" few releases ago. So I decided to remove it: 11:53 root@puchatek:~# LANGUAGE=C dnf remove yum Dependencies resolved. Package ArchVersion Repository Size Removing: bodhi-client noarch 0.9.12.2-5.fc25 @rawhide 27 k brewkoji noarch 1.8-1.fc17@System10 k createrepo noarch 0.10.3-10.fc25@rawhide 301 k createrepo_c x86_64 0.10.0-5.fc25 @rawhide 150 k createrepo_c-libsx86_64 0.10.0-5.fc25 @rawhide 207 k drpm x86_64 0.3.0-3.fc25 @rawhide 142 k dumpet x86_64 2.1-12.fc24 @rawhide 38 k fedora-packager noarch 0.5.10.7-3.fc25 @rawhide 80 k fedpkg noarch 1.24-4.fc25 @rawhide 87 k koji noarch 1.10.1-11.fc25@rawhide 1.1 M livecd-tools x86_64 1:23.3-2.fc25 @rawhide 147 k loraxx86_64 25.12-1.fc26 @rawhide 534 k lorax-templates-generic x86_64 25.12-1.fc26 @rawhide 111 k mock noarch 1.2.18-2.fc25 @rawhide 1.2 M packagedb-clinoarch 2.13-2.fc25 @rawhide 222 k pyrpkg noarch 1.46-2.fc25 @rawhide 434 k python-dockerfile-parse noarch 0.0.5-5.fc25 @rawhide 67 k python-imgcreate x86_64 1:23.3-2.fc25 @rawhide 282 k python-kickstart noarch 2.31-1.fc25 @rawhide 1.7 M python-ordered-set noarch 2.0.0-4.fc25 @rawhide 15 k python-osbs-client noarch 0.24-2.fc25 @rawhide 429 k python2-deltarpm x86_64 3.6-17.fc25 @rawhide 44 k python2-iniparse noarch 0.4-20.fc25 @rawhide 113 k python2-pygpgme x86_64 0.3-18.fc25 @rawhide 306 k python2-yubico noarch 1.3.2-3.fc25 @rawhide 244 k python3-beaker noarch 1.5.4-14.fc25 @rawhide 355 k python3-mako noarch 1.0.3-3.fc25 @rawhide 755 k pyusbnoarch 1.0.0-2.fc25 @rawhide 405 k rhpkgnoarch 1.18-2.fc20 @brew 125 k squashfs-tools x86_64 4.3-12.fc24 @rawhide 380 k system-config-keyboard noarch 1.4.0-10.fc25 @rawhide 40 k system-config-keyboard-base noarch 1.4.0-10.fc25 @rawhide 469 k yum noarch 3.4.3-510.fc25@rawhide 5.6 M yum-langpacksnoarch 0.4.5-3.fc24 @rawhide 66 k yum-utilsnoarch 1.1.31-510.fc25 @rawhide 334 k Transaction Summary Remove 35 Packages Installed size: 16 M Is this ok [y/N]: n Operation aborted. Are there plans to migrate tools/packages to stop depending on "yum" in Fedora 25-26 cycles? -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Pending ACLs
Not works. You need then talk with the requester and then decide to deny or not. And if he tries again, do the process again. What you can' t do is letting anyone waiting or making the package hostage. About the notifications, yes, everyone get notifications if set your email properly or use @fedoraproject, and is working well as delivering. So increase the amount of notifications or do it in public lists will not fix the issue that is really is, the package owner. Would even piss of more the maintainers or other users ( in case of public ) If he decide to ignore or just not reading, then all efforts to " increase" or " improve" notifications system is useless. Packages should have at least two lead owners and one group that can take equal decisions over it. On Sat, Aug 6, 2016 at 7:37 PM, wrote: > Sometimes a maintainer doesn't want to approve ACLs for "reasons" but > doesn't want to reject the request for various reasons including the > requestor re-request of denied requests. > > Dennis > > On August 5, 2016 3:34:58 PM GMT+02:00, Helio Chissini de Castro < > he...@kde.org> wrote: >> >> I have a strong opinion over this >> >> All the ACL's should be accepted, doesn't matter the level. >> And why i think of this ? >> >> Two simple reasons: >> - The packager abandoned the package, because several reasons, and then >> is far away from Fedora systems for some time >> - The packager is actively using Fedora, but seen not care to even >> properly take care of his package, not in the minimal sense to deny the >> ACL, which would be acceptable. >> >> In both cases, the package became hostage to someone that for sure aren't >> caring much for the distro, unless prove me wrong. >> >> >> >> On Fri, Aug 5, 2016 at 3:07 PM, Pierre-Yves Chibon >> wrote: >> >>> On Fri, Aug 05, 2016 at 11:14:02AM +0200, Dan Horák wrote: >>> > On Thu, 4 Aug 2016 20:41:56 +0100 >>> > "Richard W.M. Jones" wrote: >>> > >>> > > On Thu, Aug 04, 2016 at 04:43:40PM +0200, Fabio Alessandro Locati >>> > > wrote: >>> > > > Hi all, >>> > > > >>> > > > This morning, during the automation workshop, I had the occasion of >>> > > > speaking about this with Pingou and Threebean. >>> > > > Thanks to Pingou hints, I've created a query to get pending ACL >>> from >>> > > > pkgdb. >>> > > > What I'd like to share with you all is the list of users that can >>> > > > approve/deny ACL requests (older than 1 month) but have not done it >>> > > > yet (the number refers to the number of ACL pending). >>> > > > >>> > > > I think that people should take care of the pending ACL they can >>> > > > approve/deny and actually approve or deny them ASAP. >>> > > >>> > > Your email needs a "call to action" link, otherwise no one will know >>> > > what they are supposed to do about it. In this case it's probably: >>> > > >>> > > https://admin.fedoraproject.org/pkgdb/acl/pending/ >>> > > >>> > > However I visited the above URL, logged in, and it says: >>> > > >>> > > Pending ACLs >>> > > No pending ACLs for you >>> > >>> > also there should be no action required from the owner for >>> "watchcommit" >>> > or "watchbugzilla" requests, looks as a bug in the conversion when >>> > deploying the recent pkgdb >>> >>> Well, the recent pkgdb is already quite a bit old and it should >>> definitively >>> auto-accept the watch* ACLs. >>> Do you have a link so I could look at the package/history? >>> >>> Thanks, >>> Pierre >>> -- >>> devel mailing list >>> devel@lists.fedoraproject.org >>> https://lists.fedoraproject.org/admin/lists/de...@lists.fedo >>> raproject.org >>> >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org >> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
