Error in the packaging of fftw-devel-3.3.10-3.fc37.x86_64

    Hi, There seem to be some missing files in this package related to the cmake configuration. Trying to detect fftw3 with cmake induces an error: CMake Error at /usr/lib64/cmake/fftw3/FFTW3Config.cmake:13 (include):    include could not find requested file:

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

On 7/6/22 08:30, Vitaly Zaitsev via devel wrote: On 05/07/2022 21:15, Matthias Clasen wrote: And I doubt that you'd be able to notice a 'smaller than 1% slowdown' on your system. 4% slowdown is unacceptable. At least for Fedora Workstation, being a useful system for developers with working

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

On 6/26/20 1:30 PM, Qiyu Yan wrote: > > > Adam Williamson > 于 2020年6月26日周五 上午9:32写道： > > On Fri, 2020-06-26 at 08:44 +0800, Qiyu Yan wrote: > > What about to provide a prompt to the user telling them the difference > > between editors? > > For

Re: Self Introduction: Theo Papadopoulo

On 12/5/19 2:50 PM, Theodore Papadopoulo wrote: > Hello, > > My name is Theo Papadopoulo. I use linux based systems since 1996 and > redhat/fedora ones since so long I do not quite remember (2005-2007?). > Fedora is used within the research group (and actually with the resea

Self Introduction: Theo Papadopoulo

Hello, My name is Theo Papadopoulo. I use linux based systems since 1996 and redhat/fedora ones since so long I do not quite remember (2005-2007?). Fedora is used within the research group (and actually with the research institute where I am) I belong to as the main computing platform.

Re: Unorphan instructions

On 12/4/19 12:11 PM, Miro Hrončok wrote: > On 04. 12. 19 11:28, Fabio Valentini wrote: >> Doesn't the new "Take" button at >> https://src.fedoraproject.org/rpms/eclipse-avr work, so we don't have >> to bother releng anymore? >> It's at the bottom of the left navigation area. > > I have updated

Destop environment and gl performance...

Can someone explain why the destop environment (here Cinnamon) can have such an impact on the graphic card performance ? Using glmark, we see a 2x to 20x factor in glmark performance between various destops (mate,xlfce,cinnamon). What can justify such a huge gap in perfs ? Even better is

Packaging problem in pybind11-devel ?

Before submitting a bugzilla, I wonder whether this is a choice made on purpose or not. The pybind11-devel package defines a set of CMake Module files. But (at least for fedora 29) these files do not end up in /usr/share/cmake/Modules as usually but in /usr/share/cmake/pybind11 where cmake does

Re: /etc/yum.repos.d -> /etc/distro.repos.d

On 3/13/19 4:03 PM, mcatanz...@gnome.org wrote: > On Wed, Mar 13, 2019 at 7:50 AM, Kalev Lember > wrote: >> Please don't, it's just pointless renaming that invalidates all end user >> documentation and makes it harder for other programs such as packagekit >> and gnome-software that all need to

JSharing some poor experience

Hello, I recently upgraded my computer to Fedora 28 and experienced some strange behaviour with the cinnamon deskop when having two screens. On the second screen there was a black "border" around windows (eg terminals) that was flickering and expanding eg when the mouse was moving

Re: Unretiring itpp

ING %{_libdir}/*.so.* %{_datadir}/%{name} %files devel %{_includedir}/%{name} %{_libdir}/*.so %{_libdir}/pkgconfig/%{name}.pc %{_bindir}/%{name}-config %{_mandir}/man1/* %files doc %dir %{_docdir}/%{name} %{_docdir}/%{name}/html/ %changelog * Sun Jan 22 2017 Theodore Papadopoulo <theodore.pa

Re: Unretiring itpp

On 01/22/2017 08:11 PM, Alexander Ploumistos wrote: > Almost there, still some light reading ahead: > http://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs > > You need to amend your changelog entry heading to match one of the > styles mentioned there, the most common being > > * Sun Jan

Re: Unretiring itpp

OK. Thank's for the quick reply. Here is the updated spec. On 01/22/2017 04:01 PM, Alexander Ploumistos wrote: > On Sun, Jan 22, 2017 at 4:31 PM, Theodore Papadopoulo > <theodore.papadopo...@inria.fr> wrote: >> OK, I hope I have taken into acount of all suggestions except one (

Re: Unretiring itpp

OK, I hope I have taken into acount of all suggestions except one (I found nothing on %licence in %files). For now I have made the 4.3.1+patch version as the git repo, while it indeed solves the place where are installed libraries, does not put correct values in itpp-config and itpp.pc. Beside the

Re: Unretiring itpp

On 01/20/2017 07:50 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Jan 20, 2017 at 02:32:22AM +0100, Kevin Kofler wrote: >> Theodore Papadopoulo wrote: >>> The only problem is that libraries got installed (as usual with cmake) in >>> /usr/lib and no

Re: Unretiring itpp

On 01/19/2017 01:38 AM, Michael Schwendt wrote: >> Provided I get some guidance (or readings, account settings, ...), I >> ciuld maintain or co-maintain the package if necessary. > [...] > https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text > > >> %{_bindir}/%{name}-config

Re: Unretiring itpp

Thank's a lot for the review. I will analyze all your comments and produce an updated spec file. I need some time to understand the references you sent. Thank's again. Theo. On 01/19/2017 01:38 AM, Michael Schwendt wrote: >> Provided I get some guidance (or readings, account

Re: Unretiring itpp

On 01/18/2017 07:01 PM, Jon Ciesla wrote: > > It will need to be re-reviewed, since it's been retired more than two weeks. Of course... Theo. signature.asc Description: OpenPGP digital signature ___ devel mailing list --

Unretiring itpp

Hi, I'd like to unretire itpp(which was retired on 2011-07-25 due to constant C++ build problems). It seems that those problems have been solved and that as of (at least) itpp-4.3.1, it now correctly builds. Basically I recovered the last spec from fedpkgs and adapted it to cmake (which

Re: RFC: Change the default hostname for Fedora 26+

On 11/09/2016 02:32 PM, Matthew Miller wrote: > On Tue, Nov 08, 2016 at 03:25:58PM -0800, Andrew Lutomirski wrote: >> If the hostname is non-constant, can we also arrange that, by default, >> this hostname is never sent over the network? In particular, I think >> that DHCP requests should *not*

Re: DNF and PackageKit background data usage

On 11/05/2016 05:01 AM, Kevin Kofler wrote: > Theodore Papadopoulo wrote: >> Add to this that these caches seem to be never cleaned, so that they >> grow up very large up to the point they prevent updating the system. I >> just found that the packagekit cache on my

Re: DNF and PackageKit background data usage

On 10/31/2016 05:10 PM, Adam Williamson wrote: > On Mon, 2016-10-31 at 15:09 +, Richard Hughes wrote: >> >> I think this kind of issue is really fixed the hard way, i.e. fixing >> bugs and adding unimplemented features rather than just adding complex >> UI workarounds. > > I think making it

Re: DNF and PackageKit background data usage

On 10/30/2016 02:26 AM, Adam Williamson wrote: > There's two things I think are somewhat unfortunate here: > > 1) Both dnf and GNOME Software / PackageKit default to performing > fairly data-hungry transactions in the background, out of the box, > without telling you about it. GNOME's is

Re: DNF and PackageKit background data usage

On 10/30/2016 02:26 AM, Adam Williamson wrote: > * We could have some kind of configuration interface appear on install > / first boot. This would require integration with anaconda and/or > initial-setup and gnome-initial-setup. > > * We could invert the defaults and have the apps ask the user

Re: Specifying arch in comps/yumgroups.xml

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/11/2011 04:31 AM, Kevin Kofler wrote: Theodore Papadopoulo wrote: I'm playing with comps to install software. I'm mostly in an x86-64 environment, but for compatibility I need some i386 packages... but those seem to be invisible and I find

Specifying arch in comps/yumgroups.xml

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm playing with comps to install software. I'm mostly in an x86-64 environment, but for compatibility I need some i386 packages... but those seem to be invisible and I find no syntax that make them visible... And there seems to be no