rel-eng March 2014

rel-eng@lists.fedoraproject.org

12 participants
152 discussions

#5814: please remove private branch llvm/private-jvcelak
by Fedora Release Engineering 01 Sep '14

01 Sep '14

#5814: please remove private branch llvm/private-jvcelak -----------------------------+------------------------ Reporter: jvcelak | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Final | Component: git Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Please remove private branch llvm/private-jvcelak from dist-git. {{{ % git push origin :private-jvcelak remote: + refs/heads/private-jvcelak llvm jvcelak DENIED by fallthru remote: error: hook declined to update refs/heads/private-jvcelak To ssh://jvcelak@pkgs.fedoraproject.org/llvm ! [remote rejected] private-jvcelak (hook declined) error: failed to push some refs to 'ssh://jvcelak@pkgs.fedoraproject.org/llvm' }}} Btw, builds which are preserved in Koji are built only from non-private branches. And devels can create private branches, but cannot delete them. Is there any reason for that? -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5814> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 3

[PATCH] De-hardcode 'origin' as the remote name
by Mathieu Bridon 23 Jul '14

23 Jul '14

By default, Git remotes are named 'origin', but some pyrpkg-based tools might be used to interact with several remotes for the same package module. This change allows sites to define how remotes should be called by simply overriding the Commands.remote attribute. That attribute is set to "origin" though, to not break existing clones. The rpkg bash completion resource had to be modified accordingly. Since the fedpkg one already handles this properly, a simple copy-paste of that specific line was enough. --- This is important for us at $dayjob. We have this rpkg-based tool called nbpkg, which we use to interact with our packaging infrastructure, similar to fedpkg: https://github.com/network-box/nbpkg But as I'm also a Fedora packager, I like to be able to interact with both our internal infrastructure, and the Fedora one, in the same Git clone, as it allows me to easily flow changes in both directions. This workflow requires having different names for each remote though, they can't just be all called 'origin'. This patch makes this possible. I can imagine a similar use case for RHEL packagers, which could probably want to interact with both the Fedora and RHEL packaging infrastructures in the same Git clone, flowing changes both ways. I know RPMFusion would be interested as well (I added Nicolas as CC). src/pyrpkg/__init__.py | 21 ++++++++++++++------- src/rpkg.bash | 3 +-- 2 files changed, 15 insertions(+), 9 deletions(-) diff --git a/src/pyrpkg/__init__.py b/src/pyrpkg/__init__.py index c5b4ae4..89a84a2 100644 --- a/src/pyrpkg/__init__.py +++ b/src/pyrpkg/__init__.py @@ -135,6 +135,9 @@ class Commands(object): self._ver = None self.log = log + # The local name of the remote (might be overridden by subclasses) + self.remote = "origin" + # Define properties here # Properties allow us to "lazy load" various attributes, which also means # that we can do clone actions without knowing things like the spec @@ -961,6 +964,11 @@ class Commands(object): else: self.log.debug('Cloning %s' % giturl) cmd.extend([giturl]) + + if not bare_dir: + # --bare and --origin are incompatible + cmd.extend(['--origin', self.remote]) + self._run_command(cmd, cwd=path) return @@ -1009,14 +1017,14 @@ class Commands(object): for branch in branches: try: # Make a local clone for our branch - top_git.clone("--branch", branch, repo_path, branch) + top_git.clone("--branch", branch, '--origin', self.remote, + repo_path, branch) - # Set the origin correctly + # Set the remote correctly branch_path = os.path.join(top_path, branch) branch_git = git.Git(branch_path) - branch_git.config("--replace-all", "remote.origin.url", giturl) - # Bad use of "origin" here, need to fix this when more than one - # remote is used. + branch_git.config( + "--replace-all", "remote.%s.url" % self.remote, giturl) except (git.GitCommandError, OSError), e: raise rpkgError('Could not locally clone %s from %s: %s' % (branch, repo_path, e)) @@ -1452,8 +1460,7 @@ class Commands(object): self.log.debug('No local branch found, creating a new one') totrack = None for remote in remotes: - # bad use of "origin" here, will have to be fixed - if remote.replace('origin/', '') == branch: + if remote.endswith(branch): totrack = remote break else: diff --git a/src/rpkg.bash b/src/rpkg.bash index 047c98d..a2e45b6 100644 --- a/src/rpkg.bash +++ b/src/rpkg.bash @@ -283,8 +283,7 @@ _rpkg_branch() local git_options= format="--format %(refname:short)" [[ -n $1 ]] && git_options="--git-dir=$1/.git" - git $git_options for-each-ref $format 'refs/remotes/origin/*' \ - | sed 's,origin/,,' + git $git_options for-each-ref $format 'refs/remotes' | sed 's,.*/,,' git $git_options for-each-ref $format 'refs/heads' } -- 1.8.5.3

2 9

#5872: Block unalz in F21
by Fedora Release Engineering 09 Jul '14

09 Jul '14

#5872: Block unalz in F21 -----------------------------+------------------------ Reporter: ppisar | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 21 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ I've retired ''unalz'' package in Fedora 21 (bug !#1076853). Please block it in the koji. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5872> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

#5877: Schedule and coordinate mass rebuild for F21
by Fedora Release Engineering 16 Jun '14

16 Jun '14

#5877: Schedule and coordinate mass rebuild for F21 -----------------------------+------------------------ Reporter: jreznik | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 21 Alpha | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Coordinate the packages that need to be rebuilt for F21 We try to have no more than one mass rebuild per cycle. So we need to list the things that need a mass rebuild and then schedule it to happen. Branching is no earlier than 2014-07-08, so mass rebuild should be done by 2014-06-09 (with 4 weeks cleanup grace period). Initially early May was proposed as GCC 4.9 should be released and land Fedora in the first half of April. * https://fedoraproject.org/wiki/Changes/GCC49 For full Fedora 21 schedule, see https://fedoraproject.org/wiki/Releases/21/Schedule -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5877> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 10

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

03 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

#5779: Build target for tcl-8.6.1
by Fedora Release Engineering 27 May '14

27 May '14

#5779: Build target for tcl-8.6.1 -----------------------------+------------------------ Reporter: jskarvad | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Hi, could we get a separate f21 build target to build tcl-8.6.1 and rebuild packages which depend on it? It's cca. 100 packages. We can also do it without the tag - it will take approx. 1 to 2 weeks with various probably minor breakages. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5779> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 14

#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

#5868: Retired update still showing in updates-testing
by Fedora Release Engineering 30 Apr '14

30 Apr '14

#5868: Retired update still showing in updates-testing -----------------------------+------------------------ Reporter: slaanesh | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Final | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ I pushed two packages as updates in bodhi a few weeks ago, but even before they reached updates-testing I revoked them. Now, after some weeks, I see that both are available from updates-testing but I don't see them in Bodhi. They are not in my list of updates or the generic updates-testing queue. It seems they have been removed from Bodhi but somehow they reached the repository anyway. The packages are these two: * guacamole-client-0.8.3-5.fc20 * guacamole-client-0.8.3-5.fc19 I've already tried untagging the packages but I don't have required permissions: $ koji untag-pkg f19-updates-testing guacamole-client-0.8.3-5.fc19 ActionNotAllowed: tag requires admin permission I would like to know what happened and make sure the packages are retired from the repositories. Thanks & regards, --Simone -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5868> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

#5865: Package icc_examin
by Fedora Release Engineering 30 Apr '14

30 Apr '14

#5865: Package icc_examin -----------------------------+------------------------ Reporter: cicku | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Final | Component: git Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Hi, I see that this package was retired improperly. Since its upstream is still active(oyranos), I'd request if you could unblock it in pkgdb(as the repo hasn't been wiped by dead.package) Thanks. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5865> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

#5869: sbackup retirement
by Fedora Release Engineering 30 Apr '14

30 Apr '14

#5869: sbackup retirement -----------------------------+------------------------ Reporter: filiperosset | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 21 Final | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Hi guys, I retired sbackup from rawhide due lack of interest in maintaining it. It was already retired in F12/F13 (but not sure if all steps were followed), then it was back to life again (see https://fedorahosted.org/rel- eng/ticket/4271) but it was orphaned one more time. sbackup is not well written upstream, fedora git mirrors were a mess (no f19, f20 branches), etc. This time, I followed the steps in https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life to make sure sbackup retirement will be done. I just need someone to double check if it's really going to be retired and only come back if anyone really want to maintain sbackup again. I also going to close all sbackup related bugs in bugzilla. Please let me know if you need clarification/additional information. Thanks. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5869> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

← Newer
1
2
3
4
5
6
7
...
16
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng March 2014