move to debian?

[stsp]

Hi @skitt

I spent the considerable efforts on
finishing and polishing dj64dev.
All missing functionality that I was
aware of, is now implemented.
The usage of the tool-chain is greatly
simplified and fully documented:
https://github.com/stsp/dj64dev/blob/master/README.md
Also the demos are provided:
https://github.com/stsp/dj64dev/tree/master/demos
clang and freebsd ports are done.
Freebsd port required static linking
support, as it seems freebsd's dlopen()
ignores the link order... so 2 weeks spent
on making dlmopen() (which is missing
on freebsd) optional, appears to be in
vain, as dlopen() is also bad there. But
static linking is now implemented and works.

So to me it really looks like a tool-chain
now, rather than a set of an undocumented,
unportable ad-hocs.
Please let me know what is missing to
get it into debian, so that I can work it out.

[skitt]

OK, let’s do this; here’s what I need to do, I’ll open issues as appropriate if I run into problems:

• thunk-gen
  • license review
  • ITP: https://bugs.debian.org/1073181
  • update packaging for current unstable
  • upload to NEW: https://ftp-master.debian.org/new/thunk-gen_0.0~git20240607.f9cae90-1~exp1.html
• update smallerc
• djstub
  • license review
  • ITP: https://bugs.debian.org/1074057
  • update packaging for current unstable
  • upload to NEW: https://ftp-master.debian.org/new/djstub_0.0~git20240621.49e7ba6-1~exp1.html
• dj64dev
  • license review
  • ITP
  • update packaging for current unstable
  • upload to NEW

[stsp]

Is there a similar list for a programmer?

• porting: done
• documenting: done

and so on. There must be some, as I
don't think debian wants the unportable
or undocumented stuff.

[skitt]

Yes, there is: https://wiki.debian.org/UpstreamGuide

[stsp]

Forbidden

<p>You are not allowed to access this!</p>

OMG... use vpn?

[skitt]

Wow, that’s surprising!

[stsp]

So www.debian.org works but
wiki.debian.org blocks (I used
vpn so reading up).

[stsp]

OK, so from the above manual:

• off-line docs (aka man pages) are missing
• Hardcoded Paths: I have a few in -rpath:
  https://github.com/stsp/dj64dev/blob/master/dj64.mk#L35-L36
  Not sure if it is counted as a violation or not.
• Test suites: written, but not yet added to CI (add CI #3 )

[stsp]

I think the short man page can be
written, but what should I do with
README.md? Can I just package it
to deb and say that I now have the
off-line docs?

[skitt]

Packaging a README file is fine if the README provides useful documentation for end-users; that’s the case for dj64dev’s, not so much for thunk-gen. IMO from a package perspective man pages are better because more users think of using them, but from an overall perspective most users get their info from web searches now anyway, so improving READMEs is a better use of developer/maintainer time.

[stsp]

not so much for thunk-gen.

Thunk_gen is too internal.
It is very unlikely to every be used
by anyone including myself (I am
not planning any new thunk_gen-based
DOS code ports).
Do you think it should still be documented?
Of course I can just briefly describe
what it does, but that won't help any
of its potential users (which are none).

[skitt]

Yeah I agree there’s no point in documenting thunk-gen further, all I meant was that there is also no point in packaging its README.

[stsp]

Ah, ok.
I am currently trying to make dj64-gcc
script more relevant, as this is the only
"binary" that may potentially require a
man page (no other binaries are provided).

Also I have forgot to mention that djstub
must be included first.
Now since dj64dev has demos (that
require djstub to be built), I suppose I
need to add it to build-deps.

[stsp]

Or not, since demos are not built by
default... But in either case, djstub
must be packaged before thunk_gen
or dj64dev.

[skitt]

https://tracker.debian.org/news/1537129/accepted-thunk-gen-00git20240607f9cae90-1exp1-source-amd64-into-experimental/ — it’s already been accepted!

[stsp]

Good, thanks! :)
Although djstub should better go before
dj64dev, or it would be a complete breaker. :)

[skitt]

Yes, I updated the todo list above 😉

[stsp]

update smallerc

Hmm, how difficult would it be to
push updates, once things are in a
debian? smallerc was updated rather
long ago, but seems like every update
needs some amount of work from you
from now on? What's the procedure?

[skitt]

Yes, only DDs or DMs can upload packages to Debian. Once the initial packaging is done most updates are straightforward: gbp import-orig --uscan to import the latest release (or git commit if the project is set up that way), review the changes, dch to update the changelog, check the build, and upload.

[stsp]

Ok, I suppose for some time they
should live in parallel with PPA builds.
And then we'll see if the PPA can be
discontinued.

[stsp]

Added a primitive man page.
As for packaging README.md -
it contains too many external links,
so its off-line use is very small.

[stsp]

Could you please help with this
bug report:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2069483
by checking if it is fixed in bullseye?
On which, I think, Focal is based.

[skitt]

Could you please help with this bug report: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2069483 by checking if it is fixed in bullseye? On which, I think, Focal is based.

It’s fixed in bullseye, but focal is based on buster — at least, bullseye has coreutils 8.32, whereas focal has 8.30, same as buster. The same sort error occurs on buster as on focal.

[stsp]

So is this table wrong?
https://askubuntu.com/questions/445487/what-debian-version-are-the-different-ubuntu-versions-based-on

Would be cool if you can help with
fixing it on buster, although I already
applied this hack:
eb37e92
to check for FreeBSD explicitly. :)
I hate doing the like things, but the
hack is already there, so no rush at
all (but maybe you can at least bug-report
that).

Also I wonder what's the destiny of
lfanew. I talked you into adding it, and
then dropped (shit happens, but overall
I simply didn't know smallerc's upstream
is that responsive - he patched the linker
for me).
What would happen now with the package?
It was documented as a dosemu2 requirement,
which is no longer true.

[skitt]

That table is a simplification, see https://unix.stackexchange.com/a/404261/86440. Focal was branched off of bullseye during bullseye’s development, which means it has package versions that are guaranteed to be equal to or newer than those in buster (hence my comment above), and equal to or older than those in bullseye — so saying that it’s based on bullseye is misleading.

Buster is dropping out of LTS at the end of the month, and has been out of mainstream support since 2022, so it’s not possible to fix bugs there any more (other than security issues or critical bugs in packages supported in ELTS).

Regarding lfanew, I’ll stop it from being included in the next Debian release, unless another use-case turns up for it. Debian has loads of little-used (or even unused) leaf packages, so one more in unstable won’t be a problem 😉.

[stsp]

Ok, thanks for info.
Pretty clear now. :)
One day I'll just drop Focal.
It already did some problems
in the past.

[stsp]

Hmm in fact, speaking of an off-line
documentation, I can instead create
a -demos package.
Or is it an overkill?

[stsp]

Demos added to share/doc/dj64.
So I suppose the doc question is
closed.

[stsp]

Hi @skitt thanks for checking in
the progress boxes. :)
I think 1 more task should be added
to update thunk-gen, as there was 1
incompatible change, that probably
happened after you uploaded it to
debian.

[stsp]

OK, I have finished the license review.
You'll now need to re-do that step again. :)