Re: Transition to Gitlab Complete
On 5/18/20 7:57 AM, Nate Graham wrote: I'm finding that all my repos have somehow had their URLs already changed to GitLab URLs (by kdesrc-build maybe?), but not the right ones. This makes the git-kpull migration script fail: nate@spectre:~/kde/src/kio$ (master) git remote -v origin https://invent.kde.org/kio (fetch) origin ssh://g...@invent.kde.org/kio (push) nate@spectre:~/kde/src/kio$ (master) ~/kde/src/sysadmin-repo-metadata/git-helpers/git-kpull Sorry, we were unable to determine the name of the repository as it is not configured to push to the old server (git.kde.org) Never mind, this was caused by an out-of-date version of kdesrc-build that was being used instead of the most up-to-date version in the repo itself due to a local misconfiguration. Everything's working fine now. Great job on a smooth transition! Nate
Re: Transition to Gitlab Complete
On 5/17/20 4:47 AM, Ben Cooksley wrote: -- Migration Helpers -- To assist with the migration to Gitlab, Sysadmin earlier mentioned a series of helper tools which could be used to clone repositories conveniently from Gitlab as well as migrate existing clones. To set these up, you will need a clone of 'sysadmin/repo-metadata' on your local system, along with Python3 and PyYAML (packaged as python3-yaml on most distributions) installed on your system. Once you have these, add the folder 'git-helpers' in 'sysadmin/repo-metadata' to $PATH and you should be good to go. Please note that 'git kpull' at the moment is only able to perform the initial migration from anongit.kde.org/git.kde.org to invent.kde.org urls. Additional patches to improve this are welcome. I'm finding that all my repos have somehow had their URLs already changed to GitLab URLs (by kdesrc-build maybe?), but not the right ones. This makes the git-kpull migration script fail: nate@spectre:~/kde/src/kio$ (master) git remote -v origin https://invent.kde.org/kio (fetch) origin ssh://g...@invent.kde.org/kio (push) nate@spectre:~/kde/src/kio$ (master) ~/kde/src/sysadmin-repo-metadata/git-helpers/git-kpull Sorry, we were unable to determine the name of the repository as it is not configured to push to the old server (git.kde.org) Nate
Re: git-kpull suggestion: was: Transition to Gitlab Complete
On Mon, May 18, 2020 at 6:56 AM Jack Ostroff wrote: > > Ben/sysadmins, Hi Jack, > > git-kpull failed for me on Gentoo, due to an apparently long-open CVE > for pyyaml. See https://bugs.gentoo.org/659348 for more information. > The suggested fix (in comment 14 of that bug) is "you'll need to patch > out those unsafe calls. Look for calls to "yaml.load()" and replace > them with calls to "yaml.full_load()" (or "yaml.safe_load()" if you > know what you're doing). See upstream issue #265 > [https://github.com/yaml/pyyaml/issues/265] for details. > > In my case, the single change on line 36 of git-kpull: > -metadata = yaml.load( metadataFile ) > +metadata = yaml.full_load( metadataFile ) > > I don't know enough python to know whether yaml.safe-load() would work > or not and whether it would be any better or not. Thanks for pointing this out. In our case the YAML files we have are very plain and basic, so should be totally fine with yaml.safe_load. I have now switched the scripts over to use that. > > Jack Cheers, Ben
git-kpull suggestion: was: Transition to Gitlab Complete
Ben/sysadmins, git-kpull failed for me on Gentoo, due to an apparently long-open CVE for pyyaml. See https://bugs.gentoo.org/659348 for more information. The suggested fix (in comment 14 of that bug) is "you'll need to patch out those unsafe calls. Look for calls to "yaml.load()" and replace them with calls to "yaml.full_load()" (or "yaml.safe_load()" if you know what you're doing). See upstream issue #265 [https://github.com/yaml/pyyaml/issues/265] for details. In my case, the single change on line 36 of git-kpull: -metadata = yaml.load( metadataFile ) +metadata = yaml.full_load( metadataFile ) I don't know enough python to know whether yaml.safe-load() would work or not and whether it would be any better or not. Jack
Re: Transition to Gitlab Complete
On 17/05/20 12:47, Ben Cooksley wrote: > Good morning all, Hi Ben > > -- Migration Helpers -- > > To assist with the migration to Gitlab, Sysadmin earlier mentioned a > series of helper tools which could be used to clone repositories > conveniently from Gitlab as well as migrate existing clones. > > To set these up, you will need a clone of 'sysadmin/repo-metadata' on > your local system, along with Python3 and PyYAML (packaged as > python3-yaml on most distributions) installed on your system. > Once you have these, add the folder 'git-helpers' in > 'sysadmin/repo-metadata' to $PATH and you should be good to go. > > Please note that 'git kpull' at the moment is only able to perform the > initial migration from anongit.kde.org/git.kde.org to invent.kde.org > urls. > Additional patches to improve this are welcome. I tried to 'git kpull' from a bunch of clones I have but I always get this error: $ git kpull /home/elvis/dev/kde/sysadmin-repo-metadata/git-helpers/git-kpull:36: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details. metadata = yaml.load( metadataFile ) Sorry, we were unable to determine the name of the repository as it is not configured to push to the old server (git.kde.org) and also this one: $ git remote show origin fatal: unable to update url base from redirection: asked for: https://invent.kde.org/kio/info/refs?service=git-upload-pack redirect: https://invent.kde.org/users/sign_in Am I missing something? > > Thanks, > Ben Cooksley > KDE Sysadmin > Thanks, Elvis
Re: Transition to Gitlab Complete
On Sonntag, 17. Mai 2020 12:47:35 CEST Ben Cooksley wrote: > -- Work Branches -- > [...] Is this information available somewhere in the wikis? > Apologies for the disruption this caused - please note that a number > of systems that work closely with the Git repositories are in the > process of catching up with the transition at the moment. > During this time there may be some disruption to them, however we hope > that this will all be completed over the coming week. Thanks for the good work! So far, I couldn't have wished for a smoother transition... Cheers, Johannes
Re: Transition to Gitlab Complete
On Sunday, May 17, 2020 3:47:35 AM PDT Ben Cooksley wrote: > Good morning all, > > Over the past 24 hours Sysadmin has been busy working on transitioning > everything from git.kde.org over to invent.kde.org (Gitlab) a process > which we have now essentially completed. > All repositories with the exception of personal (scratch and clone) > repositories have been migrated successfully now. We intend to migrate > the remaining personal repositories over the coming week. > > You should all be aware of the following: > > -- Work Branches -- > > As part of the transition to Gitlab, we have also simultaneously > rolled out work branches. > > These are branches that live within the normal repositories, but do > not have notification hooks triggered on them. This means that they > will not close bugs, send email or be announced on IRC. As such, they > can also be force pushed. > Any branch prefixed with the name 'work/' is considered to be a work branch. > > It is important to note that the server will enforce a maximum number > of 100 commits divergence between a work branch and any other normal > branch (those not prefixed with work/) in the repository. > This is necessary to protect our systems when the work branch is > merged to a normal/release branch (which is when the hooks will > process all of those commits) > > We therefore do not recommend work branches for long term work such as > GSoC projects or other significant items of work - normal branches > should be used for these. > > All other branches will continue to be subject to normal commit hook > processing, and cannot be force pushed. > > -- Migration Helpers -- > > To assist with the migration to Gitlab, Sysadmin earlier mentioned a > series of helper tools which could be used to clone repositories > conveniently from Gitlab as well as migrate existing clones. > > To set these up, you will need a clone of 'sysadmin/repo-metadata' on > your local system, along with Python3 and PyYAML (packaged as > python3-yaml on most distributions) installed on your system. > Once you have these, add the folder 'git-helpers' in > 'sysadmin/repo-metadata' to $PATH and you should be good to go. > > Please note that 'git kpull' at the moment is only able to perform the > initial migration from anongit.kde.org/git.kde.org to invent.kde.org > urls. > Additional patches to improve this are welcome. > > -- Conclusion -- > > Apologies for the disruption this caused - please note that a number > of systems that work closely with the Git repositories are in the > process of catching up with the transition at the moment. > During this time there may be some disruption to them, however we hope > that this will all be completed over the coming week. > > Should anyone have any questions regarding this, please let us know > (via sysad...@kde.org) > > Thanks, > Ben Cooksley > KDE Sysadmin This is amazing! Congrats to everyone involved! Bet, *Jacky Alcine*[1] [1] https://jacky.wtf/?utm_medium=email signature.asc Description: This is a digitally signed message part.
Re: Transition to Gitlab Complete
> Over the past 24 hours Sysadmin has been busy working on transitioning > everything from git.kde.org over to invent.kde.org (Gitlab) a process Great work, thanks to everyone involved! Cheers, Ivan -- dr Ivan Čukić i...@cukic.co, https://cukic.co/ gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232 07AE 01C6 CE2B FF04 1C12
Transition to Gitlab Complete
Good morning all, Over the past 24 hours Sysadmin has been busy working on transitioning everything from git.kde.org over to invent.kde.org (Gitlab) a process which we have now essentially completed. All repositories with the exception of personal (scratch and clone) repositories have been migrated successfully now. We intend to migrate the remaining personal repositories over the coming week. You should all be aware of the following: -- Work Branches -- As part of the transition to Gitlab, we have also simultaneously rolled out work branches. These are branches that live within the normal repositories, but do not have notification hooks triggered on them. This means that they will not close bugs, send email or be announced on IRC. As such, they can also be force pushed. Any branch prefixed with the name 'work/' is considered to be a work branch. It is important to note that the server will enforce a maximum number of 100 commits divergence between a work branch and any other normal branch (those not prefixed with work/) in the repository. This is necessary to protect our systems when the work branch is merged to a normal/release branch (which is when the hooks will process all of those commits) We therefore do not recommend work branches for long term work such as GSoC projects or other significant items of work - normal branches should be used for these. All other branches will continue to be subject to normal commit hook processing, and cannot be force pushed. -- Migration Helpers -- To assist with the migration to Gitlab, Sysadmin earlier mentioned a series of helper tools which could be used to clone repositories conveniently from Gitlab as well as migrate existing clones. To set these up, you will need a clone of 'sysadmin/repo-metadata' on your local system, along with Python3 and PyYAML (packaged as python3-yaml on most distributions) installed on your system. Once you have these, add the folder 'git-helpers' in 'sysadmin/repo-metadata' to $PATH and you should be good to go. Please note that 'git kpull' at the moment is only able to perform the initial migration from anongit.kde.org/git.kde.org to invent.kde.org urls. Additional patches to improve this are welcome. -- Conclusion -- Apologies for the disruption this caused - please note that a number of systems that work closely with the Git repositories are in the process of catching up with the transition at the moment. During this time there may be some disruption to them, however we hope that this will all be completed over the coming week. Should anyone have any questions regarding this, please let us know (via sysad...@kde.org) Thanks, Ben Cooksley KDE Sysadmin
