Re: Attempt to update ispc
On 2019-01-26 12:24 a.m., Dominik 'Rathann' Mierzejewski wrote:
>
> I would try patching out the clang requirement from CMakeLists
> and building with system gcc.
>
> Regards,
> Dominik
Done. Unfortunately, the build failed as the compiler still remains
clang and finding the cause is beyond my knowledge. Here is the resulted
scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32277096
Luya
%global with_snapshot 0
%global commit e338aaaebcf0193e194b13267bc69e7a0ec4fa4d
%global shortcommit %(c=%{commit}; echo ${c:0:7})
Name: ispc
Version: 1.10.0
%if %{with_snapshot}
Release: 0.5.git.20190102.%{shortcommit}%{?dist}
%else
Release: 1%{?dist}
%endif
Summary: C-based SPMD programming language compiler
License: BSD
URL: https://ispc.github.io/
%if %{with_snapshot}
Source0: https://github.com/%{name}/%{name}/archive/%{commit}/%{name}-%{shortcommit}.tar.gz
%else
Source0: https://github.com/%{name}/%{name}/archive/v%{version}/%{name}-%{version}.tar.gz
%endif
BuildRequires: llvm-devel
BuildRequires: clang-devel
BuildRequires: gcc-c++
BuildRequires: cmake
BuildRequires: bison
BuildRequires: doxygen
BuildRequires: flex
BuildRequires: ncurses-devel
ExclusiveArch: %{arm} %{ix86} x86_64
# Hardcoded path from 32-bit glibc-devel needed to build
# See https://github.com/ispc/ispc/wiki/Building-ispc:-Linux-and-Mac-OS-X
%ifarch x86_64
BuildRequires: /usr/lib/crt1.o
%endif
BuildRequires: zlib-devel
# Conditional build for f24 and less
%if 0%{?fedora} < 25 || 0%{?rhel} < 7
BuildRequires: python2-devel
%else
BuildRequires: python3-devel
%endif
# Set verbose compilation and remove -Werror on Makefile
#Patch0: Makefile.patch
#Patch1: 0001-Remove-uses-of-LLVM-dump-functions.patch
%description
A compiler for a variant of the C programming language, with extensions for
"single program, multiple data" (SPMD) programming.
%prep
%if %{with_snapshot}
%autosetup -n %{name}-%{commit}
%else
%autosetup -n %{name}-%{version}
%endif
sed -i 's|set(CMAKE_C_COMPILER "clang")|set(CMAKE_C_COMPILER "gcc")|g' CMakeLists.txt
sed -i 's|set(CMAKE_CXX_COMPILER "clang++")|set(CMAKE_CXX_COMPILER "g++")|g' CMakeLists.txt
%build
mkdir build
pushd build
# Disable test otherwise build fails
%cmake -DISPC_INCLUDE_TESTS=OFF \
..
popd
%make_build
%install
install -Dpm 0755 %{name} %{buildroot}%{_bindir}/%{name}
%files
%license LICENSE.txt
%{_bindir}/%{name}
%changelog
* Sat Jan 19 2019 Luya Tshimbalanga - 1.10.0
- Update to 1.10.0
* Wed Dec 26 2018 Luya Tshimbalanga - 1.9.3-0.5.git.20190102.e338aaa
- Git snasphot 20190102
* Wed Dec 26 2018 Luya Tshimbalanga - 1.9.3-0.4.git.20181220.1e4bfb7
- Git snasphot 20181220
* Tue Nov 06 2018 Luya Tshimbalanga - 1.9.3-0.3.git.20181106.3d846b
- Git snasphot 1.9.3
* Fri Jul 13 2018 Fedora Release Engineering - 1.9.3-0.3.git.20180222.07fe054
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Thu Mar 15 2018 Iryna Shcherbina - 1.9.3-0.2.git.20180222.07fe054
- Update Python 2 dependency declarations to new packaging standards
(See https://fedoraproject.org/wikiComponents/FinalizingFedoraSwitchtoPython3)
* Sat Mar 03 2018 Luya Tshimbalanga - 1.9.3-0.1.git.20180222.07fe054
- Update to 1.9.3 git snapshot
- Use new guideline versioning semantique for snapshot
* Fri Mar 02 2018 Luya Tshimbalanga - 1.9.2-1
- Update to 1.9.2
* Wed Feb 07 2018 Fedora Release Engineering - 1.9.1-18.git.20171023.6dc0ccc
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Tue Oct 24 2017 Tom Stellard - 1.9.1-17.git.20171023.6dc0ccc
- Rebase to more current snapshot for LLVM 5.0 support.
* Wed Aug 02 2017 Fedora Release Engineering - 1.9.1-16.git.20170324.a618ad4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild
* Wed Jul 26 2017 Fedora Release Engineering - 1.9.1-15.git.20170324.a618ad4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
* Thu May 25 2017 Peter Robinson 1.9.1-14.git.20170324.a618ad4
- Rebuild clang/llvm-4
* Mon May 15 2017 Fedora Release Engineering - 1.9.1-13.git.20170324.a618ad4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_27_Mass_Rebuild
* Fri Mar 24 2017 Igor Gnatenko - 1.9.1-12.git.20170324.a618ad4
- Update to git snapshot which support LLVM4
* Thu Mar 16 2017 Luya Tshimbalanga - 1.9.1-11
- Rebuild for llvm 3.9
* Fri Feb 10 2017 Fedora Release Engineering - 1.9.1-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
* Sun Nov 06 2016 Luya Tshimbalanga - 1.9.1-9
- Rebuilt agaisnt llvm
* Fri Aug 26 2016 Dan Horák 1.9.1-8
- set ExclusiveArch
* Tue Aug 23 2016 Luya Tshimbalanga 1.9.1-7
- Added conditional build for Fedora 24- and rhel7-
* Tue Aug 23 2016 Luya Tshimbalanga 1.9.1-6
- Included OPT and LDFLAGS on build line
* Tue Aug 23 2016 Luya Tshimbalanga 1.9.1-5
- Improved patch to remove -Werror line
- Removed unecesary CXXFLAGS and LDFLAGS on make_build line
- Removed useless llvm-config
* Sat Aug 20 2016 Luya Tshimbalanga 1.9.1-4
- Added gcc into mak
%find_lang for non-standard locations
Hi, The general guidelines currently state that translations should be found using %find_lang; this macro provides a listing of all *.mo files but not their containing directories. Specifying just the files makes sense when they are in the global location (/usr/share/locale), but not so much when they are in, e.g., the Python site-packages directories. For example, python3-humanize currently lists: /usr/lib/python3.7/site-packages/humanize ... /usr/lib/python3.7/site-packages/humanize/locale/fr_FR/LC_MESSAGES/humanize.mo /usr/lib/python3.7/site-packages/humanize/locale/ko_KR/LC_MESSAGES/humanize.mo /usr/lib/python3.7/site-packages/humanize/locale/ru_RU/LC_MESSAGES/humanize.mo but *not* the humanize/locale or humanize/locale/* directories. So when you uninstall python3-humanize, you are left with the /usr/lib/python3.7/site-packages/humanize/locale/*/LC_MESSAGES/ directories. I see three ways forward: 1. Teach %find_lang to add directories if it's not in /usr/share/locale 2. Tell packagers to explicitly include the directories is not in /usr/share/locale 3. Stop recommending %find_lang if it serves no other purpose than to just list files (I *think* multiple packages owning directories is no longer an issue?) I'd lean towards 1 as I think 2 is just unnecessary extra work and the condition in 3 is not probably true. -- Elliott ___ 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
Re: F30 Self-Contained Change proposal: Bash 5.0
On Sat, Jan 26, 2019 at 12:05 PM Dominik 'Rathann' Mierzejewski wrote: > > On Saturday, 26 January 2019 at 17:15, John Reiser wrote: > [...] > > Already bash-5.0 has two official patches in three weeks. The first one > > fixes a bug in glob filename expansion. Use of globbing is almost > > universal, > > but the test cases did not catch the bug before release of bash-5.0. > > Often that is an indication that more bugs should be expected. > > > > The risk may be large. *EVERY* Fedora package uses bash. > > rpm .spec file sections such as %build, %install, %clean, %post use /bin/sh, > > and Fedora links /bin/sh -> bash. That surely is "system-wide". > > +1. > > Upgrading the default system shell should be treated similarly to > upgrading glibc. A System-Wide Change is definitely in order. > > Regards, > Dominik It's also only been released for barely 2 weeks, it's marked as a major revision number, and it seems a bit late to accept for Fedora 30. Mark it as a candidate for Fedora 31, and move on? ___ 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
Re: [Late] F30 System-Wide Change proposal: GCC9
Thank you two for the answer. YOUNG, MICHAEL A. wrote on Sat, Jan 26, 2019 at 12:53:18PM +: > The problem is your gcc build requires libgcc_s.so.1 which is the i386 > version; the x86_64 version is libgcc_s.so.1()(64bit) . So something has > gone wrong in your build process. Eh, even after reading this I was doubting you, but that appears to be true... I guess asking rpm to add a couple of parenthesis after 32bit lib requires to at least look like 64bit libs require and not a simple file require would be asking too much, I never noticed it worked like this for 32bit libs :/ And rightly enough rpm -qp --requires of "my" gcc does have both libgcc_s.so.1 while fc30's libgcc.x86_64 only requires the x86_64 version; interesting given the src.rpm is the same. I've extracted the rpm and am not quite sure where the auto requires comes from, actually? I thought there was a script doing basically ldd on each executable (as described on the rpm website[1]), but nothing in the gcc package seems to require libgcc_s - what am I missing? I can't see anything obviously different between both build logs, either copr's[2] or koji's[3] (caution: files are 10MB (compressed) and 55MB respectively); the logs are too different to diff because of parallel build but at least lines containing "libgcc_s" are similar enough... [1] http://ftp.rpm.org/max-rpm/s1-rpm-depend-auto-depend.html [2] https://copr-be.cloud.fedoraproject.org/results/martinetd/gcc9/fedora-29-x86_64/00850190-gcc/build.log.gz [3] https://kojipkgs.fedoraproject.org//packages/gcc/9.0.1/0.1.fc30/data/logs/x86_64/build.log Will look into how autodepends works a bit more, I'm curious why this is different. Thanks, -- Dominique ___ 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
Re: Looking to give these packages new maintainers
On Saturday, 26 January 2019 at 10:34, Ankur Sinha wrote: > Hi Dominik, Fabio, > > On Sat, Jan 26, 2019 10:06:13 +0100, Fabio Valentini wrote: > > You can count me in for those two packages as well (gitg, libgexiv2). > > I use gitg regularly, and libgexiv2 is a dependency of one of my packages, > > too. > > I've now added you both as admins to these packages (and removed > myself). > > Thanks very much :) Great, thanks Ankur and Fabio! Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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
Re: F30 Self-Contained Change proposal: Bash 5.0
On Saturday, 26 January 2019 at 17:15, John Reiser wrote: [...] > Already bash-5.0 has two official patches in three weeks. The first one > fixes a bug in glob filename expansion. Use of globbing is almost universal, > but the test cases did not catch the bug before release of bash-5.0. > Often that is an indication that more bugs should be expected. > > The risk may be large. *EVERY* Fedora package uses bash. > rpm .spec file sections such as %build, %install, %clean, %post use /bin/sh, > and Fedora links /bin/sh -> bash. That surely is "system-wide". +1. Upgrading the default system shell should be treated similarly to upgrading glibc. A System-Wide Change is definitely in order. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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
Re: [HEADS UP] Rebasing to Readline-8.0 in rawhide
- Original Message - > From: "Jason L Tibbitts III" > To: "Siteshwar Vashisht" > Cc: "Development discussions related to Fedora" > > Sent: Thursday, January 24, 2019 6:54:59 PM > Subject: Re: [HEADS UP] Rebasing to Readline-8.0 in rawhide > > SV> Readline-8.0 was released earlier this month[1]. I am going to > SV> rebase it in rawhide in couple of weeks. > > Note that a couple of things break in weird ways every time readline gets a > new > major version. For me that's the command line editing functionality of > the kerberos tools like kadmin. The root cause of this is something > called "libss" which is part of e2fsprogs (!). It tries to abstract > readline functionality and has a hardcoded list of libraries that it > looks for: > > get_readline.c:#define DEFAULT_LIBPATH > "libreadline.so.7:libreadline.so.6:libreadline.so.5:libreadline.so.4:libreadline.so:libedit.so.2:libedit.so:libeditline.so.0:libeditline.so" > > Could you work with the e2fsprogs maintainer to make sure that libss > continues to work as expected? I would do that. I will also provide a compatibility package for readline 7. > > Thanks, > > - J< > ___ > 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 > -- -- Siteshwar Vashisht ___ 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
Re: F30 Self-Contained Change proposal: Bash 5.0
On 1/25/19 15:27 UTC, Neal Gompa wrote: On Fri, Jan 25, 2019 at 10:17 AM Frantisek Zatloukal wrote: Why is this Self-Contained Change and not a System Wide Change? It seems, at least to me, that it should be System Wide Change, according to https://fedoraproject.org/wiki/Changes/Policy#Complex_system_wide_changes . Is it really that complicated? It's just a readline bump and bash itself getting bumped. From the Fedora perspective, it means we get to drop a whole bunch of patches we were already carrying since they are part of the 5.0 release. Yes, it is that complicated. "git diff --stat bash-4.4 bash-5.0" shows 528 files changed, 81767 insertions(+), 63829 deletions(-) in the 2 years and 3 months between releases. Some of the changes are included in Fedora's bash-4.4.3-23.1 but some are not. From the shell script language point of view, there is only one notable backwards incompatible change: a behavior change to namerefs, which are not commonly used at all. Already bash-5.0 has two official patches in three weeks. The first one fixes a bug in glob filename expansion. Use of globbing is almost universal, but the test cases did not catch the bug before release of bash-5.0. Often that is an indication that more bugs should be expected. The risk may be large. *EVERY* Fedora package uses bash. rpm .spec file sections such as %build, %install, %clean, %post use /bin/sh, and Fedora links /bin/sh -> bash. That surely is "system-wide". -- [[signature snipped]] ___ 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
Re: [Late] F30 System-Wide Change proposal: GCC9
On Sat, 26 Jan 2019, Dominique Martinet wrote: > Jonathan Wakely wrote on Fri, Jan 25, 2019 at 05:06:09PM +: >>> I think it would help having more people test things, and if there are >>> build failures would help package owners fix these - it's not always >>> obvious to fix a build failure by repeatedly submitting a new package to >>> build, and everyone doesn't have a rawhide install around. >> >> That's what 'mock' is for. > > Sure, I guess that was a bad argument; as I said I'm not maintaining > packages so I can't do that for the tools where I'd have liked to test > the new gcc. > >>> It's probably just me being lazy, though; I'll figure something out if >>> there is no such plan :) >> >> It's really easy to build it yourself: >> https://gcc.gnu.org/wiki/InstallingGCC >> >> Installing binutils is also simple. Build binutils and install it >> first, then build GCC to use the same prefix as you installed binutils >> to, and the new GCC will automatically use the new GCC. > > Sure, building a new toolchain is easy; that's one of the many > possibilities there are to test it. > One could also just use `dnf --installroot=/tmp/foo --releasever=30 > isntall gcc` to pop a new chroot, or install rawhide in a VM, but all of > these solutions take disk space and aren't systematically used when > building stuff so it makes the testing a much more conscious action than > just install some rpm and start using it. > (yes, if I build a toolchain I could just add it to my PATH and it would > just work as well; as I said, I'm just lazy.) > > > Honestly, I also figured dropping the existing fc30 srpm for gcc > followed by libtools and friends in a fc29 copr would be even simpler > for everyone - copr really is a great tool to test new utility versions, > and most of the time it just works. > > Turns out I wasn't correct here as for some reason gcc9 does build fine > but I can't get it to install in a chroot, feel free to try my attempt > if you can figure why: > https://copr.fedorainfracloud.org/coprs/martinetd/gcc9/ > > I could upgrade libgcc/libgomp/libstdc++ (in a chroot without gcc) but > trying to install gcc itself yields: > Problem: package gcc-9.0.1-0.1.fc29.x86_64 requires libgcc_s.so.1, but none > of the providers can be installed > - libgcc-8.2.1-6.fc29.i686 has inferior architecture > - libgcc-8.2.1-2.fc29.i686 has inferior architecture > - cannot install both libgcc-8.2.1-6.fc29.x86_64 and > libgcc-9.0.1-0.1.fc29.x86_64 > - cannot install both libgcc-8.2.1-2.fc29.x86_64 and > libgcc-9.0.1-0.1.fc29.x86_64 > - package gcc-9.0.1-0.1.fc29.x86_64 requires libgcc >= 9.0.1-0.1.fc29, but > none of the providers can be installed > - cannot install the best candidate for the job > > while it really looks to me that it should be provided by the newer > libgcc? > # rpm -q --provides libgcc > libgcc = 9.0.1-0.1.fc29 > libgcc(x86-64) = 9.0.1-0.1.fc29 > libgcc_s.so.1()(64bit) > libgcc_s.so.1(GCC_3.0)(64bit) > libgcc_s.so.1(GCC_3.3)(64bit) > libgcc_s.so.1(GCC_3.3.1)(64bit) > libgcc_s.so.1(GCC_3.4)(64bit) > libgcc_s.so.1(GCC_3.4.2)(64bit) > libgcc_s.so.1(GCC_3.4.4)(64bit) > libgcc_s.so.1(GCC_4.0.0)(64bit) > libgcc_s.so.1(GCC_4.2.0)(64bit) > libgcc_s.so.1(GCC_4.3.0)(64bit) > libgcc_s.so.1(GCC_4.7.0)(64bit) > libgcc_s.so.1(GCC_4.8.0)(64bit) > libgcc_s.so.1(GCC_7.0.0)(64bit) > > So, meh, I'll probably pick something else but I don't like not > understanding why something doesn't work. The problem is your gcc build requires libgcc_s.so.1 which is the i386 version; the x86_64 version is libgcc_s.so.1()(64bit) . So something has gone wrong in your build process. Michael Young ___ 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
Re: Looking to give these packages new maintainers
I'd like to become a co-maintainer for openarena. My FAS username: suve A.I. ___ 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
Re: The "see-also" field in bugzilla
On Sat, 2019-01-26 at 10:52 +, Ankur Sinha wrote: > Hello, > > I'd filed a ticket about renaming "External trackers" to something more > appropriate, and upstream has requested feedback on the ticket now[1]. > Please comment in with your views there. > > https://bugzilla.redhat.com/show_bug.cgi?id=1666266 It's not just about the name, though. It's about the functionality. "External trackers" does not automatically backlink. Also, the removal of "See also" means that all *existing* "See also" links went away; they were not automatically converted to 'External tracker' entries or anything. I had created dozens over the years. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Looking to give these packages new maintainers
> On 26. Jan 2019, at 12:15, Benjamin Kircher > wrote: > > > >> On 24. Jan 2019, at 12:19, Ankur Sinha wrote: >> >> Hello, >> >> I'm trying to focus my rather limited free time on neurofedora[1]. >> So, I'd like to pass on a number of packages that I no longer use to >> maintainers who would give them the required attention. >> >> A few of them were inactive upstream so I have orphaned them. A few of >> the rest already have co-maintainers, but more are welcome. I intend to >> remove myself from them at the end of the month (31st). The ones that >> have no co-maintainers until then will be orphaned. >> >> Orphaned (inactive upstreams or retired due to broken deps) >> - albumart: was retired, now orphaned >> - gtg: inactive upstream >> - labyrinth: inactive upstream >> - memaker: inactive upstream >> - pyode: dead package, py3ode is available but needs packaging >> - python-inlinestyler: retired, now orphaned >> - scout: inactive upstream >> - toothchart: inactive upstream >> - xword: inactive upstream >> >> Looking for new (co)-maintainers: >> - axel: Light command line download accelerator >> - bibus: The bibus rpms >> - blobby: The blobby rpms >> - dcm4che-test: The dcm4che-test rpms >> - gitg: The gitg rpms >> - gnote: A note taking application for Gnome >> - gnumed: The GNUmed electronic medical record client >> - gtg: Getting Things GNOME! >> - hamster-time-tracker: A GTK3 time tracker >> - jigdo: The jigdo rpms >> - kapow: The kapow rpms >> - libgexiv2 A GObject wrapper around the Exiv2 photo metadata library >> - lifeograph: The lifeograph rpms >> - lingot: LINGOT Is Not a Guitar-Only Tuner >> - mrpt: The mrpt rpms >> - nautilus-pastebin: The nautilus-pastebin rpms >> - nut-nutrition: The nut-nutrition rpms >> - openarena: The openarena rpms >> - openmolar: The openmolar rpms >> - OSGi-bundle-ant-task: The OSGi-bundle-ant-task rpms >> - Panini: Visual tool for creating perspective views from panoramic and wide >> angle photographs >> - prepaid-manager-applet: The prepaid-manager-applet rpms >> - pystache: The pystache rpms >> - python-baker: The python-baker rpms >> - python-django-post_office: The python-django-post_office rpms >> - python-django-stopforumspam >> - python-uri-templates: The python-uri-templates rpms >> - rssdler: RSS Broadcatcher for podcasts, videocasts, and torrent feeds >> - tagtool: The tagtool rpms >> - trash-cli: Command line interface to the freedesktop.org trashcan >> - xmedcon: The xmedcon rpms >> >> >> [1] https://neuro.fedoraproject.org > > > Hi, > > you can add me to trash-cli if you like. I use it quite heavily. Sorry, forgot to mention my Fedora ID: bkircher BK ___ 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
Re: Looking to give these packages new maintainers
> On 24. Jan 2019, at 12:19, Ankur Sinha wrote: > > Hello, > > I'm trying to focus my rather limited free time on neurofedora[1]. > So, I'd like to pass on a number of packages that I no longer use to > maintainers who would give them the required attention. > > A few of them were inactive upstream so I have orphaned them. A few of > the rest already have co-maintainers, but more are welcome. I intend to > remove myself from them at the end of the month (31st). The ones that > have no co-maintainers until then will be orphaned. > > Orphaned (inactive upstreams or retired due to broken deps) > - albumart: was retired, now orphaned > - gtg: inactive upstream > - labyrinth: inactive upstream > - memaker: inactive upstream > - pyode: dead package, py3ode is available but needs packaging > - python-inlinestyler: retired, now orphaned > - scout: inactive upstream > - toothchart: inactive upstream > - xword: inactive upstream > > Looking for new (co)-maintainers: > - axel: Light command line download accelerator > - bibus: The bibus rpms > - blobby: The blobby rpms > - dcm4che-test: The dcm4che-test rpms > - gitg: The gitg rpms > - gnote: A note taking application for Gnome > - gnumed: The GNUmed electronic medical record client > - gtg: Getting Things GNOME! > - hamster-time-tracker: A GTK3 time tracker > - jigdo: The jigdo rpms > - kapow: The kapow rpms > - libgexiv2 A GObject wrapper around the Exiv2 photo metadata library > - lifeograph: The lifeograph rpms > - lingot: LINGOT Is Not a Guitar-Only Tuner > - mrpt: The mrpt rpms > - nautilus-pastebin: The nautilus-pastebin rpms > - nut-nutrition: The nut-nutrition rpms > - openarena: The openarena rpms > - openmolar: The openmolar rpms > - OSGi-bundle-ant-task: The OSGi-bundle-ant-task rpms > - Panini: Visual tool for creating perspective views from panoramic and wide > angle photographs > - prepaid-manager-applet: The prepaid-manager-applet rpms > - pystache: The pystache rpms > - python-baker: The python-baker rpms > - python-django-post_office: The python-django-post_office rpms > - python-django-stopforumspam > - python-uri-templates: The python-uri-templates rpms > - rssdler: RSS Broadcatcher for podcasts, videocasts, and torrent feeds > - tagtool: The tagtool rpms > - trash-cli: Command line interface to the freedesktop.org trashcan > - xmedcon: The xmedcon rpms > > > [1] https://neuro.fedoraproject.org Hi, you can add me to trash-cli if you like. I use it quite heavily. BK ___ 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
Re: The "see-also" field in bugzilla
Hello, I'd filed a ticket about renaming "External trackers" to something more appropriate, and upstream has requested feedback on the ticket now[1]. Please comment in with your views there. https://bugzilla.redhat.com/show_bug.cgi?id=1666266 -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ 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
btrfs-heatmap changed license
This is a heads up for the license change of btrfs-heatmap, it is now MIT (it was GPLv2 previously). ___ 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
Re: [Late] F30 System-Wide Change proposal: GCC9
Jonathan Wakely wrote on Fri, Jan 25, 2019 at 05:06:09PM +: >> I think it would help having more people test things, and if there are >> build failures would help package owners fix these - it's not always >> obvious to fix a build failure by repeatedly submitting a new package to >> build, and everyone doesn't have a rawhide install around. > > That's what 'mock' is for. Sure, I guess that was a bad argument; as I said I'm not maintaining packages so I can't do that for the tools where I'd have liked to test the new gcc. > >It's probably just me being lazy, though; I'll figure something out if > >there is no such plan :) > > It's really easy to build it yourself: > https://gcc.gnu.org/wiki/InstallingGCC > > Installing binutils is also simple. Build binutils and install it > first, then build GCC to use the same prefix as you installed binutils > to, and the new GCC will automatically use the new GCC. Sure, building a new toolchain is easy; that's one of the many possibilities there are to test it. One could also just use `dnf --installroot=/tmp/foo --releasever=30 isntall gcc` to pop a new chroot, or install rawhide in a VM, but all of these solutions take disk space and aren't systematically used when building stuff so it makes the testing a much more conscious action than just install some rpm and start using it. (yes, if I build a toolchain I could just add it to my PATH and it would just work as well; as I said, I'm just lazy.) Honestly, I also figured dropping the existing fc30 srpm for gcc followed by libtools and friends in a fc29 copr would be even simpler for everyone - copr really is a great tool to test new utility versions, and most of the time it just works. Turns out I wasn't correct here as for some reason gcc9 does build fine but I can't get it to install in a chroot, feel free to try my attempt if you can figure why: https://copr.fedorainfracloud.org/coprs/martinetd/gcc9/ I could upgrade libgcc/libgomp/libstdc++ (in a chroot without gcc) but trying to install gcc itself yields: Problem: package gcc-9.0.1-0.1.fc29.x86_64 requires libgcc_s.so.1, but none of the providers can be installed - libgcc-8.2.1-6.fc29.i686 has inferior architecture - libgcc-8.2.1-2.fc29.i686 has inferior architecture - cannot install both libgcc-8.2.1-6.fc29.x86_64 and libgcc-9.0.1-0.1.fc29.x86_64 - cannot install both libgcc-8.2.1-2.fc29.x86_64 and libgcc-9.0.1-0.1.fc29.x86_64 - package gcc-9.0.1-0.1.fc29.x86_64 requires libgcc >= 9.0.1-0.1.fc29, but none of the providers can be installed - cannot install the best candidate for the job while it really looks to me that it should be provided by the newer libgcc? # rpm -q --provides libgcc libgcc = 9.0.1-0.1.fc29 libgcc(x86-64) = 9.0.1-0.1.fc29 libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libgcc_s.so.1(GCC_3.3)(64bit) libgcc_s.so.1(GCC_3.3.1)(64bit) libgcc_s.so.1(GCC_3.4)(64bit) libgcc_s.so.1(GCC_3.4.2)(64bit) libgcc_s.so.1(GCC_3.4.4)(64bit) libgcc_s.so.1(GCC_4.0.0)(64bit) libgcc_s.so.1(GCC_4.2.0)(64bit) libgcc_s.so.1(GCC_4.3.0)(64bit) libgcc_s.so.1(GCC_4.7.0)(64bit) libgcc_s.so.1(GCC_4.8.0)(64bit) libgcc_s.so.1(GCC_7.0.0)(64bit) So, meh, I'll probably pick something else but I don't like not understanding why something doesn't work. -- Dominique ___ 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
Re: Looking to give these packages new maintainers
Hi Dominik, Fabio, On Sat, Jan 26, 2019 10:06:13 +0100, Fabio Valentini wrote: > You can count me in for those two packages as well (gitg, libgexiv2). > I use gitg regularly, and libgexiv2 is a dependency of one of my packages, > too. I've now added you both as admins to these packages (and removed myself). Thanks very much :) -- Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ 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
Re: Looking to give these packages new maintainers
On Sat, Jan 26, 2019 at 12:52 AM Dominik 'Rathann' Mierzejewski wrote: > > On Thursday, 24 January 2019 at 12:19, Ankur Sinha wrote: > > Hello, > > > > I'm trying to focus my rather limited free time on neurofedora[1]. > > So, I'd like to pass on a number of packages that I no longer use to > > maintainers who would give them the required attention. > > > > A few of them were inactive upstream so I have orphaned them. A few of > > the rest already have co-maintainers, but more are welcome. I intend to > > remove myself from them at the end of the month (31st). The ones that > > have no co-maintainers until then will be orphaned. > [...] > > Looking for new (co)-maintainers: > [...] > > - gitg: The gitg rpms > > I use it quite often. I'll adopt it so that it doesn't get retired. > Co-maintainers welcome! > > [...] > > - libgexiv2 A GObject wrapper around the Exiv2 photo metadata library > > This is a dependency of one of my packages. I'll adopt it so it doesn't > get retired. You can count me in for those two packages as well (gitg, libgexiv2). I use gitg regularly, and libgexiv2 is a dependency of one of my packages, too. Fabio > Regards, > Dominik > -- > Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org > There should be a science of discontent. People need hard times and > oppression to develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan > ___ > 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 ___ 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
Re: Attempt to update ispc
On Saturday, 26 January 2019 at 02:20, Luya Tshimbalanga wrote: > On 2019-01-25 9:02 a.m., Jonathan Wakely wrote: > > > >> Upstream reason. Trying to build with gcc will fail. See the attacked > >> CMakeLists.txt from ispc-1.10.0 > > > > That says it wants to build with clang, but doesn't say why building > > with GCC will fail. Is it due to a GCC bug? Is it something we can > > fix? > > > My bad as I quickly wrote before leaving to work. Here is the updated > spec file and the result scratch build: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=32250196 Well, obviously existing CMakeLists file enforces the use of clang. The developers seem to have a strong preference for clang. The issue tracker has a couple of closed issues around this topic: https://github.com/ispc/ispc/issues/1355 https://github.com/ispc/ispc/issues/1352 I would try patching out the clang requirement from CMakeLists and building with system gcc. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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
