License tags of lm_sensors corrected
by Ondřej Lysoněk
Hi,
I've reviewed the licensing of lm_sensors and found the License tags to
be incorrect, so I corrected it.
Previously the License tags of all the subpackages was:
LGPLv2+ and GPLv3+ and GPLv2+ and Verbatim and Public Domain
Now the License tags read as follows.
lm_sensors: GPLv2+ and Verbatim and MIT
lm_sensors-devel: LGPLv2+ and Verbatim
lm_sensors-libs: LGPLv2+
lm_sensors-sensord: GPLv2+ and Verbatim and MIT
The actual license of the package did not change in the recent past,
only the License tags were corrected.
Best regards
Ondřej Lysoněk
5 years, 9 months
Adding pgadmin4 to Fedora repository
by Joseph D. Wagner
Fedora 28 launched with PostgreSQL 10. The PostgreSQL GUI tool in the
repository -- pgadmin3 -- only works through version 9.x. Hence, there
has been a loss of functionality that I have been trying to get back.
All of the prerequisites for pgadmin4 were taken care of here:
BUG 1380826 - Review Request: pgadmin4 - Management tool for PostgreSQL
https://bugzilla.redhat.com/show_bug.cgi?id=1380826
The developer created a working package in a branch here:
https://copr.fedorainfracloud.org/coprs/itamarjp/pgadmin4/build/772898/
However, it looks like the final step of actually adding pgadmin4 as a
package in the main repository didn't happen. (At least, I couldn't
find it the last time I checked.)
Could someone please help me through the next steps? What must be done
to get pgadmin4 into the repository?
I would really appreciate any help to get the GUI for PostgreSQL working
again.
Thanks.
Joseph D. Wagner
5 years, 10 months
Annobin: "causes a section type conflict with..."
by Jerry James
This afternoon, I received email from koschei, telling me that
polymake's builds have started to fail:
https://apps.fedoraproject.org/koschei/package/polymake?collection=f29
The failure is due to this:
/builddir/build/BUILD/polymake-3.2/include/core/polymake/internal/shared_object.h:410:9:
error: ‘void pm::shared_object<Object, TParams>::leave() [with Object
= pm::sparse2d::Table<pm::Rational, false,
(pm::sparse2d::restriction_kind)0>; TParams =
{pm::AliasHandlerTag<pm::shared_alias_handler>}]’ causes a section
type conflict with ‘const pm::perl::RegistratorQueue&
polymake::common::get_registrator_queue(polymake::mlist<T>,
std::integral_constant<pm::perl::RegistratorQueue::Kind, kind>) [with
Tag = polymake::common::GlueRegistratorTag;
pm::perl::RegistratorQueue::Kind kind =
(pm::perl::RegistratorQueue::Kind)1]’
void leave()
^~~~~
"Huh," I thought, "that's weird. Well, I'll look into that after I
kick off this mock build of openfst 1.6.8". Then the openfst build
also failed with the same kind of "section type conflict" error.
On a hunch, I added this to openfst.spec and tried again:
%undefine _annotated_build
The mock build succeeded. Did somebody just do something to annobin
today? If so, can you please undo it?
--
Jerry James
http://www.jamezone.org/
5 years, 10 months
sip-related build failures in rawhide
by Alexander Ploumistos
Hello,
A few days ago scidavis builds started failing in rawhide. Someone
mentioned here that sip was to blame for a number of such failures and
according to koschei they started to happen after the update from
sip-4.19.9-0.2.dev1805261119.fc29 to sip-4.19.12-2.fc29.
According to the logs[0], sip can't find a file:
sip: Unable to find file "QtCore/QtCoremod.sip"
which results in a number of files not getting generated.
Is this a bug in sip, do I need to change something in my spec file,
or should I contact upstream?
Best regards,
Alex
0. https://koji.fedoraproject.org/koji/taskinfo?taskID=28233105
5 years, 10 months