Hey,
Common-lisp.net has been going through a massive migration. As
stated[1], the server that cl-net was running on is not longer.
This friday was the last day of that server, and I have been working all
weekend to try and finish things off.
On of the major issues was the email hosting. It was exim4 and mailman
for the lists, both of which I did not like. So I spent today migrating
to postfix, dovecot and mlmmj for mailing lists[2].
This is the first list that I have tried beyond my own personal tests,
so consider this a test post! If you happen to get this, please respond to me.
You could also CC the list if you so desire... my hope is that some do
and some don't.
-- drewc
Hi Mark, Mario, others,
Today I finished a script to stitch the histories of the various mailing
lists back together (yay!). However, I'm running into an issue:
Mailman's HTML archive generator doesn't want to regenerate the archives
for any archive that doesn't have an active mailing list associated (why?!
Ugh!).
So, I'll be experimenting later to see if I can create an active mailing
list while regenerating the archive and deleting the mailing list
thereafter again. If anybody feels like major Python hacking to hack the
HTML archive generator to use the mailing list default settings if there's
no active mailing list, that'd be perfect. (We don't use anything but the
defaults...)
So, good news, but unfortunately, bad news too.
@Mark: some mail to armedbear-devel hasn't been archived between june 2014
and februari 2015. If you could find those mails (preferrably by
downloading them in their original text form, by downloading POP3 or IMAP
content), now would be an extremely good time, because it'll be easy to
stich that content with the rest right now.
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Hi,
Last night I have finished my scripts which stitch the mailing list history
from the old common-lisp.net system's mailman, the mlmmj and the new
mailman archives.
The result is hosted here: https://mailman-test.common-lisp.net/pipermail/
I'd greatly appreciate review of the result in order to be able to fix any
issues before we do the final conversion run. Comments can be posted here.
If you find spam when going through the archives, please let me know,
because since we're re-generating the mailing list archives, now is a good
time to remove it.
Regards,
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Dear all,
In preparation of migrating away from CVS, I've found a number of projects
which have a non-empty CVS repository as well as a non-empty Subversion
repository. To notify these projects, I've sent the mail below. However,
some projects have not received this mail, because the member's e-mail
addresses in the .forward file can't be reached.
The projects which haven't received the notification are:
plain-odbc : raverkamp(a)common-lisp.net
cl-libtai: lvecsey(a)common-lisp.net
If anybody knows how to reach these users, please forward this e-mail. If
no reaction pops up (either by the project owner or someone who feels the
need), the default action as mentioned in the mail will kick in (i.e. we'll
assume the CVS repo is a remnant of a CVS->Subversion migration).
Kindest regards,
Erik.
-----------------------------------------------------------
Dear members of the <project> project,
As part of the migration of common-lisp.net to a more coherent and
easier to support structure, it was discovered that your project
has both a non-empty CVS repository as well as a non-empty Subversion
repository.
Because support for CVS repositories will be removed from the system
in the months to come, we'd like to know if your CVS repository is a
duplicate of the CVS repository or old remnant, even.
We're currently assuming you *don't* need your CVS repository to be
migrated anywhere (it's a duplicate or old remnant). We'll remove it.
**** If this assumption is incorrect, please respond to this e-mail
by 2015-04-12, telling us what you want to happen to your /CVS/
repository ****
Your options are
1. Migrate to Git
2. Migrate to Subversion
Thank you for your cooperation!
Kindest regards,
Erik Hulsmann
common-lisp.net admins
Hello,
I'm writing with a question and request. I've spotted a bug on wiki of
cl-weblocks (its hosted on trac.common-lisp.net) - in order to modify it
and correct, I do need trac.common-lisp.net account? If yes, how to
acquire it?
Best regards,
Daniel Kochmański
--
Daniel Kochmański | Poznań, Poland
;; aka jackdaniel
"Be the change that you wish to see in the world." - Mahatma Gandhi
Hi all,
Migrating the old mailing list archives back in place will be a multi-step
plan. I've copied over the archives of the mailman lists which don't have
an active list.
Please check out the test-outcome here:
https://mailman-test.common-lisp.net/pipermail/
Any review and comments highly appreciated.
Please do note that the archives of active lists need to be merged,
something to be addressed in a later step. The same applies to the mmjlm
archives: they still have to be merged with the mailman archives. This will
happen later.
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Progress of the GitLab installation and migration scripts has been very
good. With some last tests to go, we're confident we can complete
installation and migration on *Friday March 20th, 2015. The window 08:00h -
12:00h UTC* has been designated to perform installation and migration.
During that window *existing git repositories with public visibility* (i.e.
http or gitweb access -- git:// access not counted) will be migrated into
GitLab [0]. There's no impact on Subversion, CVS, mercurial, darcs or
bazaar repositories. Users with git repositories without http or gitweb
access, who want to use GitLab for their project are kindly requested to
contact the site admins.
After the migration, *migrated repositories will be removed from their
current physical path locations*. Repositories will *only* be accessible
through GitLab and stored in a location managed by GitLab. Users who want
to make backups should do so by keeping a local clone of their git
repository(-ies).
As part of the migration, *GitLab accounts will be created for all users*
of the common-lisp.net system. Each user with a .forward file in their home
directory on the system will receive an account confirmation e-mail. This
confirmation request is valid for 48 hours. *All accounts must be confirmed
before use* - the system blocks accounts until confirmed. Your account can
be used immediately after confirmation, even during the migration window.
As part of the migration, SSH keys found in the user's home directory will
be imported into the user's GitLab account. You will receive an e-mail to
confirm this happened.
As part of the migration, *Gitlab groups will be created*, mirroring the
common-lisp.net "project" concept. Users currently part of a project by
virtue of being member of a unix group on common-lisp.net will be assigned
GitLab group membership for the mirror group in the role of Owner.
Notification mails are sent out due to the migration process. Projects that
wish to use GitLab's more fine-grained permisssions[1] can do so after
migration completes.
As part of the migration, *existing git repositories will be imported into
GitLab* under the group or account which mirrors the common-lisp.net
project or account. All repositories will have a *public* visibility. Each
repository on common-lisp.net becomes a *project* in GitLab. This means
each repository gets an issue tracker and wiki set up. Any project that
wishes not to use those can turn those off in the Settings page for the
GitLab project after the migration. Due to the nature of the migration
process, *the Administrator account will be a member of all GitLab projects
and groups.* This can be corrected after the migration.
After the migration, gitweb access won't be available anymore. It will be
replaced by URL redirection to GitLab. git:// protocol support won't be
available anymore either.
While the migration is in progress, SSH access to the system will be
blocked to prevent repositories being updated while migrated.
Should you want to start a new project in GitLab, please ask the site
admins to create a group for it.
Please note that this is just one of the steps in the restructuring plan
for common-lisp.net. Further steps as indicated in [2] will be executed
later and will affect repositories for other version control systems as
well as other services.
In case of questions please follow up to clo-devel(a)common-lisp.net: the
announcements mailing list is closed for posting.
[0] Full list of affected repositories:
https://common-lisp.net/gitlab-migration-repository-mapping/ (note: updated
today!)
[1]
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/permissions/permiss…
[2]
https://mailman.common-lisp.net/pipermail/clo-devel/2015-February/000161.ht…
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Not sure what's going on, but when I visit
https://gitlab.common-lisp.net/cmucl/cmucl/tree/master/src/lisp to see
the current changes, the "Loading commit data" just spins and spins for
at least a minute. It still hasn't loaded any commit data yet. In fact
most subdirectories from the top of the tree are really slow.
Not a big deal, but thought it might be important to mention this.
--
Ray
> On 23 Mar 2015, at 20:13, Erik Huelsmann <ehuels(a)gmail.com> wrote:
>
> Hi Mark,
>
> GitLab 7.9.0 has been released. Even though the release blog mentions their content with the size of the release, I'm usually a bit weary when it comes to big releases, so, I'm also weary to install a .0 release. However, GitLab never seems to make it into the high patch release numbers.
>
> The reason I'd like to have the 7.9 release on common-lisp.net soon is:
>
> - Allow admins to override restricted project visibility settings
>
> Which means I can put /custom and the site in private repositories which seems to suit people best.
>
> Before I install it on the site, I want to be sure to run a test install (or two) on the secondary VM. This may or may not overlap with your work on Trac. Could you let me know of a suitable time to test this upgrade?
I have no constraints on deployment: do when it suits you. trac-1.0.4 builds
and installs fine, but that can be done as a live upgrade whenever we’re ready.
The real problem is finding an OAuth 2 implementation, to enable OpenID Connect.
I’m still working on the OAuth story.
--
"A screaming comes across the sky. It has happened before but there is nothing
to compare to it now."
For kicks, I just tried to get some blame info for
https://gitlab.common-lisp.net/cmucl/cmucl/blame/master/src/assembly/sparc/…
by clicking on the blame button. I get error 500 that something
(unspecified) went wrong.
This happens for all the files I've tried. Pressing the History button
works, though.
--
Ray