rel-eng November 2012

rel-eng@lists.fedoraproject.org

2 participants
110 discussions

#5362: Use XZ for repository metadata compression
by Fedora Release Engineering 20 May '14

20 May '14

#5362: Use XZ for repository metadata compression -------------------------+------------------------ Reporter: elad | Owner: rel-eng@… Type: enhancement | Status: new Milestone: | Component: other Keywords: | Blocked By: Blocking: | -------------------------+------------------------ See [https://bugzilla.redhat.com/show_bug.cgi?id=700020 bug #700020] for details. I was informed that yum and createrepo already support xz compression for metadata, yet in Fedora still use bz2. We should probably switch repositories to use xz as well. I was told to talk with rel-eng, I hope this is the right place to do so. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5362> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 23

#5214: Setup koji tags and repo for Docs
by Fedora Release Engineering 21 Jan '14

21 Jan '14

#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

1 16

#3624: fullfilelist changes
by Fedora Release Engineering 20 Jan '14

20 Jan '14

#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

1 3

#4084: gcc multiarch broken dep
by Fedora Release Engineering 06 Jan '14

06 Jan '14

#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/os… {{{ [ ] 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/os… {{{ [ ] 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

1 9

#3761: add gpg signature for .treeinfo file and/or add CHECKSUM file for unsigned content of images
by Fedora Release Engineering 06 Jan '14

06 Jan '14

#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

1 2

#4267: collectd in EPEL
by Fedora Release Engineering 30 Nov '13

30 Nov '13

#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

1 4

#4324: Change product string in pungi for better syslinux usability
by Fedora Release Engineering 08 Aug '13

08 Aug '13

#4324: Change product string in pungi for better syslinux usability -------------------+-------------------------------------------------------- Reporter: duffy | Owner: rel-eng(a)lists.fedoraproject.org Type: task | Status: new Milestone: | Component: other Keywords: | -------------------+-------------------------------------------------------- Right now when you boot Fedora live media or otherwise call up Syslinux, you are greeted with: "Welcome to Fedora-14-x86_64-Live-Desktop!" It's not the most welcoming message though because the string is a bit unwieldy and hard-to-read. Syslinux pulls from the PRODUCT string produced via pungi: scripts/mk-images.x86: sed -i "s/@PRODUCT@/$PRODUCT/g" $MBD_BOOTTREE/syslinux.cfg I was hoping that string produced by pungi could be cleaned up a bit to be more friendly. Some examples I think that would be better: Fedora 14 (32-bit) Fedora 14 (64-bit) Fedora 14 (32-bit DVD) Fedora 14 (64-bit DVD) Fedora 14: KDE Plasma (32-bit) Fedora 14: KDE Plasma (64-bit) Fedora 14: LXDE (32-bit) Fedora 14: LXDE (64-bit) Fedora 14: Xfce (32-bit) Fedora 14: Xfce (64-bit) Fedora 14: Electronic Lab (32-bit) Fedora 14: Electronic Lab (64-bit) Fedora 14: Design Suite (32-bit) Fedora 14: Design Suite (64-bit) Fedora 14: Sugar on a Stick (32-bit) Fedora 14: Sugar on a Stick (64-bit) Fedora 14: Games Spin (32-bit) Fedora 14: Games Spin (64-bit) Fedora 14: Security Lab (32-bit) Fedora 14: Security Lab (64-bit) So the rules I'm suggesting for the strings: - The default desktop is called simply "Fedora $VERSION ($ARCH)" - Any non-default spins are called "Fedora $VERSION: $NAME_OF_SPIN ($ARCH)" - The spin name is derived from either the http://fedoraproject.org/en /get-fedora-options#desktops get.fpo options page or the spins.fedoraproject.org full name for the spin. (KDE is probably updating theirs to KDE Plasma as reflected in example strings above.) - Put the arch in () after the name of the spin. Where arch is '32-bit', '64-bit', 'Power PC', etc. The arch names here are suggested to be consistent with what the downloads are labeled on our main web pages (get.fpo and spins.fpo) - If it's live media, don't indicate that, don't point it out. Only indicate if it's a DVD. If it's DVD, point it out after the arch in the ( ) - $VERSION should be a whole number without decimals for a final release. For test releases / release candidates it would be nice to indicate something like, '14.92 RC1' '14.91 Nightly 06 Jan 2011' but that's up to your discretion! This is where the text will appear in syslinux: https://fedoraproject.org/w/uploads/3/3d/Installux-syslinux- prop1-proto1-ss2.png What do you think? -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4324> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 4

#3883: more meaningful error if module isn't found
by Fedora Release Engineering 17 Jul '13

17 Jul '13

#3883: more meaningful error if module isn't found -------------------------+-------------------------------------------------- Reporter: kalev | Owner: rel-eng(a)lists.fedoraproject.org Type: enhancement | Status: new Milestone: | Component: other Keywords: | -------------------------+-------------------------------------------------- Right now fedpkg fails with access denied message if there is not such module: {{{ $ fedpkg clone gtkmm30 R access for gtkmm30 DENIED to kalev }}} Would be nice to get a more meaningful error in that case, perhaps "module not found". Filing it in releng trac as the error is coming from gitolite, just being passed along by fedpkg. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3883> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 3

#5033: bodhi: unable to delete obsoleted update - internal server error
by Fedora Release Engineering 17 Jul '13

17 Jul '13

#5033: bodhi: unable to delete obsoleted update - internal server error ----------------------+------------------------ Reporter: jskarvad | Owner: rel-eng@… Type: defect | Status: new Milestone: | Component: other Keywords: | Blocked By: Blocking: | ----------------------+------------------------ memtest86+-4.20-3.fc16 update is obsoleted: https://admin.fedoraproject.org/updates/FEDORA-2011-16943/memtest86+-4.20-3… I tried to delete it by hitting the delete button, but it doesn't work: > 500 Internal error > > The server encountered an unexpected condition which prevented it from fulfilling > the request. > > Powered by CherryPy 2.3.0 -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5033> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

#5219: tomcat6 fedora/rawhide java dependency appears broken
by Fedora Release Engineering 17 Jul '13

17 Jul '13

#5219: tomcat6 fedora/rawhide java dependency appears broken -----------------------------+------------------------ Reporter: nkinder | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 18 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ <filing on behalf of dknox> Hi, I've performed scratch-builds of the current git contents for fedora tomcat6/rawhide (which built previously). The build is looking for java >= 1.6, fails, then installs gcj java 1.5. When R:java[-devel] >= 0:1.6.0 is specified (versus R:java) the error changes[2] and there is no attempt to install gcj (which I would expect). There are also several "already installed" comments which I don't recall having occured before. [2]http://koji.fedoraproject.org/koji/getfile?taskID=4159550&name=root.log [Open URL] [1] http://koji.fedoraproject.org/koji/getfile?taskID=4159499&name=root.log [Open URL] : <snip from [1]> DEBUG backend.py:862: ['/usr/bin/yum-builddep', '--installroot', '/var/lib/mock/f18-build-1363965-220904/root/', '/var/lib/mock/f18-build-1363965-220904/root///builddir/build/SRPMS/tomcat6-6.0.35-2.fc18.src.rpm'] DEBUG util.py:307: Executing command: ['/usr/bin/yum-builddep', '-- installroot', '/var/lib/mock/f18-build-1363965-220904/root/', '/var/lib/mock/f18-build-1363965-220904/root///builddir/build/SRPMS/tomcat6-6.0.35-2.fc18.src.rpm'] DEBUG util.py:257: Getting requirements for tomcat6-6.0.35-2.fc18.src DEBUG util.py:257: --> ant-1.8.3-2.fc18.noarch DEBUG util.py:257: --> ant-1.8.3-2.fc18.noarch DEBUG util.py:257: --> 1:ecj-3.4.2-13.fc18.x86_64 DEBUG util.py:257: --> Already installed : 1:findutils-4.5.10-5.fc18.x86_64 DEBUG util.py:257: --> apache-commons-collections-3.2.1-13.fc18.noarch DEBUG util.py:257: --> apache-commons-daemon-1.0.10-3.fc18.x86_64 DEBUG util.py:257: --> apache-commons-dbcp-1.4-9.fc18.noarch DEBUG util.py:257: --> apache-commons-pool-1.6-1.fc18.noarch DEBUG util.py:257: --> jakarta-taglibs-standard-1.1.2-4.fc18.noarch DEBUG util.py:257: --> java-1.5.0-gcj-devel-1.5.0.0-39.fc18.x86_64 DEBUG util.py:257: --> jpackage-utils-1.7.5-18.fc18.x86_64 DEBUG util.py:257: --> junit-4.10-5.fc18.noarch DEBUG util.py:257: --> log4j-1.2.17-1.fc18.noarch DEBUG util.py:257: --> Already installed : systemd-185-5.gita2368a3.fc18.x86_64 DEBUG util.py:257: Error: Package: apache-commons- daemon-1.0.10-3.fc18.x86_64 (build) DEBUG util.py:257: Requires: java >= 1:1.6.0 DEBUG util.py:257: Installing: java-1.5.0-gcj-1.5.0.0-39.fc18.x86_64 (build) DEBUG util.py:257: java = 1.5.0 DEBUG util.py:257: Error: Package: apache-commons-pool-1.6-1.fc18.noarch (build) DEBUG util.py:257: Requires: java >= 1:1.6.0 DEBUG util.py:257: Installing: java-1.5.0-gcj-1.5.0.0-39.fc18.x86_64 (build) DEBUG util.py:257: java = 1.5.0 DEBUG util.py:257: Error: Package: hamcrest-1.1-12.fc17.noarch (build) DEBUG util.py:257: Requires: java >= 1:1.6.0 DEBUG util.py:257: Installing: java-1.5.0-gcj-1.5.0.0-39.fc18.x86_64 (build) DEBUG util.py:257: java = 1.5.0 DEBUG util.py:257: Error: Package: junit-4.10-5.fc18.noarch (build) DEBUG util.py:257: Requires: java >= 1:1.6.0 DEBUG util.py:257: Installing: java-1.5.0-gcj-1.5.0.0-39.fc18.x86_64 (build) DEBUG util.py:257: java = 1.5.0 DEBUG util.py:257: Error: Package: qdox-1.12-4.fc17.noarch (build) DEBUG util.py:257: Requires: java >= 1:1.6.0 DEBUG util.py:257: Installing: java-1.5.0-gcj-1.5.0.0-39.fc18.x86_64 (build) DEBUG util.py:257: java = 1.5.0 DEBUG util.py:257: Error: Package: log4j-1.2.17-1.fc18.noarch (build) DEBUG util.py:257: Requires: java >= 1:1.6.0 DEBUG util.py:257: Installing: java-1.5.0-gcj-1.5.0.0-39.fc18.x86_64 (build) DEBUG util.py:257: java = 1.5.0 -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5219> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng November 2012