#5714: perl-DBD-AnyData retired
by Fedora Release Engineering
#5714: perl-DBD-AnyData retired
-----------------------------+------------------------
Reporter: spot | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 20 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Please block perl-DBD-AnyData in F20+. It FTBFS and upstream has no plans
to fix it.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5714>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
10 years, 2 months
#5214: Setup koji tags and repo for Docs
by Fedora Release Engineering
#5214: Setup koji tags and repo for Docs
-----------------------------+------------------------
Reporter: crantila | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 18 Alpha | Component: koji
Keywords: docs | Blocked By:
Blocking: |
-----------------------------+------------------------
Posted here as per [https://fedorahosted.org/fedora-
infrastructure/ticket/3320]
'''phenomenon'''
To support simpler and more robust updates to docs.fp.o, need to setup
koji to handle a new tag and repo for Docs.
'''implementation recommendation'''
<Sparks> What would be required to stand up a separate instance of koji
for Docs? <dgilmore> Sparks: why would you want a seperate instance?
<dgilmore> Sparks: i dont see any valid reason to do so <Sparks> dgilmore:
For the Docs website. Publican has the ability publish documentation from
packages (separate repo from the Fedora repo) for the website. We want to
replace the git repo that operates it now. <dgilmore> Sparks: and why does
that need a seperate koji? <Sparks> The git repo has gotten HUGE and is
becoming an issue. <dgilmore> Sparks: so, why does that mean a seperate
koji instance <dgilmore> Sparks: we could use a seperate tag and targets
in koji <dgilmore> i dont see why it would need its own koji <Sparks>
dgilmore: It's either that or try to get everyone setup as packagers.
<dgilmore> Sparks: get everyone setup as packagers <Sparks> dgilmore:
Except that they really won't be packagers. <dgilmore> Sparks: though you
dont need to be a a packager to get a koji cert <dgilmore> you just need
fas <dgilmore> Sparks: what would be the workflow? <Sparks> dgilmore:
Okay, and with that we can send packages through koji and tag them
separately? <Sparks> dgilmore: Basically we just tell Publican to build
the package and submit it to koji. The Publican software does all the
work. <dgilmore> Sparks: I still really dont know what your trying to do.
pretend im an idiot(not really that hard) and explain what it is and how
it should work <Sparks> dgilmore: I'm not far off... <Sparks> dgilmore: So
Publican will make an SRPM package, submit it to koji destined for a repo.
Our Publican backend will install those packages and publish the data to
the website. <Sparks> ...as I understand it <dgilmore> Sparks: so we would
need to set up seperate tags and tagets for it, defining a koji policy
allowing srpms to be built. likely we would add a new group to koji and
add people allowed to build docs to it and limit access to the
tags/targets to people in that group <dgilmore> Sparks: so its all doable
<Sparks> dgilmore: Well that's a lot easier. :) <Sparks> dgilmore: We
already have a group in FAS for people that should have access (docs-
publishers). Should I open a ticket? <dgilmore> Sparks: koji doesnt know
anything about fas <dgilmore> Sparks: please file a ticket. We wont be
able to make changes until after f17 is done <Sparks> dgilmore: That's
fine. We're not completely ready for the transition so after F17 would be
good. <Sparks> dgilmore: Thanks!
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5214>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
10 years, 3 months
#3624: fullfilelist changes
by Fedora Release Engineering
#3624: fullfilelist changes
-------------------------+--------------------------------------------------
Reporter: mmcgrath | Owner: rel-eng(a)lists.fedoraproject.org
Type: enhancement | Status: new
Milestone: | Component: other
Keywords: |
-------------------------+--------------------------------------------------
After each push, we need to run the following command:
rsync -r . > fullfilelist
This should overwrite the fullfilelist that's there and isn't very useful
at the moment:
http://download.fedora.redhat.com/pub/fedora/fullfilelist
We can't do this via a cron job, it has to go out after each push so it
needs to be added to those scripts.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3624>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
10 years, 3 months
#5418: Adopt policy that SCM request should be accepted from authorized users only
by Fedora Release Engineering
#5418: Adopt policy that SCM request should be accepted from authorized users only
--------------------+------------------------
Reporter: ppisar | Owner: rel-eng@…
Type: defect | Status: new
Milestone: | Component: git
Keywords: SCM | Blocked By:
Blocking: |
--------------------+------------------------
FESCo ticket [https://fedorahosted.org/fesco/ticket/981] moved to rel-eng
quee.
= Phenomenon
Release engineers proceed SCM request from non-authorized applicants.
= Background Analysis
spot added SCM change request for 4 packages he does not own nor co-
maintain and release engineer has processed the requests. The requests
were to create new branches owned by master owners.
Example [https://bugzilla.redhat.com/show_bug.cgi?id=835544#c7]:
{{{
From: Tom "spot" Callaway 2012-12-11 21:50:00 GMT
Package Change Request
======================
Package Name: perl-Pod-Markdown
New Branches: f16 f17
Owners: jplesnik mmaslano ppisar psabata
InitialCC: perl-sig
From: Jon Ciesla 2012-12-12 13:14:20 GMT
Git done (by process-git-requests).
}}}
This undermines regular maintainers' rights and obligations because they
cannot even be sure which branches their packages exist and which they are
responsible for. This conflicts with current policy for creating
additional branches on behalf third persons (the third person, owner of
new branch, asks current owner and current owner submits SCM request.)
= Implementation recommendation
Release engineers will accept SCM changes only from requesters who own or
co-maintaint the package.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5418>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
10 years, 4 months
#4084: gcc multiarch broken dep
by Fedora Release Engineering
#4084: gcc multiarch broken dep
-----------------------+----------------------------------------------------
Reporter: mschwendt | Owner: rel-eng(a)lists.fedoraproject.org
Type: defect | Status: new
Milestone: | Component: mash
Keywords: |
-----------------------+----------------------------------------------------
There is a discrepancy between what is pushed to stable dist repos and to
updates-testing. With the latest "gcc" test-update, F-14 is affected, too
(which means this is not specific to F-13).
gcc-gfortran.i686 is available in x86_64 development/14 but not x86_64
updates/testing/14. The version-specific dependency in it is unresolvable
deps if it isn't updated.
What is the cause of it? Can it be fixed in the compose tools? Or is a
self-"Obsoletes" (which is not arch-specific by default) in gcc-gfortran
the only cure?
http://download.fedora.redhat.com/pub/fedora/linux/development/14/x86_64/...
{{{
[ ] gcc-4.5.1-1.fc14.x86_64.rpm 13-Aug-2010 14:51 14M
[ ] gcc-c++-4.5.1-1.fc14.x86_64.rpm 13-Aug-2010 14:50 5.1M
[X] gcc-gfortran-4.5.1-1.fc14.i686.rpm 13-Aug-2010 14:56
4.4M
[ ] gcc-gfortran-4.5.1-1.fc14.x86_64.rpm 13-Aug-2010 14:54
5.0M
[ ] gcc-gnat-4.5.1-1.fc14.x86_64.rpm 13-Aug-2010 14:52
9.9M
[ ] gcc-java-4.5.1-1.fc14.x86_64.rpm 13-Aug-2010 14:56
4.0M
[ ] gcc-objc++-4.5.1-1.fc14.x86_64.rpm 13-Aug-2010 14:56
4.3M
[ ] gcc-objc-4.5.1-1.fc14.x86_64.rpm 13-Aug-2010 14:57
3.9M
[ ] libgcc-4.5.1-1.fc14.i686.rpm 13-Aug-2010 14:53 61K
[ ] libgcc-4.5.1-1.fc14.x86_64.rpm 13-Aug-2010 14:51 52K
[ ] libgcj-4.5.1-1.fc14.i686.rpm 13-Aug-2010 14:54 17M
[ ] libgcj-4.5.1-1.fc14.x86_64.rpm 13-Aug-2010 14:55 19M
[ ] libgcj-devel-4.5.1-1.fc14.i686.rpm 13-Aug-2010 14:50
1.5M
[ ] libgcj-devel-4.5.1-1.fc14.x86_64.rpm 13-Aug-2010 14:51
1.5M
[ ] libgcj-src-4.5.1-1.fc14.x86_64.rpm 13-Aug-2010 14:51
12M
}}}
http://download.fedora.redhat.com/pub/fedora/linux/development/14/x86_64/...
{{{
[ ] gcc-4.5.1-3.fc14.x86_64.rpm 07-Sep-2010 12:36 14M
[ ] gcc-c++-4.5.1-3.fc14.x86_64.rpm 07-Sep-2010 12:39 5.1M
[ ] gcc-gfortran-4.5.1-3.fc14.x86_64.rpm 07-Sep-2010 12:42
5.0M
[ ] gcc-gnat-4.5.1-3.fc14.x86_64.rpm 07-Sep-2010 12:31
9.9M
[ ] gcc-java-4.5.1-3.fc14.x86_64.rpm 07-Sep-2010 12:29
4.0M
[ ] gcc-objc++-4.5.1-3.fc14.x86_64.rpm 07-Sep-2010 12:35
4.3M
[ ] gcc-objc-4.5.1-3.fc14.x86_64.rpm 07-Sep-2010 12:34
3.9M
[ ] libgcc-4.5.1-3.fc14.i686.rpm 07-Sep-2010 12:33 62K
[ ] libgcc-4.5.1-3.fc14.x86_64.rpm 07-Sep-2010 12:33 52K
[ ] libgcj-4.5.1-3.fc14.i686.rpm 07-Sep-2010 12:29 17M
[ ] libgcj-4.5.1-3.fc14.x86_64.rpm 07-Sep-2010 12:35 19M
[ ] libgcj-devel-4.5.1-3.fc14.i686.rpm 07-Sep-2010 12:29
1.5M
[ ] libgcj-devel-4.5.1-3.fc14.x86_64.rpm 07-Sep-2010 12:37
1.5M
[ ] libgcj-src-4.5.1-3.fc14.x86_64.rpm 07-Sep-2010 12:41
12M
}}}
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4084>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
10 years, 4 months
#3761: add gpg signature for .treeinfo file and/or add CHECKSUM file for unsigned content of images
by Fedora Release Engineering
#3761: add gpg signature for .treeinfo file and/or add CHECKSUM file for unsigned
content of images
----------------------+-----------------------------------------------------
Reporter: jkeating | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: other
Keywords: meeting |
----------------------+-----------------------------------------------------
Description of problem:
Currently the only way to verify the contents of .treeinfo or the
installer
images is to download the .iso and the regarding -CHECKSUM file and check
it.
But e.g. preupgrade does not download the .iso but the *.img files, the
kernel
and the .treeinfo directly from a mirror. Therefore it is also not
possible to
easily verify these files. I guess the preupgrade way of updating is
somehow
popular, therefore it should be possible to do this securely.
I filed a bug against preupgrade for not verifying anything and not
announcing
this here: bug 509338
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3761>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
10 years, 4 months
#4267: collectd in EPEL
by Fedora Release Engineering
#4267: collectd in EPEL
----------------------+-----------------------------------------------------
Reporter: mmcgrath | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: mash
Keywords: |
----------------------+-----------------------------------------------------
Can we get collectd in EPEL set to disable multi-lib? It has become an
issue on EPEL where installing "collectd" via yum creates conflicts it
shouldn't.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4267>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
10 years, 5 months
#5702: several rel-eng scripts are missing proper license headers
by Fedora Release Engineering
#5702: several rel-eng scripts are missing proper license headers
-----------------------------+------------------------
Reporter: till | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 20 Alpha | Component: other
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
The scripts in the rel-eng git are not properly licensed, for example:
* need-rebuild.py
* buildbranched
* build_composeinfo
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5702>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
10 years, 5 months
#5748: Mash fails for i386
by Fedora Release Engineering
#5748: Mash fails for i386
-----------------------------+------------------------
Reporter: kparal | Owner: rel-eng@…
Type: defect | Status: new
Milestone: Fedora 20 Alpha | Component: mash
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
vmlinuz and initrd.img are missing for i386. Probably caused by this:
{{{
yum.YumBase.CRITICAL: installing package hdparm-9.43-5.fc20.i686 needs
1446MB on the / filesystem
yum.YumBase.CRITICAL: installing package ethtool-2:3.10-2.fc20.i686 needs
1446MB on the / filesystem
pylorax.ltmpl.ERROR: template command error in runtime-install.tmpl:
pylorax.ltmpl.ERROR: run_pkg_transaction
pylorax.ltmpl.ERROR: YumRPMTransError: Could not run transaction.
pylorax.ltmpl.DEBUG: Traceback (most recent call last):
pylorax.ltmpl.DEBUG: File "/usr/lib/python2.7/site-
packages/pylorax/ltmpl.py", line 488, in run_pkg_transaction
pylorax.ltmpl.DEBUG: rpmDisplay=LoraxRpmCallback())
pylorax.ltmpl.DEBUG: File "/usr/lib/python2.7/site-
packages/yum/__init__.py", line 6377, in processTransaction
pylorax.ltmpl.DEBUG:
self._doTransaction(callback,display=rpmDisplay)
pylorax.ltmpl.DEBUG: File "/usr/lib/python2.7/site-
packages/yum/__init__.py", line 6489, in _doTransaction
pylorax.ltmpl.DEBUG: self.runTransaction( cb=cb )
pylorax.ltmpl.DEBUG: File "/usr/lib/python2.7/site-
packages/yum/__init__.py", line 1830, in runTransaction
pylorax.ltmpl.DEBUG: errors=errors)
pylorax.ltmpl.DEBUG: YumRPMTransError: Could not run transaction.
}}}
http://koji.fedoraproject.org/mash/branched-20130826/logs/i386.log
The template needs more disk space configured.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5748>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
10 years, 6 months
#5636: Use a staging area for test composes and safe practices when naming them
by Fedora Release Engineering
#5636: Use a staging area for test composes and safe practices when naming them
-----------------------------+------------------------
Reporter: kparal | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 19 Final | Component: other
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Summary: There was a hiccup for F19 TC3 compose. First it was created with
an old anaconda, then it was deleted and created with a new anaconda. The
announcement was sent only afterwards. Unfortunately the mirrors do not
heed announcements, they periodically sync everything. For Brno office our
mirror synced the old TC3 -> we came to work -> saw TC3 announcement ->
saw TC3 on our local mirror -> tested the (outdated) TC3 version for the
whole day -> and *by pure chance* learned that we have been using an
outdated compose (and wasted a day's work) at the end of the day.
I don't mean to blame anyone. It was unfortunate, and I'd like to improve
our workflow to minimize a chance of that happening again.
I have heard a solution "If you download images before announcement, make
sure they match the upstream checksums after the announcement is out".
First, a lot of people (e.g. us) don't download images manually, our
mirror does. So this essentially means checking timestamps or checksums
for every compose that we sync. That 1) requires some time spent for
dozens of individuals 2) is error-prone, because *nobody* will do that
every time, like a machine. Can we do better?
I see two very simple solutions and they can be combined:
1. Use a "staging area" for new composes. It's really simple - create a
directory that is not world-readable (thus not mirrored) and create the
compose there. Once you are sure everything looks OK, move the compose to
the correct directory. The other benefit is that this is nearly atomic,
thus making sure we don't have half-synced mirrors.
2. Once something is public, don't change contents. It might happen that
we publish something in error. But this is the same situation as in source
tarballs for software projects. You can never change it, because you never
know if somebody hasn't downloaded it in the (albeit short) meantime. You
can delete, sure, but the fixed file/tarball/compose should always have a
bumped version. There's no problem in that, really. If TC3 is published in
error, delete it if you want, and create TC3.1 or TC4. It's just a safety
practice and we don't mind, really, quite the opposite. This is a risk-
prevention.
If we combine these approaches, I believe there is no actual increase in
your workload (these are just work approaches, but no extra load) and we
increase the reliability of our tools and processes.
Thanks.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5636>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
10 years, 6 months