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

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

-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: 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

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: 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: 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 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 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: 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: 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: 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: 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: 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.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)

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 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

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: 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

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: 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: 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 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 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: 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 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

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

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

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

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

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 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

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 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

[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: 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 > >

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: 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: 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: 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

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: 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

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 >> >>

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 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

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 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: 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: 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