I want to patch MediaWiki from 1.23.1 to latest 1.23.4 (on Ubuntu 12.04.5) I plan to use patch: https://www.mediawiki.org/wiki/Manual:Upgrading#Using_patch
My questions is can I directly apply Patch 1.23.4 or need first got 1.23.2, 1.23.3?
Based on file size it looks like I can't jump version (4 is smaller than 3)
https://releases.wikimedia.org/mediawiki//1.23/
mediawiki-1.23.2.patch.gz 30-Jul-2014 19:34 4.0K
mediawiki-1.23.3.patch.gz 27-Aug-2014 21:49 21K
mediawiki-1.23.4.patch.gz 24-Sep-2014 20:12 7.9K
You are correct: the patches are incremental, so if you choose that upgrade route, you'll need to apply each of them in sequence.
You can confirm this by looking at the patch files themselves. For example, the 1.23.4 patch starts with the following lines:
diff -Nruw -x messages -x '*.png' -x '*.jpg' -x '*.xcf' -x '*.gif' -x '*.svg' -x '*.tiff' -x '*.zip' -x '*.xmp' -x '.git*' mediawiki-1.23.3/includes/config/GlobalVarConfig.php mediawiki-1.23.4/includes/config/GlobalVarConfig.php
--- mediawiki-1.23.3/includes/config/GlobalVarConfig.php 2014-09-24 19:58:09.941581474 +0000
+++ mediawiki-1.23.4/includes/config/GlobalVarConfig.php 2014-09-24 19:55:15.782579699 +0000
From this header (which is in unified diff format) you can tell that the patch is against MediaWiki 1.23.3, i.e. it assumes that you've already applied the earlier patches.
If you tried to apply the latest patch without first applying the earlier ones, at least parts of it would almost certainly fail to apply cleanly. Some parts, however, might succeed, leaving you with a weird hybrid version of MediaWiki that would include some of the fixes from the latest minor version, but none from the earlier ones you skipped (and which would probably still retain its original version number). To avoid such a confusing situation, it may be a good idea to use the --dry-run option to the patch utility to make sure that each patch will apply cleanly before you actually apply it.
Related
In 2016, the best way to convert HTML files to PDF from the command line was using wkhtmltopdf. Unfortunately, it seems that that is not really maintained anymore. It doesn't support a lot of things like flexbox.
One can use headless chrome/chromium to do it:
chrome --headless --print-to-pdf="path/to/pdf" https://your_url
but that has no options such as margins, paper type, control over header/footer, screen size, etc.
It appears that there is no plan to add those into headless chrome as command line options (one needs to use the dev tools interface):
https://bugs.chromium.org/p/chromium/issues/detail?id=603559#c89
How can one convert HTML files to PDF from the command line that gives control over how the document prints (margins, etc., from above), and supports modern html/css? Of course, once one can convert from the command line, you can also convert using a programming language of your choice.
Here is a command line tool that you can use to convert HTML pages to PDF just as they would be in chrome. Once you have it installed, you can use it with whatever programming language you want (Python, Java, PHP, etc.) to automatically generate PDFs from HTML web pages or documents. All of the dependencies should be well maintained well into the future, so it shouldn't have the same issues as things like wkhtmltopdf that were difficult to maintain.
URLs:
https://www.npmjs.com/package/chromehtml2pdf
https://github.com/dataverity/chromehtml2pdf
To install it, you'll need npm, and type:
npm install chromehtml2pdf
or to make it globally available to all users on the system
npm install -g chromehtml2pdf
Command line usage:
chromehtml2pdf --out=file.pdf --landscape=1 https://www.npmjs.com/package/chromehtml2pdf
For help (to view all possible options), type:
chromehtml2pdf --help
Feel free to make pull requests on github.
If all you wanted to do was get rid of Chrome's default header/footer, and you control the page in question, you can do that with CSS, without having to use something more complex than a simple command line call.
#media print {
#page { margin: 0; }
}
Of course, you probably do want margins on your pages, so you'll need to fake those. The complexity of doing so varies depending on how many pages you meant to emit to PDF. The recommended body margins in the linked Answer will work if you're emitting a 1-pager. If not, you'll need to use other methods. For example, for multiple pages, you can add body padding on the left and right, then wrap each page's content in a tag with margin for top and bottom.
https://stackoverflow.com/a/15150779/176877
Project Gotenberg does this and a bit more. Including margin manipulation as well as WebHooks, timeouts, merging, and other formats.
To try it
docker run --rm -p 3000:3000 thecodingmachine/gotenberg:6
Example
curl --request POST \
--url http://localhost:3000/convert/url \
--header 'Content-Type: multipart/form-data' \
--form remoteURL=https://brave.com \
--form marginTop=0 \
--form marginBottom=0 \
--form marginLeft=0 \
--form marginRight=0 \
-o result.pdf
- HTML and Markdown conversions using Google Chrome headless
I'm trying to write some scripts for doing some simple housekeeping tasks in mercurial and one of the things I frequently need to do is check if the working set is "empty" (depending on context, that could mean untracked files or modified tracked files).
The hg status command exits with exit status 0 unless there was an internal error, in which case it exits with exit status 255.
If a few of my scripts, I'm doing something silly like capturing the output of the hg status command and checking whether it's empty or not.
In other cases I'm checking the exit status of hg id -i | grep -qvF + to check whether there are dirty tracked files.
Both of these seem a little brittle. Are there dedicated subcommands for "querying" the repository to see if there are "untracked files" or "dirty tracked files" or "removed files" or various other interesting things in the working set?
hg status is the command to check for modifications of the working directory with respect to the checked-out revision - thus you are doing the right thing.
You can get away with exclusively using hg status. Using the --mard (or --modified --added --removed --deleted) flags will yield empty if the tracked files didn't change. And using -u or --unknown will show files which are neither ignored nor tracked - and empty output should always indicate no changes to tracked files nor any non-ignored files (but there might be new files which match one of the ignore patterns).
The output format of these commands (at least in the English original, thus LC_ALL=C hg status) is treated by mercurial as API, thus you should be able to rely on it.
Depending on your actual use-case you might want to look at the mercurial command server - but for a script which runs occasionally it might be quite over the top.
test -z "$(hg status -mard --template x)" && echo clean || echo dirty
Seems to work
We are looking for a way to add / update a custom tag at the beginning of each file being committed during a commit. Its some kind of local timestamp we need.
I was thinking of hooks.
Unfortunately I cannot find a useful hook for that:
precommit: unsuitable as it fires before hg knows any metadata of the commit
pretxncommit: unsuitable, as the documentation clearly states that we should not change the working dir at this point
commit: unsuitable, as it fires when the commit has already happened.
EDIT:
I can not use hg's inline changeset-hash and / or datetime. For the following reason:
Our files get later imported into an external system (we do not have control over) which does not support any kind of versioning.
To simplify stuff: let's say tag is an ever-incrementing no. (everytime we commit). This tag is then used to help getting an idea of the version / status of the file on the system in respect to the file in the repo - like "no. of changes we're missing" and such.
Any ideas?
I would suggest a two-stage solution. First, create an alias along the following lines:
[alias]
tcommit = !tag-changed-files && $HG commit "$#"
Here, tag-changed-files would retrieve a list of modified and added/moved files via $HG status -ma -n or $HG status -ma -n -0 and tag them. I am assuming that re-tagging files that have been modified but aren't being committed yet is a harmless operation; more on that below. Note that you can even redefine commit if you absolutely want to via:
[alias]
commit = !tag-changed-files && $HG --config alias.commit=commit commit "$#"
However, this is potentially problematic, because it may confuse scripts.
You could also integrate the commit step in the program if you wanted to, and even try and parse the command line arguments to only tag those files that you are committing. For this approach, using hglib might be appropriate to avoid the overhead of invoking Mercurial multiple times. (Note that hglib and other tools that use the command server ignore aliases and command defaults, so this works even if you alias commit).
Second, you'd install a pretxncommit hook that verifies that files that are being committed have indeed been tagged appropriately (to ensure that the tag-changed-files program hasn't been bypassed by accident).
This should work without a problem on full commits; for partial commits, any files that were changed but have not been committed would also have been retagged, but since they will be either committed later (and get tagged properly at that point) or reverted, that should be harmless.
an idea of the version / status of the file on the system in respect to the file in the repo
Just one idea
Stop reinvent the wheel
Incremental counter is just shit, if you task is "to know, which version is on LIVE and which - in Mercurial's tip" (and this is your real business-task, yes?!)
Keyword Extension give you last changes per file.
If you want to inject changeset of repository into files (it's reasonable good way), re-read this part of wiki-page
If you just want to version your entire repo, do not use this
extension but let your build system take care of it. Something along
the lines of
hg -q id > version
before distribution might be well enough if file-wise keyword
expansion in the source is not absolutely required
You can insert hg id output into files at export stage (in planetmaker's sed-style), bu you can also have this additional metadata in files permanently in VCS with special encode|decode filters
There is - to my knowledge - no intrinsic system in mercurial which supports what you describe. However I can recommend an approach which somewhat is adopted from building a software release package from the repository: Make a small export script which replaces a certain KEYWORD in your files with the version information you need. A Makefile target could look like which creates a zip export for revision XXX with version information in all files which support it (thus contain the verbatim KEYWORD - use something truely unique here):
VERSION=$(hg log -rXXX --template="Version: {node|short} from {date|isodate}")
export:
hg archive -rXXX -t files export
for i in $(hg ma -rXXX); do sed -i "s/KEYWORD/$VERSION/g" $i; done
zip -9rq export.zip export
I use a similar approach in my Makefiles where I create versioned export for the source of a particular revision of my software.
EDIT: if your purpose (as stated by the comment) is only to implant the number of commits made to that file: then you can use indeed a pre-commit hook and modify the file. You can count the number of modifications made to a file with hg log FILENAME --template="{node}\n" | wc -l. Do that for every file and do the sed replacement in the header of each file in the pre-commit hook.
I am trying to create a rpm using mock. https://fedoraproject.org/wiki/Projects/Mock
I am able to build an rpm through source rpm. Now I want to add a patch to this package and I have no idea how to proceed. Can you please let me know how can I go ahead with this? What is the way to modify/patch a package using mock?
The normal approach here is not to use mock to modify your package in any way. Mock is just a way to ensure that your package is built in a clean environment every time (a fresh chroot), and it's not really meant to do more than that.
The normal thing to do, then, would be to put the patch in the spec file for your RPM itself.
This requires two parts — first, the inclusion of the patch file as part of the package, and second, its application.
For the first, list the patch near the top of the spec file, usually right after your Source line (or lines). Each patch gets a number, and the normal convention is to start counting with 0, so if you have just one, that will look like this:
Patch0: packagename-version-terse_patch_description.patch
As with source files, anything up to the last / in that filename is stripped off, so you can use a URL if you want. The patch will need to be in your RPM sources directory (usually, next to the tarball.)
At this point, if you build a source RPM from your modified spec, the resulting src.rpm file will contain this patch file. (Try it — rpm -qlp packagename-ver-rel.src.rpm). But, it won't be applied. To do that, you need to use the %patch macro.
This goes in the %prep section of the specfile, usually right after the %setup macro line. Each %patch macro has a number corresponding to the Patch line in the header, so for your Patch0, add a line like this:
%patch0 -p1 -b .bugfix
Again by convention, patches used in RPM are made built one level up, so -p1 is appropriate. (Conveniently, this will be correct for diffs made with git, too.) And the -b .bugfix bit isn't necessary, but it's customary for debugging, and I guess serves as a sort of inline comment for what this specific patch macro does. (Replace the string "bugfix" with something appropriate to your actual patch.)
I've got some MQ patches with work implemented in file path project/feature_a, but I need to move these changes to project/feature_b. Is there an easy way to do this?
The only way is to modify the patch files directly with a tool or an editor.
You must (of course) do this while the patches are unapplied, so begin with
$ hg qpop -a
Then edit the patches in .hg/patches using either an editor of your choice or perhaps by using filterdiff from patchutils. Running
$ filterdiff --strip 3 \
--addoldprefix a/project/feature_b/ \
--addnewprefix b/project/feature_b/ your-patch
might do the trick by stripping off the old a/project/feature_b prefixes before adding new ones.