Re: Escaping macros in %changelog

[Pavel Raiskup]

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

I wouldn't use proven packager rights if the package builds fine.  Fill a
pull request if anything.

One could admit that fixing similar typos (white space issues, spelling
issues, changelog date issues, ...) is OK if you are touching the spec
file anyway because of some real problems, but even then you make the
patch less readable - and thus you raise chances that something get's
overlooked.  So I wouldn't do that.

> %check → %%check
> %build → %%build
> %whatsoever → %%whatsoever
> 
> There might be valid use-cases, but I'm not sure if they really are:
> %{_localstatedir}/ft/ → %%{_localstatedir}/ft/
> 
> Thoughts?

E.g. server-side git hook refusing commits "adding typos" into changelog
would solve it once and forever.  If you were able to implement some
systematic change like this then I would excuse the walk across all the
spec files to fix old issues..

Pavel

> --
> -Igor Gnatenko
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pull requests for compat-gcc-34

[Kevin Kofler]

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 email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Igor Gnatenko]

-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 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 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.
> 
> First, there's the upstream changelog. We don't generally do much with
> these except maybe package as %doc.
> 
> Second, there's package maintainer changelogs. These are really
> redundant with the dist-git log. We don't really need this anymore.
> It's just a chore.
> 
> Third, though, there's end-user information. Why should a user care
> *This* is redundant with bodhi update info, at least if packagers fill
> that out, and it often also duplicates upstream changelogs, *and* it
> often also covers things like "fixes CVE-' also carried the
> specfile changelog.
> 
> This is neither most helpful for user *nor* ideal for packages. Why
> don't we drop changelogs entirely in favor of 1) using the dist-git
> logs for specfile maintainers and 2) providing the end-user information
> in a different way. This could be through specially formatted log lines
> going with the commit, or it could be simply in a standard separate
> file (`fedora.user-visible-changes`). Optionally, it could include both
> a high level end-user summary, and a detailed description for sysadmins
> and the curious.
> 
> Wherever it lives, this would be read by Bodhi, so there's
> would be need to enter it more than once. And, perhaps a DNF plugin
> could be made to read and display this information for systems
> administrators.

While I totally agree with what you've said, there are some problems with
generating changelogs from git.

* Many times people put some useless messages in there, so we probably don't
want to convert old history to git-based changelogs and have point where we ask
people to start writing useful commit messages.
* No easy way to map changelogs with versions and releases in package. Imagine
that you pushed commit with update, then realised that it doesn't build and
reverted. What should be in changelog?

I would **love** to switch to git-based changelogs, but we need to work on
defining how exactly it should behave and find way how to get there (it will
involve release engineering at least). Would be nice if you would describe step
by step workflow you would like to see 😉

In meanwhile, unescaped macros in %changelog create problems because they do
expand.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlp9SesACgkQaVcUvRu8
X0wPGQ/9E6PRloCCF3q945AVt+saxen2PG+ehvRRjUTPK2tmmQQDf5NzaGsVowF3
/RYwxNpCeiBUgy2mz0/3lfkRSGhvM6km5hT370LdTec0WE85Fd0MUWiYt8uPoL8q
bUxDKpJl6H7gcEFslztP0Ou2W85RWUfGGOux03IZQdjssxDF+bCUX17VrHWaieFA
o1u7Q/jFT6nYGA4F+hHOYF8eFzG7nT64ScJTXL/uJeHTiwT6pBWUm6yCKpl539tl
2+jozmKA/7GcuHopT7QaV51hlJ5nDy+mcAGhjRmYVxm5OIxAxICkegcKCL2FTbsm
BKx70jrd4gb5ScsVUBGUTXgf9BUbUdXwMV2iCrLDiSyDSkOE9kooBifR4lLj7Asf
/eldClCnOkcNeEzapfFvu6T3YDZaG6sVm64UcZ5UdfsJ+44HPE9MygCaicprnRdL
HO8eSQwq7GDYL2i+XZWgXzon3w77u3DBMGYUxOz1tTTTBNiD/mr8EAqxC2gUsxfQ
tCk8NjROmo0d0kqBGr7Fu1ltjVrB0rGx4CRlU/84O/Rt6G53ZWJ/s4+fa/QnhBCz
FzVg/aOPc8+CZX6g+vXr5RJ5lo/oKErzT5hI29eev9oUOJulhA0zc04C9pa7X3tV
9tU6DRsjKLeth9u+ecyH+SOwwfMS8XGVZZ6b2hkFfMOAqqMTWps=
=GWlO
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Zdenek Dohnal]

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 → %%whatsoever
>
> There might be valid use-cases, but I'm not sure if they really are:
> %{_localstatedir}/ft/ → %%{_localstatedir}/ft/
>
>
> Thoughts?

+1 for me, go ahead :)

> ___ > devel mailing list -- 
> devel@lists.fedoraproject.org > To unsubscribe
send an email to devel-le...@lists.fedoraproject.org
-- 
Zdenek Dohnal
Associate Software Engineer
Red Hat Czech - Brno TPB-C



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Matěj Cepl]

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 fleeting are all human passions compared to the massive
continuity of ducks.
  -- Dorothy L. Sayers: Gaudy Night
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[J. Bruce Fields]

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--for
the trivial reason that the file create already ensured this.  If your
server is Linux knfsd exporting the filesystem with async, the file
create may still not be on disk after the sync.

> I don't think a program on a remote system is particularly worse off
> if the NFS server dies, it may have to die if it can't do any special
> recovery.

Well-written applications should be able to deal with recovering after a
crash, *if* the filesystem respects fsync() and friends.  If the
filesystem ignores them and loses data silently, the application is left
in a rather more difficult position!

> > > Only difference from the normal FS conventions I am suggesting is to
> > > allow the server to stipulate "sync" on its mount that forces sync
> > > mode for all clients on that FS.
> > Anyway, we don't have protocol to tell clients to do that.
> As I said NFSv4.3 :)

Protocol extensions are certainly possible.

> > So if you have reliable servers and power, maybe you're comfortable with
> > the risk.  There's a reason that's not the default, though.
> Well, it is the default for local FS mounts so I really don't see why it
> should be different for network mounts.

It's definitely not the default for local mounts to ignore sync().  So,
you understand why I say that the "async" export option is very
different from the mount option with the same name.  (Yes, the name was
a mistake.)  And you can see why a filesystem engineer would get nervous
about recommending that configuration.

> But anyway for my usage NFS sync is completely unusable (as would
> local sync mounts) so it has to be async NFS or local disks (13 secs
> local disk -> 3mins NFS async-> 2 hours NFS sync). I would have
> thought that would go for the majority of NFS usage. No issue to me
> though as long as async can be configured and works well :)

So, instead what I personally use is a hardware configuration that allow
me to get similar performance while still using the default export
options.

> > Sure.  The protocol issues are probably more complicated than they first
> > appear, though!
> Yes, they probably are, most things are below the surface, but I still think
> there are likely to be a lot of improvements that could be made that would
> make using NFS async more tenable to the user.
> If necessary local file caching (to local disk) with delayed NFS writes. I
> do use fscache for the NFS - OpenVPN - FTTP mounts, but the NFS caching time
> tests probably hit the performance of this for reads and I presume writes
> would be write through rather than delayed write. Haven't actually looked at
> the performance of this and I know there are other network file systems that
> may be more suited in that case.

fscache doesn't remove the need for synchronous file creates.

So, in the existing protocol write delegations are probably what would
help most; which is why they're near the top of my todo list.

But write delegations just cover file data and attributes.  If we want a
client to be able to, for example, respond to creat() with success, we
want write delegations on *directories*.  That's rather more
complicated, and we currently don't even have protocol proposed for
that.  It's been proposed in the past and I hope there may be sufficient
time and motivation to make it happen some day

--b.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: glibc, riscv64, multilib, /lib64 etc

[Carlos O'Donell]

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 mistake IMO, since it creates a variant ABI.

-- 
Cheers,
Carlos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Terry Barnaby]

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 or some time has passed. So, in
your parlance, the OS write() call lies to the program. So it is by default
async unless the "sync" mount option is used when mounting the particular
file system in question.

That's right, but note applications are written with the knowledge that
OS's behave this way, and are given tools (sync, fsync, etc.) to manage
this behavior so that they still have some control over what survives a
crash.

(But sync & friends no longer do what they're supposed to on an Linux
server exporting with async.)
Doesn't fsync() and perhaps sync() work across NFS then when the server 
has an async export, I thought they did along with file locking to some 
extent ?

Although it is different from the current NFS settings methods, I would have
thought that this should be the same for NFS. So if a client mounts a file
system normally it is async, ie write() data is in buffers somewhere (client
or server) unless the client mounts the file system in sync mode.

In fact, this is pretty much how it works, for write().

It didn't used to be that way--NFSv2 writes were all synchronous.

The problem is that if a server power cycles while it still had dirty
data in its caches, what should you do?
You can't ignore it--you'd just be silently losing data.  You could
return an error at some point, but "we just lost some or your idea, no
idea what" isn't an error an application can really act on.
Yes, it is tricky error handling. But what does a program do when its 
local hard disk disk or machine dies underneath it anyway ? I don't 
think a program on a remote system is particularly worse off if the NFS 
server dies, it may have to die if it can't do any special recovery. If 
it was important to get the data to disk it would have been using 
fsync(), FS sync, or some other transaction based approach, indeed it 
shouldn't be using network remote disk mounts anyway. It all depends on 
what the program is doing and its usage requirements. A cc failing one 
in a blue moon is not a real issue (as long as it fails and removes its 
created files or at least a make clean can be run). As I have said I 
have used NFS async for about 27+ years on multiple systems with no 
problems when servers die with the type of usage I use NFS for. The 
number of times a server has died is low in that time. Client systems 
have died many many more times (User issues, experimental 
programs/kernels, random program usage, single cheap disks, cheaper non 
ECC RAM etc.)

So NFSv3 introduced a separation of write into WRITE and COMMIT.  The
client first sends a WRITE with the data, then latter sends a COMMIT
call that says "please don't return till that data I sent before is
actually on disk".

If the server reboots, there's a limited set of data that the client
needs to resend to recover (just data that's been written but not
committed.)

But we only have that for file data, metadata would be more complicated,
so stuff like file creates, setattr, directory operations, etc., are
still synchronous.


Only difference from the normal FS conventions I am suggesting is to
allow the server to stipulate "sync" on its mount that forces sync
mode for all clients on that FS.

Anyway, we don't have protocol to tell clients to do that.

As I said NFSv4.3 :)



In the case of a /home mount for example, or a source code build file
system, it is normally only one client that is accessing the dir and if a
write fails due to the server going down (an unlikely occurrence, its not
much of an issue. I have only had this happen a couple of times in 28 years
and then with no significant issues (power outage, disk fail pre-raid etc.).

So if you have reliable servers and power, maybe you're comfortable with
the risk.  There's a reason that's not the default, though.
Well, it is the default for local FS mounts so I really don't see why it 
should be different for network mounts. But anyway for my usage NFS sync 
is completely unusable (as would local sync mounts) so it has to be 
async NFS or local disks (13 secs local disk -> 3mins NFS async-> 2 
hours NFS sync). I would have thought that would go for the majority of 
NFS usage. No issue to me though as long as async can be configured and 
works well :)



4. The 0.5ms RPC latency seems a bit high (ICMP pings 0.12ms) . Maybe this
is worth investigating in the Linux kernel processing (how ?) ?

Yes, that'd be interesting to investigate.  With some kernel tracing I
think it should be possible to get high-resolution timings for the
processing of a single RPC call, which would make a good start.

It'd probably also interesting to start with the simplest possible RPC
and then work our way up and see when the RTT increases 

Re: glibc, riscv64, multilib, /lib64 etc

[Richard W.M. Jones]

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, that this would be
> > custom from what is expected in RISC-V software ecosystem. If we stay
> > with /lib64/lp64d/ then we probably need to do more fixing in packages,
> > because I doubt everything is using %{_libdir}.
> > 
> > Alternative being discussed right now at #fedora-riscv is to use
> > symlinks, e.g. /usr/lib64/lp64d -> /usr/lib64 like we have /lib64 ->
> > /usr/lib64
> > 
> > If we can solve this issue with symlinks, then I would vote for that.
> > Then we don't need to do a lot of fixing and we sorta have what's
> > expected by glibc, or/and in general RISC-V software ecosystem.
> 
> I see two issues at hand:
> 
> (a) RISC-V software ecosystem compatibility.
> 
> (b) Technical implications and ABI compatibility.
> 
> In regards to (a), I agree completely with David, that deviating
> from the RISC-V software ecosystem is going to cause adoption problems.
> We should avoid changing what upstream has chosen. Symlinks should
> solve the issue, and if they do not then that's a bug in the dynamic
> loader and someone should immediately file the bug and the Fedora
> glibc team will fix it.
> 
> In regards to (b), there are two very important distinctions to make:
> 
> (1) What is the path to the dynamic loader?
> 
> (2) What is the path to shared libraries?
> 
> Firstly, (1) is an ABI atrifact that all 3rd party libraries will
> have encoded into the binaries PT_INTERP program header entry, and
> for binaries compiled with an upstream the official path is listed
> here:
> 
> https://sourceware.org/glibc/wiki/ABIList#RISC-V
> 
> Surprisingly it is /lib. So this means that rtlddir is /lib, and
> the dynamic loader is uniquely placed in /lib *even though* it
> is a 64-bit dynamic loader.

Yes, our currently built binaries have:

  [Requesting program interpreter: /lib/ld-linux-riscv64-lp64d.so.1]

> We *must* *not* deviate from this in Fedora, and this path must
> exist to the loader, but it can be a symlink.
> 
> Secondly, (2) is all the libraries, and these we have much more
> flexibility, we can really put them wherever we want, the DSO's
> DT_NEEDED entries are SONAMES which are searched by our own loader
> and since we control those search paths we could make things
> work like we expect them to with all libraries in /lib64.
> 
> However, the upstream community has chosen /lib64/lp64 as the
> location of the shared library directory e.g. slibdir, and that
> means 3rd party binaries could have hard coded dlopen paths that
> try to open specific libraries e.g. dlopen /lib64/lp64/libfoo.so.0
> and if we don't at least symlink that path it will fail. Likewise
> 3rd party binaries may also use DT_RPATH and DT_RUNPATH to specify
> specific search paths which may be based on /lib64/lp64 e.g.
> /lib64/lp64/mozilla/plugins.
> 
> In summary:
> 
> - We must minimally provide a symlink for /lib/ld-linux-riscv64-lp64d.so.1 
> - We must minimally provide a symlink for /lib64/lp64d
> - As Fedora glibc team lead I'm OK with symlinks.
> 
> I'm happy to see both of these symlinks in glibc.spec point to
> wherever we as a community decide we want to see things.

This is great, a good summary.

What I'm going to do is work on a glibc.spec patch which I'll
circulate to you and glibc-owner before pushing anything.

However it takes 11 hours to build glibc in the emulation so
it'll be a while :-/

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: glibc, riscv64, multilib, /lib64 etc

[Carlos O'Donell]

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. If we stay
> with /lib64/lp64d/ then we probably need to do more fixing in packages,
> because I doubt everything is using %{_libdir}.
> 
> Alternative being discussed right now at #fedora-riscv is to use
> symlinks, e.g. /usr/lib64/lp64d -> /usr/lib64 like we have /lib64 ->
> /usr/lib64
> 
> If we can solve this issue with symlinks, then I would vote for that.
> Then we don't need to do a lot of fixing and we sorta have what's
> expected by glibc, or/and in general RISC-V software ecosystem.

I see two issues at hand:

(a) RISC-V software ecosystem compatibility.

(b) Technical implications and ABI compatibility.

In regards to (a), I agree completely with David, that deviating
from the RISC-V software ecosystem is going to cause adoption problems.
We should avoid changing what upstream has chosen. Symlinks should
solve the issue, and if they do not then that's a bug in the dynamic
loader and someone should immediately file the bug and the Fedora
glibc team will fix it.

In regards to (b), there are two very important distinctions to make:

(1) What is the path to the dynamic loader?

(2) What is the path to shared libraries?

Firstly, (1) is an ABI atrifact that all 3rd party libraries will
have encoded into the binaries PT_INTERP program header entry, and
for binaries compiled with an upstream the official path is listed
here:

https://sourceware.org/glibc/wiki/ABIList#RISC-V

Surprisingly it is /lib. So this means that rtlddir is /lib, and
the dynamic loader is uniquely placed in /lib *even though* it
is a 64-bit dynamic loader.

We *must* *not* deviate from this in Fedora, and this path must
exist to the loader, but it can be a symlink.

Secondly, (2) is all the libraries, and these we have much more
flexibility, we can really put them wherever we want, the DSO's
DT_NEEDED entries are SONAMES which are searched by our own loader
and since we control those search paths we could make things
work like we expect them to with all libraries in /lib64.

However, the upstream community has chosen /lib64/lp64 as the
location of the shared library directory e.g. slibdir, and that
means 3rd party binaries could have hard coded dlopen paths that
try to open specific libraries e.g. dlopen /lib64/lp64/libfoo.so.0
and if we don't at least symlink that path it will fail. Likewise
3rd party binaries may also use DT_RPATH and DT_RUNPATH to specify
specific search paths which may be based on /lib64/lp64 e.g.
/lib64/lp64/mozilla/plugins.

In summary:

- We must minimally provide a symlink for /lib/ld-linux-riscv64-lp64d.so.1 
- We must minimally provide a symlink for /lib64/lp64d
- As Fedora glibc team lead I'm OK with symlinks.

I'm happy to see both of these symlinks in glibc.spec point to
wherever we as a community decide we want to see things.

-- 
Cheers,
Carlos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Przemek Klosowski]

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 information. [..]*and*  it
often also covers things like "fixes CVE-' also carried the
specfile changelog.
This is very useful in my opinion. I know that it's not a consistent 
policy driven technology, but rather a sort of a kindness extended by 
consciencious packagers, but it's a great way to correlate specific CVE 
issues to the update stream. Without it, there's no clear way to find 
out if the system is vulnerable or not---the software versions aren't 
necessarily sufficient because of backports, and require manual checking 
to find out when a fix is being included.


Many environments (corporate, government) actually require keeping track 
of this stuff, so addressing it would help the acceptance of Fedora and 
Redhat in such environments
rpm -q --changelog mypackage | grep CVE is really useful in such 
circumstances.


Having said that, the informality of the current setup makes it a little 
haphazard:  I know that not all CVEs are being mentioned--and if they 
are, they don't always mention specific audit information like the BZ 
entries, software revisions etc.


This is neither most helpful for user*nor*  ideal for packages. Why
don't we drop changelogs entirely in favor of 1) using the dist-git
logs for specfile maintainers and 2) providing the end-user information
in a different way. This could be through specially formatted log lines
going with the commit, or it could be simply in a standard separate
file (`fedora.user-visible-changes`). Optionally, it could include both
a high level end-user summary, and a detailed description for sysadmins
and the curious.
I don't like the idea of a separate file; I'd like to preserve and maybe 
codify the security fix info in package metadata. If not changelog, then 
whatevern replaces it should mention the CVEs  in a complete and 
organized way, i.e. the packaging rules should require mentioning CVEs 
and linking them to problem reports and specific patches that address them.



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Matthew Miller]

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

First, there's the upstream changelog. We don't generally do much with
these except maybe package as %doc.

Second, there's package maintainer changelogs. These are really
redundant with the dist-git log. We don't really need this anymore.
It's just a chore.

Third, though, there's end-user information. Why should a user care
*This* is redundant with bodhi update info, at least if packagers fill
that out, and it often also duplicates upstream changelogs, *and* it
often also covers things like "fixes CVE-' also carried the
specfile changelog.

This is neither most helpful for user *nor* ideal for packages. Why
don't we drop changelogs entirely in favor of 1) using the dist-git
logs for specfile maintainers and 2) providing the end-user information
in a different way. This could be through specially formatted log lines
going with the commit, or it could be simply in a standard separate
file (`fedora.user-visible-changes`). Optionally, it could include both
a high level end-user summary, and a detailed description for sysadmins
and the curious.

Wherever it lives, this would be read by Bodhi, so there's
would be need to enter it more than once. And, perhaps a DNF plugin
could be made to read and display this information for systems
administrators.





-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Tomasz Kłoczko]

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 :|
And I'm sure that I found few specs where it was some issue wen /$ was used.

If I'll not back with some exact examples packages/specs (which I saw in
last 2-3 weeks)  in next few days it will mean that I was wrong :/

Nevertheless I found many directories not owned by any packages on my
system as result of many upgrades.
There are few common causes of such issues:

- example gluster.spec: does owns many directories %{_libdir}/glusterfs and
by this on each upgrade to the next version is
left %{_libdir}/glusterfs/ with many empty directories inside.
Other case is that set of dependencies between subpackages are not correct
and by delete some packages ordering them during remove using dependencies
there are left some empty directories

- example libiscis.spec: sometimes it is bug in spec and exact directory is
not included in %files (not added %{_libdir}/iscis
  BTW there are two iscsi client libraries in distribution and libiscsi
moves clashing library to %{_libdir}/iscis

Probably here is more common cases when after upgrade there is left some
not deleted files or directories.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Igor Gnatenko]

-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/directory into package but all files and
> subdirectories which are in /some/directory.

This is not true.

/foo/bar is same as /foo/bar/ with one caveat: /foo/bar/ will fail if "bar" is
a file and not a directory.

> What it is causing such mistake everyone can check by executing

No, this is caused by different mispackaging.

> $ (for i in /usr/{lib64,exec,share}; do find $i -name \*; done) 2>&1 |
> xargs rpm -qf |grep "is not owned by any package"

Yes, this is a problem and you better to report bugs instead of dumping this
here.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlp8jdkACgkQaVcUvRu8
X0weJg//W5VMwRVH50A9pEQe39EdGJW+HN6jCOp6V0m6NeLyGVj01+WVXtc5X89k
z+OAwiB06l/jDbdjY6VdYfnn8Z2XBvwqyRPlRpOLrffJTuthZOk53l8LFUM6Lf9C
q6MREhl3a1sdtWPzdF2IeDNlCwGa9Eu/dsMcgVuiWi0lpfec4ADXz/kYbD8PtccS
6CyRSZjZOh7fY5xBZReMgc18qTKoo5ZR1nG0cPMfeyE8uGEOOMd0ewsKLucKXv8J
lVriDuU7e2YajnJnYAByIxJqmpIRALaQbsAcLin8uSkkHBNlY1wZsyYL2egJM1bI
XiUei/8xN/TFA3yOtu60JGfSVczJbfdSrQzNABOK9pPR3Rv9XdZTPW2QVIvjKO12
bKw2uq98n8MFszCqyw+31dpN4U5rtyDyoXhBGiBpqKORjYDG1ax8CkrfF79IR67Q
F+taFyZfa8hTQU9vn0EMLs0B/JqioMJ+/muiaNddZ/bAk30fl7cg0yPftWA4WgY1
e4Na7IXQQRbjHhdSSAST3Fqr8y2K77w40BHhR8aSWotDHhkOcdQzVObV3T/CCsqn
re8kCnqTP+YcXvN+CS0Za/6cfHq9mNipyT9xSHOK1ENN14CbmJgtnBLoftYXCrPU
vRli/1pLlPAsI5PsNwnKzee3kBnkD2eQv6aZKdh0r7s/xlRDP+k=
=lugv
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Petr Stodulka]

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/directory into package but all files and
>> subdirectories which are in /some/directory.
>>
> 
> It in fact does.
> 
> The following:
> %files
> /some/directory/
> 
> is equivalent to:
> %files
> %dir /some/directory
> /some/directory/*
> 
> 
> 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.

-- 
Petr Stodulka
Core Services (In-place upgrades and migrations)
IRC nicks: pstodulk, skytak
Red Hat



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Neal Gompa]

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 which are in /some/directory.
>

It in fact does.

The following:
%files
/some/directory/

is equivalent to:
%files
%dir /some/directory
/some/directory/*


There's nothing wrong here.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Jerry James]

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 spec file contains this in %files:

%{_libdir}/polyml/

And on my x86_64 Fedora 27 box:

$ rpm -qf /usr/lib64/polyml
polyml-5.7.1-1.fc27.x86_64

The trailing slash doesn't matter.  I use it as a visual reminder that
the %files entry is a directory, not a file.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Tomasz Kłoczko]

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

[tkloczko@domek SPECS.fedora]$ grep ^%\{.*\/$ * | grep -v __ | awk -F\.
'{print $1}' | uniq| wc -l
4827

There is

[tkloczko@domek SPECS.fedora]$ grep ^%\{.*\/$ * | grep -v __ | wc -l
17762

such entries in all fedora spec files.

What it is causing such mistake everyone can check by executing

$ (for i in /usr/{lib64,exec,share}; do find $i -name \*; done) 2>&1 |
xargs rpm -qf |grep "is not owned by any package"

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Clean up your spec files

[Matthew Miller]

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.

Isn't the framework for this already in the tool with --rpm-version?


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Rex Dieter]

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
> %build → %%build
> %whatsoever → %%whatsoever

+1 , escape

-- rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Sérgio Basto]

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 and automatically escape them?
> > 
> > %check → %%check
> > %build → %%build
> > %whatsoever → %%whatsoever
> > 
> > There might be valid use-cases, but I'm not sure if they really
> > are:
> > %{_localstatedir}/ft/ → %%{_localstatedir}/ft/
> > 
> > 
> > Thoughts?
> 
> I already though a lot about this, my last decision was remove
> %instead add another one . 
> 
> %{_localstatedir}/ft/ → {_localstatedir}/ft/

Also some people make the mistake of comment %setup with #%setup 
which is not correct , setup will still running . #setup is the correct
way of comment out , i.e % have a lot of power so I though would be
better remove then . 


-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Clean up your spec files

[Tomasz Kłoczko]

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.fedoraproject.org/rpms/logrotate/raw/master/f/logrotate.spec
Just try to use command like:

$ diff -u <(curl -s
https://src.fedoraproject.org/rpms/logrotate/raw/master/f/logrotate.spec)
<(curl -s
https://raw.githubusercontent.com/logrotate/logrotate/master/logrotate.spec.in)
| less

Additionally to compare this spec.in with spec used in SuSE, altlinux and
few other ..

Spec files of csdiff, cscppc, csmock, and cswrap are produced by
> make-srpm.sh
> maintained in the upstream git repositories.
>

In such cases you will be manually adding %changelog.
In all those cases we are talking about so simple packages that one time
written correctly spec file can be used for years.
Looks like someone who found idea make-srpm.sh scripts didn't know that if
in source tar ball will be included .spec it will be possible to
build such package by

$ rpmbuild -ta .tar.gz

In other words instead including such script should be included spec
generated on "make dist-check" when tar ball with new version will be
created by maintainer.
Nevertheless logrote and other packages which you've mentioned by you
already have own history of changes in Fedora and have as well higher
release numbers (all of them).

It will be really better if source tree maintainers will be only focused on
maintaining such tree and will leave packaging to the people who are
maintaining packages in different OSes (what about *BSD,
Solaris/OpenIdiana?) and OSes distributions (what about Debian, OpenWRT/Lede
.. ?).
Usually effort like in examples which you gave are pure waste of time
because maintaining packages it is not the same as maintaining source tree
of exact package.
On both areas is required quite different knowledge.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *



>
> Kamil
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Sérgio Basto]

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
> %whatsoever → %%whatsoever
> 
> There might be valid use-cases, but I'm not sure if they really are:
> %{_localstatedir}/ft/ → %%{_localstatedir}/ft/
> 
> 
> Thoughts?

I already though a lot about this, my last decision was remove %instead add 
another one . 

%{_localstatedir}/ft/ → {_localstatedir}/ft/


Cheers,
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Clean up your spec files

[Daniel P . Berrangé]

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 several projects that blatantly ignore this.
> Off the top of my head:

> * libvirt stack packages (excluding php-libvirt, as I maintain that
> and have no rights to the libvirt-php repo)

Claiming we ignore the guideline is wrong. As the primary package
maintainer, I do consider upstream repos to have the canonical
copy of the spec file, but do *not* just blindly overwrite changes
made in Fedora. If someone proposes a cleanup to the Fedora libvirt
related specs, we'll encourage them to send that as a patch to upstream.
If they don't, and just make the change to Fedora specs, we'll none the
less apply it to upstream copy ourselves, assuming it was functionally
correct. When updating to new libvirt releases, I'll do a diff between
upstream and Fedora specs to make sure I don't mistakenly kill some
change a Fedora provenpackager made that I missed upstream. This all
works very well and ensures Fedora packages get their spec updated
accurately when upstream releases come with new features that impact
on packaging.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Clean up your spec files

[Ben Rosser]

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

Well... personally, it's pretty annoying to have to remove this from
every spec I generate using rpmdev-newspec. It also gives the
impression that the newspec-generated specs might be outdated in other
respects too.

I don't know how other people feel, though.

Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Clean up your spec files

[Neal Gompa]

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 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.
>>> There is no any reasons to use in Fedora spec file which is not
>>> readable/simple as it is only possible because someone who is not focused
>>> on Fedora want to make it universal without testing it on all possible
>>> distributions on every new version released.
>>>
>>> kloczek
>> 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
>>
>> Spec files of csdiff, cscppc, csmock, and cswrap are produced by make-srpm.sh
>> maintained in the upstream git repositories.
>
> https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Maintenance_and_Canonicity
>
> Not saying it contradicts the guideline above, just FYI.
>

In practice, there are several projects that blatantly ignore this.
Off the top of my head:

* OpenStack libraries and client packages (RDO)
* libvirt stack packages (excluding php-libvirt, as I maintain that
and have no rights to the libvirt-php repo)
* Cockpit packages

There's some hand-waviness with a few that I know of:

* Many PHP stack packages maintained by Remi (remirepo<->fedora)
* Compiler/toolchain packages (SCLized for non-Fedora)

I'm somewhat doing this with one package:
* snapd (Fedora is the canonical location, but changes are synced
between upstream and Fedora regularly for upstream CI support)


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Escaping macros in %changelog

[Igor Gnatenko]

-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

There might be valid use-cases, but I'm not sure if they really are:
%{_localstatedir}/ft/ → %%{_localstatedir}/ft/


Thoughts?
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlp8dIIACgkQaVcUvRu8
X0zOaA//WIbQAPp0ZjyWEEVAOl3d0EsG6y2Pk38B2K2ubFY8SYzJzpaZdAv3Lkdz
wJDA0rSdLrfNGRKzuEIpciGX03tCRSGENg6XeUT4mGjFPIsN467F0sC9RHkH5nWM
2H1weD4K1MeukqcvEWU8vJjyB+Wqd8qtFKGgpypp+d5jMh1ZOCeJbul4raRzQjGu
mvIVI1Qvg9x/3ZdNKk1GQdBslVRZqq/r+QLubkFjq04abAW1E3Dr5rFnRN+fWhQ7
E56UcuWxuJk21JG6LxRjNeDCMvqwHMZ44So1MqxIxGTPVHlucustNTnJwVFSLMEm
j7iPN4o9PxKew786Pm0/ggw6b49Y1w4ElzdFX6sfzQG4tAWu5Pa10paqUZyn/4IR
RpqQhOyhXjqv1DxN5z+CGvgZNps/CtIXTE9HNG1Gs1bi3taX4tHOh8bpXVlj+ocw
+03Q67LrgFVaqYaKfxW1jgfuvCRWUu3mdz16tx0W5ZuMkDgsq9H6ByYcVR8v/4Ly
W+jL/H6kYzzviCu6k+hlOGccw9PKuhN9Iwg2wmQ100QiKIU58SKlb27YqlmRDVLz
12jl1R9qzLwR9A+yDbkQqxABPKNvOdY4RPOoqMKVGb0ZRuwMsVDLofVYpcnCBfIB
wd8Rs9Kj36PxOO+HrHXKF05qRy2hOYiniS4XncmqPiFitd8GPQ4=
=rcey
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Clean up your spec files

[Vít Ondruch]

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 example specfile maintained by upstream, usable
>>> not
>>> only by Fedora.
>> Theoretically you may be right. In practice  .. nope.
>> There is no any reasons to use in Fedora spec file which is not
>> readable/simple as it is only possible because someone who is not focused
>> on Fedora want to make it universal without testing it on all possible
>> distributions on every new version released.
>>
>> kloczek
> 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
>
> Spec files of csdiff, cscppc, csmock, and cswrap are produced by make-srpm.sh 
> maintained in the upstream git repositories.

https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Maintenance_and_Canonicity

Not saying it contradicts the guideline above, just FYI.


V.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Clean up your spec files

[Rob Crittenden]

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
> only by Fedora.
> 
> 
> Theoretically you may be right. In practice  .. nope.

On what do you base your assertion? Are you saying that nobody does this?

> There is no any reasons to use in Fedora spec file which is not
> readable/simple as it is only possible because someone who is not
> focused on Fedora want to make it universal without testing it on all
> possible distributions on every new version released.
Or it may be due to complex spec files that are difficult to diff
between releases so maintaining them in one place (upstream) is far more
efficient and less error-prone.

rob
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Clean up your spec files

[Kamil Dudka]

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
> > not
> > only by Fedora.
> 
> Theoretically you may be right. In practice  .. nope.
> There is no any reasons to use in Fedora spec file which is not
> readable/simple as it is only possible because someone who is not focused
> on Fedora want to make it universal without testing it on all possible
> distributions on every new version released.
> 
> kloczek

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

Spec files of csdiff, cscppc, csmock, and cswrap are produced by make-srpm.sh 
maintained in the upstream git repositories.

Kamil
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Request to unretire Compton

[Abhiram Kuchibhotla]

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.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Clean up your spec files

[Tomasz Kłoczko]

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.
There is no any reasons to use in Fedora spec file which is not
readable/simple as it is only possible because someone who is not focused
on Fedora want to make it universal without testing it on all possible
distributions on every new version released.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: glibc, riscv64, multilib, /lib64 etc

[Richard W.M. Jones]

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 really care about,
> it'll use /lib64/lp64d/libc.so.6.
> 
> For Fedora we've settled on supporting only RV64GC as a baseline,
> which means we don't care about hardware which lacks floating point,
> nor 32 bit-only hardware since that is likely to be embedded and too
> small to run Linux (32 bit embedded hardware is best served by
> cross-compilers).  Also because this is a new architecture there is no
> legacy of 32 bit binaries that we need to run.
> 
> It's possible to change this by building glibc with
> 
>   ./configure --libdir=/lib64 [etc]
> 
> but it seems that /lib64/lp64d/ is still the default search path
> (/lib64 is not searched) even when configuring it like that, so it's a
> bit broken.
> 
> The question is how does this impact Fedora?  I'm fairly sure we
> don't want to change most libraries so they put stuff in /lib64/lp64d/
> nor do we want to change %{_libdir} on this one architecture.
> 
> We could do a downstream patch.
> 
> We could try to change upstream, but this is all now burned into the
> glibc 2.27 ABI so it's a bit complicated.
> 
> It's possible to use /usr/lib only on riscv64 (isn't that how s390x
> works too)?
> 
> Any thoughts?

Two other options omitted from this email are:

Add a symlink from /usr/lib64/lp64d -> /usr/lib64, mentioned a few
times in this thread.

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.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Clean up your spec files

[Kamil Dudka]

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 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 check your
> spec files:
> 
> * Group: System Environment/Base
> 
> Please remove it. Group was intended for something (sort apps in menus), but
> it never actually worked. It was required
> for EL5 packages. Since EL6 it
> can be omitted. And nowadays it is recommended to remove it completely. 
> 
> * rm -rf $RPM_BUILD_ROOT
> 
> In the past, it was necessary to clean the buildroot at the beginning of
> %install and the end of %clean. This is no
> longer true and not needed
> since F12.
> 
> * %defattr(-,root,root,-)
> 
> If you have this at the top of your %files section, then you can safely
> remove it. This is default since rpm 4.2, so it
> is not needed even for
> RHEL5.
> 
> * Buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
> 
> RPM define builroot variable since F12 (and EL6). There is no need to define
> it yourself.

While all the above things are safe to be removed in Fedora, they are pretty
much harmless.  I would not spend too much energy to remove them manually in
each single package.

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.

I would rather suggest to spend time on fixing spec file issues that may cause
real-world problems, such as C/C++ package being built in %install instead of
%build, or unescaped RPM macros in %changelog:

https://bugzilla.redhat.com/buglist.cgi?classification=Fedora&list_id=8392731&product=Fedora&query_format=advanced&short_desc=%25check%20RPM%20macro%20used%20in%20%25changelog%20needs%20to%20be%20escaped&short_desc_type=allwordssubstr

Kamil

> Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[HEADS UP] poppler-qt4 going away

[David Tardon]

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:

* diffpdf
- apparently not OSS anymore, so an update is unlikely

* kbibtex
- port to KF5 is in progress

* krop
- uses python-poppler-qt4
- unknown status

* ktikz
- port to KF5 is in progress

* python-poppler-qt4
- there is a Qt5 port at https://github.com/wbsoft/python-poppler-qt5
- btw, the project has moved from Google Code to
  https://github.com/wbsoft/python-poppler-qt4 and the Fedora package
  is a few releases behind

* qcomicbook
- 0.9.1, pushed to master yesterday, is ported to Qt5 :-)

* qpdfview
- builds both Qt4 and Qt5 version

* tellico
- 3.x is ported to KF5, but it's not in Fedora yet
- btw, the current version FTBFS because it depends on tcp_wrappers

D.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: cmake, mc unresponsive packagers

[Tomasz Kłoczko]

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
> > 
> >
> > One more time I'm asking for contact cmalke and mc maintainers.
>
> I'm the co-maintainer of 'cmake'. Let me check as as soon as Pagure
> becomes accessible again.
>

You know if maintainer and co-maintainers will be always reacting after
+month only after trying contact using a pressure of public communication,
only this could makes work on many packages even using git completely
pointless (now my PR needs to be rediffied and maybe only some small bits
will be possible to commit by cherry picking exact commits).
Looks like there is no any contact with primary cmake maintainer from quite
long time.
Only by this looks like already cmake.spec is quite messy.
So whatever you will do I still will be trying to takeover this package as
none of the co-maintainers started this up to now and none of them reacted
(doing proper actions) on PRs and/or bugzilla tickets.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Clean up your spec files

[Neal Gompa]

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


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Clean up your spec files

[Brett Lentz]

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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: glibc, riscv64, multilib, /lib64 etc

[Daniel P . Berrangé]

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
> >
> > 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 supporting only RV64GC as a baseline,
> > which means we don't care about hardware which lacks floating point,
> > nor 32 bit-only hardware since that is likely to be embedded and too
> > small to run Linux (32 bit embedded hardware is best served by
> > cross-compilers).  Also because this is a new architecture there is no
> > legacy of 32 bit binaries that we need to run.
> >
> > It's possible to change this by building glibc with
> >
> >   ./configure --libdir=/lib64 [etc]
> >
> > but it seems that /lib64/lp64d/ is still the default search path
> > (/lib64 is not searched) even when configuring it like that, so it's a
> > bit broken.
> >
> > The question is how does this impact Fedora?  I'm fairly sure we
> > don't want to change most libraries so they put stuff in /lib64/lp64d/
> > nor do we want to change %{_libdir} on this one architecture.
> >
> 
> I think this probably indicates we should figure out a way to support
> upstream layout.

Do we actually follow the upstream layout for our existing archs ?

The use of /lib64 instead of /lib is different to a number of other
Linux distros.

So if we've changed upstream defaults to always use  /lib64 for
the existing archs, that gives some precedence to override upstream
for riscv too to follow "normal" Fedora layout.

> > We could do a downstream patch.
> >
> > We could try to change upstream, but this is all now burned into the
> > glibc 2.27 ABI so it's a bit complicated.
> >
> 
> I don't like this, and I think it's probably a bad idea to try to change this.
> 
> > It's possible to use /usr/lib only on riscv64 (isn't that how s390x
> > works too)?
> >
> 
> No, the only arch that ever did this was Alpha. All currently
> supported 64-bit arches use /usr/lib64 for the 64-bit libraries.
> 

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: glibc, riscv64, multilib, /lib64 etc

[Richard W.M. Jones]

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
> >
> > 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 supporting only RV64GC as a baseline,
> > which means we don't care about hardware which lacks floating point,
> > nor 32 bit-only hardware since that is likely to be embedded and too
> > small to run Linux (32 bit embedded hardware is best served by
> > cross-compilers).  Also because this is a new architecture there is no
> > legacy of 32 bit binaries that we need to run.
> >
> > It's possible to change this by building glibc with
> >
> >   ./configure --libdir=/lib64 [etc]
> >
> > but it seems that /lib64/lp64d/ is still the default search path
> > (/lib64 is not searched) even when configuring it like that, so it's a
> > bit broken.
> >
> > The question is how does this impact Fedora?  I'm fairly sure we
> > don't want to change most libraries so they put stuff in /lib64/lp64d/
> > nor do we want to change %{_libdir} on this one architecture.
> >
> 
> I think this probably indicates we should figure out a way to support
> upstream layout.

Probably the fastest way would be to tweak the spec file so that
/usr/lib64/lp64d is a symlink to /usr/lib64

Rich.

> > We could do a downstream patch.
> >
> > We could try to change upstream, but this is all now burned into the
> > glibc 2.27 ABI so it's a bit complicated.
> >
> 
> I don't like this, and I think it's probably a bad idea to try to change this.
> 
> > It's possible to use /usr/lib only on riscv64 (isn't that how s390x
> > works too)?
> >
> 
> No, the only arch that ever did this was Alpha. All currently
> supported 64-bit arches use /usr/lib64 for the 64-bit libraries.
> 
> > Any thoughts?
> >
> 
> Plenty. :)
> 
> 
> -- 
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: glibc, riscv64, multilib, /lib64 etc

[Neal Gompa]

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 about,
> it'll use /lib64/lp64d/libc.so.6.
>
> For Fedora we've settled on supporting only RV64GC as a baseline,
> which means we don't care about hardware which lacks floating point,
> nor 32 bit-only hardware since that is likely to be embedded and too
> small to run Linux (32 bit embedded hardware is best served by
> cross-compilers).  Also because this is a new architecture there is no
> legacy of 32 bit binaries that we need to run.
>
> It's possible to change this by building glibc with
>
>   ./configure --libdir=/lib64 [etc]
>
> but it seems that /lib64/lp64d/ is still the default search path
> (/lib64 is not searched) even when configuring it like that, so it's a
> bit broken.
>
> The question is how does this impact Fedora?  I'm fairly sure we
> don't want to change most libraries so they put stuff in /lib64/lp64d/
> nor do we want to change %{_libdir} on this one architecture.
>

I think this probably indicates we should figure out a way to support
upstream layout.

> We could do a downstream patch.
>
> We could try to change upstream, but this is all now burned into the
> glibc 2.27 ABI so it's a bit complicated.
>

I don't like this, and I think it's probably a bad idea to try to change this.

> It's possible to use /usr/lib only on riscv64 (isn't that how s390x
> works too)?
>

No, the only arch that ever did this was Alpha. All currently
supported 64-bit arches use /usr/lib64 for the 64-bit libraries.

> Any thoughts?
>

Plenty. :)


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

glibc, riscv64, multilib, /lib64 etc

[Richard W.M. Jones]

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 supporting only RV64GC as a baseline,
which means we don't care about hardware which lacks floating point,
nor 32 bit-only hardware since that is likely to be embedded and too
small to run Linux (32 bit embedded hardware is best served by
cross-compilers).  Also because this is a new architecture there is no
legacy of 32 bit binaries that we need to run.

It's possible to change this by building glibc with

  ./configure --libdir=/lib64 [etc]

but it seems that /lib64/lp64d/ is still the default search path
(/lib64 is not searched) even when configuring it like that, so it's a
bit broken.

The question is how does this impact Fedora?  I'm fairly sure we
don't want to change most libraries so they put stuff in /lib64/lp64d/
nor do we want to change %{_libdir} on this one architecture.

We could do a downstream patch.

We could try to change upstream, but this is all now burned into the
glibc 2.27 ABI so it's a bit complicated.

It's possible to use /usr/lib only on riscv64 (isn't that how s390x
works too)?

Any thoughts?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Clean up your spec files

[Germano Massullo]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: cmake, mc unresponsive packagers

[Antonio Trande]

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
>> 
>> 
>>
>> [..] 
>>
>> cmake:
>>   https://src.fedoraproject.org/rpms/cmake/pull-request/2
>> 
>>   https://bugzilla.redhat.com/show_bug.cgi?id=1530574
>> 
>>
>> mc
>>   https://bugzilla.redhat.com/show_bug.cgi?id=1536909
>> 
>>   https://src.fedoraproject.org/rpms/mc/pull-request/1
>> 
>>
>>
>> One more time I'm asking for contact cmalke and mc maintainers.
>>
>> kloczek
>> -- 
>> Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH*
>>
>>
> 
> I'm the co-maintainer of 'cmake'. Let me check as as soon as Pagure
> becomes accessible again.
> 

Sorry, i confused 'cmake3' (epel) for 'cmake'.
Martin already replied:
https://src.fedoraproject.org/rpms/cmake/pull-request/2#comment-5212

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Clean up your spec files

[Miroslav Suchý]

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 check your
spec files:

* Group: System Environment/Base

Please remove it. Group was intended for something (sort apps in menus), but it 
never actually worked. It was required
for EL5 packages. Since EL6 it can be omitted. And nowadays it is recommended 
to remove it completely.


* rm -rf $RPM_BUILD_ROOT

In the past, it was necessary to clean the buildroot at the beginning of 
%install and the end of %clean. This is no
longer true and not needed since F12.

* %defattr(-,root,root,-)

If you have this at the top of your %files section, then you can safely remove 
it. This is default since rpm 4.2, so it
is not needed even for RHEL5.

* Buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

RPM define builroot variable since F12 (and EL6). There is no need to define it 
yourself.

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: cmake, mc unresponsive packagers

[Tomasz Kłoczko]

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 you've mention that my email landed in you spam
folder I've send you yet another prv email asking for reply or action.
On non of those two emails I had replies (pub or prv).

I did not receive any Fedora notification and at the moment
src.fedoraproject.org is currently unavailable (maintenance?).

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pull requests for compat-gcc-34

[Jonathan Wakely]

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 so many times in the past.

"libstdc++ < 7.0.0" seems to be an attempt to ensure that an
ABI-compatible version of libstdc++ is used, and conservatively names
a version that is known to be compatible (rather than assuming that
all future versions will be compatible).

The libstdc++ from GCC 8.x is ABI compatible with 3.4.x, so bumping
the Requires: to 9.0.0 (allowing any GCC 8.x release) is fine.


Thank you for your review and the explanation, Jonathan.
Of course, the reason why I bumped to "libstdc++ < 8.0.0" is that
the version 8.0.0 has been pushed to Fedora only recently, after
I had written the patches.


I'd be tempted to simply remove the version, so just have
Requires: libstdc++, or maybe Requires: libstdc++ >= 3.4.0 because
it's unlikely that libstdc++ will introduce an ABI break before that
spec file becomes obsolete. But maybe I'm not conservative enough :-)


What about the things like:

Requires: libstdc++.so.6

or

Requires: libstdc++.so.6(GLIBCXX_3.4)

?


Ah yes, good idea. That is a more precise requirement.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: cmake, mc unresponsive packagers

[Antonio Trande]

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
> 
> 
> 
> [..] 
> 
> cmake:
>   https://src.fedoraproject.org/rpms/cmake/pull-request/2
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1530574
> 
> 
> mc
>   https://bugzilla.redhat.com/show_bug.cgi?id=1536909
> 
>   https://src.fedoraproject.org/rpms/mc/pull-request/1
> 
> 
> 
> One more time I'm asking for contact cmalke and mc maintainers.
> 
> kloczek
> -- 
> Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH*
> 
> 

I'm the co-maintainer of 'cmake'. Let me check as as soon as Pagure
becomes accessible again.

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: cmake, mc unresponsive packagers

[Tomasz Kłoczko]

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.redhat.com/show_bug.cgi?id=1536909
>   https://src.fedoraproject.org/rpms/mc/pull-request/1
>

One more time I'm asking for contact cmalke and mc maintainers.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH *
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: koji build failure

[Vít Ondruch]

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 in glib2 2.55.2-2; can you try
> submitting your build again?
>

I think this is relevant BZ:

https://bugzilla.redhat.com/show_bug.cgi?id=1541318


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org