Thicket data repository for the EEG
anil.recoil.org
1{
2 "id": "https://ryan.freumh.org/2024-08-05.html",
3 "title": "5 Aug 2024",
4 "link": "https://ryan.freumh.org/2024-08-05.html",
5 "updated": "2024-08-05T00:00:00",
6 "published": "2024-08-05T00:00:00",
7 "summary": "<div>\n <span> Previous: <a href=\"2024-07-08.html\"> 8 Jul 2024</a> </span>\n <span> Next: <a href=\"2024-08-12.html\">12 Aug 2024</a> </span>\n </div>\n \n \n\n <ol>\n<li><p><span>Mon</span></p>\n<ol>\n<li><p><span>Package Management</span></p>\n<p><span>Test with `opam install –dry-run`</span></p>\n<ul>\n<li><p><span>you can emulate it by encoding their\ndependencies and then solving in that order</span></p></li>\n<li><p><span>with a real client, you would just invoke cargo\nonce</span></p></li>\n<li><p><span>cargo depexts</span></p></li>\n<li><p><span>0install</span></p></li>\n<li><p><span>memo bug</span></p></li>\n<li><p><span>getting latest ones</span></p></li>\n<li><p><span>solve for cargo</span></p>\n<ul>\n<li>equivalent to cargo install</li>\n</ul></li>\n<li><p><span>what if we did this for nix flakes? <a href=\"https://github.com/snowfallorg/thaw\">https://github.com/snowfallorg/thaw</a></span></p></li>\n</ul></li>\n<li><p><span>Eon</span></p>\n<p><span>So, interesting Eon problem: Patrick’s server\nfailed to connect to mine, presumably after a restart of both, as it was\nquerying itself for `freumh.org`:</span></p>\n<pre><code>Aug 05 10:37:31 sirref capd[1761828]: capd: [INFO] Connecting to tcp:freumh.org:7000...\nAug 05 10:37:31 sirref capd[1761828]: +Failed to connnect to primary: Unknown host "freumh.org"\nAug 05 10:37:31 sirref capd[1761828]: +Retrying in 60.000000\n</code></pre>\n<p><span>I think I’ve just reinvented glue\nrecords.</span></p></li>\n</ol></li>\n<li><p><span>Tue</span></p>\n<ol>\n<li><p><span><span>X</span> restructure\nsecond year report</span></p></li>\n<li><p><span><span>~</span> submit ASPLOS\npackage management paper</span></p></li>\n</ol></li>\n<li><p><span>Wed</span></p>\n<ol>\n<li><p><span>got opam-0install working with constraint\nsolving</span></p>\n<p><span>trying to see if it working for crossterm ?\n0.11.1</span></p></li>\n<li><p><span><span>~</span> try and add\nsome external dependancies on cargo / opam packages</span></p>\n<p><span><a href=\"https://doc.rust-lang.org/cargo/reference/registry-index.html#index-format\">https://doc.rust-lang.org/cargo/reference/registry-index.html#index-format</a>\noptional</span></p>\n<p><span>features calculus</span></p>\n<p><span>debian format apk format</span></p>\n<p><span>spin depends on</span></p>\n<pre><code>C:Q1FvuE1cGeU0tdaWgpAvu9PylxewU=\nP:aconf-mod-network\nV:0.8.1-r2\nA:x86_64\nS:3953\nI:36864\nT:Alpine Configurator\nU:https://gitlab.alpinelinux.org/kunkku/aconf/\nL:BSD-2-Clause\no:aconf\nm:Kaarle Ritvanen <kunkku@alpinelinux.org>\nt:1673055727\nc:cdd3ce01ff79a74ae2e87c50ecdc5bbb358d4df6\nD:aconf network\n</code></pre>\n<pre><code>root@a2e42152d552:/# opam install nano\n[WARNING] Running as root is not recommended\nThe following actions will be performed:\n - install libc6 2.36-9+deb12u7 [required by nano]\n - install libtinfo6 6.4-4 [required by nano]\n - install libncursesw6 6.4-4 [required by nano]\n - install nano 7.2-1+deb12u1\n===== 4 to install =====\nDo you want to continue? [Y/n] y\n\n<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>\n-> retrieved libncursesw6.6.4-4 (http://ftp.debian.org/debian/pool/main/n/ncurses/libncursesw6_6.4-4_amd64.deb)\n-> retrieved libtinfo6.6.4-4 (http://ftp.debian.org/debian/pool/main/n/ncurses/libtinfo6_6.4-4_amd64.deb)\n-> retrieved libc6.2.36-9+deb12u7 (http://ftp.debian.org/debian/pool/main/g/glibc/libc6_2.36-9+deb12u7_amd64.deb)\n-> retrieved nano.7.2-1+deb12u1 (http://ftp.debian.org/debian/pool/main/n/nano/nano_7.2-1+deb12u1_amd64.deb)\n-> installed libc6.2.36-9+deb12u7\n-> installed libtinfo6.6.4-4\n-> installed libncursesw6.6.4-4\n-> installed nano.7.2-1+deb12u1\nDone.\n# Run eval $(opam env) to update the current shell environment\n</code></pre>\n<p><span>I’ve got a repository at <a href=\"https://github.com/RyanGibb/opam-deb-repository\">https://github.com/RyanGibb/opam-deb-repository</a>\nthat seems to work! The only issue I’m having is a cyclic dependency\nbetween <a href=\"https://packages.debian.org/sid/libgcc-s1\">https://packages.debian.org/sid/libgcc-s1</a>\nand <a href=\"https://packages.debian.org/sid/libc6\">https://packages.debian.org/sid/libc6</a>…\nMaybe the debian dependency resolution just prunes cyclic dependencies?\nI’ve got around it in testing by just removing the libgcc-s1 dependancy\nfrom libc6.</span></p>\n<pre><code>Package: libc6\nSource: glibc\nVersion: 2.36-9+deb12u7\nInstalled-Size: 12986\nMaintainer: GNU Libc Maintainers <debian-glibc@lists.debian.org>\nArchitecture: amd64\nReplaces: libc6-amd64\nDepends: libgcc-s1\nRecommends: libidn2-0 (>= 2.0.5~)\nSuggests: glibc-doc, debconf | debconf-2.0, libc-l10n, locales, libnss-nis, libnss-nisplus\nBreaks: aide (<< 0.17.3-4+b3), busybox (<< 1.30.1-6), chrony (<< 4.2-3~), fakechroot (<< 2.19-3.5), firefox (<< 91~), firefox-esr (<< 91~), gnumach-image-1.8-486 (<< 2:1.8+git20210923~), gnumach-image-1.8-486-dbg (<< 2:1.8+git20210923~), gnumach-image-1.8-xen-486 (<< 2:1.8+git20210923~), gnumach-image-1.8-xen-486-dbg (<< 2:1.8+git20210923~), hurd (<< 1:0.9.git20220301-2), ioquake3 (<< 1.36+u20200211.f2c61c1~dfsg-2~), iraf-fitsutil (<< 2018.07.06-4), libgegl-0.4-0 (<< 0.4.18), libtirpc1 (<< 0.2.3), locales (<< 2.36), locales-all (<< 2.36), macs (<< 2.2.7.1-3~), nocache (<< 1.1-1~), nscd (<< 2.36), openarena (<< 0.8.8+dfsg-4~), openssh-server (<< 1:8.1p1-5), python3-iptables (<< 1.0.0-2), r-cran-later (<< 0.7.5+dfsg-2), tinydns (<< 1:1.05-14), valgrind (<< 1:3.19.0-1~), wcc (<< 0.0.2+dfsg-3)\nDescription: GNU C Library: Shared libraries\nMulti-Arch: same\nHomepage: https://www.gnu.org/software/libc/libc.html\nDescription-md5: fc3001b0b90a1c8e6690b283a619d57f\nTag: role::shared-lib\nSection: libs\nPriority: optional\nFilename: pool/main/g/glibc/libc6_2.36-9+deb12u7_amd64.deb\nSize: 2757936\nMD5sum: a9480b37954b1c6327b09526cc1974c3\nSHA256: eba944bd99c2f5142baf573e6294a70f00758083bc3c2dca4c9e445943a3f8e6\n</code></pre>\n<pre><code>Package: libgcc-s1\nSource: gcc-12\nVersion: 12.2.0-14\nInstalled-Size: 140\nMaintainer: Debian GCC Maintainers <debian-gcc@lists.debian.org>\nArchitecture: amd64\nReplaces: libgcc1 (<< 1:10)\nProvides: libgcc1 (= 1:12.2.0-14)\nDepends: gcc-12-base (= 12.2.0-14), libc6 (>= 2.35)\nDescription: GCC support library\nMulti-Arch: same\nHomepage: http://gcc.gnu.org/\nDescription-md5: bbd60d723e97d8e06c04228ee4c76f10\nImportant: yes\nProtected: yes\nTag: role::shared-lib\nSection: libs\nPriority: optional\nFilename: pool/main/g/gcc-12/libgcc-s1_12.2.0-14_amd64.deb\nSize: 49892\nMD5sum: f00018bcad3c773b1fbb378bbdd6b9d1\nSHA256: f3d1d48c0599aea85b7f2077a01d285badc42998c1a1e7473935d5cf995c8141\n</code></pre>\n<p><span>okay, next, try and see if everything is\ninstallable</span></p>\n<p><span>I’m trying to solve all package versions, but some\njust seem to be flat out broken. E.g. <a href=\"https://crates.io/crates/am\">https://crates.io/crates/am</a>\ndepends on owo-colours <code>^4.0.0</code> and\ncolor-eyre <code>^0.6.3</code>, but colour-eyre <code>^0.6.3</code> depends on owo-colours <code>^3.2.0</code>. This bug looks to have been introduced\nby a bot <a href=\"https://github.com/ryanccn/am/pull/35\">https://github.com/ryanccn/am/pull/35</a></span></p></li>\n<li><p><span><span>~</span> transform\nopam-repository depext to depend on debian packages</span></p>\n<p><span>calculus:</span></p>\n<ul>\n<li>name</li>\n<li>version</li>\n<li>depends</li>\n<li>sdf</li>\n<li>mechanism? e.g. debian, alpine, cargo etc</li>\n<li>namespacing? urls? domains?</li>\n</ul>\n<p><span>protocol spec, core format, s\nexpressions</span></p></li>\n<li><p><span><span>~</span> check if\ncargo installs fail for uninstallable opam ones too</span></p></li>\n<li><p><span><span>~</span> cudf solve\nfor multiple versions</span></p></li>\n</ol></li>\n<li><p><span>Thu</span></p>\n<p><span>The name mangling is the mechanism used to link\nmultiple versions, and the solver algorithm will select multiple\nversions there’s an upper bound below an already selected higher\nversion:</span></p>\n<p><span><a href=\"https://github.com/rust-lang/cargo/blob/027b415b524ec213b3faac0ba7e999ac74926cdd/src/cargo/core/resolver/mod.rs#L19\">https://github.com/rust-lang/cargo/blob/027b415b524ec213b3faac0ba7e999ac74926cdd/src/cargo/core/resolver/mod.rs#L19</a></span></p>\n<pre><code>The algorithm employed here is fairly simple, we simply do a DFS, activating the “newest crate” (highest version) first and then going to the next option. The heuristics we employ are:\n\nNever try to activate a crate version which is incompatible. This means we only try crates which will actually satisfy a dependency and we won’t ever try to activate a crate that’s semver compatible with something else activated (as we’re only allowed to have one) nor try to activate a crate that has the same links attribute as something else activated.\n\nAlways try to activate the highest version crate first. The default dependency in Cargo (e.g., when you write foo = "0.1.2") is semver-compatible, so selecting the highest version possible will allow us to hopefully satisfy as many dependencies at once.\n\nBeyond that, what’s implemented below is just a naive backtracking version which should in theory try all possible combinations of dependencies and versions to see if one works. The first resolution that works causes everything to bail out immediately and return success, and only if nothing works do we actually return an error up the stack.\n</code></pre></li>\n</ol>",
8 "content": "<div>\n <span> Previous: <a href=\"2024-07-08.html\"> 8 Jul 2024</a> </span>\n <span> Next: <a href=\"2024-08-12.html\">12 Aug 2024</a> </span>\n </div>\n \n \n\n <ol>\n<li><p><span>Mon</span></p>\n<ol>\n<li><p><span>Package Management</span></p>\n<p><span>Test with `opam install –dry-run`</span></p>\n<ul>\n<li><p><span>you can emulate it by encoding their\ndependencies and then solving in that order</span></p></li>\n<li><p><span>with a real client, you would just invoke cargo\nonce</span></p></li>\n<li><p><span>cargo depexts</span></p></li>\n<li><p><span>0install</span></p></li>\n<li><p><span>memo bug</span></p></li>\n<li><p><span>getting latest ones</span></p></li>\n<li><p><span>solve for cargo</span></p>\n<ul>\n<li>equivalent to cargo install</li>\n</ul></li>\n<li><p><span>what if we did this for nix flakes? <a href=\"https://github.com/snowfallorg/thaw\">https://github.com/snowfallorg/thaw</a></span></p></li>\n</ul></li>\n<li><p><span>Eon</span></p>\n<p><span>So, interesting Eon problem: Patrick’s server\nfailed to connect to mine, presumably after a restart of both, as it was\nquerying itself for `freumh.org`:</span></p>\n<pre><code>Aug 05 10:37:31 sirref capd[1761828]: capd: [INFO] Connecting to tcp:freumh.org:7000...\nAug 05 10:37:31 sirref capd[1761828]: +Failed to connnect to primary: Unknown host "freumh.org"\nAug 05 10:37:31 sirref capd[1761828]: +Retrying in 60.000000\n</code></pre>\n<p><span>I think I’ve just reinvented glue\nrecords.</span></p></li>\n</ol></li>\n<li><p><span>Tue</span></p>\n<ol>\n<li><p><span><span>X</span> restructure\nsecond year report</span></p></li>\n<li><p><span><span>~</span> submit ASPLOS\npackage management paper</span></p></li>\n</ol></li>\n<li><p><span>Wed</span></p>\n<ol>\n<li><p><span>got opam-0install working with constraint\nsolving</span></p>\n<p><span>trying to see if it working for crossterm ?\n0.11.1</span></p></li>\n<li><p><span><span>~</span> try and add\nsome external dependancies on cargo / opam packages</span></p>\n<p><span><a href=\"https://doc.rust-lang.org/cargo/reference/registry-index.html#index-format\">https://doc.rust-lang.org/cargo/reference/registry-index.html#index-format</a>\noptional</span></p>\n<p><span>features calculus</span></p>\n<p><span>debian format apk format</span></p>\n<p><span>spin depends on</span></p>\n<pre><code>C:Q1FvuE1cGeU0tdaWgpAvu9PylxewU=\nP:aconf-mod-network\nV:0.8.1-r2\nA:x86_64\nS:3953\nI:36864\nT:Alpine Configurator\nU:https://gitlab.alpinelinux.org/kunkku/aconf/\nL:BSD-2-Clause\no:aconf\nm:Kaarle Ritvanen <kunkku@alpinelinux.org>\nt:1673055727\nc:cdd3ce01ff79a74ae2e87c50ecdc5bbb358d4df6\nD:aconf network\n</code></pre>\n<pre><code>root@a2e42152d552:/# opam install nano\n[WARNING] Running as root is not recommended\nThe following actions will be performed:\n - install libc6 2.36-9+deb12u7 [required by nano]\n - install libtinfo6 6.4-4 [required by nano]\n - install libncursesw6 6.4-4 [required by nano]\n - install nano 7.2-1+deb12u1\n===== 4 to install =====\nDo you want to continue? [Y/n] y\n\n<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>\n-> retrieved libncursesw6.6.4-4 (http://ftp.debian.org/debian/pool/main/n/ncurses/libncursesw6_6.4-4_amd64.deb)\n-> retrieved libtinfo6.6.4-4 (http://ftp.debian.org/debian/pool/main/n/ncurses/libtinfo6_6.4-4_amd64.deb)\n-> retrieved libc6.2.36-9+deb12u7 (http://ftp.debian.org/debian/pool/main/g/glibc/libc6_2.36-9+deb12u7_amd64.deb)\n-> retrieved nano.7.2-1+deb12u1 (http://ftp.debian.org/debian/pool/main/n/nano/nano_7.2-1+deb12u1_amd64.deb)\n-> installed libc6.2.36-9+deb12u7\n-> installed libtinfo6.6.4-4\n-> installed libncursesw6.6.4-4\n-> installed nano.7.2-1+deb12u1\nDone.\n# Run eval $(opam env) to update the current shell environment\n</code></pre>\n<p><span>I’ve got a repository at <a href=\"https://github.com/RyanGibb/opam-deb-repository\">https://github.com/RyanGibb/opam-deb-repository</a>\nthat seems to work! The only issue I’m having is a cyclic dependency\nbetween <a href=\"https://packages.debian.org/sid/libgcc-s1\">https://packages.debian.org/sid/libgcc-s1</a>\nand <a href=\"https://packages.debian.org/sid/libc6\">https://packages.debian.org/sid/libc6</a>…\nMaybe the debian dependency resolution just prunes cyclic dependencies?\nI’ve got around it in testing by just removing the libgcc-s1 dependancy\nfrom libc6.</span></p>\n<pre><code>Package: libc6\nSource: glibc\nVersion: 2.36-9+deb12u7\nInstalled-Size: 12986\nMaintainer: GNU Libc Maintainers <debian-glibc@lists.debian.org>\nArchitecture: amd64\nReplaces: libc6-amd64\nDepends: libgcc-s1\nRecommends: libidn2-0 (>= 2.0.5~)\nSuggests: glibc-doc, debconf | debconf-2.0, libc-l10n, locales, libnss-nis, libnss-nisplus\nBreaks: aide (<< 0.17.3-4+b3), busybox (<< 1.30.1-6), chrony (<< 4.2-3~), fakechroot (<< 2.19-3.5), firefox (<< 91~), firefox-esr (<< 91~), gnumach-image-1.8-486 (<< 2:1.8+git20210923~), gnumach-image-1.8-486-dbg (<< 2:1.8+git20210923~), gnumach-image-1.8-xen-486 (<< 2:1.8+git20210923~), gnumach-image-1.8-xen-486-dbg (<< 2:1.8+git20210923~), hurd (<< 1:0.9.git20220301-2), ioquake3 (<< 1.36+u20200211.f2c61c1~dfsg-2~), iraf-fitsutil (<< 2018.07.06-4), libgegl-0.4-0 (<< 0.4.18), libtirpc1 (<< 0.2.3), locales (<< 2.36), locales-all (<< 2.36), macs (<< 2.2.7.1-3~), nocache (<< 1.1-1~), nscd (<< 2.36), openarena (<< 0.8.8+dfsg-4~), openssh-server (<< 1:8.1p1-5), python3-iptables (<< 1.0.0-2), r-cran-later (<< 0.7.5+dfsg-2), tinydns (<< 1:1.05-14), valgrind (<< 1:3.19.0-1~), wcc (<< 0.0.2+dfsg-3)\nDescription: GNU C Library: Shared libraries\nMulti-Arch: same\nHomepage: https://www.gnu.org/software/libc/libc.html\nDescription-md5: fc3001b0b90a1c8e6690b283a619d57f\nTag: role::shared-lib\nSection: libs\nPriority: optional\nFilename: pool/main/g/glibc/libc6_2.36-9+deb12u7_amd64.deb\nSize: 2757936\nMD5sum: a9480b37954b1c6327b09526cc1974c3\nSHA256: eba944bd99c2f5142baf573e6294a70f00758083bc3c2dca4c9e445943a3f8e6\n</code></pre>\n<pre><code>Package: libgcc-s1\nSource: gcc-12\nVersion: 12.2.0-14\nInstalled-Size: 140\nMaintainer: Debian GCC Maintainers <debian-gcc@lists.debian.org>\nArchitecture: amd64\nReplaces: libgcc1 (<< 1:10)\nProvides: libgcc1 (= 1:12.2.0-14)\nDepends: gcc-12-base (= 12.2.0-14), libc6 (>= 2.35)\nDescription: GCC support library\nMulti-Arch: same\nHomepage: http://gcc.gnu.org/\nDescription-md5: bbd60d723e97d8e06c04228ee4c76f10\nImportant: yes\nProtected: yes\nTag: role::shared-lib\nSection: libs\nPriority: optional\nFilename: pool/main/g/gcc-12/libgcc-s1_12.2.0-14_amd64.deb\nSize: 49892\nMD5sum: f00018bcad3c773b1fbb378bbdd6b9d1\nSHA256: f3d1d48c0599aea85b7f2077a01d285badc42998c1a1e7473935d5cf995c8141\n</code></pre>\n<p><span>okay, next, try and see if everything is\ninstallable</span></p>\n<p><span>I’m trying to solve all package versions, but some\njust seem to be flat out broken. E.g. <a href=\"https://crates.io/crates/am\">https://crates.io/crates/am</a>\ndepends on owo-colours <code>^4.0.0</code> and\ncolor-eyre <code>^0.6.3</code>, but colour-eyre <code>^0.6.3</code> depends on owo-colours <code>^3.2.0</code>. This bug looks to have been introduced\nby a bot <a href=\"https://github.com/ryanccn/am/pull/35\">https://github.com/ryanccn/am/pull/35</a></span></p></li>\n<li><p><span><span>~</span> transform\nopam-repository depext to depend on debian packages</span></p>\n<p><span>calculus:</span></p>\n<ul>\n<li>name</li>\n<li>version</li>\n<li>depends</li>\n<li>sdf</li>\n<li>mechanism? e.g. debian, alpine, cargo etc</li>\n<li>namespacing? urls? domains?</li>\n</ul>\n<p><span>protocol spec, core format, s\nexpressions</span></p></li>\n<li><p><span><span>~</span> check if\ncargo installs fail for uninstallable opam ones too</span></p></li>\n<li><p><span><span>~</span> cudf solve\nfor multiple versions</span></p></li>\n</ol></li>\n<li><p><span>Thu</span></p>\n<p><span>The name mangling is the mechanism used to link\nmultiple versions, and the solver algorithm will select multiple\nversions there’s an upper bound below an already selected higher\nversion:</span></p>\n<p><span><a href=\"https://github.com/rust-lang/cargo/blob/027b415b524ec213b3faac0ba7e999ac74926cdd/src/cargo/core/resolver/mod.rs#L19\">https://github.com/rust-lang/cargo/blob/027b415b524ec213b3faac0ba7e999ac74926cdd/src/cargo/core/resolver/mod.rs#L19</a></span></p>\n<pre><code>The algorithm employed here is fairly simple, we simply do a DFS, activating the “newest crate” (highest version) first and then going to the next option. The heuristics we employ are:\n\nNever try to activate a crate version which is incompatible. This means we only try crates which will actually satisfy a dependency and we won’t ever try to activate a crate that’s semver compatible with something else activated (as we’re only allowed to have one) nor try to activate a crate that has the same links attribute as something else activated.\n\nAlways try to activate the highest version crate first. The default dependency in Cargo (e.g., when you write foo = "0.1.2") is semver-compatible, so selecting the highest version possible will allow us to hopefully satisfy as many dependencies at once.\n\nBeyond that, what’s implemented below is just a naive backtracking version which should in theory try all possible combinations of dependencies and versions to see if one works. The first resolution that works causes everything to bail out immediately and return success, and only if nothing works do we actually return an error up the stack.\n</code></pre></li>\n</ol>",
9 "content_type": "html",
10 "categories": [],
11 "source": "https://ryan.freumh.org/atom.xml"
12}