Re: Condor Upload
Hi again,
Answers inline.
On 11/1/22 07:50, Andreas Tille wrote:
Hi again,
Am Fri, Oct 28, 2022 at 02:02:51PM +0200 schrieb Andreas Tille:
Hi Tim,
Am Thu, Oct 27, 2022 at 11:31:02AM -0500 schrieb Tim Theisen:
Thank you for the help.
You are welcome. Please note: I'm not a user of condor. My main
motivation is that the Debian Med team took over responsibility of
Neurodebian packages and I failed for years to sort this out. So I'll
probably leave you alone once the package is maintained (and thus
uploaded with the proper maintainer address and VCS fields) of Debian
HPC Team (I just fixed the Maintainer address).
These are important metadata which influence several workflows which
are broken for years now. Just to make sure you will understand my
motivation correctly.
To stress that I'm for the moment highly motivated I fixed quite some
lintian issues which you can see in Salsa CI[1]. I see room for fixing
some more which might be easier for me than for you given that I have
quite some training with such issues. But this will not happen before
next Tuesday (Monday is holiday here at my place).
I have not seen any commits of yours so far. I hope we can continue
together to finally get condor in shape.
I will work on this next week when I get back to the
office on Monday.
I would like you to decide one pretty important thing: Please
reconsider the creation of the new binary package **temporarily**. The
point is: The current condor package is urgently needed at the earliest
point in time given it fixes so many CVEs and bugs. When adding a new
binary package it takes an unpredictable time to pass the new queue and
my gut feeling tells me that we need to expect several months and most
probably several cycles in new. This means the next stable release
would be (again) without condor.
To avoid this my suggestion is to either not ship the files in the new
binary package or leave them inside the main package, upload, wait until
the package is migrated to testing and add the new binary package
*later*.
Seems my suggestion is void since we have to rename former libclassad8
to libclassad15 anyway. Please confirm you understood that we need to
adapt d/copyright to the actual status *urgently* if we want to have
the slightest chance that condor will pass ftpmaster inspection. This
is probably even more important than those lintian issues.
I see that the upstream copyright file is not up to date. I will have a
complete version within 24 hrs.
I have used the Debian copyright tools before and know how to use them
I will check over your changes. Thank you for enabling Salsa CI. I've not
used it yet. I think it will be very useful for my updates. I tried running
lintian in my debian:sid Docker container and it just hung.
Strange, but anyway we have some solution now.
I intend that the upstream HTCSS Debian build files match the Debian build
files very closely. Just the version string should be different to
distinguish between them.
What are "the upstream HTCSS Debian build files"?
They are found in build/package/new-debian (soon to be renamed debian)
I know that the Debian build files need some work. They have been essential
untouched since Debian 9 (stretch). For instance, we should be using the
debhelper stuff for systemd files.
Definitely. Unfortunately I have not dealt with systemd yet. Thus I
left this untouched. May be its a good idea if you would concentrate on
this (seeking for examples at https://codesearch.debian.net or ask for
some help on debian-mentors@lists.debian.org is highly recommended).
I have a good idea on how to address the systemd files. What we have now
works. So, this lower priority.
I have many copyright updates from the HTCSS project. I will incorporate
those from upstream.
It makes sense to update this inside the Debian packaging but as I said
above: For the moment I'd recommend to avoid some ftpmaster copyright
review since it takes more time than we have.
I repeat: Since my suggestion became void and we need to undergo
ftpmaster inspection in any case the copyright review is the most urgent
task on condor currently. For instance I can find lots of
CMakeLists.txt in externals/bundles also some patches. These *all*
contain some copyright statements. Believe it or not every single file
needs to be mentioned in d/copyright. If these files could be simply
removed from the upstream tarball since they might not be used in the
build process this would save a lot of work. You can get a first
impression what needs checking by
grep -Ri copyright | grep -v ^debian
Back to some lintian issues:
E: htcondor: no-debconf-config
I have no idea whether debconf questions are needed for htcondor
installation but if not simply removing the file
debian/htcondor.templates
would make this error vanish.
This is an error on my part. htcondor.template should be removed.
I've also removed the file
/etc/rc.d/init.d/glite-ce-blah-parser
from htcondor package since you are not permitted to install files to
/etc/rc.d directly. I have no idea what might be the purpose of this
file but given that it is sourcing a non-existing file
/etc/rc.d/init.d/functions
its not working anyway. If this script has some actual use please
fix it.
Yes. the glite-ce-blah-parser should be removed. Thank you for catching
that.
I'd also recommend to turn the csh script
src/condor_release/examples/sh_loop
into POSIX shell. There is absolutely no need to have this simple
script in csh.
Please see the now updated lintian issues[1].
Hope this helps
Andreas.
[1] https://salsa.debian.org/hpc-team/condor/-/jobs/3455879
--
Tim Theisen (he, him, his)
Release Manager
HTCondor & Open Science Grid
Center for High Throughput Computing
Department of Computer Sciences
University of Wisconsin - Madison
4261 Computer Sciences and Statistics
1210 W Dayton St
Madison, WI 53706-1685
+1 608 265 5736
Reply to: