#5924: CPUID flags on buildvm-20.phx2.fedoraproject.org
by Fedora Release Engineering
#5924: CPUID flags on buildvm-20.phx2.fedoraproject.org
-----------------------------+------------------------
Reporter: jakub | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 21 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
In the gcc-4.9.0-12.fc21 build logs I saw a weird error:
/builddir/build/BUILD/gcc-4.9.0-20140619/obj-x86_64-redhat-linux/gcc/xgcc
-B/builddir/build/BUILD/gcc-4.9.0-20140619/obj-x86_64-redhat-linux/gcc/
/builddir/build/BUILD/gcc-4.9.0-20140619/gcc/testsuite/gcc.target/i386/pr57275.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -march=native
-lm -o ./pr57275.exe
/builddir/build/BUILD/gcc-4.9.0-20140619/gcc/testsuite/gcc.target/i386/pr57275.c:1:0:
error: CPU you selected does not support x86-64 instruction set
and I'd like to debug that, but don't know of a way to force e.g. a
scratch rpm build to a particular build host. Would it be possible for
some release engineer to run
gcc -v -march=native -S -xc /dev/null -o /tmp/foo.s
cat /proc/cpuinfo
in the F21 mock chroot on that box? Perhaps we are missing something in
the -m{arch,tune}=native logic,
a CPU which clearly does support x86_64 64-bit ISA should not be
determined as one that does not.
Thanks.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5924>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
9 years, 1 month
#6056: Branched: no images/ or LiveOS/ directory created due to package conflicts
by Fedora Release Engineering
#6056: Branched: no images/ or LiveOS/ directory created due to package conflicts
-----------------------------+------------------------
Reporter: kparal | Owner: rel-eng@…
Type: defect | Status: new
Milestone: Fedora 21 Final | Component: mash
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
20141125 is the last day we have images/, LiveOS/ and similar directories:
http://koji.fedoraproject.org/mash/branched-20141125/21/x86_64/os/
After that, only Packages/ and repodata/ are available:
http://koji.fedoraproject.org/mash/branched-20141127/21/x86_64/os/
The log says:
{{{
yum.verbose.YumBase.INFO_2: Running Transaction Check
pylorax.ltmpl.ERROR: template command error in runtime-install.tmpl:
pylorax.ltmpl.ERROR: run_pkg_transaction
pylorax.ltmpl.ERROR: YumRPMCheckError: [u'ERROR with transaction check
vs depsolve:', 'fedora-productimg-cloud conflicts with fedora-productimg-
workstation-21-6.fc21.noarch', 'fedora-productimg-server conflicts with
fedora-productimg-workstation-21-6.fc21.noarch', 'fedora-productimg-server
conflicts with fedora-productimg-cloud-21-6.fc21.noarch', 'fedora-
productimg-workstation conflicts with fedora-productimg-
cloud-21-6.fc21.noarch', 'fedora-productimg-cloud conflicts with fedora-
productimg-server-21-6.fc21.noarch', 'fedora-productimg-workstation
conflicts with fedora-productimg-server-21-6.fc21.noarch']
pylorax.ltmpl.DEBUG: Traceback (most recent call last):
pylorax.ltmpl.DEBUG: File "/usr/lib/python2.7/site-
packages/pylorax/ltmpl.py", line 508, in run_pkg_transaction
pylorax.ltmpl.DEBUG: rpmDisplay=LoraxRpmCallback())
pylorax.ltmpl.DEBUG: File "/usr/lib/python2.7/site-
packages/yum/__init__.py", line 6469, in processTransaction
pylorax.ltmpl.DEBUG:
self._doTestTransaction(callback,display=rpmTestDisplay)
pylorax.ltmpl.DEBUG: File "/usr/lib/python2.7/site-
packages/yum/__init__.py", line 6548, in _doTestTransaction
pylorax.ltmpl.DEBUG: raise Errors.YumRPMCheckError,retmsgs
pylorax.ltmpl.DEBUG: YumRPMCheckError: [u'ERROR with transaction check
vs depsolve:', 'fedora-productimg-cloud conflicts with fedora-productimg-
workstation-21-6.fc21.noarch', 'fedora-productimg-server conflicts with
fedora-productimg-workstation-21-6.fc21.noarch', 'fedora-productimg-server
conflicts with fedora-productimg-cloud-21-6.fc21.noarch', 'fedora-
productimg-workstation conflicts with fedora-productimg-
cloud-21-6.fc21.noarch', 'fedora-productimg-cloud conflicts with fedora-
productimg-server-21-6.fc21.noarch', 'fedora-productimg-workstation
conflicts with fedora-productimg-server-21-6.fc21.noarch']
}}}
http://koji.fedoraproject.org/mash/branched-20141127/logs/x86_64.log
I'm not sure whether this affects our ability to create a full Fedora 21
release compose?
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6056>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
9 years, 1 month
#5959: Enable keep-alive connections for koji (primary and secondaries)
by Fedora Release Engineering
#5959: Enable keep-alive connections for koji (primary and secondaries)
-----------------------------+------------------------
Reporter: till | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 20 Final | Component: koji
Keywords: meeting | Blocked By:
Blocking: |
-----------------------------+------------------------
Keeping connections alive will speed up koji acces when multiCall() is not
used without a significant speed penalty. Therefore it is a good idea to
support this.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5959>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
9 years, 1 month
Lookaside: Move away from md5
by Mathieu Bridon
We should move to something more secure than md5 for the uploaded sources.
This patch series implements the client-side part of this change.
We might want to drop the md5 fallback once we have migrated completely, that
is when:
1. all archives on the lookaside have been moved to a stronger hash
2. the "sources" file in all git repos has been updated to the same hash
https://fedorahosted.org/rel-eng/ticket/5846
9 years, 2 months
#5846: move away from md5 for look-aside cache
by Fedora Release Engineering
#5846: move away from md5 for look-aside cache
------------------+------------------------
Reporter: till | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: other
Keywords: | Blocked By:
Blocking: |
------------------+------------------------
The lookaside cache uses md5, but something more secure like sha-256 or
sha-512 should be used instead. Maybe it should even be made to allow easy
changes in the future.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5846>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
9 years, 2 months
#5992: Create new fedora-ca certificates without SHA1
by Fedora Release Engineering
#5992: Create new fedora-ca certificates without SHA1
-----------------------------+------------------------
Reporter: till | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 20 Final | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Currently .fedora-server-ca.cert and .fedora-upload-ca.cert use SHA1 for
their self-signatures. Since SHA1 support is phased out, it might be a
good idea to re-create the signatures.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5992>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
9 years, 2 months
#6023: allow Peter Robinson to restart sigul bridges
by Fedora Release Engineering
#6023: allow Peter Robinson to restart sigul bridges
-----------------------------+------------------------
Reporter: till | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 20 Final | Component: koji
Keywords: meeting | Blocked By:
Blocking: |
-----------------------------+------------------------
The sigul bridges are very unstable, but currently nobody from Europe can
restart it, therefore it might be unusable for a long time until Dennis
Gilmore or Kevin Fenzi find the time to restart it. Especially to get the
autosigner run smoothly it would be better to have at least one more being
able to restart the bridges. Peter Robinson would be a good candidate.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6023>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
9 years, 2 months
#5654: Report full image creation for quality website updates
by Fedora Release Engineering
#5654: Report full image creation for quality website updates
-----------------------------+------------------------
Reporter: shaiton | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 19 Final | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Hi, we already discussed a bit about this issues with nirik, before the
F19 release day.
However, yesterday was worse as expected.
Please see the number of fixes:
https://git.fedorahosted.org/cgit/fedora-web.git/log/
(7 important fixes after the merge into prod aedf487eb).
== Summary of major issues:
* http://torrent.fedoraproject.org/spins/ changed to
http://torrent.fedoraproject.org/torrents and we had no idea about this.
* The naming scheme of the file changed which introduced a bug in our
spins website build as it is based against the Json file. We had to fix a
2 years old python code. And we did not know about this.
* Each release we have the 32 bit arch named i686 or i386, it's always
changing. We defined variables in order to help us maintain the websites..
And this does not help us. I know that it depends of the proc instruction
set. But where is the need to change that really? Could we avoid it?
Sooner or later we will drop 32 bit arch... Couldn't we define which arch
to stick with?
* We don't know before last minute if the Spin has built for GA and
therefore if it is going to be released. We need to check it manually. And
really, we can't do it all manually. (as lazy programmers we can't even
think about this).
* Even the spins name has changed in the past, which break our code and
already existing URLs. And then we need to define URL redirect... I hope
jam-kde won't be changed to jam-mate-compiz-fusion-dark at some point..
Just wondering...
* The secondary (ARM) path changed from Images/arm/ to Images/armhfp/.. I
understand the need to tell if it's using FP or not, but again we didn't
know about this before testing in prod.
That should not happen again. Please, help me define the best way to avoid
this. It could be improving SOP, or updating a file after each build..
whatever.
It's a probably wider collaboration issues as it is involving primary,
secondary, SIGs (spins, cloud).. But starting with Releng we can probably
sort this and define the smoother solution for all.
What we need in a simple way (script friendly) and easy to generate for
you is a way to get:
All image full name, path (if possible before release), size (not needed
for torrents), format (torrent, spin, dvd, cloud... whatever) and
checksum. What can't be available easily can have an easy process to get
them or at least we need to know how and when to get them.
The most important of course is the image full name. If we don't know that
this image exists (or died), we won't be able to update it.
Any brillant idea?
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5654>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
9 years, 3 months
#5978: Please create a f21-gnome side tag
by Fedora Release Engineering
#5978: Please create a f21-gnome side tag
-----------------------------+------------------------
Reporter: kalev | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 21 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Hi,
Please create a new f21-gnome side tag and build target. We'll be building
GNOME 3.13.91 early next week and this would help ensure it doesn't cause
instabilities in F21 proper while we're preparing it.
Thanks,
Kalev
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5978>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
9 years, 3 months
