Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2016-03-03 17:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. rktime):
2016-03-03 09:00 Thu US/Pacific PST
2016-03-03 12:00 Thu US/Eastern EST
2016-03-03 17:00 Thu UTC <-
2016-03-03 17:00 Thu Europe/London <-
2016-03-03 18:00 Thu Europe/Paris CET
2016-03-03 18:00 Thu Europe/Berlin CET
2016-03-03 22:30 Thu Asia/Calcutta IST
------------------new day----------------------
2016-03-04 01:00 Fri Asia/Singapore SGT
2016-03-04 01:00 Fri Asia/Hong_Kong HKT
2016-03-04 02:00 Fri Asia/Tokyo JST
2016-03-04 03:00 Fri Australia/Brisbane EST
Links to all tickets below can be found at:
https://fedorahosted.org/fpc/report/13
= Followups =
#topic #558 Application/Library distinction and package splitting
.fpc 558
https://fedorahosted.org/fpc/ticket/558
#topic #566 RPM file triggers
.fpc 566
https://fedorahosted.org/fpc/ticket/566
#topic #598 introduce pyp2rpm tool on Packaging:Python page
.fpc 598
https://fedorahosted.org/fpc/ticket/598
= New business =
#topic #600 %systemd_requires macro
.fpc 600
https://fedorahosted.org/fpc/ticket/600
#topic #601 Standard macro for RPM macro directory
.fpc 601
https://fedorahosted.org/fpc/ticket/601
#topic #602 Mono packages must have ExclusiveArch: %{mono_arches}
.fpc 602
https://fedorahosted.org/fpc/ticket/602
#topic #605 Bootstrapping exception for GPRbuild
.fpc 605
https://fedorahosted.org/fpc/ticket/605
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
https://fedorahosted.org/fpc/report/13
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
I've been struggling this evening with building a particular package
into the EPEL7 repositories. At first I thought I was just going
bonkers, but I think I've narrowed down a particular behavior's cause.
At least the only cause of it that I can see.
The package in question is rubygem-activesupport and the build is
supposed to be a noarch, as the package is pure Ruby. Building locally
in a mock environment has worked without fail all evening long, but
building in Koji was giving me some issues. After eliminating
mismatched packages from the two environments by tagging one of my
prior builds into the buildroot and limiting minimum dependency
version, I was still seeing a mismatch. My local builds were still
fine, but the builds in Koji kept failing, both straight builds and
scratch builds.
Links to the failed scratch builds:
https://koji.fedoraproject.org/koji/taskinfo?taskID=13171824https://koji.fedoraproject.org/koji/taskinfo?taskID=13171578
And failed source build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=13171784
And my succeeded scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=13171627
And the successful source build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=13171904
Note that nothing of consequence changed in the spec file between any
of these builds. In fact, during the two source builds NOTHING changed
in git. However, the only difference that I can see is that all of the
failed builds occurred on either VMs or PPC machines and the
successful builds all took place on hardware boxes.
I'm not sure if this is a koji thing, a Fedora/EPEL thing, or maybe
even a core Ruby thing.
Has anyone else experienced similar strange behaviors?
--Greg
Hi,
The mail "[Red Hat Bugzilla] Your Outstanding Requests" is showing me
these items since some time ago.
These seems to have the NEEDINFO flag, but they are CLOSED (and
several releases ago).
Should the closure of the bugreport have cancelled or provided the NEEDINFO?
I really want to get rid of this list.
Thanks in advance.
~~~
List of bugs:
* https://bugzilla.redhat.com/show_bug.cgi?id=869360
Bug 869360 - IndexError: list index out of range [NEEDINFO]
CLOSED WONTFIX
* https://bugzilla.redhat.com/show_bug.cgi?id=887563
Bug 887563 - anaconda manual partitioning created partitions are not
being shown in any tree ('biosboot' and 'prepboot') [NEEDINFO]
CLOSED INSUFFICIENT_DATA
* https://bugzilla.redhat.com/show_bug.cgi?id=947616
Bug 947616 - anaconda validate architecture from remote installation
sources (one can boot X86_64 dvd media and install a 32-BIT one via
NFS Installation Source) [NEEDINFO]
CLOSED NOTABUG
* https://bugzilla.redhat.com/show_bug.cgi?id=869785
Bug 869785 - F18b TC6 on KVM GUEST "invalid opcode: 0000 [#1] SMP" [NEEDINFO]
CLOSED INSUFFICIENT_DATA
* https://bugzilla.redhat.com/show_bug.cgi?id=868065
Bug 868065 - [abrt] iftop-1.0-0.2.pre2.fc17: PROTO_ADDRESS_SIZE:
Process /usr/sbin/iftop was killed by signal 6 (SIGABRT) [NEEDINFO]
CLOSED ERRATA
* https://bugzilla.redhat.com/show_bug.cgi?id=948369
Bug 948369 - LVMError: lvresize failed for root: running lvm
lvresize (anaconda custom partitioning 'reformat' a lvm root having
changing the partition scheme to standard partition results in crash
during installation) [NEEDINFO]
CLOSED INSUFFICIENT_DATA
* https://bugzilla.redhat.com/show_bug.cgi?id=961515
Bug 961515 - SwapError: mkswap failed for
'/dev/mapper/fedora_fnext--tst2-swap' [NEEDINFO]
CLOSED INSUFFICIENT_DATA
* https://bugzilla.redhat.com/show_bug.cgi?id=969667
Bug 969667 - anaconda 'begin installation' button is unlocked with
Storage: Installation Destination in state 'no disks selected'
[NEEDINFO]
CLOSED INSUFFICIENT_DATA
* https://bugzilla.redhat.com/show_bug.cgi?id=961138
Bug 961138 - red banner (failed to add device) trying to add a mount
point after filling up a previous LVM VG which is restricted to
certain disks and the new mount point should use other free disks
[NEEDINFO]
CLOSED INSUFFICIENT_DATA
i just stumbled over the following error while using bodhi on f22:
 bodhi --buildroot-override=openvas-libraries-8.0.7-2.f22 --duration=2
--notes='new libraries needed for new manager'
No handlers could be found for logger "fedora.client.bodhi"
Traceback (most recent call last):
 File "/usr/bin/bodhi", line 537, in <module>
    main()
 File "/usr/bin/bodhi", line 433, in main
    }, auth=True)
 File "/usr/lib/python2.7/site-
packages/fedora/client/openidbaseclient.py", line 240, in send_request
    output = func(method, **kwargs)
 File "/usr/lib/python2.7/site-
packages/fedora/client/openidbaseclient.py", line 78, in _decorator
    output = func(request, *args, **kwargs)
 File "/usr/lib/python2.7/site-
packages/fedora/client/openidbaseclient.py", line 195, in _authed_post
    response = self._session.post(url, params=params, data=data,
**kwargs)
 File "/usr/lib/python2.7/site-packages/requests/sessions.py", line
511, in post
    return self.request('POST', url, data=data, json=json, **kwargs)
TypeError: request() got an unexpected keyword argument 'req_params'
there seem to be several tickets open for that, but no visible
progress. tickets in trac and bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1278742https://fedorahosted.org/bodhi/ticket/790
the webpage is by no means a substitute for the cli.
josef
Hi there,
I just pushed openssh-7.2 update [1] into Fedora 23 testing. There are
no incompatible changes except these:
* the minimum modulus size supported for diffie-hellman-group-exchange
was increased to 2048 bits,
* several legacy cryptographic algorithms and MD5-based and truncated
HMAC algorithms were disabled on client side.
which might be some trouble when connecting to old systems. If you need
to use some of these fancy ciphers or HMACs, you need to configure your
client to use them explicitly, for example:
ssh -o Ciphers=+blowfish-cbc -o MACs=+hmac-md5-96 your_host
or store appropriate values to the ~/.ssh/config. SSH should now also
yield reasonable messages when it was not able to negotiate particular
algorithms.
My tests passed and the package is already for few days in rawhide and
f24, but another testing would be appreciated, especially quick check if
some of your common use cases are not disturbed. And there are also some
fancy features you might want to give a try such ad-hoc adding keys to
ssh-agent or new keyword restrict to use in authorized_keys file [2].
Thanks for attention and have a great day,
[1] https://bodhi.fedoraproject.org/updates/openssh-7.2p1-1.fc23
[2] http://www.openssh.com/txt/release-7.2
--
Jakub Jelen
Security Technologies
Red Hat
…
> # Compiling needs too much memory to build the the linker-objects in
> # virtual memory for piping through different gcc instances, thus we
> # use temporary files instead of pipes to pass the results.
> %global optflags \
> %(echo '%{optflags}' | %{__sed} -e 's![ \t]*-pipe[ \t]*! !g')
May that (or removing/adding another gcc/clang option) to the ICU x86 problem, too?
https://bugzilla.redhat.com/show_bug.cgi?id=1307633
I have a package that struggles to build on 32 bit x86 and arm because
the compiler tends to use so much memory that the builder runs out of
memory.
Upstream is aware of the issue, and mentioned that clang uses
considerably less memory to build the problem file so I thought I would
see if building with clang would work.
Unfortunately although it works on F23 I always seem to get link errors
when building with rawhide:
clang++ -o test/standalone/agg_rasterizer_integer_overflow_test-bin
-pthread test/standalone/agg_rasterizer_integer_overflow_test.o
-Ldeps/agg -Lsrc -Lsrc/json -Lsrc/wkt -L/usr/lib -L/usr/lib64 -lmapnik
-lmapnik-wkt -lmapnik-json -lagg -lboost_filesystem -lboost_regex
-lcairo -lpng -lproj -ltiff -lwebp -lxml2 -licui18n -lboost_system
-lharfbuzz -ljpeg -licuuc -lfreetype -lz -ldl -lboost_program_options
src/libmapnik.so: undefined reference to
`std::ios_base::failure::failure(char const*, std::error_code const&)'
clang-3.8: error: linker command failed with exit code 1 (use -v to see
invocation)
That's from this build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=13160432
Is building packages with clang actually allowed and/or expected to
work? The C/C++ guidelines seem to suggest it is given that they say you
should require either gc or clang.
As far as I can see the symbol being complained about does exist, though
with an abi tag in libstdc++ (but that is true in F23 as well).
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/