As previously announced, releng has made a number of changes as part of
it's 2016 "flag day".
All package maintainers will want to make sure they have updated to
following package versions (some may be in testing as of this email):
Please also see the following links for up to date information:
The following changes were made:
* koji and the source lookaside were changed to use kerberos
instead of ssl certificates. All maintainers will need to:
to get a valid kerberos TGT and be able to authenticate to koji and
the lookaside upload cgi.
See the general kerberos information at:
for more details.
Additionally, via GSSAPI many browsers allow you to seamlessly login
to any of our ipsilon using applications simply by clicking on the
button ( bodhi, fedorahosted trac, elections, fedocal, mailman3, etc)
* koji now uses a well known cert for https.
* pkgs.fedoraproject.org now redirects to https://src.fedoraproject.org
that uses a well known cert. Please correct any links you use to use
https://src.fedoraproject.org for packages spec and patch files.
* rawhide builds now land in the f26-pending tag, where they are signed
added to the f26 tag for compose in the next rawhide compose. This
rawhide packages to be fully signed as well as a point where automated
can take place in the future.
* packages "sources" files now use sha512 by default instead of md5.
You will need the fedpkg update in order to create and use these new
Questions or concerns as always welcome at #fedora-admin on
or tickets at https://pagure.io/fedora-infrastructure.
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
= Proposed System Wide Change: Golang 1.8 =
* Jakub Čajka <jcajka AT redhat DOT com>
Rebase of Golang package to upcoming version 1.8 in Fedora 26,
including rebuild of all dependent packages.
== Detailed Description ==
Rebase of Golang package to upcoming version 1.8 in Fedora 26. Golang
1.8 is schedule to be released in Feb. Due to current nature of Go
packages, rebuild of dependent package will be required to pick up the
== Scope ==
* Proposal owners:
Rebase golang package in f26, help with resolving possible issues
found during package rebuilds.
* Other developers:
fix possible issues
* Release engineering:
As there is scheduled mass-rebuild, nothing should be required.
* List of deliverables: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Any idea what this is about?
To me that looks like a combination of several factors. First of all,
the backtrace generation likely used incorrect debuginfo data because
the backtrace is impossible. Stack corruption is unlikely to yield a
relatively consistent backtrace—iconv and gconv match up, only the nscd
and sunrpc functions in the middle do not make sense.
I got lucky and build ID 25ea1fd961cb2f5a38172614365bd4c1aacb01a6 refers
to the current version of /usr/lib64/gconv/ISO8859-1.so, so I could do
the disassembly manually.
The crash is in the gconv function, at address 0xb50:
b44: 49 39 d5 cmp %rdx,%r13
b47: 72 2a jb b73 <gconv+0x3e3>
b49: 48 89 d3 mov %rdx,%rbx
b4c: 48 83 c0 01 add $0x1,%rax
b50: 0f b6 50 ff movzbl -0x1(%rax),%edx
b54: 48 39 c5 cmp %rax,%rbp
b57: 89 53 fc mov %edx,-0x4(%rbx)
b5a: 75 e4 jne b40 <gconv+0x3b0>
b5c: 41 bb 04 00 00 00 mov $0x4,%r11d
b62: e9 1a ff ff ff jmpq a81 <gconv+0x2f1>
b67: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
Experimentation with GDB shows that this is in the part which converts
from ISO-8859-1, and it is the load from the input buffer. A crash at
this point is impossible because we have a bounds check in the gconv
implementation framework before this load.
However, iconv (the command) maps the input file, and something is
truncating that file, causing the SIGBUS error. This is just how mmap
works in POSIX, unfortunately.
Is there a way to discover who is submitting these crash reports and
what they are trying to do? I wonder if we should remove the mmap from
the iconv command, so that we would not crash in this case.
where is documented what system/hw is used on (primary) Koji builders?
I'm interested in memory, storage, filesystem, host operating system, guest
operating system (if those are VMs), etc.
The only thing I was able to find is version of mock in the log output.
FWIW, I'd like to reproduce hang in gnulib's test-lock  test case.
Unless I'm able to reproduce that somehow, I'll disable the test for the time
being (done in 'coreutils' and I guess elsewhere, too).
On Wed, 21 Dec 2016 00:18:47 +0100
Miro Hrončok <mhroncok(a)redhat.com> wrote:
> I've attached the list of failed packages (failed.txt). You can search
These are victims of python-oslo-sphinx, needs a new release:
You can debug mutter (used in gnome-shell) by setting its environment
variables. These need to be set prior to run gnome-shell, so if you
want to log into GNOME from GDM, you need to create a wrapper script
called from a desktop file in /usr/share/wayland-sessions.
FIXME: Putting the wrapper script and desktop file here would be helpful."
Any chance anyone with time and interest to fix the fixme here?