Re: Question about writing systemd unit for old package

[Richard Hector]

On 20/05/21 1:59 pm, Alec Leamas wrote:

Hi,

On 20/05/2021 03:35, Paul Wise wrote:

On Wed, May 19, 2021 at 8:51 AM Richard Hector wrote:


Does that not depend on whether it does anything before dropping
privileges? For example, a webserver can bind to low ports before
dropping privilege. I imagine if the systemd service unit specified
running as (eg) www-data, that wouldn't work.


I don't know the details, but I think systemd can open the ports and
transparently pass them to the unprivileged process when it is spawned
without any data loss, in a similar way to the inetd stuff used to
work.



http://0pointer.de/blog/projects/socket-activation.html


I confess I haven't read all that, and don't know the details of socket 
activation. But I think the service in question needs to be aware of it, 
doesn't it? It doesn't apply to wrapping a systemd service unit around 
an existing server. The nginx unit, for example, doesn't set a user, but 
a user is set in the nginx config file so it can drop privs.


I'm happy to be corrected :-)

Richard

Re: Resolve circular dependency of a Python package

[Andrey Rahmatullin]

On Thu, May 20, 2021 at 07:32:53AM +0200, Jan Gru wrote:
> Those are de-facto runtime dependencies, but ~pcodedmp~ is required by
> ~oletools~ to run the `python setup.py tests` during the build of oletools,
> so it is kind of a build dependency, too. I assume disabling those tests
> selectively, which require ~pcodedmp~ would be a viable solution, since the
> policy suggests to break the loop by utilizing Debian tooling [4]. Is this
> correct?
Yes, assuming it's indeed not needed for the build process.

> If so, I have a practical question about realizing it:  I consulted the
> documentation of pybuild [5] and am able to disable all tests, which might
> not be an apt solution. Therefore I tried to `export
> PYBUILD_TEST_ARGS=-k-test_to_skip` in the rules file, which should disable
> only the test(s) in question. Unfortunately this does not work as I get the
> error error:
> 
> `I: pybuild base:232: python3.9 setup.py test -k-test_to_skip [...snip...]
> error: option -k not recognized`
-k is indeed a pytest option, and the doc you used mentions that.
I'd just disable all tests.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#988923: RFS: distorm3/3.5.2b-1 -- powerful disassembler library for x86/AMD64 binary streams (Python3 bindings)

[Lin Qigang]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the orphaned package "distorm3":

 * Package name: distorm3
   Version : 3.5.2b-1
   Upstream Author : Gil Dabah 
 * URL : https://github.com/gdabah/distorm
 * License : BSD-3-Clause, GPL-3+
 * Vcs : https://salsa.debian.org/debian/distorm3
   Section : libs

It builds those binary packages:

  libdistorm3-3 - powerful disassembler library for x86/AMD64 binary streams
  libdistorm3-dev - powerful disassembler library for x86/AMD64 binary streams 
(development files)
  python3-distorm3 - powerful disassembler library for x86/AMD64 binary streams 
(Python3 bindings)

To access further information about this package, please visit the following 
URL:

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

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/d/distorm3/distorm3_3.5.2b-1.dsc

Changes since the last upload:

 distorm3 (3.5.2b-1) unstable; urgency=medium
 .
   * New upstream release.
   * Removed fix_init_python patch
   * debian/patches: Added patch to update the library version number
   * debian/*.links: Updated symbolic links to new upstream version
   * debian/not-installed: Account for varying python3 directory naming scheme
   * debian/patches: Added makefile library version fix patch
   * debian/libdistorm3-3.symbols: Updated symbols to 3.5.2b
   * debian/python3-distorm: Account for varying python3 directory naming scheme
   * debian/rules: Account for upstream build changes
   * debian/copyright: Updated packaging copyright years
   * debian/control: Updated maintainer
   * Release to unstable

Regards,
-- 

  Lin Qigang

Lin Qigang 
GPG Fingerprint:  8CAD 1250 8EE0 3A41 7223  03EC 7096 F91E D75D 028F

signature.asc
Description: OpenPGP digital signature

Re: (No Subject)

[Polyna-Maude Racicot-Summerside]

On 2021-05-21 8:25 a.m., Hunter Wittenborn wrote:
>> I'm asking myself how many package are only available in Arch and 
not
> in Debian.
> 
> Support for Arch Linux packages on Debian was a byproduct of makedeb,
> but the main goal is to just provide an alternative to the Debian source
> package format.
> 
> On the topic of Arch Linux though, makedeb (and more specifically a side
> project for it) gives support for the AUR, which has /quite/ a few
> packages not available in the Debian repos (most notably those with
> license issues).
> 
> I also use it to get some up-to-date packages from the Arch repositories
> on my Ubuntu system, which helps to avoid a ton of extra repositories
> and PPAs.
> 
I can understand your use but like I've just had a long talk on the
debian-user mailing list, building "franken-debian" cause many problem
with support.

There's one reason why Debian offer more stability over many other
distributions of Linux. It's because the review process is long and
complete, that it ensure there's not breaking change done and not subtle
bugs that arise.

So by creating a system that "only you may have" make it impossible for
other to reproduce errors you may have and leave yourself much on your own.

Everything is related to a balance between choices.
You get all the latest bell and whistles or
You get something stable and tested

> 
> Regardless of all that though, I think I got what I need to be able to
> start somewhere.
> 
> Again, thanks for the help.
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988608: RFS: scrollz/2.2.3-2 - advanced ircII-based IRC client

[Mike Markley]

On Sun, May 16, 2021 at 02:55:32PM -0600, Mike Markley  wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> I'm seeking assistance uploading a new version of the ScrollZ IRC client
> to unstable that addresses an outstanding CVE:
> https://security-tracker.debian.org/tracker/CVE-2021-29376.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986215
> 
> Changes:
>  scrollz (2.2.3-2) unstable; urgency=high
>  .
>* Applied patch to ctcp.c to fix CVE-2021-29376 from
>  https://github.com/ScrollZ/ScrollZ/pull/26 (Closes: #986215)
>* Applied minor patch from upstream to the above fix
> 
> I'm listed as the maintainer in this package's control file, but I haven't
> had a key in the keyring for several years.
> 
> This should be the minimum change required to fix this issue. I anticipate
> there will also be stable and possibly oldstable uploads, as well.
> 
> Post-freeze, I do plan to update the source package to a newer upstream
> version.

I received numerous DMARC reports indicating that this original message
wasn't delivered, so I'm quoting this entire message to highlight it, now
that I've relaxed that policy.

The package is up on https://mentors.debian.net/package/scrollz/ now.

-- 
Mike Markley 

Re: (No Subject)

[Hunter Wittenborn]

> I'm asking myself how many package are only available in Arch and not in 
>Debian.



Support for Arch Linux packages on Debian was a byproduct of makedeb, but the 
main goal is to just provide an alternative to the Debian source package format.



On the topic of Arch Linux though, makedeb (and more specifically a side 
project for it) gives support for the AUR, which has quite a few packages not 
available in the Debian repos (most notably those with license issues).



I also use it to get some up-to-date packages from the Arch repositories on my 
Ubuntu system, which helps to avoid a ton of extra repositories and PPAs.





Regardless of all that though, I think I got what I need to be able to start 
somewhere.



Again, thanks for the help.

Re: (No Subject)

[The Wanderer]

On 2021-05-21 at 07:44, Polyna-Maude Racicot-Summerside wrote:

> Hi,
> 
> On 2021-05-21 7:30 a.m., Hunter Wittenborn wrote:
> 
>>> If you want to get makedeb into Debian, then you'll need to
>>> build a Debian source package for it.

>>> If on the other hand you want to get the packages created by
>> makedeb into Debian, you're probably out of luck.

(For awareness, the above - though quoted by Hunter Wittenborn - was
actually written by me.)

> The only build system in Debian is Debian's build system based on
> .dsc source file.

In theory, it would probably be possible to have a program which takes
as input a third-party package and transforms it into a Debian source
package, then builds that into a .deb using Debian's build tools. The
resulting intermediate-step source package could then, theoretically, be
submitted for inclusion in Debian. It would be theoretically possible
for something like makedeb to be modified to use that method, rather
than producing .debs directly.

In practice this would be unlikely to produce an acceptable source-based
build (because of the "preferred form for modification" rule), so it'd
only be viable for things that would have to go into non-free because of
being opaque binary blobs to begin with - and for those I'm not sure
there'd be much benefit from such a tool. But I'm not willing to
entirely exclude it from first concepts.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: (No Subject)

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-05-21 7:30 a.m., Hunter Wittenborn wrote:
> > If you want to get makedeb into Debian, then you'll need to build
> a Debian source package for it.
> > If on the other hand you want to get the packages created by
> makedeb into Debian, you're probably out of luck.
> 
> 
The only build system in Debian is Debian's build system based on .dsc
source file.

>> The complete build system is based on a .dsc file and this does more
> than only run a gcc build on your application or package it into a
> .tar.gz file !
> 
> That and the links all make sense, I'll see what I can do.
> 

Just checked the number of package for distributions
Arch : 11 978 (based on https://archlinux.org/packages/ )
Debian : Over 20 000 (based on https://ircbots.debian.net/stats/ )

I'm asking myself how many package are only available in Arch and not in
DebianBecause if they are available in Ubuntu or whatever distro
using debian package then it's easy to compile without changes.

> Thanks,
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: (No Subject)

[Hunter Wittenborn]

> If you want to get makedeb into Debian, then you'll need to build a Debian 
> source package for it.

> If on the other hand you want to get the packages created by makedeb into 
>Debian, you're probably out of luck.





> The complete build system is based on a .dsc file and this does more than 
>only run a gcc build on your application or package it into a .tar.gz file !



That and the links all make sense, I'll see what I can do.



Thanks,

Re: (No Subject)

[Polyna-Maude Racicot-Summerside]

Hi !

On 2021-05-21 5:43 a.m., Hunter Wittenborn wrote:
> I'm continuing to look around at things - do all packages, even those in
> non-free, have to have an accompanying .dsc file to be in the Debian
> repositories?
> 

The complete build system is based on a .dsc file and this does more
than only run a gcc build on your application or package it into a
.tar.gz file !

This is what I called "Debian rules" for package :
https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html

For example the file called "watch" is used to check if you published a
new version of your software and build it if needed, all automatic.

Maybe this could be useful for you :
Prospective developer
https://www.debian.org/doc/manuals/developers-reference/beyond-pkging.en.html#interacting-with-prospective-debian-developers

New maintainer guide (1st step) :
https://www.debian.org/doc/manuals/maint-guide/first.en.html

All the stuff I already sent you and that I found just looking at the
table of content.
-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: (No Subject)

[Polyna-Maude Racicot-Summerside]

Hi !


On 2021-05-21 5:43 a.m., Hunter Wittenborn wrote:
> I'm continuing to look around at things - do all packages, even those in
> non-free, have to have an accompanying .dsc file to be in the Debian
> repositories?
> 

Like I already wrote, there's much to read before your package get
submitted. And you question is showing exactly this

You don't submit binary, you submit a source code and automatic build
machine (computer) will produce the different binaries for all the
architectures used by Debian, will do some validation, etc.

So yes a .DSC is needed as it's the basic.

Have you ever tried using dh_make ?

Have you tried compiling some package from Debian ??

Do the following :

mkdir tmp
cd tmp
apt-get source emacs
cd emacs-*
debuild

and see the magic happens.
In the end you'll get a .build file.
Open this one and look at the lines around the end of file.
You'll see some testing done against the binary package to ensure it is
compliant with the rules Debian enforced for package.

Make you shall start from there (oh yes and RTFM Debian New Maintainer
Guide / Developer).
-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988466: RFS: aspell-sl/0.60-5 -- Slovenian dictionary for GNU Aspell

[Tomaž Šolc]

On 21. 05. 21 03:17, Paul Wise wrote:
> * At this point in the freeze, the release team asks for folks to
>upload new upstream releases and other changes not targeted at
>bullseye to be uploaded to experimental instead of unstable.
> - https://release.debian.org/bullseye/freeze_policy.html

Should I wait with this package until Bullseye is released?

>  * Should doc/sl_SI.aff also be converted to UTF-8?
>  * Should doc/sl_SI.aff be installed outside /usr/share/doc?
>     - `apt-file search .aff` suggests the same location as the other files

.aff is an affix definition file. README_sl_SI.txt has (outdated)
instructions on how to use it with OpenOffice.

This exact same file is also packaged and installed into
/usr/share/hunspell by "hunspell-sl", since hunspell/Libreoffice makes
use of it.

As far as I can tell, .aff is not used or related to aspell at all. I
don't think it makes sense to install it anywhere in "aspell-sl". I
included it under /usr/share/doc only for the sake of completion.

If you think it makes more sense, I can simply drop it from the binary
package.

>  * Creating debian/clean would let you drop override_dh_clean

I like it better the way it is right now because doc-utf8 directory is
created and removed a few lines apart in d/rules. It makes it clearer
what is going on.

As far as I can tell, dh_installdocs can't automatically transcode
files, so I need the overrides.

>  * There are some lintian complaints:
>     - some of them are true and unfixable (you could override these with a
>   comment explaining the situation)
>     - at least one of them is incorrect (you could file lintian bugs)
>     - at least one of them could be fixed

Can you tell me which lintian warnings you mean? I only get:

$ lintian --version
lLintian v2.104.0~bpo10+1
$ lintian --pedantic aspell-sl_0.60+really0.50.0-1_all.deb
$ lintian --pedantic aspell-sl_0.60+really0.50.0-1.dsc
P: aspell-sl source: package-uses-old-debhelper-compat-version 12
$

debhelper-compat is 12 in Buster. I think it makes sense to make it
possible to build the package on current stable.

>  * file is not able to identify sl.cwl, any idea what format it is and
>    what tools are able to read it? (you could file a bug against file)

It's a text file compressed with "prezip" (part of aspell). You can
decompress it with "precat sl.cwl"

Best regards
Tomaž

Re: (No Subject)

[The Wanderer]

On 2021-05-21 at 05:40, Hunter Wittenborn wrote:

> 
> 
>> If yes, then try to build it from its source. Then it can be
>> published in main
> 
> 
> 
> 
>> Why are you putting the package in non-free ?
> 
>> What license did you put your software under ?
> 
> makedeb is licensed under the GPL3 license.
> 
> The goal was to be able to just distribute the binary form of the
> packages, as that's all that I get/use when I build it myself (the
> helper application, makepkg, handles all the source files, and the
> rest is just built into a binary package with makedeb itself).

So... are you trying to get makedeb into Debian, or just the packages
which makedeb creates?

If you want to get makedeb into Debian, then you'll need to build a
Debian source package for it. Since the source is GPLv3, there's no
obvious reason why it would need to go into non-free; if (as I suspect
is likely) the package formats it is capable of taking as input are
created by and are available containing software which is itself
DFSG-compliant, there's probably also no reason why it would need to go
into contrib. At that point, it would fit into main.

If on the other hand you want to get the packages created by makedeb
into Debian, you're probably out of luck. In order to get into Debian, a
package must start out in the form which is called a Debian source
package; that's the form that includes a .dsc, et cetera. From there, it
must be compiled into a .deb on the build-daemon (buildd) servers, by
the usual Debian package-build mechanisms which take source packages as
their input.

> 
> 
>> There's rule regarding GPL software and packaging that must be
>> followed...
> 
> I was looking at the following in the Debian Policy, which was
> leading me to believe it would be fine:
> 
> "The non-free archive area contains supplemental packages intended to
> work with the Debian distribution that do not comply with the DFSG or
> have other problems that make their distribution problematic."
> 
> In this case the problems would be lack of a source package. Is there
> someplace else that says GPL programs have to be distributed under
> source packages?

That would be the fact that the people who manage the Debian archive,
and I think nowadays the tooling they use to do so, will not accept
anything other than a source package as input for going into that archive.

If you want a reference link for it, [1] was the first thing I found; it
explains the reasons behind requiring a source package well enough, and
does also state that one is required for entry into the Debian archive,
although it doesn't explain why for that latter. I don't find a
reference link for that latter myself just offhand, but it's been
discussed in these mailing lists often enough.

[1]
https://wiki.debian.org/Packaging/SourcePackage#Why_bother_with_source_package_if_there_is_a_binary_package_.3F

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: (No Subject)

[Hunter Wittenborn]

I'm continuing to look around at things - do all packages, even those in 
non-free, have to have an accompanying .dsc file to be in the Debian 
repositories?

(No Subject)

[Hunter Wittenborn]

> If yes, then try to build it from its source. Then it can be published in main





> Why are you putting the package in non-free ?

> What license did you put your software under ?



makedeb is licensed under the GPL3 license.



The goal was to be able to just distribute the binary form of the packages, as 
that's all that I get/use when I build it myself (the helper application, 
makepkg, handles all the source files, and the rest is just built into a binary 
package with makedeb itself).





> There's rule regarding GPL software and packaging that must be followed...



I was looking at the following in the Debian Policy, which was leading me to 
believe it would be fine:



"The non-free archive area contains supplemental packages intended to work with 
the Debian distribution that do not comply with the DFSG or have other problems 
that make their distribution problematic."



In this case the problems would be lack of a source package. Is there someplace 
else that says GPL programs have to be distributed under source packages?





> I'd also suggest that you publish your package somewhere on a public server.



As per the repository on GitHub, I've also got a repository and a complimentary 
signing key set up. Albeit the repository itself is managed through an 
Artifactory-type program, I'm decently knowledgeable on the layout of Debian 
repositories themselves.



I do think I need to get my package set up to be compliant though, such as the 
section and priority for it, but I don't see that taking more than a few 
minutes to set everything in the control file.



Let me know if any of you have comments or feedback on anything.

Re: Question with packaging for non-free

[Mechtilde Stehmann]

Hello Hunter

Am 21.05.21 um 08:51 schrieb Hunter Wittenborn:
> Hello,
> 
> I've recently been working on a project called
> https://github.com/hwittenborn/makedeb that converts Arch Linux
> packages into Debian packages. More specifically, it takes the Arch
> Linux build format, PKGBUILDs, and uses them to make Debian
> packages.
> 
> As of recent, I've been wanting to package it for the Debian
> repositories, but makedeb itself only makes binary packages (makedeb
> is also self-building).

Do you want to have the package "makedeb" in the Debian Repo?

If yes, then try to build it from its source. Then it can be published
in main

> As a result of that, I've decided that the best course of action
> would be to publish it to the
> https://www.debian.org/doc/debian-policy/ch-archive#s-non-free, but I
> haven't been able to find where I would start for that. I've looked
> at the https://mentors.debian.net/intro-maintainers/ page, but it
> looked like the guide was written up for people creating source
> packages.
> 
> Is there anywhere I should look at, or anyone I should contact?
> 

Kind regards
-- 
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



OpenPGP_signature
Description: OpenPGP digital signature

Re: Question with packaging for non-free

[Polyna-Maude Racicot-Summerside]

Hi!

On 2021-05-21 2:51 a.m., Hunter Wittenborn wrote:
> Hello,
> 
> I've recently been working on a project called makedeb
>  that converts Arch Linux
> packages into Debian packages. More specifically, it takes the Arch
> Linux build format, PKGBUILDs, and uses them to make Debian packages.
> 
> As of recent, I've been wanting to package it for the Debian
> repositories, but makedeb itself only makes binary packages (makedeb is
> also self-building).
> 

Why are you putting the package in non-free ?
What license did you put your software under ?

There's rule regarding GPL software and packaging that must be followed...

> As a result of that, I've decided that the best course of action would
> be to publish it to the non-free archive
> , but I
> haven't been able to find where I would start for that. I've looked at
> the Debian Mentors  page,
> but it looked like the guide was written up for people creating source
> packages.
> 
> Is there anywhere I should look at, or anyone I should contact?
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: Question with packaging for non-free

[Polyna-Maude Racicot-Summerside]

Hi,


On 2021-05-21 2:51 a.m., Hunter Wittenborn wrote:
> Hello,
> 
> I've recently been working on a project called makedeb
>  that converts Arch Linux
> packages into Debian packages. More specifically, it takes the Arch
> Linux build format, PKGBUILDs, and uses them to make Debian packages.
> 
> As of recent, I've been wanting to package it for the Debian
> repositories, but makedeb itself only makes binary packages (makedeb is
> also self-building).
> 
> As a result of that, I've decided that the best course of action would
> be to publish it to the non-free archive
> , but I
> haven't been able to find where I would start for that. I've looked at
> the Debian Mentors  page,
> but it looked like the guide was written up for people creating source
> packages.
> 
> Is there anywhere I should look at, or anyone I should contact?
> 

I'd start by looking at the Debian Developer Handbook / Reference if you
already have a feet in the house.

https://www.debian.org/doc/manuals/developers-reference/index.en.html

 I doubt it's the case so I'd suggest you read the Debian New Maintainer
guide.

https://www.debian.org/doc/manuals/maint-guide/index.en.html

Now, I'll talk only on my own behalf...
Take into account that even if you software may seem pretty useful, it
doesn't mean it will make it's way into Debian distribution. At first,
maybe you shall start by getting yourself known from the community, get
to know people, this way we'll see that you are serious in what you are
doing. You are not the first one interested in giving time or having a
package integrated into the repository. And as we are all human, people
have different reason to do so. Some of them is because they want the
software to be included as it will benefit visibility for their business
in some way, some people just want to do it so they can say they did,
etc. But one thing also is that even if you have done some work, it will
require much work from other developers in the community too. Time is
scarce and rare, so there's not much interest in trying to help someone
publish a package and that the person stop doing updates or doesn't have
the knowledge to support bugs that may arise.

People don't want to end up needing to finish others work, already have
their own.

So there's the reason I say, get yourself known.

I'd also suggest that you publish your package somewhere on a public
server. You can just put the package in a folder and sign it with your
PGP key, publish the public key on a keyserver too.

This way, at first we'll get a first hard test, what will lintian say
about compliance !

As you may have noticed, some software that exist in Kali or Ubuntu will
never end up in Debian. There's a huge reason for this, all the
specifications regarding to build of packages. This way we can also
ensure that the software will build on many architectures and will be
somewhat safe (for example compile flag to protect stack smash).

Here's a start... Hope this help you out.

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988466: RFS: aspell-sl/0.60-5 -- Slovenian dictionary for GNU Aspell

[Paul Wise]

On Fri, 2021-05-21 at 08:27 +0200, Tomaž Šolc wrote:

> Should I wait with this package until Bullseye is released?

Yes, or upload to experimental now and unstable after the release.

> If you think it makes more sense, I can simply drop it from the binary
> package.

I think it makes sense to leave it out of the binary package and maybe
use sed to remove the references to it from the README file.

> I like it better the way it is right now because doc-utf8 directory is
> created and removed a few lines apart in d/rules. It makes it clearer
> what is going on.

Fair enough.

> Can you tell me which lintian warnings you mean? I only get:

No warnings, but I enable all the lintian complaints:

   $ cat ~/.lintianrc 
   info=yes
   display-info=yes
   display-experimental=yes
   pedantic=yes
   show-overrides=yes
   color=auto
   verbose=yes

Unfixable:

   I: aspell-sl source: homepage-refers-to-filesystem-listing 
https://ftp.gnu.org/gnu/aspell/dict/0index.html

   I: aspell-sl: homepage-refers-to-filesystem-listing 
https://ftp.gnu.org/gnu/aspell/dict/0index.html
   X: aspell-sl source: debian-watch-does-not-check-gpg-signature

Incorrect:

   I: aspell-sl: wrong-section-according-to-package-name aspell-sl => 
localization

Fixable (but your reasoning is fair enough):

   P: aspell-sl source: package-uses-old-debhelper-compat-version 12

Probably not fixable yet?

   X: aspell-sl source: upstream-metadata-file-is-missing


> It's a text file compressed with "prezip" (part of aspell). You can
> decompress it with "precat sl.cwl"

When I used diffoscope to compare the .dsc files, I get a big hex diff
because it doesn't know about this file format. diffoscope can convert
binary files to plain text to make for more human readable diffs. Could
you submit a feature request about allowing this for aspell cwl files?
I would do it but I guess you know more about the format/extensions.

I noticed when diffing the precat output that there has been a lot of
reordering of words, could this have any adverse effects?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Question with packaging for non-free

[Hunter Wittenborn]

Hello,



I've recently been working on a project called 
https://github.com/hwittenborn/makedeb that converts Arch Linux packages into 
Debian packages. More specifically, it takes the Arch Linux build format, 
PKGBUILDs, and uses them to make Debian packages.



As of recent, I've been wanting to package it for the Debian repositories, but 
makedeb itself only makes binary packages (makedeb is also self-building).



As a result of that, I've decided that the best course of action would be to 
publish it to the 
https://www.debian.org/doc/debian-policy/ch-archive#s-non-free, but I haven't 
been able to find where I would start for that. I've looked at the 
https://mentors.debian.net/intro-maintainers/ page, but it looked like the 
guide was written up for people creating source packages.



Is there anywhere I should look at, or anyone I should contact?