Re: Condor Upload
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 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"?
>
> > 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 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.
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.
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
--
http://fam-tille.de
Reply to: