cppcheck orphaned
Hi, I have orphaned cppcheck due to lack of time and use on my part. tdawson is an admin, while sgrubb and c72578 have commit rights. Susi -- Susi Lehtola Fedora Project Contributor jussileht...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
pcc orphaned
Hi, I have orphaned the portable C compiler (pcc) package in Fedora due to lack of time and since I don't really use it. The package appears to have stopped working at some point (BZ#2263907) and the upstream server http://pcc.ludd.ltu.se/ appears to have died in March and is still not up. Susi -- Susi Lehtola Fedora Project Contributor jussileht...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Package reviews
Hello, I have three simple Fortran packages for review: mstore https://bugzilla.redhat.com/show_bug.cgi?id=2310390 multicharge https://bugzilla.redhat.com/show_bug.cgi?id=2310391 dftd4 https://bugzilla.redhat.com/show_bug.cgi?id=2310392 which are straightforward meson builds. multicharge depends on mstore, and dftd4 depends on mstore and multicharge. I am willing to trade reviews for these. Susi -- Susi Lehtola Fedora Project Contributor jussileht...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Review assistance needed for python-optking
Hi all, I would like to ask the scientific package community for help in reviewing optking, which is a new dependency of the Psi4 quantum chemistry package. The current release of psi4 in Fedora is version 1.3.2 which dates back to four years(!) ago. Unfortunately, the package's upstream made some big changes to their dependencies, which prevented updating the Fedora package for a long time. Now all of these issues are finally solved, and so I am trying to wrap up several years of efforts in getting the thing back up to date. So, if anyone would be willing to spend a few minutes to review the extremely straightforward python-optking package, this would be much appreciated. https://bugzilla.redhat.com/show_bug.cgi?id=2308329 Best wishes, Susi -- Susi Lehtola Fedora Project Contributor jussileht...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Looking for new maintainers for Epson inkjet printer drivers
Hi, due to increased activity in a number of open source scientific projects, I no longer have as much time for Fedora packages, and need to prune out packages I no longer can effectively maintain. The Epson inkjet drivers are very high on this list, given that I haven't even had an Epson inkjet printer in several years. I am hoping to find new maintainers for the epson-inkjet-printer-escpr and epson-inkjet-printer-escpr2 packages. Susi -- Susi Lehtola Fedora Project Contributor jussileht...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Python packaging with pip
On 8/4/23 22:08, Scott Talbert wrote: > On Fri, 4 Aug 2023, Susi Lehtola wrote: >> Hi, >> >> it's been a while since I did active Python packaging. However, one of my >> packages, python-qcelemental, https://github.com/MolSSI/QCElemental, has >> switched over from setup.py to >> >> $ python -m pip install qcelemental >> >> I did not see anything in the Python packaging guidelines on how to handle >> such >> cases in the spec file. Does anybody have an example I could follow? > > You can't build Fedora packages using pip (no network access allowed), but > it looks like they switched to a pyproject.toml, so following the standard > modern guidelines should work, ie: > > %generate_buildrequires > %pyproject_buildrequires > > %build > %pyproject_wheel > > %install > %pyproject_install Dear Scott, thanks; this did the trick! Susi -- Susi Lehtola Fedora Project Contributor jussileht...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Python packaging with pip
Hi, it's been a while since I did active Python packaging. However, one of my packages, python-qcelemental, https://github.com/MolSSI/QCElemental, has switched over from setup.py to $ python -m pip install qcelemental I did not see anything in the Python packaging guidelines on how to handle such cases in the spec file. Does anybody have an example I could follow? Susi -- Susi Lehtola Fedora Project Contributor jussileht...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired next week
On 1/31/23 14:44, Miro Hrončok wrote: > Dear maintainers. > > Based on the current fail to build from source policy, the following packages > should be retired from Fedora 38 approximately one week before branching. > > 5 weekly reminders are required, hence the retirement will happen > approximately in 1 week, i.e. around 2023-02-08. > Since this is unfortunately after the branching, > packages will be retired on rawhide and f38. > > This is the 4th reminder. I apologize for starting this process a bit later > than required. Hi, it has so far taken two weeks of waiting to get the long-awaited libQGLViewer update in Fedora. Since this is a soname bump, per Fedora policy the update will take another week before it can be built in rawhide; the libQGLViewer maintainer has now announced it on the list. IQmol can be rebuilt in rawhide as soon as libqGLViewer is updated, and retiring it is not necessary. Susi -- Susi Lehtola Fedora Project Contributor jussileht...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Non-responsive maintainer check for rmattes / update libQGLViewer to 2.9.1
On 1/29/23 12:57, Mamoru TASAKA wrote:
> Maybe slightly off-topic, but:
>
> This PR removes qt4 version libQGLViewer, which skyviewer depends on:
>
> $ dnf -q repoquery --repo=koji-38 --qf
> '%{name}-%{epoch}:%{version}-%{release}\t%{sourcerpm}' --whatrequires
> libQGLViewer
> libQGLViewer-devel-0:2.6.4-10.fc38libQGLViewer-2.6.4-10.fc38.src.rpm
> libQGLViewer-doc-0:2.6.4-10.fc38 libQGLViewer-2.6.4-10.fc38.src.rpm
> skyviewer-0:1.0.1-29.fc38 skyviewer-1.0.1-29.fc38.src.rpm
>
> , and qt5 version does soname bump, which octomap depends on:
>
> $ dnf -q repoquery --repo=koji-38 --qf
> '%{name}-%{epoch}:%{version}-%{release}\t%{sourcerpm}' --whatrequires
> libQGLViewer-qt5
> libQGLViewer-qt5-devel-0:2.6.4-10.fc38
> libQGLViewer-2.6.4-10.fc38.src.rpm
> octomap-octovis-0:1.9.7-5.fc38octomap-1.9.7-5.fc38.src.rpm
> $ dnf -q repoquery --repo=koji-38 --qf
> '%{name}-%{epoch}:%{version}-%{release}\t%{sourcerpm}' --requires
> octomap-octovis | grep QGL
> libQGLViewer-qt5.so.2.6.4()(64bit)
>
> This means this PR is going to break all packages which currently depends on
> libQGLViewer
> unless properly handled.
>
> So my question is that what is the exact reason that IQmol
> "need an update of libQGLViewer to a more modern version, since the old
> version of
> libQGLViewer is causing IQmol builds to fail".
> If this means that IQmol needs new API of libQGLViewer, this may mean that
> other packages which libQGLViewer depends on are going to FTBFS, then
> we may have to be more careful for updating libQGLViewer.
IQmol needs some functions that are only in the new API. skyviewer has also
dropped qt4 support in their latest release (from July 2020), so the issue is
that skyviewer hasn't been updated in a few years. The soname bump is hopefully
not an issue with octomap.
>> In addition to these two, I have also tried to reach Rich through
>> libqglviewer-ow...@fedoraproject.org, however, I have not received any
>> replies
>> so far. (Granted, this all happened starting on Wednesday, but February is
>> right
>> around the corner!)
>
> Currently this is -maintain...@fedoraproject.org , not -owner.
> https://fedoraproject.org/wiki/EmailAliases
Thanks!
--
Susi Lehtola
Fedora Project Contributor
jussileht...@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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Non-responsive maintainer check for rmattes / update libQGLViewer to 2.9.1
Hi, does anyone know how to contact Rich Mattes? They maintain libQGLViewer, which was last updated five years ago * Sun Aug 12 2018 Rich Mattes - 2.6.4-1 - Update to release 2.6.4, with upstream fix for qreal on armv7 (rhbz#1556028) - Remove upstream patch and update library names and there has been no other activity in the package other than automated rebuilds. I urgently need an update of libQGLViewer to a more modern version, since the old version of libQGLViewer is causing IQmol builds to fail, and IQmol is at threat of being removed in a week or so from now due to long-time FTBFS issues originally caused by the update of OpenBabel to version 3. https://bugzilla.redhat.com/show_bug.cgi?id=2164341 I have since done the work to update the package to version 2.6.4 myself, and filed a pull request against libQGLViewer to update it to the newest release in https://src.fedoraproject.org/rpms/libQGLViewer/pull-request/1 In addition to these two, I have also tried to reach Rich through libqglviewer-ow...@fedoraproject.org, however, I have not received any replies so far. (Granted, this all happened starting on Wednesday, but February is right around the corner!) I would like to get commit rights to libQGLViewer so I can update the package. I do have provenpackager rights, but this would go over their purview.. The only packages that appear to depend on libQGLViewer, in addition to IQmol, appear to be skyviewer and octomap, whose maintainers have been copied into this messages. Susi -- Susi Lehtola Fedora Project Contributor jussileht...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: List of long term FTBFS packages to be retired in February
On 1/25/23 13:04, Alexander Ploumistos wrote: > On Tue, Jan 24, 2023 at 3:56 PM Miro Hrončok wrote: >> >> IQmoljussilehtola > > I'm leaving this comment in case Susi (Cc) didn't get the previous > mail like last time. I know that they're working with upstream to > package the next version of IQmol, so this should be resolved sooner > or later. Hi, yes, un-addressed mail (bcc) is insufficient to contact package maintainers; thanks for the ping. I am aware of the issue thanks to Bugzilla, and am actively working to find a resolution. The current problem is that libQGLViewer (cc'd) was last updated 5 years ago, and the up-to-date version of IQmol that supports OpenBabel3 needs a more recent version of libQGLViewer. Susi -- Susi Lehtola Fedora Project Contributor jussileht...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
On 12/5/22 13:36, Miro Hrončok wrote: > 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 fail to install and/or build when the affected package gets > retired. Hello, although I was mentioned in the email > Affected (co)maintainers (either directly or via packages' dependencies): > jussilehtola: CheMPS2 I was was not contacted about this and the package has been falsely retired. Please check your scripts to reach out to other maintainers who may have been bitten by the retirements. -- Susi Lehtola Fedora Project Contributor jussileht...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
libxc 6.0.0 update / soversion bump
Hi, I have released libxc 6.0.0 today, and intend to update the package in Fedora as well. As a major release update, the soversion will change; however, the changes in the API should not affect any dependent packages so simple rebuilds will suffice. The list of dependent packages is cp2k-9.1-3.fc37.src.rpm elk-8.3.22-2.fc37.src.rpm gpaw-22.8.0-2.fc38.src.rpm psi4-1.3.2-14.fc37.src.rpm python-pyscf-2.1.1-1.fc38.src.rpm votca-2022-8.fc37.src.rpm I am the maintainer of psi4 and python-pyscf; I can run the rebuilds of the four other packages. I will do the update in a week from now. Susi -- Susi Lehtola Fedora Project Contributor jussileht...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
gsl soversion bump
Hello, gsl will be updated from version 2.6 to 2.7.1 which changes the soversion from .25 to .27 in one week. List of dependent packages $ for rpm in $(repoquery --disablerepo=* --enablerepo=rawhide --whatrequires "libgsl.so.25()(64bit)"); do repoquery --disablerepo=* --enablerepo=rawhide --source $rpm;done|sort|uniq 3Depict-0.0.22-12.fc37.src.rpm algol68g-3.0.3-3.fc37.src.rpm astrometry-0.89-3.fc37.src.rpm asymptote-2.81-2.fc37.src.rpm bcftools-1.13-4.fc37.src.rpm bogofilter-1.2.5-9.fc37.src.rpm calligra-3.2.1-18.fc37.src.rpm cocoalib-0.99800-3.fc37.src.rpm dieharder-3.31.1-32.fc37.src.rpm enblend-4.2-23.fc37.src.rpm espresso-4.2.0-1.fc37.src.rpm freefem++-4.11-2.fc37.src.rpm gambas3-3.17.3-1.fc37.src.rpm gdl-1.0.1-7.fc37.src.rpm getdp-3.5.0-3.fc37.src.rpm giac-1.7.0.29-4.fc37.src.rpm gnuradio-3.10.3.0-4.fc37.src.rpm GoldenCheetah-3.6-0.19.20220713git0d979f9.fc37.src.rpm gsl-2.6-7.fc37.src.rpm igt-gpu-tools-1.26-2.20220508gitcffa5ff.fc37.src.rpm inkscape-1.2.1-2.fc37.src.rpm ipe-7.2.26-2.fc37.src.rpm krita-5.0.8-4.fc37.src.rpm kst-2.0.8-38.fc37.src.rpm kstars-3.5.9-3.fc37.src.rpm LabPlot-2.8.1-6.fc37.src.rpm libindi-1.9.7-1.fc37.src.rpm luminance-hdr-2.6.1.1-47.fc37.src.rpm mathgl-2.4.4-17.fc37.src.rpm milia-1.0.0-34.fc37.src.rpm mmseq-1.0.11-12.fc37.src.rpm moose-3.1.5-14.fc37.src.rpm morse2txt-1.0.0-34.fc37.src.rpm mp-3.1.0-39.20200303git7fd4828.fc37.src.rpm ncl-6.6.2-29.fc37.src.rpm nco-5.1.0-2.fc37.src.rpm nest-3.2-6.fc37.src.rpm nip2-8.7.1-9.fc35.src.rpm ocaml-gsl-1.19.1-42.fc37.src.rpm octave-gsl-2.1.1-7.fc37.src.rpm opengrm-ngram-1.3.14-3.fc37.src.rpm orsa-0.7.0-57.fc37.src.rpm perl-PDL-2.80.0-3.fc37.src.rpm pfstools-2.2.0-5.fc37.src.rpm player-3.1.0-41.fc37.src.rpm pspp-1.6.2-2.fc37.src.rpm pygsl-2.3.0-18.fc37.src.rpm python-cvxopt-1.3.0-3.fc37.src.rpm python-pynn-0.10.0-4.fc37.src.rpm qgis-3.26.1-2.fc37.src.rpm R-gsl-2.1.6-11.fc37.src.rpm root-6.26.06-1.fc37.src.rpm sagemath-9.6-4.fc37.src.rpm scidavis-2.9.0-4.fc37.src.rpm siril-1.0.3-2.fc37.src.rpm sourcextractor++-0.18-2.fc37.src.rpm stellarsolver-2.4-2.fc37.src.rpm step-22.04.3-2.fc37.src.rpm vfrnav-20201231-30.fc37.src.rpm xaos-3.6-17.fc37.src.rpm xsnow-3.5.0-2.fc37.src.rpm -- Susi Lehtola Fedora Project Contributor jussileht...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
GitHub source URLs not working
Hi, I am experiencing problems updating packages employing GitHub source URLs. For instance, $ spectool -g python-pyscf.spec Downloading: https://github.com/pyscf/pyscf/archive/v2.0.1/pyscf-2.0.1.tar.gz Download failed: 404 Client Error: Not Found for url: https://codeload.github.com/pyscf/pyscf/tar.gz/v2.0.1/pyscf-2.0.1 - 0.0 B Elapsed Time: 0:00:00 The URLs used to work. Has anyone else noticed the same problem? -- Susi Lehtola Fedora Project Contributor jussileht...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[SONAME BUMP] libcint 5.0.0 / qcint 5.0.0
Hi, libcint 5.0.0 and qcint 5.0.0 have been released, with a soname bump. I'll be pushing the update in one week to rawhide. The only affected package is python-pyscf, which is also mine, and which I'll be similarly updating to version 2.0.1 that has also been released recently. -- Susi Lehtola Fedora Project Contributor jussileht...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: openbabel-3.1* in Rawhide
On 9/26/21 05:07, Jerry James wrote:
> On Sat, Sep 25, 2021 at 5:10 PM Alexander Ploumistos
> wrote:
>> I built the latest avogadro2 and avogadro2-libs from the srpm in your
>> copr for F34 and I hit some graphical glitches again. On Wayland,
>> Avogadro2 for X11 has a transparent canvas, whereas the other one (I
>> guess Wayland) doesn't, but as soon as I add a fourth atom to the
>> drawing, it crashes:
>>
>> /usr/include/c++/11/bits/stl_vector.h:1045: std::vector<_Tp,
>> _Alloc>::reference std::vector<_Tp,
>> _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp =
>> Eigen::Matrix; _Alloc =
>> std::allocator >; std::vector<_Tp,
>> _Alloc>::reference = Eigen::Matrix&; std::vector<_Tp,
>> _Alloc>::size_type = long unsigned int]: Assertion '__n <
>> this->size()' failed.
>> Aborted (core dumped)
>
> I don't know if this is the same as the inchi-related abort, but that
> one is caused by this code, on lines 178-180 of molecule_smiles.cpp,
> in Molecule::ToInChI():
>
> std::string s = ostream.str();
> s[s.length() - 1] = '\0'; // Abort happens here
> return ( QString( s.c_str() ) );
>
> The abort happens because s is the empty string, so s.length() == 0,
> and assigning to s[-1] just isn't a good idea. I'm pretty sure that
> line isn't needed anyway. Isn't s.c_str() guaranteed to provide a
> null-terminated C string?
In addition to .c_str() providing a null-terminated C string, the above
code is wrong also in another sense: s.length() is the length of the
string EXCLUDING THE TERMINATOR so that code is in fact removing the
last letter of the string which can't be the purpose.
You can easily verify this behavior with
#include
#include
int main ()
{
std::string str1(""), str2("c");
std::cout << "str1.length()= " << str1.length() << ", str2.length()= "
<< str2.length() << std::endl;
return 0;
}
which prints out
$ ./a.out
str1.length()= 0, str2.length()= 1
--
Susi Lehtola
Fedora Project Contributor
jussileht...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Fedora for WSL
On 5/9/21 1:32 AM, Greg Hellings wrote: > I may be hair-brained to do this, but I've put together an installer for > Fedora on WSL. > > It mostly follows the procedures that had been much talked about in a > blog post about running Fedora 33 in the WSL2, but it uses the direct > installer rather than the manual side-loads. It also will install Fedora > 34. Obviously, it's not released into the Windows Store as that requires > more than just some technical bit wrangling. But if you're feeling > adventurous, and you are sometimes relegated to the world of Windows but > want to bring your Fedora along, you can find it here: > https://github.com/greg-hellings/FedoraWSL > <https://github.com/greg-hellings/FedoraWSL> Thanks for doing this! It's great to have a free WSL installer for Fedora. Unfortunately, the installer didn't work for me. Even though I installed the security certificate as a trusted third-party root certificate, Windows did not let me run the installation. Has anyone gotten the installer to work? What were the necessary steps? -- Susi Lehtola Fedora Project Contributor jussileht...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: RPMLint 2.0 released!
On 5/18/21 8:13 AM, Neal Gompa wrote: > On Tue, May 18, 2021 at 8:10 AM Miro Hrončok wrote: >> Awesome! What is the plan for Fedora? Shall we migrate to rpmlint 2 in >> rawhide? I recall Mirek Suchý had some WIP Fedora config. >> > > Yes, please! The new rpmlint is *way* better than what we have now, > and the rpmlint-1.x branch is basically dead now. Nobody is working on > that codebase anymore. > > Someone please do it, pretty please! 🙏 If that's the case, it might not be a bad idea to push the new version in the stable releases, too, no? -- Susi Lehtola Fedora Project Contributor jussileht...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Another problem on the s390x builder
Hi, I've had a koji build running for over 6 hours, and the s390x build still hasn't started. Are the s390x builders offline? -- Susi Lehtola Fedora Project Contributor jussileht...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New segfault with flexiblas/openblaso
On Fri, 4 Sep 2020 10:57:13 +0200 Iñaki Ucar wrote: > Hi, > > Strange... Let me bring this upstream to see whether this is > flexiblas' or openblas' fault. In the meanwhile, exporting > FLEXIBLAS=netlib before the tests makes use of the reference > implementation, so everything should be slower but safer. And if this > starts happening in the wild, we can change to openblas-serial with a > quick update of FlexiBLAS. ... which would lead to a horrendous regression in performance, utterly ruining parallellization. If this happens, there is no alternative but to resort to the contingency plan of the FlexiBLAS as BLAS/LAPACK manager: undo all changes and rebuild all packages so that they work again as intended. -- Susi Lehtola Fedora Project Contributor jussileht...@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
Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Wed, 1 Jul 2020 21:03:09 -0600 Jerry James wrote: > On Wed, Jul 1, 2020 at 12:06 PM Susi Lehtola > wrote: > > On Wed, 1 Jul 2020 10:54:16 -0600 > > Jerry James wrote: > > > openblas-serial: use if the application is multithreaded > > > openblas-threads: use if the application is single-threaded > > > > No, this is exactly the wrong way around. You should use the serial > > library for code that you want to be running in serial (this way you > > can get several instances of the program running efficiently), and > > the pthreads version if you want to run the BLAS/LAPACK regions in > > parallel (but are somehow opposed to OpenMP!).. > > Okay, I think the wiki's wording is hard to understand > (https://github.com/xianyi/OpenBLAS/wiki/faq#multi-threaded), at least > for me. Let me see if I've got this straight. > > 1. openblas-opemp computes on subranges in parallel using OpenMP > 2. openblas-threads computes on subranges in parallel using pthreads > 3. openblas-serial uses a single thread for the entire computation > > Right? Exactly. But the key bit here is that if openblas-openmp is called within a code segment that is already OpenMP parallel, then OpenBLAS does not parallellize further: if you have 8 cores, and the program is running on 8 threads, further parallellism (going to 8*8=64 threads) would just ruin the performance. > What I'm looking for is a set of rules I can apply when I've got a > package that uses BLAS, but upstream has given no guidance on what > kind of BLAS library is suitable. I've got several of those, so I > want to check that they're linking with the best version of the > library. How should I make that determination? Also, how do I know > whether to use, say, openblas-openmp vs. openblas-openmp64 vs. > openblas-openmp64_? openblas-openmp is generally the safe choice. As for the latter question, it depends on whether you compile your code with 4-bit or 8-bit integers. -- Susi Lehtola Fedora Project Contributor jussileht...@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
Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Wed, 1 Jul 2020 20:16:36 +0200 Iñaki Ucar wrote: > > No, this is exactly the wrong way around. You should use the serial > > library for code that you want to be running in serial (this way you > > can get several instances of the program running efficiently), and > > the pthreads version if you want to run the BLAS/LAPACK regions in > > parallel (but are somehow opposed to OpenMP!).. > > I think I'm more confused than before. :D > > > > The question of the default is a hard one. What happens if a > > > multithreaded application that does not use OpenMP is linked with > > > the OpenMP build of OpenBLAS? > > > > Then you get too much parallellism, i.e. every call to OpenBLAS will > > launch several threads, and this will naturally ruin your scaling. > > So would you say that openblas-serial is the most sensible > system-wide default? THERE SHOULD BE NO SYSTEM-WIDE DEFAULT. The thing is that the maintainer needs to be able to pick the correct flavor. If you use the wrong one, you may seriously handicap performance. But, if one *needs* a system-wide default, in my opinion it should be the OpenMP version, since it plays well together with both sequential and OpenMP parallel programs. -- Susi Lehtola Fedora Project Contributor jussileht...@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
Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Wed, 1 Jul 2020 19:28:53 +0200 Iñaki Ucar wrote: > I'm no expert, but the FAQ says: > > "You have a GPLed program that I'd like to link with my code to build > a proprietary program. Does the fact that I link with your program > mean I have to GPL my program? (#LinkingWithGPL) > > Not exactly. It means you must release your program under a license > compatible with the GPL (more precisely, compatible with one or more > GPL versions accepted by all the rest of the code in the combination > that you link). The combination itself is then available under those > GPL versions." > > So my understanding is that it's ok for a program to link to FlexiBLAS > if its license is GPL-compatible, not necessarily GPL. But of course > we would need confirmation from legal. The library is GPLv3 only https://gitlab.mpi-magdeburg.mpg.de/software/flexiblas-release#license which already makes it incompatible with many GNU Licenses https://fedoraproject.org/wiki/Licensing:Main#GPL_Compatibility_Matrix not to mention many other free licenses that are allowed in Fedora https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses -- Susi Lehtola Fedora Project Contributor jussileht...@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
Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal
On Wed, 1 Jul 2020 10:54:16 -0600 Jerry James wrote: > On Wed, Jul 1, 2020 at 10:26 AM Iñaki Ucar > wrote: > > BTW, I would also like to discuss here, as part of this proposal, > > which backend should be the system-wide default. I believe we all > > would agree that OpenBLAS nowadays is the best choice. But then, the > > serial or the openmp version? > > First, I want to make sure I understand the current openblas > packaging. Is this correct? > > openblas-openmp: use if the application uses OpenMP Yes; then OpenBLAS calls get run in parallel in single-threaded regions of the code, and if sequential mode in regions that are already running parallel. > openblas-serial: use if the application is multithreaded > openblas-threads: use if the application is single-threaded No, this is exactly the wrong way around. You should use the serial library for code that you want to be running in serial (this way you can get several instances of the program running efficiently), and the pthreads version if you want to run the BLAS/LAPACK regions in parallel (but are somehow opposed to OpenMP!).. > The question of the default is a hard one. What happens if a > multithreaded application that does not use OpenMP is linked with the > OpenMP build of OpenBLAS? Then you get too much parallellism, i.e. every call to OpenBLAS will launch several threads, and this will naturally ruin your scaling. -- Susi Lehtola Fedora Project Contributor jussileht...@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
Re: Single-threaded OpenBLAS is not thread-safe
On Wed, 27 May 2020 12:29:36 +0200 Iñaki Ucar wrote: > Hi, > > I wanted to bring some attention to this in devel, not only to > openblas' maintainer (in CC), because there have been some discussions > around BLAS/LAPACK in the past here. > > As Dave Love pointed out in a previous discussion, generally, > parallelization is made at the top level and then you simply call a > single-threaded BLAS/LAPACK implementation. But as it turns out, > openblas is not thread-safe in such a scenario since v0.3.7 at least. > To ensure thread-safety, we need to build single-threaded openblas > with USE_LOCKING=1 [1] (which we don't do now, and we should, > especially if we intend to make this implementation a system-wide > default [2]). The correct case is to use the OpenMP flavor of OpenBLAS to avoid these issues. If you use the OpenMP library in a sequential program, the BLAS runs in parallel, and if you use the OpenMP library in an OpenMP parallel program the BLAS runs either sequentally (within already-parallel regions) or in parallel (within sequential regions). > So it's clear that things are failing out there, and USE_LOCKING=1 is > a sensible default that we should apply. I didn't find though what's > the performance penalty of setting such a flag. I've toggled USE_LOCKING=1 in openblas-0.3.9-3. > But if that's noticeable, then this is another argument in favour of > providing a proper mechanism for the user to switch the > implementation, as e.g. Debian does. Debian's mechanism for switching the implementations is improper, due to reasons already discussed on this list. -- Susi Lehtola Fedora Project Contributor jussileht...@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
Re: Another libxc soname bump...
On Fri, 15 May 2020 12:15:05 +0300 Susi Lehtola wrote: > Hello, > > > unfortunately there's going to be *another* soname bump to libxc. > Libxc 5 replaced the ancient "Fortran '90" interface with the Fortran > 2003 version based on iso_c_binding. However, this included > *renaming* the Fortran 2003 module and functions, which is obviously > inconvenient for downstream projects and has caused a lot of hassle. > > This change is reverted in the upcoming libxc release, resulting in > another soname bump, but a more backwards compatible API... It appears > that the Fortran codes elk and exciting have not yet been compiled > against libxc 5; the next release will be easier to compile against. Nevermind, there's not going to be a soname bump; a copy of the erroneously renamed library will also be shipped in the next release... the main point being that libxcf03 will be there as well and stay there. -- Susi Lehtola Fedora Project Contributor jussileht...@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
Another libxc soname bump...
Hello, unfortunately there's going to be *another* soname bump to libxc. Libxc 5 replaced the ancient "Fortran '90" interface with the Fortran 2003 version based on iso_c_binding. However, this included *renaming* the Fortran 2003 module and functions, which is obviously inconvenient for downstream projects and has caused a lot of hassle. This change is reverted in the upcoming libxc release, resulting in another soname bump, but a more backwards compatible API... It appears that the Fortran codes elk and exciting have not yet been compiled against libxc 5; the next release will be easier to compile against. -- Susi Lehtola Fedora Project Contributor jussileht...@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
qt5-devel dropped?
Hi, I just noticed that qt5-devel has been dropped. Is the idea to force all other packages to change Requires: qt5-devel into Requires: qt5-qtbase Requires: qt5-qtbase-gui Requires: qt5-qtbase-mysql Requires: qt5-qtbase-postgresql Requires: qt5-qtconnectivity Requires: qt5-qtdeclarative Requires: qt5-qtdoc Requires: qt5-qtgraphicaleffects Requires: qt5-qtimageformats Requires: qt5-qtlocation Requires: qt5-qtmultimedia Requires: qt5-qtquickcontrols Requires: qt5-qtquickcontrols2 Requires: qt5-qtscript Requires: qt5-qtsensors Requires: qt5-qtserialport Requires: qt5-qtsvg Requires: qt5-qttools Requires: qt5-qtwayland Requires: qt5-qtwebchannel Requires: qt5-qtwebsockets Requires: qt5-qtx11extras Requires: qt5-qtxmlpatterns -- Susi Lehtola Fedora Project Contributor jussileht...@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
Re: Automatic tools for soname bumps
On 4/22/20 11:54 AM, Miro Hrončok wrote: > On 22. 04. 20 10:25, Susi Lehtola wrote: >> first, I'm sorry for a partial screw-up of the libxc soname bump >> announcement. >> It appears I am not alone: there are a few soname bumps each month, many of >> them >> still unannounced. > > I'd guess the biggest problem is that a lot of packages have soname bumps > hidden > by * globs. I.e. the maintainers update thei package without even realizing > they've bumped. > > This is getting better and better now, as more packages follow the rule not to > do this and use a more strict glob. If the updates system caught changed sonames and triggered a warning / mails to affected package maintainers, this would not be a problem. >> This raises the question: shouldn't there be some sort of automatic tool for >> making soname bump announcements? It seems to me that this is a thing where >> computers easily beat humans: query for dependent packages, and shoot their >> maintainers an email. Maybe something that could go in fedpkg? Whenever >> changed >> sonames are detected, hold the update aside and start ringing the alarm >> bells? > > If somebody does this, note that there are basically 3 steps here: > > 1. > $ repoquery --repo=rawhide --source --whatrequires 'libfoo.so.1.0()(64bit)' > > 2. > https://pagure.io/fedora-misc-package-utilities/blob/master/f/find-package-maintainers > > 3. > Write and send e-mail. Three steps with manual labor instead one. A simple script could do this. > However, do you propose that this would happen automagically when the soname > is > bumped? What if I am already in touch with the dependent package owners? Then they get two emails notifying them about an upcoming soname bump. -- Susi Lehtola Fedora Project Contributor jussileht...@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
Automatic tools for soname bumps
Hello, first, I'm sorry for a partial screw-up of the libxc soname bump announcement. It appears I am not alone: there are a few soname bumps each month, many of them still unannounced. This raises the question: shouldn't there be some sort of automatic tool for making soname bump announcements? It seems to me that this is a thing where computers easily beat humans: query for dependent packages, and shoot their maintainers an email. Maybe something that could go in fedpkg? Whenever changed sonames are detected, hold the update aside and start ringing the alarm bells? -- Susi Lehtola Fedora Project Contributor jussileht...@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
libxc version 5 coming up: soname bump
Hi, libxc 5.0.0 has been released. Due to the addition of several new features, it comes with an soname bump. Also, the Fortran libraries have changed from the earlier release: now, the old F03 wrapper employing iso_c_binding is now shipped as the F90 wrapper, as the old F90 wrapper based on a custom C-Fortran interface has been obsoleted. I'll push the package to rawhide in a week from now, i.e. on Mon Apr 13. If you need help porting your package to the new version of libxc, you can ask me for help. (I am also one of the main upstream developers.) -- Susi Lehtola Fedora Project Contributor jussileht...@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
Orphaning java packages, looking for maintainers
Hello, I am orphaning java packages due to lack of time and expertise to maintain them. The packages are quite simple and shouldn't pose big problems to Java experts, as they are also quite established and stable i.e. slow-moving. The current versions in Fedora are from a few years ago, and it might be nice to have them updated to the new versions. The packages are - jmol - jspecview - naga and they are up for grabs. Jmol is a molecular viewer, which I still think is the best one; the two others are jmol's build dependencies. -- Susi Lehtola Fedora Project Contributor jussileht...@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
Re: gsl soname bump
On 8/21/19 4:11 AM, Jerry James wrote: I am happy to see a gsl update, but ... On Tue, Aug 20, 2019 at 1:48 PM Susi Lehtola wrote: Triggering rebuilds of the following affected packages ... python-cvxopt You didn't build this into the python 3.8 side tag, so now it is going to have to be built again. Any other python-using packages on this list are in the same situation. It would have been helpful to have the week to plan that the updates policy requires: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ Please do that next time. Thanks, Apologies, it seems I haven't been following up on changes to the updates policy closely enough. After three consecutive rounds of rebuild attempts, everything should be rebuilt in rawhide now, except for the following packages which appear to fail due to reasons unrelated to gsl, e.g. buildrequires on dead packages and incompatibilities with other libraries in rawhide: astrometry calligra espresso gambas3 giac gipfel gnuradio moose player root sagemath siril -- Susi Lehtola Fedora Project Contributor jussileht...@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
Re: gsl soname bump
On 8/20/19 9:57 PM, Jerry James wrote: On Tue, Aug 20, 2019 at 12:12 PM Susi Lehtola wrote: GSL 2.6 has just been released, and it comes with an soname bump. All dependent packages will need to be rebuilt in rawhide. Are you doing the rebuilds? If so, when? Triggering rebuilds of the following affected packages 3Depict astrometry asymptote bogofilter calligra cocoalib dieharder enblend espresso freefem++ gambas3 gdl getdp giac gipfel gnuradio guvcview igt-gpu-tools inkscape krita kst kstars LabPlot libindi luminance-hdr mathgl milia mmseq moose morse2txt mp ncl nco nest nip2 ocaml-gsl octave-gsl opengrm-ngram orpie orsa perl-PDL pfstools player pspp pygsl python-cvxopt qgis R-gsl root sagemath scidavis siril step vfrnav xaos -- Susi Lehtola Fedora Project Contributor jussileht...@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
gsl soname bump
Hi, GSL 2.6 has just been released, and it comes with an soname bump. All dependent packages will need to be rebuilt in rawhide. -- Susi Lehtola Fedora Project Contributor jussileht...@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
Ancient build notifications
Hello, is anyone else experiencing weird build notifications? I just got one for gsl-1.8-1.1 built by jkeating... on 5 Apr 2007. -- Susi Lehtola Fedora Project Contributor jussileht...@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
Re: How do I remove GLIBCXX_ASSERTIONS?
On 8/1/19 9:28 PM, Steven A. Falco wrote:
The upstream KiCAD project has requested that I remove
GLIBCXX_ASSERTIONS from the Fedora package, as described here:
https://bugs.launchpad.net/kicad/+bug/1838448
What is the best way to do that? I can add "%undefine
_hardened_build" (which I am testing now) but I think that will
remove other hardening features that I might want to leave enabled.
Looks like you're using CMake. This should do the trick
export CFLAGS=$(echo "%{optflags}" |
sed "s|-Wp,-D_GLIBCXX_ASSERTIONS||g")
export CXXFLAGS=$(echo "%{optflags}" |
sed "s|-Wp,-D_GLIBCXX_ASSERTIONS||g")
--
Susi Lehtola
Fedora Project Contributor
jussileht...@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
Re: openmpi dependency problem?
On 11/3/18 5:11 PM, Richard Shaw wrote: I've been working on getting a good build of FreeCAD 0.17 in Fedora (long story) and I was finally able to get a good scratch build on Rawhide so I decided to do a local mock build for Fedora 28 so I could actually test the package... As expected it built fine but I can't install it due to a dependency on libmpi... # dnf install ./freecad-0.17-2.fc28.x86_64.rpm ./freecad-data-0.17-2.fc28.noarch.rpm Judging from your package name you are not aware of the MPI packaging guidelines https://fedoraproject.org/wiki/Packaging:MPI -- Susi Lehtola Fedora Project Contributor jussileht...@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://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
libxc bump to version 4.1.1, license change LGPLv3 -> MPLv2.0
Hi, I'm updating libxc to version 4.1.1 in rawhide. This comes with a soname change, and will require rebuilds of dependent packages, which should go smoothly. The license changes from LGPLv3 to MPLv2.0 in the 4.1 series onward. The library does not forbid secondary licensing, so it is still GPL compatible. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
packmol license change
Hi, I've updated packmol to version 18.013. This carries a license change from GPLv2+ to MIT. No other packages are affected, since packmol is executable only. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
On 02/18/2018 07:09 PM, Igor Gnatenko wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Over this weekend I've performed scratch-mass-rebuild without having gcc and gcc-c++ in buildroot of all Fedora packages, many of which failed due to random reasons and I grepped all logs for some common errors found by analyzing hundreds of build logs. Guidelines: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildRequire s_and_Requies The grep output is located here: https://ignatenkobrain.fedorapeople.org/gcc-removal.txt jussilehtola IQmol OpenMesh PyQuante QMsgBox QsLog agedu cppcheck dd_rescue ddrescue epson-inkjet-printer-escpr epstool ergo gle gsl libint multitail octave packmol pcc potrace I've taken care of all of these. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
heads-up: OpenMesh soname bump
Hi all, this is to let you know that I've upgraded OpenMesh in rawhide from the 4.1 series to the 6.3 series, which is fully backward compatible with 2.x and 5.x according to upstream. The upgrade came with a soname bump, so all dependent packages need to be rebuilt. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Is it possible atlas is linked wrongly by new binutils?
On 08/15/2017 02:47 PM, Kevin Kofler wrote:
Please note that what I am proposing here is not the same as my proposal
from 3 years ago that was rejected. While I would not complain if my old
proposal were implemented, I am now suggesting a much simpler approach
(which was already hinted at in the last paragraph of my old proposal):
* drop the inefficient implementations reference (netlib) BLAS/LAPACK and
ATLAS (have OpenBLAS Obsolete them),
Why?
* use one-way symlinks or linker scripts to make everything linking or
linked to them pick up OpenBLAS instead. So libblas, liblapack and libsatlas
would just redirect to libopenblas,
This could be easier done just by linking to -lopenblas.
* I am not sure about libtatlas, ideally it should redirect to libopenblaso,
but libtatlas uses raw pthread wheres libopenblaso uses OpenMP, this may
make a difference (e.g., it will certainly cause problems if the client
program uses OpenMP itself). If libopenblaso does not work as a drop-in
libtatlas replacement, libopenblas would have to be used instead (and the
programs that really want libopenblaso would have to be rebuilt for it).
Actually, the problem is a bit bigger. The basic OpenBLAS library comes
in three variants:
- sequential (libopenblas)
- pthreads (libopenblasp)
- OpenMP (libopenblaso)
The problem is that you can't mix these. Now, I use a lot of BLAS/LAPACK
and sometimes even within OpenMP parallel regions. The only library I
would use is libopenblaso, because by doing so you get parallel
performance in sequential regions, but it doesn't parallellize when you
call a routine within a parallel region (otherwise you'll launch too
many threads and destroy your performance).
While the OpenMP version has a marginally larger overhead than the
pthreads one, it is the OpenMP version that should be default.
However, in addition to these three main flavors, the library *also*
comes in versions that support 64-bit indexing (the good old 4-byte vs
8-byte Fortran integer problem):
- libopenblas{,p,o} is the 32-bit integer one
- libopenblas{,p,o}64 is the 64-bit integer one - which has the same
symbol names as libopenblas{,p,o} !!
- libopenblas{,p,o}64_ is the 64-bit integer one with a _ suffix so you
can link the same application to the 32-bit version libopenblas{,p,o}
so it's not a simple question of libblas.so and liblapack.so
--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Is it possible atlas is linked wrongly by new binutils?
On 08/14/2017 03:35 AM, Kevin Kofler wrote: That said, ATLAS should really go away, unless they add support for runtime CPU detection and the result matches or exceeds OpenBLAS performance. In its current state (which has been the state since its inception), ATLAS is really unsuitable for distribution packaging. They just do not care about binary packages, at all. This is kind of like saying vim should go away, because emacs is better. It is the job of the distribution to ensure that software uses the most efficient BLAS/LAPACK implementation available. Other distributions ship symlinks ensuring that. The current packaging in Fedora is horrible. "Other distributions" typically end up using reference BLAS/LAPACK due to the horrible symlink/alternatives system, and/or end up with broken implementations. I'm sure a better way to do things would be possible, it's just hard to imagine a perfect system. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
heads up: libxc soname bump
Hi, I'm updating libxc in rawhide to version 4.0.1. This update contains a soname bump, so rebuilds of dependent packages will be necessary: - cp2k - gpaw - elk - exciting I don't think there have been any API changes, so the rebuilds should go smoothly. I'll take care of the rebuilds. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: not all that qualified...
On 05/31/2017 05:19 PM, Christopher wrote: On Wed, May 31, 2017 at 6:44 PM David Muse <mailto:david.m...@firstworks.com>> wrote: Hello all, I have a fairly large package that needs review: https://bugzilla.redhat.com/show_bug.cgi?id=1415612 and I've been offered a few review swaps for it, but the trouble is, I don't really feel well qualified to review packages yet. I only maintain one other package (a pre-requisite for that one above) and it's super simple. Should I just jump in anyway? How is this kind of thing usually resolved? At the risk of turning this into a "me too" thread, I want to thank you for asking this question. I'm in the same situation. I'm not comfortable reviewing packages yet. I'm sure there are others as well. So, on behalf of all us in this same situation, thanks for asking. I look forward to the advice that (hopefully) follows, from those more experienced. Sounds like a Catch-22: you can't get experience without reviewing packages, but you don't want to review until you have more experience. However, this is exactly why we have the sponsor system in place. I've found it a good system that the sponsor should ask for a few informal reviews from their sponsoree candidates, and the sponsor then does the formal review, checking if the sponsoree missed anything. Reviewing is nowadays a much simpler task than what it used to be, thanks to the automated fedora-review process. It handles a lot of things for you, but you still do have to go through some checklists by hand. I would suggest you do an informal review, and ask your sponsor, or people on the list to check it for you. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
psi4 license change: GPLv2+ -> LGPLv3
Dear all, starting from version 1.1 (building in rawhide), the license of psi4 has been changed from GPLv2+ to LGPLv3. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
libint license change
Dear all, starting from version 1.2 (building in rawhide), the license of libint has been changed from GPLv2+ to LGPLv3. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: YAST for Fedora?
On 04/18/2017 12:17 AM, Farhad Mohammadi Majd wrote: I believe that everyone comes from MS Windows to Linux will need to YAST, currently it provides many modules that makes system management very easy: * service management, what services are running, what are stopped, and user can change their status. * systemd control * hardware configuration and provide technical info about them * many more modules for doing essential works until Fedora does not provide YAST, it can not claim that is a good alternative for desktop users of MS Windows. An alternative does not mean it has to be a clone. The beauty about linux is that it tends to work without you needing to change any configs. I honestly can't remember the last time I've needed to edit services or systemd. All my devices work out-of-the box, except the wireless card in my laptop that wasn't originally supported by the kernel and so I had to grab a newer one from rawhide and newer firmware from upstream. Also, if you're going to configure services, it's a good bet you'll want to edit the config files as well. Sure, a configuration tool might be great for some simple things, like sharing your internet connection at home, but a) as stated before, the purpose-specific tools are much better at this than one-size-fits-all ones b) there's simply less need to run services yourself nowadays, because you can get them cheap or free of charge from the cloud. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Builds not hitting rawhide
Hi, it seems there's a snag in the rawhide buildroot update. My F24 and F25 buildroot overrides went into action ages ago, but rawhide still doesn't have a package I built hours ago. I notice that according to https://fedoraproject.org/wiki/Releases/26/Schedule f26 is supposed to branch tomorrow from rawhide, is the problem I'm describing related to this? -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Noarch package with arched tests
On 02/27/2017 03:36 AM, Ralf Corsepius wrote: On 02/26/2017 11:13 PM, Susi Lehtola wrote: Hi, I've packaged pybind11 which is a seamless interface between Python and C++11. This is a headers-only package, which would make it noarch... Cf. the "Packaging Header Only Libraries" section in the FPG. These are required NOT to be noarched. Thanks, I just landed on that section myself! -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Noarch package with arched tests
Hi, I've packaged pybind11 which is a seamless interface between Python and C++11. This is a headers-only package, which would make it noarch... However, it also carries a testsuite, which - of course - is important to run on all architectures. Is there some nifty trick to trick the build system to build the package on all arches simultaneously while making the headers package noarch? If there were any binaries produced by the package, this would be easily accomplished, but I don't think there's any sense in shipping e.g. the testsuite just to make the headers noarch. (Of course, should pybind11 develop a runtime library, then pybind11-devel would also include symlinks to the library, making it no longer a noarch package!) -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: OpenMPI binary only created on 64bit not on 32bit
On 11/28/2016 04:20 AM, Johannes Lips wrote:
Am 28.11.2016 09:51, schrieb Johannes Lips:
The pregenerated configure-script looks for libmpi.so in "/usr/lib
/usr/lib/openmpi /usr/lib64/openmpi/lib", but on i686 it's in
"/usr/lib/openmpi/lib". Regenerating the configure-script might
work. Something like "autoreconf --force --install" in %prep after
%setup. I can not test it at the moment (just windows-machines
around me at work).
Thanks a lot. I will try to regenerate the configure script, once I
am back home. I also reported it back to upstream, since I am not
sure if that's fedora specific.
Usually to compile MPI stuff you just set
CC=mpicc
CXX=mpic++
FC=mpifort
since those wrappers handle all the necessary libraries by themselves.
Also, note that %{_bindir} is NOT the right place to install OpenMPI
binaries - they should go into %{_libdir}/openmpi/bin. They also should
have the _openmpi suffix ($MPI_SUFFIX) to distinguish them from the
sequential binaries. And the same goes for MPICH vs OpenMPI.
--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
libxc bump to 3.0.0 in rawhide - API changes
Hi, I'm going to bump libxc to the newly released 3.0.0 version in rawhide. This introduces some changes to the API as well as a split of the libraries, which may require changes to programs compiling against libxc. The list for the affected packages is a rather short one $ repoquery --disablerepo=* --enablerepo=rawhide --source --whatrequires "libxc.so.1()(64bit)"|sort|uniq ape-2.2.0-2.fc22.src.rpm cp2k-3.0-1.fc25.src.rpm elk-3.3.17-17.fc24.src.rpm exciting-10-2.fc24.src.rpm gpaw-0.11.0.13004-20.fc24.src.rpm libxc-2.1.2-6.fc24.src.rpm I will handle the rebuilds for these packages. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Needless use of %defattr (in 4464 packages)
On 01/26/2016 12:48 AM, Ville Skyttä wrote: On Tue, Jan 26, 2016 at 9:35 AM, Petr Pisar wrote: This can bring bugs because, as noted in the orignal message, some people use to change wrong permissions coming from %install section. Can you give a concrete example where doing this actually accomplishes something with rpmbuild >= 4.4? I can't immediately think of one; I don't see how "wrong permissions from %install" would end up in the package as files with non-root user/group. AFAIU rpmbuild >= 4.4 sets %defattr(-,root,root,-) by default and repeating immediately at start of %files is a no-op. Ville is right: the move away from %defattr was done 5 years ago(!) already. As speculated by Jason in the original post, %defattr *was* necessary for EL4, but seems to be unnecessary in EL5 and newer. In my case, the use of %defattr has just been a lapse - I thought it was still necessary for EL5. I'm all for a script based approach to remove the default %defattr statements from spec files. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Koji: no space left on device
On 10/23/2015 11:12 AM, Jerry James wrote: Just had a build fail: http://koji.fedoraproject.org/koji/taskinfo?taskID=11560206 Me too, on multiple build nodes. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Query: %cmake not doing out-of-tree builds?
On 10/10/2015 01:25 PM, Neal Gompa wrote: Hello all, Over the last few weeks, I've been working on a number of packages that use CMake for the build system for various distros, and I've noticed something rather peculiar. Of all the distros I've built packages for (Fedora/CentOS, openSUSE, Mageia, Debian, and Ubuntu), only Fedora/CentOS does not automatically do CMake building in a subdirectory such that the build artifacts don't mix in with the source tree. Essentially, the %cmake macro doesn't enforce builds are out-of-tree. Is there a particular reason for this? One that comes to mind is that you might want to build different flavors of the same sources, one prominent example being parallellizable programs that can be compiled either into sequential binaries or binaries that can be run in parallel. As has already been pointed out by many people on this list, it is simple to do an out-of-root build in the spec file even though it is not done by default. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.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
OpenMesh soname bump in rawhide
Hi, I'm updating OpenMesh in rawhide to version 4.1, which bumps the soname. Only IQmol seems to use OpenMesh, which I'm rebuilding soon after. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Problem with build system?
On 09/17/2015 08:03 AM, Kevin Fenzi wrote: On Wed, 16 Sep 2015 21:34:59 -0700 Susi Lehtola wrote: BuildError: mismatch when analyzing QMsgBox-headers-0-6.20130830git94677dc.fc22.noarch.rpm, rpmdiff output was: error: cannot open Packages index using db5 - Permission denied (13) error: cannot open Packages database in /var/lib/rpm error: cannot open Packages database in /var/lib/rpm removed REQUIRES QMsgBox(armv7hl-32) = 0-6.20130830git94677dc.fc22 added REQUIRES QMsgBox(x86-64) = 0-6.20130830git94677dc.fc22 Is the build system ill? No. Your headers subpackage is different on x86_64 and armv7. Koji builds noarch subpackages on all arches and checks if they are the same. If they are not, it's an error. You are going to need to redo your headers subpackage so it's the same on all arches, or make it archfull. Ah, I got distracted by the rpm errors. The problem was indeed that I had an archful require in the noarch headers package. Thanks! -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.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
Problem with build system?
Hi all, I was just trying to build QMsgBox-0-6.20130830git94677dc, but the build fails on all distros. The difference to the earlier release is that I put in a qt5 build, and split the headers to a separate subpackage. The packages build successfully, but crash in the postprocessing stage: BuildError: mismatch when analyzing QMsgBox-headers-0-6.20130830git94677dc.fc22.noarch.rpm, rpmdiff output was: error: cannot open Packages index using db5 - Permission denied (13) error: cannot open Packages database in /var/lib/rpm error: cannot open Packages database in /var/lib/rpm removed REQUIRES QMsgBox(armv7hl-32) = 0-6.20130830git94677dc.fc22 added REQUIRES QMsgBox(x86-64) = 0-6.20130830git94677dc.fc22 Is the build system ill? -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF vs YUM, $pkg, $pkg-mpi, $pkg-openmpi having same provides
On 06/14/2015 03:02 PM, Sandro Mani wrote:
On 14.06.2015 16:28, Sandro Mani wrote:
Rules to generate such requires/provides:
* Provides: if the path of the library starts with $MPI_LIB, append
the (openmpi) resp (mpich) to the provides string
* Requires: if the path of the scanned object starts with $MPI_LIB and
the required library exists in $MPI_LIB, add (openmpi) resp (mpich) to
the requires string
Overriding the find-requires.sh could be done with a
%{?openmpi_package_header}.
Concrete examples:
https://smani.fedorapeople.org/mpi-find-provides
https://smani.fedorapeople.org/mpi-find-requires
Konsole output
$ echo -e
"/usr/lib64/openmpi/lib/libnglib-5.3.1.so\n/usr/lib64/libnglib-5.3.1.so"
| ./mpi-find-provides
libnglib-5.3.1.so()(64bit)(openmpi-x86_64)
libnglib-5.3.1.so()(64bit)
Sounds even better... although your links give HTTP 403.
--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF vs YUM, $pkg, $pkg-mpi, $pkg-openmpi having same provides
On 06/12/2015 06:34 AM, Orion Poplawski wrote: On 06/11/2015 10:01 AM, Sandro Mani wrote: So, whose fault is this? Packaging of dnf? Nothing relevant for this caught my eye skimming through the packaging guidelines. And related: trying to install some $pkg-openmpi package, I don't generally see packages enforcing that the -openmpi version of some dependency library is installed as opposed to just the regular libs package. Should such requires need to be stated explicitly? MPI packages need to filter out the provides from the MPI versions and explicitly add needed requires on the specific MPI flavors of packages needed. This probably needs to be added to the MPI guidelines. Yes, a mention of filtering should be added. Basically, this is already discussed in http://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: DNF vs YUM, $pkg, $pkg-mpi, $pkg-openmpi having same provides
On 06/11/2015 09:01 AM, Sandro Mani wrote: So, whose fault is this? Packaging of dnf? Nothing relevant for this caught my eye skimming through the packaging guidelines. I think this is dnf's fault. YUm didn't have the same problem, since if multiple packages provided the necessary library, yum installed the one with the shortest name, so out of scotch and scotch-mpich it'd install scotch. And related: trying to install some $pkg-openmpi package, I don't generally see packages enforcing that the -openmpi version of some dependency library is installed as opposed to just the regular libs package. Should such requires need to be stated explicitly? Yes, that's in the MPI guidelines. File bug reports on the packages. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Reason why non-commiters are not allowed to create buildroot overrides?
On 03/15/2015 08:35 AM, Sandro Mani wrote:
Hi,
Just wondering, is there a particular reason why non-commiters are not
allowed to create buildroot overrides for a package?
Reason for asking: I've got a package (openambit) which installs a file to
Konsole output
%{_libdir}/wireshark/plugins/%{wireshark_ver}/ambit.so
This means, for every version change of wireshark, I need to adjust
%{wireshark_ver} and rebuild.
At present, stable and branched releases, to avoid broken dependencies
in the time window wireshark and then openambit are pushed to stable,
I'd need to nag the wireshark maintainer every time to create a
buildroot override, or ask for commit access to wireshark. I suppose I
should do the latter, but yeah, just wondering if there is a reason
against allowing people to create buildroot overrides directly.
With a similar rationale you could argue that one should be able to
commit changes to packages without any special commit rights.
The reason why buildroot overrides can't be made by anyone is that the
maintainer might not want people to build packages against the new
version, if for example it breaks things.
Here the situation is obviously somewhat different. If updating
wireshark breaks openambit, then
a) wireshark shouldn't have version updates in stable releases per the
Fedora Updates Policy
b) if the updates are warranted, wireshark and openambit should be
updated in unison by the wireshark maintainer
--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Note for packages linking against GSL [ACTION NEEDED]
On 02/24/2015 07:25 AM, Jerry James wrote: On Mon, Feb 23, 2015 at 10:46 PM, Orcan Ogetbil wrote: Can you elaborate on this? gsl has plenty of other routines that have nothing to do with linear algebra. Is there a technical reason why you have to link to a BLAS if the code using gsl does not actually need a BLAS? The blas symbols are not weak, so they are undefined when linking an application without a BLAS library. See the output of "ldd -r /usr/lib64/libgsl.so.0.17.0" on Rawhide. Those symbols should be weak instead. That way, if an application doesn't use them, they don't prevent linking without a BLAS library. That's a good question. But this decision has been made upstream... -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Note for packages linking against GSL [ACTION NEEDED]
On 02/23/2015 09:46 PM, Orcan Ogetbil wrote: On 21 February 2015 at 18:50, Susi Lehtola wrote: Because libgsl is no longer linked to a CBLAS library, packages linking to GSL need to also link to a CBLAS library, ATLAS probably being the best candidate since OpenBLAS is not available for all Fedora architectures. Can you elaborate on this? gsl has plenty of other routines that have nothing to do with linear algebra. Is there a technical reason why you have to link to a BLAS if the code using gsl does not actually need a BLAS? Naturally if a package doesn't use any of GSL's vector routines, there's no performance benefit of linking to an optimized CBLAS library. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Note for packages linking against GSL [ACTION NEEDED]
On 02/22/2015 02:09 PM, Richard W.M. Jones wrote:
On Sat, Feb 21, 2015 at 03:50:16PM -0800, Susi Lehtola wrote:
Because libgsl is no longer linked to a CBLAS library, packages
linking to GSL need to also link to a CBLAS library, ATLAS probably
being the best candidate since OpenBLAS is not available for all
Fedora architectures. The following trick should be enough to handle
the link
%if 0%{?fedora} > 20 || 0%{?rhel} > 6
export LIBS="-lgsl -L%{_libdir}/atlas -lsatlas"
%else
export LIBS="-lgsl L%{_libdir}/atlas -lcblas -latlas"
%endif
Ugh, scrap that. This is only on Fedora 22 and rawhide, so only the
former version applies. So, the link argument just has to be changed
from "-lgsl" to "-lgsl -L%{_libdir}/atlas -lsatlas".
I'm not really sure I understood all of that, but anyway.
ocaml-gsl appears to use the output of `gsl-config --libs` which in
effect means that it's using on x86-64: '-lgsl -lgslcblas -lm'
Yes, a lot of packages seem to be just happily linking to gslcblas,
since it seems a lot of people are not aware of the huge performance
benefits of using optimized libraries.
It's possible to override this by exporting GSL_CBLAS_LIB to a value
like the one above.
However my questions is why doesn't `gsl-config --libs` appear to
produce the optimal link command?
That is a good question.
Also it looks like to use atlas, spec files would need an additional:
BuildRequires: atlas-devel
Yes, if you want to link to ATLAS, you need the additional buildrequire.
Proposed patch for ocaml-gsl.spec attached.
Looks good.
--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.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
Note for packages linking against GSL [ACTION NEEDED]
Hi,
the GNU Scientific Library (GSL) contains some linear algebra routines
that need a CBLAS library to work.
GSL contains a compatibility CBLAS library (gslcblas) that provides a
version of these routines. In 2010, we started to link libgsl by a
Fedora patch to libgslcblas, so linking to libgsl could be done just by
-lgsl instead of -lgsl -lgslcblas.
However, the GSL CBLAS library is far from optimal, and you can
typically get an order of magnitude more performance by using an
optimized library. In 2011, the default link in libgsl was changed to be
against ATLAS.
This default, Fedora specific link was removed in Fedora 22 in December,
because
a) there are more CBLAS libraries available than just GSL CBLAS or
ATLAS; e.g. OpenBLAS, Intel MKL or AMD ACML being good examples
b) upstream clearly intended the choice of the library to be made upon
link time
c) a project linking multiple libraries must use the same BLAS/CBLAS
library in all of its components
Because libgsl is no longer linked to a CBLAS library, packages linking
to GSL need to also link to a CBLAS library, ATLAS probably being the
best candidate since OpenBLAS is not available for all Fedora
architectures. The following trick should be enough to handle the link
%if 0%{?fedora} > 20 || 0%{?rhel} > 6
export LIBS="-lgsl -L%{_libdir}/atlas -lsatlas"
%else
export LIBS="-lgsl L%{_libdir}/atlas -lcblas -latlas"
%endif
Furthermore, because the link has vanished from GSL, the following
packages need to be recompiled:
$ sudo repoquery --disablerepo=* --enablerepo=rawhide --whatrequires
libgsl\* -i|grep "Source :"|sort|uniq|awk '{print $NF}'
3Depict-0.0.17-3.fc22.src.rpm
ape-2.2.0-2.fc22.src.rpm
asymptote-2.32-5.fc22.src.rpm
bogofilter-1.2.4-3.fc22.src.rpm
calligra-2.8.7-9.fc22.src.rpm
coot-0.8.1-1.fc22.src.rpm
dieharder-3.31.1-13.fc22.src.rpm
enblend-4.1.3-3.fc22.src.rpm
freefem++-3.31-2.3.fc23.src.rpm
freesteam-2.1-6.20140724svn753.fc22.src.rpm
gambas3-3.6.1-3.fc22.src.rpm
gdl-0.9.5-4.fc22.src.rpm
ghmm-0.7-12.svn2286.fc22.src.rpm
gipfel-0.4.0-5.fc23.src.rpm
gnuradio-3.7.5.1-5.fc22.src.rpm
gsl-1.16-16.fc22.src.rpm
IBSimu-1.0.5-9.b.fc22.src.rpm
inkscape-0.91-4.fc23.src.rpm
kst-2.0.8-1.fc22.src.rpm
LabPlot-1.6.0.3-8.fc22.src.rpm
libindi-0.9.9-1.fc22.src.rpm
luminance-hdr-2.3.1-11.fc22.src.rpm
mathgl-2.3-4.fc23.src.rpm
milia-1.0.0-7.fc22.src.rpm
mmseq-0.9.18-14.fc22.src.rpm
morse2txt-1.0.0-13.fc22.src.rpm
mp-1.3.0-3.fc22.src.rpm
nco-4.4.7-1.fc22.src.rpm
nip2-7.42.1-1.fc22.src.rpm
ocaml-gsl-1.18.1-1.fc23.src.rpm
octave-gsl-1.0.8-9.fc22.src.rpm
opengrm-ngram-1.2.1-3.fc22.src.rpm
openms-1.11.1-12.fc22.src.rpm
orsa-0.7.0-29.fc22.src.rpm
perl-PDL-2.7.0-8.fc22.src.rpm
pfstmo-1.5-7.fc22.src.rpm
player-3.0.2-40.fc22.src.rpm
pspp-0.8.4-1.fc22.src.rpm
pygsl-0.9.5-12.fc22.src.rpm
pypop-0.7.0-13.fc22.src.rpm
python-cvxopt-1.1.7-3.fc22.src.rpm
root-5.34.24-3.fc22.src.rpm
sagemath-6.4.1-4.fc22.src.rpm
scidavis-1.D8-8.fc22.src.rpm
step-14.12.1-1.fc22.src.rpm
vfrnav-20141211-1.fc22.src.rpm
votca-tools-1.2.4-3.fc22.src.rpm
xaos-3.5-12.fc22.src.rpm
I'm handling ape and octave-gsl. gsl itself obvisously doesn't need
rebuilding.
--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mass Fortran rebuilds due to new GCC?
On 02/15/2015 01:05 PM, Kevin Fenzi wrote: On Fri, 13 Feb 2015 21:59:06 +0100 Björn Esser wrote: Am Freitag, den 13.02.2015, 13:53 -0700 schrieb Kevin Fenzi: Can you expand on the breakage? Is it that they no longer rebuild? Or that they no longer run? I think, he's talking about the fact they are segfaulting… ;) Well, thats not really clear to me at least. "broken" is pretty generic and vuage. Well, yes. Broken here means that if you have packages foo and bar, with bar being built on foo, 1) if you try to rebuild bar, it will fail because foo's module is of the wrong version. 2) after foo is rebuilt, bar will typically segfault when it's run. so you'll need to rebuild both with the new version of GFortran. For this particular case it is: repoquery --whatrequires libgfortran But it sounds like it's a subset of these (only those with .mod files) that are actually affected? So, something like: % repoquery -qf /usr/lib64/gfortran/modules/\*.mod | sort | uniq elpa-mpich-devel-0:2013.11-5.008.fc22.x86_64 elpa-openmpi-devel-0:2013.11-5.008.fc22.x86_64 getdata-devel-0:0.8.6-1.fc22.x86_64 grib_api-devel-0:1.13.0-1.fc22.x86_64 hdf5-devel-0:1.8.14-1.fc22.x86_64 healpix-devel-0:2.13a-15.fc22.x86_64 libxc-devel-0:2.1.0-4.fc22.x86_64 netcdf-fortran-devel-0:4.4.1-1.fc22.x86_64 plplot-fortran-devel-0:5.10.0-17.fc22.x86_64 qd-devel-0:2.3.15-1.fc22.x86_64 wannier90-devel-0:2.0.0-3.fc22.x86_64 And then I suppose everything that buildrequires them? Yes, that might be a sane assumption. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.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
Mass Fortran rebuilds due to new GCC?
Hi, as has happened many times before, the GCC bump in rawhide has broken all Fortran packages, desperately needing a mass rebuild. Unfortunately, rpm is blissfully unaware of any breakage happening (BZ #1192617) so maintainers won't even know when this breakage happens. Before I start rebuilding packages, are there any plans to do the rebuilds soon..? -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Remove gcc, gcc-c++ and make from minimal build root
On 01/14/2015 04:38 AM, Vít Ondruch wrote: And it seems that this is the number of packages written in C++: $ repoquery --disablerepo=* --enablerepo=rawhide --source --whatrequires 'libstdc++.so.6*' | sort -u | sed -r 's/(.*)-.*-.*/\1/' | uniq | wc -l 2396 I'd like to point out at this place, that this would help also the 5006 packages written in C, since they don't need C++ to build. Only 14.8 % of packages, which happens to be written in C++, would not benefit from this change. Instead of dropping make, gcc, and gcc-c++ from the minimal build root, would it make sense just to drop gcc-c++? That would only affect a small minority of packages, while eliminating some amount of additional packages in the buildroot. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.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
Review swap
Hi, due to a new dependence in the IQmol package, I need to get OpenMesh reviewed. https://bugzilla.redhat.com/show_bug.cgi?id=1132691 It's a very straightforward package, and I'm willing to review something of similar complexity. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.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
[ACTION NEEDED] Orphaning packages
Hi, due to relocation to another continent and starting a new job, I have to refocus my reduced time for Fedora on packages that I actively use. So, I'm orphaning the following packages: dopewars efte firehol gdpc gromacs jaxodraw json-c latex2rtf lis noip pdfchain perl-Net-UPnP pidgin-latex pygrace pypar python-paida qd towhee unetbootin vecmath vim-latex votca-csg votca-tools xdrfile -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: pvm packaging guidelines violations?
On Fri, 30 May 2014 11:45:11 -0500 Richard Shaw wrote: > First let me say that if anyone wants to be the primary maintainer of pvm > please step up! I only need it as a dependency. What package are you referring to? # repoquery --whatrequires pvm pvm-gui-0:3.4.6-5.fc20.x86_64 # repoquery --whatrequires /usr/bin/pvm # I think pvm can be safely retired. The upstream seems to have been dead for years. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: pvm packaging guidelines violations?
On Fri, 30 May 2014 11:45:11 -0500
Richard Shaw wrote:
> First let me say that if anyone wants to be the primary maintainer of pvm
> please step up! I only need it as a dependency.
>
> While fixing the build for rawhide due to a tcl/tk update I had to look at
> the spec file and it was horrifying (ok, I'm exaggerating a bit).
>
> The sources are extracted directly into the buildroot and then built in
> place. Also, it is "installed" (if you can call it that) into /usr/share
> even though it includes static libraries and binaries (which are later
> symlinked into /usr/bin)
>
> So questions:
>
> 1. Is this even legal?
No.
Looking through the older branches, I can see that the same way has
been in use in Fedora 7... And I'd be tempted to say that this
originates from pre-2000.
So a *major* rewrite of the spec file is in order. [To fix things one
might also have to fix the upstream build scripts. I'm guessing they're
the root cause here.]
> 2. Should this package go through a re-review?
Not according to the policy, no.
The package has been in Fedora the whole time, and the maintainers are
supposed to keep the spec files up-to-date with Fedora policies.
Since the spec file is breaking the packaging guidelines pretty
heavily, IIRC according to policy all provenpackagers are allowed to
step in and fix the issues.
> 3. Can the install location be changed at this point? Other distros seem
> to install into /usr/lib{,64} and symlink the binaries from there.
I think so.
> There are also a large number of patches, some of which for secondary
> arches so I don't think I'm the right person to lead the charge here
> Any volunteers?
But these shouldn't matter..
--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Computational chemistry softwares orphaned in F20
On Mon, 19 May 2014 10:00:52 -0300 Henrique Junior wrote: > 2014-05-19 4:20 GMT-03:00 Susi Lehtola : > > mopac7 is orphan in F20 and rawhide, and probably will be retired(?) > > > MOPAC7 is still a very important software, it would be a shame to lose it > in our repos. > Does anyone know something about MOPAC7.1[1]? It might be, but from what I understand on computational chemistry discussion forums, there are hundreds of known bugs in MOPAC7 which won't be fixed, because the developers have since switched to a non-free licensing approach. Packages that lack a maintained upstream are often somewhat problematic. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Computational chemistry softwares orphaned in F20
On Sun, 18 May 2014 21:23:51 -0500 Jon wrote: > Indeed, something strange: > > $ spectool -g mopac7.spec > curl: (22) The requested URL returned error: 404 Not Found > > The maintainer of the mopac7 package should fix the source0, or retire > the package. mopac7 is orphan in F20 and rawhide, and probably will be retired(?) -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Computational chemistry softwares orphaned in F20
On Fri, 16 May 2014 08:26:23 -0300 Henrique Junior wrote: > 2014-05-16 6:23 GMT-03:00 Susi Lehtola : > > Computational chemistry is by no means dead. There are big packages > > available for real calculations, e.g. NWChem and PSI4 are available in > > Fedora. > > I have to disagree with you. Computational chemistry is not dead and I know > lots of chemists doing a great job in this area (both organic and > inorganic). MOPAC7 is still in good shape despite the age. That's not what I said. Also, I'm active in the field of computational chemistry myself. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Computational chemistry softwares orphaned in F20
On Thu, 15 May 2014 13:06:59 -0300 Henrique Junior wrote: > Hi, I was taking a look at Fedora Package DB and saw that some very > important computational chemistry softwares (ghemical, mopac, mpqcare... ) > marked as orphaned in F20, is that correct? > As a chemist I'm very concerned about that. > No luck contacting carllibpst to ask. ghemical upstream is dead. New versions of mopac are non-free; so same thing here. mpqc hasn't had a stable release since 2006... although upstream seems active on github. Computational chemistry is by no means dead. There are big packages available for real calculations, e.g. NWChem and PSI4 are available in Fedora. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: lbzip2 as default bzip2 implementation
On Fri, 4 Apr 2014 12:49:25 -0400 Matthew Miller wrote: > On Fri, Apr 04, 2014 at 04:15:59PM +0200, Mikolaj Izdebski wrote: > > "lbzip2 -u" always produced smallest files (even smaller than bzip2) > > while consuming the least amount of resources (CPU power and memory). > > This directly translates to lowest bills in cloud, which makes "lbzip2 > > -u" the best choice here. > > But... the size difference in your test cases appear to be 0.1% and > 0.02%. Am I reading that right? And, compressing linux-3.12.6.tar with xz > instead of bzip2 gives a 15.6%, or with xz -9, 19.7%. Of course, that's very > slow, and the other resource factors are important too. (And lbzip2 is > impressively fast.) Well, looking at the table, I calculate size differences of -0.10% and -0.14% for lbzip2 and lbzip2 -u, respectively, compared to bzip2 for compression of payload.tar. .. and -0.31% and -0.02% for linux-3.12.6.tar. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.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
pdfchain retired [was Re: pdftk retired?]
Quoting Susi Lehtola : On Thu, 06 Mar 2014 14:52:27 -0500 Tom Callaway wrote: > That are the two reasons why I'm not able to support pdftk on > Fedora anymore and was forced to reitred this package. I'm sorry > for nayone who maintaining any package with dependencies on this > package. This is why pdftk died. We can't include iText5+ because of its licensing issues. But isn't it AGPL licensed, which is a free license..? I've retired pdfchain from rawhide because of the broken dependency caused by pdftk. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: pdftk retired?
On Thu, 06 Mar 2014 14:52:27 -0500 Tom Callaway wrote: > > That are the two reasons why I'm not able to support pdftk on > > Fedora anymore and was forced to reitred this package. I'm sorry > > for nayone who maintaining any package with dependencies on this > > package. > > This is why pdftk died. We can't include iText5+ because of its > licensing issues. But isn't it AGPL licensed, which is a free license..? -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: pdftk retired?
On Thu, 06 Mar 2014 11:31:18 +0100 Michael J Gruber wrote: > I just git a "broken dependencies" notice for a package that I maintain. > The reason is that "pdftk" got retired just the other day. > > I may have missed a corresponding post on fedora-devel, but I think a > heads up notice to maintainers of depending packages may be in order > before you retire a package, as a general idea. > > You see, unretiring a package is so much more work than changing > maintainership. > > As for pdftk: I see 2 failed builds for version 1.45 and none for the > current version 2.02 (which probably breaks the api anyways). What are > the plans? Retire pdftk completely? Start fresh with pdftk2? > > pdflabs, the maker of pdftk, provide binary as well as source rpms for > pdftk 2.02, by the way. I might even look into packaging it but don't > want to duplicate any existing efforts. > > Michael +1 pdftk is a very important package, so new (co)maintainers shouldn't be hard to find. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: exclude people from giving karma?
On Sun, 23 Feb 2014 18:12:55 +0100 Reindl Harald wrote: > https://admin.fedoraproject.org/updates/FEDORA-2014-2922/libreoffice-4.2.1.1-1.fc20?_csrf_token=a6a024f6e2d35ad3fb8666c1244e215a6aa2 > > how can people pretend "installation went smoothly, no issue detected during > basic > document manipulation" for packages which are not installable at all due > dependencie problems? People *couldn't* know there were problems, because all the positive reports were from the time the update was in updates-testing. All who tried the update, also had the dependency available in updates-testing. The problem here lies in that the update was badly committed. The libreoffice and libcmis updates should have been bundled. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.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
MPICH update
Hello, looks like mpich has been updated with a soname bump. Why has this not been announced in the devel list? -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Wed, 5 Feb 2014 13:51:41 -0800 David Timothy Strauss wrote: > Like this: > https://bugzilla.redhat.com/show_bug.cgi?id=959071 > > I specifically followed up to say the issue continues in Fedora 19, > and nothing changed. The bug tracker should not expire bugs if there's > been a comment after the EOL warning. You just need to change the Version tag. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages installing files to /etc/rpm
On Fri, 31 Jan 2014 22:23:51 +0200
Ville Skyttä wrote:
> Specfiles not targeting EL < 7 can simply replace %{_sysconfdir}/rpm
> with %{_rpmconfigdir}/macros.d and ones that wish to stay compatible
> with EL5 and 6 can do something like this to find the proper dir:
>
> %global macrosdir %(d=%{_rpmconfigdir}/macros.d; [ -d $d ] ||
> d=%{_sysconfdir}/rpm; echo $d)
> jussilehtola libint (none)
Fixed.
--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.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
TeXLive broken in rawhide?
Looks like TeXLive is broken in rawhide. + pdflatex progman This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2014/dev) restricted \write18 enabled. kpathsea: Running mktexfmt pdflatex.fmt tcfmgr: config file `tcfmgr.map' (usually in $TEXMFMAIN/texconfig) not found (ls-R missing?). fmtutil: config file `fmtutil.cnf' not found. I can't find the format file `pdflatex.fmt'! RPM build errors: -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.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
Libint update, recompiles due
FYI, I've changed some configuration parameters in the libint-1.1.5-2 build, which requires all dependent packages to be rebuilt. Because this build addresses some missing functionality, I'm going to push it in older distributions as well. I'll handle the necessary changes to other packages myself. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On Mon, 30 Sep 2013 10:03:14 +0300
Susi Lehtola wrote:
> On Sun, 29 Sep 2013 23:57:21 +0200
> Kevin Kofler wrote:
>
> > Susi Lehtola wrote:
> >
> > > On Sun, 29 Sep 2013 01:04:31 +0200
> > > Kevin Kofler wrote:
> > >> Susi Lehtola wrote:
> > >> > If you link to -lblas, you're shooting yourself in the leg in the first
> > >> > place, since that's the reference implementation on current Fedoras.
> > >>
> > >> In fact, I noticed that, and that's a serious packaging bug.
> > >>
> > >> If a package links -lblas -llapack, if ATLAS is installed, it'll get
> > >> reference BLAS and ATLAS LAPACK! If it links -llapack -lblas, it'll
> > >> probably get the ATLAS functions throughout, because then libatlas is
> > >> resolved first. That's very unexpected and broken behavior.
> > >
> > > No, you're assuming nonstandard behavior. ATLAS has never done this.
> >
> > I am describing the behavior that actually happens with the Fedora 18 (and
> > I
> > presume 19 too) atlas-sse2 package!
> >
> > Try running ldd on LAPACK-using stuff, you'll see how the ATLAS liblapack
> > is
> > picked up (but libblas is not overridden, which is a bug).
>
> Yes, but everyone knows that if you want ATLAS, the link command is
> -L%{_libdir} -llapack -lf77blas -latlas
> If you link to -lblas you're assuming nonstandard behavior. Fedora is
> not Debian.
>
> Nowadays this is just
> -L%{_libdir} -lsatlas
> a much easier version.
.. and this is also the main reason why I think that the new scheme is
loads better. At the linking phase you can be 100% sure of what library
you're using, and also that you're not going to run into problems with
incompatible libraries.
--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On Sun, 29 Sep 2013 23:57:21 +0200
Kevin Kofler wrote:
> Susi Lehtola wrote:
>
> > On Sun, 29 Sep 2013 01:04:31 +0200
> > Kevin Kofler wrote:
> >> Susi Lehtola wrote:
> >> > If you link to -lblas, you're shooting yourself in the leg in the first
> >> > place, since that's the reference implementation on current Fedoras.
> >>
> >> In fact, I noticed that, and that's a serious packaging bug.
> >>
> >> If a package links -lblas -llapack, if ATLAS is installed, it'll get
> >> reference BLAS and ATLAS LAPACK! If it links -llapack -lblas, it'll
> >> probably get the ATLAS functions throughout, because then libatlas is
> >> resolved first. That's very unexpected and broken behavior.
> >
> > No, you're assuming nonstandard behavior. ATLAS has never done this.
>
> I am describing the behavior that actually happens with the Fedora 18 (and I
> presume 19 too) atlas-sse2 package!
>
> Try running ldd on LAPACK-using stuff, you'll see how the ATLAS liblapack is
> picked up (but libblas is not overridden, which is a bug).
Yes, but everyone knows that if you want ATLAS, the link command is
-L%{_libdir} -llapack -lf77blas -latlas
If you link to -lblas you're assuming nonstandard behavior. Fedora is
not Debian.
Nowadays this is just
-L%{_libdir} -lsatlas
a much easier version.
--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On Sun, 29 Sep 2013 11:25:27 +0300 Susi Lehtola wrote: > On Sun, 29 Sep 2013 01:05:23 +0200 > Kevin Kofler wrote: > > Susi Lehtola wrote: > > > Again, you should file a bug to the FPC about this. > > > > Is this really the FPC's responsibility? I'd expect this to be the > > maintainer's, and for escalation FESCO's. > > FPC maintains packaging guidelines. If you think that BLAS/LAPACK > packages should have their own guideline, then file a proposition to > the FPC. FESCO is still there if the matter needs to be escalated from > the FPC. Also, I'd still like to remind that the case of LAPACK/BLAS is analogous to that of MPI - both follow the same standard, meaning the same symbols in different implementations of the standard. In the case of MPI there was a need to totally separate the different implementations, because otherwise esoteric problems could arise. Why would this case be different? What about runtime C libraries, should you be able to switch those as well? -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On Sun, 29 Sep 2013 01:05:23 +0200 Kevin Kofler wrote: > Susi Lehtola wrote: > > Again, you should file a bug to the FPC about this. > > Is this really the FPC's responsibility? I'd expect this to be the > maintainer's, and for escalation FESCO's. FPC maintains packaging guidelines. If you think that BLAS/LAPACK packages should have their own guideline, then file a proposition to the FPC. FESCO is still there if the matter needs to be escalated from the FPC. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On Sun, 29 Sep 2013 01:04:31 +0200 Kevin Kofler wrote: > Susi Lehtola wrote: > > If you link to -lblas, you're shooting yourself in the leg in the first > > place, since that's the reference implementation on current Fedoras. > > In fact, I noticed that, and that's a serious packaging bug. > > If a package links -lblas -llapack, if ATLAS is installed, it'll get > reference BLAS and ATLAS LAPACK! If it links -llapack -lblas, it'll probably > get the ATLAS functions throughout, because then libatlas is resolved first. > That's very unexpected and broken behavior. No, you're assuming nonstandard behavior. ATLAS has never done this. I don't care what Debian does. Fedora tries to be in close contact with upstream, which also includes not breaking their naming style. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On Sat, 28 Sep 2013 13:01:33 +0200 Kevin Kofler wrote: > Orion Poplawski wrote: > > Upstream, upstream, upstream It's not like Fedora decided to change > > these things. > > We should indeed bring this to ATLAS upstream, opening a similar bug report > there as for OpenBLAS. However, I think we should not wait for upstream to > fix this horribly broken setup. Debian has patches for ATLAS 3.10.1 to fix > it which we would just need to apply. Again, you should file a bug to the FPC about this. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On Sat, 28 Sep 2013 12:59:13 +0200 Kevin Kofler wrote: > I wrote: > > The existing ATLAS setup (before the change) just worked! > > Actually, I just noticed the ATLAS packages we ship in F18 are also broken: > libblas.so.3 is missing, so if something links only -lblas, or links -lblas > before -llapack etc., it will get the unoptimized reference BLAS functions! If you link to -lblas, you're shooting yourself in the leg in the first place, since that's the reference implementation on current Fedoras. If you want the ATLAS version of BLAS, you need to link -lf77blas -latlas. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On Thu, 26 Sep 2013 17:52:27 +0200 Kevin Kofler wrote: > For the end users, it means that > | they can install the most optimized implementation we provide for their > | CPU, or even build their own (tuned for the exact properties of their > | machine), without having to recompile all the packages using BLAS and/or > | LAPACK. If you're going to build your packages from source, then perhaps it's better to use Gentoo, Sourcemage or some other non-binary distribution. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On Thu, 26 Sep 2013 17:52:27 +0200 Kevin Kofler wrote: > I wrote: > > FYI, the author of netlib-java filed an issue with OpenBLAS for that: > > https://github.com/xianyi/OpenBLAS/issues/296 > > I'm going to reproduce here the comment that I posted there: > > | The situation I'm thinking of is an application linking one BLAS > implementation, but the > | libraries it uses linking one or more other one(s). In the best case, > | you'd end up with an unexpected implementation (and so you're no better > | off than before if you were relying on getting a specific one). In the > | worst case, you end up with symbols from multiple implementations which > | are incompatible enough to crash the program or cause it to fail with an > | unresolved symbol. > | > | But yes, incompatibilities with parallelization are a problem. The default > | implementation (shipped as libblas.so.3 and liblapack.so.3) can only > | realistically be serial. But shipping the libraries with different names > | doesn't help there, unless you're also renaming all the symbols. The > | previous paragraph on symbol conflicts applies here too! Multicore CPUs are nowadays the norm, and packages should really use libraries that support this approach. Thus your argument is obsolete. The parallel libraries are not interchangeable. Currently your argument is rather theoretical. If you really feel strongly about this, then prepare a packaging guideline along the lines of the MPI guidelines, where there is a analogous situation with regard to multiple implementations of the MPI standard. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On Mon, 23 Sep 2013 16:15:16 +0200 Frantisek Kluknavsky wrote: > On 09/22/2013 09:32 PM, Susi Lehtola wrote: > > > > I might mention that OpenBLAS (successor to GotoBLAS) is in Fedora, > > which is often 2x faster than ATLAS. But, it's only available on > > ix86 and x86_64. It does have runtime CPU detection, though for the > > 20-odd CPUs supported. > > > > Could you please add more details? I can hardly imagine a situation > where properly tuned Atlas is below 50% of maximum possible floating > point performance. Packaged Atlas tuned on a completely different > machine can of course be slow. The theory goes that if you are into > serious high-performance computing, you are willing and able to > rebuild a few packages. Plus there is a high chance that you are > using some more exotic architecture than those power-hungry x86_64. > > On the other hand pre-packaged Atlas is probably the second worst > alternative for desktop use cases (the worst being canonical Blas). Yes, this is regarding pre-packaged Atlas. The cluster guys at my university did some benchmarks of ACML, MKL, OpenBLAS, ATLAS and reference BLAS. The first three are pretty much equal, then came prepackaged ATLAS with 50% less performance and then last came reference BLAS with an order of magnitude or two less speed. But yes, you are right that ATLAS should be recompiled if you really want performance. But then again, you can just use libraries that already give optimal performance. -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.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
