adflib debian/

[alexmyczko]

the package already exist but is called unadf. Tomasz do you want to maintain it for debian? I can sponsor your packaging…

[t-w]

Yes, AFAK, unadf was the only thing packaged so far (statically liked), standalone library was not there. Since there are couple of new tools, I put unadf with them to libadf-utils.

So far, I was not involved directly with Debian dev, kind of "debbing" things for myself when I needed... So I do not know too much about the processes in Debian. From wiki, I understand I would need to make account on mentors.debian.net, and upload the package there? Or the source code? Then you take over, sign the final package etc. right?

Also - couple of months ago, we were contacted by the maintainer of the unadf package about a new version for bookworm, but we did not have things ready then...

[alexmyczko]

dla mnie nie, you can put your debian src package (.dsc) anywhere online, and i'll dget and test it using debuild and some manual steps before sponsoring.

the only important thing is that upstream orig.tar.gz is without debian/, and you add debian/ which gets placed somewhere else after debuild.

not sure who contacted you because unadf package has no maintainer, well QA team.

once i get to it i'll be glad to guide you. if you're on irc try to join irc.debian.org #debian-mentors

[t-w]

So far what I do to build deb packages is (in case there is something to correct in the process...):

• having autotools or cmake done, I setup things in debian/
• I create "quilt3" archive (as I understand, required by debuild) - so basically this is the .orig.tar.gz (without debian/)
• I run debuild -us -uc
• after the above, I have .debs, .debian.tar.xz (with debian/ inside) and .dsc (and the logs)

So from the 3 files that you need, the .dsc was missing (it was not configured to be archived in the workflow). I updated the workflow to include it and I rebuild it - so now the .debian.tar.gz, .orig.tar.gz and .dsc (extracted from artifacts) are added to the assets of the 0.8.0 release - so you can get it from there.

So let me know if the files are fine and what we do next.

[alexmyczko]

normally people use dh_make to create debian/

with the source package available one can do

dget https://github.com/lclevy/ADFlib/releases/download/v0.8.0/libadf_0.8.0-1.dsc
dpkg-source -x libadf_0.8.0*.dsc
cd libadf-*/
debuild

now we get the following lintian output:

W: libadf: initial-upload-closes-no-bugs [usr/share/doc/libadf/changelog.Debian.gz:1]
W: libadf-dev: initial-upload-closes-no-bugs [usr/share/doc/libadf-dev/changelog.Debian.gz:1]
W: libadf-utils: initial-upload-closes-no-bugs [usr/share/doc/libadf-utils/changelog.Debian.gz:1]
W: libadf source: no-versioned-debhelper-prerequisite 10
W: libadf: package-name-doesnt-match-sonames libadf1
W: libadf-dev: privacy-breach-generic [<img src="http://stat3.cybermonitor.com/clubv3_v?r=pagespersos_abonnes&s=total;pagespersos">] (http://stat3.cybermonitor.com/clubv3_v?r=pagespersos_abonnes&s=total;pagespersos) [usr/share/doc/libadf-dev/adf_info.html]
W: libadf-dev: privacy-breach-generic [<script language="javascript" src="http://js.cybermonitor.com/clubv3.js">] (http://js.cybermonitor.com/clubv3.js) [usr/share/doc/libadf-dev/adf_info.html]
W: libadf source: useless-autoreconf-build-depends (does not need to satisfy autotools-dev:any)
W: libadf source: useless-autoreconf-build-depends (does not need to satisfy dh-autoreconf:any)

i'm a bit busy, but i'll try to edit/improve the answer

[t-w]

Thanks for checking and the info.

Yes, there are several warnings from lintian, they do not seem to be critical. Some probably probably will rather not be corrected ("package name doesn't match soname" will not happen as it was decided (discussion in #34) that soname will not relate to the library version... Unless we change it.... For now, I'd prefer to leave it as it is, unless it will be less troublesome to change it now than cleaning this up in the future.

I tried exactly what you wrote (dget etc.), it works except failing on signing.

So let me know if there is something to correct and, if not, how do we progress (for me no rush, too, I may also replay with some delays...)

[lclevy]

Would be nice to have a debian packaging with latest and better version of adflib 💪

[alexmyczko]

the point is this software ships unadf, thus there is already http://packages.debian.org/unadf and that needs to be replaced..

[t-w]

As I showed above, I am willing to make changes required to make it available in Debian. So I did the checks I could and waited for further tips on what has to be done... But I am not pushing for anything myself, as I myself have limited time and understand it completely.

Some points regarding unadf:

1. earlier versions were statically built (no libadf in debian or ubuntu (AFAIK, correct me if I am wrong...)
2. so far, the "unofficial" packaging that I made, has 2 differences vs. earlier unadf

• it uses libadf shared library - so requires libadf package
• it is packaged as libadf-utils with a few other tools, not separately as unadf

So, the question is, what exactly do we want to provide in debian. For me, the current packaging is optimal:

• there is shared lib, and a separated dev
• utils are separated, with dependency on libadf

This is what, I normally see in Debian for similar cases. Eventually, since unadf is an utility that was shipped separately, it could still be separated from libadf-utils and put into its own package (but still with the dependency on libadf).
If you want to have a separate, independent, statically built and packaged unadf, as it was before, debian/ can be completely replaced by a packager willing to do that. But here, we should provide all - the library and its utilities. And that is what we have so far.
So let know what you think. For people needing only unadf, installing other utilities can make no sense - but it is also matter of how many packages there are... So not sure what is better for this case (but as stated before - for me, the current unofficial packaging is optimal).

One more thing - there is some new code (#66) that repairs important things of libadf (though in writing mode, so no concern for unadf...), and some changes/improvements within the library. So, the version 0.9.0 will most likely be released very soon after merging (to prevent people from using the broken block allocation bitmap code from earlier versions...).
So working on pushing 0.8.0 into Debian now makes little sense to me, as it is probably matter of days to have a newer version.

[alexmyczko]

Ok let's do step by step. We can skip creating a RFP/ITP bug for adding a new package, by using this new version building unadf binaries through debian new queue. To do so, the source package must be called unadf, the binary built packages can be called whatever, your suggestions above are good.

Next, with a new version of this software. Can you check if one of these bugs can get fixed?
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=unadf;dist=unstable

After these things, if you believe the source package name is wrong, that can be changed. But it's always painful, so I would recommend to keep debian source package name unadf.

drop debian/README.Debian and debian/README.source
add debian/upstream/metadata (example http://sid.ethz.ch/debian/tinymembench/)
in debian/control:

Build-Depends: dh-autoreconf,
               debhelper-compat (= 13),
               autotools-dev
Standards-Version: 4.6.2

drop debian/compat

[t-w]

Concerning the bugs:

• the first occurred basically while trying to open a file containing just a short string (AAAAAAAAAAAAAAAAAAAAAAAA) as a disk image, and take it from stdin. Currently, I see that unadf do not allow stdin as an image:

$ unadf -s - < file___dev__stdin.symb 
unADF v1.2 : a unzip like for .ADF files, powered by ADFlib (v0.8.0 - 2023-06-26)

unadf [-lrcsmpw] [-v n] [-d extractdir] dumpname.adf [files-with-path]
    -l : lists root directory contents
    -r : lists directory tree contents
    -c : use dircache data (must be used with -l)
    -s : display entries logical block pointer (must be used with -l)
    -m : display file comments, if exists (must be used with -l)
    -p : send extracted files to pipe (unadf -p dump.adf Pics/pic1.gif | xv -)
    -w : mangle filenames to be compatible with Windows filesystems

    -v n : mount volume #n instead of default #0 volume

    -d dir : extract to 'dir' directory

Also - trying to open such an invalid file directly results in an error:

$ unadf -s file___dev__stdin.symb 
unADF v1.2 : a unzip like for .ADF files, powered by ADFlib (v0.8.0 - 2023-06-26)

Error <adfDevType : unknown device type>
Error <adfMountDev : unknown device type>
file___dev__stdin.symb: can't mount as device

Anyway, I will probably add a simple regtest for this as the lib should not ever crash on an invalid file...

• the second was fixed (see Fix adfGetCacheEntry() crashing on bad data #35, there is also a regtest for this one)

So both of the bugs are fixed.

(btw. note that both are about an ancient version 0.7.11... A lot of things were improved/fixed in libadf and the unadf itself was rewritten in 4ce14b2...)

As for the rest - I go back to this after merging #66, so that we figure out the setup before marking a new release.

[t-w]

Ok let's do step by step. We can skip creating a RFP/ITP bug for adding a new package, by using this new version building unadf binaries through debian new queue. To do so, the source package must be called unadf, the binary built packages can be called whatever, your suggestions above are good.

For this, I am not sure... I understand that the shortcut you propose can be simpler/faster - but wouldn't it be also inconsistent and troubling? unadf is one of the utilities (even if the most used one) based on adflib, not the opposite... It will look like adflib is rendered from unadf - while it is the opposite...

Will this not create more trouble, if someone will want to make it "properly" later, ie. change the name of the source package for libadf?

Also - versioning will be confusing as unadf has separated scheme (though currently Debian package has version 0.7.11a-5+deb1, so the version of the ADFlib, not of the utility:

unADF v1.2 : a unzip like for .ADF files, powered by ADFlib (v0.8.0 - 2023-06-26)
[...]

(For this reason, and to keep this consistent with former packages, I think I will create a separated binary package just for unadf).

Eventually, maybe can we rename the source package via patch (can files under debian/ be modified using a patch?)

(I am not arguing here what is better, this is just my curiosity and wondering what is eventually better, less-troubling in the future; having no experience with lifetime management of source packages in Debian, for sure I cannot judge this myself...)

Next, with a new version of this software. Can you check if one of these bugs can get fixed? https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=unadf;dist=unstable

Clarified above.

We have to mark this somewhere as fixed, right? (changelog?) Lintian often complains about no bugs/issues mentioned...

After these things, if you believe the source package name is wrong, that can be changed. But it's always painful, so I would recommend to keep debian source package name unadf.

drop debian/README.Debian and debian/README.source add debian/upstream/metadata (example http://sid.ethz.ch/debian/tinymembench/) in debian/control:

Build-Depends: dh-autoreconf,
               debhelper-compat (= 13),
               autotools-dev
Standards-Version: 4.6.2

If possible, I would like to keep possibility to build the library for older Debians (at least those still supported, like old stable/11), in case somebody needs it. Won't any of these changes break it?

(I see that debhelper's version in Debian 11 is 13 so probably OK. Not sure about the standards version...)

[alexmyczko]

there is two main issues when you do not handle the unadf src/bin package already:

• you have to handle unadf removal and transition

• you have to pass debian new queue

sorry i am not more detailed. but i would really go this way and can assist you with it. a src and or bin pkg rename is possible anytime, but cumbersome to handle.

[t-w]

What worries me here is that, if I understand well, instead of 1, we will have several binaries with unadf as the source package. Moreover, this will propagate most likely to ubuntu and derivatives. So I have to ask again - will this not be more cumbersome to rename this later, when several packages might be involved, than rename now, when there is only one?

One more thing - I have checked status of unadf package and it is in the state "currently being adopted": https://www.debian.org/devel/wnpp/being_adopted
-> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661461
So aren't we going somewhere in the middle of the process?

---

I have made the changes you pointed out - but removing debian/compat results in:

[...]
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
dh clean --with autoreconf
dh: error: Compatibility levels before 7 are no longer supported (level 1 requested)
make: *** [debian/rules:20: clean] Error 25
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit status 2
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui failed

Does it have to be build in some other way? (I use debuild so far).

[kyz]

I did a short survey of debian stable packages which are tagged works-with::archive, have more than one binary, and depend on "their own" library (e.g. not building upon a 3rd party library)

I got bzip2, dar, dynamite, eb-utils and zziplib-bin. Also it's not tagged but libarchive-tools also fits.

So precedent says there's no problem naming the package after the main utility or the library, and you can have extra binaries in the package.

Personally, I think the package name unadf has all existing cachet and brand recognition, it would be foolish to throw that away. It's like insisting Twitter be called "X"

You can have both, as far as I know.

Option 1:

• Package unadf: depends on libadf1; includes /usr/bin/unadf
• Package libadf-utils: depends on libadf1; includes all binaries except unadf
• Package libadf1: suggests libadf-utils, unadf

Option 2:

• Package unadf: depends on libadf1; includes all binaries including unadf (e.g. like bzip2, dar, dynamite packages)
• Package libadf1: suggests unadf

Option 3:

• Package unadf: dummy transitional package; depends on libadf-utils (e.g. like bsdtar and bsdcpio packages) - in the next Debian release, "unadf" will be completely removed and only "libadf-utils" will remain
• Package libadf-utils: depends on libadf1; includes all binaries including unadf (e.g. like libarchive-tools)
• Package libadf1: suggests libadf-utils

I would personally prefer option 1, if Debian rules allow it, or option 2 if they don't. Option 3 is a lot of extra work, as described in #59 (comment) but if the authorial intent is to forcibly rebrand everything, option 3 makes it clear.

[t-w]

We are not discussing the name of the binary package of unadf, but the source package name, which is incorrectly set as unadf. The main package for this project always was and is ADFlib. unadf is and was and example/ of library's usage, even if is it, of course, a useful utility on its own.

As I wrote before that I was going to - I have separated the binary package with unadf exactly for the reason you wrote - it is expected to be found by other packages. In fact, this can also be achieved by adding provides option to the package libadf-utils, what you do not mention in your options. The reason why I have moved unadf to a separated package is to not enforce installing other utilities (that may be much less needed).

So this aligns with your option 1, what I hope is OK for you.

Now for the last part of your message - unadf is a derivative utility using a small subset of functions of the ADFlib - thanks to which unadf, that, not that long time ago, you rewrote, exists. So nobody is trying to rebrand. Rebranding was done before by taking a shortcut and not doing things properly. IMHO like this, Laurent's library does not get proper recognition and credit for what it is. The result is that so far it was not even packaged as a library, despite its obvious usefulness. Writing some utility on top of the library is a piece of cake vs. the work he had to do so that data in the ADF format can be accessed. So I would suggest to avoid this kind of unfair statements.