- clo-devel - mailman3.common-lisp.net

[Clo-devel] Testing GitLab installation & migration nearing completion: steps to cut-over
by Erik Huelsmann 09 Mar '15

09 Mar '15

Hi all, As some of you have noticed this weekend, we're still working on migrating the common-lisp.net repositories to GitLab. While doing so, a few e-mails have been sent out while they should have been held and deleted on the testing system. My appologies if it caused confusion or inconvenience. So far, we've run multiple successful installation-and-configuration runs. We have also successfully completed seeding the system with users, groups and group members. There are a few things that need some more testing, which will be done over the next week or so: * Importing of users' public SSH keys * Apache gitweb redirect rules to the relevant GitLab URLs * Repository migration script (the script that moves the repositories under GitLab control) While we're working on these last steps, it would be highly appreciated if people would take a bit of time to review the repository mapping published on https://common-lisp.net/gitlab-migration-repository-mapping/ . The page lists all existing public git repositories, from both users and projects. On the listing, you can see under which name the repository will be mapped to the GitLab system. We expect to complete testing in the next two weeks, so if you could provide your feedback by Friday 13th, that would fit the timelines best. Then a little about the actual cut-over. On the day of the cut-over (most likely a Sunday morning, CET), the scripts that we have developed over the past weeks will be run in close succession. This means we'll be installing GitLab, creating users, creating groups, assigning users to groups (creating members, in GitLab terminology) and importing git repositories in the GitLab system. The entire process should not take more than a few hours. The system sends out a number of mails during the seeding phase, some or all of which you may receive: * Account confirmation - after account creation, the system requires verification before the account can be used * Membership creation - after your account has been assigned membership in a project, you'll be notified by mail about that * Import of SSH keys - after an SSH key has been associated with a user that user is notified of that fact It's possible that you won't get mail from account creation, if your common-lisp.net account doesn't have a .forward file. In that case, now would be a good time to create one, if you want to use your GitLab account. Another important thing to note is that repositories having been brought under GitLab control, will no longer be available on their old locations. For gitweb, there will be redirect rules instated, as will there be for direct repository access over https. If you have questions, please follow up to this mail on clo-devel(a)common-lisp.net. The announcements channel is closed for posting. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 1

[Clo-devel] Trac logins
by Raymond Toy 07 Mar '15

07 Mar '15

Did something happen to trac lately? I tried to login to cmucl's trac instance and my saved password no longer works. (I'm not 100% sure my saved password is correct, but whatever was saved always worked before.) If something did happen, please feel free to reset my password. Thanks, Ray

2 2

[Clo-devel] IP4 address change
by Mark Evenson 04 Mar '15

04 Mar '15

We’ve recently changed the IP4 address of common-lisp.net. Is this change intended to be permanent? illin:~$ host lisp.not.org lisp.not.org has address 144.76.188.67 lisp.not.org has IPv6 address 2a01:4f8:200:4310::30 illin:~$ host common-lisp.net common-lisp.net has address 148.251.248.130 common-lisp.net has IPv6 address 2a01:4f8:200:4310::30 common-lisp.net mail is handled by 10 mail.common-lisp.net. -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

2 2

[Clo-devel] Proposed organization of projects, groups and members in GitLab for common-lisp.net
by Erik Huelsmann 24 Feb '15

24 Feb '15

Hi, Trying to keep the mail short; sent too many essays already :-) So, some context regarding GitLab's structure: - each project has: + one repository + at most one issue tracker + at most one wiki + at most one snippets archive + at least one member - each group has: + one or more members + zero or more projects - each user: + has zero or more projects + is a member of zero or more groups and/or projects with a certain access level Now, every member of a group is automatically a member of the group's projects. I propose we map common-lisp.net's projects to gitlab's groups since our projects can (and do) have multiple repositories. Since our current projects don't distinguish in access level between project members, we should map access level to the highest available: owner. Our repositories map to GitLab's projects. All GitLab projects are owned by a group if found in the /project filesystem hierarchy. All personal repositories (those found in /home) will be directly owned to users. Users may choose to assign others access rights other than reading. The system's login accounts will map to GitLab users. GitLab group membership will be determined using the current method of project membership: being member of a certain group in the /etc/group file. Then there's one aspect left not discussed: project visibility. All project repositories (those found in the /project hierarchy) will be assigned to public projects. All public user repositories (those found in /home/<user>/public_html/* or those linked from /var/git/projects/users/*) will be assigned public visibility. All other user repositories will be assigned "Internal" visibility (visible only to logged-in users). Comments? -- Bye, Erik. http:// <http://efficito.com/>efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock in.

1 0

[Clo-devel] Unable to clone (permission denied)
by dalevi＠Safe-mail.net 24 Feb '15

24 Feb '15

I don't know if other projects are affected or if asdf somehow stands alone: $ git clone git://common-lisp.net/project/asdf/asdf.git Cloning into 'asdf'... fatal: remote error: access denied or repository not exported: /project/asdf/asdf.git Matthew

3 2

[Clo-devel] Last test, confirmation.
by Erik Huelsmann 20 Feb '15

20 Feb '15

Regards, Erik.

1 0

[Clo-devel] Test to check mail headers
by Erik Huelsmann 20 Feb '15

20 Feb '15

Sorry I had to send a mail to one of the common-lisp.net mailing lists to check whether the X-List-Archive header gets through correctly now. Regards, Erik.

1 0

[Clo-devel] Intended policy changes for mailing list setup
by Erik Huelsmann 19 Feb '15

19 Feb '15

Dear common-lisp.net users, mailing list owners, You're receiving this message because you're listed as a mailing list owner or because you have a common-lisp.net login account. If you have different mail addresses associated with both, you may get multiple copies. Apologies for that in advance. We're sending this mail to announce policy changes intended to be executed as of March 15th regarding mailing list setup. [For further discussion, please direct to clo-devel(a)common-lisp.net.] Changes to mailing list headers and footer ========================================== Google is tightening their DKIM validation; most of our mailing lists cause invalid DKIM signatures on out-going mails: * Adding the Subject prefix '[<mailing list>]' invalidates the DKIM signature of the original sender * Adding the e-mail footer may invalidate the e-mail's DKIM signature Since Google, Yahoo! and other big mail providers are moving to signing their outgoing mail, the percentage of invalid mail sent by common-lisp.net increases. This hurts our reputation as a mail sender and has led to problems with Google accepting common-lisp.net mail. (Admitted, DKIM was not the only reason.) Due to the above, we will change the mailing list setup for all mailing lists: * No longer add the mailing list subject prefix * No longer add the mailing list footer * Add the List-* headers as per RFC-2369, filtering of mailing list messages can be done using these fields Change to moderation expiration ======================== Additionally, we've found that many mailing lists have been set to not expire mails in the moderation queue, resulting in a moderation queue of 10-thousands of mails some more than 8 months old. Recognizing most of these mails are probably not being moderated because they are spam, we intend to change all mailing lists which do not expire their moderation queue to expire moderation requests after 90 days. Again, the above is an intended policy change. Please send feedback on clo-devel(a)common-lisp.net. Kind regards, common-lisp.net admins

2 1

[Clo-devel] Follow up to "proposed direction for common-lisp.net in 2015" -- the steps
by Erik Huelsmann 16 Feb '15

16 Feb '15

Hi everybody, As a follow-up to the changes that I proposed for common-lisp.net to be implemented over the course of 2015 [ https://mailman.common-lisp.net/pipermail/clo-devel/2015-February/000161.ht…] I've been looking at the more detailed steps to be executed to implement the proposal. Remember that the changes are targetting a more modern, but also a simplified (for users *and* admins) system. It's an investment, but one in simpler maintenance while improving user experience. Currently, I'm thinking that the steps (no timing yet) should be: 0. Install a Code Commenting plugin on Trac to make it match the GitLab code commenting capabilities 1. Finish my experiments regarding the GitLab setup / installation 2. Install GitLab on common-lisp.net (under the gitlab.common-lisp.net domain? or should we prefer git.common-lisp.net?) 3. Run the migration to create all users and groups in GitLab --> do we want all project which we know *don't* use Git to be created in GitLab too? 4. Import the CMUCL git repositories (using the script to be used for all projects) 5. Run a trial period of 2 months with Raymond Toy and CMUCL to iron out any unnoticed issues 6. Import the user's git repositories 7. Import all other projects with Git repositories 8. Turn off gitweb --> introduce rewrite rules to point to gitlab 9. Turn off git plugin for Trac --> introduce rewrite rules to point to gitlab 10. Turn off git-daemon (fully depend on https checkouts) 11. Convert all project darcs repositories to git --> Notify all darcs project owners before we do about a planning/timing 12. Import the converted darcs repositories 13. Convert users' darcs repositories --> Notify all darcs users before we do about a planning/timing 14. Import converted users' darcs repositories 15. Turn off darcsweb webbrowsing --> introduce rewrite rules to point to gitlab 16. Contact CVS repository owners to ask if they want to migrate to Subversion or Git --> Which do we default to in case of no answer? 17. Convert CVS repositories to Subversion (where requested / defaulted) 18. Convert CVS repositories to Git (where requested / defaulted) 19. Import git-converted CVS repositories 20. Turn off ViewVC (Subversion & CVS) web-browsing --> introduce rewrite rules to point to gitlab/Trac 21. Turn off cvsd and related cron jobs 22. Turn off svnserve (fully depend on https checkouts) "Import git repository" here means "move into gitlab space", which means the user will *only* be able to access the repository through GitLab's access methods (HTTPS and SSH(git user)) . Before we go to that step, we'll probably need to announce this step to all users who have git repositories in their home directories. (So they can object to the move -- if they do, the repository won't be moved, but we *will* scrap gitweb and git-daemon...) Every step which says "Import" or "Convert" entails the creation (and testing) of a scripted procedure, as far as I'm concerned. Some steps will necessarily be executed in sequence. However some parts may be executed in parallel (e.g. contacting users about preferences and developing the scripted procedure). I'm hoping that when I sign up for this task, others pick up the rest of the work that relates to cl-net, such as fixing the mailing list archives or getting OAuth working for both Trac and GitLab (assuming we want that; do we?). The order above is explicitly selected to benefit as soon as possible from having GitLab up and running, with namespaces reserved (hence the full group and user creation right at the start), but possibly unused at first (due to later imports of projects and repositories). I'm not completely sure about steps 10 and 22; if we can make step 10 work, I'm inclined to research if we can keep step 22 as well. So, judging by the number of steps to be executed, this may take all year, with one or two steps every month. I don't have a problem with that, though thought it'd be good to set expectations. So, apart from the fact that it looks like an enormous amount of work, what are your comments? (Note that I see this as a consequence of years and years maintenance backlog; so, it's not something that I expect to be solved in a day or two.) -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

5 7

[Clo-devel] mit-cadr-cvs mailing list
by Robert Swindells 11 Feb '15

11 Feb '15

Please could the admin password for mit-cadr-cvs be reset and the new one sent to me. Robert Swindells

2 1