Sponsored Content
The Lounge What is on Your Mind? Update on vB3 Migration to Discourse - Issues and Status of BBCode Transformations Post 303045597 by Neo on Thursday 2nd of April 2020 09:50:44 PM
Old 04-02-2020
Update:

Change in direction (too slow to keep doing the migration over and over).

Create / write a Ruby script (done):
  • Retrieve the mappings from the vB posts to the Discourse posts stored the Discourse postgres DB.
  • Use these postid-to-postid mappings to grab the original vB post text from each vB post in the original mysql DB.
  • Preprocess the vB post text
  • Postprocess the vB post text
  • Update the raw post in the Discourse DB
  • Test and redo.

This script above processes about a million posts in 45 minutes (much faster) and when happy with the results can rebake the raw posts into the cooked posts. Rebaking 1M posts takes about 16+ hours, so avoiding this when possible.

Ran this yesterday and found that all the bugs posted my @MadeInGermany before (mangled code, missing left square brackets) and the hard line break error reported by @Scrutinzer (where \n in code fragments were converted to hard line breaks) were fixed.

However, still more gremlins to slay, working on:
  • Fixing missing emoji in the preprocessing. In particular the thumps up emoji that Ravinder loves to use :b: converts to :+1:. DONE
  • Fixing a bug in attachments and other images. DONE

However, the main reported gremlins in code fragments appear to be fixed. Now working on other missing transformations (missing emoji, images, etc).

Making progress... slowly but surely.

All work currently done on test / staging server only.
 

6 More Discussions You Might Find Interesting

1. Shell Programming and Scripting

Shell Script migration issues

Hi All, We will be doing a Solaris 8 to Solaris 10 migration migration, just wanted to know if there are any known / common issues arise from this migration from Shell script point of view. I tried searching this site but mostly post are related to SA's question and jumpstart, etc. If there's... (4 Replies)
Discussion started by: arvindcgi
4 Replies

2. HP-UX

Migration - Compiler Issues.

All, We are migrating an application from HP-UX B.11.00 to HP-UX B.11.31 and both of them have the same informix version - 7.25se. However the compilers are different on both servers. HP-UX B.11.00 - has B3913DB C.03.33 HP aC++ Compiler (S800) HP-UX B.11.31 - has PHSS_40631 1.0 HP C/aC++... (2 Replies)
Discussion started by: helper
2 Replies

3. Programming

How to track table status delete/update/insert status in DB2 V10 z/os?

Dear Team I am using DB2 v10 z/os database . Need expert guidance to figure out best way to track table activities ( Ex Delete, Insert,Update ) Scenario We have a table which is critical and many developer/testing team access on daily basis . We had instance where some deleted... (1 Reply)
Discussion started by: Perlbaby
1 Replies

4. What is on Your Mind?

Status of Migration of Moderation Systems

First a bit of history .... A number of years ago one of our admins built a number of plugin systems for moderation, including (1) a voting system, (2) a "user feelings" system and (3) a confidential posting system. During this time, I was busy on other projects, not very active in the forums,... (1 Reply)
Discussion started by: Neo
1 Replies

5. What is on Your Mind?

VBulletin 3.8 to Discourse on Docker Migration Test Take Two

OK. Like we all do, we learn a lot from tests, test migrations, and so forth. Today, I started from scratch on test migration 2, armed with a lot more knowledge, The main differences are as follows: Installed discourse plugin ruby-bbcode-to-md before starting the install Modified... (30 Replies)
Discussion started by: Neo
30 Replies

6. What is on Your Mind?

VBulletin 3.8 to Discourse on Docker Migration Test Take Four

Test Build 4 on New Server, with changes identified in discourse test builds 2 and 3, primarily: Insuring ruby-bbcode-to-markdown is enabled. Removing line breaks from ICODE to markdown in migration script. Added vbpostid to posts in discourse to setup migrating vb "thanks" to discourse... (28 Replies)
Discussion started by: Neo
28 Replies
DH_STRIP(1)							     Debhelper							       DH_STRIP(1)

NAME
dh_strip - strip executables, shared libraries, and some static libraries SYNOPSIS
dh_strip [debhelperoptions] [-Xitem] [--dbg-package=package] [--keep-debug] DESCRIPTION
dh_strip is a debhelper program that is responsible for stripping executables, shared libraries, and static libraries that are not used for debugging. This program examines your package build directories and works out what to strip on its own. It uses file(1) and file permissions and filenames to figure out what files are shared libraries (*.so), executable binaries, and static (lib*.a) and debugging libraries (lib*_g.a, debug/*.so), and strips each as much as is possible. (Which is not at all for debugging libraries.) In general it seems to make very good guesses, and will do the right thing in almost all cases. Since it is very hard to automatically guess if a file is a module, and hard to determine how to strip a module, dh_strip does not currently deal with stripping binary modules such as .o files. OPTIONS
-Xitem, --exclude=item Exclude files that contain item anywhere in their filename from being stripped. You may use this option multiple times to build up a list of things to exclude. --dbg-package=package This option is a now special purpose option that you normally do not need. In most cases, there should be little reason to use this option for new source packages as debhelper automatically generates debug packages ("dbgsym packages"). If you have a manual --dbg-package that you want to replace with an automatically generated debug symbol package, please see the --dbgsym-migration option. Causes dh_strip to save debug symbols stripped from the packages it acts on as independent files in the package build directory of the specified debugging package. For example, if your packages are libfoo and foo and you want to include a foo-dbg package with debugging symbols, use dh_strip --dbg-package=foo-dbg. This option implies --no-automatic-dbgsym and cannot be used with --automatic-dbgsym or --dbgsym-migration. -k, --keep-debug This option is a now special purpose option that you normally do not need. In most cases, there should be little reason to use this option for new source packages as debhelper automatically generates debug packages ("dbgsym packages"). If you have a manual --dbg-package that you want to replace with an automatically generated debug symbol package, please see the --dbgsym-migration option. Debug symbols will be retained, but split into an independent file in usr/lib/debug/ in the package build directory. --dbg-package is easier to use than this option, but this option is more flexible. This option implies --no-automatic-dbgsym and cannot be used with --automatic-dbgsym. --dbgsym-migration=package-relation This option is used to migrate from a manual "-dbg" package (created with --dbg-package) to an automatic generated debug symbol package. This option should describe a valid Replaces- and Breaks-relation, which will be added to the debug symbol package to avoid file conflicts with the (now obsolete) -dbg package. This option implies --automatic-dbgsym and cannot be used with --keep-debug, --dbg-package or --no-automatic-dbgsym. Examples: dh_strip --dbgsym-migration='libfoo-dbg (<< 2.1-3~)' dh_strip --dbgsym-migration='libfoo-tools-dbg (<< 2.1-3~), libfoo2-dbg (<< 2.1-3~)' --automatic-dbgsym, --no-automatic-dbgsym Control whether dh_strip should be creating debug symbol packages when possible. The default is to create debug symbol packages. --ddebs, --no-ddebs Historical name for --automatic-dbgsym and --no-automatic-dbgsym. --ddeb-migration=package-relation Historical name for --dbgsym-migration. NOTES
If the DEB_BUILD_OPTIONS environment variable contains nostrip, nothing will be stripped, in accordance with Debian policy (section 10.1 "Binaries"). This will also inhibit the automatic creation of debug symbol packages. The automatic creation of debug symbol packages can also be prevented by adding noautodbgsym to the DEB_BUILD_OPTIONS environment variable. However, dh_strip will still add debuglinks to ELF binaries when this flag is set. This is to ensure that the regular deb package will be identical with and without this flag (assuming it is otherwise "bit-for-bit" reproducible). CONFORMS TO
Debian policy, version 3.0.1 SEE ALSO
debhelper(7) This program is a part of debhelper. AUTHOR
Joey Hess <joeyh@debian.org> 11.1.6ubuntu2 2018-05-10 DH_STRIP(1)
All times are GMT -4. The time now is 05:20 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy