Re: GitLab repo breaks make website?
Em seg., 11 de mai. de 2020 às 20:45, Dan Eble escreveu: > Run autogen.sh and/or configure? > — > Dan > Yes, that's extacly what I was missing. Sorrythanks!
Re[2]: labels on GitLab
Jonas, you wrote 12/05/2020 14:49:27 Actually I think we should use milestones for this. They can be closed and don't clutter the labels. This comes with the disadvantage that there can be at most one milestone set (which you also get with the scoped labels). This is not correct for some patches that have been backported. I'm still building ideas for how to handle this. Why do we need labels indicating a patch has been applied to several releases when a patch has been back-ported? Indicating the earliest release to which the patch has been applied should be adequate, or am I missing something here? Scoping the Fixed labels sounds good to me. Trevor
Re: labels on GitLab
Jonas wrote 12/05/2020 13:42:46 > In my opinion, there are currently far too many labels on GitLab. To > avoid the situation getting worse, please do not create new labels out > of thin air for now. Instead we should first contemplate on what we > really need and configure this appropriately. (Adding a label for every > possible warning that could be fixed is not helpful.) +1 Labels are most useful when they form a limited set. That way we all know what they are and what they mean. Inventing new labels is not really helpful as they can rarely be applied to anything else and after a short while no one knows they exist or what they mean. Is there any way of limiting the set of labels which may be applied? That would also eliminate spelling mistakes as well as making selecting Issues by label more reliable. Trevor
Re: labels on GitLab
On 12/05/2020 16:15, Valentin Villenave wrote: On 5/12/20, Jonas Hahnfeld wrote: I'd really hope we can discuss things before changing... And*I*’d really hope “discuss things” can amount to more than “blindly reverting everything and anything that’s been done by someone else”. It was't blind Valentin, He did explain why he reverted it. Be fair. We've all got to get used to this 'new' instance, and there will be some bumps before it is all smooth. I am sure Jonas will, once we see how it all pans out, suggest and get some doc done. Regards James
Re: labels on GitLab
On 5/12/20, Jonas Hahnfeld wrote: > I'd really hope we can discuss things before changing... And *I*’d really hope “discuss things” can amount to more than “blindly reverting everything and anything that’s been done by someone else”. Look, you’ve obviously spent quite some time setting this up and you’re obviously much more familiar with the tools at hand; therefore, I’m not gonna bother spending any more time trying to lend a hand before *you* update the CG and properly explain what it is you want us to do and/or not do, and how you want us to do and/or not do it. Cheers, -- V.
Re: labels on GitLab
Am Dienstag, den 12.05.2020, 16:58 +0200 schrieb Valentin Villenave: > On 5/12/20, Jonas Hahnfeld wrote: > > In my opinion, there are currently far too many labels on GitLab. > > Well, we used to say `Labels are cheap’ back when we were using Google Code… > > > please do not create new labels out of thin air for now. > > Not entirely out of thin air. I’ve actually decreased the number of > concurrent labels in use, by merging midi with MIDI, warning with > Warning, musicxml2ly with musicxml, Build with Type::Build and so on. > (Case-sensitivity in this instance is cumbersome, as you can see from > the number and inconsistency of fixed_ and Fixed_ prefixed labels.) > > I have indeed created a new label for type conversion issues, which > seemed appropriate, and another one for SVG output. This is the sort > of thing some of us used to find useful a dozen years ago; it may be > less so today but that remains to be seen. > > > Instead we should first contemplate on what we > > really need and configure this appropriately. (Adding a label for every > > possible warning that could be fixed is not helpful.) > > That is not my intent. > > V. And I just saw you changed prioritized labels. This breaks the ordering in merge requests, so I'm going to revert this now. I'd really hope we can discuss things before changing... Jonas signature.asc Description: This is a digitally signed message part
Re: labels on GitLab
On 5/12/20, Jonas Hahnfeld wrote: > In my opinion, there are currently far too many labels on GitLab. Well, we used to say `Labels are cheap’ back when we were using Google Code… > please do not create new labels out of thin air for now. Not entirely out of thin air. I’ve actually decreased the number of concurrent labels in use, by merging midi with MIDI, warning with Warning, musicxml2ly with musicxml, Build with Type::Build and so on. (Case-sensitivity in this instance is cumbersome, as you can see from the number and inconsistency of fixed_ and Fixed_ prefixed labels.) I have indeed created a new label for type conversion issues, which seemed appropriate, and another one for SVG output. This is the sort of thing some of us used to find useful a dozen years ago; it may be less so today but that remains to be seen. > Instead we should first contemplate on what we > really need and configure this appropriately. (Adding a label for every > possible warning that could be fixed is not helpful.) That is not my intent. V.
Re: updated Stockhausen example
Werner LEMBERG wrote >>>I have a hard time imagining a performer bringing this to life in a >>>manner justifying the complexity written into the score. >> >> Why? >> >> It seems you haven"t heard enough of today"s highly qualified and >> dedicated performers ... > > It's not about performing this notation. I'm sure this could be > *much* simpler notated, and nobody listening to it would hear a > difference. > > At least for ensemble music this makes a huge difference IMHO – the > simpler the score, the less rehearsal time you need, and the better > the performance is. I would like to respectfully half-disagree with you. I say half because what you say is obviously true, regarding simplicity vs rehearsal time and accuracy. The part that I will actually argue is that today's music is many times harder than Stockhausen's Klavierstucke. And some of this music is music for, say, piano and percussion, or piano and drums etc., and with that one has to be exact. The thing is, they can be done that way today. If anything, these kinds of things usually are so much better for one's mental picture of rhythm rather than simply getting through a piece. One learns rhythm at a deeper level when they count 5/6 keeping the time from before rather than changing the time a-la-modulation and getting back. In the first case they superimpose one timing over another, polyrhythmic counting which is a great skill to acquire, while on the latter they just change the metronome for a bit and back again. Sometimes the notation implies a method that makes one a better rhythmicist, if such a term applies. The easiest thing probably would be to change back and fro, but that would not give much to the performer as a skill. My opinion always, nothing more. Thank you -S. -- Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html
Re: GitLab review email
Il giorno mar 12 mag 2020 alle 15:52, Thomas Morley ha scritto: Am Di., 12. Mai 2020 um 14:23 Uhr schrieb James : Hello On 12/05/2020 13:09, Federico Bruni wrote: > > Il giorno mar 12 mag 2020 alle 07:40, Dan Eble ha > scritto: >> Rietveld used to send email to lilypond-devel for all comments by >> default, though one could disable that when commenting. Are we >> satisfied with GitLab's not doing that? I think so because it is configurable per developer. >> > > As non developer, I'm satisfied :-) > > I'm interested in following discussions on lilypond-devel, but I use > to delete 99% of the rietveld emails without even read them. > Not even easy, because emails from Rietveld are not grouped by thread. > > One of the nice feature of GitLab is that each developer can decide > the amount of emails reaching his inbox without "imposing" a single > decision for everyone. > I also ignored 99% of rietveld emails too mainly because I'd only care about the issues on countdown and then I'd just scan the conversation look for anything that sounded contentious or needing a decision. We always have lilypond-auto list https://lists.gnu.org/archive/html/lilypond-auto/ perhaps that could be useful for something? James I'm one of the subscribers to this list and found it always useful, although a lot of mails are output. Not sure, if it could made to work with GitLab When you have time, try. I'm sure you can get the same (or very similar) experience using GitLab notifications. I agree with James that lilypond-auto may be set up to provide the "old lilypond-devel experience". Don't know about the technical details though.
Re: GitLab review email
Am Di., 12. Mai 2020 um 14:23 Uhr schrieb James : > > Hello > > On 12/05/2020 13:09, Federico Bruni wrote: > > > > Il giorno mar 12 mag 2020 alle 07:40, Dan Eble ha > > scritto: > >> Rietveld used to send email to lilypond-devel for all comments by > >> default, though one could disable that when commenting. Are we > >> satisfied with GitLab's not doing that? > I think so because it is configurable per developer. > >> > > > > As non developer, I'm satisfied :-) > > > > I'm interested in following discussions on lilypond-devel, but I use > > to delete 99% of the rietveld emails without even read them. > > Not even easy, because emails from Rietveld are not grouped by thread. > > > > One of the nice feature of GitLab is that each developer can decide > > the amount of emails reaching his inbox without "imposing" a single > > decision for everyone. > > > I also ignored 99% of rietveld emails too mainly because I'd only care > about the issues on countdown and then I'd just scan the conversation > look for anything that sounded contentious or needing a decision. > > We always have lilypond-auto list > > https://lists.gnu.org/archive/html/lilypond-auto/ > > perhaps that could be useful for something? > > > James I'm one of the subscribers to this list and found it always useful, although a lot of mails are output. Not sure, if it could made to work with GitLab Cheers, Harm
Re: labels on GitLab
Am Dienstag, den 12.05.2020, 13:43 + schrieb Carl Sorensen: > On 5/12/20, 6:43 AM, Jonas Hahnfeld wrote: > > In my opinion, there are currently far too many labels on GitLab. To > avoid the situation getting worse, please do not create new labels out > of thin air for now. Instead we should first contemplate on what we > really need and configure this appropriately. (Adding a label for every > possible warning that could be fixed is not helpful.) > > ->CS And following up on this, it seems like we should move away from > Fixed_x_y_z to Fixed::x.y.z > > ->CS Although, that is still one label per release, at least the labels are > all grouped under the prefix Fixed:: Actually I think we should use milestones for this. They can be closed and don't clutter the labels. This comes with the disadvantage that there can be at most one milestone set (which you also get with the scoped labels). This is not correct for some patches that have been backported. I'm still building ideas for how to handle this. Jonas signature.asc Description: This is a digitally signed message part
Re: labels on GitLab
On 5/12/20, 6:43 AM, "lilypond-devel on behalf of Jonas Hahnfeld" wrote: In my opinion, there are currently far too many labels on GitLab. To avoid the situation getting worse, please do not create new labels out of thin air for now. Instead we should first contemplate on what we really need and configure this appropriately. (Adding a label for every possible warning that could be fixed is not helpful.) ->CS And following up on this, it seems like we should move away from Fixed_x_y_z to Fixed::x.y.z ->CS Although, that is still one label per release, at least the labels are all grouped under the prefix Fixed:: Carl
labels on GitLab
In my opinion, there are currently far too many labels on GitLab. To avoid the situation getting worse, please do not create new labels out of thin air for now. Instead we should first contemplate on what we really need and configure this appropriately. (Adding a label for every possible warning that could be fixed is not helpful.) signature.asc Description: This is a digitally signed message part
Re: GitLab review email
Hello On 12/05/2020 13:09, Federico Bruni wrote: Il giorno mar 12 mag 2020 alle 07:40, Dan Eble ha scritto: Rietveld used to send email to lilypond-devel for all comments by default, though one could disable that when commenting. Are we satisfied with GitLab's not doing that? I think so because it is configurable per developer. As non developer, I'm satisfied :-) I'm interested in following discussions on lilypond-devel, but I use to delete 99% of the rietveld emails without even read them. Not even easy, because emails from Rietveld are not grouped by thread. One of the nice feature of GitLab is that each developer can decide the amount of emails reaching his inbox without "imposing" a single decision for everyone. I also ignored 99% of rietveld emails too mainly because I'd only care about the issues on countdown and then I'd just scan the conversation look for anything that sounded contentious or needing a decision. We always have lilypond-auto list https://lists.gnu.org/archive/html/lilypond-auto/ perhaps that could be useful for something? James
Re: GitLab review email
Il giorno mar 12 mag 2020 alle 07:40, Dan Eble ha scritto: Rietveld used to send email to lilypond-devel for all comments by default, though one could disable that when commenting. Are we satisfied with GitLab's not doing that? As non developer, I'm satisfied :-) I'm interested in following discussions on lilypond-devel, but I use to delete 99% of the rietveld emails without even read them. Not even easy, because emails from Rietveld are not grouped by thread. One of the nice feature of GitLab is that each developer can decide the amount of emails reaching his inbox without "imposing" a single decision for everyone.
GitLab review email
Rietveld used to send email to lilypond-devel for all comments by default, though one could disable that when commenting. Are we satisfied with GitLab's not doing that? — Dan
Re: Re[2]: Verifying issues on Gitlab
Am Dienstag, den 12.05.2020, 11:19 + schrieb Trevor: > Another question: > > How do I remove labels no longer relevant (or entered incorrectly!) eg > Patch:Push for verified issues? If using the UI, click "Edit" next to the labels, find the one you want to remove and untick. For the lazy, type '/unlabel ~' and pick the right one from the dropdown that appears when JS is enabled signature.asc Description: This is a digitally signed message part
Re[2]: Verifying issues on Gitlab
Another question: How do I remove labels no longer relevant (or entered incorrectly!) eg Patch:Push for verified issues? Trevor -- Original Message -- From: "Kevin Barry" To: "Federico Bruni" Cc: "lilypond-devel" Sent: 12/05/2020 08:15:02 Subject: Re: Verifying issues on Gitlab Hi Federico, Thank you for the instructions. I will try to help get them done as well. On Tue, May 12, 2020 at 12:28:24AM +0200, Federico Bruni wrote: In the last comment you should find a commit id (if it's missing you'll have to search it). The easiest and quickest way to verify that a certain id has been included in the release tag label used in the issue is using Github. Start from this URL: Another handy way to do this is to run git tag --contains . (For me this is faster than github.) Kevin
Re: Verifying issues on Gitlab
Am Dienstag, den 12.05.2020, 10:03 +0200 schrieb Davide Liessi: > Dear Federico, > > I can contribute too, probably on the same order as Carl: > > Il giorno mar 12 mag 2020 alle ore 01:12 Carl Sorensen > ha scritto: > > I'll start jumping in, but it will probably be on the order of about 10 per > > day, give or take. > > Can you give me the appropriate permissions? > My GitLab name is dliessi. Granted 'Reporter' access for now, let me know if you need 'Developer' to also push branches (note that you can always fork & open a merge request from there; it's not strictly necessary anymore to be a member somewhere before contributing). Jonas signature.asc Description: This is a digitally signed message part
Ghostcript warning about LinLibertine0 during make doc
Hello, While doing some sanity tests this morning building doc (making sure everything works for me for testing with new infrastructure) I spent more time looking at the terminal window than I usually do. During the make doc part where the 'page numbers' all whiz by I noticed occasionally I'd get a line /"GPL Ghostscript 9.26: Can't embed the complete font LinLibertineO as it is too large, embedding a subset."/ also part of that log stream. I don't know if we should be worried or if we can do anything about that or something else but I thought I would mention it. I haven't noticed anything obvious in the resulting PDF - but then again I haven't looked that hard. regards James
Re: Verifying issues on Gitlab
Dear Federico, I can contribute too, probably on the same order as Carl: Il giorno mar 12 mag 2020 alle ore 01:12 Carl Sorensen ha scritto: > I'll start jumping in, but it will probably be on the order of about 10 per > day, give or take. Can you give me the appropriate permissions? My GitLab name is dliessi. Best wishes. Davide
Re: repository at GitLab
Am Di., 12. Mai 2020 um 09:19 Uhr schrieb Thomas Morley : > > Am Di., 12. Mai 2020 um 08:47 Uhr schrieb Jonas Hahnfeld : > > > > Am Dienstag, den 12.05.2020, 08:43 +0200 schrieb Thomas Morley: > > > Am Di., 12. Mai 2020 um 08:32 Uhr schrieb Jonas Hahnfeld > > > : > > > > Am Dienstag, den 12.05.2020, 08:24 +0200 schrieb Thomas Morley: > > > > > Hi, > > > > > > > > > > currently I've very little time to work on LilyPond or to monitor the > > > > > mailing-lists at all, thus I apologize if this is already answered > > > > > elsewhere. > > > > > For now I'll expect me getting familiar with GitLab very slowly... > > > > > > > > > > Nevertheless, I just did: > > > > > $ git remote set-url origin g...@gitlab.com:lilypond/lilypond.git > > > > > > > > > > Next I wanted to do: > > > > > $ git fetch > > > > > returning: > > > > > The authenticity of host 'gitlab.com > > > > > (2606:4700:90:0:f22e:fbec:5bed:a9b9)' can't be established. > > > > > ECDSA key fingerprint is > > > > > SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw. > > > > > Are you sure you want to continue connecting (yes/no)? > > > > > > > > > > What to do? > > > > > > > > It prompts you to confirm that it's really gitlab.com that you're > > > > connecting to. As SSH uses no certificates, that's on the user to do. > > > > The usual way is to verify the fingerprint, which are published here: > > > > https://docs.gitlab.com/ee/user/gitlab_com/index.html#ssh-host-keys-fingerprints > > > > > > > > As they match, you probably want to continue (unless you consider the > > > > possibility that somebody hijacked both the website for both of us and > > > > the SSH connection to a spoofed host...) > > > > > > > > Jonas > > > > > > I now get: > > > $ git fetch > > > The authenticity of host 'gitlab.com > > > (2606:4700:90:0:f22e:fbec:5bed:a9b9)' can't be established. > > > ECDSA key fingerprint is > > > SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw. > > > Are you sure you want to continue connecting (yes/no)? yes > > > Warning: Permanently added > > > 'gitlab.com,2606:4700:90:0:f22e:fbec:5bed:a9b9' (ECDSA) to the list of > > > known hosts. > > > Connection closed by 2606:4700:90:0:f22e:fbec:5bed:a9b9 port 22 > > > fatal: Could not read from remote repository. > > > > > > Please make sure you have the correct access rights > > > and the repository exists. > > > > Did you add the SSH key to your GitLab account? If not, see this > > documentation page: > > https://docs.gitlab.com/ee/ssh/README.html#adding-an-ssh-key-to-your-gitlab-account > > > > Regards > > Jonas > > Well, as far as I can tell, I did as you adviced. > Though: > $ git fetch > now wants a password, though I never set one for this repo. > > I give up for now, probably I wait for the updated CG, please make > sure it's written for very dumb dummies... > > Many thans for your advice, best > Harm I think I've found the culprit. Previously I had a couple of lilypond-git-repos (mainly because I could switch between compilations with different guile-versions very conveniant), but only one, protected by a password, for doing serious work, patches, push etc. The others were not set up for push. Looks like the repo I took for testing access to GitLab is now the main, password-protected repo. Which is ok for me. Seems it's time for some clean up with my repos ... well ... if I find the time ... Many thanks again. Harm
Re: Verifying issues on Gitlab
Il giorno mar 12 mag 2020 alle 08:15, Kevin Barry ha scritto: Another handy way to do this is to run git tag --contains . (For me this is faster than github.) Right, I forgot it. It's faster indeed. Thanks to everybody for jumping in so quickly!
Re: repository at GitLab
Am Di., 12. Mai 2020 um 08:47 Uhr schrieb Jonas Hahnfeld : > > Am Dienstag, den 12.05.2020, 08:43 +0200 schrieb Thomas Morley: > > Am Di., 12. Mai 2020 um 08:32 Uhr schrieb Jonas Hahnfeld : > > > Am Dienstag, den 12.05.2020, 08:24 +0200 schrieb Thomas Morley: > > > > Hi, > > > > > > > > currently I've very little time to work on LilyPond or to monitor the > > > > mailing-lists at all, thus I apologize if this is already answered > > > > elsewhere. > > > > For now I'll expect me getting familiar with GitLab very slowly... > > > > > > > > Nevertheless, I just did: > > > > $ git remote set-url origin g...@gitlab.com:lilypond/lilypond.git > > > > > > > > Next I wanted to do: > > > > $ git fetch > > > > returning: > > > > The authenticity of host 'gitlab.com > > > > (2606:4700:90:0:f22e:fbec:5bed:a9b9)' can't be established. > > > > ECDSA key fingerprint is > > > > SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw. > > > > Are you sure you want to continue connecting (yes/no)? > > > > > > > > What to do? > > > > > > It prompts you to confirm that it's really gitlab.com that you're > > > connecting to. As SSH uses no certificates, that's on the user to do. > > > The usual way is to verify the fingerprint, which are published here: > > > https://docs.gitlab.com/ee/user/gitlab_com/index.html#ssh-host-keys-fingerprints > > > > > > As they match, you probably want to continue (unless you consider the > > > possibility that somebody hijacked both the website for both of us and > > > the SSH connection to a spoofed host...) > > > > > > Jonas > > > > I now get: > > $ git fetch > > The authenticity of host 'gitlab.com > > (2606:4700:90:0:f22e:fbec:5bed:a9b9)' can't be established. > > ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw. > > Are you sure you want to continue connecting (yes/no)? yes > > Warning: Permanently added > > 'gitlab.com,2606:4700:90:0:f22e:fbec:5bed:a9b9' (ECDSA) to the list of > > known hosts. > > Connection closed by 2606:4700:90:0:f22e:fbec:5bed:a9b9 port 22 > > fatal: Could not read from remote repository. > > > > Please make sure you have the correct access rights > > and the repository exists. > > Did you add the SSH key to your GitLab account? If not, see this > documentation page: > https://docs.gitlab.com/ee/ssh/README.html#adding-an-ssh-key-to-your-gitlab-account > > Regards > Jonas Well, as far as I can tell, I did as you adviced. Though: $ git fetch now wants a password, though I never set one for this repo. I give up for now, probably I wait for the updated CG, please make sure it's written for very dumb dummies... Many thans for your advice, best Harm
Re: Verifying issues on Gitlab
Hi Federico, Thank you for the instructions. I will try to help get them done as well. On Tue, May 12, 2020 at 12:28:24AM +0200, Federico Bruni wrote: > In the last comment you should find a commit id (if it's missing you'll have > to search it). > The easiest and quickest way to verify that a certain id has been included > in the release tag label used in the issue is using Github. Start from this > URL: Another handy way to do this is to run git tag --contains . (For me this is faster than github.) Kevin
Re: repository at GitLab
Am Dienstag, den 12.05.2020, 08:43 +0200 schrieb Thomas Morley: > Am Di., 12. Mai 2020 um 08:32 Uhr schrieb Jonas Hahnfeld : > > Am Dienstag, den 12.05.2020, 08:24 +0200 schrieb Thomas Morley: > > > Hi, > > > > > > currently I've very little time to work on LilyPond or to monitor the > > > mailing-lists at all, thus I apologize if this is already answered > > > elsewhere. > > > For now I'll expect me getting familiar with GitLab very slowly... > > > > > > Nevertheless, I just did: > > > $ git remote set-url origin g...@gitlab.com:lilypond/lilypond.git > > > > > > Next I wanted to do: > > > $ git fetch > > > returning: > > > The authenticity of host 'gitlab.com > > > (2606:4700:90:0:f22e:fbec:5bed:a9b9)' can't be established. > > > ECDSA key fingerprint is > > > SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw. > > > Are you sure you want to continue connecting (yes/no)? > > > > > > What to do? > > > > It prompts you to confirm that it's really gitlab.com that you're > > connecting to. As SSH uses no certificates, that's on the user to do. > > The usual way is to verify the fingerprint, which are published here: > > https://docs.gitlab.com/ee/user/gitlab_com/index.html#ssh-host-keys-fingerprints > > > > As they match, you probably want to continue (unless you consider the > > possibility that somebody hijacked both the website for both of us and > > the SSH connection to a spoofed host...) > > > > Jonas > > I now get: > $ git fetch > The authenticity of host 'gitlab.com > (2606:4700:90:0:f22e:fbec:5bed:a9b9)' can't be established. > ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw. > Are you sure you want to continue connecting (yes/no)? yes > Warning: Permanently added > 'gitlab.com,2606:4700:90:0:f22e:fbec:5bed:a9b9' (ECDSA) to the list of > known hosts. > Connection closed by 2606:4700:90:0:f22e:fbec:5bed:a9b9 port 22 > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. Did you add the SSH key to your GitLab account? If not, see this documentation page: https://docs.gitlab.com/ee/ssh/README.html#adding-an-ssh-key-to-your-gitlab-account Regards Jonas signature.asc Description: This is a digitally signed message part
Re: repository at GitLab
Am Di., 12. Mai 2020 um 08:32 Uhr schrieb Jonas Hahnfeld : > > Am Dienstag, den 12.05.2020, 08:24 +0200 schrieb Thomas Morley: > > Hi, > > > > currently I've very little time to work on LilyPond or to monitor the > > mailing-lists at all, thus I apologize if this is already answered > > elsewhere. > > For now I'll expect me getting familiar with GitLab very slowly... > > > > Nevertheless, I just did: > > $ git remote set-url origin g...@gitlab.com:lilypond/lilypond.git > > > > Next I wanted to do: > > $ git fetch > > returning: > > The authenticity of host 'gitlab.com > > (2606:4700:90:0:f22e:fbec:5bed:a9b9)' can't be established. > > ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw. > > Are you sure you want to continue connecting (yes/no)? > > > > What to do? > > It prompts you to confirm that it's really gitlab.com that you're > connecting to. As SSH uses no certificates, that's on the user to do. > The usual way is to verify the fingerprint, which are published here: > https://docs.gitlab.com/ee/user/gitlab_com/index.html#ssh-host-keys-fingerprints > As they match, you probably want to continue (unless you consider the > possibility that somebody hijacked both the website for both of us and > the SSH connection to a spoofed host...) > > Jonas I now get: $ git fetch The authenticity of host 'gitlab.com (2606:4700:90:0:f22e:fbec:5bed:a9b9)' can't be established. ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'gitlab.com,2606:4700:90:0:f22e:fbec:5bed:a9b9' (ECDSA) to the list of known hosts. Connection closed by 2606:4700:90:0:f22e:fbec:5bed:a9b9 port 22 fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. I guess I need some GitLab-for-dummies-guide... Cheers, Harm
Re: repository at GitLab
Am Dienstag, den 12.05.2020, 08:24 +0200 schrieb Thomas Morley: > Hi, > > currently I've very little time to work on LilyPond or to monitor the > mailing-lists at all, thus I apologize if this is already answered > elsewhere. > For now I'll expect me getting familiar with GitLab very slowly... > > Nevertheless, I just did: > $ git remote set-url origin g...@gitlab.com:lilypond/lilypond.git > > Next I wanted to do: > $ git fetch > returning: > The authenticity of host 'gitlab.com > (2606:4700:90:0:f22e:fbec:5bed:a9b9)' can't be established. > ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw. > Are you sure you want to continue connecting (yes/no)? > > What to do? It prompts you to confirm that it's really gitlab.com that you're connecting to. As SSH uses no certificates, that's on the user to do. The usual way is to verify the fingerprint, which are published here: https://docs.gitlab.com/ee/user/gitlab_com/index.html#ssh-host-keys-fingerprints As they match, you probably want to continue (unless you consider the possibility that somebody hijacked both the website for both of us and the SSH connection to a spoofed host...) Jonas signature.asc Description: This is a digitally signed message part
Re: repository at GitLab
Am Mo., 11. Mai 2020 um 09:14 Uhr schrieb Jonas Hahnfeld : > > Everything went pretty much as expected, so here's the repo: > https://gitlab.com/lilypond/lilypond > If you already have a local repository cloned from Savannah, execute > $ git remote set-url origin g...@gitlab.com:lilypond/lilypond.git > to switch to GitLab (or edit your .git/config manually if preferred). > > I granted everybody access to the group https://gitlab.com/lilypond who > sent requests so far. Please make sure that your username is > recognizable to match with something that had access to SourceForge / > Savannah. If in doubt just send me a private email because there's no > possibility to reply to incoming access request from within GitLab. > > The general process stays in place, please push to staging instead of > directly to master. Whoever runs patchy, please update the > configuration as described above. > To open a merge request, there are two possibilities: either fork the > project or push a new dev/* branch directly to the repo and follow the > links. The label Patch::new should be added automatically. > > If you want to get emails for the project: GitLab has a notification > setting per project (little bell to the right of the project name). > "Watch" will notify you about everything (new issues, merge requests, > comments, ...), otherwise you can tick what you want with "Custom". > > So much for now. I expect us to figure things out as we go, and most > probably change some if suitable. > > Jonas Hi, currently I've very little time to work on LilyPond or to monitor the mailing-lists at all, thus I apologize if this is already answered elsewhere. For now I'll expect me getting familiar with GitLab very slowly... Nevertheless, I just did: $ git remote set-url origin g...@gitlab.com:lilypond/lilypond.git Next I wanted to do: $ git fetch returning: The authenticity of host 'gitlab.com (2606:4700:90:0:f22e:fbec:5bed:a9b9)' can't be established. ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw. Are you sure you want to continue connecting (yes/no)? What to do? $ git config -e reads [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] url = g...@gitlab.com:lilypond/lilypond.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master [branch "dev/guile-v2-work"] remote = origin merge = refs/heads/dev/guile-v2-work [branch "stable/2.20"] remote = origin merge = refs/heads/stable/2.20 [branch "staging"] remote = origin Which looks ok, afaict. Thanks, Harm
