New repo closed as invalid
Hello, I have requested a repo for a package recently approved https://bugzilla.redhat.com/show_bug.cgi?id=2213588 and the releng-bot is closing the issue with "The Bugzilla review bug creator could not be found in FAS. Make sure your FAS email address is the same as in Bugzilla." For example, this one: https://pagure.io/releng/fedora-scm-requests/issue/65453 Any idea of what is happening? Best regards -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Review swap, python package
Hello, I have a python package pending review, it's required to upgrade APLpy to version 2.1. I'm happy to review other package in return. python-PyAVM - Python package to handle Astronomy Visualization Metadata https://bugzilla.redhat.com/show_bug.cgi?id=2213588 Best, Sergio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Help needed to fix FTBFS in scikit learn
I have reproduced the problem with a test case. The problem is in cython. It generates code with this type of problem in some cases (inlined methods of derived classes). I have reported the problem upstream https://github.com/cython/cython/issues/6033 I don't know how to continue from here. Is it possible to build C code with the old behaviour? Best, Sergio El sáb, 17 feb 2024 a las 22:19, Jakub Jelinek () escribió: > > On Sat, Feb 17, 2024 at 10:03:39PM +0100, Sergio Pascual wrote: > > Hello, currently python-scikit-learn fails to build in f40 and rawhide > > https://bugzilla.redhat.com/show_bug.cgi?id=2261602 > > > > The problem is a series of incompatible pointer conversions that > > appear in cython generated C code. > > The code has classes defined in cython and in the offending code > > "self" is passed as a pointer to the base class with a conversion to > > the derived class > > > > sklearn/metrics/_dist_metrics.c: In function > > ‘__pyx_f_7sklearn_7metrics_13_dist_metrics_19EuclideanDistance32_dist_csr’: > > sklearn/metrics/_dist_metrics.c:51033:90: error: passing argument 1 of > > ‘__pyx_f_7sklearn_7metrics_13_dist_metrics_19EuclideanDistance32_rdist_csr’ > > from incompatible pointer type [-Wincompatible-pointer-types] > > > > note: expected ‘struct > > __pyx_obj_7sklearn_7metrics_13_dist_metrics_EuclideanDistance32 *’ > > but argument is of type ‘struct > > __pyx_obj_7sklearn_7metrics_13_dist_metrics_DistanceMetric32 *’ > > If the conversion is correct and desirable, it needs to be explicit, not > implicit. > > Jakub > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Help needed to fix FTBFS in scikit learn
Hello, currently python-scikit-learn fails to build in f40 and rawhide https://bugzilla.redhat.com/show_bug.cgi?id=2261602 The problem is a series of incompatible pointer conversions that appear in cython generated C code. The code has classes defined in cython and in the offending code "self" is passed as a pointer to the base class with a conversion to the derived class sklearn/metrics/_dist_metrics.c: In function ‘__pyx_f_7sklearn_7metrics_13_dist_metrics_19EuclideanDistance32_dist_csr’: sklearn/metrics/_dist_metrics.c:51033:90: error: passing argument 1 of ‘__pyx_f_7sklearn_7metrics_13_dist_metrics_19EuclideanDistance32_rdist_csr’ from incompatible pointer type [-Wincompatible-pointer-types] note: expected ‘struct __pyx_obj_7sklearn_7metrics_13_dist_metrics_EuclideanDistance32 *’ but argument is of type ‘struct __pyx_obj_7sklearn_7metrics_13_dist_metrics_DistanceMetric32 *’ Regards, Sergio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
El dom, 28 ene 2024 a las 18:06, Maxwell G () escribió: > > Report started at 2024-01-28 16:04:44 UTC > > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the affected > packages or a package that depends on one. Please adopt the affected package > or > retire your depending package to avoid broken dependencies, otherwise your > package will be retired when the affected package gets retired. > > Request package ownership via the *Take* button in he left column on > https://src.fedoraproject.org/rpms/ > > Full report available at: > https://a.gtmx.me/orphans/orphans.txt > grep it for your FAS username and follow the dependency chain. > > For human readable dependency chains, > see https://packager-dashboard.fedoraproject.org/ > For all orphaned packages, > see https://packager-dashboard.fedoraproject.org/orphan > > Package (co)maintainersStatus > Change > > 3proxy orphan 3 weeks ago > applet-window-buttons @kde-sig, orphan0 weeks ago > bismuth@kde-sig, orphan0 weeks ago > cdsclient @astro-sig, orphan 4 weeks ago > csmith orphan 4 weeks ago > drumstick0 orphan, yanqiyu 1 weeks ago > elpa @scitech_sig, orphan3 weeks ago > kpipewire5 @kde-sig, orphan2 weeks ago > lightlyorphan 0 weeks ago > php-PHP-CSS-Parser orphan 3 weeks ago > plasma-bigscreen @kde-sig, orphan0 weeks ago > python-GridDataFormats @scitech_sig, orphan3 weeks ago > python-compressed-rtf orphan 4 weeks ago > python-extractcode @python-packagers-sig, orphan 0 weeks ago > python-flit@epel-packagers-sig, @python- 0 weeks ago >packagers-sig, orphan, salimma > python-jupyter-collaboration orphan 2 weeks ago > python-jupyter-server-fileid orphan 2 weeks ago > python-jupyter-ydocorphan 2 weeks ago > python-kaitaistructorphan 3 weeks ago > python-maya@neuro-sig, orphan 5 weeks ago > python-mmtf@scitech_sig, orphan3 weeks ago > python-mrcfile orphan 3 weeks ago > python-red-black-tree-mod orphan 4 weeks ago > python-represent orphan 0 weeks ago > python-y-py@python-packagers-sig, orphan 2 weeks ago > python-ypy-websocket orphan 2 weeks ago > qterm orphan 4 weeks ago > rubygem-hrxjcpunk, orphan, tdawson 5 weeks ago > rubygem-linked-listjcpunk, orphan, tdawson 5 weeks ago > rubygem-rubygems-mirror@ruby-packagers-sig, orphan 1 weeks ago > rust-lib0 @rust-sig, orphan 2 weeks ago > rust-yrs @rust-sig, orphan 2 weeks ago > scamp @astro-sig, orphan 4 weeks ago > sphinxbase @epel-packagers-sig, orphan 0 weeks ago > tachyon@scitech_sig, orphan3 weeks ago > virtme orphan 3 weeks ago > xdrawchem @scitech_sig, orphan3 weeks ago > I have taken scamp and cdsclient Regards -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Updating wcslib in rawhide to 8.2.2 (with sidetag)
El jue, 11 ene 2024 a las 8:11, Mattia Verga via devel () escribió: > > Il 09/01/24 17:20, Sergio Pascual ha scritto: > > Hello, I have created the side tag f40-build-side-81054 to build > > packages depending on wcslib > > > > Build your package with: > > fedpkg build --target=f40-build-side-81054 > > > > Affected: > > astrometry > > cpl > > kstars > > python3-astrometry > > python3-astropy > > siril > > sourcextractor++ > > stellarsolver > > > > I have already built cpl and I'm building python-astropy now > > > I've rebuilt siril in the side-tag. > > Astrometry rebuild failed because it requires python-astropy which is > currently FTB with wcslib 8. I have fixed the problem and astropy has been built in the side tag. Regards, sergio > > Mattia > > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Updating wcslib in rawhide to 8.2.2 (with sidetag)
Hello, I have created the side tag f40-build-side-81054 to build packages depending on wcslib Build your package with: fedpkg build --target=f40-build-side-81054 Affected: astrometry cpl kstars python3-astrometry python3-astropy siril sourcextractor++ stellarsolver I have already built cpl and I'm building python-astropy now Best regards, Sergio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Are package-owner mail addresses working?
El lun, 1 ene 2024 a las 13:49, Mamoru TASAKA () escribió: > > Sergio Pascual wrote on 2024/01/01 21:36: > > Hello and happy new year. > > > > Are package-owner mail addresses working? I have send mails to several > > and they return a 550 error message, for example: > > > > 550 5.1.1 : Recipient address > > rejected: User unknown in local recipient table > > > > Best, Sergio > > -- > > Currently it is -maintain...@fedoraproject.org : > > https://fedoraproject.org/wiki/EmailAliases > Great, thank you. In that case, the "senmail.to" property in the rpm git repositories should be updated to point to the correct address. I have checked several repositories and all have -owner addresses there. For example: $ git config sendemail.to cfitsio-ow...@fedoraproject.org > Mamoru > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Are package-owner mail addresses working?
Hello and happy new year. Are package-owner mail addresses working? I have send mails to several and they return a 550 error message, for example: 550 5.1.1 : Recipient address rejected: User unknown in local recipient table Best, Sergio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Updating wcslib in rawhide to 8.2.2
Hello, I'm going to update (one week from now) wcslib from 7.12 to 8.2. There is an API break, the changes are here; https://www.atnf.csiro.au/people/mcalabre/WCS/CHANGES Affected: astrometry cpl kstars python3-astrometry python3-astropy siril sourcextractor++ stellarsolver I will send another message with the side tag in one week. Regards, Sergio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Brasero can't create CD images in F39
Hello, I would like to bring attention to this bug https://bugzilla.redhat.com/show_bug.cgi?id=2250192 This problem prevents Brasero from creating CD images in F39. Brasero complains about "old version of cdrdao", but the version in F39 is the latest (1.2.5). It actually works if you force install an older (1.2.4) cdrdao from F37. Regards, Sergio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
CCfits license correction: "BSD" to "CFITSIO"
Hello, the license of CCfits was incorrectly identified as "BSD", it is actually "CFITSIO". I have updated it in rawhide. Regards, Sergio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
cfitsio license correction: "MIT" to "CFITSIO"
Hello, the license of cfitsio was incorrectly identified as "MIT", it is actually "CFITSIO". I have updated it in rawhide. Regards, Sergio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Cfitsio soname bump, side tag created
El vie, 30 dic 2022 a las 2:33, Maxwell G via devel (< devel@lists.fedoraproject.org>) escribió: > On Thu Dec 29, 2022, Maxwell G via devel wrote: > > On Thu Dec 29, 2022, Maxwell G via devel wrote: > > > On Wed Dec 28, 2022 at 15:00 +0100, Sergio Pascual wrote: > > > > Hello again, as stated before [1], I'm updating cfitsio to 4.2. I > have > > > > created a side tag f38-build-side-61457 > > > > > > > > I have already built cfitsio, CCfits and wcslib. > > > > > > > > @music already built luminance-hdr. I'm submitting builds for the rest. > > > > > > The builds have finished. The following packages failed to build after > > being rebuilt a total of three times: > > > > name:taskid:status > > -- > > astrometry:95679269:failed > > esorex:95679267:failed > > python-astropy:95679270:failed > > python-healpy:95679272:failed > > > > > > esorex and python-astropy are preexisting failures. python-healpy and > > astrometry depend on python-astropy and are failing with > > > > DEBUG util.py:443: No matches found for the following disable plugin > patterns: local, spacewalk, versionlock > > DEBUG util.py:445: Package pkgconf-pkg-config-1.8.0-3.fc37.aarch64 is > already installed. > > DEBUG util.py:443: Error: > > DEBUG util.py:443: Problem: conflicting requests > > DEBUG util.py:443:- nothing provides libcfitsio.so.9()(64bit) needed > by python3-astropy-5.1-3.fc38.aarch64 > > DEBUG util.py:445: (try to add '--skip-broken' to skip uninstallable > packages) > > DEBUG util.py:596: Child return code was: 1 > > I've submitted > https://src.fedoraproject.org/rpms/python-astropy/pull-request/2/. > > Hello, I have built python-astropy 5.2 in the side tag, we can continue with the packages depending on it. I have taken care of esorex too ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Cfitsio soname bump, side tag created
Hello again, as stated before [1], I'm updating cfitsio to 4.2. I have created a side tag f38-build-side-61457 I have already built cfitsio, CCfits and wcslib. Affected packages are: astrometry bes CCfits cpl elements-alexandria gdal healpix indi-3rdparty-gphoto kstars kst LabPlot libindi luminance-hdr perl-Astro-FITS-CFITSIO phd2 python-astropy python-fitsio python-healpy root siril skyviewer sourcextractor++ ufraw vips wcslib Best regards, Sergio [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SRAVHMZMCH7AUX5ZAEYAZ6MSQIY475YJ/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Cfitsio soname bump
Hello, I'm going to update to cfitsio 4.2 in Rawhide. This involves a soname bump. Affected packages: astrometry bes CCfits cpl elements-alexandria gdal healpix indi-gphoto kstars kst LabPlot libindi luminance-hdr perl-Astro-FITS-CFITSIO phd2 python-astropy python-fitsio python-healpy root siril skyviewer sourcextractor++ ufraw vips wcslib I think the preferred way to update these days is using a side tag. I will send another message with the side tag in one week (and/or create PRs). Best regards, Sergio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F35 no USB after today's updates
El lun, 8 nov 2021 a las 19:01, Sergio Pascual () escribió: > > > El lun, 8 nov 2021 a las 15:02, Sergio Pascual () > escribió: > >> >> >> El lun, 8 nov 2021 a las 14:36, Stephen John Smoogen () >> escribió: >> >>> >>> Can you try downgrading to the F34 linux-firmware and see if the f34 >>> kernel sees the chipset again? >>> >>> >>> >> I have downgraded everything to the released F35 and now it works, with >> kernel 5.14.16-301 and linux-firmware-20210919-125 >> >> >> > I have updated the system from F35 without updates to fully updated and > the problem has disappeared. I have updated in small groups of packages and > rebooted afterwards to check USB. Whatever happened, it is fixed now. My > current kernel is 5.14.16-301 but 5.15.15-300 works also > >> >> > The problem with the missing usb reappeared again this morning. This time I have installed kernel 5.14.13-300.fc35.x86_64, which fixes the problem. Probably I'm suffering https://bugzilla.redhat.com/show_bug.cgi?id=2019788 so at least I can workaround the problem. Thanks everyone! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 no USB after today's updates
El lun, 8 nov 2021 a las 15:02, Sergio Pascual () escribió: > > > El lun, 8 nov 2021 a las 14:36, Stephen John Smoogen () > escribió: > >> >> Can you try downgrading to the F34 linux-firmware and see if the f34 >> kernel sees the chipset again? >> >> >> > I have downgraded everything to the released F35 and now it works, with > kernel 5.14.16-301 and linux-firmware-20210919-125 > > > I have updated the system from F35 without updates to fully updated and the problem has disappeared. I have updated in small groups of packages and rebooted afterwards to check USB. Whatever happened, it is fixed now. My current kernel is 5.14.16-301 but 5.15.15-300 works also > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 no USB after today's updates
El lun, 8 nov 2021 a las 14:36, Stephen John Smoogen () escribió: > > Can you try downgrading to the F34 linux-firmware and see if the f34 > kernel sees the chipset again? > > > I have downgraded everything to the released F35 and now it works, with kernel 5.14.16-301 and linux-firmware-20210919-125 > > -- > Stephen J Smoogen. > Let us be kind to one another, for most of us are fighting a hard > battle. -- Ian MacClaren > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 no USB after today's updates
El lun, 8 nov 2021 a las 13:39, Stephen John Smoogen () escribió: > On Mon, 8 Nov 2021 at 06:53, Sergio Pascual > wrote: > > > > Hi, I upgraded my workstation to F35 last Friday, and today I 'dnf > updated' and rebooted. After the reboot, all my USBs are disabled. No > mouse, no keyword. > > I know my hardware works because the keyboard works in grub, and the > light of my optical mouse in on until some errors appear in the kernel > during boot. > > > > I have tried: > > kernel-5.14.15-200.fc34.x86_64 > > kernel-5.14.15-300.fc35.x86_64 > > kernel-5.14.16-301.fc35.x86_64 > > > > The developers will need to know what the exact motherboard/laptop > version and manufacturer you have in order to diagnose this issue. My > initial guess is that since the f34 kernel also fails, that the > problem is with a firmware module and whatever the motherboard is > expecting to use. [The fact that it is only finding USB2 says that > either the system is really old or that it is trying to fail to its > lowest working value.] > > > My workstation is a Dell Precision Tower 7910. lscpi says I have the following serial bus controllers 00:14.0 USB controller: Intel Corporation C610/X99 series chipset USB xHCI Host Controller (rev 05) 00:1a.0 USB controller: Intel Corporation C610/X99 series chipset USB Enhanced Host Controller #2 (rev 05) 00:1d.0 USB controller: Intel Corporation C610/X99 series chipset USB Enhanced Host Controller #1 (rev 05) Regards > > without success. > > I'm getting messages like these: > > > > [ 23.722355] usb 3-10: new high-speed USB device number 7 using > xhci_hcd > > [ 23.857746] usb 3-10: New USB device found, idVendor=0bda, > idProduct=0184, bcdDevice=84.13 > > [ 23.857755] usb 3-10: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > > [ 23.857759] usb 3-10: Product: USB2.0-CRW > > [ 23.857762] usb 3-10: Manufacturer: Generic > > [ 23.857764] usb 3-10: SerialNumber: 2010081884130 > > [ 24.016363] usb 3-7.1: new high-speed USB device number 8 using > xhci_hcd > > [ 29.648377] usb 3-7.1: device descriptor read/64, error -110 > > [ 45.520400] usb 3-7.1: device descriptor read/64, error -110 > > [ 45.624451] usb 3-7-port1: attempt power cycle > > [ 45.738358] usb 3-13: new high-speed USB device number 9 using > xhci_hcd > > [ 45.865929] usb 3-13: New USB device found, idVendor=05e3, > idProduct=0608, bcdDevice=32.98 > > [ 45.865939] usb 3-13: New USB device strings: Mfr=0, Product=1, > SerialNumber=0 > > [ 45.865942] usb 3-13: Product: USB2.0 Hub > > [ 45.866653] hub 3-13:1.0: USB hub found > > [ 45.866992] hub 3-13:1.0: 4 ports detected > > [ 46.304365] usb 3-7.1: new high-speed USB device number 10 using > xhci_hcd > > [ 56.160384] xhci_hcd :00:14.0: Abort failed to stop command ring: > -110 > > [ 56.160384] xhci_hcd :00:14.0: xHCI host controller not > responding, assume dead > > [ 56.160384] xhci_hcd :00:14.0: HC died; cleaning up > > [ 56.488455] xhci_hcd :00:14.0: Timeout while waiting for setup > device command > > [ 56.488480] usb 4-2: USB disconnect, device number 2 > > [ 56.904366] usb 3-7.1: device not accepting address 10, error -108 > > [ 56.904412] usb 3-7-port1: couldn't allocate usb_device > > [ 56.904464] usb usb3-port2: couldn't allocate usb_device > > [ 56.904502] usb 3-13-port1: couldn't allocate usb_device > > [ 56.904603] usb 3-3: USB disconnect, device number 2 > > [ 56.927819] usb 3-6: USB disconnect, device number 3 > > > > > > > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > > > > -- > Stephen J Smoogen. > Let us be kind to one another, for most of us are fighting a hard > battle. -- Ian MacClaren > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: &
F35 no USB after today's updates
Hi, I upgraded my workstation to F35 last Friday, and today I 'dnf updated' and rebooted. After the reboot, all my USBs are disabled. No mouse, no keyword. I know my hardware works because the keyboard works in grub, and the light of my optical mouse in on until some errors appear in the kernel during boot. I have tried: kernel-5.14.15-200.fc34.x86_64 kernel-5.14.15-300.fc35.x86_64 kernel-5.14.16-301.fc35.x86_64 without success. I'm getting messages like these: [ 23.722355] usb 3-10: new high-speed USB device number 7 using xhci_hcd [ 23.857746] usb 3-10: New USB device found, idVendor=0bda, idProduct=0184, bcdDevice=84.13 [ 23.857755] usb 3-10: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 23.857759] usb 3-10: Product: USB2.0-CRW [ 23.857762] usb 3-10: Manufacturer: Generic [ 23.857764] usb 3-10: SerialNumber: 2010081884130 [ 24.016363] usb 3-7.1: new high-speed USB device number 8 using xhci_hcd [ 29.648377] usb 3-7.1: device descriptor read/64, error -110 [ 45.520400] usb 3-7.1: device descriptor read/64, error -110 [ 45.624451] usb 3-7-port1: attempt power cycle [ 45.738358] usb 3-13: new high-speed USB device number 9 using xhci_hcd [ 45.865929] usb 3-13: New USB device found, idVendor=05e3, idProduct=0608, bcdDevice=32.98 [ 45.865939] usb 3-13: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 45.865942] usb 3-13: Product: USB2.0 Hub [ 45.866653] hub 3-13:1.0: USB hub found [ 45.866992] hub 3-13:1.0: 4 ports detected [ 46.304365] usb 3-7.1: new high-speed USB device number 10 using xhci_hcd [ 56.160384] xhci_hcd :00:14.0: Abort failed to stop command ring: -110 [ 56.160384] xhci_hcd :00:14.0: xHCI host controller not responding, assume dead [ 56.160384] xhci_hcd :00:14.0: HC died; cleaning up [ 56.488455] xhci_hcd :00:14.0: Timeout while waiting for setup device command [ 56.488480] usb 4-2: USB disconnect, device number 2 [ 56.904366] usb 3-7.1: device not accepting address 10, error -108 [ 56.904412] usb 3-7-port1: couldn't allocate usb_device [ 56.904464] usb usb3-port2: couldn't allocate usb_device [ 56.904502] usb 3-13-port1: couldn't allocate usb_device [ 56.904603] usb 3-3: USB disconnect, device number 2 [ 56.927819] usb 3-6: USB disconnect, device number 3 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Cfitsio soname bump
El mié, 3 feb 2021 a las 14:33, Alejandro Álvarez Ayllón (< aalva...@fedoraproject.org>) escribió: > Hi Sergio, > > Could you trigger a rebuild of ccfits, please? It seems it was rebuilt > against cfitsio 3.470, being uninstallable right now in rawhide. > > Hi Alejandro, it's done https://koji.fedoraproject.org/koji/buildinfo?buildID=1703454 > Best regards, > Alejandro > > El jue, 14 ene 2021 a las 1:17, Sergio Pascual () > escribió: > >> Hello, I'm going to build new cfitsio 3.490 in Rawhide in a week. This >> involves a soname bump. >> >> The affected packages are the following: >> >> CCfits >> LabPlot >> astrometry >> bes >> cpl >> elements-alexandria >> gdal >> healpix >> indi-gphoto >> kst >> kstars >> libindi >> luminance-hdr >> nightviewperl-Astro-FITS-CFITSIO >> phd2 >> python-astropy >> python-fitsio >> python-healpy >> root >> siril >> skyviewer >> sourcextractor++ >> ufraw >> vips >> wcslib >> >> Best regards, Sergio >> >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Cfitsio soname bump
Hello, I'm going to build new cfitsio 3.490 in Rawhide in a week. This involves a soname bump. The affected packages are the following: CCfits LabPlot astrometry bes cpl elements-alexandria gdal healpix indi-gphoto kst kstars libindi luminance-hdr nightviewperl-Astro-FITS-CFITSIO phd2 python-astropy python-fitsio python-healpy root siril skyviewer sourcextractor++ ufraw vips wcslib Best regards, Sergio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Updating wcslib in Rawhide to 7.1
Hello, I'm going to update (one week from now) wcslib to from 6.4 to 7.1. There is an API break, the changes are here; https://www.atnf.csiro.au/people/mcalabre/WCS/CHANGES I'm CCing affected package owners (astrometry, cpl, kstars and python-astropy). Regards, Sergio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Help with gcc10-arm-only problem
Hi list, I'm trying to fix this problem https://bugzilla.redhat.com/show_bug.cgi?id=1799588 It built in previous releases, so I assume is gcc 10 related https://koji.fedoraproject.org/koji/taskinfo?taskID=41318599 The package build in all arches except in arm an the error is: /builddir/build/BUILD/libindi-1.8.1/libs/indibase/inditelescope.cpp: In member function 'bool INDI::Telescope::processTimeInfo(const char*, const char*)': /builddir/build/BUILD/libindi-1.8.1/libs/indibase/inditelescope.cpp:1647:17: error: 'stime' was not declared in this scope; did you mean 'ctime'? 1647 | stime(&raw_time); | ^ | ctime make[2]: *** [CMakeFiles/indidriverstatic.dir/build.make:352: CMakeFiles/indidriverstatic.dir/libs/indibase/inditelescope.cpp.o] Error 1 For some reason, stime works in all arches except in arm. Any hint? Thank you, Sergio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaning trac plugins
Hello, I have orphaned the following trac plugins, as I do not use trac anymore trac-xmlrpc-plugin trac-doxygen-plugin https://src.fedoraproject.org/rpms/trac-xmlrpc-plugin https://src.fedoraproject.org/rpms/trac-doxygen-plugin Regards, Sergio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Updating wcslib in Rawhide to 6.3
Hello, I'm going to update wcslib from 5.19 to 6.3. It breaks API, so I'm announcing it here in advance. The policy [1] says that I should notify also the maintainers of the packages that depend on mine. What command I have to run to know the names of the packages? After a bit to research I did: dnf repoquery --repoid=fedora --whatrequires wcslib But this checks against my current Fedora (30 in my host). How do I check against Rawhide? It would help a lot if this information were in the documentation. Regards, Sergio [1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_rawhide_devel_master ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Help needed with FTBFS of package cpl in i686 and Fedora>=29
Hello, I'm trying to fix a FTBFS bug in cpl, a C library. The package fails
in i686 on Fedora>=29 and compiles in Fedora<=28
https://koji.fedoraproject.org/koji/taskinfo?taskID=29215071
https://kojipkgs.fedoraproject.org//work/tasks/5071/29215071/build.log
I imagine that, after enabling SSE2 in Fedora 29, we are compiling a
different code path
that fails. I don't have any experience with this kind of code.
The error is related with _m_from_int64, that seems undefined? But
_m_from_int64 is defined in one of the *intrin.h headers. I'm don't know
what is happening.
cpl_image_basic.c: In function 'dcompl_mult_sse_fast':
cpl_image_basic.c:245:30: warning: implicit declaration of function
'_m_from_int64'; did you mean '_m_from_int'?
[-Wimplicit-function-declaration]
#define cpl_m_from_int64 _m_from_int64
^
cpl_image_basic.c:260:54: note: in expansion of macro 'cpl_m_from_int64'
_mm_add_pd(a, _mm_xor_pd(b,
(__m128d)_mm_set_epi64(cpl_m_from_int64(0x0llu), \
^~~~
cpl_image_basic.c:4065:12: note: in expansion of macro 'CPL_MM_ADDSUB_PD'
return CPL_MM_ADDSUB_PD(t1, sb); /* x * y - y * w, z*y + x * w */
^~~~
cpl_image_basic.c:245:30: error: incompatible type for argument 1 of
'_mm_set_epi64'
#define cpl_m_from_int64 _m_from_int64
^
cpl_image_basic.c:260:54: note: in expansion of macro 'cpl_m_from_int64'
_mm_add_pd(a, _mm_xor_pd(b,
(__m128d)_mm_set_epi64(cpl_m_from_int64(0x0llu), \
^~~~
cpl_image_basic.c:4065:12: note: in expansion of macro 'CPL_MM_ADDSUB_PD'
return CPL_MM_ADDSUB_PD(t1, sb); /* x * y - y * w, z*y + x * w */
^~~~
In file included from
/usr/lib/gcc/i686-redhat-linux/8/include/xmmintrin.h:1252,
from cpl_image_basic.c:240:
/usr/lib/gcc/i686-redhat-linux/8/include/emmintrin.h:595:22: note: expected
'__m64' {aka '__vector(2) int'} but argument is of type 'int'
_mm_set_epi64 (__m64 __q1, __m64 __q0)
~~^~~~
cpl_image_basic.c:245:30: error: incompatible type for argument 2 of
'_mm_set_epi64'
#define cpl_m_from_int64 _m_from_int64
Any help would be appreciated, I have never touched code like this.
Best, Sergio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JAHKEG2PUN5IX2KMIJUXQHJN5YBXBL6E/
Retire loki-lib
I would like to retire loki-lib. It's a C++ library that hasn't been updated in nearly 10 years. It FTBS for some releases (circa F23) Repoquery says that nothing in Fedora depends on it. Regards, Sergio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/S2XX6OMGDZKKG4ZF6TD4C2FYD4F2VSPA/
xpa license change
The license in xpa has changed from LGPLv2+ in version 2.1.15 to MIT in xpa 2.1.18 Regards, Sergio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GSN2MSQRTH5RZ2ZLVMOVHNQMYAKFZYE4/
Re: Cfitsio soname bump
Hi 2018-05-26 10:12 GMT+02:00 Christian Dersch : > > @Sergio: For F28 we have to coordinate somehow. Yes, when I saw how many packages depend on cfitsio, I thought, "this is going to be difficult in F28, but in rawhide it will be easier" > I'm unhappy with the > soname bump (and the way upstream handles security fixes), they bump for > almost every new release nowadays… > > In the past, I have exchanged some lengthy mails with upstream explaining when they should change the soname. They didn't have a soname then. In seems that I didn't explain myself very well. > Greetings, > Christian > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@lists. > fedoraproject.org/message/YDAYVECLC33VIE4VABS57EA6UMOSYD35/ > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YDDXQWDEVD5IKF5CVLSNTX46MVB5AOUW/
Re: Cfitsio soname bump
Sorry, I tried to follow the policy as I remembered it. As a packager with limited time to work in Fedora, I tend to update packages. It's difficut for me to be up to date with the all the policy changes, the guidelines changes and the packaging changes. If Fedora wants this kind of policy to be effective, it should automate the checks. Like, I don't know, people is doing this days in github, with pull requests, automated sanity checks of the RPMS, bots checking the dependecies of your packages and sending emails to the packger owners, etc 2018-05-25 17:55 GMT+02:00 Adam Williamson : > On Fri, 2018-05-25 at 12:41 +0200, Sergio Pascual wrote: > > Hello, I'm going to build new cfitsio 3.450 in Rawhide. This involves a > > soname bump. Notice that I plan to do the same in F28 (with a buildroot > > override, etc) as cfitsio has security issues > > https://bugzilla.redhat.com/show_bug.cgi?id=1570484 > > Thanks for the heads-up, but this is still not in line with the policy: > > "When a proposed update contains an ABI or API change: notify a week in > advance both fedora-devel and maintainers directly (using the > packagename-owner@ alias) whose packages depend on yours to rebuild or > offer to do these rebuilds for them." > > Note, in the original "a week in advance" is bolded. AFAICS you did not > send this notice to the package owners, nor did you send it "a week in > advance" - you have done the build already. > > https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master > > > > > The list of dependencies I get are: > > > > $ dnf --releasever rawhide repoquery --whatrequires cfitsio --alldeps > --srpm > > > > CCfits-0:2.5-7.fc29.src > > astrometry-0:0.73-4.fc29.src > > bes-0:3.17.4-7.fc29.src > > cfitsio-0:3.430-1.fc29.src > > cpl-0:7.0-8.fc29.src > > gdal-0:2.2.4-2.fc29.src > > healpix-0:3.31-10.fc29.src > > indi-apogee-0:1.6.2-3.fc29.src > > indi-gphoto-0:1.6.2-4.fc29.src > > kst-0:2.0.8-20.fc29.src > > kstars-1:2.9.3-2.fc29.src > > libindi-0:1.6.2-3.fc29.src > > luminance-hdr-0:2.5.1-11.fc29.src > > nightview-0:0.3.3-27.fc29.src > > perl-Astro-FITS-CFITSIO-0:1.11-7.fc29.src > > phd2-0:2.6.5-1.fc29.src > > pyfits-0:3.5-3.fc29.src > > python-astropy-0:3.0.1-1.fc29.src > > python-fitsio-0:0.9.11-5.fc29.src > > python-healpy-0:1.11.0-4.fc29.src > > python2-astropy-0:2.0.5-2.fc29.src > > root-0:6.12.06-2.fc29.src > > siril-0:0.9.8.3-3.fc29.src > > skyviewer-0:1.0.1-14.fc29.src > > ufraw-0:0.22-12.fc29.src > > vips-0:8.6.2-4.fc29.src > > wcslib-0:5.18-1.fc29.src > > Now the build's been done I'll try and help with rebuilding at least > the most important of these. :/ > -- > 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 > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@lists. > fedoraproject.org/message/2R7LYBSDDTTU5KOIARZUVEWOUV64Z7FM/ > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RBFODV6MOVWIMBWEQLHESQDHLKRE2UU6/
Cfitsio soname bump
Hello, I'm going to build new cfitsio 3.450 in Rawhide. This involves a soname bump. Notice that I plan to do the same in F28 (with a buildroot override, etc) as cfitsio has security issues https://bugzilla.redhat.com/show_bug.cgi?id=1570484 The list of dependencies I get are: $ dnf --releasever rawhide repoquery --whatrequires cfitsio --alldeps --srpm CCfits-0:2.5-7.fc29.src astrometry-0:0.73-4.fc29.src bes-0:3.17.4-7.fc29.src cfitsio-0:3.430-1.fc29.src cpl-0:7.0-8.fc29.src gdal-0:2.2.4-2.fc29.src healpix-0:3.31-10.fc29.src indi-apogee-0:1.6.2-3.fc29.src indi-gphoto-0:1.6.2-4.fc29.src kst-0:2.0.8-20.fc29.src kstars-1:2.9.3-2.fc29.src libindi-0:1.6.2-3.fc29.src luminance-hdr-0:2.5.1-11.fc29.src nightview-0:0.3.3-27.fc29.src perl-Astro-FITS-CFITSIO-0:1.11-7.fc29.src phd2-0:2.6.5-1.fc29.src pyfits-0:3.5-3.fc29.src python-astropy-0:3.0.1-1.fc29.src python-fitsio-0:0.9.11-5.fc29.src python-healpy-0:1.11.0-4.fc29.src python2-astropy-0:2.0.5-2.fc29.src root-0:6.12.06-2.fc29.src siril-0:0.9.8.3-3.fc29.src skyviewer-0:1.0.1-14.fc29.src ufraw-0:0.22-12.fc29.src vips-0:8.6.2-4.fc29.src wcslib-0:5.18-1.fc29.src Regards ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FP346J6ASAXQLWCEVGC6RU333VZS5IEV/
Package stops supporting python 2.7 in latest version, what to do now
Hello all, python package astropy as ceased to support python 2.7 in its latest version, 3.0. It still provides a LTS version that supports both python 2 and 3. As astropy packagers, we seek advice on how to manage this situation. So the posibilities are: 1) package the version with support of python 3 and forget about python 2 2) package the LTS version that supports both python 2 and 3 3) package the LTS version for python 2 and the new version for python 3. In the third case, wihich consider the best approach, do I need to create a new package and go through the review process? Best regards, Sergio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Multiseat seems broken in Fedora 24
2016-11-03 15:08 GMT+01:00 Ray Strode : > Hi, > > > Is this use case still supported by Fedora? > It's definitely not a tested use case. Definitely worth filing a bug > in upstream (gnome) bugzilla. I filled https://bugzilla.gnome.org/show_bug.cgi?id=774144 Thanks > I wouldn't be surprised if there's more > than one bug that needs to get fixed before it will work again, > though. > It's going to get worse after > https://bugzilla.gnome.org/show_bug.cgi?id=741688 lands since > gnome-shell will only handle one seat, but it will get started > per-user. > > --Ray > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Multiseat seems broken in Fedora 24
Hello, I have a machine with two identical nvidia cards and I configured it with multiseat and Fedora 23. It worked well, that is, two GDM login screens, one in each display. Then I updated to Fedora 24 and it stoped to work. I have tested that multiseat works with the LiveCDs of Fedora 23 and Fedora 24. As soon as I do loginctl attach seat1 /sys/devices/pci:00//drm/card1 a GDM appears in the second screen. With the updated Fedora 24 I get a black screen. journalctl says something like: systemd-logind[1314]: New session c6 of user gdm. systemd[1]: Started Session c6 of user gdm. gdm-launch-environment][2804]: pam_unix(gdm-launch-environment:session): session opened for user gdm by (uid=0) audit[2804]: USER_START pid=2804 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:6 res=success' audit[2821]: ANOM_ABEND auid=4294967295 uid=42 gid=42 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 pid=2821 comm="gnome-session-c" exe="/usr/libexec/gnome-session-check-accelerated" sig=11 kernel: show_signal_msg: 3 callbacks suppressed kernel: gnome-session-c[2821]: segfault at 71 ip 7fb4b5655c8a sp 7ffd216e9520 error 4 in libX11.so.6.3.0[7fb4b5629000+139000] Basically, /usr/libexec/gnome-session-check-accelerated crashes There are quite a few bugs related with gnome-session-check-accelerated crashes in bugzilla. I can send a new one, but I'm afraid it will be lost in the sea of bugs. Is this use case still supported by Fedora? Sergio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
python-sep-1.0.0 license change
python-sep-1.0.0-1 has changed its license from "MIT and LGPLv3+" to "MIT and BSD and LGPLv3+" Regards ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
32-bit RPMs are being duplicated for CPL in the final repository
Hello, this is related to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1230595 CPL is a C library and 32-bit RPMS appear in the x86_64 repository. Who is the right person to ask/where to fill a bug/ if this is an infra issue? Best, Sergio -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Heads up, wcslib soname bump
Hello, tomorrow I'm going to update wcslib to 5.14, which includes a soname bump. This change affects the following packages: cpl kstars python-astropy astrometry Best regards, Sergio -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Enable Wake-On-LAN in current Fedora
I was wondering what is the "correct" way of enabling WOL on a network card. This Arch document [1] describes several methods (which basically are different methods on running "ethtool -s eth0 wol g"). * run ethtool in udev * run a cron on reboot * run a systemd unit This Fedora bug [2] suggests that you can make NetworkManager run a script in /etc/NetworkManager/dispatcher.d And finally you can use good old /etc/rc.d/rc.local and put there the ethtool command. Notice that all of this requires editing files, there isn't a check box somewhere in the NetworkManager GUI to enable this option, for example. Regards, Sergio [1] https://wiki.archlinux.org/index.php/Wake-on-LAN [2] https://bugzilla.redhat.com/show_bug.cgi?id=826652 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Continuous integration for Fedora
Hello, I have recently heard of Debian Continuous Integration, i.e, automated self tests are run for packages whenever its dependencies are updated. http://ci.debian.net/ Are there any plans to have something similar for Fedora? Regards, Sergio -- 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: F22 Self Contained Change: Disabled Repositories Support
2015-03-18 18:51 GMT+01:00 Ralf Corsepius : > On 03/18/2015 05:46 PM, Rahul Sundaram wrote: > >> Hi >> >> On Wed, Mar 18, 2015 at 12:21 PM, Mike Pinkerton wrote: >> >> >> What I don't understand is the wisdom of an official Fedora >> "product" endorsing a copr when either the software or packaging (or >> both) is not of sufficient quality to make it into the official >> Fedora repo. >> >> >> I don't think of it as a endorsement. >> > I see them as a means of discouraging people from packaging for Fedora: > > Ask yourself: "Why should I package a package properly, when I can get off > 'cheap'?" - msuchy's rationale is along this line. > > It is making them more easily >> discoverable but there is going to be a prompt of some sort that warns >> them of the nature of such software and users get to choose whether they >> are willing to accept that tradeoff for immediate access. One might >> choose to use say, Chromium regardless of the bundling issues for example. >> > > There are many more ways why a package not to be eligible for Fedora than > "bundling": > - Illegal/patent-encumbered in the US, but legal to distribute in other > countries. > - Legal to distribute binaries, repackaged for "packager lazyness", (e.g. > Java) or complexity (foreign arch binaries needed to support > cross-toolchains). > - Content-only packages (Videos, Audiofiles). > - Packages with ethical/political controversial contents. > ... > > In other words, if you are really serious about this plan, you need some > authority to continuously review the packages in such "endorsed" repos, > technically, legally and "politically". > > > The idea of use disabled-third-party-repos to ship non free software has been discused in the desktop list, this for example https://lists.fedoraproject.org/pipermail/desktop/2015-February/011634.html In fact, in the last meeting of the Workstation WG, one of the action items is: * Third party repositories (stickster, 15:41:18) * LINK: http://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Summary_table is interesting. (stickster, 15:48:12) * LINK: https://repos.fedorapeople.org/repos/spot/chromium/ , F21 last updated in january (kalev, 16:08:47) * LINK: https://copr.fedoraproject.org/coprs/churchyard/chromium-russianfedora/ is the other i was thinking of (jwb, 16:09:29) * AGREED: Go for Chrome next (stickster, 16:15:39) * ACTION: cschalle stickster work up justification for Council and review gnome-software text for an appropriate warning to suggest (stickster, 16:16:12) **Go for Chrome next.** Here is the full text. https://lists.fedoraproject.org/pipermail/desktop/2015-March/011722.html I said in my first message that the purpose of the Change is to help people to install non-free software. Probably I was wrong and there are legitimate uses. Anyway what is true is that *some people* wants to use this Change to make it easy to install non-free software. Sergio -- 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: F22 Self Contained Change: Disabled Repositories Support
2015-03-16 15:52 GMT+01:00 Jaroslav Reznik : > = Proposed Self Contained Change: Disabled Repositories Support = > https://fedoraproject.org/wiki/Changes/DisabledRepoSupport > > "Disabled Repositories Support" sounds better than "Help People Install Non-Free Software in Fedora", but the result is the same. Personally, I don't like it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
New libindi in Rawhide/F22, with soname bump
Hello, I'm going to update libindi to version 1.0, which includes a soname bump. All the indi drivers and kstars must be rebuilt. Christian Dersch (lupinix) is going to take of most of the rebuilds. Best, Sergio -- 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] Ring-based Packaging Policies
> > > > Also RH and other distros history repeatedly has told the lesson > > such will not fly and are doomed to fail. > > It seems to have been working just fine in RPMFusion, where the free > and nonfree repositories have different standards for inclusion, and > where packages in nonfree can depend on packages in free, but not the > other way. > The only difference in both repositories is the license of the software. The package guidelines are exactly the same as Fedora's (with the exception of kernel modules) in both repos. > At another scale, it seems to not be working too badly already for > Fedora+RPMFusion, where Fedora and RPMFusion have different standards > for inclusion, and where packages in RPMFusion can depend on packages > in Fedora, but not the other way. > The standard for inclusion in rpmfusion is not being elegible to be in Fedora. Again, the reasons are purelly legal (with the exception of kernel modules). Again, there is no difference in the guidelines (bundled libraries must be unblundled, etc) -- 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: Heads-up: python{,3}-sphinx-latex subpackage in Rawhide
Hello, 2015-01-23 11:04 GMT+01:00 Michel Alexandre Salim : > Hi all, > > From python-sphinx-1.2.2-6.fc22 onwards support for building LaTeX > documentation using Sphinx has been split off into the -latex subpackage > (so that Sphinx can be installed without pulling in TeXLive). > > (There's also a bug discovered when doing this split -- the python3 build > wasn't shipping with locale files). > this bug is related and requires fixing, in F21 at least, probably in F20 too: python-sphinx ships python3 files https://bugzilla.redhat.com/show_bug.cgi?id=1148037 Regards, Sergio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
deltarpm rebuild fails due to prelink missing?
Hi, perhaps this happens due to some oddity in my system, but I have noticed meesages like this while doing updates via yum (this has happened today) Downloading packages: updates/21/x86_64/prestodelta | 621 kB 00:00 Delta RPMs reduced 21 M of updates to 1.4 M (93% saved) (1/13): gdal-libs-1.11.1-4.fc21_1.11.1-5.fc21.x86_64.drpm | 463 kB 00:00 (2/13): gdal-python-1.11.1-4.fc21_1.11.1-5.fc21.x86_64.drpm | 42 kB 00:00 (3/13): glpk-4.53-5.fc21_4.53-6.fc21.x86_64.drpm| 87 kB 00:00 (4/13): harfbuzz-0.9.35-1.fc21_0.9.36-1.fc21.i686.drpm | 40 kB 00:00 (5/13): harfbuzz-0.9.35-1.fc21_0.9.36-1.fc21.x86_64.drpm| 41 kB 00:00 (6/13): harfbuzz-icu-0.9.35-1.fc21_0.9.36-1.fc21.x86_64.drp | 11 kB 00:00 (7/13): libgeotiff-1.2.5-16.fc21_1.4.0-2.fc21.x86_64.drpm | 323 kB 00:00 (8/13): phonon-4.8.1-1.fc21_4.8.2-1.fc21.x86_64.drpm| 49 kB 00:00 (9/13): qt5-qtlocation-5.4.0-1.fc21_5.4.0-2.fc21.x86_64.drp | 71 kB 00:00 (10/13): qt5-qtsensors-5.4.0-1.fc21_5.4.0-2.fc21.x86_64.drp | 22 kB 00:00 (11/13): stoken-libs-0.8-2.git.ba44603.fc21_0.81-1.fc21.x86 | 21 kB 00:00 (12/13): wireshark-1.12.2-1.fc21_1.12.2-2.fc21.x86_64.drpm | 271 kB 00:00 (13/13): wireshark-gnome-1.12.2-2.fc21.x86_64.rpm | 1.0 MB 00:00 Finishing delta rebuilds of 10 package(s) (20 M) /usr/sbin/prelink: No such file or directory prelink not installed, cannot undo prelinking/usr/sbin/prelink: No such file or directory prelink not installed, cannot undo prelinking/usr/sbin/prelink: No such file or directory prelink not installed, cannot undo prelinking/usr/sbin/prelink: No such file or directory /usr/sbin/prelink: No such file or directory ] 0.0 B/s | 1.9 MB --:-- ETA Some delta RPMs failed to download or rebuild. Retrying../s | 20 MB 00:00 ETA (1/5): harfbuzz-0.9.36-1.fc21.i686.rpm | 164 kB 00:00 (2/5): harfbuzz-0.9.36-1.fc21.x86_64.rpm| 160 kB 00:00 (3/5): harfbuzz-icu-0.9.36-1.fc21.x86_64.rpm| 17 kB 00:00 (4/5): libgeotiff-1.4.0-2.fc21.x86_64.rpm | 716 kB 00:00 (5/5): stoken-libs-0.81-1.fc21.x86_64.rpm | 43 kB 00:00 So it seems that the reconstruction of certain packages fails due to prelink missing? Regards, Sergio -- 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: Q: Splitting existing pkg into subpackages?!
2014-10-30 10:50 GMT+01:00 Alec Leamas : > On 30/10/14 10:41, Sergio Pascual wrote: > >> Hello >> >> 2014-10-30 10:32 GMT+01:00 Alec Leamas > <mailto:leamas.a...@gmail.com>>: >> >> Hi all! >> >> >> Feeling dumb (again...) I have a package which I now need to split >> into subpackages. >> > [cut] > >> >> Does this help? >> >> http://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_ >> renaming_or_splitting_packages >> >> >> > No, not really. My case is really the one-to-many case, probably to simple > to be mentioned in that doc (?) > > You can use the n to m case, with n = 1. What the doc says is that you create an empty -compat subpackage, that obsoletes your previous package and that requires your new subpackages. After one release cycle you add again your old name and obsolete the -compat package. That's what I understand, at least > That said, thanks for pointer! > > > Cheers! > > --alec > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- 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: Q: Splitting existing pkg into subpackages?!
Hello 2014-10-30 10:32 GMT+01:00 Alec Leamas : > Hi all! > > > Feeling dumb (again...) I have a package which I now need to split into > subpackages. Also, I want the original package to just be an empty one > pulling in all the new subpackages, giving a smooth upgrade path > (installing the base package installs everything, as it used to be). > > My problems are the deps. Is there a way to add a Requires: *only* to the > base package? This is really what I want to do, but adding it among the > others will let also the sub-packages inherit it which becomes a mess. Or > am I just thinking in the wrong direction? > > This must be done so many times... anyone, out there? > Does this help? http://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages > > Cheers! > > --alec > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Unretire xpa
I would like to unretire xpa. It's a package I orphaned in 2011 due to lack of use. This is the re-review https://bugzilla.redhat.com/show_bug.cgi?id=1157794 -- 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: LLVM 3.5 rebase
2014-10-21 12:32 GMT+02:00 Kalev Lember : > On 10/21/2014 10:37 AM, Sergio Pascual wrote: > > Just a question. If I retire the package in F21, will it affect the F20 > > F21 upgrade path for those > > who have python-llvmpy installed? > > > > I mean, you upgrade, there is a new llvm 3.5, but you have python-llvpmy > > that requires llvm 3.4 > > and... fedup will probably ignore python-llvpmy and will go ahead, but > > those that use yum will need to > > uninstall python-llvmpy by hand. Is this correct? > > The usual fix for this is to have something remove the retired package > on upgrades. llvm should be a good candidate for doing the removal since > all python-llvmpy installations already have llvm installed. > > Something like this in llvm spec file: > > Obsoletes: python-llvmpy < 0.12.7-2 > Obsoletes: python3-llvmpy < 0.12.7-2 > > I have retired python-llvmpy in Rawhide and F21. Now if the owner of llvm does the "Obsoletes trick " then the rebase can go ahead, is it right? > -- > Hope this helps, > 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 > -- 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: LLVM 3.5 rebase
2014-10-20 16:19 GMT+02:00 Adam Jackson : > On Fri, 2014-10-17 at 19:16 +0200, Sergio Pascual wrote: > > 2014-10-17 16:00 GMT+02:00 Peter Robinson : > > > So I'm OK with retiring python-llvmpy if a patch doesn't appear soon. > > I would be too, but I'm going to want 3.5 in F21, and we have this whole > thing about not retiring packages in a live release. > > So I will retire the package before the window for F21 closes. Just a question. If I retire the package in F21, will it affect the F20 F21 upgrade path for those who have python-llvmpy installed? I mean, you upgrade, there is a new llvm 3.5, but you have python-llvpmy that requires llvm 3.4 and... fedup will probably ignore python-llvpmy and will go ahead, but those that use yum will need to uninstall python-llvmpy by hand. Is this correct? -- 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: LLVM 3.5 rebase
2014-10-17 16:00 GMT+02:00 Peter Robinson : > On Fri, Oct 17, 2014 at 2:56 PM, Adam Jackson wrote: > > Yep, this again. I'm just as thrilled as you are. 3.5 is necessary for > > proper ppc64le support, as well as some minor radeonsi features in Mesa. > > And massively improved aarch64 support > > > One problem this time around appears to be python-llvmpy, which appears > > to have decided that llvm 3.2/3.3 are the only versions it will support: > > > > > https://github.com/llvmpy/llvmpy/commit/1e141931b874dd0bc3d8e9d801b949939430ad4e > > > > We're already shipping it built against 3.4, so that's truly charming. > > I'm open to suggestions here. > > It doesn't look, with a basic repoquery test, that anything in the > core distro needs python-llvmpy so my general feeling is to query > upstream to see what their intentions are regarding support of newer > releases and if they don't intend to keep up then just drop > python-llvmpy at least for the time being unless the Fedora maintainer > plans to fix it RSN. > I initially had intentions to package numba, and other pyhton goodies that depend on python-llvmpy, but I haven't worked on it on a very long time. So I'm OK with retiring python-llvmpy if a patch doesn't appear soon. in the tracking bug for 3.5 https://github.com/llvmpy/llvmpy/issues/106 Sergio -- 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: Unable to connect to https://admin.fedoraproject.org with firefox, error is ssl_error_no_cypher_overlap
Hi 2014-10-13 17:12 GMT+02:00 Kevin Fenzi : > On Mon, 13 Oct 2014 16:49:38 +0200 > Sergio Pascual wrote: > > > Hello, since a week or so I have been unable to connect to > > https://admin.fedoraproject.org with firefox, I get an error like (I'm > > translating from Spanish) > > "Secure connection failed, no common cipher algorithms > > (ssl_error_no_cypher_overlap)" > > What version of firefox is this? > This is firefox-32.0.2-1.fc20.x86_64 I have created a new empty firefox profile and it works, so it must something in my profile configuration. > > We have been tweaking our ssl settings recently to match up with the > recommended Mozilla ssl server settings: > https://wiki.mozilla.org/Security/Server_Side_TLS > > > I haven't changed any security configuration in firefox, so I assume > > this is a change in admin server or in firefox. I can connect with > > epiphany to https://admin.fedoraproject.org > > > > https://koji.fedoraproject.org doesn't seem affected ( I can connect > > with firefox) > > Can you file a ticket on this in the infrastructure trac and we can try > and see whats happening in your case? > > https://fedorahosted.org/fedora-infrastructure/newticket > I can't login into this one either :( Well, I will do it with epiphany https://fedorahosted.org/fedora-infrastructure/ticket/4567 Thank you > > Thanks, > > kevin > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Unable to connect to https://admin.fedoraproject.org with firefox, error is ssl_error_no_cypher_overlap
Hello, since a week or so I have been unable to connect to https://admin.fedoraproject.org with firefox, I get an error like (I'm translating from Spanish) "Secure connection failed, no common cipher algorithms (ssl_error_no_cypher_overlap)" I haven't changed any security configuration in firefox, so I assume this is a change in admin server or in firefox. I can connect with epiphany to https://admin.fedoraproject.org https://koji.fedoraproject.org doesn't seem affected ( I can connect with firefox) Regards, Sergio -- 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: btrfs as default filesystem for F22?
2014-10-07 1:29 GMT+02:00 Matěj Cepl : > I mean what is shown on > http://www.youtube.com/watch?v=-pNh1n3seTg (I don't even know > what language it is), and > http://www.youtube.com/watch?v=kdjulcvhhuU (which is Spanish, > I guess). > Both are Spanish -- 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: Review swap: python-gmpy2
2014-09-10 23:36 GMT+02:00 Jerry James : > Is anyone up for a review swap? I need python-gmpy2, which is a > successor to the existing gmpy package. > > https://bugzilla.redhat.com/show_bug.cgi?id=1138892 > > Let me know what I can review for you in return. > Could you review python-dill? https://bugzilla.redhat.com/show_bug.cgi?id=1140577 Thank you -- 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: Review swap: python-gmpy2
2014-09-10 23:36 GMT+02:00 Jerry James : > Is anyone up for a review swap? I need python-gmpy2, which is a > successor to the existing gmpy package. > > https://bugzilla.redhat.com/show_bug.cgi?id=1138892 > > I will take it. It was in my packaging queue anyway > Let me know what I can review for you in return. > -- > 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 -- 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: Unresponsive maintainer Germán Racca (skytux)
2014-09-10 20:57 GMT+02:00 Kevin Fenzi : > I have orphaned skytux'es packages: > > APLpy -- The Astronomical Plotting Library in Python ( master f21 f20 f19 ) > Taken, thank you -- 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: Unresponsive maintainer Germán Racca (skytux)
Mid July? 2014-09-08 12:17 GMT+02:00 Itamar Reis Peixoto : > how long you requested commit access in pkgdb ? > > https://admin.fedoraproject.org/pkgdb/package/APLpy/ > > > On Mon, Sep 8, 2014 at 7:13 AM, Sergio Pascual > wrote: > >> Hello, the past week I requested to take the package APLpy, following the >> nonresponsive maintainer policy. Apart of writing to the devel list, is >> there anything more I have to do to move this forward? >> >> 2014-09-01 23:47 GMT+02:00 Sergio Pascual : >> >>> The last week I asked if somebody knows how to contact Germán Racca. >>> Given that all attempts to contact him have been unsuccessfull and as I >>> would like to fix bug #1116895 I request to take over package APLpy >>> >>> Regards, Sergio >>> >>> >>> [1] >>> https://lists.fedoraproject.org/pipermail/devel/2014-August/201825.html >>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1116895 >>> >> >> >> Sergio >> > > > > >> -- >> > > > Itamar Reis Peixoto > > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- 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: Unresponsive maintainer Germán Racca (skytux)
Hello, the past week I requested to take the package APLpy, following the nonresponsive maintainer policy. Apart of writing to the devel list, is there anything more I have to do to move this forward? 2014-09-01 23:47 GMT+02:00 Sergio Pascual : > The last week I asked if somebody knows how to contact Germán Racca. Given > that all attempts to contact him have been unsuccessfull and as I would > like to fix bug #1116895 I request to take over package APLpy > > Regards, Sergio > > > [1] > https://lists.fedoraproject.org/pipermail/devel/2014-August/201825.html > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1116895 > Sergio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Unresponsive maintainer Germán Racca (skytux)
The last week I asked if somebody knows how to contact Germán Racca. Given that all attempts to contact him have been unsuccessfull and as I would like to fix bug #1116895 I request to take over package APLpy Regards, Sergio [1] https://lists.fedoraproject.org/pipermail/devel/2014-August/201825.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=1116895 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Unresponsive maintainer: skytux
Hello, I would like to ask if somebody knows how to contact Germán Racca, fas skytux. My last communication with him was in May, we talked about updating APLpy to use astropy instead of pywcs. Since then, he hasn't answered me. This is the request to update APLpy https://bugzilla.redhat.com/show_bug.cgi?id=1116895 -- 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: Review Swap
Hi Erik, I have these two python packages I would like to get reviewd. I will take yours https://bugzilla.redhat.com/show_bug.cgi?id=1109751 https://bugzilla.redhat.com/show_bug.cgi?id=1117906 2014-07-24 5:08 GMT+01:00 Erik Johnson : > I have a couple new python packages I'd like to get reviewed, does > anyone have something they need reviewed? > > https://bugzilla.redhat.com/show_bug.cgi?id=1113310 > https://bugzilla.redhat.com/show_bug.cgi?id=1113328 > > Note: The above submissions have undergone a few changes, so view the > latest post in each for updated links to the spec and SRPM. > > -- > > Erik Johnson | Engineer > > 2825 E. Cottonwood Parkway, Suite 360 | Salt Lake City, UT 84121 > e...@saltstack.com | http://saltstack.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 > -- 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: [ACTION REQUIRED] Retiring packages for Fedora 21 v3
Hello 2014-07-21 10:59 GMT+02:00 Christopher Meng : > I just want to ask here, why did you retire the pywcs and considered > it as dead upstream whereas pypi pywcs has a new release in the > February? > The functionallity of pywcs is now in astropy, is where active development is happening. The API is the same. Sometimes the developers backport the code to pywcs, but is a dead end. > And now APLpy is broken. > I contacted the maintainer before the change and he agreed to update to APLpy 0.9.11 that uses astropy instead of pywcs. He hasn't updated yet. https://bugzilla.redhat.com/show_bug.cgi?id=1116895 In this report there is a new specfile for APLpy 0.9.11. I would have updated myself but I'm not a proven packager. Regards > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- 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: Very slow trackpad after install latest F20 updates
Yes, it fixes my issue, thank you 2014-06-28 2:06 GMT+02:00 Andrew Price : > On 27/06/14 23:58, Sergio Pascual wrote: > >> Hello, I have updated two laptops runing F20 today. After the update, on >> both of them (Asus and Dell) the trackpad has turned very slow, and >> unaffected of any change in the gnome control panel. >> > > Try this update: > > https://admin.fedoraproject.org/updates/FEDORA-2014-7810/ > xorg-x11-server-1.14.4-11.fc20 > > Andy > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Very slow trackpad after install latest F20 updates
Hello, I have updated two laptops runing F20 today. After the update, on both of them (Asus and Dell) the trackpad has turned very slow, and unaffected of any change in the gnome control panel. I'm not sure which update is responsible. Perhaps xorg-x11-server-*-1.14.4-10.fc20.x86_64? Has anybody seen something similar with late updates? Sergio -- 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: dnf even allows to uninstall RPM and systemd without warnings
2014-06-24 14:25 GMT+02:00 Nils Philippsen : > On Tue, 2014-06-24 at 11:45 +0200, Thomas Bendler wrote: > > 2014-06-24 11:36 GMT+02:00 Richard Hughes : > > On 24 June 2014 10:31, Thomas Bendler > > wrote: > > > you need to unlock the gun before you can shoot in your > > foot... > > > ...and modern systems ask you up to four, five times > > > > How many different locks does a gun have? Last time I checked > > there > > was one safety catch -- DNF asks you for 'y/N' confirmation > > with a > > > > > > Three safety locks the last time I used it. After inserting the > > magazine I had to load the bullet first, then I had to unlock the gun > > and then I had to pull the trigger. I don't think that this procedure > > happens accidentally. > > Two of which aren't safety features, but just part of the mechanism how > a gun can be fired. Because everyone loves car analogies: The safety > mechanism that keeps your car from moving isn't the tank which can be > empty or the ignition which can be switched off, or the accelerator > which you can decide not to push down, but the brakes. Mind that I'm not > arguing against an additional safety if it can be switched off, but I > wouldn't miss it either. > > We are not taking about the security needed to move the car, we are taking about the additional security needed to remove the engine. 99% of the time you don't want to remove the engine, even if you have the keys of the car. Seriously, yum already implements this and it's better to have this additional protection than don't have it. Sergio > Nils > -- > Nils Philippsen "Those who would give up Essential Liberty to purchase > Red Hat a little Temporary Safety, deserve neither Liberty > n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 > PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Retire pywcs
Hello, I have retired pywcs in Rawhide. It FTBS in the last mass build, and upstream recomends to switch to astropy anyway. Sergio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaning cmpfit
Hello, I'm not using cmpfit anymore, so I'm orphaning it. The package has one comaintainer. Thanks, Sergio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
swarp license change
swarp (astronomical imaging resampling and coadding) has change its license from CeCILL to GPLv3+ in upstream version 2.38.0 Regards, Sergio Pascual -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
sextractor license change
sextractor (source extraction from astronomical images) has change its license from CeCiLL to GPLv3+ in upstream version 2.19.5 Regards -- 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: Heads up: Mesa/LLVM rebase and OpenGTL retirement in F20
Hi 2014-03-27 21:02 GMT+01:00 Adam Jackson : > We'd like to update to Mesa 10.1 in Fedora 20, since the cycle is so > long before F21 and (among other goodies) it enables OpenGL 3.3 on some > newer Radeons. This implies rebasing LLVM 3.4, and that's where it gets > a little awkward: the OpenGTL package only works up to LLVM 3.3. > > The following source packages will also be updated for the llvm rebase: > > dragonegg > gambas3 > pocl > pure > python-llvmpy > I have patched python-llvmpy to work with llvm 3.4, so it should be a problem. The patched package (0.12.4-19 has been built in Rawhide but not in F20, to avoid re building the same thing twice. Regards, Sergio -- 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: Problems running mock with rawhide build root
Thank you for pointing me the bug report
2014-02-04 Panu Matilainen :
> On 02/04/2014 02:44 PM, Sergio Pascual wrote:
>
>> Hi, I'm having problems running mock with a rawhide buildroot.
>>
>> I get the following error
>>
>> ERROR: Command failed. See logs for output.
>> # /usr/bin/repoquery -c /tmp/tmpQ6Wu7m --installed -a --qf '%{nevra}
>> %{buildtime} %{size} %{pkgid} %{yumdb_info.from_repo}' >
>> /var/lib/mock/fedora-rawhide-x86_64/result/installed_pkgs
>>
>> And in the root.log file
>>
>> DEBUG util.py:281: error: cannot open Packages index using db5 -
>> Permission denied (13)
>> DEBUG util.py:281: error: cannot open Packages database in
>> /var/lib/mock/fedora-rawhide-x86_64/root/var/lib/rpm
>> DEBUG util.py:281: error: cannot open Packages database in
>> /var/lib/mock/fedora-rawhide-x86_64/root/var/lib/rpm
>>
>> Which seems highly suspicious. Is something related with RPM broken in
>> rawhide?
>>
>
> Not that I know of, nor am I able to reproduce that.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=982043 has similar symptoms
> as well, but as to what is causing it... Could be some exotic setup, also I
> wouldn't count out SELinux being related one way or another.
>
> - Panu -
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Problems running mock with rawhide build root
Hi, I'm having problems running mock with a rawhide buildroot.
I get the following error
ERROR: Command failed. See logs for output.
# /usr/bin/repoquery -c /tmp/tmpQ6Wu7m --installed -a --qf '%{nevra}
%{buildtime} %{size} %{pkgid} %{yumdb_info.from_repo}' >
/var/lib/mock/fedora-rawhide-x86_64/result/installed_pkgs
And in the root.log file
DEBUG util.py:281: error: cannot open Packages index using db5 -
Permission denied (13)
DEBUG util.py:281: error: cannot open Packages database in
/var/lib/mock/fedora-rawhide-x86_64/root/var/lib/rpm
DEBUG util.py:281: error: cannot open Packages database in
/var/lib/mock/fedora-rawhide-x86_64/root/var/lib/rpm
Which seems highly suspicious. Is something related with RPM broken in
rawhide?
Regards, Sergio
--
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: Drawing lessons from fatal SELinux bug #1054350
2014/1/24 Ralf Corsepius > > Certainly, downgrading installations which already upgraded to faulty > packages would not work. > > Ralf > The situation (a broken system that cannot be upgraded) could be mitigated a little bit by using yum + system snapshots. You can rollback to a previous sane system. There is a plugin yum-plugin-fs-snapshot, but it requires better documentation and system integration. Currently (I don't know how current is F16 documentation) it requires running lvm by hand http://docs.fedoraproject.org/en-US/Fedora/16/html/System_Administrators_Guide/sec-Plugin_Descriptions.html Sergio > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Review swap: python-patsy
Hi, I have this review https://bugzilla.redhat.com/show_bug.cgi?id=1051254 Its python-patsy, to use R like formula language in Python I will review other package in return. Thanks, Sergio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Cfitsio soname bump
Hello, I'm going to build new cfitsio 3.360 in Rawhide. This involves a soname bump. You can see the changes here http://heasarc.gsfc.nasa.gov/FTP/software/fitsio/c/docs/changes.txt and more detailed information about the changes here: http://upstream-tracker.org/versions/cfitsio.html The affected packages must be rebuilt CCfits cpl dmapd gdal healpix indi-apogee kst kstars libindi nightview nip2 perl-Astro-FITS-CFITSIO pyfits root siril skyviewer ufraw vips wcslib Regards, Sergio -- 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: Updating hdf5 to 1.8.12
Orion, is it possible that you missed h5py? We are getting this 1. Warning! ***HDF5 library version mismatched error*** 2. The HDF5 header files used to compile this application do not match 3. the version used by the HDF5 library to which this application is linked. 4. Data corruption or segmentation faults may occur if the application continues. 5. This can happen when an application was compiled by one version of HDF5 but 6. linked with a different version of static or shared HDF5 library. 7. You should recompile the application or check your shared library related 8. settings such as 'LD_LIBRARY_PATH'. 9. You can, at your own risk, disable this warning by setting the environment 10. variable 'HDF5_DISABLE_VERSION_CHECK' to a value of '1'. 11. Setting it to 2 or higher will suppress the warning messages totally. 12. Headers are 1.8.11, library is 1.8.12 when building astropy in its review (details here https://bugzilla.redhat.com/show_bug.cgi?id=1014738#c28 ) and I think that is happens because h5py was not rebuilt. Regards, Sergio 2013/12/27 Orion Poplawski > I will be updating hdf5 to 1.8.12 shortly in rawhide and rebuilding > dependent packages: > > Field3D-1.3.2-14.fc21.src.rpm > R-hdf5-1.6.9-22.fc20.src.rpm > ViTables-2.1-7.fc21.src.rpm > cgnslib-3.2-3.fc20.src.rpm > gdl-0.9.4-1.fc21.src.rpm > hdf5-1.8.11-6.fc21.src.rpm > jhdf5-2.9-3.fc20.src.rpm > matio-1.5.1-4.fc21.src.rpm > netcdf-4.3.0-7.fc21.src.rpm > octave-3.6.4-9.fc21.src.rpm > paraview-4.0.1-3.fc21.src.rpm > scilab-5.5.0-0.2.beta1.fc21.1.src.rpm > vtk-6.0.0-9.fc21.src.rpm > > -- > 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 -- 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: Review swap: python-astropy
Taken 2013/12/18 Christopher Meng > Swap with https://bugzilla.redhat.com/show_bug.cgi?id=1033433 if you like. > > I need to handle these remaining bugs now. > > Thanks. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Review swap: python-astropy
Hello, I have this review https://bugzilla.redhat.com/show_bug.cgi?id=1014738 and I'll be happy to review other package in return Thanks, Sergio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
FYI: Soname bump in erfa
Hello, erfa soname has been updated to liberfa.so.1. As nothing (yet) depends on erfa the change should be painless. Regards, Sergio -- 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: Draft Product Description for Fedora Workstation
2013/11/7 Olav Vitters > On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote: > > Olav Vitters wrote: > > > AFAIK (not sure), it should come somewhat easy once you the > distribution > > > is based upon systemd. > > > > That means it will exclude the most popular distribution out there. > > I fail to see the point of discussing non-Fedora distributions on Fedora > devel mailing list. I fail to see the point of discussing a feature that is meant to allow upstreams to provide installable bundles that work in all linuxes if it is only to work in Fedora. -- 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: Draft Product Description for Fedora Workstation
2013/11/6 Olav Vitters > If one will immediately solve it for multiple distributions, then the > gain is immensely higher. An IMO, it is not about RPM vs another > packaging format. To get into Fedora, you need an account, reviews, etc. > It is a pretty long process. > Has this "sanboxed-bundled-from-upstream" proposal been discussed with other distributions? If the final result is that the "Universal Linux Package" only works in Fedora we are not gaining anything. -- 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: prelink performance gains
2013/10/17 Josh Boyer > On Thu, Oct 17, 2013 at 7:22 AM, Paul Wouters wrote: > > On Thu, 17 Oct 2013, Jan Kratochvil wrote: > >> I agree there remains some work on prelink itself and some packages > around > >> to > >> make prelink relevant again > > > > > > I don't mean to pick a fight with you Jan, but you are the only person > > actively defending prelink right now. When even you reach the above > > conclusions and cannot put in the time, and the maintainer isn't looking > > at filed bugs for over a year, the only real answer is to turn prelink > > into a dead.package for now. > > There's no reason to kill the package entirely. Some people still > want to use it despite the current issues. So just don't install it > by default. Reducing everything down to absolutes isn't helpful. And if we get this fixed https://bugzilla.redhat.com/show_bug.cgi?id=841434 those who are using prelink can remove it and end up with a sane system -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Clang error: unknown target CPU 'pentium-m'
Hi, I need help with an error of clang in mock. I have this package review: https://bugzilla.redhat.com/show_bug.cgi?id=1012169 That builds OK in mock in a x86_64 machine. A scratch build in koji fails for x86_64 (and probably others) http://koji.fedoraproject.org/koji/taskinfo?taskID=5992058 with the following error ( http://kojipkgs.fedoraproject.org//work/tasks/2060/5992060/build.log) error: unknown target CPU 'pentium-m' ERROR:root:Command '['clang', '-O3', '-march=native', '-c', 'mathcode.c', '-S', '-emit-llvm', '-o', '/builddir/build/BUILD/llvmmath-0.1.1/llvmmath/mathcode/mathcode.s', '-I/usr/lib64/python2.7/site-packages/numpy/core/include', '-I/usr/include/python2.7', '-I/builddir/build/BUILD/llvmmath-0.1.1/llvmmath/mathcode/private']' returned non-zero exit status 1 Traceback (most recent call last): File "setup.py", line 103, in llvmmath.build.build_targets(config) File "/builddir/build/BUILD/llvmmath-0.1.1/llvmmath/build.py", line 97, in build_targets build_target(config) File "/builddir/build/BUILD/llvmmath-0.1.1/llvmmath/build.py", line 46, in build_llvm cwd=mathcode) File "/usr/lib64/python2.7/subprocess.py", line 542, in check_call raise CalledProcessError(retcode, cmd) I imaging that -march=native is returning the arch of the builder, that is not supported. How can I make this work? Regards, Sergio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Retiring chktex
I have retired chktex, its functionality is provided by texlive-chktex from Fedora 18 and later. texlive-chktex both provides and obsoletes chktex Regards -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads up, new cfitsio 3.350 in rawhide
Hello, a new cfitsio (3.350) is going to land tomorrow in rawhide. This version comes with a significant change, upstream provides a soname for the shared library. This means that hopefully updating cfitsio won't be so painful in the future. Regards, Sergio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
milia soname bump
Hi, milia-1.0.0 has been released and involves a soname bump. I will build it tomorrow for Rawhide and F19. The only package affected is pymila (python wrappers) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New cfitsio 3.330 in Rawhide and F19 (take 2)
I have written cfitsio upstream, requesting that they include a soname in
the library.
Regarding our current discussion, the only requirement is that the soname
is unique
for each release. This comes for the infamous function call that checks the
library version at runtime. In this sense,
libcfitsio-3.340.so.0 and libcfitsio.so.3.340 are equally valid.
In /usr/lib there are lots of libraries with different versioning schemes.
Some include the package version, some not. We have even a library that
includes fc18 in the soname,
$ objdump -p /usr/lib64/libopcodes-2.23.51.0.1-6.fc18.so|grep SONAME
SONAME libopcodes-2.23.51.0.1-6.fc18.so
I feel reluctant to rebuild the package and all dependant packages now just
to remove the .0, that is harmless. I will remove it in the next release.
Hopefully the soname will be provided by upstream then.
Regards
2013/3/25 Michael Schwendt
> On Mon, 25 Mar 2013 01:44:49 +0100, Kevin Kofler wrote:
>
> > Michael Schwendt wrote:
> > > "Standard" versioning is not beneficial here at all. As explained
> before,
> > > here the full version is part of the SONAME. Not just the major
> version.
> > > libcfitsio.so.3.330 would be incompatible with libcfitsio.so.3.340 as
> > > mentioned in a later post by Sergio (on 2013-03-22) already. There is
> > > no common libcfitsio.so.3 that would be downward compatible.
> >
> > But there's no rule that says that the soname has to be libcfitsio.so.3
> > (well, there is if the package builds using libtool, but e.g. CMake
> allows
> > any arbitrary soname, and it also correctly handles the case where the
> > soname is the same as the fully-versioned name). In cfitsio's case, the
> > makefile commands writing the library are handwritten (i.e. don't use
> > libtool) and thus also allow an arbitrary soname; in fact, the soname WAS
> > libcfitsio.so.3.330 before you incorrectly told him to change it
>
> Why is that incorrect?
>
> > (based on
> > the wrong assumption that he would be setting the soname to just
> > libcfitsio.so.3, which would of course be wrong).
>
> Huh? Who has made that assumption? The previous soname was libcfitsio.so.0,
> which has been a bad choice for an API/ABI that changes so frequently.
>
> > Just set the soname and the fully-versioned name both to
> > "libcfitsio.so.%{version}".
>
> That is misleading. IMHO.
>
> > >> The version goes after .so, not before it, unless you want to have it
> > >> also in the symlink, which you explicitly DON'T want here.
> > >
> > > Why not? It would even have been okay to name the run-time lib
> > > libcfitsio-3.330.so with the implicit opportunity to use the same file
> > > as the build-time lib. That would even make it possible to ship
> multiple
> > > releases of cfitsio, since with a non-versioning build-time lib,
> multiple
> > > -devel packages would conflict in their .so symlink (if that one is
> used).
> >
> > But then ALL packages using cfitsio have to be patched to use the
> versioned
> > name. It just doesn't make sense.
>
> That isn't done, however, so currently no patching is necessary.
>
> > >> I know that going back and forth sucks (as everything will have to be
> > >> rebuilt AGAIN), but I think you should really should change this back
> > >> (and you should never have changed it from .so.3.330 to -3.330.so.0 in
> > >> the first place).
> > >
> > > Either naming version would require rebuilds of dependencies for
> version
> > > changes. So, why bother?
> >
> > Because libcfitsio.so → libcfitsio.so.3.330 is just the cleaner scheme
> > compared to libcfitsio.so → libcfitsio-3.330.so.0. Your scheme has 2
> > versions, one of which is always 0, and the devel symlink does not follow
> > the pattern of pointing from foo.so to foo.so.* with the same name foo.
>
> "Cleaner"? That's all? Then this is a superfluous discussion. It doesn't
> make sense to go in circles. What you consider cleaner is just a version
> that pretends that a clean versioning scheme is implemented. The added .0
> does no harm. It would make it possible to change the ABI without bumping
> the library version.
>
> --
> Fedora release 19 (Schrödinger’s Cat) - Linux
> 3.9.0-0.rc3.git1.4.fc19.x86_64
> loadavg: 0.08 0.08 0.07
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
New cfitsio 3.340 in Rawhide and F19
Hello, upstream cfitsio has released 3.340 the very same day that we updated cfitsio in rawhide to 3.330. There's at least an API change listed in the changelog (a global variable has moved inside a data structure) so I can't just backport the bugfixes. So sorry for the inconvience, but we have to rebuild again everything depending con cfitsio. Let's hope there aren't more releases before F19 is released. Regards, Sergio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Planning to retire hpic
Hello, I'm going to retire hpic (Healpix pixelization of the sphere). The package is not developed anymore. Anyone interested in this subject should use healpix (available in Fedora). The package will be retired from Rawhide and F19. Regards, Sergio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New cfitsio 3.330 in Rawhide and F19 (take 2)
Oh great. I didn't thought that a link from libcfitsio-3.330.so.0 to
libcfitsio.so would work.
I have changed it now. The soname is (finally) libcfitsio-3.330.so.0, the
library is libcfitsio-3.330.so.0 and is linked to libcfitsio.so
2013/3/19 Michael Schwendt
> On Tue, 19 Mar 2013 12:03:44 +0100, Sergio Pascual wrote:
>
> > Hello, a new cfitsio (3.330) is going to land tomorrow in rawhide and
> F19 .
> > All the packages depending on cfitsio must be rebuilt.
> >
> > Following this thread,
> >
> > http://lists.fedoraproject.org/pipermail/devel/2013-March/179610.html
> >
> > I have changed the way we create the (non-define by upstream) soname of
> > libcfitsio. The new soname is libcfitsio.so.%{version}
> (libcfitsio.so.3.330
> > in this case). A lot of packages check the existance of libcfitsio.so
> > (instead of using the pkg-config file cfitsio provides), Changing the
> name
> > to libcfitsio-%{version}.so would require to patch those packages also.
>
> Do you refer to build-time? If so, the libcfitsio.so symlink could
> point at anything and would not influence your choices of how to name
> the run-time lib.
>
> --
> Fedora release 19 (…) - Linux 3.9.0-0.rc2.git0.3.fc19.x86_64
> loadavg: 0.22 0.47 0.53
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
New cfitsio 3.330 in Rawhide and F19 (take 2)
Hello, a new cfitsio (3.330) is going to land tomorrow in rawhide and F19 .
All the packages depending on cfitsio must be rebuilt.
Following this thread,
http://lists.fedoraproject.org/pipermail/devel/2013-March/179610.html
I have changed the way we create the (non-define by upstream) soname of
libcfitsio. The new soname is libcfitsio.so.%{version} (libcfitsio.so.3.330
in this case). A lot of packages check the existance of libcfitsio.so
(instead of using the pkg-config file cfitsio provides), Changing the name
to libcfitsio-%{version}.so would require to patch those packages also.
Regards
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New cfitsio (3.330) in rawhide
The versioned soname seems a good idea. I will change the soname to
libcfitsio-%{version}.so.0
2013/3/11 Michael Schwendt
> On Mon, 11 Mar 2013 04:55:06 +0100, Kevin Kofler wrote:
>
> > Sergio Pascual wrote:
> > > cfitsio function fits_open_file checks at runtime if the version of
> > > cfistio used during compile is the same version used at runtime. If
> not,
> > > the program aborts. So every program linked with cfitsio must be
> > > recompiled.
> >
> > That's a totally broken versioning system, the soname needs to be bumped
> > instead.
>
> That soname is added by a patch in the Fedora package. :-/
> Bad idea to begin with, if the library performs such a run-time check.
> A soname such as libcfitsio-%{version}.so.0 would have been a better idea.
> It would enforce rebuilds whenever the version changes, and due to lack
> of symbol versioning, it would also make the automatic soname dependency
> in (re)builds against updates of cfitsio more strict (since they might
> depend on added symbols).
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New cfitsio (3.330) in rawhide
Hi, I did repoquery --repofrompath=this, http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/source/SRPMS--repoid=this --archlist=src --whatrequires cfitsio-devel 2013/3/10 Michael Schwendt > > > Hello, a new cfitsio (3.330) is going to land tomorrow Monday in > rawhide. > > > All the packages depending on cfitsio should be rebuilt. > > > > Why is that? And is it a "should" or a "must"? > > The shared lib 3.330 also only adds two more symbols compared with 3.310. > > Which repoquery has been used to list dependencies? This one finds > a few more: > > # repoquery --whatrequires cfitsio -s|uniq|grep -v cfitsio > CCfits-2.4-6.fc19.src.rpm > HippoDraw-1.21.3-6.fc19.src.rpm > healpix-2.13a-8.fc19.src.rpm > cpl-6.2-1.fc19.src.rpm > dmapd-0.0.50-5.fc19.src.rpm > esorex-3.9.0-4.fc19.src.rpm > gdal-1.9.1-18.fc19.src.rpm > healpix-2.13a-8.fc19.src.rpm > hpic-0.53.1-2.fc19.src.rpm > indi-apogee-1.0-10.fc19.src.rpm > kst-2.0.6-2.fc19.src.rpm > kstars-4.10.1-1.fc19.src.rpm > libindi-0.9.6-2.fc19.src.rpm > nightview-0.3.3-7.fc18.src.rpm > nip2-7.32.0-1.fc19.src.rpm > perl-Astro-FITS-CFITSIO-1.08-4.fc19.src.rpm > root-5.34.05-1.fc19.src.rpm > siril-0.8-13.fc19.src.rpm > skyviewer-1.0.0-8.fc17.src.rpm > ufraw-0.19-1.fc19.src.rpm > vips-7.32.0-1.fc19.src.rpm > wcslib-4.13.4-3.fc19.src.rpm > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New cfitsio (3.330) in rawhide
Hi,
cfitsio function fits_open_file checks at runtime if the version of
cfistio used during compile is the same version used at runtime. If not,
the program aborts. So every program linked with cfitsio must be recompiled.
And you are comparing 3.300 with 3.310. There are more changes between
3.300 and 3.330. More details here
https://bugzilla.redhat.com/show_bug.cgi?id=841363#c2
Best, Sergio
2013/3/10 Michael Schwendt
> On Sun, 10 Mar 2013 23:15:44 +0100, Sergio Pascual wrote:
>
> > Hello, a new cfitsio (3.330) is going to land tomorrow Monday in rawhide.
> > All the packages depending on cfitsio should be rebuilt.
>
> Why is that? And is it a "should" or a "must"?
>
> $ rpmsodiff cfitsio-3.300-2.fc18.x86_64.rpm cfitsio-3.310-3.fc19.x86_64.rpm
> common sonames:
> libcfitsio.so.0 /usr/lib64/libcfitsio.so.0 /usr/lib64/libcfitsio.so.0
>
> --- cfitsio-3.300-2.fc18/libcfitsio.so.02013-03-10
> 23:19:02.447829152 +0100
> +++ cfitsio-3.310-3.fc19/libcfitsio.so.02013-03-10
> 23:19:09.504433421 +0100
> @@ -44,2 +44,3 @@
> GZBUFSIZE D
> +_edata D
> _fini T
> @@ -519,2 +520,3 @@
> ffifileT
> +ffifile2 T
> ffiimg T
>
> 2 symbols added
> D _edata
> T ffifile2
>
> # template for libcfitsio.so.0 version script
> CFITSIO_3.310 {
> global:
> _edata;
> ffifile2;
> };
>
> vim:ft=diff
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
New cfitsio (3.330) in rawhide
Hello, a new cfitsio (3.330) is going to land tomorrow Monday in rawhide. All the packages depending on cfitsio should be rebuilt. Repoquery says that the affected packages are: CCfits-0:2.4-6.fc19.src HippoDraw-0:1.21.3-6.fc19.src cpl-0:6.2-1.fc19.src esorex-0:3.9.0-4.fc19.src gdal-0:1.9.1-18.fc19.src healpix-0:2.13a-8.fc19.src hpic-0:0.53.1-2.fc19.src indi-apogee-0:1.0-10.fc19.src kst-0:2.0.6-2.fc19.src libindi-0:0.9.6-2.fc19.src nightview-0:0.3.3-7.fc18.src perl-Astro-FITS-CFITSIO-0:1.08-4.fc19.src root-0:5.34.05-1.fc19.src siril-0:0.8-13.fc19.src skyviewer-0:1.0.0-8.fc17.src ufraw-0:0.19-1.fc19.src wcslib-0:4.13.4-3.fc19.src Regards, Sergio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
blitz license change
Hello, blitz-0.10 has updated its license terms. It has changed from either LGPLv3+ or BSD to either LGPLv3+ or BSD or Artistic 2.0 It was Artistic 1.0 febore, but as this is not allowed in Fedora, it wasn't mentioned. This new version will arrive at rawhide soon. Regards, Sergio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
blitz-0.1.0, license change
Hello, blitz-0.10 has changed its license from GPLv2 to either LGPLv3+ or BSD. This new version will arrive at rawhide soon. Regards, Sergio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
