glue issueshttps://git.ligo.org/lscsoft/glue/-/issues2024-03-01T14:10:11Zhttps://git.ligo.org/lscsoft/glue/-/issues/42Drop support for EL7/RHEL7/SL72024-03-01T14:10:11ZRobert BruntzDrop support for EL7/RHEL7/SL7Scientific Linux 7 (SL7, and the RHEL7 underlying it) is now severely deprecated at LIGO(see ["LIGO Lab O4b Python2 and Scientific Linux 7 Security Policy for Computing Clusters"](https://dcc.ligo.org/LIGO-M2400052)). We should drop sup...Scientific Linux 7 (SL7, and the RHEL7 underlying it) is now severely deprecated at LIGO(see ["LIGO Lab O4b Python2 and Scientific Linux 7 Security Policy for Computing Clusters"](https://dcc.ligo.org/LIGO-M2400052)). We should drop support for SL7/EL7/RHEL7 at some point. (It's also the EL7 parts of CI that consistently take noticeably longer than anything else to finish.)https://git.ligo.org/lscsoft/glue/-/issues/43Glue doesn't declare it's minimum required version of setuptools for Debian2024-03-04T11:50:36ZDuncan Macleodduncan.macleod@ligo.orgGlue doesn't declare it's minimum required version of setuptools for DebianNow that all of the version metadata is in `pyproject.toml`, on Debian (at least) we need `python3-setuptools (>=61.0.0), but this isn't declared, see `https://git.ligo.org/computing/sccb/-/issues/1454#note_958035.Now that all of the version metadata is in `pyproject.toml`, on Debian (at least) we need `python3-setuptools (>=61.0.0), but this isn't declared, see `https://git.ligo.org/computing/sccb/-/issues/1454#note_958035.lscsoft-glue 4.0.1Duncan Macleodduncan.macleod@ligo.orgDuncan Macleodduncan.macleod@ligo.orghttps://git.ligo.org/lscsoft/glue/-/issues/41Build and upload wheels to PyPI2024-03-01T14:01:14ZLeo P. SingerBuild and upload wheels to PyPIhttps://git.ligo.org/lscsoft/glue/-/issues/40Rename master branch to main2024-02-29T18:20:38ZLeo P. SingerRename master branch to mainhttps://git.ligo.org/lscsoft/glue/-/issues/35lscsoft-glue 3.0.2 and 4.0.0 planning2024-02-29T08:27:47ZDuncan Macleodduncan.macleod@ligo.orglscsoft-glue 3.0.2 and 4.0.0 planning@robert.bruntz, please consider the following attack order to finalise %"lscsoft-glue 3.0.2" and %"lscsoft-glue 4.0.0":
Glue merge request attack order:
- [x] https://git.ligo.org/lscsoft/glue/-/merge_requests/125+
- [x] https://git.li...@robert.bruntz, please consider the following attack order to finalise %"lscsoft-glue 3.0.2" and %"lscsoft-glue 4.0.0":
Glue merge request attack order:
- [x] https://git.ligo.org/lscsoft/glue/-/merge_requests/125+
- [x] https://git.ligo.org/lscsoft/glue/-/merge_requests/107+
- [x] https://git.ligo.org/lscsoft/glue/-/merge_requests/87+
- [x] https://git.ligo.org/lscsoft/glue/-/merge_requests/114+
- [x] https://git.ligo.org/lscsoft/glue/-/merge_requests/115+
- [x] https://git.ligo.org/lscsoft/glue/-/merge_requests/118+
- [x] https://git.ligo.org/lscsoft/glue/-/merge_requests/121+
- [x] https://git.ligo.org/lscsoft/glue/-/merge_requests/124+
- [x] https://git.ligo.org/lscsoft/glue/-/merge_requests/126+
- [x] https://git.ligo.org/lscsoft/glue/-/merge_requests/130+
- [x] https://git.ligo.org/lscsoft/glue/-/merge_requests/131+
Then we can finalise lscsoft-glue-3.0.2 as the last glue.ligolw-supporting release.
Then
- [x] https://git.ligo.org/lscsoft/glue/-/merge_requests/117+
- [x] https://git.ligo.org/lscsoft/glue/-/merge_requests/127+
- [x] https://git.ligo.org/lscsoft/glue/-/merge_requests/128+
- [x] https://git.ligo.org/lscsoft/glue/-/merge_requests/129+
Many of the above will require rebasing from me as upstream MRs are merged, so please yell.lscsoft-glue 3.0.2Duncan Macleodduncan.macleod@ligo.orgRobert BruntzDuncan Macleodduncan.macleod@ligo.orghttps://git.ligo.org/lscsoft/glue/-/issues/30Use a local DTD file, if one is available2023-09-22T21:17:01ZRobert BruntzUse a local DTD file, if one is availableI think there was an attempt at some point to recognize and use a local DTD file if one existed, rather than always using the one on the CIT server ( http://ldas-sw.ligo.caltech.edu/doc/ligolwAPI/html/ligolw_dtd.txt ). This would probab...I think there was an attempt at some point to recognize and use a local DTD file if one existed, rather than always using the one on the CIT server ( http://ldas-sw.ligo.caltech.edu/doc/ligolwAPI/html/ligolw_dtd.txt ). This would probably speed up publishing and would improve resilience, since currently [publishing stops](https://git.ligo.org/computing/helpdesk/-/issues/4653) when the `ldas-sw.ligo.caltech.edu` server goes offline, Apache on that server is turned off, etc.
There is an old commit that did something like this here ( https://git.ligo.org/lscsoft/glue/-/commit/e8d2eb25ea575b203b89a840063a38c0c3ec69a0 ), but obviously that bypass is not being used (and might not even apply - I haven't traced through the code to see where this should happen in the current code). It would probably be best to first see if that code *should* be using the local DTD file, if so, then check if that file exists, if so, then figure out why it isn't working.