Tips on how to find a sponsor for an archiver

[fcorbelli]

After some work I get here

https://mentors.debian.net/package/zpaqfranz/

There are some warnings that I struggle to understand, probably because I don't understand (yet) well the Debian "rules"

Hope to find some more experienced users for a... helping hand

[Aki]

Hello,

I suppose we are off-topic in this thread. Perhaps it could be better to open a dedicated thread in the programming section of the forum.

Anyway, some hints if it can help. The output (you sent from QA page) can be locally produced by the following commands (after installing devscripts and lintian packages; using debian unstable):

Code: Select all

dget -u https://mentors.debian.net/debian/pool/main/z/zpaqfranz/zpaqfranz_55.14-1.dsc
cd zpaqfranz-55.14
debuild -uc
lintian -i --pedantic

Running lintian with -i option, it will give you explanations of its messages (as the QA page already does).

I read the descriptions of the lintian’s messages and to overcome them you can:
1) delete the file debian/compat (overridden by clausole in debian/control)
2) modify the file debian/rules (see attached file)
3) modify the file debian/control (see attached file)

The message I was not able to solve is:

Code: Select all

$ lintian --pedantic
P: zpaqfranz source: very-long-line-length-in-source-file 146793 > 512 [src/zpaqfranz.cpp:39939]

This message if caused by a *very* unusual long (146793 columns) line at row 39939 in the source code:

Code: Select all

39931 /*
39932         Section: sfx
39933         The two binaries (zsfx.exe for Windows 64 bit, and zsfx32.exe for Win32)
39934         are compressed with zpipe (from 55.14+) max compression
39935         The 32-bit is about 2/3 of the 64 (~220K vs ~320K)
39936         but slower. In fact not a big deal
39937 */
39938 #if defined(_WIN32) && (defined(_WIN64))  
39939 char zsfx_mime64[]={"N2tTdKAxg9OMsiiw03pQUQEB/wAJEAAAFwMOCA4AAgn/AwUICwMIDgQIDgUIDgYIDgcIDggIDgkEEhQDDQgODAMNCA4OAw4ID>
39940 string zsfx_hash="7537DEDC40B59AF9E8029D04D3390C2AA4EE5819E0D2CDD6467C20CDA287318C";
39941 #endif
39942 #if defined(_WIN32) && (!defined(_WIN64))  
39943 char zsfx_mime64[]={"N2tTdKAxg9OMsiiw03pQUQEB/wAJEAAAFwMOCA4AAgn/AwUICwMIDgQIDgUIDgYIDgcIDggIDgkEEhQDDQgODAMNCA4OAw4ID>
39944 string zsfx_hash="29CF5510EF6E1CCA159017D0FE101FD923499D7E0146B3F5D81CD29D3003E90C";
39945 ~#endif
39946 #if !defined(_WIN32)

It seems to me you have included binary blobs of executable files in the source code for an external program: see [1] [2].

Hope that helps.

[1] https://wiki.debian.org/EmbeddedCopies
[2] https://wiki.debian.org/UpstreamGuide

[fcorbelli]

Thank you very much
I'll make the fix asap

About the embedded exe(s) : it is a sfx module for Windows (2 in fact, 32 and 64 bit) compressed and converted by mime64 (easier notepad++ edit)
Cannot enter in Nix executable (because of ifdef)
In any case zsfx is opensource too
https://github.com/fcorbelli/zsfx
written by me 100% but not related to Debian (in fact everything not win32/win64)
I can make sfx modules (for nix) but I do not want to (embed binaries is a big no no)

But there is another thing, an embedded. Zpaq (an archive) for the autotest

Running on something "strange" (non Intel big endian) there is a function to pepare a folder with a script to check
Here
https://sourceforge.net/projects/zpaqfranz/files/55.14/

BTW
Is it possible to make a rules for big endian?
Something like
"if big endian CPU add a -DBIG in the compiler switches"
And (less important)
"if no pthread available add - DESX"?

[Aki]

Hello,

Thank you very much I'll make the fix asap

I'm happy I helped you to sort it out.

About the embedded exe(s) : it is a sfx module for Windows (2 in fact, 32 and 64 bit) compressed and converted by mime64 [..] Cannot enter in Nix executable (because of ifdef)
In any case zsfx is opensource too [..] But there is another thing, an embedded. Zpaq (an archive) for the autotest

These are some Debian's tips on the subject in the previous quote [1][2]: for example, "No inclusion of third party code" and "Source only tarball".

Is it possible to make a rules for big endian?
Something like
"if big endian CPU add a -DBIG in the compiler switches"
And (less important)
"if no pthread available add - DESX"?

Please, open a separate thread on the programming questions about the software you are packaging: this thread has a different topic.

[1] https://wiki.debian.org/UpstreamGuide
[2] https://wiki.debian.org/EmbeddedCopies

[fcorbelli]

These are some Debian's tips on the subject in the previous quote [1][2]: for example (...)

In fact no, no because "If you distribute precompiled binaries with your source code".
It is not a binary, an executable program, but an archive with pseudorandom files inside,
whose name corresponds to the hash of the file itself (in this way you can check if the extraction is correct)

Code: Select all

- 2022-08-18 16:41:13              37.037 A     00DF215A60892C8EACB0882904F35B208530CF98BD144FBF210A0285B7D66BAC
- 2022-08-18 16:41:13              37.037 A     018C10A4EA346AFA300FDD64FD35840C2E6D8667AE8958D42631DE673296DE05
- 2022-08-18 16:41:13              37.037 A     (...)

I will open a topic to ask if it is possible to download the source from github, and operate a sed on it before compiling it.
That way I wouldn't have to make two different sources, one for Debian and the other for "the rest of the world"

"No inclusion of third party code" and "Source only tarball".

Please, open a separate thread on the programming questions about the software you are packaging: this thread has a different topic.

You are right, is a rules specific question

[Aki]

Hello,

These are some Debian's tips on the subject in the previous quote [1][2]: for example (...)

In fact no, no because "If you distribute precompiled binaries with your source code".
It is not a binary, an executable program, but an archive with pseudorandom files inside,

A "binary file" is ... a "binary file", intended as the opposite of a "text file", if I recall correctly.
Therefore, both executable and data files (that are not text files) are "binary files", IMHO.

[fcorbelli]

Seems to be more a "if you embed a bugged software, then it's harder to fix bugs"
https://salsa.debian.org/security-track ... ode-copies

A "binary file" is ... a "binary file", intended as the opposite of a "text file", if I recall correctly.
Therefore, both executable and data files (that are not text files) are "binary files", IMHO.

I have just prepared a sed to trim everything from the source,

Code: Select all

sed -i -e '/DEBIANSTART/,/\/\/\/DEBIANEND/d' -e 's/\/\/\/char extract_test1/char extract_test1/g' zpaqfranz.cpp

and a warning at runtime ( zpaqfranz detect whenever the file become {"DEBIAN"} )

Code: Select all

root@debian:/zp/zpaqfranz-55.14/src# ./zpaqfranz autotest -all -to /testme
zpaqfranz v55.15i-experimental-JIT-L archiver,  (Sep  4 2022)
Self-test for correct internal functioning


33565: *** This seems Debian: sorry, cannot make FULL autotest on this platform
33566: *** You need to download the full source code from github and manually
33567: *** compile
(...)

And into the result-script

Code: Select all

(1) Sorry, no full test on Debian allowed. Download and compile source from github

This should fix Debian's concerns

It's a hassle (keeping two sources, Debian and "rest of the world") but doable

I am undecided on "mute" (in rules) a warning due to gcc bug
Actually it's not my mistake

Azz

It is recommended that packages produce bit-for-bit identical binaries even if most environment variables and build paths are varied. It is intended for this stricter standard to replace the above when it is easier for packages to meet it.

[Aki]

Seems to be more a "if you embed a bugged software, then it's harder to fix bugs"

Yes, both in cases of source and binary embedded software. IMHO, the embedding of data files in source code is inconvenient.

I have just prepared a sed to trim everything from the source,

Code: Select all

sed -i -e '/DEBIANSTART/,/\/\/\/DEBIANEND/d' -e 's/\/\/\/char extract_test1/char extract_test1/g' zpaqfranz.cpp

and a warning at runtime ( zpaqfranz detect whenever the file become {"DEBIAN"} ) [..] This should fix Debian's concerns
[..]
It's a hassle (keeping two sources, Debian and "rest of the world") but doable
[..]

The solution probably could be to include support programs in the project hierarchy in autonomous source code files (instead of including binary blobs in the main program's source code). Likewise, data files could be supplied as autonomous file in the project (outside of main program's source code), too.

The external libraries could be included in a project tree different from the main program's source code.

At build time, the building software (for example, make) could generate the main program, support programs, data file according to the target operating system (e.g. Windows, Debian, FreeBSD, others) and CPU's architecture (with its endianness).

[fcorbelli]

For a multiplatform project this will not work
On some platforms simply make does not exists at all
On others use a very different syntax

A lot of effort was needed to make a sort of "docker" (with ")
No patches, no diffs, no trouble for updating and upgrading
No dependencies, no conflict
No install or deinstall (just delete the file)

This software.can be made in 2 commands
A wget and a g++ (better with -static)
That's all

Splitting resources from the executable means to deal with absent files
Or different version, maybe incompatible, maybe corrupted

Package managers are very complex and very fragile (all of them), very ancient philosophy, maybe '80 or earlier

On Windows I develop full Delphi ERP software in a single EXE (with resources embedded)
No setup, no install, no deinstall, no diff, no patches.
No msi, fully portable, no reg config etc
---
Now I am "fighting" with time consuming details, very strange and archane config files
Just an example: if you use " in changelog once, but no" in pgp key, the automatic signing will fail
If you remove " from changelog a lot of warning is raised
So manual sign with -key is needed
Not a big deal, but wasted time

But it is very funny indeed, seems to go back when I was young in '90

[fcorbelli]

Okay, being on vacation I "exhume" the situation.

Considering that the zpaq maintainer keeps not responding at all (he surely have more important things to take care of) does anyone happen to know any active Debian developers in the archiving area?
Maybe I can try a direct contact.

On the other hand it would be useless to ask, for example, people who deal with WiFi drivers or video game porting

Thanks!

[cds60601]

You are missing one very fundamental aspect of gaining a sponsor/Mentor, and that is Time.
You MUST be willing to wait for a sponsor/Mentor. This could take a few hours or many months. It all depends on the time available that potential mentors have.
If you are impatient and not willing to follow the proper steps and formats, you will fail.
There is no rushing into things. A Mentor will ultimately be responsible for signing off on your package.
Additionally, one does not become a developer (Debian Dev) based on one package. Many have spent years and dozens of packages before being promoted to a full fledged Debian Developer.
Again, time is what is needed. If you are unwilling to play the game the way it should be played, you won't make the team.

The seemingly hurry to get a developer and to get package uploaded seems sus to me.

[fcorbelli]

You are missing one very fundamental aspect of gaining a sponsor/Mentor, and that is Time.
You MUST be willing to wait for a sponsor/Mentor. This could take a few hours or many months. It all depends on the time available that potential mentors have.
If you are impatient and not willing to follow the proper steps and formats, you will fail.
There is no rushing into things. A Mentor will ultimately be responsible for signing off on your package.
Additionally, one does not become a developer (Debian Dev) based on one package. Many have spent years and dozens of packages before being promoted to a full fledged Debian Developer.
Again, time is what is needed. If you are unwilling to play the game the way it should be played, you won't make the team.

The seemingly hurry to get a developer and to get package uploaded seems sus to me.

Well, I am waiting for 2 years, as today.
To be precise from 2021-07-18 (yep, I work on Debian package... in summertime)
Not to be accommodated, but even for a negative response

Maybe you haven't noticed that I do updates at ONE YEAR intervals, last one 2022-09-08, september 2022, not 2023
https://lists.debian.org/debian-wnpp/20 ... 00377.html


Maybe that's a short time for Debian, indeed, but I'm 50 years old, do you think before I retire I can find a Debian developer?
Is there any upper time limit?


PS I wrote an entire operating system, with vi, for AXP machines before Torvalds, Linux & Debian
It did not take me years

PS/2 You can install my package on any FreeBSD or OpenBSD system or (with brew) macOS.
It is a very normal opensource program, there are thousands worse and thousands better, in Debian.
What would be "suspect" for you?

PS/3 Of course the "last resort" will be e-mail to debian-mentors@lists.debian.org, mr. Germann is very kind
But it seems a bit... overkill

[cds60601]

You are missing one very fundamental aspect of gaining a sponsor/Mentor, and that is Time.
You MUST be willing to wait for a sponsor/Mentor. This could take a few hours or many months. It all depends on the time available that potential mentors have.
If you are impatient and not willing to follow the proper steps and formats, you will fail.
There is no rushing into things. A Mentor will ultimately be responsible for signing off on your package.
Additionally, one does not become a developer (Debian Dev) based on one package. Many have spent years and dozens of packages before being promoted to a full fledged Debian Developer.
Again, time is what is needed. If you are unwilling to play the game the way it should be played, you won't make the team.

The seemingly hurry to get a developer and to get package uploaded seems sus to me.

Well, I am waiting for 2 years, as today.
To be precise from 2021-07-18 (yep, I work on Debian package... in summertime)
Not to be accommodated, but even for a negative response

Maybe you haven't noticed that I do updates at ONE YEAR intervals, last one 2022-09-08

Maybe that's a short time for Debian, indeed, but I'm 50 years old, do you think before I retire I can find a Debian developer?
Is there any upper time limit?


PS I wrote an entire operating system, with vi, for AXP machines before Torvalds, Linux & Debian
It did not take me years

PS/2 You can install my package on any FreeBSD or OpenBSD system or (with brew) macOS.
It is a very normal opensource program, there are thousands worse and thousands better, in Debian.
What would be "suspect" for you?

PS/3 Of course the "last resort" will be e-mail to debian-mentors@lists.debian.org, mr. Germann is very kind
But it seems a bit... overkill

Your credentials really don't mean anything here. There is no timeline when a person gets excepted as a Debian Dev.
As I mentioned, sometimes it could take years. And if you are only working one package and at best, once a year, it could take longer considering there isn't much real proof of anything.
I suggest adopting a package (or many for that matter) wait for a Mentor to guide you and upload it for you. Continue to adopt packages and in time, you will get noticed.

As to being sus - anytime a person feels that they need to boast about accomplishments, usually is a red flag. And the seemingly fast pace you want this pushed as in do it now, or, how can I circumvent the natural process, that would be a 2nd red flag.
That's just me though - I tend to have a cynical point of view on humans as a whole.

There used to be a saying (perhaps still a thing) when folks were asking when is the next release of Debian? The apt answer was and probably still is, when it's ready.
Take that in consideration when wanting to pursue sponsorship.

[sunrat]

Debian Users Forum is not really an avenue for Debian developers, maintainers, or mentors. An email to the mentors mailing list would seem to me to be an obvious first place to contact.

[fcorbelli]

Debian Users Forum is not really an avenue for Debian developers, maintainers, or mentors. An email to the mentors mailing list would seem to me to be an obvious first place to contact.

Already done (1 year ago)

[fcorbelli]

You are missing one very fundamental aspect of gaining a sponsor/Mentor, and that is Time.
You MUST be willing to wait for a sponsor/Mentor. This could take a few hours or many months. It all depends on the time available that potential mentors have.
If you are impatient and not willing to follow the proper steps and formats, you will fail.
There is no rushing into things. A Mentor will ultimately be responsible for signing off on your package.
Additionally, one does not become a developer (Debian Dev) based on one package. Many have spent years and dozens of packages before being promoted to a full fledged Debian Developer.
Again, time is what is needed. If you are unwilling to play the game the way it should be played, you won't make the team.

The seemingly hurry to get a developer and to get package uploaded seems sus to me.

Well, I am waiting for 2 years, as today.
To be precise from 2021-07-18 (yep, I work on Debian package... in summertime)
Not to be accommodated, but even for a negative response

Maybe you haven't noticed that I do updates at ONE YEAR intervals, last one 2022-09-08

Maybe that's a short time for Debian, indeed, but I'm 50 years old, do you think before I retire I can find a Debian developer?
Is there any upper time limit?


PS I wrote an entire operating system, with vi, for AXP machines before Torvalds, Linux & Debian
It did not take me years

PS/2 You can install my package on any FreeBSD or OpenBSD system or (with brew) macOS.
It is a very normal opensource program, there are thousands worse and thousands better, in Debian.
What would be "suspect" for you?

PS/3 Of course the "last resort" will be e-mail to debian-mentors@lists.debian.org, mr. Germann is very kind
But it seems a bit... overkill

Your credentials really don't mean anything here. There is no timeline when a person gets excepted as a Debian Dev.
As I mentioned, sometimes it could take years. And if you are only working one package and at best, once a year, it could take longer considering there isn't much real proof of anything.
I suggest adopting a package (or many for that matter) wait for a Mentor to guide you and upload it for you. Continue to adopt packages and in time, you will get noticed.

As to being sus - anytime a person feels that they need to boast about accomplishments, usually is a red flag. And the seemingly fast pace you want this pushed as in do it now, or, how can I circumvent the natural process, that would be a 2nd red flag.
That's just me though - I tend to have a cynical point of view on humans as a whole.

There used to be a saying (perhaps still a thing) when folks were asking when is the next release of Debian? The apt answer was and probably still is, when it's ready.
Take that in consideration when wanting to pursue sponsorship.

You seem incredibly rude to me for no reason, again

If you don't have intelligent suggestions to make, I'm sure you'll find another place to enjoy yourself

[cds60601]

Topic going nowhere?

[fcorbelli]

We'll see the outcome

[cds60601]

You seem incredibly rude to me for no reason, again

If you don't have intelligent suggestions to make, I'm sure you'll find another place to enjoy yourself

If me pointing out the obvious is rude, then I'll wear that badge.
Many have tried to inform you what you must do however, you feel that's not good enough and want a "shortcut".

You don't like the answers, that's fine. Your persistence is what's being rude...

[fcorbelli]

You seem incredibly rude to me for no reason, again

If you don't have intelligent suggestions to make, I'm sure you'll find another place to enjoy yourself

If me pointing out the obvious is rude, then I'll wear that badge.
Many have tried to inform you what you must do however, you feel that's not good enough and want a "shortcut".

You don't like the answers, that's fine. Your persistence is what's being rude...

Thanks for your opinions
I emphasize yours