{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":377930558,"defaultBranch":"latest-in-ATTIC","name":"PackageKit_ATTIC","ownerLogin":"imz","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2021-06-17T18:46:00.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/740014?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1718617247.0","currentOid":""},"activityList":{"items":[{"before":"e162daf69109c68be6dcc326f830543ab9893770","after":null,"ref":"refs/heads/1.2.3-alt2imz3/sisyphus","pushedAt":"2024-06-17T09:40:47.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"}},{"before":"90bccfd77185199d440eb4cb817bc63097844391","after":null,"ref":"refs/heads/1.2.3-alt2imz2/sisyphus","pushedAt":"2024-06-17T09:40:47.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"}},{"before":"217ee496638b6bc7440e007d63a14e29a4308718","after":null,"ref":"refs/heads/1.2.3-alt2imz2/revert-apt-API","pushedAt":"2024-06-17T09:40:47.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"}},{"before":"f2cb6849b2a4623b3759af23606d2ff35ff78128","after":null,"ref":"refs/heads/1.2.3-alt2imz2/new-ABI-tmp","pushedAt":"2024-06-17T09:40:47.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"}},{"before":"8f7ca821d1b9a0003afd6fdc996f0103a91042be","after":null,"ref":"refs/heads/1.2.3-alt2imz2/lazyCacheFile","pushedAt":"2024-06-17T09:40:47.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"}},{"before":null,"after":"d87913d54f9ae7450594bcbe7b9ffc6188ea447e","ref":"refs/heads/mark-overrides_traditionalAPI","pushedAt":"2024-06-11T15:42:01.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"aptcc: -Wsuggest-override (as an error) as a style enforcement\n\nto make sure we haven't missed any overrides.\n\nIf we have marked all overrides now, in future, when API changes, the\ncompiler would detect dependent required changes of the methods that\nare intended to be overrides.","shortMessageHtmlLink":"aptcc: -Wsuggest-override (as an error) as a style enforcement"}},{"before":null,"after":"cde62c87d901ab1ca2ceded5756db5a43b713b4f","ref":"refs/heads/sisyphus1_3","pushedAt":"2024-06-08T18:21:40.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"1.1.12-alt12\n\n- Imported changes from upstream.\n\n(cherry picked from commit 21b36a0131abc34438411fe13e5c8035aea99124)","shortMessageHtmlLink":"1.1.12-alt12"}},{"before":null,"after":"ce78b607fae6b2d82dfde917e8deaeb28a9f4b28","ref":"refs/heads/sisyphus0_3","pushedAt":"2024-06-08T18:21:00.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"1.1.12-alt12\n\n- Imported changes from upstream.\n\n(cherry picked from commit 21b36a0131abc34438411fe13e5c8035aea99124)","shortMessageHtmlLink":"1.1.12-alt12"}},{"before":null,"after":"12ceb1217cf2731731c39b83b9c8c92c6df25d11","ref":"refs/heads/p9_4_1","pushedAt":"2024-06-08T18:18:36.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"%%changelog: +1\n\n(cherry picked from commit acaa67b0e633a3bead76ba5375d73e381f68f1c9)","shortMessageHtmlLink":"%%changelog: +1"}},{"before":"3661e3e8ca76de3b25183bddaf6146e3b83a65e0","after":"520e466af9c515afd21b764ba95c99d3968f5cce","ref":"refs/heads/1.1.13.0.0.5p9_4_2","pushedAt":"2024-06-08T18:16:03.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"merge -s ours p9 (into the head of a rebased ALT's p9 history on top of some new upstream commits: 1.1.13.0.0.5p9_4_2)\n\n(It's like a non-existent \"-s theirs\" merge of the rebased history into\nthe p9 branch. I believe that having the rebased history as the first\nparent of the merge is convenient for exploring the history with\n\"git blame --first-parent\", so that one sees the refactored commits.)\n\nThis time, the only substantial differences to the previous p9 commit are\nthe few new upstream commits from the PACKAGEKIT_1_1_X branch (all of them)\n(see the diff to the last ALT release--the second parent of the merge commit).\n\nThe ALT's changes are easier to track and understand if they get rebased\nand sometimes rewritten to better present their ideas; this also keeps\nthem prepared for submitting upstream.\n\nI'd like to continue to follow this scheme, i.e.:\n\n* first, as usual, make new/backported changes in the p9 branch (for ALT's releases);\n* then, before a rebase, they are cherry-picked (with \"-x\") to the branch with\n  the rebased ALT's history (including even the commits touching the spec-file);\n* optionally, the ALT's history is rewritten (to be more clear as a whole);\n* finally (and also optionally), the ALT's history is rebased onto a new\n  upstream release (or just some uptream commit);\n* and a similar merge is done \"into\" the p9 branch, so that the contents\n  of the rebased and rewritten ALT's history replaces the previous tree in\n  the Sisyphus branch (i.e., it should be like an \"-s theirs\" merge).\n\n(Notes on how I'm going to manage the rebased branch(es) and their naming:\n\nIt's faster for doing the rebases to have it always under the same\nname, without renaming it based on the base upstream version; say,\njust p9_4 or sisyphus10, meaning, the 4th or the 10th revision of the\npatch series.\n\nWhen I rewrite the patch series in a noticeable way, however, I'd\nchange the number at the end of the name--in order to keep track of\nthe different revisions of the patch series.\n\nWhen doing a merge (like this one) with the built branch (sisyphus, p9,\netc), I'd give a distinctive name to the branch based on the base\nupstream version. This action doesn't happen so often, not so often as\nall the mundane rebases of the patch series. And actually there is no\nbig necessity in a distinctive name in this case, perhaps, just for\nclarity when looking at the history graph and for technical\nconvenience of the merge commands.\n\nThere are two cases when a merge like this is done:\n1. after rebasing the series of ALT's patches onto a new upstream version;\n2. after rewriting the series of ALT's patches (to present them differently).\nI'd keep these two kinds of merges separate. In the 2nd kind of case,\nthe rewriting results in no substantial difference to the parent ALT's\nrelease; and this property is easier to verify if there is a merge separate\nfrom the 1st kind of case, which brings new code.)","shortMessageHtmlLink":"merge -s ours p9 (into the head of a rebased ALT's p9 history on top …"}},{"before":null,"after":"1c5f560f1b49e8034582f321f00303769f89d60c","ref":"refs/heads/p9_4_3","pushedAt":"2024-06-08T18:14:13.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"%%changelog: +1\n\n(cherry picked from commit acaa67b0e633a3bead76ba5375d73e381f68f1c9)","shortMessageHtmlLink":"%%changelog: +1"}},{"before":null,"after":"627ed5ffc095e6afc55a3abe080917f281bd981e","ref":"refs/heads/1.1.13.0.0.5p9_4_3","pushedAt":"2024-06-08T18:13:41.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"merge -s ours p9 (into the head of a rebased ALT's p9 history on top of some new upstream commits: 1.1.13.0.0.5p9_4_3)\n\n(It's like a non-existent \"-s theirs\" merge of the rebased history into\nthe p9 branch. I believe that having the rebased history as the first\nparent of the merge is convenient for exploring the history with\n\"git blame --first-parent\", so that one sees the refactored commits.)\n\nThis time, the only substantial differences to the previous p9 commit are\nthe few new upstream commits from the PACKAGEKIT_1_1_X branch (all of them)\n(see the diff to the last ALT release--the second parent of the merge commit).\n\nThe ALT's changes are easier to track and understand if they get rebased\nand sometimes rewritten to better present their ideas; this also keeps\nthem prepared for submitting upstream.\n\nI'd like to continue to follow this scheme, i.e.:\n\n* first, as usual, make new/backported changes in the p9 branch (for ALT's releases);\n* then, before a rebase, they are cherry-picked (with \"-x\") to the branch with\n  the rebased ALT's history (including even the commits touching the spec-file);\n* optionally, the ALT's history is rewritten (to be more clear as a whole);\n* finally (and also optionally), the ALT's history is rebased onto a new\n  upstream release (or just some uptream commit);\n* and a similar merge is done \"into\" the p9 branch, so that the contents\n  of the rebased and rewritten ALT's history replaces the previous tree in\n  the Sisyphus branch (i.e., it should be like an \"-s theirs\" merge).\n\n(Notes on how I'm going to manage the rebased branch(es) and their naming:\n\nIt's faster for doing the rebases to have it always under the same\nname, without renaming it based on the base upstream version; say,\njust p9_4 or sisyphus10, meaning, the 4th or the 10th revision of the\npatch series.\n\nWhen I rewrite the patch series in a noticeable way, however, I'd\nchange the number at the end of the name--in order to keep track of\nthe different revisions of the patch series.\n\nWhen doing a merge (like this one) with the built branch (sisyphus, p9,\netc), I'd give a distinctive name to the branch based on the base\nupstream version. This action doesn't happen so often, not so often as\nall the mundane rebases of the patch series. And actually there is no\nbig necessity in a distinctive name in this case, perhaps, just for\nclarity when looking at the history graph and for technical\nconvenience of the merge commands.\n\nThere are two cases when a merge like this is done:\n1. after rebasing the series of ALT's patches onto a new upstream version;\n2. after rewriting the series of ALT's patches (to present them differently).\nI'd keep these two kinds of merges separate. In the 2nd kind of case,\nthe rewriting results in no substantial difference to the parent ALT's\nrelease; and this property is easier to verify if there is a merge separate\nfrom the 1st kind of case, which brings new code.)","shortMessageHtmlLink":"merge -s ours p9 (into the head of a rebased ALT's p9 history on top …"}},{"before":null,"after":"d20e9c7e4eba9a58b1e24a912fcd2c3669785df8","ref":"refs/heads/1.1.12.0.0.0sisyphus0_3","pushedAt":"2024-06-08T18:11:31.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"merge -s ours c9 (into the head of a rebased ALT's history: 1.1.12.0.0.0sisyphus0_3)\n\n(It's like a non-existent \"-s theirs\" merge of the rebased history into\nthe c9 branch. I believe that having the rebased history as the first\nparent of the merge is convenient for exploring the history with\n\"git blame --first-parent\", so that one sees the refactored commits.)\n\nThis time, the substantial differences to the previous c9 commit are\nsome ALT's changes for verifying our build that I wanted to apply early\nin the history.\n(See the diff to the last ALT release--the second parent of the merge commit.)\n\nThe ALT's changes are easier to track and understand if they get rebased\nand sometimes rewritten to better present their ideas; this also keeps\nthem prepared for submitting upstream.\n\nI'd like to continue to follow this scheme, i.e.:\n\n* first, as usual, make new/backported changes in the c9 branch (for ALT's releases);\n* then, before a rebase, they are cherry-picked (with \"-x\") to the branch with\n  the rebased ALT's history (including even the commits touching the spec-file);\n* optionally, the ALT's history is rewritten (to be more clear as a whole);\n* finally (and also optionally), the ALT's history is rebased onto a new\n  upstream release (or just some uptream commit);\n* and a similar merge is done \"into\" the c9 branch, so that the contents\n  of the rebased and rewritten ALT's history replaces the previous tree in\n  the Sisyphus branch (i.e., it should be like an \"-s theirs\" merge).\n\n(Notes on how I'm going to manage the rebased branch(es) and their naming:\n\nIt's faster for doing the rebases to have it always under the same\nname, without renaming it based on the base upstream version; say,\njust c9_4 or sisyphus10, meaning, the 4th or the 10th revision of the\npatch series.\n\nWhen I rewrite the patch series in a noticeable way, however, I'd\nchange the number at the end of the name--in order to keep track of\nthe different revisions of the patch series.\n\nWhen doing a merge (like this one) with the built branch (sisyphus, c9,\netc), I'd give a distinctive name to the branch based on the base\nupstream version. This action doesn't happen so often, not so often as\nall the mundane rebases of the patch series. And actually there is no\nbig necessity in a distinctive name in this case, perhaps, just for\nclarity when looking at the history graph and for technical\nconvenience of the merge commands.\n\nThere are two cases when a merge like this is done:\n1. after rebasing the series of ALT's patches onto a new upstream version;\n2. after rewriting the series of ALT's patches (to present them differently).\nI'd keep these two kinds of merges separate. In the 2nd kind of case,\nthe rewriting results in no substantial difference to the parent ALT's\nrelease; and this property is easier to verify if there is a merge separate\nfrom the 1st kind of case, which brings new code.)","shortMessageHtmlLink":"merge -s ours c9 (into the head of a rebased ALT's history: 1.1.12.0.…"}},{"before":null,"after":"be9d2349a3a57a38b515d67a3350ddc9c34c1982","ref":"refs/heads/checkinstall_traditionalAPI","pushedAt":"2024-06-08T18:09:16.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"Requires: apt # It provides the stuff needed to run the APT backend\n\nThe stuff needed to run the APT backend: the download methods\n(/usr/lib*/apt/methods/), conf files (/etc/apt/), and cache dirs\n(/var/cache/apt/archives/).\n\nThis fixes the error messages like this when trying to use the APT\nbackend without having apt installed:\n\n    # /usr/lib/packagekit-direct search-detail packagekit; echo $?\n    Status: wait\n    Status: loading-cache\n    Done: 100%\n\n    (packagekit-direct:7251): PackageKit-APTcc-WARNING **: 11:37:53.571: Could not open file /etc/apt/pkgpriorities - open (2 No such file or directory)\n\n    (packagekit-direct:7251): PackageKit-APTcc-WARNING **: 11:37:53.571: could not open package priority file /etc/apt/pkgpriorities\n    Error: cannot-get-lock  E: Could not open file /etc/apt/pkgpriorities - open (2 No such file or directory)\n    E: could not open package priority file /etc/apt/pkgpriorities\n\n    Status: finished\n    Exit code: failed\n    0","shortMessageHtmlLink":"Requires: apt # It provides the stuff needed to run the APT backend"}},{"before":null,"after":"9f24206f3c042845879e569938763284329c37a2","ref":"refs/heads/verify-elf_traditionalAPI","pushedAt":"2024-06-08T18:08:31.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"(.spec) apply verify-elf to the backend+packagekit-direct (in the strict manner)\n\nThis would catch some errors; either:\n\n* bad, incorrectly compiled&linked backend modules (which would\n  supposedly be unusable in both \"main\" executables: packagekit-direct\n  or packgekitd);\n\n* bad, incorrectly compiled packagekit-direct executable (which would\n  not work with the backend modules; as in\n  <https://github.com/PackageKit/PackageKit/issues/477>).\n\nWe can't verify the symbols in the modules against both \"main\"\nexecutables, so we choose the one that is used less frequently for it\nto receive more \"testing\".\n\nWith this change, the package wouldn't build correctly without the fix\nin the previous commit:\n\nAuthor: Ivan Zakharyaschev <imz@altlinux.org>\nDate:   Thu May 20 22:43:08 2021 +0300\n\n    packagekit-direct: make backends that use pk-backend-spawn work (#477)\n\n    The packagekit-direct executable couldn't use backends that use\n    functions from pk-backend-spawn.h, e.g., the APT backend:\n\n    # /usr/lib/packagekit-direct refresh\n    Failed to load the backend: opening module aptcc failed : /usr/lib64/packagekit-backend/libpk_backend_aptcc.so: undefined symbol: pk_backend_spawn_set_name","shortMessageHtmlLink":"(.spec) apply verify-elf to the backend+packagekit-direct (in the str…"}},{"before":null,"after":"3661e3e8ca76de3b25183bddaf6146e3b83a65e0","ref":"refs/heads/1.1.13.0.0.5p9_4_2","pushedAt":"2024-06-06T16:03:22.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"merge -s ours p9 (into the head of a rebased ALT's p9 history on top of some new upstream commits: 1.1.13.0.0.5p9_4_2)\n\n(It's like a non-existent \"-s theirs\" merge of the rebased history into\nthe p9 branch. I believe that having the rebased history as the first\nparent of the merge is convenient for exploring the history with\n\"git blame --first-parent\", so that one sees the refactored commits.)\n\nThis time, the differences to the previous p9 commit are not substantial\n(see the diff to the last ALT release--the second parent of the merge commit).\n\nThe ALT's changes are easier to track and understand if they get rebased\nand sometimes rewritten to better present their ideas; this also keeps\nthem prepared for submitting upstream.\n\nI'd like to continue to follow this scheme, i.e.:\n\n* first, as usual, make new/backported changes in the p9 branch (for ALT's releases);\n* then, before a rebase, they are cherry-picked (with \"-x\") to the branch with\n  the rebased ALT's history (including even the commits touching the spec-file);\n* optionally, the ALT's history is rewritten (to be more clear as a whole);\n* finally (and also optionally), the ALT's history is rebased onto a new\n  upstream release (or just some uptream commit);\n* and a similar merge is done \"into\" the p9 branch, so that the contents\n  of the rebased and rewritten ALT's history replaces the previous tree in\n  the Sisyphus branch (i.e., it should be like an \"-s theirs\" merge).\n\n(Notes on how I'm going to manage the rebased branch(es) and their naming:\n\nIt's faster for doing the rebases to have it always under the same\nname, without renaming it based on the base upstream version; say,\njust p9_4 or sisyphus10, meaning, the 4th or the 10th revision of the\npatch series.\n\nWhen I rewrite the patch series in a noticeable way, however, I'd\nchange the number at the end of the name--in order to keep track of\nthe different revisions of the patch series.\n\nWhen doing a merge (like this one) with the built branch (sisyphus, p9,\netc), I'd give a distinctive name to the branch based on the base\nupstream version. This action doesn't happen so often, not so often as\nall the mundane rebases of the patch series. And actually there is no\nbig necessity in a distinctive name in this case, perhaps, just for\nclarity when looking at the history graph and for technical\nconvenience of the merge commands.\n\nThere are two cases when a merge like this is done:\n1. after rebasing the series of ALT's patches onto a new upstream version;\n2. after rewriting the series of ALT's patches (to present them differently).\nI'd keep these two kinds of merges separate. In the 2nd kind of case,\nthe rewriting results in no substantial difference to the parent ALT's\nrelease; and this property is easier to verify if there is a merge separate\nfrom the 1st kind of case, which brings new code.)","shortMessageHtmlLink":"merge -s ours p9 (into the head of a rebased ALT's p9 history on top …"}},{"before":null,"after":"1ad5ef7d919b00a7454dc69502042a4e1a6ec0ff","ref":"refs/heads/1.1.13.0.0.3p9_4_2","pushedAt":"2024-06-06T16:03:12.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"1.1.13-alt1.p9.1\n\n- Updated to upstream version 1.1.13 (the latest version in 1_1_X branch).\n\n(cherry picked from commit 97f61abaa955bb5e40b8be4b31e905d8153d5585)","shortMessageHtmlLink":"1.1.13-alt1.p9.1"}},{"before":null,"after":"42094b886f2d9965398ceb86b064a78b553d6557","ref":"refs/heads/new-apt-API","pushedAt":"2024-06-04T16:27:59.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"Migrate to new Apt ABI","shortMessageHtmlLink":"Migrate to new Apt ABI"}},{"before":null,"after":"c50e093a4a888fd335143d3daab40a50f541e1e9","ref":"refs/heads/apt-traditionalAPI","pushedAt":"2024-06-04T16:27:15.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"1.1.12-alt5\n\n- Fixed crash during showing errors.\n- Enabled verbose logging for packagekit service.","shortMessageHtmlLink":"1.1.12-alt5"}},{"before":null,"after":"790622d308d1143ba7909b3f922f4d6abbc19369","ref":"refs/heads/1.1.13.0.0.3p9_4_1","pushedAt":"2024-05-30T15:40:31.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"merge -s ours 1.1.13-alt1.p9.1 (into the head of a rebased ALT's p9 history: 1.1.13.0.0.3p9_4_1)\n\n(It's like a non-existent \"-s theirs\" merge of the rebased history into\nthe p9 branch. I believe that having the rebased history as the first\nparent of the merge is convenient for exploring the history with\n\"git blame --first-parent\", so that one sees the refactored commits.)\n\nThis time, the differences to the previous p9 commit are not substantial\n(see the diff to the last ALT release--the second parent of the merge commit).\n\nThe ALT's changes are easier to track and understand if they get rebased\nand sometimes rewritten to better present their ideas; this also keeps\nthem prepared for submitting upstream.\n\nI'd like to continue to follow this scheme, i.e.:\n\n* first, as usual, make new/backported changes in the p9 branch (for ALT's releases);\n* then, before a rebase, they are cherry-picked (with \"-x\") to the branch with\n  the rebased ALT's history (including even the commits touching the spec-file);\n* optionally, the ALT's history is rewritten (to be more clear as a whole);\n* finally (and also optionally), the ALT's history is rebased onto a new\n  upstream release (or just some uptream commit);\n* and a similar merge is done \"into\" the p9 branch, so that the contents\n  of the rebased and rewritten ALT's history replaces the previous tree in\n  the Sisyphus branch (i.e., it should be like an \"-s theirs\" merge).\n\n(Notes on how I'm going to manage the rebased branch(es) and their naming:\n\nIt's faster for doing the rebases to have it always under the same\nname, without renaming it based on the base upstream version; say,\njust p9_4 or sisyphus10, meaning, the 4th or the 10th revision of the\npatch series.\n\nWhen I rewrite the patch series in a noticeable way, however, I'd\nchange the number at the end of the name--in order to keep track of\nthe different revisions of the patch series.\n\nWhen doing a merge (like this one) with the built branch (sisyphus, p9,\netc), I'd give a distinctive name to the branch based on the base\nupstream version. This action doesn't happen so often, not so often as\nall the mundane rebases of the patch series. And actually there is no\nbig necessity in a distinctive name in this case, perhaps, just for\nclarity when looking at the history graph and for technical\nconvenience of the merge commands.\n\nThere are two cases when a merge like this is done:\n1. after rebasing the series of ALT's patches onto a new upstream version;\n2. after rewriting the series of ALT's patches (to present them differently).\nI'd keep these two kinds of merges separate. In the 2nd kind of case,\nthe rewriting results in no substantial difference to the parent ALT's\nrelease; and this property is easier to verify if there is a merge separate\nfrom the 1st kind of case, which brings new code.)","shortMessageHtmlLink":"merge -s ours 1.1.13-alt1.p9.1 (into the head of a rebased ALT's p9 h…"}},{"before":null,"after":"328cac6af6449d45be98e6248af1c7c237fb1c75","ref":"refs/heads/1.1.13.0.0.5p9_4_1","pushedAt":"2024-05-30T15:40:03.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"merge -s ours p9 (into the head of a rebased ALT's p9 history on top of some new upstream commits: 1.1.13.0.0.5p9_4_1)\n\n(It's like a non-existent \"-s theirs\" merge of the rebased history into\nthe p9 branch. I believe that having the rebased history as the first\nparent of the merge is convenient for exploring the history with\n\"git blame --first-parent\", so that one sees the refactored commits.)\n\nThis time, the differences to the previous p9 commit are not substantial\n(see the diff to the last ALT release--the second parent of the merge commit).\n\nThe ALT's changes are easier to track and understand if they get rebased\nand sometimes rewritten to better present their ideas; this also keeps\nthem prepared for submitting upstream.\n\nI'd like to continue to follow this scheme, i.e.:\n\n* first, as usual, make new/backported changes in the p9 branch (for ALT's releases);\n* then, before a rebase, they are cherry-picked (with \"-x\") to the branch with\n  the rebased ALT's history (including even the commits touching the spec-file);\n* optionally, the ALT's history is rewritten (to be more clear as a whole);\n* finally (and also optionally), the ALT's history is rebased onto a new\n  upstream release (or just some uptream commit);\n* and a similar merge is done \"into\" the p9 branch, so that the contents\n  of the rebased and rewritten ALT's history replaces the previous tree in\n  the Sisyphus branch (i.e., it should be like an \"-s theirs\" merge).\n\n(Notes on how I'm going to manage the rebased branch(es) and their naming:\n\nIt's faster for doing the rebases to have it always under the same\nname, without renaming it based on the base upstream version; say,\njust p9_4 or sisyphus10, meaning, the 4th or the 10th revision of the\npatch series.\n\nWhen I rewrite the patch series in a noticeable way, however, I'd\nchange the number at the end of the name--in order to keep track of\nthe different revisions of the patch series.\n\nWhen doing a merge (like this one) with the built branch (sisyphus, p9,\netc), I'd give a distinctive name to the branch based on the base\nupstream version. This action doesn't happen so often, not so often as\nall the mundane rebases of the patch series. And actually there is no\nbig necessity in a distinctive name in this case, perhaps, just for\nclarity when looking at the history graph and for technical\nconvenience of the merge commands.\n\nThere are two cases when a merge like this is done:\n1. after rebasing the series of ALT's patches onto a new upstream version;\n2. after rewriting the series of ALT's patches (to present them differently).\nI'd keep these two kinds of merges separate. In the 2nd kind of case,\nthe rewriting results in no substantial difference to the parent ALT's\nrelease; and this property is easier to verify if there is a merge separate\nfrom the 1st kind of case, which brings new code.)","shortMessageHtmlLink":"merge -s ours p9 (into the head of a rebased ALT's p9 history on top …"}},{"before":"428afc0cff6d049ff639e798f82d314500428979","after":null,"ref":"refs/heads/1.1.13.0.0.5p9.4.1","pushedAt":"2024-05-30T15:06:02.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"}},{"before":"66bc57c84f88858a3645b975c4da9d5c1ec60b0f","after":null,"ref":"refs/heads/p9_1.1.13.0.0.5p9.4.1","pushedAt":"2024-05-30T15:03:35.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"}},{"before":"855efb64c051fa7be872514110b36a22d382cf8b","after":null,"ref":"refs/heads/p9_1.1.13.0.0.3p9.4.1","pushedAt":"2024-05-28T03:16:00.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"}},{"before":"ff3312d64d164e834ba3771b0c0d900afb4519a2","after":null,"ref":"refs/heads/1.1.13.0.0.3p9.4.1","pushedAt":"2024-05-28T03:15:00.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"}},{"before":null,"after":"0c16633f2dd1c4248cf8a3b11090c1cab903c589","ref":"refs/heads/1.2.0.0.0.0revert-not-ALT","pushedAt":"2024-05-26T17:56:19.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"Revert \"aptcc: Implement frontend-locking\"\n\nThis reverts commit 5ba21995f9a212076bc8957d1ef1be7110ec1db4.\n\n(cherry picked from commit a75a9dd1ec90c0deb2b872771f202abb41ebea59)","shortMessageHtmlLink":"Revert \"aptcc: Implement frontend-locking\""}},{"before":null,"after":"a5dea6d47912e8ac6c7163142f916696db8dbdeb","ref":"refs/heads/1.1.13.0.0.3revert-not-ALT","pushedAt":"2024-05-26T17:55:45.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"Revert \"aptcc: Implement frontend-locking\"\n\nThis reverts commit 5ba21995f9a212076bc8957d1ef1be7110ec1db4.\n\n(cherry picked from commit a75a9dd1ec90c0deb2b872771f202abb41ebea59)","shortMessageHtmlLink":"Revert \"aptcc: Implement frontend-locking\""}},{"before":null,"after":"ae326cbfcf681c8db9d40f2e19ff833758627d2c","ref":"refs/heads/revert-not-ALT","pushedAt":"2024-05-26T17:55:15.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"Revert \"aptcc: Implement frontend-locking\"\n\nThis reverts commit 5ba21995f9a212076bc8957d1ef1be7110ec1db4.\n\n(cherry picked from commit a75a9dd1ec90c0deb2b872771f202abb41ebea59)","shortMessageHtmlLink":"Revert \"aptcc: Implement frontend-locking\""}},{"before":null,"after":"eadb00a4f47479a8d12918e1942e82d76407e272","ref":"refs/heads/1.2.0.0.0.0sisyphus4.1","pushedAt":"2024-05-26T17:54:37.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"1.2.0-alt1\n\n- Updated to upstream version 1.2.0.\n\n(cherry picked from commit aade094c601287febcca44198f09232ed4377518)","shortMessageHtmlLink":"1.2.0-alt1"}},{"before":null,"after":"f5fd693b762585df714581307f37fae7f5084951","ref":"refs/heads/const-arg-in-body","pushedAt":"2024-05-26T17:53:56.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"imz","name":"Ivan Zakharyaschev","path":"/imz","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/740014?s=80&v=4"},"commit":{"message":"aptcc: mark as const arguments in the implementation of a method\n\n...as a little help in maintaining the code. (The more things are\nexplicit and rigid, the easier it will be to change the code without\nbeing afraid of introducing errors. For example, this method might\nsome day take arguments by reference.)\n\n(Adding the const modifiers in the declaration in the header is just a\nmatter of taste/style. There is no need for them in the header, since\nthey don't affect the API, but just express a property of the\nimplementation of the function: the body of the function doesn't need\nto modify these copies.)","shortMessageHtmlLink":"aptcc: mark as const arguments in the implementation of a method"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEZzOzuAA","startCursor":null,"endCursor":null}},"title":"Activity · imz/PackageKit_ATTIC"}