move to debian?

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

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

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.

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

Forbidden

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

OMG... use vpn?

Wow, that’s surprising!

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

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 )

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?

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.

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

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.

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.

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

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

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

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?

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.

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?

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

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.

@skitt

Hi @skitt any progress?

FYI, since today dj64dev no longer
build-depends on cross-gcc, which
was a major complain from some
distros. Hope that will help with the
debian adoption as well.
Also there will be no more build
problems if debian happens to have
an outdated package, as I am now
versioning all the changes properly
(only for debian-included packages).
So I really hope all the possible hurdles
are resolved.

@skitt

Hi @skitt any news?
Have you changed your intention
of adding this?

@skitt

Hi @skitt so what about
nasm-segelf? That should be
easy, and will help a lot.

Sysroot problem is solved.
At least lintian no longer
complains. I introduced the
--with-sysroot option and
now debuild moves sysroot
to multiarch libdir.
Hope this helps.

Also packages are split per
sonames, as debian requires.
So I don't know if anything
still offends to debuild system.

Ok, nasm-segelf dropped from
fdpp. This means no more weird
deps, besides those already in
debian!
Not sure how can I please you
even more. :)
Does this help?

@skitt

Hi @skitt

Please update djstub to 0.8
to get the full dosbox compatibility.
You need to remove the note
about dosemu2 in your current
deb description. Its now emu-
independent.

Please get this comcom32:
https://code.launchpad.net/~dosemu2/+archive/ubuntu/ppa/+files/comcom32_0.4-0~202606250643+202606252349~ubuntu26.04.1_all.deb
and you'll notice that it runs under
any emulator. Moreover, even
commands like elfexec2 do work.
It is produced with the new dj32
target of dj64dev suit.

You can even build comcom with
djgpp, then restub with djstub-0.8,
and that restubbing alone will enable
elfexec2 command.

So both djstub and dj64dev packages
are now emu-independent, and thus
are having value for debian on their
own, not as a dep of dosemu2. And
in addition, they bring in no new deps
like ia16-gcc or djgpp - no, just smallerc.

Is there anything else to convince
you to get that in?

@skitt

@skitt so if you have obviously
decided to give dosbox-x a priority
(as an unfair competition), then I
still don't understand what's wrong
with dj64dev: its fully dosbox-compatible!
(except bsd sockets)
So what's up?

@skitt

Hi @skitt

Another try.
So if getting dj64dev is so
problematic, I've split it into
2 packages. You just need to
get this one:
https://github.com/dosemu2/djdev64/
Its a very small package, consisting
of 2 solibs. It is enough for dosemu2
to load the statically linked comcom64,
that we already provide via github
pages. So with that, people will only
need to build fdpp and DL the binary
of comcom64 to get a working dosemu2.
fdpp is already buildable because you
took thunk-gen, so basically this package
alone will solve the biggest part of
the problem.

Navigation Menu

Repository navigation

move to debian? #5

60 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

move to debian? #5

Description

Activity

skitt commented on Jun 14, 2024

stsp commented on Jun 14, 2024

skitt commented on Jun 14, 2024

stsp commented on Jun 14, 2024

skitt commented on Jun 14, 2024

stsp commented on Jun 14, 2024

stsp commented on Jun 14, 2024

stsp commented on Jun 14, 2024

skitt commented on Jun 14, 2024

stsp commented on Jun 14, 2024

skitt commented on Jun 14, 2024

stsp commented on Jun 14, 2024

stsp commented on Jun 14, 2024

skitt commented on Jun 14, 2024

stsp commented on Jun 14, 2024

60 remaining items

skitt commented on Aug 17, 2024

stsp commented on Aug 17, 2024

stsp commented on Aug 17, 2024

stsp commented on Aug 17, 2024

stsp commented on Aug 17, 2024

stsp commented on Nov 10, 2024

stsp commented on Dec 8, 2024

stsp commented on Jan 29, 2025

stsp commented on May 10, 2026

stsp commented on May 28, 2026

stsp commented on May 28, 2026

stsp commented on May 30, 2026

stsp commented on Jun 26, 2026

stsp commented on Jul 22, 2026

stsp commented on Sep 22, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions