August 2013 - rel-eng - Fedora mailing-lists

#5665: Providing a master CHECKSUMS file for boot.fpo
by Fedora Release Engineering 29 Apr '15

29 Apr '15

#5665: Providing a master CHECKSUMS file for boot.fpo -----------------------------+------------------------ Reporter: shaiton | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Alpha | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Hi, as requested to webmasters[1], could we get a CHECKSUMS file (as provided for other Fedora releases) including all checksums? It also needs to be signed of course. You might decide that it is not needed, just forwarded the query. [1] https://lists.fedoraproject.org/pipermail/websites/2013-July/011535.html -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5665> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 3

#1107: auto-cleanup rawhide trees
by Fedora Release Engineering 29 Apr '15

29 Apr '15

#1107: auto-cleanup rawhide trees -------------------------+-------------------------------------------------- Reporter: notting | Owner: rel-eng(a)lists.fedoraproject.org Type: enhancement | Status: new Milestone: | Component: koji Keywords: | -------------------------+-------------------------------------------------- Rawhide tree expiry is manual at the moment, unless I missed something. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/1107> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 8

#5721: Need application icons and application descriptions
by Fedora Release Engineering 29 Apr '15

29 Apr '15

#5721: Need application icons and application descriptions ----------------------------+------------------------ Reporter: rhughes | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Beta | Component: koji Keywords: | Blocked By: Blocking: | ----------------------------+------------------------ Hi, For the application installer preview I need the application icons and localized description data. I had the fedora-app-data package NAKd, but something needs to provide this data. Spot seemed to think it would be okay to include as metadata. The idea is to: * Generate the appstream.xml and appstream.tar files on koji * xmlmerge the .xml files and cat the .tar files when mash'ing the compose together. I've got C code to do the former, although someone familiar with python probably wants to re-write the code before putting it into koji. For F20 we can probably just ship the 15 most popular application icons and descriptions in gnome-software, although this won't scale with all the apps in Fedora. Any questions, I'm hughsie on IRC. Thanks. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5721> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 19

#5678: koji package for cloud images so they can be non-scratch, and garbage collection policies for those packages
by Fedora Release Engineering 29 Apr '15

29 Apr '15

#5678: koji package for cloud images so they can be non-scratch, and garbage collection policies for those packages -----------------------------+------------------------ Reporter: mattdm | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Replying to [ticket:3897 mattdm]: > We want to generate non-scratch cloud images. Because of a bug, these currently need to have the name of the architecture in the package. That will be fixed in the Real Soon Future, but in the meantime I'd like to get going with what we have. Could we please create koji packages named > > {{{ > Fedora-19-cloud-x86_64 > Fedora-19-cloud-i386 > Fedora-20-cloud-x86_64 > Fedora-20-cloud-i386 > Fedora-rawhide-cloud-x86_64 > Fedora-rawhide-cloud-i386 > }}} > > And, we would also like to have a custom garbage collection policy for these; even though they are not scratch builds, they don't need to stay around forever. If we can do a nightly builds (ideal), then I think a week is fine; if they are weekly, keeping a month around seems good. Of course, longer is always better. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5678> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 6

#5622: [RFE] Allow user to (create/)delete private branches
by Fedora Release Engineering 29 Apr '15

29 Apr '15

#5622: [RFE] Allow user to (create/)delete private branches -----------------------------+------------------------ Reporter: vondruch | Owner: rel-eng@… Type: enhancement | Status: new Milestone: Fedora 19 Alpha | Component: git Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ I'd like to be able to manage my private branches. For example, in preparation for Ruby 2.0 release, I was pushing my changes to .spec file into Ruby's repository in dist git, into ruby-2.0 branch. This branch is already merged into master for some while and I'd like to delete it, but it is forbidden: {{{ $ git push -f origin :ruby-2.0 remote: + refs/heads/ruby-2.0 ruby vondruch DENIED by fallthru remote: error: hook declined to update refs/heads/ruby-2.0 To ssh://vondruch@pkgs.fedoraproject.org/ruby ! [remote rejected] ruby-2.0 (hook declined) error: failed to push some refs to 'ssh://vondruch@pkgs.fedoraproject.org/ruby' }}} Would it be possible to allow some development branches, which can be created and deleted as well, without need of opening rel-eng tickets etc? Thanks -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5622> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 5

#5329: RFE: Send branched report only when there is any change committed
by Fedora Release Engineering 29 Apr '15

29 Apr '15

#5329: RFE: Send branched report only when there is any change committed -----------------------------+------------------------ Reporter: pnemade | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 18 Alpha | Component: mash Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Hi, While we are in freeze, can branched report be only sent to the devel/test list when there is any change added for any package? Parag. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5329> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 4

#5218: block httpd-devel.i686, php-devel.i686 from x86_64 compose
by Fedora Release Engineering 29 Apr '15

29 Apr '15

#5218: block httpd-devel.i686, php-devel.i686 from x86_64 compose -----------------------------+------------------------ Reporter: jorton | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 18 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Could the .i686 packages for both httpd-devel and php-devel be blocked from inclusion in the x86_64 compose, we don't (can't/won't) support them biarch. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5218> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 2

#5215: Stage comps and spin-kickstarts during freezes
by Fedora Release Engineering 29 Apr '15

29 Apr '15

#5215: Stage comps and spin-kickstarts during freezes -----------------------------+------------------------ Reporter: adamwill | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 18 Alpha | Component: git Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ As noted on the F17 QA retrospective by me and Bruno Wolff: https://fedoraproject.org/wiki/Fedora_17_QA_Retrospective it's a problem that we use git master of both comps and spin-kickstarts for composes - not the latest packaged version - and both these git repos are not frozen during freezes. During the 17 cycle, we had a concrete example of a comps change during a freeze causing considerable trouble: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=807879 - pulling Boxes into comps during the Beta freeze made that issue a serious problem. For spin-kickstarts, the same kind of thing is possible, and we also have a release criterion requiring a spin-kickstarts package which matches the .ks files used for the compose to be present in the release repository; obviously, the lack of a git freeze makes this tricky to ensure. So we would strongly recommend, at minimum, a mechanism for freezing spin- kickstarts and comps at Alpha, Beta and Final freeze. Post-freeze changes could be made following the same blocker/NTH process used for other post- freeze changes. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5215> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

#5223: F18 TODO: automate torrent generation
by Fedora Release Engineering 29 Apr '15

29 Apr '15

#5223: F18 TODO: automate torrent generation -----------------------------+------------------------ Reporter: ausil | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 18 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Torrent Releases Infrastructure SOP http://torrent.fedoraproject.org/ is our master torrent server for Fedora distribution. It runs out of ServerBeach. Contact Information Owner: Fedora Infrastructure Team Contact: #fedora-admin, sysadmin-torrent group Location: ibiblio Servers: torrent.fedoraproject.org Purpose: Provides the torrent master server for Fedora distribution Torrent Release When you want to add a new torrent to the tracker at http://torrent.fedoraproject.org you need to take the following steps to have it listed correctly: 1. login to torrent.fedoraproject.org. If you are unable to do so please contact the fedora infrastructure group about access. This procedure requires membership in the torrentadmin group. 2. upload the files you want to add to the torrent to torrent.fedoraproject.org:/srv/torrent/new/$yourOrg/ 3. use sha1sum and verify the file you have uploaded matches the source 4. organize the files into subdirs (or not) as you would like 5. run /srv/torrent/new/maketorrent [file-or-dir-to-torrent] ([file-or-dir-to-torrent]) to generate a .torrent file or files 6. copy the .torrent file(s) to: /srv/torrent/www/torrents/$yourOrg/ 7. cd to /srv/torrent/torrent-generator/ or /srv/torrent/spins- generator/ (depending on if it is an official release or spins release) 8. add a .ini file in this directory for the content you'll be torrenting. we use fedora-torrent-ini.py from fedora releng git repo to generate it 9. mv all files from /srv/torrent/new/$yourOrg into /srv/torrent/btholding/ - this includes the files you uploaded as well as the .torrent files you've created. Your files will be linked on the website and available on the tracker after this. $yourOrg is one of fedora or spins this all needs to be setup to be done via a single script. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5223> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 4

#5332: [RFE] Generate .composeinfo for Fedora secondary arches
by Fedora Release Engineering 29 Apr '15

29 Apr '15

#5332: [RFE] Generate .composeinfo for Fedora secondary arches -----------------------------+------------------------ Reporter: bpeck | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 18 Alpha | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Please generate a .composeinfo for secondary arches. The secondary arches that we are interested in are: arm, ppc, and s390. Ideally we could get a .composeinfo when *all* these arches are complete. But I understand that they have different time schedules and may update at different times. Worst case we look to see if the datetime on the file changes and we can re-import again with the newly added arch. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5332> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

#4985: Extend test image creation SOP to require notification of delays
by Fedora Release Engineering 09 Mar '15

09 Mar '15

#4985: Extend test image creation SOP to require notification of delays ----------------------+----------------------------------------------------- Reporter: adamwill | Owner: rel-eng(a)lists.fedoraproject.org Type: task | Status: new Milestone: | Component: koji Keywords: | ----------------------+----------------------------------------------------- Working through the F16 QA retrospective here: https://fedoraproject.org/wiki/Fedora_16_QA_Retrospective One of the notes is: "jlaska - Alpha TC1 - Missed the Alpha-TC1 milestone by 1 week, little to no communication regarding status. With only two weeks Alpha ISO test time, losing 50% of time almost certainly results in a slip. See rel-eng ticket#4844 . None of the Alpha rel-eng release tickets have been filed at this time. adamw - perhaps releng image compose SOP should require updating of ticket with progress info, especially when image compose / delivery is delayed?" So: this ticket proposes that the releng 'Composing test images' SOP - https://fedoraproject.org/wiki/Composing_test_images - should be extended to require whoever is creating the images to post a comment on the image request ticket if the compose is delayed, explaining the reasons for the delay (so that any other interested party can attempt to contribute to resolving them) and giving a best estimate of an ETA if possible (so other groups can adjust their scheduling as best they can). Thanks! -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4985> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 4

#5654: Report full image creation for quality website updates
by Fedora Release Engineering 19 Jan '15

19 Jan '15

#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

1 9

#5679: merge buildbranched/buildrawhide into a single script
by Fedora Release Engineering 10 Nov '14

10 Nov '14

#5679: merge buildbranched/buildrawhide into a single script -----------------------------+------------------------ Reporter: ausil | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ in order to simplify things it would be good to make a single script to build rawhide and branched. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5679> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 2

#4071: Block pushes to origin/ in gitolite ACLs
by Fedora Release Engineering 24 Sep '14

24 Sep '14

#4071: Block pushes to origin/ in gitolite ACLs ----------------------+----------------------------------------------------- Reporter: jkeating | Owner: rel-eng(a)lists.fedoraproject.org Type: task | Status: new Milestone: | Component: git Keywords: | ----------------------+----------------------------------------------------- Common typo to create a new branch that starts with "origin/". We can stop that at the ACL level. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4071> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 5

#4355: metadata for "grouped" files on master mirror
by Fedora Release Engineering 15 Sep '14

15 Sep '14

#4355: metadata for "grouped" files on master mirror ---------------------+------------------------------------------------------ Reporter: mdomsch | Owner: rel-eng(a)lists.fedoraproject.org Type: task | Status: new Milestone: | Component: other Keywords: | ---------------------+------------------------------------------------------ This may be less of an issue now that we don't have the split CD set, but I would like it if rel-eng could produce a file into the master mirror tree for "groups" of files that should be a single consistent download set, such as a DVD and the checksum file, or the set of files that are together inside a single torrent. MirrorManager is growing the idea of a "file group", a single requestable entity that will return a metalink listing each of the files in the file group. The intent was to use it for the multi-CD download sets, but it's just as valuable for the DVD and checksum file, or other similar groups. But it needs to be a file (say, .fileset or something), in a directory that MM can find and use to build the FileGroups. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4355> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 2

#5653: script automatic weekly install rawhide trees
by Fedora Release Engineering 08 Sep '14

08 Sep '14

#5653: script automatic weekly install rawhide trees --------------------+------------------------ Reporter: mattdm | Owner: rel-eng@… Type: task | Status: new Milestone: | Component: other Keywords: | Blocked By: Blocking: | --------------------+------------------------ This was removed as part of the No Frozen Rawhide at the anaconda team's request. Dennis mentions that at this point they're for having a weekly tree (but no more). Dennis further notes that this is basically just a matter of * setup a cronjob * get the compose box to mount /pub/alt rw * automate cleanup of old trees And Kevin noted that the rw mount was no problem. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5653> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 11

#3903: change component owner in bugzilla
by Fedora Release Engineering 07 Sep '14

07 Sep '14

#3903: change component owner in bugzilla ----------------------+----------------------------------------------------- Reporter: mmaslano | Owner: rel-eng(a)lists.fedoraproject.org Type: task | Status: new Milestone: | Component: other Keywords: | ----------------------+----------------------------------------------------- Could you create perl-fedora-maint as bug owner for all my perl-* modules and perl component? I'm sharing bugs with my colleagues in RHEL and we'd like to have it also for Fedora. I suppose set up mailing list is also needed. This should be applied only for perl modules, where I am an owner of the package. Not only co-maintainer. The group perl-fedora-maint should include mmaslano, ppisar, psabata. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3903> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 15

#5700: mass bugzilla script uses wrong urls
by Fedora Release Engineering 31 Aug '14

31 Aug '14

#5700: mass bugzilla script uses wrong urls -------------------+------------------------ Reporter: ausil | Owner: rel-eng@… Type: task | Status: new Milestone: | Component: other Keywords: | Blocked By: Blocking: | -------------------+------------------------ the script for mass filing bugs puts the wrong urls in to log files. they are short lived anyway. we need to find a better way to deal with them. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5700> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 2

#5729: remove libvpd and lsvpd from main koji
by Fedora Release Engineering 02 Jun '14

02 Jun '14

#5729: remove libvpd and lsvpd from main koji -----------------------------+------------------------ Reporter: till | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ libvpd and lsvpd were build for all archs until F15 but are only useful for PPC(64). The packages need to be removed somehow from koji: https://lists.fedoraproject.org/pipermail/devel/2013-August/187956.html Possiblities: - manually cleanup koji database - cut off older release inheritance -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5729> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 5

#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

#5714: perl-DBD-AnyData retired
by Fedora Release Engineering 27 Feb '14

27 Feb '14

#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

1 4

#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

#5418: Adopt policy that SCM request should be accepted from authorized users only
by Fedora Release Engineering 07 Jan '14

07 Jan '14

#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

1 18

#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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng August 2013