Bug#1020274: ITP: dual-function-keys -- interception plugin for generic dual function keys

[Osamu Aoki]

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

* Package name: dual-function-keys
  Version : 1.5.0
  Upstream Author : Alexander Courtis 
* URL : 
https://gitlab.com/interception/linux/plugins/dual-function-keys.git
* License : MIT
  Programming Lang: C
  Description : interception plugin for generic dual function keys

Package name above is the source package name.  The binary package is
prefixed with "interception-" in line with interception-caps2esc which
was uploaded today..

Recommends: interception-tools
Description: interception plugin for generic dual function keys
 Using dual-function-keys with interception-tools offers the flexible keyboard
 configure with dual-function capabilities under Wayland/X/Linux console.
 .
 This is a generic companion plugin program to mangle evdev data with
 interception-tools.  Basically, xmodmap-like functionality is realized
 at the kernel level in this way for arbitral keys.
 .
 If you just needs to use CapsLock key for dual function Esc/Ctrl key,
 please try the caps2esc plugin package as a starter which is simpler to
 set up.  But this dual-function-keys can configure tap and hold timing
 even for such case.

This package allows keymap customization via YAML file.
This is a part of official plugins from interception upstream.

Bug#837336: ITP: gawkextlib -- Dynamically loaded extension libraries for GNU Awk

[Raul Vidal]

Package: wnpp
Followup-For: Bug #837336
Owner: Raul Vidal 
X-Debbugs-Cc: debian-devel@lists.debian.org, raulvior@gmail.com



I'm packaging this software (first time I try to package and upload a 
piece of software). I already packaged the base library (libgawkextlib). Then I 
was going to file an ITP request and found this RFP. I was going to package 
each library into a different package. But maybe it is better to package all 
libraries 
in a single package plus -dev and -tools counterparts (gawk-xml builds xmlgawk 
binary). 
Or two packages, the base lib which provides extension infrastructure and 
another 
package for the rest of currently available libraries.

Bug#1020295: ITP: dh-puredata -- debhelper addon for building Pd externals

[Debian/GNU]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmölnig (Debian/GNU) 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: dh-puredata
  Version : 1
  Upstream Author : IOhannes m zmölnig 
* URL : * https://salsa.debian.org/multimedia-team/pd/dh-puredata
* License : GPL3+
  Programming Lang: Perl
  Description : debhelper addon for building Pd externals

This package provides the 'pd-lib-builder' Debhelper-sequence for
streamlining the process of creating Debian packages of pd-lib-builder
based externals for the Pure Data computer music language.


I intend to maintain this under the multimedia-team umbrella, along with
the other Pure Data related packages.

Re: 'The' timestamp of a snapshot of deb.debian.org

[Mattia Rizzolo]

On Sun, Sep 18, 2022 at 10:58:37AM +0200, Roland Clobus wrote:
> All of these timestamps (for sid) are close to each other, but not
> identical. I would guess that the earliest timestamp is the 'real'
> timestamp, but it is accessible (on snapshot.d.o) only with a later
> timestamp.

Consider that the archive "freezes" when it starts working on an update.
Once it finishes its job it generates the Release files, and puts the
current timestamp *inside* the file.  But then that file gets copied
around, signed, etc and that will change the timestamp.

Also, for example, I just spotted a line on IRC saying that this time
around copying the archive from the live one to archive.debian.org also
reset the mtimes...

So I really wouldn't trust mtimes in any way, only what's inside the
Release file.

What's in the trace file is IIRC the time when the archive kicks the
mirrors off, which also happens after the generation of the indexes, and
really has no business in this discussion as it's only a tool mirrors
use to coordinate and see if they are too much out of sync.
As you noticed snapshots indexes by time of the archive run, which is…
honestly I don't particularly consider it a good idea myself but that's
how the design decision went I guess.
(does it make sense to archive twice if there were two mirror pushes for
the same identical set of index files?)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Q: uscan with GitHub

[Hideki Yamane]

Hi,

 Recent changes in GitHub releases pages, I cannot check upstream version
 with uscan. How do you deal with it?



$ cat debian/watch 
version=4
https://github.com/KittyKatt/screenFetch/releases 
/KittyKatt/screenFetch/archive/refs/tags/v*@ANY_VERSION@@ARCHIVE_EXT@

$ uscan --no-download 
uscan warn: In debian/watch no matching files for watch line
  https://github.com/KittyKatt/screenFetch/releases 
/KittyKatt/screenFetch/archive/refs/tags/v*(?:[-_]?(\d[\-+\.:\~\da-zA-Z]*))(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|tar\.zstd?|zip|tgz|tbz|txz))



-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Re: Q: uscan with GitHub

[julien . puydt]

Hi,

Le lundi 19 septembre 2022 à 20:50 +0900, Hideki Yamane a écrit :
> 
>  Recent changes in GitHub releases pages, I cannot check upstream
> version with uscan. How do you deal with it?

It's not that recent ; here is a working example:

version=4
opts="\
dversionmangle=s/\+dfsg.*$//,\
filenamemangle=s/.+\/[vV]?(\d\S+)\.tar\.gz/coq-$1\.tar\.gz/,\
repack,repacksuffix=+dfsg,\
" \
https://github.com/coq/coq/tags .*/[vV]?(\d[^\s+]+)\.tar\.gz


Cheers,

J.Puydt

Re: Q: uscan with GitHub

[Samuel Thibault]

julien.pu...@gmail.com, le lun. 19 sept. 2022 18:00:37 +0200, a ecrit:
> Le lundi 19 septembre 2022 à 20:50 +0900, Hideki Yamane a écrit :
> > 
> >  Recent changes in GitHub releases pages, I cannot check upstream
> > version with uscan. How do you deal with it?
> 
> It's not that recent ; here is a working example:
> 
> version=4
> opts="\
> dversionmangle=s/\+dfsg.*$//,\
> filenamemangle=s/.+\/[vV]?(\d\S+)\.tar\.gz/coq-$1\.tar\.gz/,\
> repack,repacksuffix=+dfsg,\
> " \
> https://github.com/coq/coq/tags .*/[vV]?(\d[^\s+]+)\.tar\.gz

That works for the tags page, but not for the releases page... The
problem is that the tags page only contains snapshots of the repository,
and not an autoconf-ed tarball. For instance since recently uscan cannot
get the correct tarballs from

https://github.com/brailcom/speechd/releases

Samuel

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Vincent Lefevre]

On 2022-09-08 17:58:25 +0200, Dylan Aïssi wrote:
> We cannot talk about PipeWire without mentioning its session manager.
> Thus, this change should go along the switch of the default session manager,
> i.e. from the deprecated pipewire-media-session to WirePlumber.
> We still use pipewire-media-session as default session manager because it
> enables PipeWire *only* for screen-sharing and not for managing audio.
> Whereas WirePlumber always configures PipeWire for audio excepted by modifying
> conf files in a non-compatible packaging way. This issues was also hit on
> the Arch Linux side [4]. This WirePlumber behavior may be solved in the next
> major release 0.5 planned later this year.

In the case WirePlumber is used, what is the status of bug 998073?

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998073
  wireplumber: fails to automatically switch to headphones when connected

(which is an issue for those who use both speakers and headphones
and want to automatically switch between them). The upstream bug

  https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/267

is still open and users are still reporting problems. There is no such
issue with PA.

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

Re: Q: uscan with GitHub

[Simon McVittie]

On Mon, 19 Sep 2022 at 18:12:15 +0200, Samuel Thibault wrote:
> julien.pu...@gmail.com, le lun. 19 sept. 2022 18:00:37 +0200, a ecrit:
> > Le lundi 19 septembre 2022 à 20:50 +0900, Hideki Yamane a écrit :
> > >  Recent changes in GitHub releases pages, I cannot check upstream
> > > version with uscan. How do you deal with it?
> > 
> > version=4
> > opts="\
> > dversionmangle=s/\+dfsg.*$//,\
> > filenamemangle=s/.+\/[vV]?(\d\S+)\.tar\.gz/coq-$1\.tar\.gz/,\
> > repack,repacksuffix=+dfsg,\
> > " \
> > https://github.com/coq/coq/tags .*/[vV]?(\d[^\s+]+)\.tar\.gz
> 
> That works for the tags page, but not for the releases page... The
> problem is that the tags page only contains snapshots of the repository,
> and not an autoconf-ed tarball.

It's quite noisy and unpleasant, but here's the best I could come up with:
https://salsa.debian.org/debian/bubblewrap/-/blob/debian/latest/debian/watch
(my upstream here uses tags like v1.2.3, adjust as necessary if yours
doesn't)

or if you need to repack for DFSG reasons:
https://salsa.debian.org/sdl-team/libsdl2/-/blob/master/debian/watch
(in this case my upstream uses tags like release-1.2.3)

smcv

Re: Q: uscan with GitHub

[Andrea Pappacoda]

Il giorno lun 19 set 2022 alle 18:12:15 +02:00:00, Samuel Thibault 
 ha scritto:

That works for the tags page, but not for the releases page... The
problem is that the tags page only contains snapshots of the 
repository,
and not an autoconf-ed tarball. For instance since recently uscan 
cannot

get the correct tarballs from

https://github.com/brailcom/speechd/releases


Hi, what I usually do with GitHub is to use its API, since it has the 
advantage of not breaking uscan when they do changes to the web UI.


See 
 
for example.


In your case, as you have to download an asset and not the automatic 
tarball produced by GitHub, I'd do something like this:


   version=4
   opts="searchmode=plain, \
 
filenamemangle=s/.+\/speech-dispatcher-@any_vers...@.tar.gz/@PACKAGE@-$1\.tar\.gz/" 
\

   https://api.github.com/repos/brailcom/speechd/releases \
   
https://github.com/brailcom/speechd/releases/download/\d[\.\d]*/speech-dispatcher-@any_vers...@.tar.gz


It could probably be done in a cleaner way, but my knowledge of regular 
expressions is pretty limited :/


--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Re: Automatic trimming of changelogs in binary packages

[Bill Allombert]

Le Tue, Sep 06, 2022 at 07:13:30AM +0200, Gioele Barabucci a écrit :
> On 18/08/22 21:18, Gioele Barabucci wrote:
> > Does anybody have objective objections against activating automatic
> > changelog trimming in binary packages?
> 
> Hi,
> 
> a couple of weeks since the initial email (thanks everybody for the input),
> my reading is that there is now consensus in going ahead with the proposed
> automatic trimming of changelogs.

Count me out. changelog embbed Debian history. The very first entries
are often very important. It is much more convenient to have them as
file you can grep to that as output of some commands that depend
on network availability.

Network access is not universal.  There are better way to save diskspace.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Presenting DPKG_ROOT

[Russ Allbery]

Johannes Schauer Marin Rodrigues  writes:

> in 2016 we filed our first DPKG_ROOT patch #824594 against
> base-files. The dpkg version at the time just had included support for
> the DPKG_ROOT variable being set for maintainer scripts and we were
> excited to try out this new feature for creating foreign architecture
> chroots. At the time we thought that no discussion on d-devel was
> necessary before filing the bug because we knew only 10 source packages
> had to add DPKG_ROOT to their maintainer scripts and because doing so
> would not affect any normal installation.

[...]

Thank you for this excellent write-up!

This is exactly the type of fairly obscure Debian lore that, although it
only affects a small number of packages, is worth documenting because it
can be very difficult to understand otherwise why it's present or to debug
problems caused by accidentally breaking it.

I would therefore love to see this documented in Policy.  The
documentation doesn't have to be long, but even though this only affects a
small handful of packages used during early bootstrapping, I think we
should write it down somewhere official so that we have a record of what
we're doing and how it's supposed to work (and what packages need to care
about it).

If possible, could you write up a brief description along those lines and
open a bug against debian-policy with that description?  We can then
figure out where to put it in the document.

Thanks!

-- 
Russ Allbery (r...@debian.org)  

Re: Q: uscan with GitHub

[Paul Wise]

On Mon, 2022-09-19 at 18:54 +0200, Andrea Pappacoda wrote:

> Hi, what I usually do with GitHub is to use its API, since it has the
> advantage of not breaking uscan when they do changes to the web UI.

Since the API uses pagination, this has the minor downside of making it
harder to use the uscan --download-version option with older versions.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: Q: uscan with GitHub

[Paul Wise]

On Mon, 2022-09-19 at 20:50 +0900, Hideki Yamane wrote:

> Recent changes in GitHub releases pages, I cannot check upstream
> version with uscan. How do you deal with it?

If you are using the automatically generated tarballs, then
just switching to the uscan git mode seems like the way to go.

For signed tarballs and other GitHub release artefacts, it sounds like
uscan will need to use the GitHub API or Debian QA fakeupstream.cgi
will need to add a redirector based on the GitHub API.

https://salsa.debian.org/qa/qa/-/blob/master/cgi-bin/fakeupstream.cgi
https://qa.debian.org/cgi-bin/fakeupstream.cgi

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: Q: uscan with GitHub

[Paul Wise]

On Mon, 2022-09-19 at 18:12 +0200, Samuel Thibault wrote:

> The problem is that the tags page only contains snapshots of the
> repository, and not an autoconf-ed tarball.

I think that is an advantage, because then you can be sure that you can
rebuild the autotools generated files from source during the build.

The only reason I would use the autotools tarball is when it is signed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Re: Presenting DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Hi Russ,

Quoting Russ Allbery (2022-09-20 00:05:23)
> Johannes Schauer Marin Rodrigues  writes:
> > in 2016 we filed our first DPKG_ROOT patch #824594 against
> > base-files. The dpkg version at the time just had included support for
> > the DPKG_ROOT variable being set for maintainer scripts and we were
> > excited to try out this new feature for creating foreign architecture
> > chroots. At the time we thought that no discussion on d-devel was
> > necessary before filing the bug because we knew only 10 source packages
> > had to add DPKG_ROOT to their maintainer scripts and because doing so
> > would not affect any normal installation.
> 
> [...]
> 
> Thank you for this excellent write-up!
> 
> This is exactly the type of fairly obscure Debian lore that, although it
> only affects a small number of packages, is worth documenting because it
> can be very difficult to understand otherwise why it's present or to debug
> problems caused by accidentally breaking it.
> 
> I would therefore love to see this documented in Policy.  The
> documentation doesn't have to be long, but even though this only affects a
> small handful of packages used during early bootstrapping, I think we
> should write it down somewhere official so that we have a record of what
> we're doing and how it's supposed to work (and what packages need to care
> about it).
> 
> If possible, could you write up a brief description along those lines and
> open a bug against debian-policy with that description?  We can then
> figure out where to put it in the document.

sure thing!

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020323

Lets continue the discussion about how to best include the relevant information
into policy over there.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1020324: ITP: domdf-python-tools -- Helpful functions for Python

[Josenilson Ferreira da Silva]

Package: wnpp
Version: wnpp
Severity: wishlist
File: bug
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: domdf-python-tools
  Version : 3.4.0
  Upstream Author : Dominic Davis-Foste 
* URL : https://github.com/domdfcoding/domdf_python_tools
* License : MIT/X
  Programming Lang: Python
  Description : Helpful functions for Python

  Note:package is a dependency of this module: 
https://github.com/repo-helper/whey