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:

• [x] thunk-gen
  • [x] license review
  • [x] ITP: https://bugs.debian.org/1073181
  • [x] update packaging for current unstable
  • [x] upload to NEW: https://ftp-master.debian.org/new/thunk-gen_0.0~git20240607.f9cae90-1~exp1.html
• [x] update smallerc
• [x] djstub
  • [x] license review
  • [x] ITP: https://bugs.debian.org/1074057
  • [x] update packaging for current unstable
  • [x] upload to NEW: https://ftp-master.debian.org/new/djstub_0.0~git20240621.49e7ba6-1~exp1.html
• [ ] dj64dev
  • [x] 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 (#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 :wink:

[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: https://github.com/stsp/dj64dev/commit/eb37e92e2dcb3e0f27bf0b2225c2eaf4ec138642 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 :wink:.

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

As for the license review, I am now also trying to do that. :) (yes, code first, license last!) And I see a small problem: all the library-related code (which means src/libc/* was licensed under LGPL. But src/libc/dj64 is a port of fdpp's porting layers, which were licensed under GPLv3+. Now I am not sure what does this mix give us. Should I, as a sole author of that code, re-license src/libc/dj64/* under LGPLv2+? Or LGPLv3+? Or GPLv3+ suits?

[stsp]

Or GPLv3+ suits?

Well, I am afraid it doesn't suit, as in this case the resulting libs are also GPLv3+, which is undesirable... So I am afraid we need to do something here. Fortunately I am the sole author of that code, so any re-licensing can be done without hesitations. I just need to understand what suits the best.

[stsp]

Wrote to djgpp list. Hope they will be able to guide me with that.

[stsp]

https://www.delorie.com/archives/browse.cgi?p=djgpp/2024/06/28/16:28:37

[stsp]

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

[stsp]

Actually I wonder if it is a normal practice to use GPLv2+ or LGPLv2.1+, but explicitly disallowing to ever upgrade them to version 3... And this is what djgpp does.

[stsp]

Any progress? :)

[stsp]

Hi @skitt what's the blocker? Licensing changes?

[stsp]

Minimal CI workflow added (as was suggested by debian docs).

[skitt]

Hi @skitt what's the blocker? Licensing changes?

I was on holiday :wink:. I’ve updated thunk_gen and djstub, dj64dev is next.

[stsp]

I was on holiday 😉

Just curious, does this mean you are paid worker for debian? :) I mean, when I was working, I could contribute to dosemu2 mostly only on holidays.

[skitt]

No, I do my Debian work on my own time — I meant that I was away from home, on holiday without a computer.

[stsp]

holiday without a computer.

Cool! :) Most people probably completely forgot about such possibility ever existed.

[skitt]

I have a couple of questions regarding the target architectures... If I’ve understood correctly, dj64 contains the target C library .so, dj64-dev the target C library header files, dj64-dev-static the target C library built statically; all those should target the “dj64” architecture. djdev64 and djdev64-dev contain files for the host architecture, so they target Debian/Ubuntu arches as usual. Is all that correct?

A consequence of the above is that the target triplet probably needs fixing. Currently it’s always i386-pc-dj64, even though dj64 doesn’t target i386s! The first part should be an appropriate GNU CPU name, such as x86_64 for 64-bit x86 or aarch64 for 64-bit ARM.

Another consequence is that since the dj64 packages aren’t built for Debian/Ubuntu arches, they should be arch-all packages built for the appropriate dj64 architectures. That probably means either bundling multiple target arches, or multiplying the number of packages in gcc-mingw-w64 style (dj64-x86-64, dj64-aarch64, etc.).

Does all this make sense, or am I barking up the wrong tree?

[stsp]

Is all that correct?

Yes.

Currently it’s always i386-pc-dj64, even though dj64 doesn’t target i386s!

This is not quite correct. "dj64 architecture" as you called it, is bi-arch. dj64 package installs the libs targeting the host platform (a run-time), but dj64-dev install files for development, and they target i386 arch. I guess this is slightly confusing or inconsistent. The only alternative I can think of, is to install the run-time into /usr/lib/dj64/*, but that also has downsides: its a bit strange to have the headers for that lib in i386-pc-dj64 when the lib itself is outside. I.e. separating the lib from its headers probably just makes things even worse. So I went for this bi-arch approach: /usr/i386-pc-dj64/lib = i386 /usr/i386-pc-dj64/lib64 = x86_64/aarch64 Given that info, what layout do you propose?

or multiplying the number of packages in gcc-mingw-w64 style (dj64-x86-64, dj64-aarch64, etc.).

That should be fine. And -dev is not needed to be duplicated, as it keeps targeting just i386.

Does all this make sense, or am I barking up the wrong tree?

It definitely makes sense. But the bi-arch nature of dj64 must be taken into account.

[stsp]

That should be fine.

Wait, no, I guess its not. Could you please state the problem more explicitly? So "dj64 packages aren’t built for Debian/Ubuntu arches" because it uses this /usr/i386-pc-dj64 sysroot? Or any other reason? If I'd like it to be built for debian arches, what must be done?

[stsp]

If current layout is not acceptable, we can even have double-sysroot: /usr/i386-pc-dj64/usr/<debian_arches>/lib. Will that work?

[stsp]

So briefly: we need a runtime support libs built for host arch. BUT they are so tied to their headers and i386 libs in /usr/i386-pc-dj64 that moving them outside makes no sense.