Bug#1049462: dpkg-source: Ignore __pycache__ by default (was: Re: __pycache__ directories)

[Ansgar]

Package: dpkg
Severity: wishlist
X-Debbugs-Cc: Michael Biebl , debian-devel@lists.debian.org

On Mon, 2023-08-14 at 22:09 +0200, Michael Biebl wrote:
> I received a couple of bug reports against packages I (co) maintain 
> regarding this issue and having a quick look, quite a few fail due to
> python scripts being run during the build and creating a __pycache__ 
> directory.

dpkg-source already ignores various paths for the diff when building
source packages, for example ".git", ".svn", "CVS", "*~", ...

Maybe $diff_ignore_default_regex should just be extended to include
"__pycache__" as well and these would be non-issues.

Ansgar

Re: __pycache__ directories (Re: Potential MBF: packages failing to build twice in a row)

[Konstantin Demin]

I'd recommend to add in d/rules following variable:

```make
export PYTHONDONTWRITEBYTECODE=1
```

Optionally add this too:

```make
export PYTHONUNBUFFERED=1
```

Extra thing:

```make
define remove_pycache

: # $(strip $(1)): remove Python cache
find $(strip $(1))/ -name __pycache__ -type d -exec rm -rf {} +
find $(strip $(1))/ -name '*.py[co]' -ls -delete

endef
```

and then use it like this:

```make
$(call remove_pycache, $(CURDIR) )
```

ср, 16 авг. 2023 г. в 08:41, Michael Biebl :
>
> Am 16.08.23 um 06:02 schrieb Paul Wise:
> > On Mon, 2023-08-14 at 22:09 +0200, Michael Biebl wrote:
> >
> >> I received a couple of bug reports against packages I (co) maintain
> >> regarding this issue and having a quick look, quite a few fail due to
> >> python scripts being run during the build and creating a __pycache__
> >> directory.
> >
> > I recommend asking upstream to delete those directories from their VCS.
> >
>
> Those directories were created *during* build.
> They are not shipped in the VCS.



-- 
SY,
Konstantin Demin

Re: Potential MBF: packages failing to build twice in a row

[Vincent Lefevre]

On 2023-08-15 09:38:32 +0200, Lucas Nussbaum wrote:
> On 15/08/23 at 01:29 -0400, Michael Stone wrote:
> > we don't know, since the test was "regenerate source"--a thing very few
> > people care about--rather than "build twice" which is the thing people do
> > seem to care about. It seems likely that the difference is thousands of
> > packages.
> > 
> > I'm somewhat concerned we magically went from "should we do an MBF" to "I
> > just did an MBF" without any real consensus in the middle. This being so
> > painfully obvious that the MBF itself basically says there's no consensus.
> 
> I agree that the distinction between "fails to build source after
> successful build" and "fails to build binary packages after successful
> build" is useful. My initial test covered both, but I separated both
> issues later on to provide more specific bug reports, so the MBF only
> covered the first case. I also plan to do a MBF for "fails to build
> binary packages after successful build" (there are about 700 packages
> failing this).

Note that if the source has been modified, it may be possible that
the second build succeeds but is incorrect. I suppose that you need
to check that both builds are identical.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: __pycache__ directories (Re: Potential MBF: packages failing to build twice in a row)

[Luca Boccassi]

On Wed, 16 Aug 2023 at 09:43, Konstantin Demin  wrote:
>
> I'd recommend to add in d/rules following variable:
>
> ```make
> export PYTHONDONTWRITEBYTECODE=1
> ```
>
> Optionally add this too:
>
> ```make
> export PYTHONUNBUFFERED=1
> ```
>
> Extra thing:
>
> ```make
> define remove_pycache
>
> : # $(strip $(1)): remove Python cache
> find $(strip $(1))/ -name __pycache__ -type d -exec rm -rf {} +
> find $(strip $(1))/ -name '*.py[co]' -ls -delete
>
> endef
> ```
>
> and then use it like this:
>
> ```make
> $(call remove_pycache, $(CURDIR) )
> ```

Why should we do something like that by hand for every single python
source package? It doesn't make much sense. This is something that
needs to be handled in the tooling/infrastructure automatically, not
create busywork for hundreds of people.

Kind regards,
Luca Boccassi

Re: Issues in the Patch Tagging Guidelines

[Jonathan Dowland]

On Thu, Aug 10, 2023 at 03:42:03PM +0200, Lucas Nussbaum wrote:

On 08/08/23 at 01:25 +0200, Guillem Jover wrote:

  - There is a requirement for the first field to appear on the first
line, but git formatted patches start with «From ».


That's OK, since From is an alternative to Author, so it's a valid DEP3
field.


Is "From " an alternative to "Author:"? "From:" is, but Git patches are
more mbox-like with "From " (space suffixed, not colon). DEP3 seems
remarkably ambiguous on the syntax. (RFC 2822 seems fairly clear though,
only colon delimits the header field name.)


So I think that the next step would be for someone to start a draft to
update DEP3. I might do it myself at some point, but would be very happy
if someone else did it.


+1

--
Please do not CC me for listmail.

👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net

Re: Issues in the Patch Tagging Guidelines

[Guillem Jover]

Hi!

[ Started this some days ago and only finished it now, I see Jonathan has
  covered some parts of this. ]

On Thu, 2023-08-10 at 15:42:03 +0200, Lucas Nussbaum wrote:
> On 08/08/23 at 01:25 +0200, Guillem Jover wrote:
> > Lately I've been updating metadata in patches in packages I maintain and
> > noticed several issues with the Patch Tagging Guidelines, and after Lucas
> > created the new great patches UDD service [P] and we discussed some
> > other issues there, it looked like the guidelines could do with some
> > fixes and updates.
> > 
> >   [P]  also part of DMD.
> > 
> > The following list are some of the issues or things that might deserve
> > to be clarified, fixed or updated (for reference the current guidelines
> > can be found at ):
> 
> For context, there are several bugs about UDD's implementation of patch 
> parsing:
> #1028503 UDD: Unknown "yes" value for Forwarded field in patch metadata
> #1031381 UDD/dmd: Incorrectly considers patches needing work
> #1043043 UDD patches: marks Forwarded as invalid if not 'no', 'not-needed', 
> 'yes' or URL
> 
> The UDD parser of DEP3 metadata is
> https://salsa.debian.org/qa/udd/-/blob/master/rimporters/patches.rb#L163
> 
> The issues listed below fall in two categories:
> 1/ general issues about DEP3
> 2/ issues about computation of the "Forwarded" field value

> 1/ General issues about DEP3
> 
> 
> > * dpatch complicates parsing, it is deprecated, probably worth dropping
> >   support for it.
> 
> I believe this is solved: dpatch is no longer available in
> stable/testing/unstable, and we don't have any packages build-depending
> on it. There are still some patches that are dpatch-formatted but do not
> depend on dpatch-specific features, so this is not a big issue.
> 
> See:
> select source, patch from sources_patches inner join patches using (hash, 
> file)
> where release='trixie' and headers ~* 'dpatch' order by 1,2;
> => 96 source packages, 295 patches

Yes, probably unclear, my point was to drop the dpatch support from
the Patch Guidelines, precisely due to this, and because otherwise a
strictly conforming parser would need to support it as it stands.

> > * Although the guidelines seem to intend for git formatted patches to be
> >   supported, the actual specification of the format is not very clear
> >   on its usage and a strict reading does not really allow it.
> > 
> >   - There is a requirement for the first field to appear on the first
> > line, but git formatted patches start with «From ».
> 
> That's OK, since From is an alternative to Author, so it's a valid DEP3
> field.

Notice the space. Here's what a git format-patch patch looks like:

,---
From 9767e87d08803d78208464be3652a9231b6b08e3 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Thu, 10 Aug 2023 20:31:02 +0200
Subject: [PATCH] Patch description

Long explanation.
---
 test | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 test

diff --git a/test b/test
new file mode 100644
index 000..58bc469
--- /dev/null
+++ b/test
@@ -0,0 +1 @@
+Something.
-- 
2.40.1
`---

Which is not what the example looks like.

> >   - You cannot easily add custom Patch Guideline patches into the first
> > git stanza, those need to go into the git trailers in the commit
> > message, separated by whatever text is found in the description,
> > which does not follow the deb822 format.
> 
> That's OK. You can have random text before the next DEP3 headers. See
> the first example in the DEP3 specification.

Right. I guess my core issue here is that the specification mixes git
format patches with something that is deb822 formatted, which seems
like a bad idea, because even though they are close they have different
formatting. I think ideally it would state that you have to use either
format, but not mix them?

> >   - Having to store the patch guideline fields in git commit trailer
> > fields might mean these pollute the patch which might need to be
> > removed before submitting upstream.
> 
> In practice, supporting both git-formatted patches and custom-formatted
> patches was a non-issue when writing a parser.

This is an issue for developers not parsers though.

> > * For Applied-Upstream it is not easy to predict what will be the
> >   future upstream version that the patch will be included in. I've opted
> >   for stuff like «3.2.1+, commit:» when 3.2.1 is the last release,
> >   but that does not seem optimal.
> > 
> > * The git Date field could somehow be used in place of Last-Update (even
> >   though the Committer Date instead of the Author Date is what matches
> >   here more closely, but which is not available from «git format-patch»).
> 
> Yes, the UDD implementation does that.
> 
> > * Add new metadata to track single-debian-patch autogenerated patches,
> >   perhaps a new «Autogenerated: yes» or perhaps better something like
> >   «Origin: autogenerated, by:d

Bug#1049864: ITP: libopaque - Language bindings for establishing a shared secret using the OPAQUE protocol

[Joost van Baal-Ilić]

Package: wnpp
Severity: wishlist
Owner: Joost van Baal-Ilić 

* Package name: libopaque
  Version : 0.99
  Upstream Author : Stefan Marsiske and Chris Topher
* URL : https://github.com/stef/libopaque
* License : GPLv3, LGPLv3
  Programming Lang: C, JavaScript, Python, Go, PHP
  Description : Language bindings for establishing a shared secret using 
the OPAQUE protocol

 This library implements the OPAQUE protocol as proposed in the IRTF Crypto
 Forum Research Group draft (https://github.com/cfrg/draft-irtf-cfrg-opaque).
 The OPAQUE protocol combines a Oblivious Pseudo-Random Function (OPRF) and an
 Authenticated Key-Exchange (AKE) into a protocol where a user holding nothing
 but a password and a server holding some information protected by the password
 can establish a shared secret.  The library comes with bindings for js, php7,
 ruby, java, erlang, lua, python, go and SASL.


libopaque depends on liboprf, ITP Bug #1049347 .

The (yet to be packaged) Klutshnik software (https://klutshnik.info/) will
depend upon libopaque.  I will be working on this package at (yet to be created)
https://salsa.debian.org/debian/libopaque .

The libopaque project was funded through the NGI0 PET Fund, a fund established
by NLnet with financial support from the European Commission's Next Generation
Internet programme, under the aegis of DG Communications Networks, Content and
Technology under grant agreement No 825310.

Bye,

Joost

Re: groff warning: TE macro called with TW register undefined

[Hugh McMaster]

Hi Colin,

On Tue, 15 Aug 2023 at 23:55, Colin Watson wrote:
>
> On Tue, Aug 15, 2023 at 10:46:30PM +1000, Hugh McMaster wrote:
> > Lintian has recently started emitting this groff warning for ftlint.1
> > in freetype-demos as part of its man pages check:
> >
> > groff-message an.tmac::66: warning: tbl preprocessor
> > failed, or it or soelim was not run; table(s) likely not rendered (TE
> > macro called with TW register undefined)
>
> I haven't looked at your code in detail, but this sounds similar to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042358.  groff is most 
> likely observing that
> you're using the tbl macros but haven't invoked groff with -t, which
> means any warnings it issues are going to be inaccurate representations
> of how pages are actually rendered in practice.  Your starting point
> should be to add -t to the groff command line in this check, and then
> see what else shows up after that.

It is similar, yes, but unfortunately, I'm working with a hand-crafted
man page file.

Re: Issues in the Patch Tagging Guidelines

[Simon McVittie]

On Wed, 16 Aug 2023 at 12:25:13 +0200, Guillem Jover wrote:
> Here's what a git format-patch patch looks like:
> 
> ,---
> From 9767e87d08803d78208464be3652a9231b6b08e3 Mon Sep 17 00:00:00 2001
> From: Guillem Jover 
> Date: Thu, 10 Aug 2023 20:31:02 +0200

One particularly popular tool for managing debian/patches is gbp pq, which
removes the leading "From " line, and the trailing "-- " and git version,
in an effort to normalize the patch content in a way that will reduce
spurious changes when the patch series is rebased.

I think ideally the Patch Tagging Guidelines should *allow* the first line
to start with "From ", with no semantic meaning, so that maintainers of
simple packages can drop `git format-patch` output directly into
debian/patches; but should not *require* that first line, so that the
current output of `gbp pq export` is considered to be equally correct.

I personally think the extent to which git has "won", both upstream and in
Debian package maintenance, means that the Patch Tagging Guidelines should
be encouraging the git-like style as primary, with From/Date/Subject
in a header and all Debian-specific fields in a trailing pseudo-header,
the same layout that's familiar for Signed-off-by and similar tags used
by many upstream developers:

From 
From: ...
Date: ...
Subject: 





Signed-off-by: ...
Bug: https://...
Origin: vendor, Debian
Forwarded: https://...
---


That would encourage interoperability with how patches are represented and
tagged (formally or informally) in many non-Debian environments.

When interacting with developers of non-Debian-based distributions (for
example one of my $work projects is Arch-based), I'd like to be able to
point to DEP-3 and say "consider using this format" with a minimum of what
developers of the other project would consider to be weird Debianisms:
concepts like tracking whether a patch is upstreamable in principle,
and how far it has got in actually going upstream, are equally useful
for any downstream distribution. Emphasizing the familiar git-like format
in preference to deb822 would be a step in that direction.

smcv

Re: groff warning: TE macro called with TW register undefined

[Hugh McMaster]

Hi Branden,

On Wed, 16 Aug 2023 at 00:30, G. Branden Robinson wrote:
>
> Hi Hugh,
>
> I work on groff upstream.

Perfect :-)

> At 2023-08-15T22:46:30+1000, Hugh McMaster wrote:
> > groff-message an.tmac::66: warning: tbl preprocessor
> > failed, or it or soelim was not run; table(s) likely not rendered (TE
> > macro called with TW register undefined)
> >
> > It seems TW is not defined in the number register.
> >
> > While I can define TW by adding `.nr TW 0` before .TS, I don't know if
> > that's the correct solution.
>
> It is a bad idea.  The purpose of the `TW` register is defined in the
> tbl(1) man page.
>
> The register TW stores the width of the table region in basic units;
> it can’t be used within the region itself, but is defined before the
> .TE token is output so that a groff macro named TE can make use of
> it. [...]

Okay. I didn't think this approach was the solution.

> This information is necessary for macro packages that want to center
> tables, a common feature of packages _except_ those that render man
> pages.  Because forgetting to run the tbl preprocessor is a common
> error, during groff 1.23.0 development it occurred to me that I could
> use this register as an indicator.
>
> > Any ideas on fixing this warning, or is it best to ignore it for now?
>
> The diagnostic message is trying to warn you that you _probably_ forgot
> to run tbl.  But there are other causes.
>
> 1.  tbl crashed or aborted.
>
> 2.  The man(7) document embedded the beginning of table in a different
> file that it "sourced" with the `so` request, but soelim(1) was not
> run on the document.  This is valid, but not considered portable man
> page composition style.[1]
>
> 3.  A `TE` macro call is in the man page with no `TS` preceding it.
> This could arise due to clumsy editing, unfamiliarity with the
> man(7) language, or bad luck combined with inexperience (an ordinary
> text line happened to begin with `.TE` and the page author didn't
> realize that *roff would attempt to interpret that as a macro call).
>
> I tried to cover these bases in the diagnostic, but might have failed.

This all seems promising. Unfortunately, the man page is hand-crafted,
not generated from another source, so groff is never invoked, and no
other documents are referenced in the file.

AFAICT, the syntax is correct, with .TS, table content, and .TE macros
all present.

> Can you tell me what part of the message was confusing?

I woudn't say it's confusing; the message clearly states the problem
is that TW is undefined.

For me, I see more of a "chicken and egg" problem. `groff -t` needs to
be invoked to register the TW value, but the file is hand-crafted, so
groff isn't run.

> Regards,
> Branden
>
> [1] Any *roff can handle this.  So can mandoc(1)--I just found that out.
> This fact raises some interesting possibilities, since everything
> that was ever called "man2html", the original motive for
> groff_man(7)'s Portability section[2] has long gone to the dustbin.
>
> [2] In groff 1.23.0, this section is now in groff_man_style(7).

Happy 30 Years Debian Project

[Luna Jernberg]

Happy Birthday 30 years of the Debian Linux Project

https://www.gamingonlinux.com/2023/08/happy-debian-day-going-30-years-strong/
https://wiki.debian.org/DebianDay/2023
https://wiki.debian.org/DebianHistory?action=AttachFile&do=get&target=Debian-announcement-1993-pic-by-Ian_Murdock.png

Bug#1049868: ITP: ceph-tools -- utilities to manage a Ceph cluster

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: ceph-tools
  Version : 0.0.1
  Upstream Contact: Philippe Seraphin 
* URL : 
https://salsa.debian.org/openstack-team/third-party/ceph-tools
* License : Apache-2.0
  Programming Lang: bash, python
  Description : utilities to manage a Ceph cluster

 This package contains a set of utilities to help managing a Ceph cluster. It
 helps, for example:
  * managing rebalance
  * adding multiple OSD in a scheduled way
  * display the dispersion of OSD fillings

Re: Potential MBF: packages failing to build twice in a row

[Jeremy Stanley]

On 2023-08-16 11:45:43 +0800 (+0800), Paul Wise wrote:
> On Sun, 2023-08-13 at 21:18 +, Jeremy Stanley wrote:
> 
> > Similarly, I got one for __pycache__/*.cpython-311.pyc file
> > overwrites... is that something dh_python should clean?
> 
> Probably just send upstream a change removing them?

Maybe I was unclear. It's not included in the source tarballs, the
Python interpreter generates it automatically at package build time
as a side effect of being invoked.

Yes I could add bespoke clean rules to delete these autogenerated
files (it's the most straightforward approach though does mean a
package revision and bothering a sponsor as I'm not a DD), but since
a vast number of other Python-based projects' packages are also
affected it makes more sense to have debhelper/dh_python or similar
just take care of excluding it automatically so that packaging
configuration can be minimized and to avoid anyone bothering to
upload new packages just to fix this (in my case it's the only
actionable bug reported against the package in some time).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Check if config files were changed during package installation

[Олег Михайлов]

I want to create a package, which acts in the following manner:
 - If configs were not changed by dpkg during installation, restart service
immediately after installation;
 - If configs were changed by dpkg during installation, do not restart
service (either stop, or do not start).

As far as I remember, if default configs in a package differ from previous
package configs, dialogue will be shown. Can I somehow automatically check
its result during package installation process and make it a condition in
postinst (or even solve the problem via 'rules' somehow)?

__
Best Regards,
Oleg

Re: Issues in the Patch Tagging Guidelines

[Andrea Bolognani]

On Wed, Aug 16, 2023 at 12:22:33PM +0100, Simon McVittie wrote:
> I personally think the extent to which git has "won", both upstream and in
> Debian package maintenance, means that the Patch Tagging Guidelines should
> be encouraging the git-like style as primary, with From/Date/Subject
> in a header and all Debian-specific fields in a trailing pseudo-header,
> the same layout that's familiar for Signed-off-by and similar tags used
> by many upstream developers:
> 
> From 
> From: ...
> Date: ...
> Subject: 
> 
> 
> 
> 
> 
> Signed-off-by: ...
> Bug: https://...
> Origin: vendor, Debian
> Forwarded: https://...
> ---
> 

While I completely agree with everything that you've said, I will
additionally point out that a notable use of patches is backporting
upstream fixes to older package releases.

In that context, it's generally useful (best practice?) to call 'git
cherry-pick -x' on the upstream commit, which will result in git
generating a line like

  (cherry-picked from commit ...)

In that case, the patch metadata should IMO go *after* that line,
leaving the upstream commit message completely unchanged. See [1] for
an example of how that looks like in practice.

Incidentally, notice how I've had to include

  Forwarded: not-needed
  Origin: https://gitlab.com/libvirt/libvirt/-/commit/...

in order for tracker.d.o not to report this backport as a patch that
needs forwarding upstream. I feel that the presence of a
"(cherry-picked from commit ...)" line should imply at least the
first bit, but maybe there are scenarios that I haven't considered
and that make being explicit about it a necessity.


[1] 
https://salsa.debian.org/libvirt-team/libvirt/-/blob/26c4e495779fc9e7649956983818735bbc7300fd/debian/patches/backport/src-fix-max-file-limits-in-systemd-services.patch
-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Subject: Package name streamlink-twitch-gui RTP: streamlink-twitch-gui A graphical user interface on top of the Streamlink command line interface

[james smith]

Package name : streamlink-twitch-gui
Severity: RTP
Package name: streamlink-twitch-gui
Version: 0.0.27
Upstream Author: https://github.com/rustdesk/rustdesk
URL: https://streamlink.github.io/streamlink-twitch-gui/
License: MIT
Description: A graphical user interface on top of the Streamlink
 command line interface
Copyright: N/A depends=('streamlink' 'libxss' 'gtk3')
optdepends=('libpulse: Pulseaudo) source=("
https://github.com/streamlink/streamlink-twitch-gui/releases/tag/v2.3.0";
"LICENSE-$pkgver.html:
https://github.com/streamlink/streamlink-twitch-gui/blob/master/LICENSE";
"OSS-LICENSES-$pkgver.html::
https://github.com/streamlink/streamlink-twitch-gui/blob/master/LICENSE";)
sha512sums=() Please let me know if you need any more info

Package name streamlink-twitch-gui RFP: discord a modern voice & text chat app

[james smith]

Package name : streamlink-twitch-gui
Severity: RFP
Package name: streamlink-twitch-gui
Version: 0.0.27
Upstream Author: https://github.com/streamlink/streamlink-twitch-gui
URL: https://streamlink.github.io/streamlink-twitch-gui/
License: MIT
Description: A graphical user interface on top of the Streamlink
 command line interface
Copyright: N/A depends=('streamlink' 'libxss' 'gtk3')
optdepends=('libpulse: Pulseaudo) source=("
https://github.com/streamlink/streamlink-twitch-gui/releases/tag/v2.3.0";
"LICENSE-$pkgver.html:
https://github.com/streamlink/streamlink-twitch-gui/blob/master/LICENSE";
"OSS-LICENSES-$pkgver.html::
https://github.com/streamlink/streamlink-twitch-gui/blob/master/LICENSE";)
sha512sums=() Please let me know if you need any more info

Package name: streamlink-twitch-gui RFP: discord a modern voice & text chat app

[james smith]

Subject: Package name streamlink-twitch-gui RFP: discord a modern voice &
text chat app
Package name : streamlink-twitch-gui
Severity: RFP
Package name: streamlink-twitch-gui
Version: 0.0.27
Upstream Author: https://github.com/streamlink/streamlink-twitch-gui
URL: https://streamlink.github.io/streamlink-twitch-gui/
License: MIT
Description: A graphical user interface on top of the Streamlink
 command line interface
Copyright: N/A depends=('streamlink' 'libxss' 'gtk3')
optdepends=('libpulse: Pulseaudo) source=("
https://github.com/streamlink/streamlink-twitch-gui/releases/tag/v2.3.0";
"LICENSE-$pkgver.html:
https://github.com/streamlink/streamlink-twitch-gui/blob/master/LICENSE";
"OSS-LICENSES-$pkgver.html::
https://github.com/streamlink/streamlink-twitch-gui/blob/master/LICENSE";)
sha512sums=() Please let me know if you need any more info

Package name : streamlink-twitch-gui RFP: discord a modern voice & text chat app

[james smith]

Package name : streamlink-twitch-gui
Severity: RFP
Package name: streamlink-twitch-gui
Version: 0.0.27
Upstream Author: https://github.com/streamlink/streamlink-twitch-gui
URL: https://streamlink.github.io/streamlink-twitch-gui/
License: MIT
Description: A graphical user interface on top of the Streamlink
 command line interface
Copyright: N/A depends=('streamlink' 'libxss' 'gtk3')
optdepends=('libpulse: Pulseaudo) source=("
https://github.com/streamlink/streamlink-twitch-gui/releases/tag/v2.3.0";
"LICENSE-$pkgver.html:
https://github.com/streamlink/streamlink-twitch-gui/blob/master/LICENSE";
"OSS-LICENSES-$pkgver.html::
https://github.com/streamlink/streamlink-twitch-gui/blob/master/LICENSE";)
sha512sums=() Please let me know if you need any more info

Package: streamlink-twitch-gui RFP: discord a modern voice & text chat app

[james smith]

Package name : streamlink-twitch-gui
Severity: RFP
Package name: streamlink-twitch-gui
Version: 0.0.27
Upstream Author: https://github.com/streamlink/streamlink-twitch-gui
URL: https://streamlink.github.io/streamlink-twitch-gui/
License: MIT
Description: A graphical user interface on top of the Streamlink
 command line interface
Copyright: N/A depends=('streamlink' 'libxss' 'gtk3')
optdepends=('libpulse: Pulseaudo) source=("
https://github.com/streamlink/streamlink-twitch-gui/releases/tag/v2.3.0";
"LICENSE-$pkgver.html:
https://github.com/streamlink/streamlink-twitch-gui/blob/master/LICENSE";
"OSS-LICENSES-$pkgver.html::
https://github.com/streamlink/streamlink-twitch-gui/blob/master/LICENSE";)
sha512sums=() Please let me know if you have any questions

Package streamlink-twitch-gui RFP: A graphical user interface on top of the Streamlink command line interface

[james smith]

Package Subject: Package: streamlink-twitch-gui RFP: A graphical username :
streamlink-twitch-gui
Severity: RFP
Package name: streamlink-twitch-gui
Version: 0.0.27
Upstream Author: https://github.com/streamlink/streamlink-twitch-gui
URL: https://streamlink.github.io/streamlink-twitch-gui/
License: MIT
Description: A graphical user interface on top of the Streamlink
 command line interface
Copyright: N/A depends=('streamlink' 'libxss' 'gtk3')
optdepends=('libpulse: Pulseaudo) source=("
https://github.com/streamlink/streamlink-twitch-gui/releases/tag/v2.3.0";
"LICENSE-$pkgver.html:
https://github.com/streamlink/streamlink-twitch-gui/blob/master/LICENSE";
"OSS-LICENSES-$pkgver.html::
https://github.com/streamlink/streamlink-twitch-gui/blob/master/LICENSE";)
sha512sums=() Please let me know if you have any questions

Re: Happy 30 Years Debian Project

[Tuco Ramirez]

Happy Birthday Debian

By the way, thank you all who put any amount of work on Debian. 

Thank you Ian.

On August 16, 2023 11:31:35 AM UTC, Luna Jernberg  wrote:
>Happy Birthday 30 years of the Debian Linux Project
>
>https://www.gamingonlinux.com/2023/08/happy-debian-day-going-30-years-strong/
>https://wiki.debian.org/DebianDay/2023
>https://wiki.debian.org/DebianHistory?action=AttachFile&do=get&target=Debian-announcement-1993-pic-by-Ian_Murdock.png
>

Re: groff warning: TE macro called with TW register undefined

[Colin Watson]

On Wed, Aug 16, 2023 at 09:29:45PM +1000, Hugh McMaster wrote:
> This all seems promising. Unfortunately, the man page is hand-crafted,
> not generated from another source, so groff is never invoked, and no
> other documents are referenced in the file.

groff must be run somewhere, because you're seeing a warning from groff.
What exact check is failing here (is it lintian, or something else)?
Could you please give us a pointer to the man page in question?

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1049916: ITP: python-django-dynamic-fixtures -- Django app to install dynamic fixtures

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 
X-Debbugs-Cc: debian-devel@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-dynamic-fixtures
  Version : 0.2.1
  Upstream Contact: Peter Slump 
* URL : https://github.com/Peter-Slump/django-dynamic-fixtures
* License : Expat
  Programming Lang: Python
  Description : Django app to install dynamic fixtures


 Django Dynamic Fixtures is a Django app which gives you the ability to setup
 fixture-data in a more dynamic way. Static fixtures are sometimes too static in
 a way that for example even the primary keys are static defined, this can be
 very hard to maintain especially in bigger projects. Another example; when your
 application depends on data with a recent timestamp your static fixtures can
 get ‘outdated’.
 .
 Features:
  * Write fixtures in Python;
  * Load fixtures which are required for your task.
  * Manage fixture Dependencies.

I intend to maintain this as part of the DPT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmTdJ2YRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WqOiwf9EjJ+sw0WyGfrG+oTE4yfK/w2HZT0xv83
b8+EIKdNjp22NvLgnIh/lVDOrDmA5jvQxALDUWnTh9iVos4zxa9xmrNCvNgiDKHB
RrDrMoYriZPGkdgCykDu9Qf1S6wcLXL3ZGiMnm3kjno9sK5UINAVzDl3qtotPOyC
/P3uzwJIGR5/4KuX6aZ2sU01DfrWiNNN7ftzkD/IY9phaJDVF4dpUbfCwWiGx9j0
o9lFXJqjYoD9FuntY+O6WqrtlD2tEK7FJtVrKzXyd9YEoRPgjd9p+4CCUFeC0Qlo
EQBDUX1MLfMizy7Y4QZsfyzAmAcffVVmelvpGCUKh11B5Yi8ME4aHw==
=XESa
-END PGP SIGNATURE-

Bug#1049917: ITP: python-django-pgtrigger -- Write Postgres triggers for your Django models

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 
X-Debbugs-Cc: debian-devel@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-pgtrigger
  Version : 4.7.0
  Upstream Contact: Wes Kendall 
* URL : https://github.com/Opus10/django-pgtrigger
* License : BSD-3-clause
  Programming Lang: Python
  Description : Write Postgres triggers for your Django models

 django-pgtrigger helps you write Postgres triggers for your Django models.
 Triggers can solve a variety of complex problems more reliably, performantly,
 and succinctly than application code.
 .
 For example:
  * Protecting operations on rows or columns (pgtrigger.Protect).
  * Making read-only models or fields (pgtrigger.ReadOnly).
  * Soft-deleting models (pgtrigger.SoftDelete).
  * Snapshotting and tracking model changes (django-pghistory).
  * Enforcing field transitions (pgtrigger.FSM).
  * Keeping a search vector updated for full-text search
(pgtrigger.UpdateSearchVector).
  * Building official interfaces (e.g. enforcing use of User.objects.create_user
and not User.objects.create).
  * Versioning models, mirroring fields, computing unique model hashes.

I intend to maintain this as part of the DPT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmTdKBcRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WrVVAf/f5ouJAEVM938tYRGGIU6o41ho2slDKsC
6PqyxXZbR+L+hL5VLTDcu6/9EPwgyQs1h6EDwJ4gCy3jdJ9ZwmL5UZZa9am6qBCb
n1KIw2DcCOyp36hslVWZkntEBUqdCF6ebfDcZknh8X2ojyO98s1eWBIh2z/a7WjL
+A8scsD2CzjXzh80kkqGUV5zFdPMGV7C01IEorC0uzjOzpT9Sgvo+bb+cUCB2v0p
zEop4qxw6Qzm8gzEzFAiP6Ya6CbQ2uPl+7FDDuu0hl6mrBMlCuJEZbdQWquJ3b14
HnRiWaguDFFEe+8fPSdXBMDS+Hj42BqbFNgPA2QNZYr8aZrFH4272A==
=7Bql
-END PGP SIGNATURE-

Re: groff warning: TE macro called with TW register undefined

[Hugh McMaster]

On Thu, 17 Aug 2023 at 03:39, Colin Watson wrote:
>
> On Wed, Aug 16, 2023 at 09:29:45PM +1000, Hugh McMaster wrote:
> > This all seems promising. Unfortunately, the man page is hand-crafted,
> > not generated from another source, so groff is never invoked, and no
> > other documents are referenced in the file.
>
> groff must be run somewhere, because you're seeing a warning from groff.

I meant that groff is never called by FreeType's build system, as the
man page is hand-crafted.

> What exact check is failing here (is it lintian, or something else)?
> Could you please give us a pointer to the man page in question?

Lintian issues the warning when checking for man-page issues using
groff (via man). This particular warning has only appeared since the
recent groff 1.23.0 upload.

The Lintian tag is 'groff-message'. The tag description helpfully
provides the exact command used during the check:

LC_ALL=C.UTF-8 MANROFFSEQ='' MANWIDTH=80 \
man --warnings -E UTF-8 -l -Tutf8 -Z  >/dev/null

The man page in question -- ftlint.1 -- is in the freetype2-demos
package [1], or you can get an online copy from [2].

[1] /usr/share/man/man1/ftlint.1.gz
[2] 
https://sources.debian.org/src/freetype/2.13.0%2Bdfsg-1/ft2demos/man/ftlint.1/

Re: groff warning: TE macro called with TW register undefined

[Colin Watson]

On Thu, Aug 17, 2023 at 07:54:03AM +1000, Hugh McMaster wrote:
> The man page in question -- ftlint.1 -- is in the freetype2-demos
> package [1], or you can get an online copy from [2].
> 
> [1] /usr/share/man/man1/ftlint.1.gz
> [2] 
> https://sources.debian.org/src/freetype/2.13.0%2Bdfsg-1/ft2demos/man/ftlint.1/

Your problem is that you need this line as the very first line of the
page to instruct man(1) to run the tbl preprocessor:

  '\" t

See https://manpages.debian.org/bookworm/man-db/man.1.en.html#DEFAULTS.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: groff warning: TE macro called with TW register undefined

[G. Branden Robinson]

Hi Hugh,

At 2023-08-17T07:54:03+1000, Hugh McMaster wrote:
> On Thu, 17 Aug 2023 at 03:39, Colin Watson wrote:
> > On Wed, Aug 16, 2023 at 09:29:45PM +1000, Hugh McMaster wrote:
> > > This all seems promising. Unfortunately, the man page is
> > > hand-crafted, not generated from another source, so groff is never
> > > invoked, and no other documents are referenced in the file.
> >
> > groff must be run somewhere, because you're seeing a warning from
> > groff.
> 
> I meant that groff is never called by FreeType's build system, as the
> man page is hand-crafted.

Okay.  But Lintian _is_ calling groff, to format man pages and sniff out
problems with them.

So whether the man page is hand-crafted or generated from some other
format at build time is not relevant.  In fact, it's _meta_ irrelevant
(if that's even a thing) because the only reason (apart from the
validation Lintian's doing) for a source project to run groff at build
time on a man page is to generate a PDF, "cat page", or other
_formatted_ version of the man page.[1]  Examples of these are rare, but
Bash and NetHack generate cat pages, and groff itself generates a PDF
compilation of all its man pages.[2]

> > What exact check is failing here (is it lintian, or something else)?
> > Could you please give us a pointer to the man page in question?
> 
> Lintian issues the warning when checking for man-page issues using
> groff (via man). This particular warning has only appeared since the
> recent groff 1.23.0 upload.

The warning is new to groff 1.23.0.[3]

> The Lintian tag is 'groff-message'. The tag description helpfully
> provides the exact command used during the check:
> 
> LC_ALL=C.UTF-8 MANROFFSEQ='' MANWIDTH=80 \
> man --warnings -E UTF-8 -l -Tutf8 -Z  >/dev/null
> 
> The man page in question -- ftlint.1 -- is in the freetype2-demos
> package [1], or you can get an online copy from [2].

In the course of composing this message, I see that Colin covered this
point.[4]

I would also note that you can use the grog(1) command (new and improved
in groff 1.23.0![5]) to help you figure out which preprocessors (and
macro package) a *roff document needs.[6]

Let me know if this helps, or does not.

Regards,
Branden

[1] Another use case is to produce non-man-page manuals from *roff
sources using a macro package like "ms", "me", or "mm".  groff
supports all of these and it was commonly done in pre-Web days, but
it's now sadly close to a lost art.  The _Unix Time-Sharing System
Programmer's Manual Seventh Edition Volume 2_ (1979) remains
valuable reading and an example of high-quality technical writing
apply *roff to ends other than man pages.


https://archive.org/details/bitsavers_attunix7thersManualSeventhEditionVol21983_34117955/

It's particularly valuable for learning "classical Unix" tools in
their early and more easily grasped forms.  I've found that GNU
manuals, in spite of the advantages touted for Texinfo for
preparation of book-length works over mere reference guides (a.k.a.
man pages), are nevertheless often written in the style of man pages
with little effort made to give the reader a perspective from which
to integrate knowledge of the (nearly always) larger interface and
feature list of GNU replacements for Unix tools.  In other words,
they too often suffer from the same defects that the GNU Coding
Standards attribute to man pages.


https://web.archive.org/web/20041029120203/http://www.gnu.org/prep/standards/html_node/GNU-Manuals.html#GNU-Manuals

(To be fair, more recent versions of the GNU Coding Standards have
moved--slightly--in the direction of acknowledging that the
quality of the technical writing, not the formatting language used
to compose it, that is the predominant factor in production of
useful manuals.)

[2] https://www.gnu.org/software/groff/manual/groff-man-pages.pdf
[3] 
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=80ee140eb0616b794b853bbad623263cbea06abc
[4] https://lists.debian.org/debian-devel/2023/08/msg00220.html
[5] Yes, I can feel my eternal soul tumbling down several rungs in Hell
for engaging in promotion.

[6] https://man.cx/grog

I was going to link to
https://manpages.debian.org/unstable/groff/grof.1.en.html here, but
the man page is missing!  groff definitely ships it.  Any advice?


signature.asc
Description: PGP signature

Re: groff warning: TE macro called with TW register undefined

[Colin Watson]

On Wed, Aug 16, 2023 at 07:08:18PM -0500, G. Branden Robinson wrote:
> [6] https://man.cx/grog
> 
> I was going to link to
> https://manpages.debian.org/unstable/groff/grof.1.en.html here, but
> the man page is missing!  groff definitely ships it.  Any advice?

Aside from the typo in the last URL segment, the penultimate segment
identifies the binary package, and grog(1) is in the groff-base package
rather than groff.

  https://manpages.debian.org/unstable/groff-base/grog.1.en.html

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: groff warning: TE macro called with TW register undefined

[G. Branden Robinson]

At 2023-08-17T01:37:52+0100, Colin Watson wrote:
> On Wed, Aug 16, 2023 at 07:08:18PM -0500, G. Branden Robinson wrote:
> > [6] https://man.cx/grog
> > 
> > I was going to link to
> > https://manpages.debian.org/unstable/groff/grof.1.en.html here, but
> > the man page is missing!  groff definitely ships it.  Any advice?
> 
> Aside from the typo in the last URL segment, the penultimate segment
> identifies the binary package, and grog(1) is in the groff-base package
> rather than groff.

Thanks, Colin.  That explains why I also couldn't find it under
.

Upstream mentality plus a senior moment--not a good combination!

>   https://manpages.debian.org/unstable/groff-base/grog.1.en.html

Regards,
Branden


signature.asc
Description: PGP signature