Re: packaging: upgrade a library to a header-only library
On Tuesday, October 1, 2019 4:41:29 PM CEST Miro Hrončok wrote: > On 01. 10. 19 16:24, laurent.rineau__fed...@normalesup.org wrote: > > > Another possibility would be to switch to a noarch package, but in the > > future I would like to package the CGAL examples and demos as > > sub-packages. > > You should not do that, see the "Do not use noarch" part of: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_packaging_header > _only_libraries Thanks. That part of the guidelines seems what I was looking for. ... But I have another concerned, compare to header-only C++ libraries (like eigen3-devel): what will be the upgrade path? If I remove the main package `CGAL` (and keep only `CGAL-devel`), nothing will provide an upgrade path from CGAL-4.14.1-1. I could create a fake noarch sub-package 'CGAL-upgrade-to-header-only', with a versionned Obsoletes:, and an ad-hoc %doc file, but that looks like an ugly hack. -- Laurent Rineau, PhD R Engineer at GeometryFactory http://www.geometryfactory.com/ ___ 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 libQGLViewer
Hi, I have orphaned libQGLViewer: https://src.fedoraproject.org/rpms/libQGLViewer The main reason is that I no longer uses it at work. The other reasons are: - its upstream developer is no longer maintaining fully, - it fails to build from sources (FTBFS) in F28 and Rawhide branches, and I do not really have time to have a look at the issue and find a solution. Two packages depend on it in Fedora: https://src.fedoraproject.org/rpms/octomap https://src.fedoraproject.org/rpms/skyviewer I hope that package will find new maintainers. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HL4WPNVV25OY7MIHKJJAS263SV2ACHHG/
CGAL soname version bump
In Rawhide, the CGAL library has been updated to version 4.6-beta1. The SONAME is now libCGAL.so.11 instead of 10. There are a few minor API changes. Please have a look at the details on: http://www.cgal.org/releases.html#release4.6 -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- 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: CGAL soname version bump
Le Tuesday 24 February 2015 12:47:58 Laurent Rineau a écrit : In Rawhide, the CGAL library has been updated to version 4.6-beta1. The SONAME is now libCGAL.so.11 instead of 10. There are a few minor API changes. Please have a look at the details on: http://www.cgal.org/releases.html#release4.6 Since CGAL-4.6 will be published before the beta-freeze of F22, I have also build CGAL-4.6-beta1 for F22 as well, and plan to build CGAL-4.6 as soon as it is released. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no
Le Thursday 08 January 2015 08:42:45 Paul Wouters a écrit : If you want to fight that, you need to set PasswordAuthentication no and insist that people start using ssh keypairs instead. Would not the following satisfy everybody? Match User root PasswordAuthentication no -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaning ipe and figtoipe
I lack time to deal with my Fedora packages, and I just orphaned the two of them that I no longer use in my day job: ipe and figtoipe. I hope they will find new maintainers, because I know users, mostly in research centers, who expect those packages to be maintained. https://admin.fedoraproject.org/pkgdb/package/ipe/ https://admin.fedoraproject.org/pkgdb/package/figtoipe/ -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- 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: Re: Orphaning ipe and figtoipe
Le Monday 19 May 2014 19:16:56 Christopher Meng a écrit : I will take figtoipe. I imagine you want to take 'ipe' too, do not you? -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- 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: Re: Re: Orphaning ipe and figtoipe
Le Monday 19 May 2014 09:01:25 nonamedotc a écrit : I can take ipe. I have used it on and off... Please take the ownership. What I found difficult with Ipe is that the Otfried Cheong has not kept the compatibility between Ipe6 and Ipe7: a file created by ipe6, and even ipe5, cannot be opened by Ipe7. In my opinion, Fedora should have packages for the tools ipe5toxml, and ipe6upgrade, that are made to upgrade old files to newer formats. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- 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: Re: Re: Re: Orphaning ipe and figtoipe
Le Monday 19 May 2014 22:54:41 Christopher Meng a écrit : Or simply write down these in Fedora release notes. Gpodder has done this. There should be packages for the conversion tools in Fedora, because it can be written in the release notes. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- 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: Re: F21 System Wide Change: lbzip2 as default bzip2 implementation
Le Friday 04 April 2014 16:15:59 Mikolaj Izdebski a écrit : CPU: Haswell B0, Genuine Intel(R) CPU @ 2.20GHz bogomips: 4389.60 Processors:56 NUMA Nodes:2 Memory:31966 MB It would be fair to post also a bench that ran on a more usual machine, like quad-core (8 threads), and 16GB of RAM. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Packaging guideline for a library using either Qt4 or Qt5
libQGLViewer (http://www.libqglviewer.com/) is a library that can be build with either Qt4 or Qt5, with recent versions. I am considering providing packages build with both Qt4 and Qt5. I personally need both versions for my daily job (to test compatibility). I do not think we already have such libraries in Fedora. Do we have relevant packaging guidelines for such a case? https://admin.fedoraproject.org/pkgdb/acls/name/libQGLViewer -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- 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: What is the usage of an empty RPM ?
Le Tuesday 04 February 2014 19:30:16 Kevin Wilson a écrit : Hi, What is the usage of an empty RPM ? What it is for ? For example, on Fedora 20: rpm -qpl libvirt-1.1.3.3-2.fc20.x86_64.rpm shows: (contains no files) That package does not contain files, but it does contain other things: provides and requirements: $ rpm -q libvirt --requires libvirt-daemon = 1.0.5.9-1.fc19 libvirt-daemon-config-network = 1.0.5.9-1.fc19 libvirt-daemon-config-nwfilter = 1.0.5.9-1.fc19 libvirt-daemon-driver-libxl = 1.0.5.9-1.fc19 libvirt-daemon-driver-lxc = 1.0.5.9-1.fc19 libvirt-daemon-driver-qemu = 1.0.5.9-1.fc19 libvirt-daemon-driver-uml = 1.0.5.9-1.fc19 libvirt-daemon-driver-xen = 1.0.5.9-1.fc19 libvirt-daemon-driver-interface = 1.0.5.9-1.fc19 libvirt-daemon-driver-secret = 1.0.5.9-1.fc19 libvirt-daemon-driver-storage = 1.0.5.9-1.fc19 libvirt-daemon-driver-network = 1.0.5.9-1.fc19 libvirt-daemon-driver-nodedev = 1.0.5.9-1.fc19 libvirt-daemon-driver-nwfilter = 1.0.5.9-1.fc19 libvirt-client = 1.0.5.9-1.fc19 /bin/sh rpmlib(FileDigests) = 4.6.0-1 rpmlib(PayloadFilesHavePrefix) = 4.0-1 rpmlib(CompressedFileNames) = 3.0.4-1 rpmlib(PayloadIsXz) = 5.2-1 $ rpm -q libvirt --provides bundled(gnulib) libvirt = 1.0.5.9-1.fc19 libvirt(x86-64) = 1.0.5.9-1.fc19 -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- 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: Who uses abi-compliance-checker?
Le mercredi 03 juillet 2013 15:03:53 Richard Shaw a écrit : I initially got abi-compliance-checker into Fedora because one of my packages does not maintain any sort of API/ABI compatibility or even versioning for that matter. That way I could always check a new release to see if any of its dependencies needed to be rebuilt. Since then, I've started using it for all of my libraries in the spirit of Trust but verify, and I've occasionally found issues even though upstream didn't bump the soversion. So out of curiosity, anyone else using this great tool? As the upstream release manager of the CGAL libraries (http://www.cgal.org/), I have started to use it for one year, to check before I publish a beta release. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CGAL license change to (L)GPLv3+
Le mardi 07 février 2012 14:21:53 Laurent Rineau a écrit : From release 4.0, the CGAL libraries will be released under LGPLv3+ for the foundations, and GPLv3+ for the high level packages (instead of LGPLv2 and QPL respectively). In the CGAL.spec file, I mentionned License: LGPLv3+ and GPLv3+. Could not I simplify that into: License: GPLv3+? -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
CGAL license change to (L)GPLv3+
From release 4.0, the CGAL libraries will be released under LGPLv3+ for the foundations, and GPLv3+ for the high level packages (instead of LGPLv2 and QPL respectively). I have built a prerelease of CGAL-4.0 in Rawhide. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trouble with building packages in F16: The moc has changed too much
On lundi 01 août 2011 20:08:12 Richard Hughes wrote: On 1 August 2011 15:24, Jaroslav Reznik jrez...@redhat.com wrote: It's not very good idea to ship pre-generated moc files, better to autogenerate them during the build-time. PackageKit is using automake, so it's a little bit more difficult but possible, check for example [1]. Right, I *think* I'm doing the right thing in https://gitorious.org/packagekit/packagekit/blobs/master/lib/packagekit-qt/ src/Makefile.am with the only difference being that I'm shipping the moc files in the tarball. Can I just nuke the moc files in the fedora spec file, and they'll get regenerated at build time? Or should I remove MOCFILES from EXTRA_DIST? Yes. MOC files are generated files like .o files. The difference is that it is generated *source* files. MOC files are with a version of Qt is not guaranted to be usable with another one x.y.z, even if only the .z version number is changed. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages that will be orphaned
On mercredi 22 juin 2011 14:00:40 Jaroslav Reznik wrote: We (as KDE SIG) should probably take care about the rest of K* and Q* apps/libs, I'll talk to guys. knutclient If nobody wants knutclient, I will maintain it. I have an UPS and use nut and knutclient to monitor it. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who broke fedoraproject.org usability?
Le mercredi 27 octobre 2010 18:32:29, Jason L Tibbitts III a écrit : MP == Michał Piotrowski mkkp...@gmail.com writes: MP Where is the link to the wiki? It's in page footer. Actually it's right at the top; click Contributors. (I can't tell you why it's called Contributors but clicking there takes you where you want to go.) With my setup, where fonts are bigger by default, I cannot see the link Contributors (it is behind the div #site-content). I have to decrease the font sizes to see it. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100423 changes
On Friday 23 April 2010 13:07:46 Rawhide Report wrote:
Compose started at Fri Apr 23 08:15:03 UTC 2010
Broken deps for i386
--
[...]
skyviewer-1.0.0-3.fc12.i686 requires libQGLViewer.so.2
Broken deps for x86_64
--
[...]
skyviewer-1.0.0-3.fc12.x86_64 requires libQGLViewer.so.2()(64bit)
Hi, I am the maintainer of libQGLViewer in Fedora.
While trying to upgrade the Rawhide version to last upsteram release (from
2.3.1 to 2.3.5), I have discovered that the upstream developer does not ensure
any binary compatibility between any releases, and the upgrade to 2.3.5 did
break the compatibility!
libQGLViewer build system is qmake (the build system of Qt4), and it hardcodes
that the SONAME of the lirbraries is ${NAME}.so.${MAJVER}, where MAJVER is the
first component of the version number. I have done a quite ugly hack in the
%build and %install parts of the spec file, so that the new SONAME is
libQGLViewer.so.2.3.5 (with full version number).
QUESTION: Knowing that the upstream developer will probably never ensure
binary compatibility, was that the right thing to do?
Before building the new release, I did:
repoquery --requires libQGLViewer.so.2
on my machine, to check if any other package was using it, but I forgot that
on x64 machines there is a suffix in provides/requires, and I had not seen any
dependent package.
QUESTIONS: What is the right way to get skyviewer in Rawhide rebuild against
the last release of libQGLViewer? How should I proceed in future to
synchronize rebuilds of libQGLViewer and packages using it?
I am sorry to ask so naive questions. Because of my daily job being more time-
consuming for one or two years, I have spend less time for Fedora packaging,
and it seems my packaging skills have been outdated while the years passed. I
may have other questions of such kind. May I ask them on this list?
--
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Push an update to F-13
What is the new process to push an update to F-13 between alpha and beta? The packages I have in mind are out of the set of critical packages. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT unusable again
Le samedi 06 février 2010 15:53:03, Stefan Schulze Frielinghaus a écrit : On Sa, 2010-02-06 at 14:08 +0100, Michael Schwendt wrote: [...] I'm happy about every detailed backtrace I get, but I would be even more happy if users contributed a tiny bit more and added comments to their tickets and responded to NEEDINFO queries and gave feedback on Test Updates. ABRT has lowered the hurdle so much that people dump generated reports into bugzilla but otherwise they appear like /dev/null and only show rarely that they care about a package. On the one hand I agree with you on the other hand I see it from an users point of view and feel a bit in a pickle. For example, every second login gnome-panel crashes, removes Gnote from the panel and ABRT shows me a core dump. I cannot reproduce this problem except from a logout and login. So I cannot provide a detailed description what was going on and how to reproduce it (except as I already said: logout and login). But since it crashes that frequently I decided to report it anyway just in the hope that the package maintainer sees from the backtrace what is going wrong. Maybe this is not the best thing to do but after a couple of weeks seeing the red flash light several times a day you go crazy ;-) Same for me. I reported a crash in abrt-gui, without knowing what has caused it, with the hope that the maintainer can understand that from the backtrace. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Sources file audit - 2010-01-06
Le dimanche 10 janvier 2010 08:06:11, Kevin Fenzi a écrit : rineau:BADSOURCE:figtoipe-20080505.tar.gz:figtoipe rineau:BADSOURCE:ipe-6.0pre32patch1-src.tar.gz:ipe Does the change of URLs of Source0 worths a rebuild in Rawhide, or is the cvs commit sufficient? -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
