[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Condor Upload



HTCondor 23.2.0 is ready to go. Let me know what the next steps are.

https://salsa.debian.org/hpc-team/condor/-/pipelines

...Tim

On 12/7/23 07:35, Andreas Tille wrote:
Ping?

Kind regards, Andreas.

Am Tue, Jul 04, 2023 at 10:54:17AM +0200 schrieb Andreas Tille:
Hi again,

Am Wed, Mar 22, 2023 at 07:31:09AM +0100 schrieb Andreas Tille:
Just to make sure you understood release policy:  There is zero chance
that htcondor will be included into bookworm since this is frozen which
means no new packages will be accepted any more (new in terms not in
testing).
A new release cycle has started and I would recommend to use this as a
chance to upload some sensible candidate to new as early as possible.
I noticed that version 10.6.0 is the latest release of htcondor.  Should
we upgrade the packaging to this version and upload it to new?
I have uploaded HTCondor 10.3.0 and it builds on x86_64. And passed lintian
with warnings. (I resolved all errors.) So, now it build on x86_64 on salsa.
On i386, it is supposed to use C code for one program and instead it is
trying to use x86_64 assembler. So, I would have to look at changes needed
to build on i386.
I'm waiting until you confirm that the issue mentioned in your other
mail is solved.
I do not remember that issue - may be its solved with the new version -
thus I do not check.
I see that it failed piuparts testing. I imagine that this also needs fixing
before it is accepted.
I think you should make absolutely sure that debian/copyright is precise
and is mentioning all copyrights in single files that are deriving from
the main copyright of the code.  Htcondor needs to pass the new queue
due to the change in the name of the binary.  As a consequence ftpmaster
will check d/copyright and to my experience this takes long (in terms of
one to several months).  In case ftpmaster finds some issue you have to
fix this and re-upload which sometimes (not always) takes the same
waiting time again.  I'd recommend some

    grep -Ri copyright | grep -v 'Condor Team, Computer Sciences Department'

as a starting point what files need extra mentioning.
I'd like to repeat that this is *really* important.
I really want to get this in. Updating from 10.3.0 to 10.4.0 will be much
easier than going from 8.6.8 to 10.3.0.
Sounds promising for the future.
So what should be out target version?
Thanks a lot for your cooperation
     Andreas.
Again thanks a lot

      Andreas.
On 3/1/23 11:13, Andreas Tille wrote:
Hi again,

I admit I had quite some hope that we would manage to get condor into
shape in the end of last year.  Unfortunately this did not happen.
I wonder whether it is more in the sense of our users to remove the
really outdated version of condor from Debian at all now since it is
clear that it will not reach the next stable release any more.  Any
new upload of what we have needs to pass Debian New queue anyway.

What do you think?

Kind regards
     Andreas.

PS: I perfectly understand that you are busy and the Debian packaging
      might have lower priority.  So if you do not manage to respond in
      the next month I'll decide myself and will ask for removal.
      No matter what will happen I'll happily help you to re-introduce
      any new version of condor and you can ping me about this in
      future.

Am Wed, Jan 11, 2023 at 08:32:20PM +0100 schrieb Andreas Tille:
Hi Tim,

seems we lost track from condor again.  Due to the fact that the freeze
process is starting tomorrow and ftpmaster should not accept libraries
with version bumps, it is not possible that condor will be part of the
next stable release.

I really hope you will continue working on this package anyway, to get
it somehow into shape may be for backports.

Kind regards
     Andreas.

Am Wed, Nov 23, 2022 at 03:35:19PM +0100 schrieb Andreas Tille:
Hi Tim,

Am Wed, Nov 23, 2022 at 06:19:05AM -0600 schrieb Tim Theisen:
We want to stay with the 10.0.x versions are these are our LTS versions and
quite stable.

The 10.1.x versions are our feature releases and have a short support
lifetime.
Thanks for the helpful clarification.  I've adapted d/watch to report
only even minor version numbers (which is a bit weak since it will not
report 10.10 but there is some time left until then. ;-))
So, for Debian I think that it is best to stay with any version where 0 is
the second number.
Done in Git.
Could you give me the steps to add the pristine tar. I have never done that
and I don't fully understand it. Do you start with our official tarball, or
generate one from the github repository?
The generation is done by uscan via

     uscan --verbose --force-download

and the import of pristine-tar is done via

     gbp import-orig --pristine-tar --no-interactive /PATH/TO/condor_VERSION.orig.tar.xz

I know there is some gbp command which does everything in one rush but
since I always forget this one this is my workflow. ;-)

There is one file in msconfig, do_tests.pl. It is required to run our test
suite on all platforms. I know that this file is logically in the wrong
directory. I will restore it at some future date.
Thanks a lot for the additional background hint.  I've adapted
Files-Excluded in d/copyright accordingly.  It looks a bit nasty, but
well, it does what it is supposed to do. ;-)

More answers below.

As always, your help is greatly appreciated.

On 11/23/22 02:59, Andreas Tille wrote:
I did the following other changes:

     1. Added pristine-tar for the **latest** upstream release
        (your packaging was 10.0.0 - I injected 10.1.1)
Reverted to 10.0.0.

     2. I removed dir msconfig/ completely from upstream source
        since it seems to be Windows only
Left msconfig/do_tests.pl where it is.

     3. I had to tweak dh_install files since the upstream build
        does not install to debian/tmp/usr any more but rather to
        debian/tmp.  This is **not** **fully** **fixed** - some
        of the debian/*.install files do not find the files mentioned
        there.  Please fix this.
        Note: There is no need to specify debian/tmp in the
              beginning since this is default.
Thank you for the tip. This was done before my time by Michael Hanke.
It might be that in some ancient compat level of debhelper this was
needed.  So its no mistake in principle - just not a nice reading for
your fellow team members.

I have no idea what might have caused this change and I started working
on this in commit 5cde13597e7[3] - but I did not finished it since I'm
not sure how the package layout should be done.
Something changed somewhere such that the files are not landing where they
belong.
Do you see any chance to move them right into place?

Hope this helps
       Andreas.

--
http://fam-tille.de
--
http://fam-tille.de


--
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


--
http://fam-tille.de


--
http://fam-tille.de


--
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: