Re: koji build failure

Dne 7.2.2018 v 06:32 Kalev Lember napsal(a): > On 02/07/2018 06:17 AM, Dave Young wrote: >> - nothing provides /usr/bin//usr/bin/python3 needed by >> glib2-devel-2.55.2-1.fc28.x86_64 > Looks like something gone wrong with new brp-mangle-shebangs script in > redhat-rpm-config. I've disabled it

Re: cmake, mc unresponsive packagers

On 30 January 2018 at 21:32, Tomasz Kłoczko wrote: > https://fedoraproject.org/wiki/Policy_for_nonresponsive_ > package_maintainers > [..] > cmake: > https://src.fedoraproject.org/rpms/cmake/pull-request/2 > https://bugzilla.redhat.com/show_bug.cgi?id=1530574 > > mc > https://bugzilla.redh

Re: cmake, mc unresponsive packagers

On 08/02/2018 13:06, Tomasz Kłoczko wrote: > On 30 January 2018 at 21:32, Tomasz Kłoczko > wrote: > > > https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers > >

Re: Pull requests for compat-gcc-34

On 08/02/18 01:31 +0100, Rafal Luzynski wrote: 7.02.2018 14:58 Jonathan Wakely wrote: On 07/02/18 02:09 +0100, Rafal Luzynski wrote: >[...] >Also, just to clarify: I still don't know whether it is correct to just >bump the required version of libstdc++, I just bump it because it has been >done

Re: cmake, mc unresponsive packagers

On 8 February 2018 at 12:12, Jindrich Novy wrote: > Hi Tomasz, > > Haven't I granted you commit access and co-maintenance rights few days ago > for mc? > In prv email you asked me "Do you wish to become mc maintainer?" and you should have my positive reply on this question. Because in this email

Clean up your spec files

Hi, I am sometimes reviewing spec files and I very often see common mistakes. I mean in packages which are already in Fedora. For a long time and they have some dust from past times. I am not going to file bug reports as those are not bugs. I will just point it here and leave it up to you to che

Re: cmake, mc unresponsive packagers

On 08/02/2018 13:14, Antonio Trande wrote: > On 08/02/2018 13:06, Tomasz Kłoczko wrote: >> On 30 January 2018 at 21:32, Tomasz Kłoczko > > wrote: >> >> >> https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers >> >>

Re: Clean up your spec files

Miroslav thank you for the hints, I will check my packages, but I think Igor Gnatenko already removed such stuff because he made a quick review of them. I would also say that we should increase the usage of *comments* in spec files because they are very useful for new packagers

glibc, riscv64, multilib, /lib64 etc

It looks as if upstream RISC-V / glibc teams settled on some exciting new paths to use for libc.so.6: https://sourceware.org/ml/libc-alpha/2018-01/msg00969.html In short, on normal 64 bit hardware which is all we really care about, it'll use /lib64/lp64d/libc.so.6. For Fedora we've settled on

Re: glibc, riscv64, multilib, /lib64 etc

On Thu, Feb 8, 2018 at 9:03 AM, Richard W.M. Jones wrote: > It looks as if upstream RISC-V / glibc teams settled on some exciting > new paths to use for libc.so.6: > > https://sourceware.org/ml/libc-alpha/2018-01/msg00969.html > > In short, on normal 64 bit hardware which is all we really care a

Re: glibc, riscv64, multilib, /lib64 etc

On Thu, Feb 08, 2018 at 09:08:59AM -0500, Neal Gompa wrote: > On Thu, Feb 8, 2018 at 9:03 AM, Richard W.M. Jones wrote: > > It looks as if upstream RISC-V / glibc teams settled on some exciting > > new paths to use for libc.so.6: > > > > https://sourceware.org/ml/libc-alpha/2018-01/msg00969.html

Re: glibc, riscv64, multilib, /lib64 etc

On Thu, Feb 08, 2018 at 09:08:59AM -0500, Neal Gompa wrote: > On Thu, Feb 8, 2018 at 9:03 AM, Richard W.M. Jones wrote: > > It looks as if upstream RISC-V / glibc teams settled on some exciting > > new paths to use for libc.so.6: > > > > https://sourceware.org/ml/libc-alpha/2018-01/msg00969.html

Re: Clean up your spec files

On 08/02/18 14:09 +0100, Miroslav Suchý wrote: * rm -rf $RPM_BUILD_ROOT rpmdev-newspec still inserts this. It may be worthwhile to file a bug to get it to stop. ---Brett. signature.asc Description: PGP signature ___ devel mailing list -- devel@l

Re: Clean up your spec files

On Thu, Feb 8, 2018 at 9:49 AM, Brett Lentz wrote: > On 08/02/18 14:09 +0100, Miroslav Suchý wrote: >> >> >> * rm -rf $RPM_BUILD_ROOT >> > > rpmdev-newspec still inserts this. It may be worthwhile to file a bug to get > it to stop. > The only reason I haven't dropped it yet is because SLE 11 stil

Re: cmake, mc unresponsive packagers

On 8 February 2018 at 12:14, Antonio Trande wrote: [..] > > > > > cmake: > > https://src.fedoraproject.org/rpms/cmake/pull-request/2 > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1530574 > >

[HEADS UP] poppler-qt4 going away

Hi, The latest release of poppler, 0.62.0, drops the Qt4 frontend. As there are still 7 packages in Fedora that use it, I'll revert that change to give these packages more time to get ported--or finish porting--to Qt5. The "grace period" will end before F29 branch-off. The affected packages are:

Re: Clean up your spec files

On Thursday, February 8, 2018 2:09:07 PM CET Miroslav Suchý wrote: > Hi, > I am sometimes reviewing spec files and I very often see common mistakes. The issues you are mentioning below hardly classify as mistakes in my view. > I mean in packages which are already in > Fedora. For a long time and

Re: glibc, riscv64, multilib, /lib64 etc

On Thu, Feb 08, 2018 at 02:03:08PM +, Richard W.M. Jones wrote: > It looks as if upstream RISC-V / glibc teams settled on some exciting > new paths to use for libc.so.6: > > https://sourceware.org/ml/libc-alpha/2018-01/msg00969.html > > In short, on normal 64 bit hardware which is all we re

Re: Clean up your spec files

On 8 February 2018 at 15:03, Kamil Dudka wrote: [..] > There might be valid reasons for the old stuff appearing in _some_ spec > files > beyond your knowledge, for example specfile maintained by upstream, usable > not > only by Fedora. > Theoretically you may be right. In practice .. nope. Ther

Request to unretire Compton

Good evening, I'd like to unretire the compton package and continue maintaining it. You can find my bugzilla review request here: https://bugzilla.redhat.com/show_bug.cgi?id=1532042 Regards, Abhiram K ___ devel mailing list -- devel@lists.fedoraprojec

Re: Clean up your spec files

On Thursday, February 8, 2018 4:21:53 PM CET Tomasz Kłoczko wrote: > On 8 February 2018 at 15:03, Kamil Dudka wrote: > [..] > > > There might be valid reasons for the old stuff appearing in _some_ spec > > files > > beyond your knowledge, for example specfile maintained by upstream, usable > > no

Re: Clean up your spec files

Tomasz Kłoczko wrote: > On 8 February 2018 at 15:03, Kamil Dudka > wrote: > [..]  > > There might be valid reasons for the old stuff appearing in _some_ > spec files > beyond your knowledge, for example specfile maintained by upstream, > usable not >

Re: Clean up your spec files

Dne 8.2.2018 v 16:39 Kamil Dudka napsal(a): > On Thursday, February 8, 2018 4:21:53 PM CET Tomasz Kłoczko wrote: >> On 8 February 2018 at 15:03, Kamil Dudka wrote: >> [..] >> >>> There might be valid reasons for the old stuff appearing in _some_ spec >>> files >>> beyond your knowledge, for exam

Escaping macros in %changelog

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello everyone, It seems that a lot of people have %file, %check, %build, %whatsoever in their changelog section. Is there any reason I should not go and automatically escape them? %check → %%check %build → %%build %whatsoever → %%whatsoever Ther

Re: Clean up your spec files

On Thu, Feb 8, 2018 at 10:45 AM, Vít Ondruch wrote: > > > Dne 8.2.2018 v 16:39 Kamil Dudka napsal(a): >> On Thursday, February 8, 2018 4:21:53 PM CET Tomasz Kłoczko wrote: >>> On 8 February 2018 at 15:03, Kamil Dudka wrote: >>> [..] >>> There might be valid reasons for the old stuff appearin

Re: Clean up your spec files

On Thu, Feb 8, 2018 at 9:53 AM, Neal Gompa wrote: > On Thu, Feb 8, 2018 at 9:49 AM, Brett Lentz wrote: >> On 08/02/18 14:09 +0100, Miroslav Suchý wrote: >>> >>> >>> * rm -rf $RPM_BUILD_ROOT >>> >> >> rpmdev-newspec still inserts this. It may be worthwhile to file a bug to get >> it to stop. >> >

Re: Clean up your spec files

On Thu, Feb 08, 2018 at 11:05:38AM -0500, Neal Gompa wrote: > On Thu, Feb 8, 2018 at 10:45 AM, Vít Ondruch wrote: > > https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Maintenance_and_Canonicity > > > > Not saying it contradicts the guideline above, just FYI. > > > > In practice, there are

Re: Escaping macros in %changelog

On Thu, 2018-02-08 at 17:02 +0100, Igor Gnatenko wrote: > Hello everyone, > > It seems that a lot of people have %file, %check, %build, %whatsoever > in their > changelog section. > > Is there any reason I should not go and automatically escape them? > > %check → %%check > %build → %%build > %wh

Re: Clean up your spec files

On 8 February 2018 at 15:39, Kamil Dudka wrote: [..] > For example logrotate upstream maintains a spec file that is regularly > updated > and CI-tested by Travis: > > https://github.com/logrotate/logrotate/commits/master/logrotate.spec.in OK. Please compare what is one that URL with https://src

Re: Escaping macros in %changelog

On Thu, 2018-02-08 at 16:20 +, Sérgio Basto wrote: > On Thu, 2018-02-08 at 17:02 +0100, Igor Gnatenko wrote: > > Hello everyone, > > > > It seems that a lot of people have %file, %check, %build, > > %whatsoever > > in their > > changelog section. > > > > Is there any reason I should not go an

Re: Escaping macros in %changelog

Igor Gnatenko wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hello everyone, > > It seems that a lot of people have %file, %check, %build, %whatsoever in > their changelog section. > > Is there any reason I should not go and automatically escape them? > > %check → %%check > %bu

Re: Clean up your spec files

On Thu, Feb 08, 2018 at 09:53:01AM -0500, Neal Gompa wrote: > The only reason I haven't dropped it yet is because SLE 11 still is > supported, and it requires it. > I could see into adding some magic into removing it when newer rpm is > detected, but I'm not sure it's worth it for a single line. I

Please review use /$ in %files (Was: Re: Escaping macros in %changelog)

BTW some massively occurring errors in really big number Fedora of specs. Looks like many people don't know that %files entry like: /some/directory/ does not include /some/directory into package but all files and subdirectories which are in /some/directory. This is in how many specs such lines

Re: Please review use /$ in %files (Was: Re: Escaping macros in %changelog)

On Thu, Feb 8, 2018 at 9:56 AM, Tomasz Kłoczko wrote: > Looks like many people don't know that %files entry like: > > /some/directory/ > > does not include /some/directory into package but all files and > subdirectories which are in /some/directory. That is incorrect. For example, the polyml spe

Re: Please review use /$ in %files (Was: Re: Escaping macros in %changelog)

On Thu, Feb 8, 2018 at 11:56 AM, Tomasz Kłoczko wrote: > BTW some massively occurring errors in really big number Fedora of specs. > > Looks like many people don't know that %files entry like: > > /some/directory/ > > does not include /some/directory into package but all files and > subdirectories

Re: Please review use /$ in %files (Was: Re: Escaping macros in %changelog)

On 8.2.2018 18:33, Neal Gompa wrote: > On Thu, Feb 8, 2018 at 11:56 AM, Tomasz Kłoczko > wrote: >> BTW some massively occurring errors in really big number Fedora of specs. >> >> Looks like many people don't know that %files entry like: >> >> /some/directory/ >> >> does not include /some/directo

Re: Please review use /$ in %files (Was: Re: Escaping macros in %changelog)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2018-02-08 at 16:56 +, Tomasz Kłoczko wrote: > BTW some massively occurring errors in really big number Fedora of specs. > > Looks like many people don't know that %files entry like: > > /some/directory/ > > does not include /some/dire

Re: Please review use /$ in %files (Was: Re: Escaping macros in %changelog)

On 8 February 2018 at 17:39, Petr Stodulka wrote: [..] > > There's nothing wrong here. > > > > > > Exactly. IMHO, use of %dir macro for "top" pkg directories is more clean > solution, but > doesn't matter in case the rpm is packaged correctly. > I'm sure that in the past it was difference here :

Re: Escaping macros in %changelog

On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote: > It seems that a lot of people have %file, %check, %build, %whatsoever > in their changelog section. > Is there any reason I should not go and automatically escape them? This seems like a lot of churn. If we're going to do this, let's

Re: Escaping macros in %changelog

On 02/08/2018 01:32 PM, Matthew Miller wrote: This seems like a lot of churn. If we're going to do this, let's go big and get rid of RPM changelogs. When we have a package update, there are basically two different kinds of changelog information. Well, three. [...] Third, though, there's end-user

Re: glibc, riscv64, multilib, /lib64 etc

On 02/08/2018 06:51 AM, david.abdurachma...@gmail.com wrote: >> We could do a downstream patch. > > This would be a minimal patch based on quick look into glibc code. We > could force it to act as, e.g AArch64. I worry, that this would be > custom from what is expected in RISC-V software ecosystem

Re: glibc, riscv64, multilib, /lib64 etc

On Thu, Feb 08, 2018 at 11:50:32AM -0800, Carlos O'Donell wrote: > On 02/08/2018 06:51 AM, david.abdurachma...@gmail.com wrote: > >> We could do a downstream patch. > > > > This would be a minimal patch based on quick look into glibc code. We > > could force it to act as, e.g AArch64. I worry, tha

Re: Fwd: Re: Fedora27: NFS v4 terrible write performance, is async working

On 06/02/18 21:48, J. Bruce Fields wrote: On Tue, Feb 06, 2018 at 08:18:27PM +, Terry Barnaby wrote: Well, when a program running on a system calls open(), write() etc. to the local disk FS the disk's contents is not actually updated. The data is in server buffers until the next sync/fsync o

Re: glibc, riscv64, multilib, /lib64 etc

On 02/08/2018 07:14 AM, Richard W.M. Jones wrote: > Or when building glibc, use: > > ./configure --libdir=/usr/lib64 libc_cv_slibdir=/usr/lib64 > libc_cv_rtlddir=/usr/lib64 > > which seems to be sufficent to override the default path choices, > although maybe not completely. This would be a m

Re: Fwd: Re: Fedora27: NFS v4 terrible write performance, is async working

On Thu, Feb 08, 2018 at 08:21:44PM +, Terry Barnaby wrote: > Doesn't fsync() and perhaps sync() work across NFS then when the server has > an async export, No. On a local filesystem, a file create followed by a sync will ensure the file create reaches disk. Normally on NFS, the same is true-

Re: Escaping macros in %changelog

On 2018-02-08, 18:32 GMT, Matthew Miller wrote: > This seems like a lot of churn. If we're going to do this, > let's go big and get rid of RPM changelogs. +1 Matej -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 How f

Re: Escaping macros in %changelog

On 02/08/2018 05:02 PM, Igor Gnatenko wrote: > Hello everyone, > > It seems that a lot of people have %file, %check, %build, %whatsoever > in their > changelog section. > > Is there any reason I should not go and automatically escape them? > > %check → %%check > %build → %%build > %whatsoever → %%w

Re: Escaping macros in %changelog

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 2018-02-08 at 13:32 -0500, Matthew Miller wrote: > On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote: > > It seems that a lot of people have %file, %check, %build, %whatsoever > > in their changelog section. > > Is there any reaso

Re: Pull requests for compat-gcc-34

Rafal Luzynski wrote: > Requires: libstdc++.so.6 That needs to be libstdc++.so.6()(64bit) on x86_64 and other 64-bit multilib architectures though. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an emai

Re: Escaping macros in %changelog

On Thursday, February 8, 2018 5:02:10 PM CET Igor Gnatenko wrote: > Hello everyone, > > It seems that a lot of people have %file, %check, %build, %whatsoever in their > changelog section. > > Is there any reason I should not go and automatically escape them? There's IMO no good reason why you sh