Orphan Spyder package
Hi, "Spyder is the Scientific PYthon Development EnviRonment" I no longer use Spyder, so I'm looking for someone who wants to take it over. Please, ask for ACLs for it if you would like to take it over. https://admin.fedoraproject.org/pkgdb/package/spyder/ Radek Novacek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaned packages looking for new Point of Contact
Am 2015-10-01 06:50, schrieb Michael Cronenworth: On 09/30/2015 11:47 PM, Jens Lody wrote: I want to take these theree, but they are still not official orphaned, so I can not take ownership. Should I just wait until the status changed in pkgdb ? Those packages were orphaned but they were immediately picked up. Send a message to the new POC to request co-maintainership. https://admin.fedoraproject.org/pkgdb/package/fillets-ng/timeline https://admin.fedoraproject.org/pkgdb/package/frozen-bubble/timeline I should have looked into the timeline (I still have to learn to use all available tools). It's okay for me. I just wanted the packages to stay in Fedora/Epel and prevent retiring. I'm quite busy at work at the moment and interested in unretiring aeskulap. So I think I will concentrate on this (for the moment). It's a little more work. Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
bugzilla search missing fields; can't find if F21 dracut bug filed lately
Is anybody else bothered by the latest BZ changes? Where does one select the Fedora release to limit search results to? And how does one figure out where to select kernel or dracut? Those scroll lists are much too difficult to find anything in, overscrolling nearly always except doing one line at a time, which would take an eternity to locate anything not starting with z or a. I'm trying to figure out if anyone else has filed a bug that dracut builds F21 32 bit Athlon/VIA chipset initrds without any storage driver (pata_via needed) sometime after kernel 4.1.4 was replaced with whatever came next. 4.1.4 works, but 4.1.7 produces emergency shell for failure to find root device whether root=LABEL= or root=devname or root=UUID= on cmdline. Also, rebooting attemps from the emergency shell utterly fail, and this after taking more than 3 minutes just to reach the emergency shell after selecting a Grub stanza. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bugzilla search missing fields; can't find if F21 dracut bug filed lately
Dne 1.10.2015 v 09:38 Felix Miata napsal(a): > Is anybody else bothered by the latest BZ changes? Where does one select the > Fedora release to limit search results to? And how does one figure out where > to select kernel or dracut? Those scroll lists are much too difficult to find > anything in, overscrolling nearly always except doing one line at a time, > which would take an eternity to locate anything not starting with z or a. > > I'm trying to figure out if anyone else has filed a bug that dracut builds > F21 32 bit Athlon/VIA chipset initrds without any storage driver (pata_via > needed) sometime after kernel 4.1.4 was replaced with whatever came next. > 4.1.4 works, but 4.1.7 produces emergency shell for failure to find root > device whether root=LABEL= or root=devname or root=UUID= on cmdline. Also, > rebooting attemps from the emergency shell utterly fail, and this after > taking more than 3 minutes just to reach the emergency shell after selecting > a Grub stanza. Does http://bugz.fedoraproject.org/dracut work for you? Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bugzilla search missing fields; can't find if F21 dracut bug filed lately
Vít Ondruch composed on 2015-10-01 04:22 (UTC-0400): > Does http://bugz.fedoraproject.org/dracut work for you? Marginally better than nothing: doesn't any kind of list in SeaMonkey (maybe because of noscript?) tiny gray (painful) text no way to choose sort order no way to say only bugs newer than specified date Nothing found in that list on point I was looking for. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bugzilla search missing fields; can't find if F21 dracut bug filed lately
On 10/01/2015 09:38 AM, Felix Miata wrote: > Is anybody else bothered by the latest BZ changes? Where does one select the > Fedora release to limit search results to? Under Custom Search: https://bugzilla.redhat.com/buglist.cgi?classification=Fedora&component=dracut&f1=version&list_id=3919791&o1=equals&product=Fedora&query_format=advanced&v1=21 > And how does one figure out where > to select kernel or dracut? You type “dra” in the component field and select it from the drop-down list. (You need to enable Javascript for this to work.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Non-responsive maintainer: Karol Trzcionka (karlik)
Hi, I've been unsuccessfull in getting any reply from Karol Trzcionka (karlik) on bug #1264044, neither through BZ nor per direct email. Per non-responsive maintainer policy: Anyone know whether karlik is still active in Fedora / alternative ways to contact? Other packages of karlik: doodle -- Doodle is a tool to quickly search the documents on a computer ( master f23 f22 f21 ) gmediaserver -- UPnP compatible media server for the GNU system ( master f23 f22 f21 ) quesoglc -- The OpenGL Character Renderer ( master f23 f22 f21 ) tesseract -- Raw OCR Engine ( master f23 f22 f21 el6 ) tesseract-langpack -- Langpacks for tesseract ( master f23 f22 f21 el6 ) warzone2100 -- Innovative 3D real-time strategy ( master f23 f22 f21 ) Thanks Sandro -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bugzilla search missing fields; can't find if F21 dracut bug filed lately
Dne 1.10.2015 v 10:53 Felix Miata napsal(a): > Vít Ondruch composed on 2015-10-01 04:22 (UTC-0400): > >> Does http://bugz.fedoraproject.org/dracut work for you? > Marginally better than nothing: > > doesn't any kind of list in SeaMonkey (maybe because of noscript?) > tiny gray (painful) text > no way to choose sort order > no way to say only bugs newer than specified date > > Nothing found in that list on point I was looking for. You can follow the "open bugs" link, which redirects to BZ and then "Edit search as you wish" Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule of Fedora 24 published
Hi, let me inform you that schedule of Fedora 24 has been approved by FESCo [1]. You can find the schedule on [2] and [3]. The key dates follows: * Alpha Release Public Availability: 2016-03-01 * Beta Release Public Availability: 2016-04-12 * Final Release Public Availability (GA): 2016-05-17 I am currently in the process of cleaning the schedule from old stuff, so if you are aware of anything what is already deprecated, or something what is missing in the schedule, please let me know. [1] https://fedorahosted.org/fesco/ticket/1480 [2] https://fedoraproject.org/wiki/Releases/24/Schedule [3] https://fedorapeople.org/groups/schedule/f-24/f-24-key-tasks.html Regards, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20151001 changes
Compose started at Thu Oct 1 05:15:03 UTC 2015 Broken deps for i386 -- [CableSwig] CableSwig-3.20.0-13.fc23.i686 requires gccxml [IQmol] IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2 [bro] bro-2.3.2-6.fc23.i686 requires libjemalloc.so.1 [bwm-ng] bwm-ng-0.6-18.fc24.i686 requires libstatgrab.so.6 [derelict] derelict-3-32.20141022git7fc1714.fc23.i686 requires libphobos2-ldc-debug.so.66 derelict-3-32.20141022git7fc1714.fc23.i686 requires libdruntime-ldc-debug.so.66 derelict-AL-3-32.20141022git7fc1714.fc23.i686 requires libphobos2-ldc-debug.so.66 derelict-AL-3-32.20141022git7fc1714.fc23.i686 requires libdruntime-ldc-debug.so.66 derelict-ALURE-3-32.20141022git7fc1714.fc23.i686 requires libphobos2-ldc-debug.so.66 derelict-ALURE-3-32.20141022git7fc1714.fc23.i686 requires libdruntime-ldc-debug.so.66 derelict-ASSIMP3-3-32.20141022git7fc1714.fc23.i686 requires libphobos2-ldc-debug.so.66 derelict-ASSIMP3-3-32.20141022git7fc1714.fc23.i686 requires libdruntime-ldc-debug.so.66 derelict-FI-3-32.20141022git7fc1714.fc23.i686 requires libphobos2-ldc-debug.so.66 derelict-FI-3-32.20141022git7fc1714.fc23.i686 requires libdruntime-ldc-debug.so.66 derelict-FT-3-32.20141022git7fc1714.fc23.i686 requires libphobos2-ldc-debug.so.66 derelict-FT-3-32.20141022git7fc1714.fc23.i686 requires libdruntime-ldc-debug.so.66 derelict-GL3-3-32.20141022git7fc1714.fc23.i686 requires libphobos2-ldc-debug.so.66 derelict-GL3-3-32.20141022git7fc1714.fc23.i686 requires libdruntime-ldc-debug.so.66 derelict-GLFW3-3-32.20141022git7fc1714.fc23.i686 requires libphobos2-ldc-debug.so.66 derelict-GLFW3-3-32.20141022git7fc1714.fc23.i686 requires libdruntime-ldc-debug.so.66 derelict-IL-3-32.20141022git7fc1714.fc23.i686 requires libphobos2-ldc-debug.so.66 derelict-IL-3-32.20141022git7fc1714.fc23.i686 requires libdruntime-ldc-debug.so.66 derelict-LUA-3-32.20141022git7fc1714.fc23.i686 requires libphobos2-ldc-debug.so.66 derelict-LUA-3-32.20141022git7fc1714.fc23.i686 requires libdruntime-ldc-debug.so.66 derelict-ODE-3-32.20141022git7fc1714.fc23.i686 requires libphobos2-ldc-debug.so.66 derelict-ODE-3-32.20141022git7fc1714.fc23.i686 requires libdruntime-ldc-debug.so.66 derelict-Ogg-3-32.20141022git7fc1714.fc23.i686 requires libphobos2-ldc-debug.so.66 derelict-Ogg-3-32.20141022git7fc1714.fc23.i686 requires libdruntime-ldc-debug.so.66 derelict-PHYSFS-3-32.20141022git7fc1714.fc23.i686 requires libphobos2-ldc-debug.so.66 derelict-PHYSFS-3-32.20141022git7fc1714.fc23.i686 requires libdruntime-ldc-debug.so.66 derelict-PQ-3-32.20141022git7fc1714.fc23.i686 requires libphobos2-ldc-debug.so.66 derelict-PQ-3-32.20141022git7fc1714.fc23.i686 requires libdruntime-ldc-debug.so.66 derelict-SDL2-3-32.20141022git7fc1714.fc23.i686 requires libphobos2-ldc-debug.so.66 derelict-SDL2-3-32.20141022git7fc1714.fc23.i686 requires libdruntime-ldc-debug.so.66 derelict-SFML2-3-32.20141022git7fc1714.fc23.i686 requires libphobos2-ldc-debug.so.66 derelict-SFML2-3-32.20141022git7fc1714.fc23.i686 requires libdruntime-ldc-debug.so.66 derelict-Vorbis-3-32.20141022git7fc1714.fc23.i686 requires libphobos2-ldc-debug.so.66 derelict-Vorbis-3-32.20141022git7fc1714.fc23.i686 requires libdruntime-ldc-debug.so.66 [gnash] 1:gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 require
Agenda for Env-and-Stacks WG meeting (2015-10-01)
WG meeting will be at 12:00 UTC (9:00 EST, 14:00 Brno, 8:00 Boston, 21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting-2 on Freenode. = Topics = * Fedora + CentOS docker images naming conventions Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-23 Branched report: 20151001 changes
Compose started at Thu Oct 1 07:15:03 UTC 2015 Broken deps for armhfp -- [CableSwig] CableSwig-3.20.0-13.fc23.armv7hl requires gccxml [apache-scout] apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws) apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:juddi-client) [gmsh] gmsh-libs-2.10.1-2.fc23.armv7hl requires libalglib-3.9.0.so gmsh-mpich-libs-2.10.1-2.fc23.armv7hl requires libalglib-3.9.0.so gmsh-openmpi-libs-2.10.1-2.fc23.armv7hl requires libalglib-3.9.0.so [golang-github-goraft-raft] golang-github-goraft-raft-devel-0-0.6.git73f9c44.fc23.noarch requires golang(code.google.com/p/goprotobuf) [hawaii-shell] hawaii-shell-0.3.0-3.fc22.armv7hl requires libqtaccountsservice-qt5.so.0.1.2 [hbase] hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hbase-tests-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hbase-tests-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hbase-tests-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core) [licq] licq-1.8.2-9.fc23.armv7hl requires libboost_regex.so.1.57.0 [mariadb-galera] 1:mariadb-galera-server-10.0.17-5.fc23.armv7hl requires galera >= 0:25.3.3 [moon-buggy] moon-buggy-1.0.51-14.fc23.armv7hl requires libesd.so.0 [netbeans-platform] 1:netbeans-platform-harness-7.0.1-11.fc22.armv7hl requires cobertura >= 0:1.9.3 [nodejs-grunt-contrib-copy] nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires npm(file-sync-cmp) < 0:0.2 nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires npm(file-sync-cmp) >= 0:0.1.0 nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires npm(chalk) >= 0:0.5.1 [nodejs-grunt-saucelabs] nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(sauce-tunnel) >= 0:2.2.3 nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(requestretry) < 0:1.3 nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(lodash) >= 0:3.7.0 nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(colors) >= 0:1.0.0 [oat] oat-appraiser-1.6.0-16.fc22.armv7hl requires tomcat-servlet-3.0-api oat-client-1.6.0-16.fc22.armv7hl requires tomcat-servlet-3.0-api [oozie] oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.pig:pig) oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-serde) oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-metastore) oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-exec) oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-common) oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-cli) oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive.hcatalog:webhcat-java-client) oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive.hcatalog:hcatalog-server-extensions) oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive.hcatalog:hcatalog-pig-adapter) oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive.hcatalog:hcatalog-core) [openstack-heat-gbp] openstack-heat-gbp-2014.2-2.fc23.noarch requires openstack-heat-engine < 0:2014.3 [openstack-neutron-gbp] openstack-neutron-gbp-2014.2-2.fc23.noarch requires openstack-neutron < 0:2014.3 [openstack-swift] openstack-swift-2.3.0-2.fc23.noarch requires python-pyeclib [polymake] polymake-2.13-22.git20141013.fc23.armv7hl requires perl(:MODULE_COMPAT_5.20.2) polymake-2.13-22.git20141013.fc23.armv7hl requires perl = 4:5.20.2 polymake-2.13-22.git20141013.fc23.armv7hl requires libperl.so.5.20 [publican] publican-4.1.3-3.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) [pyjigdo] pyjigdo-0.4.0.3-9.fc23.noarch requires fuseiso [python-django-horizon-gbp] openstack-dashboard-gbp-2014.2-2.fc23.noarch requires openstack-dashboard < 0:2014.3 python-django-horizon-gbp-2014.2-2.fc23.noarch requires python-django-horizon < 0:2014.3 [python-fiat] python-fiat-1.5.0-2.fc23.noarch requires ScientificPython [python-gbpclient] python-gbpclient-0.9.0-2.fc23.noarch requires python-neutronclient = 0:2.3.9 [rubygem-font-awesome-rails] rubygem-font-awesome-rails-4.4.0.0-1.fc23.noarch requires fontawesome-fonts >= 0:4.4.0 [tortoisehg] tortoisehg-3.4-2.fc23.noarch requires mercurial < 0:3.4 [tritonus] tritonus-esd-0.3.7-0.23.20101108cvs.fc22.armv7hl requires libesd.so.0 [trustedqsl] tqsllib-devel-2.4-9.fc23.1.armv7hl requires tqsllib(armv7hl-32) = 0:2.4-9.fc23 [vdr-live] vdr-live-0.3.0-21.20150213git6ea279a.fc23.armv7hl requires libtntnet.so.12 vdr-live-0.3.0-21.20150213git6ea
Re: Orphaned packages looking for new Point of Contact
On Wed, 30 Sep 2015 15:31:13 -0600 Kevin Fenzi wrote: [...] > You do know you should be able to add yourself as co-maintainer and/or > re-take point of contact (If you feel you have time to), right? FWIW, I have re-taken ownership of 4 of my packages, which are ones that I actually still use and shouldn't be critical to anyone. All the other ones I still care about have quickly found new owners, which I'm very happy about :-) I think maintaining 4 packages should be doable, and it should make sure I don't disconnect completely from Fedora packaging. Those are : * linux_logo * lsdvd * libcaca * relevation I have just updated relevation (#1021873) and will be looking into the only open ldvd bug report (#1220086). Two vs. my 3348 unread bugzilla notifications... much better. I really should have been pro-active on orphaning packages a long time ago, sorry for not doing so. Matthias -- Matthias Saou ██ ██ ██ ██ Web: http://matthias.saou.eu/ ██ Mail/XMPP: matth...@saou.eu ██ ██ GPG: 4096R/E755CC63██ ██ ██ 8D91 7E2E F048 9C9C 46AF ██ ██ ██ ██ 21A9 7A51 7B82 E755 CC63 pgpd6JQv7YBUr.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bugzilla search missing fields; can't find if F21 dracut bug filed lately
On Thu, 2015-10-01 at 04:53 -0400, Felix Miata wrote: > doesn't any kind of list in SeaMonkey (maybe because of noscript?) Yeah, the fact is that NoScript is incompatible with the Internet... probably that's not how the web should be, but it is how it is For those of us not blocking the scripts, the Bugzilla upgrade is a huge improvement. Those gigantic combo boxes were horrible to use; typeahead find is way nicer. I smile each time I use it; eventually I will get used to it, but for now, being able to easily move bugs between components for the first time is still a huge deal to me. Maybe you could whitelist RH Bugzilla? I think I trust Red Hat not to collect data on me for behavioral advertising, or mine Bitcoin on my computer, or use my computer to DoS Oracle Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaned packages looking for new Point of Contact
On Wed, 2015-09-30 at 13:40 -0600, Kevin Fenzi wrote: > suitesparse (el5) > suitesparse (f21) > suitesparse (f22) > suitesparse (f23) > suitesparse (master) I checked - the package is orphaned, but it does have 3 "administrators" - should I first check if any of them would like to take over before I request ownership? -- Thanks, Regards, Ankur Sinha "FranciscoD" http://fedoraproject.org/wiki/User:Ankursinha signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaned packages looking for new Point of Contact
On Thu, Oct 01, 2015 at 01:49:07PM +0200, Matthias Saou wrote: > * linux_logo Huh. Does this always default to Source Mage, or does it have heuristics which are misfiring? -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Strange missing dependencies for claws-mail-plugins-geolocation
Hello I'm tring to build claws-mail 3.13.0 with its plugins. After running ./configure I've that the geolocation plugin (the only one), will not build, cause missing dependencies. It claims for champlain-gtk-0.8 (and perhaps clutter-gtk-0.10 too). But they are already installed: libchamplain-gtk-0.12.10-1.fc22.i686 (clutter-gtk-1.6.2-1.fc22.i686) In the configure.log: configure:22045: $PKG_CONFIG --exists --print-errors "champlain-gtk-0.8 > 0.8.0" Package champlain-gtk-0.8 was not found in the pkg-config search path. Perhaps you should add the directory containing `champlain-gtk-0.8.pc' to the PKG_CONFIG_PATH environment variable No package 'champlain-gtk-0.8' found Package clutter-gtk-0.10 was not found in the pkg-config search path. Perhaps you should add the directory containing `clutter-gtk-0.10.pc' to the PKG_CONFIG_PATH environment variable No package 'clutter-gtk-0.10' found Is a problem with the versions installed or what? Thanks pgp7XpdUJ7sFs.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
XSD on EPEL7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all. I need XSD on EPEL7. Is it possible a build? Package: https://admin.fedoraproject.org/pkgdb/package/xsd/ Bugzilla request: https://bugzilla.redhat.com/show_bug.cgi?id=1251682 Thanks. - -- Antonio Trande mailto: sagitter 'at' fedoraproject 'dot' org http://fedoraos.wordpress.com/ https://fedoraproject.org/wiki/User:Sagitter GPG Key: 0x565E653C Check on https://keys.fedoraproject.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWDVKqAAoJEF5tK7VWXmU8fw4IAIOjbuEpL1lUpVXZugKWVbcC FZcKozTHw+3Fw72xgqHxpmfQNir1M9TYSb3iEiOgi1V+z2cUOPGQCcWTcmB8crU8 Hl6zlppnw/xPHT+XKhIpdB1QUOcFv8BmsAF47bQsaLa3UAIyKsS0UbCTsJpnrl+o mmZfTa1KmhCKAmnFUbwSYQMwg9T5I5vW3KzXpJJUnd69zmSVV28mu557RHeL+3p0 6uSrnyJSSxcM+tjVbE9wDwrIFir2ILua+m8nbL6vnOTLpdjWQ0EeS79cRhmc9GE/ pi5EpHSr8hyH853+uABcS0Ww19anf0CFpnqcgzN5XLw+f3mwiudhim5JTuf/61A= =siMO -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Strange missing dependencies for claws-mail-plugins-geolocation
On 10/01/2015 09:19 AM, Luigi Votta wrote: > Hello I'm tring to build claws-mail 3.13.0 with its plugins. > After running > ./configure > > I've that the geolocation plugin (the only one), will not > build, cause missing dependencies. > > It claims for > champlain-gtk-0.8 > (and perhaps clutter-gtk-0.10 too). > > But they are already installed: > libchamplain-gtk-0.12.10-1.fc22.i686 > (clutter-gtk-1.6.2-1.fc22.i686) > You are going to need libchamplain-gtk-devel, clutter-gtk-devel > In the configure.log: > configure:22045: $PKG_CONFIG --exists --print-errors "champlain-gtk-0.8 >> 0.8.0" > Package champlain-gtk-0.8 was not found in the pkg-config search path. > Perhaps you should add the directory containing `champlain-gtk-0.8.pc' > to the PKG_CONFIG_PATH environment variable > No package 'champlain-gtk-0.8' found > > Package clutter-gtk-0.10 was not found in the pkg-config search path. > Perhaps you should add the directory containing `clutter-gtk-0.10.pc' > to the PKG_CONFIG_PATH environment variable > No package 'clutter-gtk-0.10' found You may find even after installing the -devel packages that you don't have the required versions. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
comps packagereq items default to "mandatory"
I'm not sure that this is common knowledge as it is not specifically mentioned in either: https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups or https://fedorahosted.org/comps/ that the default type for packagereq is "mandatory". As a result I believe that there are a *large* number of packages listed in comps that are inadvertently being marked as "mandatory", e.g.: standard <_name>Standard <_description>Common set of utilities that extend the minimal installation. false false abrt-cli acl at attr bash-completion kde-desktop <_name>KDE <_description>The KDE Plasma Workspaces, a highly-configurable graphical user interface which includes a panel, desktop, system icons and desktop widgets, and many powerful KDE applications. false false abrt-desktop adwaita-gtk2-theme akonadi akonadi-mysql akregator apper ... Almost none of those appear to be "Mandatory". We think this is becoming an issue now because it appears that dnf perhaps now prevents kickstart installs from removing mandatory packages from the install set. See https://bugzilla.redhat.com/show_bug.cgi?id=1199868 and the good detective work done by Adam Williamson for more background. So, it seems we can either (perhaps) go back to the previous behavior, and/or fix comps. We may want to fix comps anyways as I expect this has UI effects as well (perhaps cannot deselect packages after selecting a group?). -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Strange missing dependencies for claws-mail-plugins-geolocation
On Thu, 1 Oct 2015 09:40:49 -0600 Orion Poplawski wrote: > On 10/01/2015 09:19 AM, Luigi Votta wrote: > > Hello I'm tring to build claws-mail 3.13.0 with its plugins. > > After running > > ./configure > > > > I've that the geolocation plugin (the only one), will not > > build, cause missing dependencies. > > > > It claims for > > champlain-gtk-0.8 > > (and perhaps clutter-gtk-0.10 too). > > > > But they are already installed: > > libchamplain-gtk-0.12.10-1.fc22.i686 > > (clutter-gtk-1.6.2-1.fc22.i686) > > > > You are going to need libchamplain-gtk-devel, clutter-gtk-devel > > > In the configure.log: > > configure:22045: $PKG_CONFIG --exists --print-errors > > "champlain-gtk-0.8 > >> 0.8.0" > > Package champlain-gtk-0.8 was not found in the pkg-config search > > path. Perhaps you should add the directory containing > > `champlain-gtk-0.8.pc' to the PKG_CONFIG_PATH environment variable > > No package 'champlain-gtk-0.8' found > > > > Package clutter-gtk-0.10 was not found in the pkg-config search > > path. Perhaps you should add the directory containing > > `clutter-gtk-0.10.pc' to the PKG_CONFIG_PATH environment variable > > No package 'clutter-gtk-0.10' found > > You may find even after installing the -devel packages that you don't > have the required versions. Sorry for my incomplete info: the -devel pkgs were installed. Any hints? perhaps contact the mantainer in upstream? pgpU5CxMMhLwO.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Strange missing dependencies for claws-mail-plugins-geolocation
On 10/01/2015 10:07 AM, Luigi Votta wrote: > On Thu, 1 Oct 2015 09:40:49 -0600 > Orion Poplawski wrote: > >> On 10/01/2015 09:19 AM, Luigi Votta wrote: >>> Hello I'm tring to build claws-mail 3.13.0 with its plugins. >>> After running >>> ./configure >>> >>> I've that the geolocation plugin (the only one), will not >>> build, cause missing dependencies. >>> >>> It claims for >>> champlain-gtk-0.8 >>> (and perhaps clutter-gtk-0.10 too). >>> >>> But they are already installed: >>> libchamplain-gtk-0.12.10-1.fc22.i686 >>> (clutter-gtk-1.6.2-1.fc22.i686) >>> >> >> You are going to need libchamplain-gtk-devel, clutter-gtk-devel >> >>> In the configure.log: >>> configure:22045: $PKG_CONFIG --exists --print-errors >>> "champlain-gtk-0.8 0.8.0" >>> Package champlain-gtk-0.8 was not found in the pkg-config search >>> path. Perhaps you should add the directory containing >>> `champlain-gtk-0.8.pc' to the PKG_CONFIG_PATH environment variable >>> No package 'champlain-gtk-0.8' found >>> >>> Package clutter-gtk-0.10 was not found in the pkg-config search >>> path. Perhaps you should add the directory containing >>> `clutter-gtk-0.10.pc' to the PKG_CONFIG_PATH environment variable >>> No package 'clutter-gtk-0.10' found >> >> You may find even after installing the -devel packages that you don't >> have the required versions. > > Sorry for my incomplete info: the -devel pkgs were installed. > Any hints? perhaps contact the mantainer in upstream? Looks like claws-mail in Fedora does not build to the geolocation plugin due to gtk2/3 conflicts. But yeah, looks like claws-mail requires specific versions of champlain and clutter and you have newer ones. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Strange missing dependencies for claws-mail-plugins-geolocation
On Thu, 2015-10-01 at 17:19 +0200, Luigi Votta wrote: > Hello I'm tring to build claws-mail 3.13.0 with its plugins. > After running > ./configure > > I've that the geolocation plugin (the only one), will not > build, cause missing dependencies. > > It claims for > champlain-gtk-0.8 > (and perhaps clutter-gtk-0.10 too). > > But they are already installed: > libchamplain-gtk-0.12.10-1.fc22.i686 > (clutter-gtk-1.6.2-1.fc22.i686) These two provide champlain-0.12 and clutter-gtk-1.0, both for gtk3, while claws-mail (as a gtk2-based app) requires the last versions which were for gtk2. In theory (and with some patches), these two versions could be made parallel-installable (e.g. as clutter-gtk010 and libchamplain08), but AFAIK the old versions are no longer maintained. -- Yaakov Selkowitz Associate Software Engineer, ARM Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Can't build EPEL 6 package: broken dependencies, Release Enginering ???
See here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=11296302
https://kojipkgs.fedoraproject.org//work/tasks/6309/11296309/root.log
--
DEBUG util.py:441: Executing command: ['/usr/bin/yum', '--installroot',
'/var/lib/mock/dist-6E-epel-build-4130166-530761/root/', 'groupinstall',
'build'] with env {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL':
'/bin/bash', 'LC_MESSAGES': 'C', 'PROMPT_COMMAND': 'printf
"\x1b]0;\x07"', 'PATH':
'/usr/bin:/bin:/usr/sbin:/sbin', 'HOME': '/builddir', 'HOSTNAME': 'mock'} and
shell False
DEBUG util.py:377: Error: Package: redhat-rpm-config-9.0.3-44.el6.noarch
(build)
DEBUG util.py:377: Requires: /bin/sh
DEBUG util.py:377: Error: Package: redhat-rpm-config-9.0.3-44.el6.noarch
(build)
DEBUG util.py:377: Requires: mktemp
DEBUG util.py:377: Error: Package: epel-release-6-8.noarch (build)
DEBUG util.py:377: Requires: /bin/sh
DEBUG util.py:377: Error: Package: epel-release-6-8.noarch (build)
DEBUG util.py:377: Requires: redhat-release >= 6
DEBUG util.py:377: You could try using --skip-broken to work around the
problem
DEBUG util.py:377: You could try running: rpm -Va --nofiles --nodigest
DEBUG util.py:377: Error: Package: redhat-rpm-config-9.0.3-44.el6.noarch
(build)
DEBUG util.py:377: Requires: /usr/bin/perl
DEBUG util.py:377: Error: Package: redhat-rpm-config-9.0.3-44.el6.noarch
(build)
DEBUG util.py:377: Requires: perl(Getopt::Long)
DEBUG util.py:377: Error: Package: redhat-rpm-config-9.0.3-44.el6.noarch
(build)
DEBUG util.py:377: Requires: /bin/bash
DEBUG util.py:488: Child return code was: 1
DEBUG util.py:170: kill orphans
--
Regards, Irina.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaned packages looking for new Point of Contact
> Huh. Does this always default to Source Mage, or does it have > heuristics which are misfiring? Neither. The Fedora package is built using `make logos-all`, which means that all available logos are compiled in. The `find` command is used to find the logos, and C code for building a linked list of them is written into load_logos.h before compilation. At runtime, linux_logo walks the linked list to find an appropriate logo, according to the settings that are in effect. Since `find` is used, the logos aren't in any particular order. Here's the build log for the F22 package: https://kojipkgs.fedoraproject.org//packages/linux_logo/5.11/10.fc22/data/logs/x86_64/build.log Towards the end you can see all the "Added logo..." lines, which show the order in which the logos were found at build time. You can also see the list by running `linux_logo -L list`, which also shows whether each logo is a "Banner" logo (text underneath the logo), or a "Classic" logo (text to the right of the logo): Available Built-in Logos: NumTypeAsciiNameDescription 1ClassicYesclassic-nodotsThe Classic Logo, No Periods 2ClassicYesclassicThe Default Classic Logo 3ClassicYesclassic-simpClassic No Dots Or Letters 4BannerYessourcemage_banSource Mage GNU/Linux banner ... Banner mode is the default, but the first three logos are "Classic" logos, so the Source Mage logo is used by default. For the latest F23 build (http://koji.fedoraproject.org/koji/buildinfo?buildID=652899), the order is different, so that build displays a Solaris logo by default :/ The "normal" way to build this only compiles in the two Linux logos shown on the linux_logo home page (http://www.deater.net/weave/vmwprod/linux_logo/), so not compiling in all logos would be one way to get more satisfactory default behaviour. Another possibility, if we really wanted the Fedora package to include all logos, would be to make sure the two Linux logos appear first in the logo_config file that contains the list of compiled-in logos. I just spent far too much time figuring out how this works :-) Since I've done that, I may as well file a bug... Richard -- Richard Fearn richardfe...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 23 Branched 20151001 compose check report
No missing expected images. No images in this compose but not 23 Branched 20150930 No images in 23 Branched 20150930 but not this. Failed openQA tests: 15 of 52 ID: 4393Test: i386 kde_live default_install ID: 4392Test: x86_64 kde_live default_install ID: 4391Test: i386 workstation_live default_install ID: 4385Test: i386 universal upgrade_desktop_32bit ID: 4381Test: i386 universal server_software_raid ID: 4380Test: i386 universal server_simple_encrypted ID: 4373Test: x86_64 universal server_btrfs@uefi ID: 4371Test: x86_64 universal server_multi_empty@uefi ID: 4370Test: x86_64 universal server_simple_free_space@uefi ID: 4368Test: x86_64 universal server_delete_partial@uefi ID: 4361Test: x86_64 universal upgrade_desktop_64bit ID: 4360Test: x86_64 universal upgrade_minimal_64bit ID: 4358Test: x86_64 universal server_no_swap ID: 4354Test: x86_64 universal server_software_raid ID: 4351Test: x86_64 universal server_simple_encrypted Passed openQA tests: 37 of 52 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaned packages looking for new Point of Contact
Hi, On 09/30/2015 09:40 PM, Kevin Fenzi wrote: > In today's FESCo meeting we marked 2 maintainers as no longer > responsive and I have just orphaned the packages that they were point > of contact on. > > Please take a look at this list and if you wish to become the point of > contact for that package do so in pkgdb. > > Thanks. > > kevin > -- ... > python-metar (f21) > python-metar (f22) > python-metar (f23) > python-metar (master) I have taken the python-metar package (branches only). Jos de Kloe. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora Rawhide 20151001 compose check report
No missing expected images. No images in this compose but not Rawhide 20150930 No images in Rawhide 20150930 but not this. Failed openQA tests: 50 of 52 ID: 4341Test: i386 kde_live default_install ID: 4340Test: x86_64 workstation_live default_install@uefi ID: 4339Test: x86_64 workstation_live default_install ID: 4338Test: x86_64 kde_live default_install ID: 4337Test: i386 workstation_live default_install ID: 4336Test: i386 generic_boot default_install ID: 4335Test: x86_64 generic_boot default_install@uefi ID: 4334Test: x86_64 generic_boot default_install ID: 4333Test: i386 universal upgrade_desktop_32bit ID: 4332Test: i386 universal server_lvmthin ID: 4331Test: i386 universal server_ext3 ID: 4330Test: i386 universal server_btrfs ID: 4329Test: i386 universal server_software_raid ID: 4328Test: i386 universal server_simple_encrypted ID: 4327Test: i386 universal server_repository_http_graphical ID: 4326Test: i386 universal server_scsi_updates_img ID: 4325Test: i386 universal package_set_minimal ID: 4324Test: x86_64 universal server_no_swap@uefi ID: 4323Test: x86_64 universal server_lvmthin@uefi ID: 4322Test: x86_64 universal server_ext3@uefi ID: 4321Test: x86_64 universal server_btrfs@uefi ID: 4320Test: x86_64 universal server_software_raid@uefi ID: 4319Test: x86_64 universal server_multi_empty@uefi ID: 4318Test: x86_64 universal server_simple_free_space@uefi ID: 4317Test: x86_64 universal server_simple_encrypted@uefi ID: 4316Test: x86_64 universal server_delete_partial@uefi ID: 4315Test: x86_64 universal server_delete_pata@uefi ID: 4314Test: x86_64 universal server_sata_multi@uefi ID: 4313Test: x86_64 universal european_language_install ID: 4312Test: x86_64 universal server_shrink_ntfs ID: 4311Test: x86_64 universal server_shrink_ext4 ID: 4310Test: x86_64 universal server_updates_img_local ID: 4309Test: x86_64 universal upgrade_desktop_64bit ID: 4308Test: x86_64 universal upgrade_minimal_64bit ID: 4307Test: x86_64 universal server_kickstart_hdd ID: 4306Test: x86_64 universal server_no_swap ID: 4305Test: x86_64 universal server_lvmthin ID: 4304Test: x86_64 universal server_ext3 ID: 4303Test: x86_64 universal server_btrfs ID: 4302Test: x86_64 universal server_software_raid ID: 4301Test: x86_64 universal server_multi_empty ID: 4300Test: x86_64 universal server_simple_free_space ID: 4299Test: x86_64 universal server_simple_encrypted ID: 4298Test: x86_64 universal server_delete_partial ID: 4297Test: x86_64 universal server_repository_http_variation ID: 4296Test: x86_64 universal server_repository_http_graphical ID: 4295Test: x86_64 universal server_mirrorlist_graphical ID: 4294Test: x86_64 universal server_delete_pata ID: 4291Test: x86_64 universal server_sata_multi ID: 4290Test: x86_64 universal package_set_minimal Passed openQA tests: 2 of 52 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: comps packagereq items default to "mandatory"
Orion Poplawski (or...@cora.nwra.com) said: > Almost none of those appear to be "Mandatory". > > We think this is becoming an issue now because it appears that dnf perhaps now > prevents kickstart installs from removing mandatory packages from the install > set. See https://bugzilla.redhat.com/show_bug.cgi?id=1199868 and the good > detective work done by Adam Williamson for more background. > > So, it seems we can either (perhaps) go back to the previous behavior, and/or > fix comps. We may want to fix comps anyways as I expect this has UI effects > as well (perhaps cannot deselect packages after selecting a group?). Unless something has changed (possible, haven't been playing close attention), there's no individual package selection for groups, so there are no UI effects. Historical info: This was generally intentional - the group is intended to define a specific set of packages that would be ensured to be there if that group was installed. Optional selections are for groups which only have optional packages, or optional groups that would be selected for particular environments. That can always be revisited, but the initial premise was that groups of that form that are specified as they are in comps now weren't supposed to be modifyable in that way. (Even if yum-based anaconda let you do it in kickstart.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Can't build EPEL 6 package: broken dependencies, Release Enginering ???
Yep. I am working on it as I type. Should be fixed in a few here... kevin pgpKxu7oQq4CA.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Can't build EPEL 6 package: broken dependencies, Release Enginering ???
This was fixed a few minutes after my last email. If you still see problems, please file an infrastructure trac ticket. Thanks, kevin pgpUtmyqG4O3C.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
On Wednesday, 30 September 2015 at 14:35, Stephen Gallagher wrote:
> Just to circle around here (in case people don't read my reply to the
> FESCo meeting agenda), I'm making the following revised proposal[1] to
> FESCo which may or may not be discussed at today's meeting (given that
> it was submitted late):
>
>
> === Mandatory ===
> * The Fedora Base Working Group has been tasked with defining the base
> platform of Fedora since its inception. As part of this proposal, we
> set a deadline for them to provide (and maintain) a specific list of
> critical path packages. The critical path set is ''not'' required to be
> self-hosting.
> * Working Groups for the separate Editions '''may''' voluntarily add
> packages into the critical path atop the Base WG requirements.
> * All packages in the critical path '''must''' obey the current strict
> bundling rules.
> * All packages not in the critical path whose upstreams allow them to
> be build against system libraries '''must''' be built against system
> libraries.
> * All packages not in the critical path whose upstreams have no
> mechanism to build against system libraries '''must''' be contacted
> publicly about a path to supporting system libraries. If upstream
> refuses, this must be recorded in a link included in the spec file.
> * All packages not in the critical path whose upstreams have no
> mechanism to build against system libraries '''may''' opt to carry
> bundled libraries, but if they do, they '''must''' include {{{Provides:
> bundled() = }}} in their RPM spec file.
I strongly object to this last point. If we simply allow free bundling
provided that it's recorded then we're opening a can of worms each
having a different CVE written on their backs. A recently discovered
bundling of lua[2] (with an actual open CVE) in luatex (and probably
in many more packages) is a good example of why this is a bad idea.
The current FPC bundling exception process should be preserved,
otherwise we're effectively removing all motivation to work with
upstreams on unbundling.
> === Strongly Recommended ===
> * Packages in the critical path should be re-reviewed every two years
> (possibly as a Flock workshop) to avoid unintentional divergence from
> the policies.
+1
> [1] https://fedorahosted.org/fesco/ticket/1483
[2] https://fedorahosted.org/fpc/ticket/569
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Planned Outage: Server updates/reboots - 2015-10-06 21:00 UTC
Planned Outage: Server updates/reboots - 2015-10-06 21:00 UTC There will be an outage starting at 2015-10-06 21:00 UTC, which will last approximately 6 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2015-10-06 21:00 UTC' Reason for outage: We will be updating and rebooting servers with the latest errata/updates. No services will be down for the entire window, but particular services may be down and back up at any time in the window as we reboot servers. Affected Services: All services may see some effect with the exception of: * Fedorainfracloud / copr will be updated seperately and should be up as normal during this outage. * mirrorlists, static web content, hotspot file, dns and geoip services should always be available. Contact Information: Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/4909 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. pgppNxCnRbBSr.pgp Description: OpenPGP digital signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Planned Outage: fedorainfracloud.org / copr - 2015-10-05 00:00 UTC
Planned Outage: fedorainfracloud.org / copr - 2015-10-05 00:00 UTC There will be an outage starting at 2015-10-05 00:00 UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2015-10-05 00:00 UTC' Reason for outage: We will be updating and rebooting our openstack cloud and all the instances in it. This will result in downtime for any cloud related instances, in particular copr will be unavailable. Affected Services: fedorainfracloud.org copr.fedoraproject.org fedoramagazine.org taiga.fedorainfracloud.org testdays.fedorainfracloud.org jenkins.fedorainfracloud.org various development instances Contact Information: Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/4908 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. pgp0WUJrvD6_1.pgp Description: OpenPGP digital signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
RE: bugzilla search missing fields; can't find if F21 dracut bug filed lately
> Is anybody else bothered by the latest BZ changes? Where does one select > the > Fedora release to limit search results to? And how does one figure out > where > to select kernel or dracut? Those scroll lists are much too difficult to > find > anything in, overscrolling nearly always except doing one line at a time, > which would take an eternity to locate anything not starting with z or a. > > I'm trying to figure out if anyone else has filed a bug that dracut builds > F21 32 bit Athlon/VIA chipset initrds without any storage driver (pata_via > needed) sometime after kernel 4.1.4 was replaced with whatever came next. > 4.1.4 works, but 4.1.7 produces emergency shell for failure to find root > device whether root=LABEL= or root=devname or root=UUID= on cmdline. Also, > rebooting attemps from the emergency shell utterly fail, and this after > taking more than 3 minutes just to reach the emergency shell after > selecting > a Grub stanza. I too noticed the advanced search to be severely broken or at least confusing. Under the Component field it tells you to "Click to list all components" but what exactly are you supposed to click? At the time I tried, typing in the Component field did not get me a reduced list like it did before so I eventually had to use a simple search and the sort by the component column. Now however it appears that entering text into the Component field does cause a list to appear for those that match. I still think the "Click to.." message is confusing. Some of my confusion may just be due to the incredibly slow response time, Now I've played again with it a bit and Firefox is reporting that the script has become unresponsive. It certainly doesn't seem very usable to me. I didn't file a bug on BZ because I wasn't sure where exactly one does that. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaned packages looking for new Point of Contact
Hi, On Thursday, 01 October 2015 at 00:04, Christian Dersch wrote: > I've taken yasm. I'd like to co-maintain. It's essential for mplayer and ffmpeg over at RPMFusion. Request for commit access submitted. Regards, -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bugzilla search missing fields; can't find if F21 dracut bug filed lately
On 10/01/2015 02:07 PM, John Florian wrote: >> Is anybody else bothered by the latest BZ changes? Where does one select >> the >> Fedora release to limit search results to? And how does one figure out >> where >> to select kernel or dracut? Those scroll lists are much too difficult to >> find >> anything in, overscrolling nearly always except doing one line at a time, >> which would take an eternity to locate anything not starting with z or a. >> >> I'm trying to figure out if anyone else has filed a bug that dracut builds >> F21 32 bit Athlon/VIA chipset initrds without any storage driver (pata_via >> needed) sometime after kernel 4.1.4 was replaced with whatever came next. >> 4.1.4 works, but 4.1.7 produces emergency shell for failure to find root >> device whether root=LABEL= or root=devname or root=UUID= on cmdline. Also, >> rebooting attemps from the emergency shell utterly fail, and this after >> taking more than 3 minutes just to reach the emergency shell after >> selecting >> a Grub stanza. > > > I too noticed the advanced search to be severely broken or at least > confusing. Under the Component field it tells you to "Click to list all > components" but what exactly are you supposed to click? At the time I tried, > typing in the Component field did not get me a reduced list like it did > before so I eventually had to use a simple search and the sort by the > component column. Now however it appears that entering text into the > Component field does cause a list to appear for those that match. I still > think the "Click to.." message is confusing. Some of my confusion may just > be due to the incredibly slow response time, Now I've played again with it a > bit and Firefox is reporting that the script has become unresponsive. For me I can click on that an I see "Working" then eventually a list appears. But it's slow as you might expect for bringing up so many components. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaned packages looking for new Point of Contact
On Thu, Oct 01, 2015 at 06:57:43PM +0100, Richard Fearn wrote: > > Huh. Does this always default to Source Mage, or does it have > > heuristics which are misfiring? > > Neither. The Fedora package is built using `make logos-all`, which > means that all available logos are compiled in. The `find` command is > used to find the logos, and C code for building a linked list of them > is written into load_logos.h before compilation. At runtime, > linux_logo walks the linked list to find an appropriate logo, > according to the settings that are in effect. > > Since `find` is used, the logos aren't in any particular order. > > Here's the build log for the F22 package: > > > https://kojipkgs.fedoraproject.org//packages/linux_logo/5.11/10.fc22/data/logs/x86_64/build.log What about a Fedora logo? Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Minutes from Env-and-Stacks WG meeting (2015-10-01)
== #fedora-meeting-2: Env and Stacks (2015-10-01) == Meeting started by hhorak at 17:00:27 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-2/2015-10-01/env-and-stacks.2015-10-01-17.00.log.html . Meeting summary --- * Fedora + CentOS docker images naming conventions (hhorak, 17:04:59) * we're fine with namespaces: centos/ and fedora/ (nothing more needed for now) (hhorak, 17:09:09) * today on the mailing list, a conversation is going on to obselete fedora-dockerfiles. to be replaced with a dist-git process. (hhorak, 17:10:50) * we should be fine with namespace/packagename:majorversion for non-scl packages, distro seems to be irrelevant, because we usually use one component in one container and don't care much about the rest of the system in the container (hhorak, 17:41:36) * LINK: https://github.com/projectatomic/ContainerApplicationGenericLabels (hhorak, 18:09:02) * IDEA: start using labels (at least name, version, maybe at least optionally summary, description) as described at https://github.com/projectatomic/ContainerApplicationGenericLabels (hhorak, 18:15:42) * for the images coming from sclo at centos we need to talk to openshift guys about whether centos needs to stay as suffix (hhorak, 18:17:30) * ACTION: hhorak to apprach bparees with outcomes from today's discussion (hhorak, 18:18:19) Meeting ended at 18:18:39 UTC. Action Items * hhorak to apprach bparees with outcomes from today's discussion Action Items, by person --- * hhorak * hhorak to apprach bparees with outcomes from today's discussion * **UNASSIGNED** * (none) People Present (lines said) --- * Evolution (60) * hhorak (59) * scollier (42) * jkaluza (10) * jkaluza_ (6) * zodbot (5) * jkaluza__ (2) * bkabrda (0) * phracek (0) * ttomecek (0) * vpavlin (0) * juhp (0) * ncoghlan (0) * walters (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
On Thu, Oct 01, 2015 at 10:01:29PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> > * All packages not in the critical path whose upstreams have no
> > mechanism to build against system libraries '''may''' opt to carry
> > bundled libraries, but if they do, they '''must''' include {{{Provides:
> > bundled() = }}} in their RPM spec file.
> I strongly object to this last point. If we simply allow free bundling
> provided that it's recorded then we're opening a can of worms each
Just to be clear -- this last point is basically the entire proposal.
It's okay to object to it, of course, but I don't think you can
meaningfully object to just this bit alone.
> having a different CVE written on their backs. A recently discovered
> bundling of lua[2] (with an actual open CVE) in luatex (and probably
> in many more packages) is a good example of why this is a bad idea.
I take that a different way. Exactly the opposite way, in fact. First,
it shows that the the current policy isn't working — it doesn't keep
bundling out. Second, it demonstrates a case where it'd be better if
the bundling had been documented, because it would have shown up in a
query when the security team was working on that vulnerability.
--
Matthew Miller
Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
Am 01.10.2015 um 23:27 schrieb Matthew Miller:
On Thu, Oct 01, 2015 at 10:01:29PM +0200, Dominik 'Rathann' Mierzejewski wrote:
* All packages not in the critical path whose upstreams have no
mechanism to build against system libraries '''may''' opt to carry
bundled libraries, but if they do, they '''must''' include {{{Provides:
bundled() = }}} in their RPM spec file.
I strongly object to this last point. If we simply allow free bundling
provided that it's recorded then we're opening a can of worms each
Just to be clear -- this last point is basically the entire proposal.
It's okay to object to it, of course, but I don't think you can
meaningfully object to just this bit alone.
having a different CVE written on their backs. A recently discovered
bundling of lua[2] (with an actual open CVE) in luatex (and probably
in many more packages) is a good example of why this is a bad idea.
I take that a different way. Exactly the opposite way, in fact. First,
it shows that the the current policy isn't working — it doesn't keep
bundling out. Second, it demonstrates a case where it'd be better if
the bundling had been documented, because it would have shown up in a
query when the security team was working on that vulnerability
the last part *only* works *if* it had been documented
nothing of the whole thread solves the problem of unintentionally
bundeling becaue missing knowledge or just not care about it
in a perfect world upsteram would not write crap which needs to be
unbundeled as well as maintainers would not bundle withoput intemtion by
missing knowledge - nothing of that is solved or targeted
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
On 09/30/2015 05:20 PM, Neal Gompa wrote: On Wed, Sep 30, 2015 at 10:52 AM, Ralf Corsepius mailto:rc040...@freenet.de>>wrote: On 09/30/2015 04:25 PM, Reindl Harald wrote: the opposite is more likely: people trying to avoid the FPC burden now can declare it without fearing somebody takes notice and points out a violation If they don't care or are not aware about the consequences of their bundling? Like I've said many times before, I feel Fedora needs a serious vulnerability in a widespread bundled or static library, such that people finally comprehend the harm of bundling. Ralf Are you saying we're doing our job too well, so people don't see the advantages of the effort anymore? No. I am saying actively fighting bundling has prevented cases like the zlib disaster 15+ years to return. Seems to me, as if today's generation of fedora users and esp. current Fedora leaders need to go through the lessons people who had been using Linux then were tought the cruel way. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
On 09/30/2015 06:32 PM, Matthew Miller wrote: On Wed, Sep 30, 2015 at 04:52:48PM +0200, Ralf Corsepius wrote: people not declaring their bundles and not care about policies did the same before: not declare it and not ask for exceptions - there is a logical flow in "now that i don't need to ask FPC i don't declare it" Exactly, that's what I would consider a serious regression. But re-read what you're just replying to. The thing is, there's all sorts of bundling going on all throughout Fedora under the radar. I know - while Fedora is doing pretty good job on unbundling in many cases, there are case where Fedora is doing a missable job. IMO, this should be reason to encourage fighting bundling and not to weaken unbundling and weaken enforcing unbundling. Which is - as I feel - what you are currently doing. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
On Thu, 2015-10-01 at 23:54 +0200, Ralf Corsepius wrote: > Seems to me, as if today's generation of fedora users and esp. > current > Fedora leaders need to go through the lessons people who had been > using > Linux then were tought the cruel way. I know you always think you're the ONLY ONE WHO UNDERSTANDS, but the people proposing this have been doing it just as long as you. They know the issues. You can't successfully argue against them by pretending they don't, and should just yield to your unquestionably superior wisdom. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphan Spyder package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/01/2015 03:17 AM, Radek Novacek wrote: > Hi, > > "Spyder is the Scientific PYthon Development EnviRonment" > > I no longer use Spyder, so I'm looking for someone who wants to > take it over. Please, ask for ACLs for it if you would like to > take it over. > > https://admin.fedoraproject.org/pkgdb/package/spyder/ > > Radek Novacek > > I will take it. I have started using this very much lately. I will request ACLs right away. Thanks, Mukundan. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJWDa9rAAoJEHE/1K3lyLxnyd8QAIU8UP6GaH1NIO0WAVtvNoKm ccufOJZ4eV1Kp/Hi1fYdRxXTlbOlPRF8MjsJYT+Nt0x/aeAkrsBN4Ti+NtVZm84P VsKIP19PCzdpX6+uLCMPBhKvQcnjmUONEgtoIul3QWDSOex6GHTEJvgUhZrxz4Wy SXBRAS4FFKuTTD+Wy9xcIUsNu2LJQwSE/+gaPIVPh7nJv0y2D48NWODyLb8rc8X0 hFSNlB6FeQYUIGnjIIDjaeavVsuqNLJmoi27OaVD0RCnkGjjRn+C+p91MuLm+6P4 QbyA+FOjhB/Dqu3fRL82rikfUYeSo9ceBNUJyvaDltfXWUAvqN1z6moYmphjxg4j Adc+DqD1P3kwt10UyZqIE+D5uYThJDRMg09HktGIsu0bxHieMmMKcPRt+SEsZsn7 aNsxIdAkLjuY2aXaOpMgn3XH+vfG0qQ6gO76F0ttRRpUDoT9F5pbj7O+kaK6Odz/ q9J/1TTWf+svI9uxL47u2U0dArxaj7qtsg5y+noP6kVgXxteSC5bHefgBl7BQLCM xhFo8fYg0s5PmgeGVAiXYZbK63BmzxVzMQBCU6dQq/GfdO5dMtmofqKfgZEH2gL4 cSe0LpFZR1Smou9XhEMUITOvdTze8y0EVU0/VlxVwH+UbD4ffsyPVaEPxpbNzj9t 6KYoD0mwAyXMnJg6xRzw =tCmH -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
On 10/02/2015 12:09 AM, Adam Williamson wrote: On Thu, 2015-10-01 at 23:54 +0200, Ralf Corsepius wrote: Seems to me, as if today's generation of fedora users and esp. current Fedora leaders need to go through the lessons people who had been using Linux then were tought the cruel way. I know you always think you're the ONLY ONE WHO UNDERSTANDS, but the people proposing this have been doing it just as long as you. I'm long enough in open source to ignore this rude offensive tone of yours for now. They know the issues. You can't successfully argue against them by pretending they don't, and should just yield to your unquestionably superior wisdom. Their words and action speak a clear and misunderstandable language. Their proposal is just populist and against common sense. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaned packages looking for new Point of Contact
On Thu, Oct 01, 2015 at 08:46:57PM +, Zbigniew Jędrzejewski-Szmek wrote: > > > > https://kojipkgs.fedoraproject.org//packages/linux_logo/5.11/10.fc22/data/logs/x86_64/build.log > What about a Fedora logo? We need to ask Fedora Design for a trademark-approved ASCII art version. -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 23 Branched 20151001 compose check report
No missing expected images. No images in this compose but not 23 Branched 20150930 No images in 23 Branched 20150930 but not this. Failed openQA tests: 8 of 52 ID: 4409Test: i386 workstation_live default_install ID: 4408Test: x86_64 universal upgrade_minimal_64bit ID: 4393Test: i386 kde_live default_install ID: 4392Test: x86_64 kde_live default_install ID: 4385Test: i386 universal upgrade_desktop_32bit ID: 4370Test: x86_64 universal server_simple_free_space@uefi ID: 4368Test: x86_64 universal server_delete_partial@uefi ID: 4361Test: x86_64 universal upgrade_desktop_64bit Passed openQA tests: 44 of 52 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
On Thu, Oct 01, 2015 at 11:38:31PM +0200, Reindl Harald wrote: > >bundling out. Second, it demonstrates a case where it'd be better if > >the bundling had been documented, because it would have shown up in a > >query when the security team was working on that vulnerability > > the last part *only* works *if* it had been documented > > nothing of the whole thread solves the problem of unintentionally > bundeling becaue missing knowledge or just not care about it > > in a perfect world upsteram would not write crap which needs to be > unbundeled as well as maintainers would not bundle withoput > intemtion by missing knowledge - nothing of that is solved or > targeted That's a good point; it's not in the scope of this proposal. However, it does fit with what Matthias said earier in this thread — automation is key. We definitely have some pieces of that puzzle already — I'd love to hear about a project to put them together. -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
On Thu, Oct 01, 2015 at 07:00:13PM -0400, Matthew Miller wrote: > On Thu, Oct 01, 2015 at 11:38:31PM +0200, Reindl Harald wrote: > > >bundling out. Second, it demonstrates a case where it'd be better if > > >the bundling had been documented, because it would have shown up in a > > >query when the security team was working on that vulnerability > > > > the last part *only* works *if* it had been documented > > > > nothing of the whole thread solves the problem of unintentionally > > bundeling becaue missing knowledge or just not care about it > > > > in a perfect world upsteram would not write crap which needs to be > > unbundeled as well as maintainers would not bundle withoput > > intemtion by missing knowledge - nothing of that is solved or > > targeted > > That's a good point; it's not in the scope of this proposal. However, > it does fit with what Matthias said earier in this thread — automation > is key. We definitely have some pieces of that puzzle already — I'd > love to hear about a project to put them together. We could run a script which looks for duplicated files on the output of 'fedpkg prep' on a tree of all packages. There are various linter-style tools which look for duplicated code, but I doubt that they would be functional for a problem of this size. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaned packages looking for new Point of Contact
On Thu, Oct 01, 2015 at 06:53:35PM -0400, Matthew Miller wrote: > On Thu, Oct 01, 2015 at 08:46:57PM +, Zbigniew Jędrzejewski-Szmek wrote: > > > > > > https://kojipkgs.fedoraproject.org//packages/linux_logo/5.11/10.fc22/data/logs/x86_64/build.log > > What about a Fedora logo? > > We need to ask Fedora Design for a trademark-approved ASCII art > version. What about the one from screenfetch [1]? [1] http://in.waw.pl/~zbyszek/fedora/screenfetch.png (sorry for the black-and-whiteness, not so easy to take screenshot under wayland.) Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Can't build EPEL 6 package: broken dependencies, Release Enginering ???
tor 2015-10-01 klockan 13:43 -0400 skrev Irina Boverman:
> See here:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=11296302
>
> https://kojipkgs.fedoraproject.org//work/tasks/6309/11296309/root.log
> --
> DEBUG util.py:441: Executing command: ['/usr/bin/yum', '-
> -installroot', '/var/lib/mock/dist-6E-epel-build-4130166
> -530761/root/', 'groupinstall', 'build'] with env {'LANG': 'en_US.UTF
> -8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'LC_MESSAGES': 'C',
> 'PROMPT_COMMAND': 'printf "\x1b]0;\x07"',
> 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'HOME': '/builddir',
> 'HOSTNAME': 'mock'} and shell False
> DEBUG util.py:377: Error: Package: redhat-rpm-config-9.0.3
> -44.el6.noarch (build)
> DEBUG util.py:377: Requires: /bin/sh
> DEBUG util.py:377: Error: Package: redhat-rpm-config-9.0.3
> -44.el6.noarch (build)
> DEBUG util.py:377: Requires: mktemp
> DEBUG util.py:377: Error: Package: epel-release-6-8.noarch (build)
> DEBUG util.py:377: Requires: /bin/sh
> DEBUG util.py:377: Error: Package: epel-release-6-8.noarch (build)
> DEBUG util.py:377: Requires: redhat-release >= 6
> DEBUG util.py:377: You could try using --skip-broken to work around
> the problem
> DEBUG util.py:377: You could try running: rpm -Va --nofiles -
> -nodigest
> DEBUG util.py:377: Error: Package: redhat-rpm-config-9.0.3
> -44.el6.noarch (build)
> DEBUG util.py:377: Requires: /usr/bin/perl
> DEBUG util.py:377: Error: Package: redhat-rpm-config-9.0.3
> -44.el6.noarch (build)
> DEBUG util.py:377: Requires: perl(Getopt::Long)
> DEBUG util.py:377: Error: Package: redhat-rpm-config-9.0.3
> -44.el6.noarch (build)
> DEBUG util.py:377: Requires: /bin/bash
> DEBUG util.py:488: Child return code was: 1
> DEBUG util.py:170: kill orphans
> --
> Regards, Irina.
The EPEl build root contains the combination of the RHEL and EPEL
repos. Koji knows when the EPEL repo is updated and regenerates the
build root when this happens, but when RHEL is updated there is no
immediate automatic regeneration triggered of the EPEL build root, so
the EPEL build root can be broken for some time.
The trick I usually do in this case is that I request a build root
override for some package in the affected EPEL release (even though I
don't really need one), which triggers a regeneration of the build root
that picks up the changes from the RHEL repo.
Mattias
smime.p7s
Description: S/MIME cryptographic signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
