[Git][debian-gis-team/grass][ubuntugis/jammy] 10 commits: Set distribution to unstable.
Martin Landa (@martinl-guest)
gitlab at salsa.debian.org
Mon Jul 29 16:31:26 BST 2024
Martin Landa pushed to branch ubuntugis/jammy at Debian GIS Project / grass
Commits:
5fc7e376 by Bas Couwenberg at 2024-07-17T10:43:50+02:00
Set distribution to unstable.
- - - - -
7c88f12a by Bas Couwenberg at 2024-07-17T10:55:26+02:00
Merge changes from 8.3.2-2.
- - - - -
12a592b0 by Bas Couwenberg at 2024-07-27T09:57:18+02:00
Add upstream patch to fix FTBFS with GCC 14. (closes: #1075041)
- - - - -
e722b5ef by Bas Couwenberg at 2024-07-27T09:57:19+02:00
Set distribution to unstable.
- - - - -
3f6164bf by Bas Couwenberg at 2024-07-27T10:23:34+02:00
Merge tag 'debian/8.3.2-3' into experimental
releasing package grass version 8.3.2-3
- - - - -
250d661b by Bas Couwenberg at 2024-07-27T18:15:40+02:00
New upstream version 8.4.0
- - - - -
fc856f0d by Bas Couwenberg at 2024-07-27T18:18:36+02:00
Update upstream source from tag 'upstream/8.4.0'
Update to upstream version '8.4.0'
with Debian dir 77ef87bd053f855df793a89aa213cfac6445d610
- - - - -
90a5d4b1 by Bas Couwenberg at 2024-07-27T18:21:02+02:00
New upstream release.
- - - - -
ff425b77 by Bas Couwenberg at 2024-07-27T18:22:44+02:00
Set distribution to experimental.
- - - - -
be3315a6 by Martin Landa at 2024-07-29T16:56:01+02:00
Rebuild 8.4.0 for jammy
- - - - -
17 changed files:
- CONTRIBUTING.md
- debian/changelog
- + doc/development/github_guide.md
- − doc/help_loc_structure.odg
- + doc/help_project_structure.odg
- doc/howto_release.md
- grasslib.dox
- gui/wxpython/gmodeler/dialogs.py
- gui/wxpython/gmodeler/panels.py
- include/VERSION
- lib/init/Makefile
- − lib/init/help_loc_struct.png
- + lib/init/help_project_structure.png
- − lib/loc_struct.png
- raster/r.in.pdal/info.cpp
- raster/r.li/r.li.html
- utils/generate_release_notes.py
Changes:
=====================================
CONTRIBUTING.md
=====================================
@@ -8,122 +8,13 @@ or explore <https://grass.osgeo.org/get-involved/>.
## Changing code and documentation
-This guide covers contributing to the main version of GRASS GIS source
-code which is in the branch called _main_.
-It assumes that you have some very basic knowledge of Git and GitHub,
-but if you don't just go through some tutorial online or ask on the
-GRASS GIS developer mailing list.
+To contribute changes to GRASS GitHub repository, use a
+"fork and pull request" workflow. This [guide](./doc/development/github_guide.md)
+leads you through a first time setup and shows how to create a pull request.
To contribute effectively, please familiarize yourself with our
[Programming Style Guide](./doc/development/style_guide.md).
-### First time setup
-
-* Create an account on GitHub.
-* Install Git on your computer.
-* Set up Git with your name and email.
-* Fork the repository (by clicking the `Fork` button in the upper right corner
- of the GitHub interface).
-* Clone your fork (use HTTPS or SSH URL, here we will use HTTPS):
-
-```bash
-git clone git at github.com:your_GH_account/grass.git
-```
-
-* Enter the directory
-
-```bash
-cd grass/
-```
-
-* Add main GRASS GIS repository as "upstream" (use HTTPS URL):
-
-```bash
-git remote add upstream https://github.com/OSGeo/grass
-```
-
-* Your remotes now should be "origin" which is your fork and "upstream" which
- is this main GRASS GIS repository. You can confirm that using:
-
-```bash
-git remote -v
-```
-
-* You should see something like:
-
-```bash
-origin git at github.com:your_GH_account/grass.git (fetch)
-origin git at github.com:your_GH_account/grass.git (push)
-```
-
-For the following workflow, it is important that
-"upstream" points to the OSGeo/grass repository
-and "origin" to your fork
-(although generally, the naming is up to you).
-
-### Update before creating a feature branch
-
-* Make sure your are using the _main_ branch to create the new branch:
-
-```bash
-git checkout main
-```
-
-* Download updates from all branches from the _upstream_ remote:
-
-```bash
-git fetch upstream
-```
-
-* Update your local _main_ branch to match the _main_ branch
- in the _upstream_ repository:
-
-```bash
-git rebase upstream/main
-```
-
-Notably, you should not make commits to your local main branch,
-so the above is then just a simple update (and no actual
-rebase or merge happens).
-
-### Update if you have local changes
-
-If `rebase` fails with "error: cannot rebase: You have unstaged changes...",
-then move your uncommitted local changes to "stash" using:
-
-```bash
-git stash
-```
-
-* Now you can rebase:
-
-```bash
-git rebase upstream/main
-```
-
-* Get the changes back from stash:
-
-```bash
-git stash pop
-```
-
-### Creating a new feature branch
-
-Now you have updated your local _main_ branch, you can create a feature branch
-based on it.
-
-* Create a new feature branch and switch to it:
-
-```bash
-git checkout -b new-feature
-```
-
-### Making changes
-
-You can use your favorite tools to change source code or other files
-in the local copy of the code. When making changes, please follow the
-[Programming Style Guide](./doc/development/style_guide.md).
-
### Testing changes
Testing helps to ensure that the changes work well with the rest
@@ -145,57 +36,6 @@ For Python, run `black .` to apply standardized formatting. You can
also run linter tools such as Pylint which will suggest different improvements
to your code.
-### Committing
-
-* Add files to the commit (changed ones or new ones):
-
-```bash
-git add file1
-git add file2
-```
-
-* Commit the change (first word is the module name):
-
-```bash
-git commit -m "module: added a new feature"
-```
-
-### Pushing changes to GitHub
-
-* Push your local feature branch to your fork:
-
-```bash
-git push origin new-feature
-```
-
-### Pull request
-
-When you push, GitHub will respond back in the command line to tell
-you what URL to use to create a pull request. You can follow that URL
-or you can go any time later to your fork on GitHub, display the
-branch `new-feature`, and GitHub will show you a button to create
-a pull request.
-
-Alternatively, you can explore GitHub CLI tool (_gh_) which allows you
-to do `git push` and create a pull request in one step with `gh pr create -fw`.
-
-### After creating a pull request
-
-GRASS GIS maintainers will now review your pull request.
-If needed, the maintainers will work with you to improve your changes.
-
-Once the changes in the pull request are ready to be accepted,
-the maintainers will usually squash all your commits into one commit and merge it
-to the _main_ branch.
-
-Once the pull request is merged, it is a good time to update your
-local _main_ branch in order to get the change you just contributed.
-
-### Further notes
-
-GRASS GIS maintainers use additional workflows besides the one described
-above. These are detailed at <https://trac.osgeo.org/grass/wiki/HowToGit>
-
## Compilation
More often than not, in order to test the changes, you need to create
=====================================
debian/changelog
=====================================
@@ -1,9 +1,35 @@
+grass (8.4.0-1~jammy1) jammy; urgency=medium
+
+ * Rebuild for jammy.
+
+ -- Martin Landa <landa.martin at gmail.com> Mon, 29 Jul 2024 16:53:59 +0200
+
+grass (8.4.0-1~exp1) experimental; urgency=medium
+
+ * New upstream release.
+
+ -- Bas Couwenberg <sebastic at debian.org> Sat, 27 Jul 2024 18:22:27 +0200
+
+grass (8.3.2-3) unstable; urgency=medium
+
+ * Add upstream patch to fix FTBFS with GCC 14.
+ (closes: #1075041)
+
+ -- Bas Couwenberg <sebastic at debian.org> Sat, 27 Jul 2024 09:16:02 +0200
+
grass (8.4.0~rc1-1~exp1~jammy1) jammy; urgency=medium
* Rebuild for jammy.
-- Martin Landa <landa.martin at gmail.com> Fri, 19 Jul 2024 13:33:40 +0200
+grass (8.3.2-2) unstable; urgency=medium
+
+ * Drop python3-distutils dependency.
+ (closes: #1065869)
+
+ -- Bas Couwenberg <sebastic at debian.org> Wed, 17 Jul 2024 10:43:41 +0200
+
grass (8.4.0~rc1-1~exp1) experimental; urgency=medium
* New upstream release candidate.
=====================================
doc/development/github_guide.md
=====================================
@@ -0,0 +1,187 @@
+# Guide to contributing on GitHub
+
+This guide covers contributing to the GRASS GIS source,
+specifically to the _main_ branch.
+It assumes that you have some very basic knowledge of Git and GitHub.
+
+## First time setup
+
+1. Create an account on GitHub.
+1. Install Git on your computer.
+1. Set up Git with your name and email.
+1. Fork the repository (by clicking the `Fork` button in the upper right corner
+ of the GitHub interface).
+1. Clone your fork (use HTTPS or SSH URL, here we will use HTTPS):
+
+```bash
+git clone https://github.com/your_GH_account/grass.git
+```
+
+1. Enter the directory:
+
+```bash
+cd grass/
+```
+
+1. Add the main GRASS GIS repository as "upstream" (use HTTPS URL):
+
+```bash
+git remote add upstream https://github.com/OSGeo/grass
+```
+
+1. Your remotes now should be "origin" which is your fork and "upstream" which
+ is this main GRASS GIS repository. You can confirm that using:
+
+```bash
+git remote -v
+```
+
+1. You should see something like:
+
+```bash
+origin https://github.com/your_GH_account/grass.git (fetch)
+origin https://github.com/your_GH_account/grass.git (push)
+upstream https://github.com/OSGeo/grass (fetch)
+upstream https://github.com/OSGeo/grass (push)
+
+```
+
+For the following workflow, it is important that
+"upstream" points to the OSGeo/grass repository
+and "origin" to your fork
+(although generally, the naming is up to you).
+
+## Update before creating a feature branch
+
+Make sure your are using the _main_ branch to create the new branch:
+
+```bash
+git checkout main
+```
+
+Download updates from all branches from the _upstream_ remote:
+
+```bash
+git fetch upstream
+```
+
+Update your local _main_ branch to match the _main_ branch
+ in the _upstream_ repository:
+
+```bash
+git rebase upstream/main
+```
+
+Notably, you should not make commits to your local main branch,
+so the above is then just a simple update (and no actual
+rebase or merge happens).
+
+## Creating a new feature branch
+
+Now you have updated your local _main_ branch, you can create a feature branch
+based on it.
+
+Create a new feature branch and switch to it:
+
+```bash
+git switch -c new-feature
+```
+
+## Committing
+
+Add files to the commit (changed ones or new ones):
+
+```bash
+git add file1
+git add file2
+```
+
+Commit the change. Write a meaningful commit message (first word is for example
+the tool name):
+
+```bash
+git commit -m "tool: added a new feature doing X"
+```
+
+## Pushing changes to GitHub
+
+Push your local feature branch to your fork:
+
+```bash
+git push origin new-feature
+```
+
+## Creating a pull request
+
+When you push, GitHub will respond back in the command line to tell
+you what URL to use to create a pull request (PR). You can follow that URL
+or you can go any time later to your fork on GitHub, display the
+branch `new-feature`, and GitHub will show you a button to create
+a PR.
+
+Alternatively, you can explore GitHub CLI tool (_gh_) which allows you
+to do `git push` and create a PR in one step with `gh pr create -fw`.
+
+## After creating a PR
+
+GRASS GIS maintainers will now review your PR.
+If needed, the maintainers will work with you to improve your changes.
+
+Once the changes in the PR are ready to be accepted,
+the maintainers will usually squash all your commits into one commit and merge it
+to the _main_ branch.
+
+Once the PR is merged, it is a good time to [update your
+local _main_ branch](#update-before-creating-a-feature-branch) in order to get
+the change you just contributed.
+
+## Further notes
+
+Here we cover common situations and how to deal with them:
+
+### Update if you have local changes
+
+Assumption is you are on the main branch and you are trying to update it.
+If `git rebase` fails with `error: cannot rebase: You have unstaged changes...`,
+then move your uncommitted local changes to "stash" using:
+
+```bash
+git stash
+```
+
+Now you can rebase:
+
+```bash
+git rebase upstream/main
+```
+
+Get the changes back from stash:
+
+```bash
+git stash pop
+```
+
+### Updating your PR from main
+
+Updating your PR from the main branch is often referred to as rebasing a PR.
+It comes into play in case there are changes in the main branch you need to
+incorporate into your (feature or fix) branch before the PR can be merged,
+you need to merge the upstream main into your branch:
+
+```bash
+git fetch upstream
+git merge upstream/main
+```
+
+Git will ask you to edit the merge commit messsage, you can leave the default
+and close the editor. You may run into a conflict,
+in that case you need to resolve it.
+
+### Testing PRs from other contributors
+
+For testing other contributors' PRs, we recommend using
+[GitHub CLI](https://cli.github.com/). To checkout a specific PR, run:
+
+```bash
+gh pr checkout <PR number>
+```
=====================================
doc/help_loc_structure.odg deleted
=====================================
Binary files a/doc/help_loc_structure.odg and /dev/null differ
=====================================
doc/help_project_structure.odg
=====================================
Binary files /dev/null and b/doc/help_project_structure.odg differ
=====================================
doc/howto_release.md
=====================================
@@ -133,7 +133,7 @@ see: <https://help.github.com/en/articles/creating-releases>.
### Tag release
Before creating the tag, it is a good idea to see if the CI jobs are not failing.
-Check on GitHub or use GitHub CLI:
+Check on [GitHub Actions](https://github.com/OSGeo/grass/actions) or use GitHub CLI:
```bash
gh run list --branch releasebranch_8_4
@@ -152,7 +152,7 @@ stored for annotated tags including a date; message is suggested by the
`./utils/update_version.py` script):
```bash
-git tag $TAG -a -m "..."
+git tag $TAG -a -m "GRASS GIS $VERSION"
```
List all tags (annotated will be at the top of both lists):
@@ -174,15 +174,15 @@ so that you can continue in the release process.
### Create release notes
-Generate a draft of release notes using a script. The script the script needs to
+Generate a draft of release notes using a script. The script needs to be
run from the top directory and will expect its configuration files
to be in the _utils_ directory.
-#### Major and minor releases
+#### First RC of a major and minor releases
-For major (X.y.z) and minor (x.Y.z) releases, GitHub API gives good results for the
-first release candidate because it contains contributor handles and can identify
-new contributors, so use with the _api_ backend, e.g.:
+For a first RC of a major (X.y.z) and minor (x.Y.z) release, the GitHub API gives
+good results for the first release candidate because it contains contributor handles
+and can identify new contributors, so use with the _api_ backend, e.g.:
```bash
python ./utils/generate_release_notes.py api releasebranch_8_4 8.3.0 $VERSION
@@ -198,7 +198,7 @@ The _git log_ command operates on commits, so use use the _log_ backend:
python ./utils/generate_release_notes.py log releasebranch_8_4 8.4.0 $VERSION
```
-#### RCs
+#### Between RCs and from last RC to final release
In between RCs and between last RC and final release, the _log_ backend is useful
for showing updates since the last RC:
@@ -214,7 +214,7 @@ added manually to the result from the _api_ backend.
The script sorts them into categories defined in _utils/release.yml_.
However, these notes need to be manually edited to collapse related items into
-one. Additionally, a _Highlights_ section needs to be added with manually
+one. Additionally, a _Highlights_ section needs to be added on top with manually
identified new major features for major and minor releases. For all releases, a
_Major_ section may need to be added showing critical fixes or breaking changes
if there are any.
@@ -260,7 +260,8 @@ Eventually, commit with the suggested commit message and push, e.g.:
```bash
git show
-git commit include/VERSION -m "..."
+eval $(./utils/update_version.py status --bash)
+git commit include/VERSION -m "version: Back to $VERSION"
git push upstream
```
@@ -349,11 +350,14 @@ SERVER2=osgeo7-download
SERVER2DIR=/osgeo/download/grass/grass$MAJOR$MINOR/source/
echo $SERVER1:$SERVER1DIR
echo $SERVER2:$SERVER2DIR
+eval $(ssh-agent) && ssh-add
-# upload along with associated files:
+# upload along with associated files, creating target dir if still needed
+ssh $USER@$SERVER1 "mkdir -p $SERVER1DIR"
scp -p grass-$VERSION.* AUTHORS COPYING ChangeLog_$VERSION.gz \
INSTALL.md REQUIREMENTS.md CONTRIBUTING.md $USER@$SERVER1:$SERVER1DIR
+ssh $USER@$SERVER2 "mkdir -p $SERVER2DIR"
scp -p grass-$VERSION.* AUTHORS COPYING ChangeLog_$VERSION.gz \
INSTALL.md REQUIREMENTS.md CONTRIBUTING.md $USER@$SERVER2:$SERVER2DIR
@@ -528,7 +532,7 @@ Add release to history page:
## Tell others about release
-- If release candidate (just a short invitation to test):
+- If release candidate (just a short invitation to test it):
- <grass-dev at lists.osgeo.org>
- <grass-user at lists.osgeo.org>
=====================================
grasslib.dox
=====================================
@@ -203,9 +203,9 @@ as follows:
<!--
original:
- doc/help_loc_structure.odg
+ doc/help_project_structure.odg
-->
-\image html "loc_struct.png" "Diagram of GRASS file structure"
+\image html "help_project_structure.png" "Diagram of GRASS file structure"
\section Compiling_and_Installing_GRASS_Modules Compiling and Installing GRASS Modules
=====================================
gui/wxpython/gmodeler/dialogs.py
=====================================
@@ -412,12 +412,10 @@ class ModelRelationDialog(wx.Dialog):
flag=wx.EXPAND | wx.LEFT | wx.RIGHT | wx.BOTTOM,
border=5,
)
- mainSizer.Add(
- btnSizer, proportion=0, flag=wx.EXPAND | wx.ALL | wx.ALIGN_CENTER, border=5
- )
+ mainSizer.Add(btnSizer, proportion=0, flag=wx.EXPAND | wx.ALL, border=5)
self.panel.SetSizer(mainSizer)
- mainSizer.Fit(self.panel)
+ mainSizer.Fit(self)
self.Layout()
self.SetSize(self.GetBestSize())
=====================================
gui/wxpython/gmodeler/panels.py
=====================================
@@ -67,7 +67,6 @@ from gmodeler.giface import GraphicalModelerGrassInterface
from gmodeler.model import (
Model,
ModelAction,
- ModelData,
ModelRelation,
ModelLoop,
ModelCondition,
@@ -1136,7 +1135,7 @@ class ModelerPanel(wx.Panel, MainPageBase):
"""Add data item to model"""
# add action to canvas
width, height = self.canvas.GetSize()
- data = ModelData(
+ data = ModelDataSingle(
self, x=width / 2 + self._randomShift(), y=height / 2 + self._randomShift()
)
=====================================
include/VERSION
=====================================
@@ -1,4 +1,4 @@
8
4
-0RC1
+0
2024
=====================================
lib/init/Makefile
=====================================
@@ -25,7 +25,7 @@ FILES = \
$(ETC)/echo$(EXE) \
$(ETC)/license \
$(ETC)/VERSIONNUMBER \
- $(HTMLDIR)/help_loc_struct.png \
+ $(HTMLDIR)/help_project_structure.png \
$(HTMLDIR)/grassdb.png \
$(HTMLDIR)/location.png \
$(HTMLDIR)/location-add.png \
=====================================
lib/init/help_loc_struct.png deleted
=====================================
Binary files a/lib/init/help_loc_struct.png and /dev/null differ
=====================================
lib/init/help_project_structure.png
=====================================
Binary files /dev/null and b/lib/init/help_project_structure.png differ
=====================================
lib/loc_struct.png deleted
=====================================
Binary files a/lib/loc_struct.png and /dev/null differ
=====================================
raster/r.in.pdal/info.cpp
=====================================
@@ -116,7 +116,7 @@ void print_lasinfo(struct StringList *infiles)
std::cout << "Point offset: " << h.pointOffset() << "\n";
std::cout << "Point count: " << h.pointCount() << "\n";
for (size_t i = 0; i < pdal::LasHeader::RETURN_COUNT; ++i)
- std::cout << "Point count by return[" << i << "]: "
+ std::cout << "Point count by return[" << i + 1 << "]: "
<< const_cast<pdal::LasHeader &>(h).pointCountByReturn(i)
<< "\n";
std::cout << "Scales X/Y/Z: " << h.scaleX() << "/" << h.scaleY() << "/"
=====================================
raster/r.li/r.li.html
=====================================
@@ -211,7 +211,7 @@ for more information about development.
McGarigal, K., and B. J. Marks. 1995. FRAGSTATS: spatial pattern
analysis program for quantifying landscape structure. USDA For. Serv.
Gen. Tech. Rep. PNW-351
- (<a href="http://www.fs.fed.us/pnw/pubs/gtr_351.pdf">PDF</a>).
+ (<a href="https://research.fs.usda.gov/treesearch/3064">PDF</a>).
<li>
Baker, W.L. and Y. Cai. 1992. The r.le programs for multiscale analysis of
=====================================
utils/generate_release_notes.py
=====================================
@@ -66,7 +66,7 @@ def split_to_categories(changes, categories):
def print_section_heading_2(text, file=None):
- print(f"### {text}\n", file=file)
+ print(f"## {text}\n", file=file)
def print_section_heading_3(text, file=None):
@@ -123,11 +123,35 @@ def print_by_category(changes, categories, file=None):
def binder_badge(tag):
"""Get mybinder Binder badge from a given tag, hash, or branch"""
- binder_image_url = "https://camo.githubusercontent.com/581c077bdbc6ca6899c86d0acc6145ae85e9d80e6f805a1071793dbe48917982/68747470733a2f2f6d7962696e6465722e6f72672f62616467655f6c6f676f2e737667" # noqa
+ binder_image_url = "https://mybinder.org/badge_logo.svg"
binder_url = f"https://mybinder.org/v2/gh/OSGeo/grass/{tag}?urlpath=lab%2Ftree%2Fdoc%2Fnotebooks%2Fjupyter_example.ipynb" # noqa
return f"[]({binder_url})"
+def adjust_after(lines):
+ """Adjust new contributor lines in the last part of the generated notes"""
+ bot_file = Path("utils") / "known_bot_names.txt"
+ known_bot_names = bot_file.read_text().splitlines()
+ new_lines = []
+ for line in lines:
+ if line.startswith("* @"):
+ unused, username, text = line.split(" ", maxsplit=2)
+ username = username.replace("@", "")
+ if username in known_bot_names:
+ continue
+ output = subprocess.run(
+ ["gh", "api", f"users/{username}"],
+ capture_output=True,
+ text=True,
+ check=True,
+ ).stdout
+ name = json.loads(output)["name"]
+ if name and name != username:
+ line = f"* {name} (@{username}) {text}"
+ new_lines.append(line)
+ return new_lines
+
+
def print_notes(
start_tag, end_tag, changes, categories, before=None, after=None, file=None
):
@@ -145,6 +169,8 @@ def print_notes(
if before:
print(before)
+ print_section_heading_2("Highlights", file=file)
+ print("* _Put handcrafted list of items here._\n")
print_section_heading_2("What's Changed", file=file)
changes_by_category = split_to_categories(changes, categories=categories)
print_by_category(changes_by_category, categories=categories, file=file)
@@ -185,12 +211,13 @@ def notes_from_gh_api(start_tag, end_tag, branch, categories, exclude):
else:
changes.append(change)
changes = remove_excluded_changes(changes=changes, exclude=exclude)
+ after = adjust_after(lines[end_whats_changed + 1 :])
print_notes(
start_tag=start_tag,
end_tag=end_tag,
changes=changes,
before="\n".join(lines[:start_whats_changed]),
- after="\n".join(lines[end_whats_changed + 1 :]),
+ after="\n".join(after),
categories=categories,
)
View it on GitLab: https://salsa.debian.org/debian-gis-team/grass/-/compare/fc2f6d87351008d64d5ff55a5834011c83152e5b...be3315a68ab93ed40019e516d719ccd467f58746
--
View it on GitLab: https://salsa.debian.org/debian-gis-team/grass/-/compare/fc2f6d87351008d64d5ff55a5834011c83152e5b...be3315a68ab93ed40019e516d719ccd467f58746
You're receiving this email because of your account on salsa.debian.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-grass-devel/attachments/20240729/821c3606/attachment-0001.htm>
More information about the Pkg-grass-devel
mailing list