Orphaning gedit-valencia -- Re: Removing packages that have broken dependencies in F21 tree
Hi, On 11/13/2014 08:20 PM, Kalev Lember wrote: Hi, I would like to remove the packages that still have broken dependencies in the F21 tree. This is a followup to https://lists.fedoraproject.org/pipermail/devel/2014-October/203411.html It makes little sense to ship something that cannot even be installed. We're about to enter the final freeze next week in order to wrap up F21; after the gold release is done, fixes can no longer be pushed to the base repo. This means that anything that shipped with broken dependencies would stay that way in the base repo throughout the F21 lifetime. To avoid that, I'll file a FESCo ticket next Monday to approve dropping the following packages, unless they get fixed first: ... gedit-valencia Upstream (Yorba) has been aware of the breaking API changes in Gedit 3.12, but unfortunately lacks the manpower to fix it. There's a patch submitted in September that laid dormant, and unfortunately changes between Gedit 3.12 and 3.14 cause additional breakage. https://bugzilla.gnome.org/show_bug.cgi?id=724173 Unfortunately I don't have the time to devote to fixing this, so I'm pushing a final update for the Fedora 20 branch of gedit-valencia (containing some test patches that can be applied to get the codebase to compile on Fedora 21) but releasing ownership for F21 and master. Any Vala / GObject / Gedit maven willing to take this package up? Best regards, -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A IDs:keybase.io/michel-slm | IRC: michel_...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments 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: Taskotron depcheck broken/incomplete (was: Re: Removing packages that have broken dependencies in F21 tree)
Adam Williamson wrote: http://tirfa.com/current-state-of-depcheck-and-paths-forward.html Sigh. This shows that once again a purported replacement for a working piece of software was deployed before it was able to perform the allegedly replaced tool's most important task, even though the problem was known to the replacement's developers. We really should not accept this kind of known regressions. I'm sort-of volunteered to write the approach I suggested in a comment as a new test, but it's going to have to wait until at least post-f21. Your approach indeed makes sense. It will not cause issues caused by added Conflicts or the like, but at least it catches the common case. (Just make sure you also consider Obsoleted packages as the old package whose Provides will no longer be available.) Kevin Kofler -- 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: Taskatron depcheck broken/incomplete (was: Re: Removing packages that have broken dependencies in F21 tree)
On Sun, 2014-11-16 at 01:21 +0100, Kevin Kofler wrote: Kalev Lember wrote: 2) juffed was broken by https://admin.fedoraproject.org/updates/FEDORA-2014-14301/ . Interestingly enough the update passed the Taskatron depcheck test there, even though it created a new broken dependency in the repo. The Taskatron depcheck appears to be broken or incomplete: It might be effective at checking whether the new package has any broken dependencies, but it definitely does not appear to check whether the update breaks OTHER packages' dependencies (at least I've seen 2 instances where it didn't catch that, and this is the third). The old AutoQA got that right. http://tirfa.com/current-state-of-depcheck-and-paths-forward.html I'm sort-of volunteered to write the approach I suggested in a comment as a new test, but it's going to have to wait until at least post-f21. -- 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: Removing packages that have broken dependencies in F21 tree
On 11/13/2014 02:20 PM, Kalev Lember wrote: To avoid that, I'll file a FESCo ticket next Monday to approve dropping the following packages, unless they get fixed first: I've filed the ticket now: https://fedorahosted.org/fesco/ticket/1368 In addition, 3 broken dependencies have pending fixes. Would be good to karma those up today so that they can be pushed to stable in advance of the freeze tomorrow: juffed: https://admin.fedoraproject.org/updates/juffed-0.10-11.fc21 meshmagick: https://admin.fedoraproject.org/updates/meshmagick-0.6.0-23.svn2898.fc21 totpcgi: https://admin.fedoraproject.org/updates/FEDORA-2014-15164/totpcgi-0.5.5-4.fc21 -- Thanks, Kalev -- 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: Taskotron depcheck broken/incomplete (was: Re: Removing packages that have broken dependencies in F21 tree)
I wrote: The Taskatron depcheck appears to be broken or incomplete: It might be effective at checking whether the new package has any broken dependencies, but it definitely does not appear to check whether the update breaks OTHER packages' dependencies (at least I've seen 2 instances where it didn't catch that, and this is the third). The old AutoQA got that right. Another fun Taskotron depcheck bug, this time a false positive: https://admin.fedoraproject.org/updates/FEDORA-2014-14865 https://taskotron.fedoraproject.org/taskmaster//builders/x86_64/builds/13276/steps/runtask/logs/stdio Kevin Kofler -- 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: Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)
On Thu, Oct 16, 2014 at 14:40:50 +0200, Kalev Lember kalevlem...@gmail.com wrote: [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 meshmagick has been rebuilt in rawhide and f21 (requested for the testing repo). -- 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: Removing packages that have broken dependencies in F21 tree
On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote: To avoid that, I'll file a FESCo ticket next Monday to approve dropping the following packages, unless they get fixed first: I can do the mass retirement if there is a final list and decision. Did you check that there are not packages listed that were just recently broken? Also do you propose to retire the package only in F21 or also in Rawhide? Regards Till -- 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: Removing packages that have broken dependencies in F21 tree
Matthias Runge wrote: yes, that's the package. But IMHO transifex became closed source, and last code change was about 2 years ago; since then, django changed quite a bit. So we now have core Fedora infrastructure depending on a proprietary third- party web service? We should never have moved Fedora translations to the upstream Transifex instance. We now need to either fork the last Free version and put it up on Fedora Infrastructure, or replace it altogether. Kevin Kofler -- 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: Removing packages that have broken dependencies in F21 tree
Kalev Lember wrote: I would like to remove the packages that still have broken dependencies in the F21 tree. Please check for packages requiring those broken packages, and transitively packages requiring packages requiring those broken packages etc. Otherwise, you'll just add more broken dependencies. Kevin Kofler -- 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: Removing packages that have broken dependencies in F21 tree
On 11/13/2014 02:20 PM, Kalev Lember wrote: Hi, I would like to remove the packages that still have broken dependencies in the F21 tree. This is a followup to https://lists.fedoraproject.org/pipermail/devel/2014-October/203411.html It makes little sense to ship something that cannot even be installed. We're about to enter the final freeze next week in order to wrap up F21; after the gold release is done, fixes can no longer be pushed to the base repo. This means that anything that shipped with broken dependencies would stay that way in the base repo throughout the F21 lifetime. To avoid that, I'll file a FESCo ticket next Monday to approve dropping the following packages, unless they get fixed first: audtty authhub deltacloud-core django-recaptcha dragonegg edelib fatrat flush gdesklet-SlideShow gdesklets-citation gedit-valencia gofer gorm juffed leiningen libghemical libopensync-plugin-irmc ltsp meshmagick monodevelop-vala netdisco nwchem i have submitted nwchem update: https://admin.fedoraproject.org/updates/nwchem-6.5.26243-13.fc21 Best regards, Marcin ocaml-pa-do openslides openvas-client pootle python-askbot-fedmsg python-coffin python-django-addons python-django-longerusername rubygem-linecache19 rubygem-rubigen rubygem-ruby-debug-base19 sugar-tamtam totpcgi transifex valabind why zyGrib Please note that Fedora policies allow adding new packages in the updates repo, so even if something gets dropped now, it can always be fixed and shipped in the updates repo at a later date. -- 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: Removing packages that have broken dependencies in F21 tree
We're not running the Transifex Server on the Fedora infrastructure. The Localization group has also decided to move to a self-managed Zanata instance anyway. The Transifex Client package is which is what many developers use. -d On Sat, Nov 15, 2014 at 5:59 AM, Kevin Kofler kevin.kof...@chello.at wrote: Matthias Runge wrote: yes, that's the package. But IMHO transifex became closed source, and last code change was about 2 years ago; since then, django changed quite a bit. So we now have core Fedora infrastructure depending on a proprietary third- party web service? We should never have moved Fedora translations to the upstream Transifex instance. We now need to either fork the last Free version and put it up on Fedora Infrastructure, or replace it altogether. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Dimitris Glezos Founder CEO, Transifex http://www.transifex.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: Removing packages that have broken dependencies in F21 tree
On 11/15/2014 03:02 PM, Kevin Kofler wrote: Kalev Lember wrote: I would like to remove the packages that still have broken dependencies in the F21 tree. Please check for packages requiring those broken packages, and transitively packages requiring packages requiring those broken packages etc. Otherwise, you'll just add more broken dependencies. Thanks Kevin, that's a very good point. Here's the list of impacted dependant packages (package owners BCC'd): Depending on: deltacloud-core (1), status change: 2014-07-08 (18 weeks ago) condor-cloud (maintained by: imain) condor-cloud-0.1-8.fc21.noarch requires deltacloud-core = 1.1.3-1.fc20 Depending on: fatrat (1), status change: 2014-07-08 (18 weeks ago) fatrat-subtitlesearch (maintained by: cicku) fatrat-subtitlesearch-1.2.0-0.6.beta1.fc21.i686 requires fatrat(x86-32) = 1:1.2.0-0.21.beta2.fc21 fatrat-subtitlesearch-1.2.0-0.6.beta1.fc21.src requires fatrat-devel = 1:1.2.0-0.21.beta2.fc21 Depending on: gofer (1), status change: 2014-07-08 (18 weeks ago) katello-agent (maintained by: lzap) katello-agent-1.1.3-4.fc21.noarch requires gofer = 0.77.1-2.fc21, gofer-package = 0.77.1-2.fc21 Depending on: libghemical (1), status change: 2014-07-08 (18 weeks ago) ghemical (maintained by: cicku, tolland) ghemical-2.99.2-24.fc20.i686 requires libghemical = 2.99.1-24.fc20, libghemical.so.5 ghemical-2.99.2-24.fc20.src requires libghemical-devel = 2.99.1-24.fc20 Depending on: rubygem-rubigen (1), status change: 2014-07-08 (18 weeks ago) rubygem-newgem (maintained by: mmorsi) rubygem-newgem-1.5.3-11.fc21.noarch requires rubygem(rubigen) = 1.5.8, rubygem(rubigen) = 1.5.8-1 rubygem-newgem-1.5.3-11.fc21.src requires rubygem(rubigen) = 1.5.8, rubygem(rubigen) = 1.5.8-1 -- Kalev -- 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: Removing packages that have broken dependencies in F21 tree
On 11/15/2014 11:52 AM, Till Maas wrote: On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote: To avoid that, I'll file a FESCo ticket next Monday to approve dropping the following packages, unless they get fixed first: I can do the mass retirement if there is a final list and decision. Thanks Till. Did you check that there are not packages listed that were just recently broken? Most of those are longstanding (broken for more than a month), with two exceptions: 1) gdesklet-SlideShow and gdesklets-citation depend on gdesklets which appears to have been retired recently; 2) juffed was broken by https://admin.fedoraproject.org/updates/FEDORA-2014-14301/ . Interestingly enough the update passed the Taskatron depcheck test there, even though it created a new broken dependency in the repo. Also do you propose to retire the package only in F21 or also in Rawhide? My gut feeling is to retire the broken packages in Rawhide as well, but it's ultimately up to FESCo to decide what to do. -- Kalev -- 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: Removing packages that have broken dependencies in F21 tree
On Thu, 13 Nov 2014 20:40:07 +0100 Till Maas opensou...@till.name wrote: On Thu, Nov 13, 2014 at 07:40:19PM +0100, Till Maas wrote: On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote: totpcgi This requires an selinux export to make it build again: | + make NAME=mls -f /usr/share/selinux/devel/Makefile | Compiling mls totpcgi module | totpcgi.te:55: Warning: miscfiles_read_certs() has been deprecated, please use miscfiles_read_generic_certs() instead. | totpcgi.te:58: Warning: miscfiles_read_certs() has been deprecated, please use miscfiles_read_generic_certs() instead. | totpcgi.te:41:ERROR 'unknown type httpd_totpcgi_script_t' at token ';' on line 5216: | typeattribute httpd_totpcgi_script_t syslog_client_type; | #line 41 https://github.com/mricon/totp-cgi/issues/27 https://bugzilla.redhat.com/show_bug.cgi?id=1107456 Thanks to tfirg on #selinux I now know that this is because apache_content_template() does not add a httpd_ prefix to types in F21+. Thanks for looking into this. I have requested commits on this package and in the mean time have done rawhide and f21 build with your fix. kevin pgp6GwYjRWG0V.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
Taskatron depcheck broken/incomplete (was: Re: Removing packages that have broken dependencies in F21 tree)
Kalev Lember wrote: 2) juffed was broken by https://admin.fedoraproject.org/updates/FEDORA-2014-14301/ . Interestingly enough the update passed the Taskatron depcheck test there, even though it created a new broken dependency in the repo. The Taskatron depcheck appears to be broken or incomplete: It might be effective at checking whether the new package has any broken dependencies, but it definitely does not appear to check whether the update breaks OTHER packages' dependencies (at least I've seen 2 instances where it didn't catch that, and this is the third). The old AutoQA got that right. Kevin Kofler -- 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: Removing packages that have broken dependencies in F21 tree
Dne 13.11.2014 v 14:20 Kalev Lember napsal(a): rubygem-linecache19 rubygem-ruby-debug-base19 Removing this two will break rubygem-ruby-debug19, so you should remove it as well (unless maintainer fixes them, which does not appear to be the case). Vír -- 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: Removing packages that have broken dependencies in F21 tree
On 11/14/2014 02:15 PM, Vít Ondruch wrote: Dne 13.11.2014 v 14:20 Kalev Lember napsal(a): rubygem-linecache19 rubygem-ruby-debug-base19 Removing this two will break rubygem-ruby-debug19, so you should remove it as well (unless maintainer fixes them, which does not appear to be the case). I'll add it to the list, thanks! -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Removing packages that have broken dependencies in F21 tree
Hi, I would like to remove the packages that still have broken dependencies in the F21 tree. This is a followup to https://lists.fedoraproject.org/pipermail/devel/2014-October/203411.html It makes little sense to ship something that cannot even be installed. We're about to enter the final freeze next week in order to wrap up F21; after the gold release is done, fixes can no longer be pushed to the base repo. This means that anything that shipped with broken dependencies would stay that way in the base repo throughout the F21 lifetime. To avoid that, I'll file a FESCo ticket next Monday to approve dropping the following packages, unless they get fixed first: audtty authhub deltacloud-core django-recaptcha dragonegg edelib fatrat flush gdesklet-SlideShow gdesklets-citation gedit-valencia gofer gorm juffed leiningen libghemical libopensync-plugin-irmc ltsp meshmagick monodevelop-vala netdisco nwchem ocaml-pa-do openslides openvas-client pootle python-askbot-fedmsg python-coffin python-django-addons python-django-longerusername rubygem-linecache19 rubygem-rubigen rubygem-ruby-debug-base19 sugar-tamtam totpcgi transifex valabind why zyGrib Please note that Fedora policies allow adding new packages in the updates repo, so even if something gets dropped now, it can always be fixed and shipped in the updates repo at a later date. -- Thanks, Kalev On 11/13/2014 02:00 PM, Fedora Branched Report wrote: Compose started at Thu Nov 13 07:15:03 UTC 2014 Broken deps for armhfp -- [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 [gdesklet-SlideShow] gdesklet-SlideShow-0.9-16.fc21.noarch requires gdesklets [gdesklets-citation] gdesklets-citation-2.0-3.20120702git355e2ee.fc19.noarch requires gdesklets [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [gorm] gorm-1.2.18-5.fc20.armv7hl requires libgnustep-gui.so.0.23 [juffed] juffed-plugin-terminal-0.10-10.fc21.armv7hl requires libqtermwidget.so.0 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3 libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1 [ltsp] ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [ocaml-pa-do] ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [openslides] openslides-1.3.1-3.fc21.noarch requires python-django 0:1.5 [openstack-nova] openstack-nova-compute-2014.1.2-1.fc21.noarch requires libvirt-daemon-xen [openvas-client] openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_omp.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_nasl.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_misc.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_hg.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_base.so.6 [php-pecl-sphinx] php-pecl-sphinx-1.3.2-1.fc21.armv7hl requires libsphinxclient-0.0.1.so [pootle] pootle-2.1.6-8.fc21.noarch requires python-django14 [python-askbot-fedmsg] python-askbot-fedmsg-0.1.0-2.fc21.noarch requires askbot [python-coffin] python-coffin-0.3.7-3.fc21.noarch requires python-django14 [python-django-addons] python-django-addons
Re: Removing packages that have broken dependencies in F21 tree
On 13/11/14 14:33, Richard W.M. Jones wrote: On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote: ocaml-pa-do This package was rewritten upstream. I've not tried to package the new version. The version packaged in Fedora Rawhide is orphaned, so I guess you may as well remove the F21 package too (unless someone else wants to jump in and fix this). transifex Huh?? If this is the package I'm thinking of, it's pretty important to many other packages. yes, that's the package. But IMHO transifex became closed source, and last code change was about 2 years ago; since then, django changed quite a bit. Matthias -- 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: Removing packages that have broken dependencies in F21 tree
On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote: ocaml-pa-do This package was rewritten upstream. I've not tried to package the new version. The version packaged in Fedora Rawhide is orphaned, so I guess you may as well remove the F21 package too (unless someone else wants to jump in and fix this). transifex Huh?? If this is the package I'm thinking of, it's pretty important to many other packages. why This is another OCaml package. For some reason I'm not getting any emails about this, but I will try a rebuild now. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- 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: Removing packages that have broken dependencies in F21 tree
On 11/13/2014 03:33 PM, Richard W.M. Jones wrote: On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote: transifex Huh?? If this is the package I'm thinking of, it's pretty important to many other packages. It depends on python-django14 that was removed a while back and nobody seems to have ported it to a newer django version: [transifex] transifex-1.2.1-12.fc21.noarch requires python-django14 -- Kalev -- 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: Removing packages that have broken dependencies in F21 tree
On Thu, Nov 13, 2014 at 15:20:03 +0200, Kalev Lember kalevlem...@gmail.com wrote: meshmagick For meshmagick the real isssue is FTBFS due to stricter checking by gcc. I started working on it a while back but didn't finish and didn't get back to it. I believe I can get it fixed by Monday. -- 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: Removing packages that have broken dependencies in F21 tree
On Nov 13, 2014 8:02 AM, Kalev Lember kalevlem...@gmail.com wrote: On 11/13/2014 03:33 PM, Richard W.M. Jones wrote: On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote: transifex Huh?? If this is the package I'm thinking of, it's pretty important to many other packages. It depends on python-django14 that was removed a while back and nobody seems to have ported it to a newer django version: [transifex] transifex-1.2.1-12.fc21.noarch requires python-django14 -- Kalev -- transifex-client is probably seeing a lot more use ( at least on my desk :) It still seems openly active at https://github.com/transifex/transifex-client . I doubt they will change that - it's mostly just pycurl talking to an API, no secret sauce, and tx really does advocate open souce even if they struggled with making it commercially viable. --Pete -- 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: Removing packages that have broken dependencies in F21 tree
On Thu, Nov 13, 2014 at 6:33 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote: why This is another OCaml package. For some reason I'm not getting any emails about this, but I will try a rebuild now. I had already rebuilt it, and an update was pending. I just pushed the update to stable, so nothing further needs to be done here. -- Jerry James http://www.jamezone.org/ -- 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: Removing packages that have broken dependencies in F21 tree
On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote: totpcgi This requires an selinux export to make it build again: | + make NAME=mls -f /usr/share/selinux/devel/Makefile | Compiling mls totpcgi module | totpcgi.te:55: Warning: miscfiles_read_certs() has been deprecated, please use miscfiles_read_generic_certs() instead. | totpcgi.te:58: Warning: miscfiles_read_certs() has been deprecated, please use miscfiles_read_generic_certs() instead. | totpcgi.te:41:ERROR 'unknown type httpd_totpcgi_script_t' at token ';' on line 5216: | typeattribute httpd_totpcgi_script_t syslog_client_type; | #line 41 https://github.com/mricon/totp-cgi/issues/27 https://bugzilla.redhat.com/show_bug.cgi?id=1107456 Regards Till -- 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: Removing packages that have broken dependencies in F21 tree
On Thu, Nov 13, 2014 at 07:40:19PM +0100, Till Maas wrote: On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote: totpcgi This requires an selinux export to make it build again: | + make NAME=mls -f /usr/share/selinux/devel/Makefile | Compiling mls totpcgi module | totpcgi.te:55: Warning: miscfiles_read_certs() has been deprecated, please use miscfiles_read_generic_certs() instead. | totpcgi.te:58: Warning: miscfiles_read_certs() has been deprecated, please use miscfiles_read_generic_certs() instead. | totpcgi.te:41:ERROR 'unknown type httpd_totpcgi_script_t' at token ';' on line 5216: | typeattribute httpd_totpcgi_script_t syslog_client_type; | #line 41 https://github.com/mricon/totp-cgi/issues/27 https://bugzilla.redhat.com/show_bug.cgi?id=1107456 Thanks to tfirg on #selinux I now know that this is because apache_content_template() does not add a httpd_ prefix to types in F21+. Regards Till -- 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: Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)
On Thu, Oct 16, 2014 at 04:47:29PM +0200, Mathieu Bridon wrote: [cduce] cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 This fails to rebuild: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881630 This was waiting for an upstream fix. I have not checked the current status however. [ocaml-pa-do] ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 This fails to rebuild: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881760 This package is supposed to be orphaned and/or retired. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- 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: Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)
On Fri, Oct 17, 2014 at 5:59 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Thu, Oct 16, 2014 at 04:47:29PM +0200, Mathieu Bridon wrote: [cduce] cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 This fails to rebuild: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881630 This was waiting for an upstream fix. I have not checked the current status however. [ocaml-pa-do] ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 This fails to rebuild: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881760 This package is supposed to be orphaned and/or retired. It looks like the fedpkg retire was done in F-22, and not F-21. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)
Hi all, We seem to have a number of broken dependencies in F21 that have gone unfixed for a quite some time. Not sure what's up with them; the maintainers are supposed to get daily notifications to make sure these don't go unnoticed. Does anyone have ideas how to deal with these packages? I wonder if it would make sense to just drop them before F21. Having broken dependencies basically means that the packages are completely broken and cannot be installed at all. Not much point in shipping those in the repositories ... Any ideas how to deal with this? -- Kalev On 10/15/2014 01:45 PM, Fedora Branched Report wrote: Compose started at Wed Oct 15 07:15:03 UTC 2014 Broken deps for armhfp -- [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [cduce] cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [cp2k] cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl requires hibernate3-jbosscache = 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires libmetacity-private.so.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3 libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1 [ltsp] ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [ocaml-pa-do] ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [openslides] openslides-1.3.1-3.fc21.noarch requires python-django 0:1.5 [openstack-nova] openstack-nova-compute-2014.1.2-1.fc21.noarch requires libvirt-daemon-xen [openvas-client] openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_omp.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_nasl.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_misc.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_hg.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_base.so.6 [perl-RT-Authen-ExternalAuth] perl-RT-Authen-ExternalAuth-0.11-5.fc21.noarch requires rt3 [perl-RT-Extension-CommandByMail] perl-RT-Extension-CommandByMail-0.07-10.fc21.noarch requires perl(RT::Interface::Email) [pipelight-selinux] pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight [pootle] pootle-2.1.6-8.fc21.noarch requires python-django14 [python-askbot-fedmsg] python-askbot-fedmsg-0.1.0-2.fc21.noarch
Re: Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)
On Thu, Oct 16, 2014 at 14:40:50 +0200, Kalev Lember kalevlem...@gmail.com wrote: Does anyone have ideas how to deal with these packages? I have been meaning to deal with meshmagick. I actually did a small part of the changes locally. The issue is that stricter checking by gcc is resulting in the package not building and some repeated consructs need to be fixed. -- 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: Broken dependencies in F21
Thanks for bringing this up. Speaking of broken Ruby stuff: [rubygem-linecache19] rubygem-linecache19-0.5.13-6.fc20.armv7hl requires libruby.so.2.0 [rubygem-ruby-debug-base19] rubygem-ruby-debug-base19-0.11.26-6.fc20.armv7hl requires libruby.so.2.0 A while ago, I suggested to drop these and rubygem-ruby-debug19 as well, but the question is still unanswered by maintainer: https://lists.fedoraproject.org/pipermail/ruby-sig/2014-August/001654.html [rubygem-rubigen] rubygem-rubigen-1.5.8-3.fc21.noarch requires rubygem(activesupport) 0:3.2.0 This seems to be abandoned by upstream: https://github.com/drnic/rubigen/issues/15 [rubygem-simple_form] rubygem-simple_form-3.0.0-0.1.rc.fc20.noarch requires rubygem(activemodel) 0:4.1 rubygem-simple_form-3.0.0-0.1.rc.fc20.noarch requires rubygem(actionpack) 0:4.1 I guess we are waiting for new upstream release here. [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) Not sure how active is the upstream, but I asked maintainer/deltacloud upstream and he seems to go to orphan this package. But the fix might be as easy as dropping the dependencies, since they were retired in Fedora. [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [rubygem-thinking-sphinx] rubygem-thinking-sphinx-3.1.0-2.fc21.noarch requires rubygem(joiner) = 0:0.2.0 Not sure about the state of these two. It seems they were broken by updated dependencies, so they should be either updated, the dependencies should be relaxed (but also in .gemspec file, so it would need some patching) or fixed if there are some incompatibilities. Vít Dne 16.10.2014 v 14:40 Kalev Lember napsal(a): Hi all, We seem to have a number of broken dependencies in F21 that have gone unfixed for a quite some time. Not sure what's up with them; the maintainers are supposed to get daily notifications to make sure these don't go unnoticed. Does anyone have ideas how to deal with these packages? I wonder if it would make sense to just drop them before F21. Having broken dependencies basically means that the packages are completely broken and cannot be installed at all. Not much point in shipping those in the repositories ... Any ideas how to deal with this? -- 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: Broken dependencies in F21
On 16/10/14 14:40, Kalev Lember wrote: Hi all, We seem to have a number of broken dependencies in F21 that have gone unfixed for a quite some time. Not sure what's up with them; the maintainers are supposed to get daily notifications to make sure these don't go unnoticed. Does anyone have ideas how to deal with these packages? I wonder if it would make sense to just drop them before F21. Having broken dependencies basically means that the packages are completely broken and cannot be installed at all. Not much point in shipping those in the repositories ... Any ideas how to deal with this? openslides: Needs an update to latest version, and a few reviews for currently unpackaged deps. I didn't had the time for it django-recaptcha: I'm not the maintainer here. IMHO we just can drop it right now. pipelight-selinux: a leftover from pipelight removal. Should be dropped ASAP. python-askbot-fedmsg: askbot was retired, so should this one. Matthias -- 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: Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)
On Thu, 2014-10-16 at 14:40 +0200, Kalev Lember wrote: Hi all, We seem to have a number of broken dependencies in F21 that have gone unfixed for a quite some time. Not sure what's up with them; the maintainers are supposed to get daily notifications to make sure these don't go unnoticed. Does anyone have ideas how to deal with these packages? I wonder if it would make sense to just drop them before F21. Having broken dependencies basically means that the packages are completely broken and cannot be installed at all. Not much point in shipping those in the repositories ... Any ideas how to deal with this? Here's a quick look at some of them. Note that I'm not a provenpackager, so I can't actually do anything about it myself. ## libint soname bump [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 This can just be rebuilt: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881637 [cp2k] cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 This hasn't finished building yet, but it seems ok so far: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881650 ## json-c soname bump [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 This fails to build: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881643 ## rbtorrent soname bump [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 Seems this will need some upstream work: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881660 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 So does this: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881679 ## ocaml-camlp4 update The dep was updated: $ repoquery --provides ocaml-camlp4 ocaml(Camlp4) = 315363230d084ceb1cc5e85bfe2bfd49 [cduce] cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 This fails to rebuild: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881630 [ocaml-pa-do] ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 This fails to rebuild: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881760 ## vala update [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 This fails to build: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881927 However, there's a new upstream release which might fix the problem. [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala 0:0.25.0 This fails to build: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881961 However, there's a new upstream release which might fix the problem. [valabind] valabind-0.7.4-4.fc21.armv7hl requires libvala-0.24.so.0 This fails to build: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881954 However, there's a new upstream release which might fix the problem. ## Django 1.4 retired [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [openslides] openslides-1.3.1-3.fc21.noarch requires python-django 0:1.5 [pootle] pootle-2.1.6-8.fc21.noarch requires python-django14 [python-coffin] python-coffin-0.3.7-3.fc21.noarch requires python-django14 [python-django-addons] python-django-addons-0.6.6-2.fc21.noarch requires python-django14 [python-django-longerusername] python-django-longerusername-0.4-5.20130204gite4e85d7d.fc21.noarch requires python-django14 [transifex] transifex-1.2.1-12.fc21.noarch requires python-django14 Django 1.4 has been retired: https://lists.fedoraproject.org/pipermail/devel/2014-September/202593.html [python-askbot-fedmsg] python-askbot-fedmsg-0.1.0-2.fc21.noarch requires askbot Askbot was retired in f21 and master: https://lists.fedoraproject.org/pipermail/devel/2014-September/202687.html [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 Seems libaudclient was part of audacious but has then been removed upstream: http://audacious-media-player.org/download ## Unknown cases [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so This is weird, edelib provides libedelib.so.2.1.0, but somehow it requires libedelib.so Could it be the rpmbuild automatic requires generator misbehaved? [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [spring-maps-default] spring-maps-default-0.1-12.fc21.noarch requires spring [freesteam] freesteam-ascend-2.1
Re: Broken dependencies in F21
On 10/16/2014 02:40 PM, Kalev Lember wrote: [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires libmetacity-private.so.0 And replying to my own mail, this should be fixed with: https://admin.fedoraproject.org/updates/gnome-python2-desktop-2.32.0-20.fc21 -- Kalev -- 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: Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)
On Thu, Oct 16, 2014 at 04:47:29PM +0200, Mathieu Bridon wrote: On Thu, 2014-10-16 at 14:40 +0200, Kalev Lember wrote: Hi all, We seem to have a number of broken dependencies in F21 that have gone unfixed for a quite some time. Not sure what's up with them; the maintainers are supposed to get daily notifications to make sure these don't go unnoticed. Does anyone have ideas how to deal with these packages? I wonder if it would make sense to just drop them before F21. Having broken dependencies basically means that the packages are completely broken and cannot be installed at all. Not much point in shipping those in the repositories ... Any ideas how to deal with this? Here's a quick look at some of them. Note that I'm not a provenpackager, so I can't actually do anything about it myself. ## libint soname bump [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 This can just be rebuilt: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881637 Re-built: https://admin.fedoraproject.org/updates/PyQuante-1.6.4-13.fc21 Amusingly, it FTBFS on F22, apparently due to a change in numpy: http://koji.fedoraproject.org/koji/taskinfo?taskID=7882563 I'll let the maintainer fix that one. Pierre -- 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: Broken dependencies in F21
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 https://lists.fedoraproject.org/pipermail/devel/2014-August/201840.html - -- Antonio Trande mailto: sagitter 'at' fedoraproject 'dot' org http://fedoraos.wordpress.com/ https://fedoraproject.org/wiki/User:Sagitter GPG Key: 0x66E15D00 Check on https://keys.fedoraproject.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIbBAEBAgAGBQJUP+86AAoJEFyovWBm4V0AdA0P+Lz7W/0XubV3oN3VJz4lrKqQ JXrLFlYfMtaD2aZUdlOv6hhGnpbZashhXDbL0jw176sx+Y43v5/b7wnHcxTGEBoB udgfE/I6ansxzzrnjXc3boyDJ7sDFmEcMAkUcQ6RohQLZye4hEGXGH4s9Rz2EPfn zDZNX7du9NQ9aNwkLpz3T67n7bNAXRyUL10CXEn82PFbWfokPePf79i+yMXG9I77 IlaA2VYmevIMMVDbrkduF7P5drqmEcZL/gUiYuy6Qc3TGqyOaeZiGjIAk/xhavNS z6/pe4279HGsFNcAQ1iVUVtchvDc/mzyTTKz67VSeGSvabgcdD4J+wV8kkZsMYy3 aG768vMdN55foldOozm59WOdYezBsqi0+HEmP4tCu6X6PyfT1eYEJ7QpvWibB7Pj DfD9bsjyvNGLPZCOvIrvbL1X/HyBrtP9RCrgtwpg6NKB8jle+OZs8sQ9sqpZ29E/ YroJnrCc+8oXPodFbSdKAarsDanD7/qPZcakHaXrBeVEkdTbpc1THMvoKNvTC5b/ 40HGnn9EIvZgyDqvMI/bbuBGstkcbqucsZQlBDMN1BIPbe/frS8wfu+8Mwiip2I5 DlbhvqRhMB0I10JEgCqt/+zKNdnLR6ErmcxmqiaSmuyXemT2QR5912e/D2ouZkb4 tOeM60v5kSqFoI1/Dgc= =uehC -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: Broken dependencies in F21
On 10/16/2014 06:16 PM, Antonio Trande wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 https://lists.fedoraproject.org/pipermail/devel/2014-August/201840.html Likely fixed by https://admin.fedoraproject.org/updates/FEDORA-2014-12872/ascend-0.9.8-15.20140710svn4695.fc21 , can you test it and give the update karma? -- Thanks, Kalev -- 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: Broken dependencies in F21
On 10/16/2014 04:47 PM, Mathieu Bridon wrote: On Thu, 2014-10-16 at 14:40 +0200, Kalev Lember wrote: ## json-c soname bump json-c seems to have dropped the /usr/include/json - /usr/include/json-c symlink. This breaks packages, which depend upon /usr/include/json, e.g. libverto-jsonrpc. Was this change intentional or an accident? [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 This fails to build: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881643 Apart from the fact this package's spec appears suffer from bit rot, this package depends upon libverto-jsonrpc-devel, i.e. it indirectly is a victim of /usr/include/json having gone. 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: Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)
On Thursday, 16 October 2014 at 16:47, Mathieu Bridon wrote: On Thu, 2014-10-16 at 14:40 +0200, Kalev Lember wrote: Hi all, We seem to have a number of broken dependencies in F21 that have gone unfixed for a quite some time. Not sure what's up with them; the maintainers are supposed to get daily notifications to make sure these don't go unnoticed. Does anyone have ideas how to deal with these packages? I wonder if it would make sense to just drop them before F21. Having broken dependencies basically means that the packages are completely broken and cannot be installed at all. Not much point in shipping those in the repositories ... Any ideas how to deal with this? Here's a quick look at some of them. Note that I'm not a provenpackager, so I can't actually do anything about it myself. [...] [cp2k] cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 This hasn't finished building yet, but it seems ok so far: https://koji.fedoraproject.org/koji/taskinfo?taskID=7881650 https://admin.fedoraproject.org/updates/FEDORA-2014-12957/ in testing. Sorry, it took a while to get elpa building first and then fix the remaining issues in cp2k build. 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: Broken dependencies in F21 (was: Re: F-21 Branched report: 20141015 changes)
On Thu, 16 Oct 2014 14:40:50 +0200, Kalev Lember wrote: We seem to have a number of broken dependencies in F21 that have gone unfixed for a quite some time. Not sure what's up with them; the maintainers are supposed to get daily notifications to make sure these don't go unnoticed. Does anyone have ideas how to deal with these packages? [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 That library has been discontinued, but meanwhile has reappeared in a separate tarball. The original audtty packager had retired audtty in response to bugzilla tickets, but someone else has taken over the package without any activity [yet]. IMO, it would have been fine to resurrect the package no sooner than when something would be ready. E.g. a libaudclient review request with approval. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
