Got an e-mail from Koschei  with a notice that camotics package is starting to fail to build. The reason for this seems to be that something that used to pull mesa-libEGL-devel doesn't do so anymore.
/usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No such file or directory
Since /usr/include/GL/glext.h belongs to mesa-libGL-devel and not camotics I think it would be more appropriate to put the dependency there. Thoughts?
| When a new package maintainer joins the Fedora Project, we request
that he/she introduces
| themselves on the Fedora devel
I am a programmer/maintainer of white_dune (
http://wdune.ourproject.org/ ) and i am trying to
include it into fedora.
I got the following mail
basset<admin+basset(a)fedoraproject.org> has sponsored you for membership in the cla_fpca
group of the Fedora account system. If applicable, this change should
propagate into the e-mail aliases and git repository within an hour.
but i don't know, if it is sufficent to build a fedora package.
Currently i have the following problem:
$ fedpkg --release f29 build --srpm rpmbuild/SRPMS/wdune-0.99-1.pl1216.fc29.src.rpm
Failed to get repository name from Git url or pushurl
[====================================] 100% 00:00:46 22.25 MiB 489.29 KiB/sec
Building wdune-0.99-1.pl1216.fc29.src.rpm for f29-candidate
Created task: 31387399
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=31387399
Watching tasks (this may be safely interrupted)...
31387399 build (f29-candidate, wdune-0.99-1.pl1216.fc29.src.rpm): free
31387399 build (f29-candidate, wdune-0.99-1.pl1216.fc29.src.rpm): free -> FAILED: ActionNotAllowed: policy violation (build_from_srpm)
0 free 0 open 0 done 1 failed
31387399 build (f29-candidate, wdune-0.99-1.pl1216.fc29.src.rpm) failed
Any ideas ?
Downstream, we had a separate set of builds flags for certain packages
and used -O3 there, targeted at POWER (both ppc64 and ppc64le), for
increased use of vectorization presumably.
I don't think this was ever upstreamed to Fedora (the downstream changes
were in the redhat-rpm-config package). I don't recall seeing a
corresponding Fedora change. As a result, the recent downstream rebase
lost support for this.
Should Fedora package maintainers remove _performance_build support or
custom flag overrides for -O3 from their packages?
My understanding is that Fedora build flag policy is set by the
redhat-rpm-config package, which currently specifies -O2 for all
during packaging of a new python-img2pdf version I noticed that 2
unit-test cases fail on aarch64.
This is caused by zlib.compress() yielding different output on aarch64
and x86-64. Which triggers the failure because the unit-test case just
compares the result after compression (it's a small PDF that contains a
compressed image - and that PDF is compared against a reference PDF).
I checked the aarch64 compress output and it's valid zlib data, i.e. I can
decompress it on both aarch64 and x86-64 and get the same decompression
result (i.e. the input image data).
As far as I understand RFC 1951, it allows for different implementations
to yield differing compress output bit-streams - as long as other
requirements are met and uncompress(compress(x)) == x (in any
combination of implementations).
Funnily, the img2pdf author uses Debian, and Debian aarch64
zlib.compress() *does* yield bit-identical output (to x86-64). Perhaps
the deviating Fedora aarch64 behaviour is due to different compile
options/patches (e.g. some Neon optimization or something like that).
The img2pdf author isn't really convinced that zlib may produce
different output on different architectures:
'I have long really held the opinion that the amount of noise
which any one can bear undisturbed stands in inverse proportion
to his mental capacity, and therefore may be regarded as a pretty
fair measure of it.' (Arthur Schopenhauer, The World As Will And
Idea. Vol. 2, p.199, 1883)
A few minutes ago I was notified about a post in a closed bug. It
turns out that the account that made the post has been sporadically
spamming various bugs:
The websites that are being linked to from these posts seem to be of
the support scam garden variety.
I did not know where to report this, hence this message.
Can someone nuke the posts or at least the hyperlinks?
Btw, bugzilla reports that there are multiple accounts with the same
name, so that might be worth looking into.