| === genii is now known as genii-core | ||
| schopin | ginggs: I remember you talking about the autopkgtests runners sometimes pulling all of -proposed because of unsatisfied dependencies. Any advice on how to solve that? (looking into the rails failure triggered by ruby-sqlite3, so dbungert might be interested as well) | 09:27 |
|---|---|---|
| ginggs | schopin: yes, i see in https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/r/rails/20220113_212339_c7613@/log.gz | 09:29 |
| ginggs | autopkgtest: WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from jammy-proposed | 09:29 |
| ginggs | if you add all the packages that are needed as additional triggers, then it won't retry with all-proposed | 09:31 |
| ginggs | i'm getting 504 Gateway Time-out from autopkgtest.ubuntu.com/request.cgi - is it working for anyone else? | 09:33 |
| schopin | Time-out as well here. | 09:36 |
| seb128 | are others also getting gateway timeout errors using https://autopkgtest.ubuntu.com/request.cgi ? | 09:40 |
| ginggs | seb128: yes | 09:43 |
| seb128 | ginggs, thx | 09:44 |
| seb128 | juliank, ^ is that something for you or IS? | 09:44 |
| juliank | seb128: hooray, I guess I can have a quick look, but I'm out today | 09:46 |
| seb128 | juliank, ah, thanks, and sorry for bothering you on a vac day! | 09:46 |
| juliank | restarting rabbitmq | 09:48 |
| juliank | should write a guide for that :D | 09:49 |
| juliank | seb128: ginggs we're back | 09:51 |
| ginggs | juliank: <3 | 09:51 |
| seb128 | juliank, thanks! and instructions that others can restart it when you are not around would be nice | 09:51 |
| * juliank should write the weekly restart rabbitmq cronjob/systemd timer | 09:51 | |
| juliank | prod-proposed-migration@wendigo:~$ juju ssh rabbitmq-server/0 | 09:52 |
| juliank | ubuntu@juju-4d1272-prod-proposed-migration-8:~$ sudo service rabbitmq-server restart | 09:52 |
| juliank | that's all there is too it | 09:53 |
| juliank | anyone of vor_lon,ap_w,st_graber,sil_2100,x_nox, and me can do that (_ to avoid highlight) | 09:54 |
| juliank | to figure out whether it's amqp, submit a request with a false version, if it's rejected, and the one with the right version hangs, restart amqp | 09:54 |
| * juliank needs to copy it to the docs on monday | 09:55 | |
| seb128 | juliank, thanks and enjoy the long weekend! | 09:56 |
| ricotz | ginggs, hi :), please let me know when you start handling "level 4" of python3.10 transition, I want to upload a new libreoffice, so a no-change rebuild can be avoided | 13:08 |
| RikMills | schopin: sshfs-fuse is now sync'd | 14:09 |
| ginggs | ricotz: libreoffice doesn't build on i386 and riscv64, so I think you can go ahead and upload as soon as libpq-dev is published on arm64 and armhf. should be in a few minutes | 14:12 |
| ricotz | ginggs, great, I assume this is not urgent? I want to wait for autopkgtests runs for this new build to finish first | 14:13 |
| ricotz | (meaning, the python3.10 transition won't be finished before next week) | 14:15 |
| ginggs | ricotz: i'll probably carry on with rebuilds over the weekend, but i've noted to skip libreoffice | 14:20 |
| ricotz | ginggs, ack, thanks | 14:21 |
| === genii-core is now known as genii | ||
| blackboxsw | Heya folks! Filesystem Hierarchy Standard type question: I have a static JSON schema file that we package in cloud-init which defines the behavior of user-data validation and warnings within. I **could** package it and deliver it in 1. /etc/cloud/ with other cloud-init configuration data, or 2. /var/lib/cloud with other product metadata, or 3. local to the schema modules in /usr/lib/python3/dist-utils/cloudinit/config. | 19:42 |
| blackboxsw | per 1. /etc. It's not a config file we expect end-users/people to alter. It's just product "meta-data" | 19:43 |
| blackboxsw | per 3. /usr/lib/python3/dist-packages Are there any patterns of library static configuration files being delivered inder /usr/lib? Is this a no-no? | 19:44 |
| blackboxsw | It feels like "3" is a no-go and I wanted to speed check that sentiment more broadly, and that option 2. /var/lib/cloud" is probably the most-desired packaging path to deliver static configuration files and meta-data for a given project. | 19:47 |
| dbungert | blackboxsw: there is no reason whatsoever end users would modify the schema, right? That would seem to disqualify #1 or #2 | 19:56 |
| dbungert | when you look at things like https://importlib-resources.readthedocs.io/en/latest/using.html I believe there is suitable precedent for shipping that under dist-packages | 19:57 |
| blackboxsw | dbungert: Anyone mangling/extending this schema would be folks creating their or very customized downstream of cloud-init with private plugin modules that aren't intended for upstream. | 19:57 |
| dbungert | May I get assistance with some retests? retry-autopkgtest-regressions|grep 'trigger=sqlite3' | 20:08 |
| bdmurray | I will assist | 20:16 |
| dbungert | bdmurray: thanks! | 20:24 |
| blackboxsw | dbungert: thanks. the only thing I thought about /var/lib/cloud was that we'd be persisting data across boot "/var/lib | 20:55 |
| blackboxsw | State information. Persistent data modified by programs as they run (e.g., databases, packaging system metadata, etc.)" per https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard | 20:55 |
| blackboxsw | dbungert: but the more I read through FHS again to refresh, it feels like this static schema doc might need to live in /usr/share/doc per https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html | 20:55 |
| blackboxsw | the schema file is documentaion for how cloud-init will validate user-data, so "maybe" it meets the goal there for "docMiscellaneous documentation (optional)" | 20:57 |
| dbungert | right, I'm on the fence about that. How likely do you think people would read that? | 20:57 |
| sarnold | I think I've heard docker(?) images of ubuntu configure dpkg with patch-exclude options to drop all /usr/share/doc, or something similar | 20:57 |
| blackboxsw | FWIW we already also include a mess of user-data #cloud-config schema examples in /usr/share/doc/cloud-init/examples | 20:58 |
| sarnold | err, path-exclude of course | 20:58 |
| blackboxsw | dbungert: I'm not hoping people will read it specifically, but there will be external consumers or that content cloud-init devel schema --annotate command will source that file. We also aim to publish that content to external reference libraries like schemastore.org and eventually integrate with simple offsite schema validation services to allow clouds to preflight validate user-data before allowing people to launch | 21:00 |
| blackboxsw | instances | 21:00 |
| blackboxsw | that said all of the schema definitions are sourced anyway during readthedocs builds @ module documentation "Config schema: like thishttps://cloudinit.readthedocs.io/en/latest/topics/modules.html#apt-configure | 21:02 |
| blackboxsw | https://cloudinit.readthedocs.io/en/latest/topics/modules.html#apt-configure | 21:02 |
| blackboxsw | sarnold: ooh good point. | 21:03 |
| blackboxsw | sarnold: looks docker like a thing +1 thanks for the warning there https://github.com/tianon/docker-brew-debian/issues/48 | 21:04 |
| ubottu | Issue 48 in tianon/docker-brew-debian "create 'slim' variants without bits like /usr/share/locale and /usr/share/doc" [Closed] | 21:04 |
| blackboxsw | or at least the general motivation to make docker images smaller etc. | 21:06 |
| blackboxsw | ok, well /usr/lib/python3/dist-packages/cloudinit/ it is. python3-jsonschema/python3-nftables/python3-wadllib all show the practice of delivering static schema files though /usr/lib/python3 dirs. thanks for the input! | 21:26 |
| blackboxsw | since those schemas are needed for the library modules to run effectively. I can see if being defensible to include the module-local. | 21:27 |
| cjwatson | I think packaging that sort of thing in dist-packages is fine, indeed. It would also be possible to put it in /usr/share/cloud-init/, but that's probably less convenient from the Python point of view. | 22:08 |
| blackboxsw | good news too was that setuptools via setup.py also provides the simple package_data directive which I hadn't used before, which allowed me to easily add package_data={"": "*.json"}, to ensure we package the JSON schema files directly wherever they are in our tree. https://setuptools.pypa.io/en/latest/userguide/datafiles.html | 23:31 |
| blackboxsw | This simplified out readthedocs generation too which can now allow sphinx doc generation to relay on data files local to the python modules instead of trying to provide env vars or custom RTD config to inject the schema file in an sphinx build accessible location. | 23:34 |
| blackboxsw | thx again. | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!