{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":47560213,"defaultBranch":"master","name":"ostree","ownerLogin":"jlebon","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2015-12-07T15:20:40.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/11934099?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1711038304.0","currentOid":""},"activityList":{"items":[{"before":null,"after":"05b3b662756def30026fc722d0832a24a33d9803","ref":"refs/heads/pr/on-failure-isolate","pushedAt":"2024-03-21T16:25:04.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"ostree-prepare-root.service: add OnFailureJobMode=isolate\n\nThis is stronger than the default (`replace`) because it tells systemd\nto *stop everything* and go to `emergency.target`. In other codebases,\nthis has definitely helped me with the problem of \"systemd keeps going\neven after a failure\".\n\nLikely addresses #3219.\n\nSee also e.g. https://github.com/coreos/ignition-dracut/commit/3d2e165f97f30c1e62577357f27f32e60e6add18.","shortMessageHtmlLink":"ostree-prepare-root.service: add OnFailureJobMode=isolate"}},{"before":"31b804f20d2265d9c8ec806665841688b3eecfbc","after":"15ec3399c2e7f23ad13a9a225893729c19dd729c","ref":"refs/heads/pr/main","pushedAt":"2024-02-06T19:47:12.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"generator: Restore graceful exit behaviour if `ostree` karg missing\n\nIn CoreOS live environments, we do have `/run/ostree` but no `ostree=`\nkarg; we hackily fool `ostree-prepare-root.service` by bind-mounting\nover `/proc/cmdline` so it does the right thing. Presumably, we should\nclean this up eventually, but even so we don't want to require PXE users\nto add an `ostree=` arg, so we need to tolerate this.\n\nSo this assertion would fail there. Restore the behaviour prior to\nb9ce0e89 and re-add a more contemporary comment.\n\nFixes b9ce0e89 (\"generator: Exit if there's no `/run/ostree`\").","shortMessageHtmlLink":"generator: Restore graceful exit behaviour if <code>ostree</code> karg missing"}},{"before":null,"after":"31b804f20d2265d9c8ec806665841688b3eecfbc","ref":"refs/heads/pr/main","pushedAt":"2024-02-06T15:27:39.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"admin/state-overlay: Require root and don't lock sysroot\n\nNot required for anything in particular, but it's good to use the right\nflags here anyway.","shortMessageHtmlLink":"admin/state-overlay: Require root and don't lock sysroot"}},{"before":"9ffae90d770477668bea3110f296bc7378f8dc67","after":"e233d0236fbf9b28698f7b2cf7464d63b009dda5","ref":"refs/heads/pr/state-overlays","pushedAt":"2024-01-10T20:41:21.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"build(deps): bump libglnx from `aff1eea` to `b415d046`\n\nBumps libglnx from `aff1eea` to `b415d046`.\n\nFor https://gitlab.gnome.org/GNOME/libglnx/-/merge_requests/52.\n\nUpdate submodule: libglnx","shortMessageHtmlLink":"build(deps): bump libglnx from <code>aff1eea</code> to <code>b415d046</code>"}},{"before":"92b1a2720234dc01edfe44b8a188ba5c754027c0","after":"9ffae90d770477668bea3110f296bc7378f8dc67","ref":"refs/heads/pr/state-overlays","pushedAt":"2024-01-10T18:18:23.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"build(deps): bump libglnx from `aff1eea` to `b415d046`\n\nBumps libglnx from `aff1eea` to `b415d046`.\n\nFor https://gitlab.gnome.org/GNOME/libglnx/-/merge_requests/52.","shortMessageHtmlLink":"build(deps): bump libglnx from <code>aff1eea</code> to <code>b415d046</code>"}},{"before":"30ec1867ddff243343e4f8513f412b4e7f2adc25","after":"92b1a2720234dc01edfe44b8a188ba5c754027c0","ref":"refs/heads/pr/state-overlays","pushedAt":"2024-01-10T04:20:44.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"Add concept of state overlays\n\nIn the OSTree model, executables go in `/usr`, state in `/var` and\nconfiguration in `/etc`. Software that lives in `/opt` however messes\nthis up because it often mixes code *and* state, making it harder to\nmanage.\n\nMore generally, it's sometimes useful to have the OSTree commit contain\ncode under a certain path, but still allow that path to be writable by\nsoftware and the sysadmin at runtime (`/usr/local` is another instance).\n\nAdd the concept of state overlays. A state overlay is an overlayfs\nmount whose upper directory, which contains unmanaged state, is carried\nforward on top of a lower directory, containing OSTree-managed files.\n\nIn the example of `/usr/local`, OSTree commits can ship content there,\nall while allowing users to e.g. add scripts in `/usr/local/bin` when\nbooted into that commit.\n\nSome reconciliation logic is executed whenever the base is updated so\nthat newer files in the base are never shadowed by a copied up version\nin the upper directory. This matches RPM semantics when upgrading\npackages whose files may have been modified.\n\nFor ease of integration, this is exposed as a systemd template unit which\nany downstream distro/user can enable. The instance name is the mountpath\nin escaped systemd path notation (e.g.\n`ostree-state-overlay@usr-local.service`).\n\nSee discussions in https://github.com/ostreedev/ostree/issues/3113 for\nmore details.","shortMessageHtmlLink":"Add concept of state overlays"}},{"before":"15d749606b65c73d2a4ba3371e8c243dc69067b5","after":"30ec1867ddff243343e4f8513f412b4e7f2adc25","ref":"refs/heads/pr/state-overlays","pushedAt":"2024-01-09T21:56:24.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"Add concept of state overlays\n\nIn the OSTree model, executables go in `/usr`, state in `/var` and\nconfiguration in `/etc`. Software that lives in `/opt` however messes\nthis up because it often mixes code *and* state, making it harder to\nmanage.\n\nMore generally, it's sometimes useful to have the OSTree commit contain\ncode under a certain path, but still allow that path to be writable by\nsoftware and the sysadmin at runtime (`/usr/local` is another instance).\n\nAdd the concept of state overlays. A state overlay is an overlayfs\nmount whose upper directory, which contains unmanaged state, is carried\nforward on top of a lower directory, containing OSTree-managed files.\n\nIn the example of `/usr/local`, OSTree commits can ship content there,\nall while allowing users to e.g. add scripts in `/usr/local/bin` when\nbooted into that commit.\n\nSome reconciliation logic is executed whenever the base is updated so\nthat newer files in the base are never shadowed by a copied up version\nin the upper directory. This matches RPM semantics when upgrading\npackages whose files may have been modified.\n\nFor ease of integration, this is exposed as a systemd template unit which\nany downstream distro/user can enable. The instance name is the mountpath\nin escaped systemd path notation (e.g.\n`ostree-state-overlay@usr-local.service`).\n\nSee discussions in https://github.com/ostreedev/ostree/issues/3113 for\nmore details.","shortMessageHtmlLink":"Add concept of state overlays"}},{"before":"3a8dc91c9d413ccfbfe2cccbba3dfa4ae3ef17b1","after":"15d749606b65c73d2a4ba3371e8c243dc69067b5","ref":"refs/heads/pr/state-overlays","pushedAt":"2024-01-09T21:50:59.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"Add concept of state overlays\n\nIn the OSTree model, executables go in `/usr`, state in `/var` and\nconfiguration in `/etc`. Software that lives in `/opt` however messes\nthis up because it often mixes code *and* state, making it harder to\nmanage.\n\nMore generally, it's sometimes useful to have the OSTree commit contain\ncode under a certain path, but still allow that path to be writable by\nsoftware and the sysadmin at runtime (`/usr/local` is another instance).\n\nAdd the concept of state overlays. A state overlay is an overlayfs\nmount whose upper directory, which contains unmanaged state, is carried\nforward on top of a lower directory, containing OSTree-managed files.\n\nIn the example of `/usr/local`, OSTree commits can ship content there,\nall while allowing users to e.g. add scripts in `/usr/local/bin` when\nbooted into that commit.\n\nSome reconciliation logic is executed whenever the base is updated so\nthat newer files in the base are never shadowed by a copied up version\nin the upper directory. This matches RPM semantics when upgrading\npackages whose files may have been modified.\n\nFor ease of integration, this is exposed as a systemd template unit which\nany downstream distro/user can enable. The instance name is the mountpath\nin escaped systemd path notation (e.g.\n`ostree-state-overlay@usr-local.service`).\n\nSee discussions in https://github.com/ostreedev/ostree/issues/3113 for\nmore details.","shortMessageHtmlLink":"Add concept of state overlays"}},{"before":"39ff27f803d5a511ff5e615e8cc97cad3e74d576","after":"cc5747a60561db0b6c8a534d1556605599192a03","ref":"refs/heads/pr/autoprune-aarch64-dtb","pushedAt":"2024-01-04T18:07:24.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"lib/deploy: Add safety margin in early prune space check\n\nThere are a few things the estimator doesn't account for, e.g. writing\nthe new BLS entries. Rather than trying to perfect it (since I think we\nshould change approach entirely -- see previous commit message), just\nadd a 1M margin to the space check.","shortMessageHtmlLink":"lib/deploy: Add safety margin in early prune space check"}},{"before":null,"after":"39ff27f803d5a511ff5e615e8cc97cad3e74d576","ref":"refs/heads/pr/autoprune-aarch64-dtb","pushedAt":"2024-01-04T16:22:38.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"lib/deploy: Add 1M margin in early prune space check\n\nThere are a few things the estimator doesn't account for, e.g. writing\nthe new BLS entries. Rather than trying to perfect it (since I think we\nshould change approach entirely -- see previous commit message), just\nadd a 1M margin to the space check.","shortMessageHtmlLink":"lib/deploy: Add 1M margin in early prune space check"}},{"before":"fb5050d5bea74688dacc0f3e963c84913c5efacb","after":"3a8dc91c9d413ccfbfe2cccbba3dfa4ae3ef17b1","ref":"refs/heads/pr/state-overlays","pushedAt":"2023-12-14T22:17:25.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"Add concept of state overlays\n\nIn the OSTree model, executables go in `/usr`, state in `/var` and\nconfiguration in `/etc`. Software that lives in `/opt` however messes\nthis up because it often mixes code *and* state, making it harder to\nmanage.\n\nMore generally, it's sometimes useful to have the OSTree commit contain\ncode under a certain path, but still allow that path to be writable by\nsoftware and the sysadmin at runtime (`/usr/local` is another instance).\n\nAdd the concept of state overlays. A state overlay is an overlayfs\nmount whose upper directory, which contains unmanaged state, is carried\nforward on top of a lower directory, containing OSTree-managed files.\n\nIn the example of `/usr/local`, OSTree commits can ship content there,\nall while allowing users to e.g. add scripts in `/usr/local/bin` when\nbooted into that commit.\n\nSome reconciliation logic is executed whenever the base is updated so\nthat newer files in the base are never shadowed by a copied up version\nin the upper directory. This matches RPM semantics when upgrading\npackages whose files may have been modified.\n\nFor ease of integration, this is exposed as a systemd template unit which\nany downstream distro/user can enable. The instance name is the mountpath\nin escaped systemd path notation (e.g.\n`ostree-state-overlay@usr-local.service`).\n\nSee discussions in https://github.com/ostreedev/ostree/issues/3113 for\nmore details.","shortMessageHtmlLink":"Add concept of state overlays"}},{"before":"cb6e0e1aa0ff88045b78375a4b76c85917bc5e3a","after":"fb5050d5bea74688dacc0f3e963c84913c5efacb","ref":"refs/heads/pr/state-overlays","pushedAt":"2023-12-14T22:14:48.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"Add concept of state overlays\n\nIn the OSTree model, executables go in `/usr`, state in `/var` and\nconfiguration in `/etc`. Software that lives in `/opt` however messes\nthis up because it often mixes code *and* state, making it harder to\nmanage.\n\nMore generally, it's sometimes useful to have the OSTree commit contain\ncode under a certain path, but still allow that path to be writable by\nsoftware and the sysadmin at runtime (`/usr/local` is another instance).\n\nAdd the concept of state overlays. A state overlay is an overlayfs\nmount whose upper directory, which contains unmanaged state, is carried\nforward on top of a lower directory, containing OSTree-managed files.\n\nIn the example of `/usr/local`, OSTree commits can ship content there,\nall while allowing users to e.g. add scripts in `/usr/local/bin` when\nbooted into that commit.\n\nSome reconciliation logic is executed whenever the base is updated so\nthat newer files in the base are never shadowed by a copied up version\nin the upper directory. This matches RPM semantics when upgrading\npackages whose files may have been modified.\n\nFor ease of integration, this is exposed as a systemd template unit which\nany downstream distro/user can enable. The instance name is the mountpath\nin escaped systemd path notation (e.g.\n`ostree-state-overlay@usr-local.service`).\n\nSee discussions in https://github.com/ostreedev/ostree/issues/3113 for\nmore details.","shortMessageHtmlLink":"Add concept of state overlays"}},{"before":"e389c214f113d21dc982cabe8ef345cb60a76f18","after":"cb6e0e1aa0ff88045b78375a4b76c85917bc5e3a","ref":"refs/heads/pr/state-overlays","pushedAt":"2023-12-14T21:58:35.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"Add concept of state overlays\n\nIn the OSTree model, executables go in `/usr`, state in `/var` and\nconfiguration in `/etc`. Software that lives in `/opt` however messes\nthis up because it often mixes code *and* state, making it harder to\nmanage.\n\nMore generally, it's sometimes useful to have the OSTree commit contain\ncode under a certain path, but still allow that path to be writable by\nsoftware and the sysadmin at runtime (`/usr/local` is another instance).\n\nAdd the concept of state overlays. A state overlay is an overlayfs\nmount whose upper directory, which contains unmanaged state, is carried\nforward on top of a lower directory, containing OSTree-managed files.\n\nIn the example of `/usr/local`, OSTree commits can ship content there,\nall while allowing users to e.g. add scripts in `/usr/local/bin` when\nbooted into that commit.\n\nSome reconciliation logic is executed whenever the base is updated so\nthat newer files in the base are never shadowed by a copied up version\nin the upper directory. This matches RPM semantics when upgrading\npackages whose files may have been modified.\n\nFor ease of integration, this is exposed as a systemd template unit which\nany downstream distro/user can enable. The instance name is the mountpath\nin escaped systemd path notation (e.g.\n`ostree-state-overlay@usr-local.service`).\n\nSee discussions in https://github.com/ostreedev/ostree/issues/3113 for\nmore details.","shortMessageHtmlLink":"Add concept of state overlays"}},{"before":null,"after":"e389c214f113d21dc982cabe8ef345cb60a76f18","ref":"refs/heads/pr/state-overlays","pushedAt":"2023-12-14T21:49:14.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"Add concept of state overlays\n\nIn the OSTree model, executables go in `/usr`, state in `/var` and\nconfiguration in `/etc`. Software that lives in `/opt` however messes\nthis up because it often mixes code *and* state, making it harder to\nmanage.\n\nMore generally, it's sometimes useful to have the OSTree commit contain\ncode under a certain path, but still allow that path to be writable by\nsoftware and the sysadmin at runtime (`/usr/local` is another instance).\n\nAdd the concept of state overlays. A state overlay is an overlayfs\nmount whose upper directory, which contains unmanaged state, is carried\nforward on top of a lower directory, containing OSTree-managed files.\n\nIn the example of `/usr/local`, OSTree commits can ship content there,\nall while allowing users to e.g. add scripts in `/usr/local/bin` when\nbooted into that commit.\n\nSome reconciliation logic is executed whenever the base is updated so\nthat newer files in the base are never shadowed by a copied up version\nin the upper directory. This matches RPM semantics when upgrading\npackages whose files may have been modified.\n\nFor ease of integration, this is exposed as a systemd template unit which\nany downstream distro/user can enable. The instance name is the mountpath\nin escaped systemd path notation (e.g.\n`ostree-state-overlay@usr-local.service`).\n\nSee discussions in https://github.com/ostreedev/ostree/issues/3113 for\nmore details.","shortMessageHtmlLink":"Add concept of state overlays"}},{"before":"8002983d45cad31258b8dbc75435fd5d74d6ca07","after":null,"ref":"refs/heads/pr/abort-concurrent","pushedAt":"2023-11-21T22:18:18.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"}},{"before":null,"after":"8002983d45cad31258b8dbc75435fd5d74d6ca07","ref":"refs/heads/pr/abort-concurrent","pushedAt":"2023-11-21T20:33:30.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"ci: cancel previous build on PR update\n\nThis is an easy way to save CI resources; when a PR is updated, abort\nany previous build for that PR to focus on testing the latest push.","shortMessageHtmlLink":"ci: cancel previous build on PR update"}},{"before":"2cb49115ff816ac5bc95d3fbfdace4f1bae6f9d2","after":"bdac515ab5f3941fccbfb9580e2d9978863eb48d","ref":"refs/heads/pr/log-selinux-refresh","pushedAt":"2023-10-19T15:41:12.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"lib/deploy: Log SELinux policy refresh\n\nI have a suspicion that the `semodule -N --refresh` we do here is\ninvolved in https://github.com/coreos/fedora-coreos-tracker/issues/1597.\nLet's log when we execute it and include its time.\n\nWhile we're here, also log the time it takes to `syncfs()` and the\nfsfreeze/thaw cycling. It's logged in a structured journal entry, but\nthat's less accessible than just having it in the journal message field.","shortMessageHtmlLink":"lib/deploy: Log SELinux policy refresh"}},{"before":null,"after":"2cb49115ff816ac5bc95d3fbfdace4f1bae6f9d2","ref":"refs/heads/pr/log-selinux-refresh","pushedAt":"2023-10-19T15:39:40.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"lib/deploy: Log SELinux policy refresh\n\nI have a suspicion that the `semodule -N --refresh` we do here is\ninvolved in https://github.com/coreos/fedora-coreos-tracker/issues/1597.\nLet's log when we execute it and include its time.\n\nWhile we're here, also log the time it takes to `syncfs()` and the\nfsfreeze/thaw cycling. It's logged in a structured journal entry, but\nthat's less accessible than just having it in the journal message field.","shortMessageHtmlLink":"lib/deploy: Log SELinux policy refresh"}},{"before":"097fb7a8df38c7534656ff9553066c00c9de809a","after":"b8ce61ba7bb070ad8fddcead6cab3363bee07f48","ref":"refs/heads/pr/revert-virtiofs-hack","pushedAt":"2023-09-27T23:36:09.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"cgwalters","name":"Colin Walters","path":"/cgwalters","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/244096?s=80&v=4"},"commit":{"message":"Revert \"ci: Run cosa unprivileged\"\n\nThis reverts commit 2fe88f80fae83e206f811003a072c73ceebcea59.\n\nThis shouldn't be necessary now with the workaround built in cosa:\n\nhttps://github.com/coreos/coreos-assembler/pull/3625","shortMessageHtmlLink":"Revert \"ci: Run cosa unprivileged\""}},{"before":"9a66b6d9c4df4f8feabcc910a8b96ee9e36cd15c","after":"097fb7a8df38c7534656ff9553066c00c9de809a","ref":"refs/heads/pr/revert-virtiofs-hack","pushedAt":"2023-09-20T13:24:18.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"cgwalters","name":"Colin Walters","path":"/cgwalters","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/244096?s=80&v=4"},"commit":{"message":"Revert \"ci: Run cosa unprivileged\"\n\nThis reverts commit 2fe88f80fae83e206f811003a072c73ceebcea59.\n\nThis shouldn't be necessary now with the workaround built in cosa:\n\nhttps://github.com/coreos/coreos-assembler/pull/3625","shortMessageHtmlLink":"Revert \"ci: Run cosa unprivileged\""}},{"before":null,"after":"9a66b6d9c4df4f8feabcc910a8b96ee9e36cd15c","ref":"refs/heads/pr/revert-virtiofs-hack","pushedAt":"2023-09-19T18:52:45.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"Revert \"ci: Run cosa unprivileged\"\n\nThis reverts commit 2fe88f80fae83e206f811003a072c73ceebcea59.\n\nThis shouldn't be necessary now with the workaround built in cosa:\n\nhttps://github.com/coreos/coreos-assembler/pull/3625","shortMessageHtmlLink":"Revert \"ci: Run cosa unprivileged\""}},{"before":"2fe88f80fae83e206f811003a072c73ceebcea59","after":"cd116a1e63aa9c7114b3ca5ee804fdafa57360af","ref":"refs/heads/pr/static-delta-fetch-no-scan","pushedAt":"2023-09-11T02:18:31.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"lib/pull: Drop static delta superblocks references\n\nWe don't need them long-lived anymore. They were just used for reporting\nat this point, but we can use the new `static_delta_targets` hash table\nsize for that now.","shortMessageHtmlLink":"lib/pull: Drop static delta superblocks references"}},{"before":"f94cc9ca305658e4256fbe499893ef8c43b30750","after":"2fe88f80fae83e206f811003a072c73ceebcea59","ref":"refs/heads/pr/static-delta-fetch-no-scan","pushedAt":"2023-09-09T01:09:11.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"ci: Run cosa unprivileged\n\nAs a workaround for a virtiofs bug:\nhttps://gitlab.com/virtio-fs/virtiofsd/-/merge_requests/197\n\nxref coreos/coreos-assembler#3428 (comment)\n\nJust like in https://github.com/coreos/rpm-ostree/pull/4585.","shortMessageHtmlLink":"ci: Run cosa unprivileged"}},{"before":"fc5aef6fe6332fa7ddc057064afcabc3d6d680f4","after":"f94cc9ca305658e4256fbe499893ef8c43b30750","ref":"refs/heads/pr/static-delta-fetch-no-scan","pushedAt":"2023-09-09T00:40:50.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"ci: Run cosa unprivileged\n\nAs a workaround for a virtiofs bug:\nhttps://gitlab.com/virtio-fs/virtiofsd/-/merge_requests/197\n\nxref coreos/coreos-assembler#3428 (comment)\n\nJust like in https://github.com/coreos/rpm-ostree/pull/4585.","shortMessageHtmlLink":"ci: Run cosa unprivileged"}},{"before":"c2c9521806929b587a6ebfd1470bfa8607cfd6d9","after":"fc5aef6fe6332fa7ddc057064afcabc3d6d680f4","ref":"refs/heads/pr/static-delta-fetch-no-scan","pushedAt":"2023-09-08T21:49:36.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"lib/pull: Don't scan commit objects we fetch via deltas\n\nWhen we're fetching a commit via static delta, we already take care of\nfetching the full commit, so there's no need to also scan it using the\nregular object workflow.\n\nCloses: #2053","shortMessageHtmlLink":"lib/pull: Don't scan commit objects we fetch via deltas"}},{"before":"46625e2405dcef85873a98369c5f5687a18ea117","after":"c2c9521806929b587a6ebfd1470bfa8607cfd6d9","ref":"refs/heads/pr/static-delta-fetch-no-scan","pushedAt":"2023-09-08T21:00:30.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"lib/pull: Don't scan commit objects we fetch via deltas\n\nWhen we're fetching a commit via static delta, we already take care of\nfetching the full commit, so there's no need to also scan it using the\nregular object workflow.\n\nCloses: #2053","shortMessageHtmlLink":"lib/pull: Don't scan commit objects we fetch via deltas"}},{"before":"bc8c63c3f47ebe5300986bee244b1ffd53c3df5e","after":"46625e2405dcef85873a98369c5f5687a18ea117","ref":"refs/heads/pr/static-delta-fetch-no-scan","pushedAt":"2023-09-08T21:00:10.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"lib/pull: Don't scan commit objects we fetch via deltas\n\nWhen we're fetching a commit via static delta, we already take care of\nfetching the full commit, so there's no need to also scan it using the\nregular object workflow.\n\nCloses: #2053","shortMessageHtmlLink":"lib/pull: Don't scan commit objects we fetch via deltas"}},{"before":"6b7bff81135db85ac2f087d672568b8789fb8313","after":"bc8c63c3f47ebe5300986bee244b1ffd53c3df5e","ref":"refs/heads/pr/static-delta-fetch-no-scan","pushedAt":"2023-09-08T20:57:37.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"lib/pull: Don't scan commit objects we fetch via deltas\n\nWhen we're fetching a commit via static delta, we already take care of\nfetching the full commit, so there's no need to also scan it using the\nregular object workflow.\n\nCloses: #2053","shortMessageHtmlLink":"lib/pull: Don't scan commit objects we fetch via deltas"}},{"before":"6737625a3a2407f866c23005205c87ae5bcdd9ee","after":"6b7bff81135db85ac2f087d672568b8789fb8313","ref":"refs/heads/pr/static-delta-fetch-no-scan","pushedAt":"2023-09-08T20:54:47.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"lib/pull: Don't scan commit objects we fetch via deltas\n\nWhen we're fetching a commit via static delta, we already take care of\nfetching the full commit, so there's no need to also scan it using the\nregular object workflow.\n\nCloses: #2053","shortMessageHtmlLink":"lib/pull: Don't scan commit objects we fetch via deltas"}},{"before":"2987762d124ea1ac2ff81fc2bb37085e32822a69","after":"193ef29f3f0886e3d59e6580e394f8817f2f123e","ref":"refs/heads/pr/autoprune-tweaks","pushedAt":"2023-05-29T16:17:14.520Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jlebon","name":"Jonathan Lebon","path":"/jlebon","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/11934099?s=80&v=4"},"commit":{"message":"lib/deploy: Use `fallocate` for early prune space check\n\nThe `f_bfree` member of the `statvfs` struct is documented as the\n\"number of free blocks\". However, different filesystems have different\ninterpretations of this. E.g. on XFS, this is truly the number of blocks\nfree for allocating data. On ext4 however, it includes blocks that\nare actually reserved by the filesystem and cannot be used for file\ndata. (Note this is separate from the distinction between `f_bfree` and\n`f_bavail` which isn't relevant to us here since we're privileged.)\n\nIf a kernel and initrd is sized just right so that it's still within the\n`f_bfree` limit but above what we can actually allocate, the early prune\ncode won't kick in since it'll think that there is enough space. So we\nend up hitting `ENOSPC` when we actually copy the files in.\n\nRework the early prune code to instead use `fallocate` which guarantees\nus that a file of a certain size can fit on the filesystem. `fallocate`\nrequires filesystem support, but all the filesystems we care about for\nthe bootfs support it (including even FAT).\n\n(There's technically a TOCTOU race here that existed also with the\n`statvfs` code where free space could change between when we check\nand when we copy. Ideally we'd be able to pass down that fd to the\ncopying bits, but anyway in practice the bootfs is pretty much owned by\nlibostree and one doesn't expect concurrent writes during a finalization\noperation.)","shortMessageHtmlLink":"lib/deploy: Use <code>fallocate</code> for early prune space check"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEG_LDegA","startCursor":null,"endCursor":null}},"title":"Activity · jlebon/ostree"}