search

lclevy / ADFlib

A free, portable and open implementation of the Amiga filesystem
GNU General Public License v2.0
84 stars 29 forks source link

adflib debian/ #59

Open alexmyczko opened 1 year ago

alexmyczko commented 1 year ago

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

t-w commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

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 commented 1 year ago

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 commented 1 year ago

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 commented 8 months ago

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

alexmyczko commented 8 months ago

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

t-w commented 8 months ago

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:

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 commented 8 months ago

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 commented 8 months ago

Concerning the bugs:

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_devstdin.symb unADF v1.2 : a unzip like for .ADF files, powered by ADFlib (v0.8.0 - 2023-06-26)

Error Error file_devstdin.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](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862740) was fixed (see #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 commented 7 months ago

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 commented 7 months ago

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

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 commented 7 months ago

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 commented 7 months ago

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:

Option 2:

Option 3:

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 https://github.com/lclevy/ADFlib/issues/59#issuecomment-1902093855 but if the authorial intent is to forcibly rebrand everything, option 3 makes it clear.

t-w commented 7 months ago

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.

kyz commented 7 months ago

I've known Laurent for a long time, so I hope he doesn't mind, but I've been using unadf since it was released in 1999 (simultaneously with ADFLib, 2 years after he began the ADF FAQ) and it's an exceptionally useful tool, I've used regularly for more than 20 years now. I liked it enough to contribute a reimplementation to improve its ergonomics and security. I've never needed to write a program that used ADFLib directly. We have different perspectives.

Another example: Debian packagers added my software, source package cabextract, in 2001. When I moved its core code to a library,called libmspack in 2004, there were many more static builds and no library package until 2013, when they added a new source package libmspack. They didn't drop source package cabextract, nor do I consider it incorrectly named or its existence stealing the glory from libmspack. I release them separately as libmspack and cabextract; the former is a library with some toy usage examples, the latter is a "productised" command-line tool with its own unique features, portability and security concerns. I think unadf is similar to this. We have different perspectives.

My example shows the source package unadf can remain, independent of whether there is a another source package called adflib to package the library and other tools.

Whether there needs to be a source package named adflib or not is down to choice - wait to get a new package accepted, or adopt the old one but have to keep its name. I have no concerns over that choice, I believe nobody but a few Debian maintainers ever see the source package name. I am concerned about the binary package name; I would expect to find unadf in apt-cache search because from my perspective it is the product I use. If I searched apt-cache search unadf and found no such package, but matched libadf-utils instead, I'd roll my eyes hard and note that the ADFLib marketing team had been at work. If I used the library I'd expect it to be in libadf1 and libadf-dev, but I wouldn't notice or care the source package name. It's not even shown to me as a user.

We now get these options, ordered by effort:

  1. Source package unadf builds packages libadf1 and unadf (all binaries).
  2. Source package unadf builds packages libadf1, libadf-utils (some binaries) and unadf (just unadf).
  3. New source package adflib builds packages libadf1, libadf-utils (all binaries). Source package unadf builds unadf ( transitional package to ibadf-utils)
  4. New source package adflib builds packages libadf1, libadf-utils (some binaries), libadf-unadf (just unadf). Source package unadf builds unadf (transitional package to libadf-unadf). At the next Debian release, a further transition from libadf-unadf to unadf
  5. New source package adflib builds packages libadf1, libadf-utils (some binaries). Source package unadf builds unadf (just unadf). This approach probably does not fit with the build structure of the library packaging, as libadf and unadf do not appear to be treated or released as separate products.
  6. Option 1 or 2 above, to be expeditious and avoid introducing a new source package, but decide later that it's unbearable to call the source package unadf so have to introduce a new source package anyway... this will, as far as I know, involve making transitional packages to temporary names for all the binary packages, and then a follow up plan for the next Debian release to transition them back to their intended names.

The most expeditious route is option 1 or 2. If name of the source package is very important, I think you should go with option 3 or 4 and spend the effort upfront, rather than option 6. My preference is either option 2 or 4, due to my binary package name preferences.

alexmyczko commented 7 months ago

@kyz this is another such package, started with binary only later also shipped lib: https://sources.debian.org/src/ancient/2.1.0%2Bds-1/debian/changelog/

alexmyczko commented 7 months ago

you're welcome https://github.com/t-w/ADFlib/pull/3

t-w commented 7 months ago

I've known Laurent for a long time, so I hope he doesn't mind, but I've been using unadf since it was released in 1999 (simultaneously with ADFLib, 2 years after he began the ADF FAQ) and it's an exceptionally useful tool, I've used regularly for more than 20 years now. I liked it enough to contribute a reimplementation to improve its ergonomics and security. I've never needed to write a program that used ADFLib directly. We have different perspectives.

Well, the result of neglecting the library is as I mentioned - the library is not officially packaged anywhere until now and we have a naming mess to clean-up.

Yes, we do have different perspectives. I do not use nor particularly need unadf (though I might, I am happy it exists). I do use the library, I need it for fuseadf which replaces for me completely the functionality of unadf adding a lot more, giving me features of any other (basic) filesystem. Hence my will to improve the library to provide necessary features (but also to add more utilities to, for instance, examine or repair things).

Another example: Debian packagers added my software, source package cabextract, in 2001. When I moved its core code to a library,called libmspack in 2004, there were many more static builds and no library package until 2013, when they added a new source package libmspack. They didn't drop source package cabextract, nor do I consider it incorrectly named or its existence stealing the glory from libmspack. I release them separately as libmspack and cabextract; the former is a library with some toy usage examples, the latter is a "productised" command-line tool with its own unique features, portability and security concerns. I think unadf is similar to this. We have different perspectives.

My example shows the source package unadf can remain, independent of whether there is a another source package called adflib to package the library and other tools.

That is a completely different project. The library libmspack is basically a set of independent algorithms, simply replacable by selected single static source files. ADFlib is a library entirely dedicated for a certain purpose, and is functional only as a whole.

The fact that you treat and ship those things independently - good. I have also added here an environment that allows to do easily whatever users want and I try to build artifacts that can be immediately used, for instance, on Windows, where people might be less used for building things themselves. So I also want that people have the choice how they use provided pieces, whether you want to build utilities statically and use standalone or not. But unadf is not an independent utility, it is a single source C program which is a part of the ADFlib project, requiring ADFlib library for any operation and is developed and tested along with it. The problem is that current Debian packaging is limited to just one selected piece, and that is reflected in package naming, which, if kept when shipping all, is basically incorrect and misleading.

Contrary to your cabextract, I do not see any reason to provide unadf completely independently here, it is not a separated project, never was.

If Debian wants only unadf as before - pity, but fine. They can build statically such package as before from what is already provided. Here will be provided deb packages with everything.

In fact, I start considering this last thing as a temporal alternative - so that Debian only package static unadf as before so they can update it, and we have here still the possibility to more freely change the library, without too much hassle with compatibility management. (btw. for this we have to fix #67, as I am not releasing an utility which cannot reliably deal with command line arguments...)

Whether there needs to be a source package named adflib or not is down to choice - wait to get a new package accepted, or adopt the old one but have to keep its name. I have no concerns over that choice, I believe nobody but a few Debian maintainers ever see the source package name. I am concerned about the binary package name; I would expect to find unadf in apt-cache search because from my perspective it is the product I use. If I searched apt-cache search unadf and found no such package, but matched libadf-utils instead, I'd roll my eyes hard and note that the ADFLib marketing team had been at work.

I thought this I was clear enough - unadf goes as a separated binary package (#69), I explained why before.

For the marketing statement, if packaging of unadf binary was changed to libadf-utils providing unadf (as it was initially in unofficial packaging 0.8.0), it could be a perfectly normal evolution. You find your utility, in which binary package, it can be evolving, such things always happen (you have cases of colliding packages in Debian, providing alternatives to the same thing). Rolling eyes of one user who expects what he wants disregarding other things can be taken into account but also may not matter, if this is a better way for the whole project. Maybe for you a person trying to push the only piece he care about is not what you call marketing at all, but the trouble with package naming now is because somebody did exactly that in the past...

If I used the library I'd expect it to be in libadf1 and libadf-dev, but I wouldn't notice or care the source package name. It's not even shown to me as a user.

If you are a user that sometimes rebuild packages on your own, then you have to deal with the source packages. So this is not something only for few developers, but for any a little bit more advanced user, who will get unadf project providing libadf and libadf-utils... I am using Debian for a long time (possibly longer that you) and I haven't seen such case.

We now get these options, ordered by effort:

1. Source package `unadf` builds packages `libadf1` and `unadf`  (all binaries).

2. Source package `unadf` builds packages `libadf1`, `libadf-utils` (some binaries) and `unadf` (just unadf).

3. New source package `adflib` builds packages `libadf1`, `libadf-utils` (all binaries). Source package `unadf` builds `unadf` ( transitional package to ibadf-utils)

4. New source package `adflib` builds packages `libadf1`, `libadf-utils` (some binaries), `libadf-unadf` (just unadf). Source package `unadf` builds `unadf` (transitional package to libadf-unadf). At the next Debian release, a further transition from libadf-unadf to unadf

5. New source package `adflib` builds packages `libadf1`, `libadf-utils` (some binaries). Source package `unadf` builds `unadf` (just unadf). This approach probably does not fit with the build structure of the library packaging, as libadf and unadf do not appear to be treated or released as separate products.

6. Option 1 or 2 above, to be expeditious and avoid introducing a new source package, but decide later that it's unbearable to call the source package `unadf` so have to introduce a new source package anyway... this will, as far as I know, involve making transitional packages to temporary names for all the binary packages, and then a follow up plan for the next Debian release to transition them back to their intended names.

The most expeditious route is option 1 or 2. If name of the source package is very important, I think you should go with option 3 or 4 and spend the effort upfront, rather than option 6. My preference is either option 2 or 4, due to my binary package name preferences.

The structure of packaging should reflect in some way the structure of the project from which it comes. AFAIK, unadf was never a separated, standalone piece of software. The only thing that keeps unadf as the source package is the fact that it was for some reason packaged in this, in my opinion invalid, way. While I understand certain complications coming from changing it, I do want to know if the situation will not be much worse if we ship libadf and libadf-utils with unadf as the source and then someday will come a reflection that maybe it should be changed and it will be worse than to deal with it now. And this still is unanswered from alex, but you have answered this in point 6, thank you.

So, while I was, eventually, willing to go for what you call here 2., now I am becoming more convinced that unadf should be replaced with adflib (or libadf?) as the source package name. Otherwise the mess will spread, as I was pointing out before.

So for me point 4 would be the proper way to go.

t-w commented 7 months ago

@kyz this is another such package, started with binary only later also shipped lib: https://sources.debian.org/src/ancient/2.1.0%2Bds-1/debian/changelog/

Sorry, I do not see how this relates here. ancient is the name of the project, binary and the name of the library. There is no conflict in naming of the source package.

A similar example to ADFlib is libqcow.

t-w commented 7 months ago

you're welcome t-w#3

Thanks, but, if you do not mind, first I want to clarify here the way to go. You haven't answered my questions about started adaptation process and implications of not changing the invalid source package name while shipping more packages using it. So let's start with that.

t-w commented 7 months ago

So, I see that there is no will to discuss this further.

Personally, I am against keeping unadf as the source package name for releasing all (the library and the utilities), what, as was clearly stated before will create more inconsistency and become a lot more difficult to clean-up in the future.

However, I really do appreciate your input and help, and I do not want to dictate anything, but I do want to choose the best solution.

I would like to leave this to Laurent to state his position on this matter - so @lclevy, is it OK for you that the source package name for distributing the library and the tools in Debian (and most likely all derivatives like Ubuntu) will be unadf? It will look like @alexmyczko linked: http://sid.ethz.ch/debian/adflib/gh/ what is important there is that by getting the sources for adflib in Debian using apt-get source libadf), users will get:

unadf_0.8.0+ds-1.debian.tar.xz     
unadf_0.8.0+ds-1.dsc               
unadf_0.8.0+ds.orig.tar.xz

and the directory with the source code named:

unadf-0.8.0+ds/

As I stated, I do not like this solution as it will be complicated and more time consuming to change later than doing it properly now - but if this is OK. for you, it is OK. for me, too, and we can go on this way.

Another solution is that we postpone official releasing of the library for Debian (also, officially released, it will have to be more carefully maintained, addressing eventual issues on any platform etc.), package the things unofficially (like it was with 0.8.0), and either:

alexmyczko commented 7 months ago

Absolutely I would like to get this sorted, it's just I'm very busy this week, will reply ASAP, sorry for letting you wait... are you not on IRC somewhere, would be much easier?

alexmyczko commented 7 months ago

It's perfectly fine to have the source package of adflib as it's original name, we just have to make sure to remove unadf first though then. And after it's removal, all bugs on it get closed, we forget them (usually you re-open them), then we upload new adflib package, and wait for it to travel through new queue. We lose debian/changelog of unadf, but I guess that's not so important.

t-w commented 7 months ago

OK. Sure, no rush. (I thought you had enough of this discussion ;-)

I am glad you agree on correcting the name, I know it is more to do now, but we have less mess later, thank you for this.

Just let me know if you prefer to make a new PR yourself (to the tw/ADFlib/debian branch instead of t-w#3) or I should apply your changes myself (so that you do not have to spend more time on it...).

alexmyczko commented 7 months ago

I would not mind you doing it :)

alexmyczko commented 7 months ago

Also need to take care of this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661461

t-w commented 7 months ago

For these procedural things, I will need your guidance, as I have no experience with that...

In the meantime, I am having look into misc Debian docs, but for sure I will need steps/directions what exactly has to be done.

For dealing with bugs, this email API is used, right? ( https://www.debian.org/Bugs/server-control )

(for some things, when quick interaction is needed, maybe we can indeed meet on some IRC or whatever, but anyway I will probably need some time to look into things myself to learn and understand how to move around)

alexmyczko commented 7 months ago

basically yes. but there is also the bts cli, and this: https://github.com/alexmyczko/autoexec.bat/blob/master/deb2itp

alexmyczko commented 6 months ago

@lclevy would it be possible to tag a new release when @t-w agrees so we can continue with packaging adflib for debian?

lclevy commented 6 months ago

Yes . Please just explain me how to do this

t-w commented 6 months ago

@alexmyczko, I will tag a new release, hopefully soon. But I want to make some clean-up in some parts of the library first, as when put in debian it has to be maintained in that version for a longer time.

Concerning packaging - I had some second thoughts regarding the workflow when maintaining things and decided to move packaging specifically for debian to a separated repository, dedicated for that purpose. Debian packaging require a lot of dedicated things with its own constraints like versioning (which will be usually at least slightly different than the main project) and probably maintaining several versions (for different Debian releases etc.).

I will keep "unofficial" deb packaging in ADFlib's repo (but move to packaging/ subdirectory, to be copied when needed), but the official configuration for debian goes to the new repo.

I have prepared there some test version (in devel) how it would look like. The ADFlib is tied as a submodule and there are few scripts and a Makefile to facilite working with it (make to build, make clean to clean etc.).

If this seems reasonable, I will add some config. for github actions to build automatically.

If you have some suggestions how usually people organize this in optimal way or can point me to a project being a good example of this, I can change or improve it further.

Let me know what you think.

alexmyczko commented 4 months ago

I do not know or have example, but do you have a package to review?

alexmyczko commented 2 weeks ago

friendly ping, is there anything i can help with? it would be great to have updated adflib in debian, i guess there's time until end of year, and then about 6 months freeze until debian 13...