Bug#1065978: Handle listxattr failures better (upstream patch 9.1.0162)

[Paul Tagliamonte]

Thanks, James!

I'm deeply grateful for your work on vim, thank you so much for
maintaining it!

  paultag


On Sun, Mar 10, 2024 at 8:17 PM James McCoy  wrote:
>
> On Sun, Mar 10, 2024 at 05:44:27PM -0400, Paul R. Tagliamonte wrote:
> > I sent a fix to upstream vim to handle a bug where vim would attempt
> > to allocate size_t max (for me, 0x aka
> > 18446744073709551615 bytes) when the filesystem responded with an
> > error on listxattr other than not supported.
> >
> > The upstream patch can be found at
> > 14759ded57447345ba11c11a99fd84344797862c[1] - I've exported that patch
> > for inclusion into sid.
>
> Thanks! I'll likely refresh against the ~latest upstream once things in
> the time_t land settle down some, so this will get pulled in then.
>
> Cheers,
> --
> James
> GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB



--
:wq

Re: Clarification for broken packages in IPv6-only environments

[Paul Tagliamonte]

On Thu, Nov 30, 2023 at 08:24:18PM +0100, Thomas Braun wrote:
> Now I would like to know if being able to run in an IPv6-only environment is
> a must have feature for any debian package?

I run an IPv6 only LAN on my home network, where I use `jool`, and
`dns64-prefix`+`unbound` to interoperate with legacy IP space. There's
no assigned IPv4 addresses for hosts on that LAN.

Most packages work fine IPv6 only -- but some things break once in a
while. Show-stopping breakage is rare and usually results in me filing a bug
report.

I have no idea what the project's stance is, but I don't regard this as
a particularly high bar, it tends to take some pretty heavy and gnarly usage
of legacy api surface to render programs show stoppingly broken.

  paultag

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Paul Tagliamonte 
  ⣾⠁⢠⠒⠀⣿⡁  https://people.debian.org/~paultag | https://pault.ag/
  ⢿⡄⠘⠷⠚⠋Debian, the universal operating system.
  ⠈⠳⣄⠀⠀  4096R / FEF2 EB20 16E6 A856 B98C  E820 2DCD 6B5D E858 ADF3


signature.asc
Description: PGP signature

Re: armhf NEON exception for chromium

[Paul Tagliamonte]

On Fri, Sep 15, 2023 at 12:18 PM Andres Salomon  wrote:
> So my proposal for chromium is this:
> a) Enable NEON for chromium's armhf build.
> b) Add a check in debian/rules for 'neon' in /proc/cpuinfo's Features: line, 
> and fail to build if NEON is not present. This should ensure that any buildds 
> or downstream builders don't waste resources configuring/building chromium on 
> a non-NEON board only to have it fail somewhere in the middle.
> c) Using the current shell script wrapper for chromium (which already checks 
> for things like SSE3 cpu instructions on x86), check for NEON support at 
> startup by also looking for the string 'neon' in /proc/cpuinfo; if NEON is 
> not supported, print an error message and exit before launching the chromium 
> binary.
> d) Ask the buildd admins to restrict building of chromium from any Armada XP 
> buildds, which appear to be the only armhf buildds left in rotation that lack 
> NEON support. If they are unwilling/unable to do this, then I'll have to play 
> the giveback game for armhf (step right up! everyone's a winner!), which I 
> often end up having to do currently because the 2-3 day armhf builds will 
> sometimes hang/crash halfway through.

This seems like a very good idea to me. I doubt anyone running
chromium on an armhf at this point would try to do so on anything that
doesn't support NEON. As a user (and developer targeting armhf) this
seems like a win for users, IMVHO.

  paultag

-- 
:wq

Bug#1051785: gdm3 won't allow logins when a smarcard with a x.509 credential is plugged in

[Paul Tagliamonte]

On Thu, Sep 14, 2023 at 11:25:57AM +0200, Raphael Hertzog wrote:
> In my case, I don't have any "smartcard development tools" (at least not
> on purpose), I just have a smartcard inserted with a single GPG key used
> for "authentication" (i.e. mainly for SSH logins).

Ahha! As do I! I removed all my tokens, and understood smartcard to mean
an x.509 credential. My Debian signing key is on Hardware as well.

> $ gpg --card-status 
> Reader ...: Alcor Micro AU9540 00 00
> Application ID ...: D276000124010201000540DD
> Application type .: OpenPGP
> Version ..: 2.1
> Manufacturer .: ZeitControl
> [...]
> Key attributes ...: rsa2048 rsa2048 rsa2048
> Max. PIN lengths .: 32 32 32
> PIN retry counter : 3 0 3
> Signature counter : 0
> Signature key : [none]
> Encryption key: [none]
> Authentication key: 1CAC 8718 CAA0 C7B9 1EC0  E907 F1CA EE10 6CE6 97F8
>   created : 2022-01-19 08:31:51

Reader ...: Yubico YubiKey FIDO CCID 00 00
Application ID ...: D276000124010201000607535263
Application type .: OpenPGP
Version ..: 2.1
Manufacturer .: Yubico
[...]
Name of cardholder: [not set]
Language prefs ...: [not set]
Salutation ...: 
URL of public key : [not set]
Login data ...: [not set]
Signature PIN : forced
Key attributes ...: rsa4096 rsa4096 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : [...]
Signature counter : [...]
Signature key : B7EC F42D DFD9 8AC7 301C  062B 1101 AD5A 8136 9AD7
  created : 2019-02-09 15:52:11

  paultag

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Paul Tagliamonte 
  ⣾⠁⢠⠒⠀⣿⡁  https://people.debian.org/~paultag | https://pault.ag/
  ⢿⡄⠘⠷⠚⠋Debian, the universal operating system.
  ⠈⠳⣄⠀⠀  4096R / FEF2 EB20 16E6 A856 B98C  E820 2DCD 6B5D E858 ADF3


signature.asc
Description: PGP signature

Bug#1051785: gdm3 won't allow logins when a smarcard with a x.509 credential is plugged in

[Paul Tagliamonte]

On Tue, Sep 12, 2023 at 05:27:15PM +0100, Simon McVittie wrote:
> On Tue, 12 Sep 2023 at 10:52:16 -0400, Paul Tagliamonte wrote:
> > I have NSS set up to talk with OpenSC
> 
> "NSS" is unfortunately ambiguous in this context. Is this the glibc Name
> Service Switch (the thing that for example libnss-systemd integrates
> with), or Mozilla's Netscape Security Services (libnss3), or some secret
> third thing also named NSS?

Ah, very sorry. libnss3.

I usually use OpenSC in the following configuration:

```
modutil -add "OpenSC" \
  -libfile /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so \
  -dbdir sql:$HOME/.pki/nssdb
```

However, when I went to confirm my notes[1] against my running system, I
found it to be in a different state (using onepin-opensc-pkcs11.so,
which is new to me):

| An aside:
|
| [1]: My notes are in the form of manpages for stuf I do infrequently but
| want to remember. Here's a markdon of the yubkey manpage when I noodle
| with using it in OpenSC mode, in case this is helpful for more
| information: https://gist.github.com/paultag/2c35b62e85a032856c2cb97345c3d24d
|
| That's from 2017, so the world has changed quite a bit, and some of it
| is bad / outdated advice, so I'd just use it to help understand likely
| system configuration than best practice -- for instance, don't use
| pkcs#11 for ssh keys anymore pls :)

Related output when using `modutil -list -dbdir sql:$HOME/.pki/nssdb`

I'm seeing a slightly different configuration (hurmm, odd):

```
  2. OpenSC smartcard framework (0.22)
library name: /usr/lib/x86_64-linux-gnu/onepin-opensc-pkcs11.so
   uri: 
pkcs11:library-manufacturer=OpenSC%20Project;library-description=OpenSC%20smartcard%20framework;library-version=0.23
 slots: 1 slot attached
status: loaded

 slot:
token:
  uri: pkcs11:
```

dpkg output from the packages I know about off the top of my head that
would be involved that aren't in the last report:

ii  opensc   0.23.0-1   
   amd64Smart card utilities with support for PKCS#15 
compatible cards
ii  opensc-pkcs11:amd64  0.23.0-1   
   amd64Smart card utilities (PKCS#11 module)
ii  libnss3:amd642:3.92-1   
   amd64Network Security Service libraries
ii  libnss3-dev:amd642:3.92-1   
   amd64Development files for the Network Security Service 
libraries
ii  libnss3-tools2:3.92-1   
   amd64Network Security Service tools
ii  libykpiv-dev:amd64   2.2.0-1.1  
   amd64Development files for the YubiKey PIV Library
ii  libykpiv2:amd64  2.2.0-1.1  
   amd64Library for communication with the YubiKey PIV 
smartcard
ii  pcscd2.0.0-1
   amd64Middleware to access a smart card using PC/SC 
(daemon side)
ii  libccid  1.5.2-1
   amd64PC/SC driver for USB CCID smart card readers

-- 
:wq


signature.asc
Description: PGP signature

Bug#1051785: gdm3 won't allow logins when a smarcard with a x.509 credential is plugged in

[Paul Tagliamonte]

Subject: gdm3 won't allow logins when a smarcard with a x.509 credential is 
plugged in
Package: gdm3
Version: 45~beta-1
Severity: important
thanks

Hey GNOME maintainers,

I upgraded my sid system, and post-upgrade gdm3 isn't showing my face
when I reboot, and entering my username causes it to loop back to
username entry again (no password prompt). After some help from smcv, I
narrowed down the issue to the interactions between my smartcard
development tools installed locally and gdm3.

The journal shows the following output:

| Sep 12 10:18:47 nyx gdm-launch-environment][1851]: 
pam_unix(gdm-launch-environment:session): session opened for user 
Debian-gdm(uid=116) by (uid=0)
| Sep 12 10:18:49 nyx gdm-smartcard][2749]: PAM unable to dlopen(pam_sss.so): 
/lib/security/pam_sss.so: cannot open shared object file: No such file or 
directory
| Sep 12 10:18:49 nyx gdm-smartcard][2749]: PAM adding faulty module: pam_sss.so
| Sep 12 10:19:02 nyx gdm-smartcard][2749]: gkr-pam: no password is available 
for user
| Sep 12 10:19:02 nyx gdm-smartcard][3505]: PAM unable to dlopen(pam_sss.so): 
/lib/security/pam_sss.so: cannot open shared object file: No such file or 
directory
| Sep 12 10:19:02 nyx gdm-smartcard][3505]: PAM adding faulty module: pam_sss.so
| Sep 12 10:19:03 nyx gdm-smartcard][3505]: gkr-pam: no password is available 
for user
| Sep 12 10:19:03 nyx gdm-smartcard][3512]: PAM unable to dlopen(pam_sss.so): 
/lib/security/pam_sss.so: cannot open shared object file: No such file or 
directory
| Sep 12 10:19:03 nyx gdm-smartcard][3512]: PAM adding faulty module: pam_sss.so
| Sep 12 10:19:33 nyx gdm-smartcard][4045]: PAM unable to dlopen(pam_sss.so): 
/lib/security/pam_sss.so: cannot open shared object file: No such file or 
directory
| Sep 12 10:19:33 nyx gdm-smartcard][4045]: PAM adding faulty module: pam_sss.so
| Sep 12 10:19:34 nyx gdm-smartcard][4045]: gkr-pam: no password is available 
for user
| Sep 12 10:19:34 nyx gdm-smartcard][4237]: PAM unable to dlopen(pam_sss.so): 
/lib/security/pam_sss.so: cannot open shared object file: No such file or 
directory
| Sep 12 10:19:34 nyx gdm-smartcard][4237]: PAM adding faulty module: pam_sss.so

(I do not have libpam-sss installed - after I got this error I installed
 it to see if I could unlock myself, but it didn't do much and I purged
 it again).

I have not configured my machine to use gdm-smartcard (nor do I want
to); but I do have a lot of smartcard stuff installed due to other hobby
work. I have NSS set up to talk with OpenSC, but that's only for TLS
keying material via GNOME, not system login.

When I unplugged my Yubikey which is both WebAuthN and a x.509
Smartcard, I was able to log in as usual.

My hunch is that I believe gdm-smartcard thinks it's supposed to kick
into gear and authenticate my smartcard, but it isn't configured to do
so (heck, it hasn't been told how to match my UPN/Email
SAN/Subject/Serial to UID, nor an x.509 CA to use for user
authentication). However, it kicking into gear has kicked me out of my
ability to login :)

I suspect the fix here is to explicitly toggle on gdm-smartcard when it's
properly configured, rather than implicitly running when the right deps
are installed and an x509 cert is found on an OpenSC token when it can't
properly authenticate it.

Fondly,
  paultag


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gdm3 depends on:
ii  accountsservice23.13.9-4
ii  adduser3.137
ii  cool-retro-term [x-terminal-emulator]  1.2.0+ds2-1+b1
ii  dbus [default-dbus-system-bus] 1.14.10-1
ii  dbus-bin   1.14.10-1
ii  dbus-daemon1.14.10-1
ii  dconf-cli  0.40.0-4
ii  dconf-gsettings-backend0.40.0-4
ii  debconf [debconf-2.0]  1.5.82
ii  foot [x-terminal-emulator] 1.15.3-1
ii  gir1.2-gdm-1.0 45~beta-1
ii  gnome-session [x-session-manager]  44.0-4
ii  gnome-session-bin  44.0-4
ii  gnome-session-common   44.0-4
ii  gnome-settings-daemon  45~rc-1
ii  gnome-shell44.4-1
ii  gnome-terminal [x-terminal-emulator]   3.49.99-1
ii  gsettings-desktop-schemas  45~rc-1
ii  libaccountsservice023.13.9-4
ii  libaudit1  1:3.1.1-1
ii  libc6  2.37-8
ii  libcanberra-gtk3-0 0.30-10
ii  libcanberra0 

Bug#1038812: ITP: sexpp -- S-expressions parser and generator C++ library and command-line tool

[Paul Tagliamonte]

On Thu, Aug 10, 2023 at 09:59:24PM +, Thorsten Alteholz wrote:
> On Thu, 10 Aug 2023, Daniel Kahn Gillmor wrote:
> > It would be great if someone on the FTP team could either accept the
> > sexpp package, or reject it with an explanation of what needs to be done
> > to fix it.
> 
> I am not going to ACCEPT a package with that name,

I agree with Thorsten (and the advice of anti-harassment team) that
weboob was a problem, and we need to remain vigilant to ensure we don't
allow things like that again.

I also know (being a Lisper) that S-Expressions (Symbolic Expressions)
are commonly abbreviated as sexprs both internal to codebase (such as
internal package names) and in user-facing documentation. There are also
similar M-Expressions (Meta Expressions). I do not believe this name is
in any way intended to be a joke, or to reference the string "sex"; this
is the only technically correct way to refer to the syntax for which
it's designed to parse.

In fact, "sexpr" is included in the codebase of libreoffice, gcc, vim,
firefox, llvm, sed, chromium, zsh, bash, grub2, along with 410 other
packages, according to codesearch.debian.net. If 'sexpr' is an issue,
we have a *lot* of work to do; on the order of "master/slave" being
slowly fixed to "primary/secondary" (or other more helpful and
descriptive terms) which will require the coordination of a *lot* of
upstreams.

> but maybe someone else from the team wants to do this.

Given that I believe that I understand the reasons behind the hold, I
have reviewed this package, and marked it for accept on my best
judgement. This package should hit sid soon. If the rest of the ftpteam
continues to disagree, we can hash it out and I can take accountability
for fixing the archive due to any actions I have taken.

  paultag

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Paul Tagliamonte 
  ⣾⠁⢠⠒⠀⣿⡁  https://people.debian.org/~paultag | https://pault.ag/
  ⢿⡄⠘⠷⠚⠋Debian, the universal operating system.
  ⠈⠳⣄⠀⠀  4096R / FEF2 EB20 16E6 A856 B98C  E820 2DCD 6B5D E858 ADF3


signature.asc
Description: PGP signature

Bug#1038812: ITP: sexpp -- S-expressions parser and generator C++ library and command-line tool

[Paul Tagliamonte]

On Thu, Aug 10, 2023 at 09:59:24PM +, Thorsten Alteholz wrote:
> On Thu, 10 Aug 2023, Daniel Kahn Gillmor wrote:
> > It would be great if someone on the FTP team could either accept the
> > sexpp package, or reject it with an explanation of what needs to be done
> > to fix it.
> 
> I am not going to ACCEPT a package with that name,

I agree with Thorsten (and the advice of anti-harassment team) that
weboob was a problem, and we need to remain vigilant to ensure we don't
allow things like that again.

I also know (being a Lisper) that S-Expressions (Symbolic Expressions)
are commonly abbreviated as sexprs both internal to codebase (such as
internal package names) and in user-facing documentation. There are also
similar M-Expressions (Meta Expressions). I do not believe this name is
in any way intended to be a joke, or to reference the string "sex"; this
is the only technically correct way to refer to the syntax for which
it's designed to parse.

In fact, "sexpr" is included in the codebase of libreoffice, gcc, vim,
firefox, llvm, sed, chromium, zsh, bash, grub2, along with 410 other
packages, according to codesearch.debian.net. If 'sexpr' is an issue,
we have a *lot* of work to do; on the order of "master/slave" being
slowly fixed to "primary/secondary" (or other more helpful and
descriptive terms) which will require the coordination of a *lot* of
upstreams.

> but maybe someone else from the team wants to do this.

Given that I believe that I understand the reasons behind the hold, I
have reviewed this package, and marked it for accept on my best
judgement. This package should hit sid soon. If the rest of the ftpteam
continues to disagree, we can hash it out and I can take accountability
for fixing the archive due to any actions I have taken.

  paultag

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Paul Tagliamonte 
  ⣾⠁⢠⠒⠀⣿⡁  https://people.debian.org/~paultag | https://pault.ag/
  ⢿⡄⠘⠷⠚⠋Debian, the universal operating system.
  ⠈⠳⣄⠀⠀  4096R / FEF2 EB20 16E6 A856 B98C  E820 2DCD 6B5D E858 ADF3


signature.asc
Description: PGP signature

Bug#1042778: RFS: fluxbox/1.3.7-1+nmu1 [NMU] [RC] -- Highly configurable and low resource X11 Window manager

[Paul Tagliamonte]

On Wed, Aug 2, 2023 at 8:04 PM Nicholas D Steeves  wrote:
> It's great to hear from you :)

tbh, I'm a bit surprised at a lot of the frustration and surprise i'm
reading - I've replied whenever I've got the email and have tried to
be helpful. It's great to be asked or sent an email, I guess?

> time and energy to review and merge Mateusz's work in the near future?

This is now the 3rd time I've offered to sponsor? Yeah. Again - please
send me an updated DSC I can review that turns it into a regular
upload -- either call it a Team Upload or a normal one and Mateusz -
you can add yourself as an Uploader, please.

I'll also say I'm lowNMU so this could have just been done without me,
but since I'd be sponsoring I don't want to sponsor a NMU against a
package I'm on the Uploaders for.

  Paul

-- 
:wq

Bug#1042778: RFS: fluxbox/1.3.7-1+nmu1 [NMU] [RC] -- Highly configurable and low resource X11 Window manager

[Paul Tagliamonte]

On Wed, Aug 2, 2023 at 8:04 PM Nicholas D Steeves  wrote:
> It's great to hear from you :)

tbh, I'm a bit surprised at a lot of the frustration and surprise i'm
reading - I've replied whenever I've got the email and have tried to
be helpful. It's great to be asked or sent an email, I guess?

> time and energy to review and merge Mateusz's work in the near future?

This is now the 3rd time I've offered to sponsor? Yeah. Again - please
send me an updated DSC I can review that turns it into a regular
upload -- either call it a Team Upload or a normal one and Mateusz -
you can add yourself as an Uploader, please.

I'll also say I'm lowNMU so this could have just been done without me,
but since I'd be sponsoring I don't want to sponsor a NMU against a
package I'm on the Uploaders for.

  Paul

-- 
:wq

Bug#1042778: RFS: fluxbox/1.3.7-1+nmu1 [NMU] [RC] -- Highly configurable and low resource X11 Window manager

[Paul Tagliamonte]

I /am/ one of the package maintainers :)

On Wed, Aug 2, 2023, 6:37 PM Tong Sun  wrote:

> Retry for Paul.
>
> The NMU is not from me but Mateusz.
>
> Hope you'll be a DM soon @Mateusz, but meanwhile, I concur with Paul,
> don't do NMU, be the package owner and do a normal maintainer upload
> @Mateusz, as you cans see from
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927477 that the
> package owner stop responding to people more than 5 years ago.
>
> @Paul, no hurry, take your time, as we've been waiting for more than 8
> years, 
>
> cheers
>
> On Wed, Aug 2, 2023 at 6:25 PM Paul Tagliamonte - paul...@debian.org
> wrote:
> >
> > Happy to review - why a NMU? Let's make it a team upload or you're
> welcome to join as an uploader!
> >
> > I don't see the bug on CC, but please feel free to re add it on your
> reply
> >
> > I'll see about reviewing this later today, but I'd prefer to have this
> be a normal maintainer upload :)
> >
> > Paul
> >
> > On Wed, Aug 2, 2023, 6:20 PM Tong Sun  wrote:
> >>
> >> Thanks Mateusz.
> >>
> >> Seeing that your previous NMU 1.3.5-2.1 upload got unnoticed, I'm just
> trying to stir up some noise to get you more traction.
> >>
> >> CCing Paul who offered me help last time when I attempted it.
> >>
> >> Thanks everyone!
> >>
> >> On Mon, Jul 31, 2023 at 4:46 PM Mateusz Łukasik - mat...@linuxmint.pl
> wrote:
> >>>
> >>> Package: sponsorship-requests
> >>> Severity: important
> >>>
> >>> Dear mentors,
> >>>
> >>> I am looking for a sponsor for my package "fluxbox":
> >>>
> >>>  * Package name : fluxbox
> >>>Version  : 1.3.7-1+nmu1
> >>>Upstream contact : fluxbox maintainers
> >>>  * URL  : https://fluxbox.org
> >>>  * License  : CC-BY-SA-3, Expat
> >>>  * Vcs  : [fill in URL of packaging vcs]
> >>>Section  : x11
> >>>
> >>> The source builds the following binary packages:
> >>>
> >>>   fluxbox - Highly configurable and low resource X11 Window manager
> >>>
> >>> To access further information about this package, please visit the
> following URL:
> >>>
> >>>   https://mentors.debian.net/package/fluxbox/
> >>>
> >>> Alternatively, you can download the package with 'dget' using this
> command:
> >>>
> >>>   dget -x
> https://mentors.debian.net/debian/pool/main/f/fluxbox/fluxbox_1.3.7-1+nmu1.dsc
> >>>
> >>> Changes since the last upload:
> >>>
> >>>  fluxbox (1.3.7-1+nmu1) unstable; urgency=medium
> >>>  .
> >>>* Non-maintainer upload. (See #927477)
> >>>* Upload to unstable, latest upstream version stuck in experimental
> for
> >>>  8 years. (Closes: #969440 #987223)
> >>>* Merge my changes for NMU 1.3.5-2.1. (Closes: #943578)
> >>>* Drop depends on deprecated GTK 2. No longer used. (Closes:
> #967345)
> >>>* Add debian/patches/fix_ld_ftbfs.patch from upstream for fix FTBFS
> with
> >>>  build-system: fix "make check".
> >>>* Bump dh version to 13.
> >>>* Bump Standards-Version to 4.6.2.
> >>>* Add debian/patches/replace_FbRootWindow_depth_with_maxDepth.patch
> for
> >>>  replace FbRootWindow::depth with maxDepth. (Closes: #1003798)
> >>>
> >>> Regards,
> >>> --
> >>>   Mateusz Łukasik
> >>>
> >>>
>

Bug#1042778: RFS: fluxbox/1.3.7-1+nmu1 [NMU] [RC] -- Highly configurable and low resource X11 Window manager

[Paul Tagliamonte]

I /am/ one of the package maintainers :)

On Wed, Aug 2, 2023, 6:37 PM Tong Sun  wrote:

> Retry for Paul.
>
> The NMU is not from me but Mateusz.
>
> Hope you'll be a DM soon @Mateusz, but meanwhile, I concur with Paul,
> don't do NMU, be the package owner and do a normal maintainer upload
> @Mateusz, as you cans see from
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927477 that the
> package owner stop responding to people more than 5 years ago.
>
> @Paul, no hurry, take your time, as we've been waiting for more than 8
> years, 
>
> cheers
>
> On Wed, Aug 2, 2023 at 6:25 PM Paul Tagliamonte - paul...@debian.org
> wrote:
> >
> > Happy to review - why a NMU? Let's make it a team upload or you're
> welcome to join as an uploader!
> >
> > I don't see the bug on CC, but please feel free to re add it on your
> reply
> >
> > I'll see about reviewing this later today, but I'd prefer to have this
> be a normal maintainer upload :)
> >
> > Paul
> >
> > On Wed, Aug 2, 2023, 6:20 PM Tong Sun  wrote:
> >>
> >> Thanks Mateusz.
> >>
> >> Seeing that your previous NMU 1.3.5-2.1 upload got unnoticed, I'm just
> trying to stir up some noise to get you more traction.
> >>
> >> CCing Paul who offered me help last time when I attempted it.
> >>
> >> Thanks everyone!
> >>
> >> On Mon, Jul 31, 2023 at 4:46 PM Mateusz Łukasik - mat...@linuxmint.pl
> wrote:
> >>>
> >>> Package: sponsorship-requests
> >>> Severity: important
> >>>
> >>> Dear mentors,
> >>>
> >>> I am looking for a sponsor for my package "fluxbox":
> >>>
> >>>  * Package name : fluxbox
> >>>Version  : 1.3.7-1+nmu1
> >>>Upstream contact : fluxbox maintainers
> >>>  * URL  : https://fluxbox.org
> >>>  * License  : CC-BY-SA-3, Expat
> >>>  * Vcs  : [fill in URL of packaging vcs]
> >>>Section  : x11
> >>>
> >>> The source builds the following binary packages:
> >>>
> >>>   fluxbox - Highly configurable and low resource X11 Window manager
> >>>
> >>> To access further information about this package, please visit the
> following URL:
> >>>
> >>>   https://mentors.debian.net/package/fluxbox/
> >>>
> >>> Alternatively, you can download the package with 'dget' using this
> command:
> >>>
> >>>   dget -x
> https://mentors.debian.net/debian/pool/main/f/fluxbox/fluxbox_1.3.7-1+nmu1.dsc
> >>>
> >>> Changes since the last upload:
> >>>
> >>>  fluxbox (1.3.7-1+nmu1) unstable; urgency=medium
> >>>  .
> >>>* Non-maintainer upload. (See #927477)
> >>>* Upload to unstable, latest upstream version stuck in experimental
> for
> >>>  8 years. (Closes: #969440 #987223)
> >>>* Merge my changes for NMU 1.3.5-2.1. (Closes: #943578)
> >>>* Drop depends on deprecated GTK 2. No longer used. (Closes:
> #967345)
> >>>* Add debian/patches/fix_ld_ftbfs.patch from upstream for fix FTBFS
> with
> >>>  build-system: fix "make check".
> >>>* Bump dh version to 13.
> >>>* Bump Standards-Version to 4.6.2.
> >>>* Add debian/patches/replace_FbRootWindow_depth_with_maxDepth.patch
> for
> >>>  replace FbRootWindow::depth with maxDepth. (Closes: #1003798)
> >>>
> >>> Regards,
> >>> --
> >>>   Mateusz Łukasik
> >>>
> >>>
>

Bug#1041868: Include patch fixing SNDRV_PCM_IOCTL_SW_PARAMS ioctl on src/pcm/pcm_hw.c

[Paul Tagliamonte]

severity 1041868 important
thanks

Hey pkg-alsa-devel,

Due to my fat-fingering the submit email, the submission of this bug
never hit the ALSA mailing lists. Apologies for the aggressive (in
wallclock time) ping, but I don't think folks here actually saw this. My
control messages came through but not the bug itself.

After sleeping on it I believe this bug is 'important' not 'normal'
because it renders another bit of software unusable (src:direwolf) even
though alsa works fine most of the time, I've adjusted the severity; but
I'm open to having the severity changed.

I'd very much like to land this patch -- it's very short, and attached
to the bug report. The diff is a single char (although single char
changes tend to be the most conceptually hard to reason about), and the
patch was taken from the upstream repo. I'm worried about this bug
propagating out via derivitives, so I'd love to see if we can apply the
patch attached to the bug.

Here's the tl;dr of the patch:

```src/pcm/pcm_hw.c:
-   if (ioctl(hw->fd, SNDRV_PCM_IOCTL_SW_PARAMS, sw_params) < 0) {
+   if (ioctl(hw->fd, SNDRV_PCM_IOCTL_SW_PARAMS, _params) < 0) {
```

I believe this was introduced in alsa-lib 1.2.9, so this is only about a
month old -- and I'd love to stop this from spreading out from sid. It's
already pulled into mantic, and I'm not sure where else.

Thank you for maintaining alsa!
  paultag

-- 
  ⢀⣴⠾⠻⢶⣦⠀       Paul Tagliamonte 
  ⣾⠁⢠⠒⠀⣿⡁  https://people.debian.org/~paultag | https://pault.ag/
  ⢿⡄⠘⠷⠚⠋Debian, the universal operating system.
  ⠈⠳⣄⠀⠀  4096R / FEF2 EB20 16E6 A856 B98C  E820 2DCD 6B5D E858 ADF3


signature.asc
Description: PGP signature

Bug#1041868: Include patch fixing SNDRV_PCM_IOCTL_SW_PARAMS ioctl on src/pcm/pcm_hw.c

[Paul Tagliamonte]

Package: alsa-libs
Severity: normal
Version: 1.2.9-1
Tags: patch

Howdy, ALSA team!

I had some unrelated software (src:direwolf) break on me, which turns
out is a bug in ALSA.

Commit 2115cdb4dc314d66e92a9e04413bcedc543da007 (first part of 1.2.9
AFAICT) introduced a change to src/pcm/pcm_hw.c where sw_params is
passed by value rather than as a pointer in the ioctl call. Whoopsies.

This means for users of specific hardware (I am one such person!), ALSA
was returnning bad address (well, ALSA was returning the kernel being
grumpy) which horked writing audio to ALSA.

I took the attached patch from the upstream repo
(commit a5d8af8e4ef02340531092ea388dd1b668182409) and rebuilt alsa-libs.
This fixes the issue that presented with my hardware, and I was able to
transmit normally.

Thanks to Dan Cross for the fix

  paultag

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Paul Tagliamonte 
  ⣾⠁⢠⠒⠀⣿⡁  https://people.debian.org/~paultag | https://pault.ag/
  ⢿⡄⠘⠷⠚⠋Debian, the universal operating system.
  ⠈⠳⣄⠀⠀  4096R / FEF2 EB20 16E6 A856 B98C  E820 2DCD 6B5D E858 ADF3
From a5d8af8e4ef02340531092ea388dd1b668182409 Mon Sep 17 00:00:00 2001
From: Dan Cross 
Date: Wed, 14 Jun 2023 21:09:10 +
Subject: [PATCH] pcm: fix minor bug in ioctl

Commit 2115cdb added a new call to the `SNDRV_PCM_IOCTL_SW_PARAMS`
ioctl on line 675 of src/pcm/pcm_hw.c, but passed the `sw_params`
argument by value; this should be passed by pointer.

I ran across this in the context of the direwolf software modem
for amateur radio; debugging details are in
https://groups.io/g/direwolf/message/8286

Fixes #329

Signed-off-by: Dan Cross 
---
 src/pcm/pcm_hw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/pcm/pcm_hw.c b/src/pcm/pcm_hw.c
index b468a071..f488023a 100644
--- a/src/pcm/pcm_hw.c
+++ b/src/pcm/pcm_hw.c
@@ -672,7 +672,7 @@ static int snd_pcm_hw_prepare(snd_pcm_t *pcm)
 
if (hw->prepare_reset_sw_params) {
snd_pcm_sw_params_current_no_lock(pcm, _params);
-   if (ioctl(hw->fd, SNDRV_PCM_IOCTL_SW_PARAMS, sw_params) < 0) {
+   if (ioctl(hw->fd, SNDRV_PCM_IOCTL_SW_PARAMS, _params) < 0) {
err = -errno;
SYSMSG("SNDRV_PCM_IOCTL_SW_PARAMS failed (%i)", err);
return err;


signature.asc
Description: PGP signature

Bug#1041858: ITP: tundra-nat64 -- A minimal, user-space, stateless NAT64, CLAT and SIIT implementation for Linux

[Paul Tagliamonte]

On Mon, Jul 24, 2023 at 04:16:52PM +0200, Daniel Gröber wrote:
> Stateless IP/ICMP translation (SIIT), Stateful NAT64 and [CLAT]
> are important mechnisms to pave the way to an IPv6-only future. I've
> found the tools we currently have in Debian to provide and use these
> services, Tayga and Jool, lacking in various respects.

As a current jool user, I'm very interested in this project. I'll have
to try this out.

> Tayga has major performance problems due to being single-threaded and
> comes nowhere near to even measily 100Mbit forwarding on modern
> hardware but it currently is the only viable way to implement [CLAT]
> on Debian.
> 
> [CLAT]: Is the client-side of a 464XLAT setup. This is used to support
> applications using IPv4 literals on top of an IPv6-only access network.
> 
> Jool being an out-of-tree kernel module has to employ various kernel
> hacks to get it's job done that lead to all kinds of jankyness. It's
> reasonably fast though, so it's more suited for deployment as a
> network service. Unfortunately the upstream project is in "maintanance
> only" mode so my concern is it may get abandoned at some point.

Same :)

> Hence we need more alternatives for these services in Debian.
> 
> tundra-nat64 is a new userspace implementation of SIIT, NAT64 and
> [CLAT]. It's multithreaded as opposed to tayga so my hope is the
> performance will be much better.
> 
> I plan on maintaining tuntra-nat64 myself but I do need a sponsor :)

Why the heck not, I'm happy to review and sponsor; IPv6 adoption is
critical, and giving a hand to someone working to maintain current
tooling to help with the adoption is doing good work. Hit me up off-list
and we'll work out a workflow and all that.

  paultag

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Paul Tagliamonte 
  ⣾⠁⢠⠒⠀⣿⡁  https://people.debian.org/~paultag | https://pault.ag/
  ⢿⡄⠘⠷⠚⠋Debian, the universal operating system.
  ⠈⠳⣄⠀⠀  4096R / FEF2 EB20 16E6 A856 B98C  E820 2DCD 6B5D E858 ADF3

Bug#1041858: ITP: tundra-nat64 -- A minimal, user-space, stateless NAT64, CLAT and SIIT implementation for Linux

[Paul Tagliamonte]

On Mon, Jul 24, 2023 at 04:16:52PM +0200, Daniel Gröber wrote:
> Stateless IP/ICMP translation (SIIT), Stateful NAT64 and [CLAT]
> are important mechnisms to pave the way to an IPv6-only future. I've
> found the tools we currently have in Debian to provide and use these
> services, Tayga and Jool, lacking in various respects.

As a current jool user, I'm very interested in this project. I'll have
to try this out.

> Tayga has major performance problems due to being single-threaded and
> comes nowhere near to even measily 100Mbit forwarding on modern
> hardware but it currently is the only viable way to implement [CLAT]
> on Debian.
> 
> [CLAT]: Is the client-side of a 464XLAT setup. This is used to support
> applications using IPv4 literals on top of an IPv6-only access network.
> 
> Jool being an out-of-tree kernel module has to employ various kernel
> hacks to get it's job done that lead to all kinds of jankyness. It's
> reasonably fast though, so it's more suited for deployment as a
> network service. Unfortunately the upstream project is in "maintanance
> only" mode so my concern is it may get abandoned at some point.

Same :)

> Hence we need more alternatives for these services in Debian.
> 
> tundra-nat64 is a new userspace implementation of SIIT, NAT64 and
> [CLAT]. It's multithreaded as opposed to tayga so my hope is the
> performance will be much better.
> 
> I plan on maintaining tuntra-nat64 myself but I do need a sponsor :)

Why the heck not, I'm happy to review and sponsor; IPv6 adoption is
critical, and giving a hand to someone working to maintain current
tooling to help with the adoption is doing good work. Hit me up off-list
and we'll work out a workflow and all that.

  paultag

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Paul Tagliamonte 
  ⣾⠁⢠⠒⠀⣿⡁  https://people.debian.org/~paultag | https://pault.ag/
  ⢿⡄⠘⠷⠚⠋Debian, the universal operating system.
  ⠈⠳⣄⠀⠀  4096R / FEF2 EB20 16E6 A856 B98C  E820 2DCD 6B5D E858 ADF3

Re: anything like top but for USB?

[Paul Tagliamonte]

On Sun, Jul 16, 2023 at 09:31:51PM +0300, Hannu Vuolasaho wrote:
> Is there a tool to show statististics of USB devices? Like how much
> there is free bandwidth, which endpoints are hogging bandwidth and so
> on?

I haven't seen any replies to this, so I figure I'd take a swing at
sending you a few pointers I have handy.

> Ideally it could be like top but for USB or a page on systat or
> something like that.

I do not know of such a tool (tl;dr: this is the entirety of the email,
if this is all you care about, feel free to trash this email)

> Are there technical reasons or am I just bad at searching?

The OpenBSD USB stack is -- as I've come to discover -- delightfully
spartan^Hminimalist. It supports synchronous bulk transfers via ugen,
and some specific hardware via bespoke drivers, but not a heck of a lot
else.

Through my debugging in trying to get a userland library to place nice,
I've made friends with using tcpdump(8) to capure USB traffic (see: man
for tcpdump(8), look up -i, it makes mention of usb interfaces).

Two notes here that may be varying degrees of helpful:

  1. If you wanted to build such a tool, it may be possible to sniff
 traffic from the kernel by using pcap's USB support. This may give
 you enough information to understand the traffic on your US Bus.
 (saying USB Bus seems redundant don't you think?)

  2. The OpenBSD USB subsystem is not what I'd call highly optimized. It
 gets the job done, and is generally reliable and predictable, but
 assumptions from other OSs break down -- especially with software
 designed and tested with another OS in mind. OpenBSD's USB stack
 has quirks, to be sure, and porting userland code that makes exotic
 use of the USB stack is a fucking headache.

This isn't meant to criticize the OS, just to provide a bit of nuance to
the actual reply, which is that performance bottlenecks may not even
live where one would expect in the abstract. If I was so motiated (I
haven't been so moitivated yet, to be clear :) ) and wanted to
understand when I'm hitting transfer limits in USB my first approach
would be to take a capture and graph the traffic, looking for flat lines
(as flat lines are not generally from nature). My goal would be to
understand why it's flat. The nature of the flat line may lie with the
hardware, kernelspace, userland libraries or with software optmized for
other operating systems. It may even be with underlying I/O writing
results to (a slow?) disk or a (flaky?) network endpoint -- maybe even
both? (slow i/o because of a flaky network + nfs)

Sorry I can't be of help, but I wish you well. I would invite you to
take a more holistic view of the system. I'd be interested if you
discover anything helpful here. I haven't needed to optimize throughput,
but I'm eager to understand the OpenBSD USB stack better.

Take this with a grain of salt, I don't know what I'm talking about :)

Fondly,
   paultag

-- 
:wq

protoc-gen-go-grpc in golang-google-grpc

[Paul Tagliamonte]

Replying not on my phone, hopefully this doesn't trigger a bunch of
replies - we ought to let this thread chill a bit, tensions are
obviously a bit high. We need to cool down a bit on the other thread.

On Mon, Jun 26, 2023 at 08:52:44AM +0200, Thomas Goirand wrote:
> > Besides, you drop the protoc-gen-go-grpc binary package without any
> > explanation.
> 
> I can't remember why I did this. What is this binary for?

This binary is pretty important for gRPC protobuf files. The protoc
command will invoke protoc-gen-go-grpc when you run with the gRPC plugin
by requesting grpc output files in go:

$ protoc --go-grpc_out=... .../*.proto

Without this it won't be able to build the gRPC services into
_grpc.pb.go files. We very likely want to continue to ship this, or
anything using gRPC will FTBFS (or more interestingly, it'll keep
working because we keep the pre-generated code :) ) -- actually,
including etcd, come to think of it. Did it ftbfs with this?

This is a pretty big breakage for any r-b-deps; but it's an easy fix.

   paultag

-- 
  ⢀⣴⠾⠻⢶⣦⠀       Paul Tagliamonte 
  ⣾⠁⢠⠒⠀⣿⡁  https://people.debian.org/~paultag | https://pault.ag/
  ⢿⡄⠘⠷⠚⠋Debian, the universal operating system.
  ⠈⠳⣄⠀⠀  4096R / FEF2 EB20 16E6 A856 B98C  E820 2DCD 6B5D E858 ADF3

Re: Intend to revert golang-google-grpc in unstable

[Paul Tagliamonte]

Thanks for your comments. Please take a break for a few hours.

Paul

On Mon, Jun 26, 2023, 9:15 AM Shengjing Zhu  wrote:

> On Mon, Jun 26, 2023 at 9:12 PM Shengjing Zhu  wrote:
> >
> > On Mon, Jun 26, 2023 at 9:09 PM Paul R. Tagliamonte 
> wrote:
> > >
> > > Packages will be removed from experimental if it contains a newer
> version in unstable (a so called "NVIU" removal).
> > >
> >
> > The problem with zigo's package is not NVIU.
> > Nobody has uploaded any version newer than zigo's version in
> experimental.
>
> Of course except himself.
>
> --
> Shengjing Zhu
>

Bug#1035058: python-validictory: ROM; deprecated upstream since 2018, no rdeps

[Paul Tagliamonte]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

https://github.com/jamesturk/validictory is deprecated upstream as of
2018. Dependencies are encouraged to move to jsonschema. There are no
(longer?) r-deps in Debian, so we should likely remove this. Steve
posted a patch for the Python 3.10 break, which for sure fixes the
problem, but we shouldn't rely on this library anymore.

$ dak rm -Rnb python3-validictory
Checking reverse dependencies...
No dependency problem found.

-- 
:wq

Re: what tools exist to help a beginner debug a hung syscall?

[Paul Tagliamonte]

Thank you very much for your reply, this is extremely high signal.

On Mon, Apr 03, 2023 at 10:15:00AM -, Stuart Henderson wrote:
> On 2023-04-01, Paul Tagliamonte  wrote:
> > I've been trying to take a library[1] I use on my Linux boxen, and coax
> > it into working on OpenBSD[2], and have been able to get a compiled .so
> > that looks good, with the exception of the USB transport. Given the
> 
> This is probably the most informative reply from the previous times the
> subject came up:
> 
> https://marc.info/?l=openbsd-tech=159420462501384=2
> 
> (I don't think anything changed in this area since then).

Exactly the same, in fact! Disapointing reply, but after having spent a
bit over a week tracing this down, it's a relief to my ego that it's not
something obvious. It's doubly frustrating since what I do see in
kernelspace looks to be initialized sensibly, it just sits in progress
and never completes until EINTR.

I'll have to track down that GSOC work, but I'm not super inclined to
put a -current kernel into use outside the lab bench. I fear I may be
the next breadcrumb when someone tries this again within the next 4
years.

> OpenBSD's USB stack, especially regarding direct device access from
> userland, definitely has some issues that don't exist on other systems.
> FWIW I'm tending to run such devices on single-purpose Linux boxes now.

Totally. I was trying to get to 100% feature parity between OpenBSD and
Linux for some code I spend my free time on. Given the better idea I now
have of the landscape, I'm now trying to balance how much I want 100%
feature parity against the three practical options in front of me;
namely:

 1) writing enough of a shim in libusb or libuhd to make this work as-is
today (the only reason I think this is possible is because
unmodified upstream rtl-sdr and hackrf are making libusb async calls
and getting data on my OpenBSD system)

 2) make the most minimal kernel change to get the userland code working

 3) giving up entirely on libuhd on OpenBSD

I'll likely give #2 an ernest try this week, and then fall back on #3. I
don't think I'm going to be the one to crack this multi-decade TODO in
spare cycles between work on a spare cycles project.

> I don't have a kernel core handy to test but you can load a kernel into
> gdb (watch out for reorder_kernel; you will need to save the actual
> kernel that produced the core) and may be able to load the core (saved
> in /var/crash after booting following "boot crash") into gdb with
> 'target kvm $file'. Not sure if you will get better results from base
> or ports gdb ("egdb" binary) in this case; try the other if one doesn't
> work. Though I don't think it's very widely used so may have rotted.
> Generally I think either ddb or adding debug code seem more common,
> also dt(4) helps figure out some things.

This is very pointer rich, thank you very much. I'll give this a try to
see if I can refine the workflow a bit. It sounds like I'm not far off
from best practice, which is -- again -- a bit of a relief.

> Here or maybe tech@. Though this (libusb/direct device access from
> userland) is not an area in which anyone is particularly active.

full ack

Thanks sth@ for your reply, I very much appreciate it.

  paultag

-- 
:wq

what tools exist to help a beginner debug a hung syscall?

[Paul Tagliamonte]

Heyya, misc@,

I'm very new to using OpenBSD for anything more than what's 'on the tin'
(DNS RR, Router, etc), and have got myself stuck and have tried during
nights and weekends for about a week to try and unwedge myself here,
unsuccessfully. I'm hoping someone can help point me to a OpenBSD kernel
for newbies guide/help of some sort.

I've emailed a few lists, but so far everyone either looked the other
way quickly[0], didn't know, or didn't have time to help me out (fair
enough!)

I've been trying to take a library[1] I use on my Linux boxen, and coax
it into working on OpenBSD[2], and have been able to get a compiled .so
that looks good, with the exception of the USB transport. Given the
history of related libraries having similar-sounding[3] issues[4] with
libusb1, I suspect the issue isn't in the library I'm trying to port,
rather, in libusb1's OpenBSD support, or in (*shudder*) the kernel.
Either that or this is a common libusb 'gotcha' that everyone eventually
finds and patches that presents itself on OpenBSD by always locking up.

To get my library working on OpenBSD, I've had to use -snapshot (it
requires waitid(2)), and to debug the system (which is now entirely
just for testing this singular problem), I've built a -current kernel.
Specifically, it's mostly based on the source tree that the Git mirror
knows as e3f6ba90cc00f3d7457f857a0fd00f2b435bc0ec (Wed, Mar 29th,
2023).[5]

Everything below is the state as I understand it while the program is
locked up:

[Split-cut to: userland]

When reading from the device, my 3-line test program (3-line is
disengenious here since it's calling into a library that calls into a
library that eventually talks to the OS) eventually hangs while invoking
'libusb_submit_transfer', which is, specifically, hung on a read(2)
against a ugen device (specifically, the read in '_sync_gen_transfer' in
the libusb OpenBSD implementation). A pthread in the background is
continuing to exercise the 'libusb_handle_events' endpoint, to no avail.

I asked the upstream list about this[6], no reply yet.

[Fade to: kernelspace]

[Scene one: read(2) syscall]

The kernelspace end of the read(2) has wound up in `usbd_transfer`,
roundabout line 406 of usbdi.c, waiting for the xfer on the other end of
the endpoint's pipe to be complete. This intrepid syscall earnestly
stands by, waiting for the day when it'll be called back.

[Scene two: ugen driver state]

Everything is using USB3/xhci. That's the only bus on the system, and
this device communicates using USB3 in this case.

The ugen device (other USB devices are not a factor as far as I can
tell, and will continue to operate, even in the locked state,
interestingly) looks something like:

 ugen device unit 1:
   - endpoint 2: dir=0 (OUT) -- NULL pipe
   - endpoint 4: dir=0 (OUT) -- NULL pipe
   - endpoint 6: dir=1 (IN)  -- NULL pipe
   - endpoint 8: dir=1 (IN)  -- pipe alloc'd

The one related endpoint, which is endpoint 8 here, has a refcount of 1.
It's running (not aborting).

Here's the output of some USB_DEBUG knobs:

usbd_dump_device: dev=0x81291500
 bus=0x80132000 default_pipe=0x801bd000
 address=3 config=1 depth=1 speed=4 self_powered=0 power=2 langid=1033
 pipe=0x808b6000

usbd_dump_endpoint: endp=0x812d6ee0
 edesc=0x801b785d refcnt=1
 bEndpointAddress=0x88
 (usbd_dump_pipe:)
 running=1 aborting=0
 intrxfer=0x0, repeat=0, interval=-1

Since this doesn't give me a lot of insight into the xfer state, I wrote
a small stub and threw it into a dark corner where I could let it be,
and have the following from it:

pipe=0x808b6000
  xfer=0xfd827f59daf0 status=1 done=0 length=1024 flags=0x16 timeout=0

My understanding is that this means that endpoint 8 has an active pipe
that is running (not aborting), with an in-flight xfer which is
IN_PROGRESS, with the (USBD_SYNCHRONOUS | USBD_SHORT_XFER_OK |
USBD_CATCH) flags set [0x02 | 0x04 | 0x10 - as seen in usbdi.h].

Even while waiting a signficant (in human-time) length of time, the xfer
remains in this state, and is never marked as done until I C-c the
process, and everything cleans up on close(2)/EINTR

[Cut to: author]

Right, thank you for sticking around. I'm looking for some help for what
steps to take next on trying to isolate what may be blocking the xfer
from being processed -- and trying to figure out what userland knobs are
invoking kernelspace in a way that's causing it. Since other libraries
are working OK, I have to assume this isn't actually a kernelspace bug,
but I'd feel a lot better root causing it.

During the wedged state, xhci messages don't come through after the
transfer was submitted (I have xhcidebug, as well as other
{usb,ugen,*}debug set high), and I've very quickly got myself lost past
this point. This makes me suspect some sort of inturupt is maybe
being suspended while a call is in progress; I just have no idea where
to start with that theory, much 

Re: devel/libusb1 hangs when transfering data to a USB device

[Paul Tagliamonte]

On Mon, Mar 27, 2023 at 12:55:55PM -0400, Paul Tagliamonte wrote:
> [...]

In the hopes this is useful, I had a second to build a -current kernel
with ugen debugging enabled. Here's the prior output along with a tail
of /var/log/messages in the background.

/
| [ 0.718964] [00042c96] libusb: debug [libusb_claim_interface] interface 4
| [ 0.719026] [00042c96] libusb: debug [libusb_submit_transfer] transfer 
0x2ea487360
| [ 0.719043] [00042c96] libusb: debug [obsd_submit_transfer]  
| [ 0.719054] [00042c96] libusb: debug [_access_endpoint] endpoint 8 mode 0
| [ 0.729511] [00042c96] libusb: debug [_errno_to_libusb] error: Operation 
timed out (60)
| [ 0.729531] [00042c96] libusb: debug [libusb_free_transfer] transfer 
0x2ea487360
| [ 0.730553] [00042c96] libusb: debug [libusb_submit_transfer] transfer 
0x2ea487460
| [ 0.730569] [00042c96] libusb: debug [obsd_submit_transfer]  
| [ 0.730580] [00042c96] libusb: debug [_access_endpoint] endpoint 8 mode 0
| Mar 27 20:04:40 ourea /bsd: ugenopen: flag=3, mode=8192, unit=0 endpt=8
| Mar 27 20:04:40 ourea /bsd: ugenopen: flag=1, mode=8192, unit=0 endpt=8
| Mar 27 20:04:40 ourea /bsd: ugenopen: sc=0x801be000, endpt=8, dir=1, 
sce=0x801bf7c0
| Mar 27 20:04:40 ourea /bsd: ugen_clear_iface_eps: clear interface eps
| Mar 27 20:04:40 ourea /bsd: ugenioctl: cmd=80045572
| Mar 27 20:04:40 ourea /bsd: ugenioctl: cmd=80045571
| Mar 27 20:04:40 ourea /bsd: ugen0: ugenread: 8
| Mar 27 20:04:40 ourea /bsd: ugenread: start transfer 512 bytes
| Mar 27 20:04:40 ourea /bsd: ugenioctl: cmd=80045572
| Mar 27 20:04:40 ourea /bsd: ugenioctl: cmd=80045571
| Mar 27 20:04:40 ourea /bsd: ugen0: ugenread: 8
| Mar 27 20:04:40 ourea /bsd: ugenread: start transfer 1024 bytes
| [ 0.824716] [0003af1b] libusb: debug [usbi_wait_for_events] poll() returned 0
| [ 0.824746] [0003af1b] libusb: debug [libusb_get_next_timeout] no URB with 
timeout or all handled by OS; no timeout!
| [ 0.824761] [0003af1b] libusb: debug [libusb_handle_events_timeout_completed] 
doing our own event handling
| [ 0.824774] [0003af1b] libusb: debug [usbi_wait_for_events] poll() 1 fds with 
timeout in 100ms
| [ 0.934674] [0003af1b] libusb: debug [usbi_wait_for_events] poll() returned 0
| [ 0.934702] [0003af1b] libusb: debug [libusb_get_next_timeout] no URB with 
timeout or all handled by OS; no timeout!
| [ 0.934716] [0003af1b] libusb: debug [libusb_handle_events_timeout_completed] 
doing our own event handling
| [ 0.934727] [0003af1b] libusb: debug [usbi_wait_for_events] poll() 1 fds with 
timeout in 100ms
| [ 1.044719] [0003af1b] libusb: debug [usbi_wait_for_events] poll() returned 0
| [ 1.044746] [0003af1b] libusb: debug [libusb_get_next_timeout] no URB with 
timeout or all handled by OS; no timeout!
| [ 1.044763] [0003af1b] libusb: debug [libusb_handle_events_timeout_completed] 
doing our own event handling
 ...
| [ 1.924783] [0003af1b] libusb: debug [usbi_wait_for_events] poll() 1 fds with 
timeout in 100ms
| [ 2.034700] [0003af1b] libusb: debug [usbi_wait_for_events] poll() returned 0
| [ 2.034731] [0003af1b] libusb: debug [libusb_get_next_timeout] no URB with 
timeout or all handled by OS; no timeout!
| [ 2.034744] [0003af1b] libusb: debug [libusb_handle_events_timeout_completed] 
doing our own event handling
| [ 2.034757] [0003af1b] libusb: debug [usbi_wait_for_events] poll() 1 fds with 
timeout in 100ms
| ^C
| Mar 27 20:04:42 ourea /bsd: ugenclose: flag=3, mode=8192, unit=0, endpt=0
| Mar 27 20:04:42 ourea /bsd: ugenclose: close control
| Mar 27 20:04:42 ourea /bsd: ugenclose: flag=1, mode=8192, unit=0, endpt=8
| Mar 27 20:04:42 ourea /bsd: ugenclose: endpt=8 dir=1 sce=0x801bf7c0
\

Thanks, all!
  paultag

-- 
:wq

Bug#1031354: Fwd: Bug#1031354 closed by Paul Tagliamonte (Re: Bug#1031354: installation-reports: I cannot find /usr/bin/ps in any package, but it is normally installed with via an

[Paul Tagliamonte]

On Wed, Feb 15, 2023 at 11:23:29AM -0500, Paul Tagliamonte wrote:
> >$ dpkg -S $(which ps)
> >On a system with /usr/bin/ps

Also, forgot to reply to this bit; this is due to usr merge. This is a
known sharp edge that folks are actively working on.

While it's present at `/usr/bin`, that's because `/bin` is symlinked,
dpkg, abet confusingly, knows it as /bin/ps, not /usr/bin/ps

$ dpkg -S /bin/ps
procps: /bin/ps

  paultag

-- 
:wq

Bug#1031354: Fwd: Bug#1031354 closed by Paul Tagliamonte (Re: Bug#1031354: installation-reports: I cannot find /usr/bin/ps in any package, but it is normally installed with via an

[Paul Tagliamonte]

On Wed, Feb 15, 2023 at 11:23:29AM -0500, Paul Tagliamonte wrote:
> >$ dpkg -S $(which ps)
> >On a system with /usr/bin/ps

Also, forgot to reply to this bit; this is due to usr merge. This is a
known sharp edge that folks are actively working on.

While it's present at `/usr/bin`, that's because `/bin` is symlinked,
dpkg, abet confusingly, knows it as /bin/ps, not /usr/bin/ps

$ dpkg -S /bin/ps
procps: /bin/ps

  paultag

-- 
:wq

Bug#1031354: Fwd: Bug#1031354 closed by Paul Tagliamonte (Re: Bug#1031354: installation-reports: I cannot find /usr/bin/ps in any package, but it is normally installed with via an

[Paul Tagliamonte]

On Wed, Feb 15, 2023 at 11:21:02AM -0500, Steve Roggenkamp wrote:
>I attempted to use the phusion passenger package, but it would not
>properly run because it needs /usr/bin/ps for somer reason.

This happens with some other packages too, like Jenkins, a friend
pointed out to me.

>No
>problem, I will just install it. When I searched for the package
>containing it on [5]packages.debian.org, the search returns no results.
> That is, there is no package that  contains /usr/hin/ps.  I expected

The package is `procps`

Description: /proc file system utilities
 This package provides command line and full screen utilities for browsing
 procfs, a "pseudo" file system dynamically generated by the kernel to
 provide information about the status of entries in its process table
 (such as whether the process is running, stopped, or a "zombie").
 .
 It contains free, kill, pkill, pgrep, pmap, ps, pwdx, skill, slabtop,
 snice, sysctl, tload, top, uptime, vmstat, w, and watch.

>it would be in coreutils, but it is not.  It seems to be present on a
>another recent Debian bullseye install I did, but, again, it is
>contained in any package.  It should be contained in a package in the
>base_system, but it is not.  How does it get there? What if there is a
>security issue identified with the program, would it be updated? Having
>a binary program installed on a system without it being contained in a
>package seems to contravene the Debian packaging policies.
>Downstream distributions, such as Ubuntu are also affected.  I
>confirmed the /usr/bin/ps is not contained in any package for 22.04
>LTS, although I have not filed a bug report.
>You can reproduce the problem easily by either searching for
>/usr/bin/ps on [6]packages.debian.org or
>$ dpkg -S $(which ps)
>On a system with /usr/bin/ps
>Thanks,
>Steve

Hope that helps,
  Paul

-- 
:wq

Bug#1031354: Fwd: Bug#1031354 closed by Paul Tagliamonte (Re: Bug#1031354: installation-reports: I cannot find /usr/bin/ps in any package, but it is normally installed with via an

[Paul Tagliamonte]

On Wed, Feb 15, 2023 at 11:21:02AM -0500, Steve Roggenkamp wrote:
>I attempted to use the phusion passenger package, but it would not
>properly run because it needs /usr/bin/ps for somer reason.

This happens with some other packages too, like Jenkins, a friend
pointed out to me.

>No
>problem, I will just install it. When I searched for the package
>containing it on [5]packages.debian.org, the search returns no results.
> That is, there is no package that  contains /usr/hin/ps.  I expected

The package is `procps`

Description: /proc file system utilities
 This package provides command line and full screen utilities for browsing
 procfs, a "pseudo" file system dynamically generated by the kernel to
 provide information about the status of entries in its process table
 (such as whether the process is running, stopped, or a "zombie").
 .
 It contains free, kill, pkill, pgrep, pmap, ps, pwdx, skill, slabtop,
 snice, sysctl, tload, top, uptime, vmstat, w, and watch.

>it would be in coreutils, but it is not.  It seems to be present on a
>another recent Debian bullseye install I did, but, again, it is
>contained in any package.  It should be contained in a package in the
>base_system, but it is not.  How does it get there? What if there is a
>security issue identified with the program, would it be updated? Having
>a binary program installed on a system without it being contained in a
>package seems to contravene the Debian packaging policies.
>Downstream distributions, such as Ubuntu are also affected.  I
>confirmed the /usr/bin/ps is not contained in any package for 22.04
>LTS, although I have not filed a bug report.
>You can reproduce the problem easily by either searching for
>/usr/bin/ps on [6]packages.debian.org or
>$ dpkg -S $(which ps)
>On a system with /usr/bin/ps
>Thanks,
>Steve

Hope that helps,
  Paul

-- 
:wq

Re: [Bloat] speedtest-cli on multihomed gateway

[Paul Tagliamonte via Bloat]

On Thu, Feb 02, 2023 at 10:15:23AM -0500, Paul Tagliamonte wrote:
> [... stuff ...]

Additional note: the nonfree / closed source speedtest cli binary downloadable
at no cost at https://www.speedtest.net/apps/cli contains a `-i` flag for
binding to a specific interface, which means you don't have to faff
around with network namespacing :)

   paultag

-- 
:wq
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] speedtest-cli on multihomed gateway

[Paul Tagliamonte via Bloat]

I wasn't going to reply, since I figured others would get here first
with more constructive notes; but since I don't see any, here's some
pointers, but alas, not anything concrete; a lot is still left as an
exercise to the reader. Sorry about that.

Sorry this is a bit long, i'm going to try to make this as helpful as I
can.

On Wed, Feb 01, 2023 at 12:20:56PM -0800, Kenneth Porter via Bloat wrote:
> # ip netns add comcast-1
> # ip link set eno4 netns comcast-1
> # ip netns exec comcast-1 speedtest-cli

Network Namespaces work like the other Linux namespaces (ok fine, not
*all* of them, but most of them) -- when you create a new one, you're in
an entirely different universe that is not connected to your existing
world. This world doesn't talk to other namespaces, unless you use
something like a `ip link add link-name0 type veth peer link-name1`, and
move one end of the veth "wormhole" into the network namespace, leave
the other out of it, and use it to bridge. This is fundementally how
things like Docker work.

All this to say, by moving eno4 to netns comcast-1, the host won't be
able to meaningfully use it anymore. This is likely not what you want
(an outage during the speedtest), so my guess is you'd want a network
namespace, veth pair with one end on the host, one end in the network
namespace, and a bridge to join the veth0 to comcast-1.

Let's create two network veth interfaces (it's like a pipe if you've
never used one directly before), on-host0 which will live on my host's
network namespace, and `in-ns0` which will be moved into the network
namespace once we set it up. These are bad names I'm picking to make
this super explicit.

prompts like `host$` are done via bash on my host, perhaps with sudo.
Prompts like `ns$` are done via bash inside a network namespace. Also,
perhaps with sudo.

```
host$ ip link add on-host0 type veth peer in-ns0
```

Note `ip link`. It'll show `on-host0` and `in-ns0` in the host
namespace, and also down.

Let's add a network namespace.

```
host$ sudo ip netns add bloat
host$ sudo ip netns exec bloat $(which bash)
ns$ ip link
1: lo:  mtu 65536 qdisc noop state DOWN mode DEFAULT group default 
qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
ns$
```

```
host$ ip link set in-ns0 netns bloat
host$ 
```

```
ns$ ip link
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
17: in-ns0@if18:  mtu 1500 qdisc noop state DOWN mode 
DEFAULT group default qlen 1000
link/ether fe:a8:45:16:c5:5a brd ff:ff:ff:ff:ff:ff link-netnsid 0
```

You'll note that I currently have no interfaces, *none* of the host
interfaces show -- and even `lo` is down. Let's fix that.

```
ns$ ip link set lo up
ns$ ip link set in-ns0 up
ns$ ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
17: in-ns0@if18:  mtu 1500 qdisc noqueue 
state LOWERLAYERDOWN group default qlen 1000
link/ether fe:a8:45:16:c5:5a brd ff:ff:ff:ff:ff:ff link-netnsid 0
```

You'll note `in-ns0` is still LAYERDOWN, this is because the host veth
end is still down.

The last big thing is because this is its own network namespace, you'll
need to add an IP address to the veth device depending on configuration
(e.g., you could NAT from the veth on-host0 -> comcast-1, bridge it, or
whatever your setup and upstream will allow), and then you can set up
your routes as required.

```
ns$ ip route
ns$ 
```

From here on out, I suspect you've got it, given you're juggling 4 WAN
ports, I guess you can fill in the rest of the blanks here, it's just a
few routes/interface configurations on the host and inside your netns.

FWIW, at some point this becomes almost exactly like a Docker container
(or podman or what have you) without the nicities -- Docker and other
container daemons/launchers are usually capable of automating this
bridge+veth+netns dance for you. If that's not an option due to the
platform, doing it by hand is doable, but requires a bit of work to
debug.

> At this point I'm not sure what I need to do to make the network
> namespace usable.

Best of luck,
   paultag

-- 
:wq
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Bug#1028227: Should we FTP RM libi8x?

[Paul Tagliamonte]

On Mon, Jan 30, 2023 at 12:30:40PM -0500, Paul Tagliamonte wrote:
> doko is not MIA. I've seen recent uploads from him. He's also on IRC.  I
> asked him on IRC, he replied fairly quickly:
> 
> 17:27 < doko> paultag: please remove, there's no upstream development anymore
> 
> Next time, it'd be great if you gave him a ping and found a way to get
> in touch with package maintainers - RoQA'ing a package that ought to be
> RoM because the maintainer is still very active in Debian is a lot of
> work for us to resolve.

I spoke too soon, this removal has a reverse dependency issue:

Checking reverse dependencies...
# Broken Build-Depends:
i8c: python3-libi8x

Dependency problem found.

williamdes: can you take a look at i8c and file a RoM/RoQA for that as
well? Looks like it's not in testing or stable.

  paultag

-- 
:wq

Bug#1028227: Should we FTP RM libi8x?

[Paul Tagliamonte]

On Sat, Jan 28, 2023 at 08:49:04AM +0100, William Desportes wrote:
> Hi,
> 
> I would say that at first doko was not reachable, now doko has probably a lot 
> to do.
> 
> I had mailed the MIA team to see what could be done.

doko is not MIA. I've seen recent uploads from him. He's also on IRC.  I
asked him on IRC, he replied fairly quickly:

17:27 < doko> paultag: please remove, there's no upstream development anymore

Next time, it'd be great if you gave him a ping and found a way to get
in touch with package maintainers - RoQA'ing a package that ought to be
RoM because the maintainer is still very active in Debian is a lot of
work for us to resolve.

  paultag

-- 
:wq

Bug#1028227: RM: libi8x -- RoQA; no rdeps, no update since 2017, does not build

[Paul Tagliamonte]

What's the status of this removal request? Has doko been consulted? Can
he comment here if he would like the removal to go ahead or close it if
not? I see ScottK asked the same a few days ago; we'll likely close this
bug if it's unack'd

  paultag

-- 
:wq

Bug#1029547: RM: libcoq-ocaml-dev -- NBS; cruft

[Paul Tagliamonte]

On Tue, Jan 24, 2023 at 08:50:22AM -0500, Paul Tagliamonte wrote:
> dak rm -o -m "[auto-cruft] NBS (no longer built by coq)" -s unstable \
>   -a amd64,arm64,armhf,i386,ppc64el,s390x -p -R -b libcoq-ocaml 
> libcoq-ocaml-dev

I've been following your hard work dilligently uploading fixes for all
the r-deps. I noticed the last package go through and get through the
archive -- I've run this decruft command and closed this bug. Thank you
very much!

   Paul

-- 
:wq

Bug#1029547: RM: libcoq-ocaml-dev -- NBS; cruft

[Paul Tagliamonte]

On Tue, Jan 24, 2023 at 08:38:18AM -0500, Paul Tagliamonte wrote:
> Thanks! If you would be able to fix the r-deps to stop other packages
> from depending on a package that hasn't been built for a few months, we
> should be able to do this no problem. The auto-decrufter may even pick
> it up without humans after that's done :)

Sorry - one last note - if you do go about fixing this, since I did a rm
of coq-theories in #1029538 (which was safe as a one-off RM since it had
no r-deps), here's the *actual* command I want to run to decruft coq --
note it contains an additional binary package that no one has asked
about yet -- libcoq-ocaml.

dak rm -o -m "[auto-cruft] NBS (no longer built by coq)" -s unstable \
  -a amd64,arm64,armhf,i386,ppc64el,s390x -p -R -b libcoq-ocaml libcoq-ocaml-dev

Thanks for your work!
  Paul

-- 
:wq

Bug#1029547: RM: libcoq-ocaml-dev -- NBS; cruft

[Paul Tagliamonte]

tags 1029547 + moreinfo
thanks

On Tue, Jan 24, 2023 at 10:53:49AM +0100, julien.pu...@gmail.com wrote:
> Dear FTP Team,
> 
> Please remove all libcoq-ocaml-dev (binary) packages from unstable. 

The (now) infamous coq package. It's on our cruft-report, but we're
unable to handle it very gracefully, since removing this package will
break r-deps. I've included the output[1] from
`mirror.ftp-master.debian.org` along with a removal command that we'd
run from ftp-master down below at[2]


> They correspond to an old coq source package, but coq has stopped
> building them for months.

Thanks! If you would be able to fix the r-deps to stop other packages
from depending on a package that hasn't been built for a few months, we
should be able to do this no problem. The auto-decrufter may even pick
it up without humans after that's done :)

[1]:

Checking reverse dependencies...
# Broken Depends:
coq-elpi: libcoq-elpi [amd64 arm64 i386 ppc64el]

# Broken Build-Depends:
coq-bignums: libcoq-ocaml-dev
coq-corn: libcoq-ocaml-dev
coq-deriving: libcoq-ocaml-dev
coq-dpdgraph: libcoq-ocaml-dev
coq-elpi: libcoq-ocaml-dev (8.15 >=)
coq-equations: libcoq-ocaml-dev
coq-ext-lib: libcoq-ocaml-dev
coq-extructures: libcoq-ocaml-dev
coq-gappa: libcoq-ocaml-dev
coq-hammer: libcoq-ocaml-dev
coq-hott: libcoq-ocaml-dev
coq-interval: libcoq-ocaml-dev
coq-iris: libcoq-ocaml-dev
coq-libhyps: libcoq-ocaml-dev
coq-math-classes: libcoq-ocaml-dev
coq-menhirlib: libcoq-ocaml-dev
coq-mtac2: libcoq-ocaml-dev
coq-quickchick: libcoq-ocaml-dev
coq-record-update: libcoq-ocaml-dev
coq-reduction-effects: libcoq-ocaml-dev
coq-reglang: libcoq-ocaml-dev
coq-relation-algebra: libcoq-ocaml-dev
coq-simple-io: libcoq-ocaml-dev
coq-stdpp: libcoq-ocaml-dev
coq-unicoq: libcoq-ocaml-dev
coq-unimath: libcoq-ocaml-dev
coqeal: libcoq-ocaml-dev
coqprime: libcoq-ocaml-dev
coquelicot: libcoq-ocaml-dev
flocq: libcoq-ocaml-dev
ott: libcoq-ocaml-dev
paramcoq: libcoq-ocaml-dev


[2]: 
 first `ssh mirror.ftp-master.debian.org`, and then run:
 dak rm -o -m "[auto-cruft] NBS (no longer built by coq)" -s unstable \
   -a amd64,arm64,armhf,i386,ppc64el,s390x -p -R -b libcoq-ocaml-dev
-- 
:wq

Bug#1029134: RM: mricron [mipsel powerpc ppc64] -- ROM; Please remove some unsupported architectures

[Paul Tagliamonte]

On Thu, Jan 19, 2023 at 08:24:52PM +0100, Andreas Tille wrote:
> According to
>https://buildd.debian.org/status/package.php?p=mricron
> the package builds on ppc64el and I left it in the architecture list.
> I had to remove ppc64 from the list of architectures since it did not
> built there.
> 
> Thanks for asking for clarification anyway

Great, I'm happy I asked!

Can you retitle to match the arches you're intending to RM on? As a
hint, I don't see anything in unstable for powerpc or ppc64; hence the
confusion :)

$ dak ls mricron -a mipsel
mricron| 1.2.20211006+dfsg-1+b1 | testing| mipsel
mricron| 1.2.20211006+dfsg-1+b1 | unstable   | mipsel
$ dak ls mricron -a powerpc
$ dak ls mricron -a ppc64

Should the title be just [mipsel]? If so, could you please change the
title to reflect the targets of the rm? If no debs are in that arch, I
can't remove it :)

Thank you!
   paultag

-- 
:wq

Bug#1029134: RM: mricron [mipsel powerpc ppc64] -- ROM; Please remove some unsupported architectures

[Paul Tagliamonte]

Hey Andreas,

>From the title: [mipsel powerpc ppc64] 

Is ppc64 right or should it be ppc64el? I suspect you mean/want ppc64el
but I don't want to take an rm action here until I've got a lot of
positive confirmation.

If that's right, would you please re-title this bug? Thank you very
much!

   Paul

-- 
:wq

Bug#1027449: d/copyright is wrong

[Paul Tagliamonte]

Package: ruby-dbm
Severity: serious
User: paul...@debian.org
Usertags: ftp
X-Debbugs-CC: ftpmas...@ftp-master.debian.org
thanks

I've filed the bug since I wasn't sure if my email made it through due
to SMTP issues. Since I didn't see anything in git or any other acks,
I'll file the bug to help with tracking the issue.

I've marked this package for ACCEPT last night.

The debian/coypright file describes source files, not binaries. It looks
like ruby-dbm's copyright file added GPL-3+ because of the GDBM
implementation we link to, which is a welcome degree of diligence I do
appreciate, but it may change without the involvement of this source
package (if the implementation were to change, or how a downstream
changes the way the deb is built). If we had to list all the licensing
information of all our build-deps / links, things would get very messy
indeed! I'd expect someone to look through the dependency tree iff they
need to determine the binary distribution terms.

  paultag (on behalf of the ftpteam)


signature.asc
Description: PGP signature

Bug#1027449: d/copyright is wrong

[Paul Tagliamonte]

Package: ruby-dbm
Severity: serious
User: paul...@debian.org
Usertags: ftp
X-Debbugs-CC: ftpmas...@ftp-master.debian.org
thanks

I've filed the bug since I wasn't sure if my email made it through due
to SMTP issues. Since I didn't see anything in git or any other acks,
I'll file the bug to help with tracking the issue.

I've marked this package for ACCEPT last night.

The debian/coypright file describes source files, not binaries. It looks
like ruby-dbm's copyright file added GPL-3+ because of the GDBM
implementation we link to, which is a welcome degree of diligence I do
appreciate, but it may change without the involvement of this source
package (if the implementation were to change, or how a downstream
changes the way the deb is built). If we had to list all the licensing
information of all our build-deps / links, things would get very messy
indeed! I'd expect someone to look through the dependency tree iff they
need to determine the binary distribution terms.

  paultag (on behalf of the ftpteam)


signature.asc
Description: PGP signature

[DRE-maint] Bug#1027449: d/copyright is wrong

[Paul Tagliamonte]

Package: ruby-dbm
Severity: serious
User: paul...@debian.org
Usertags: ftp
X-Debbugs-CC: ftpmas...@ftp-master.debian.org
thanks

I've filed the bug since I wasn't sure if my email made it through due
to SMTP issues. Since I didn't see anything in git or any other acks,
I'll file the bug to help with tracking the issue.

I've marked this package for ACCEPT last night.

The debian/coypright file describes source files, not binaries. It looks
like ruby-dbm's copyright file added GPL-3+ because of the GDBM
implementation we link to, which is a welcome degree of diligence I do
appreciate, but it may change without the involvement of this source
package (if the implementation were to change, or how a downstream
changes the way the deb is built). If we had to list all the licensing
information of all our build-deps / links, things would get very messy
indeed! I'd expect someone to look through the dependency tree iff they
need to determine the binary distribution terms.

  paultag (on behalf of the ftpteam)


signature.asc
Description: PGP signature
___
Pkg-ruby-extras-maintainers mailing list
Pkg-ruby-extras-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers

Re: [DRE-maint] ruby-dbm_1.1.0-1_amd64.changes is NEW

[Paul Tagliamonte]

I've marked this package for ACCEPT.

However, there's one borderline issue that I'm going to allow through
NEW, because I don't believe it impacts our distributability, however
it's likely an RC bug IMHO.

The debian/coypright file describes source files, not binaries. It
looks like you've added GPL-3+ because of the GDBM implementation we
link to, which is a welcome degree of diligence I do appreciate, but
it may change without the involvement of this source package (if the
implementation were to change, or how a downstream changes the way the
deb is built). If we had to list all the licensing information of all
our build-deps / links, things would get very messy indeed! I'd expect
someone to look through the dependency tree iff they need to determine
the binary distribution terms.

If you could upload a new version of this package with a fixed
d/coypright, that'd be super helpful!

I'll spare filing the bug since it's not in the archive yet, I trust
the team to update this before I have a chance to file a bug :)

I'm not rejecting because the correct terms are in fact there, and no
terms of the license would be violated by our distribution here from
how I'm seeing it. The license document is also clarified in a way
that's factual and understandable for a human to read.

  paultag (on behalf of the ftpteam)



On Fri, Dec 30, 2022 at 10:21 PM Antonio Terceiro  wrote:
>
> Hi,
>
> On Sat, Dec 31, 2022 at 01:09:44AM +, Debian FTP Masters wrote:
> > binary:ruby-dbm is NEW.
> > binary:ruby-dbm is NEW.
> > source:ruby-dbm is NEW.
>
> This package is needed ir order to fix dhelp:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027407
>
> It's also a very simple package, so if possible please try to expedite
> it through NEW.



-- 
:wq

___
Pkg-ruby-extras-maintainers mailing list
Pkg-ruby-extras-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers

Bug#1027404: RFS: sfeed/1.6-1 [ITP] -- simple RSS and Atom parser

[Paul Tagliamonte]

On Fri, Dec 30, 2022 at 10:38:52PM +0100, Matteo Bini wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "sfeed":

sfeed_1.6-1_amd64 was uploaded to NEW, and rejected due to a very
fixable copyright oversight. I don't see it in NEW or the archive,
so I'm going to CC the last folks to package this, perhaps you can
deduplicate your work.

   paultag

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Paul Tagliamonte 
  ⣾⠁⢠⠒⠀⣿⡁  https://people.debian.org/~paultag | https://pault.ag/
  ⢿⡄⠘⠷⠚⠋Debian, the universal operating system.
  ⠈⠳⣄⠀⠀  4096R / FEF2 EB20 16E6 A856 B98C  E820 2DCD 6B5D E858 ADF3


signature.asc
Description: PGP signature

Bug#1027404: RFS: sfeed/1.6-1 [ITP] -- simple RSS and Atom parser

[Paul Tagliamonte]

On Fri, Dec 30, 2022 at 10:38:52PM +0100, Matteo Bini wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "sfeed":

sfeed_1.6-1_amd64 was uploaded to NEW, and rejected due to a very
fixable copyright oversight. I don't see it in NEW or the archive,
so I'm going to CC the last folks to package this, perhaps you can
deduplicate your work.

   paultag

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Paul Tagliamonte 
  ⣾⠁⢠⠒⠀⣿⡁  https://people.debian.org/~paultag | https://pault.ag/
  ⢿⡄⠘⠷⠚⠋Debian, the universal operating system.
  ⠈⠳⣄⠀⠀  4096R / FEF2 EB20 16E6 A856 B98C  E820 2DCD 6B5D E858 ADF3


signature.asc
Description: PGP signature

Re: [patch] arp.c spaces nested between tabs

[Paul Tagliamonte]

On Thu, Dec 29, 2022 at 09:52:49AM +0100, Omar Polo wrote:
> ksh actually supports that style of globbing :)

Fair enough! TIL -- but the GNU Grep bit stands, though :)


Any takers on the diff? Should be an easy one

  paultag

-- 
:wq

Bug#1026588: Fix pending in the NEW queue

[Paul Tagliamonte]

On Thu, Dec 29, 2022 at 08:03:06AM -0500, Reinhard Tartler wrote:
>Dear ftp-master, happy holidays!

>Any chance you could fast-track this package so that I can fix 2 RC
>bugs? I'm concerned that if not fixed in time, aardvark-dns would be
>removed from testing, which would break podman and friends.
>Thanks in advance!

Marked for ACCEPT.

While reviewing it, it looks like you have patches that aren't in the
series file; that's usually an oversight - worth taking a look at, but
it's not impacting its suitability for the archive.

  paultag, for the ftpteam

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Paul Tagliamonte 
  ⣾⠁⢠⠒⠀⣿⡁  https://people.debian.org/~paultag | https://pault.ag/
  ⢿⡄⠘⠷⠚⠋Debian, the universal operating system.
  ⠈⠳⣄⠀⠀  4096R / FEF2 EB20 16E6 A856 B98C  E820 2DCD 6B5D E858 ADF3


signature.asc
Description: PGP signature

Bug#1026588: Fix pending in the NEW queue

[Paul Tagliamonte]

On Thu, Dec 29, 2022 at 08:03:06AM -0500, Reinhard Tartler wrote:
>Dear ftp-master, happy holidays!

>Any chance you could fast-track this package so that I can fix 2 RC
>bugs? I'm concerned that if not fixed in time, aardvark-dns would be
>removed from testing, which would break podman and friends.
>Thanks in advance!

Marked for ACCEPT.

While reviewing it, it looks like you have patches that aren't in the
series file; that's usually an oversight - worth taking a look at, but
it's not impacting its suitability for the archive.

  paultag, for the ftpteam

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Paul Tagliamonte 
  ⣾⠁⢠⠒⠀⣿⡁  https://people.debian.org/~paultag | https://pault.ag/
  ⢿⡄⠘⠷⠚⠋Debian, the universal operating system.
  ⠈⠳⣄⠀⠀  4096R / FEF2 EB20 16E6 A856 B98C  E820 2DCD 6B5D E858 ADF3


signature.asc
Description: PGP signature

Re: [patch(es)] fix a few typos in /src

[Paul Tagliamonte]

On Wed, Dec 28, 2022 at 09:35:52PM +, Jason McIntyre wrote:
> i've finished with this diff. the usr.sbin parts i didn;t take are
> listed below, along with any explanation.

I *think* by my count and by watching the logs this is all of the diffs
on this thread! Kudos for your steadfast review, thank you very much for
your work applying the diff. I'm very appreciative!

   paultag

-- 
:wq

[patch] arp.c spaces nested between tabs

[Paul Tagliamonte]

Hello, tech@!

Minor patch for `arp(8)`. It uses some spaces between two tabs that are
hard to notice. I have a syntax highlighting rule that shows such spaces[1]
so I saw it while reviewing the arp.c source.

I've learned my lesson trying to patch the monorepo across folder lines, so
here's a patch for only just arp.c, and a list of files that match a grep[2]
attached for someone else who feels the urge to be told off on the list -- I've
done exactly zero work to figure out if there's any false positives (spoiler,
there are just from scanning some of them) due to filetype[3] or source that's
not `style(9)` formatted yet; but I'll let someone else take that windmill on
if they're so inclined. I have become disinclined :)

Plus, I fear if I send another large diff after going through all these cases,
jmc@ won't have any free time this holiday season[4], and we can't have that.

```
Index: arp.c
===
RCS file: /cvs/src/usr.sbin/arp/arp.c,v
retrieving revision 1.88
diff -u -p -r1.88 arp.c
--- arp.c   16 Sep 2019 20:49:28 -  1.88
+++ arp.c   28 Dec 2022 04:49:15 -
@@ -418,7 +418,7 @@ tryagain:
if (sdl->sdl_family == AF_LINK && rtm->rtm_flags & RTF_LLINFO) {
if (rtm->rtm_flags & RTF_LOCAL)
return (0);
-   if (!(rtm->rtm_flags & RTF_GATEWAY))
+   if (!(rtm->rtm_flags & RTF_GATEWAY))
switch (sdl->sdl_type) {
case IFT_ETHER:
case IFT_FDDI:
```

   paultag


[1]: from my ~/.exrc for vim:
 highlight NestedSpace ctermbg=red ctermfg=white guibg=red
 match NestedSpace  /\t \+\t/

[2]: {openbsd monks avert your eyes: gnu grep and bash w/ 'shopt -s extglob'}:
 $ grep -P '\t +\t' !(gnu|sys) -ril

[3]: you can never be too sure; perhaps there's some whitespace
 (the language) source in-tree
 https://en.wikipedia.org/wiki/Whitespace_(programming_language)

[4]: if someone with eyes on jmc@ could give him some cookies as a thanks for
 his hard work, the universe would be very thankful.

-- 
:wq
bin/ed/ed.h
bin/ed/io.c
bin/ed/main.c
bin/csh/proc.c
distrib/notes/alpha/hardware
etc/etc.powerpc64/MAKEDEV
etc/etc.powerpc64/MAKEDEV.md
games/hack/hack.end.c
games/hack/hack.shk.c
games/bs/bs.c
games/atc/update.c
games/phantasia/phantstruct.h
games/cribbage/cribcur.h
games/backgammon/backgammon/move.c
games/canfield/canfield/canfield.c
include/rpc/auth_unix.h
include/protocols/talkd.h
include/Makefile
include/resolv.h
lib/libkeynote/keynote-ver.l
lib/libkeynote/keynote-verify.c
lib/libkeynote/keynote.l
lib/libkeynote/keynote.y
lib/libpcap/grammar.y
lib/libpcap/optimize.c
lib/libfido2/src/u2f.c
lib/libcurses/tinfo/MKfallback.sh
lib/libform/form.h
lib/libsndio/sio_aucat.c
lib/csu/hppa/md_init.h
lib/libcrypto/engine/eng_cnf.c
lib/libcrypto/sha/asm/sha1-586.pl
lib/libcrypto/modes/gcm128.c
lib/libcrypto/modes/cfb128.c
lib/libcrypto/objects/objects.txt
lib/libcrypto/perlasm/x86_64-xlate.pl
lib/libcrypto/x509/x509_pmaps.c
lib/libcrypto/x509/x509.h
lib/libcrypto/rsa/rsa_lib.c
lib/libcrypto/whrlpool/wp_dgst.c
lib/libcrypto/util/mkstack.pl
lib/libcrypto/aes/asm/bsaes-x86_64.pl
lib/libm/src/e_log.c
lib/libm/src/e_fmod.c
lib/libm/src/e_rem_pio2f.c
lib/libm/src/e_cosh.c
lib/libm/src/e_rem_pio2.c
lib/libm/src/e_lgammaf_r.c
lib/libm/src/s_log1pf.c
lib/libm/src/s_expm1f.c
lib/libm/src/e_atan2f.c
lib/libm/src/s_log1p.c
lib/libm/src/e_sinh.c
lib/libm/src/s_erf.c
lib/libm/src/e_jnf.c
lib/libm/src/e_logf.c
lib/libm/src/k_rem_pio2.c
lib/libm/src/e_atan2.c
lib/libm/src/e_remainderf.c
lib/libm/src/k_rem_pio2f.c
lib/libm/src/s_expm1.c
lib/libm/src/e_sqrt.c
lib/libm/src/e_jn.c
lib/libm/src/e_fmodf.c
lib/libm/src/k_cos.c
lib/libm/src/e_lgamma_r.c
lib/libm/src/k_tan.c
lib/libm/src/e_expf.c
lib/libm/src/e_atan2l.c
lib/libm/src/k_sin.c
lib/libc/db/btree/bt_split.c
lib/libc/db/hash/hash.h
lib/libc/gdtoa/ldtoa.c
lib/libc/arch/powerpc/string/memmove.S
lib/libc/arch/amd64/string/ffs.S
lib/libc/arch/powerpc64/string/memmove.S
lib/libc/arch/i386/string/ffs.S
lib/libc/stdlib/merge.c
lib/libc/stdlib/malloc.c
lib/libc/stdlib/getopt_long.3
lib/libc/time/localtime.c
lib/libc/stdio/fvwrite.c
lib/libc/stdio/vfwscanf.c
lib/libmenu/eti.h
lib/libssl/d1_both.c
lib/libssl/ssl3.h
lib/libssl/tls1.h
libexec/ld.so/aarch64/SYS.h
libexec/ld.so/riscv64/SYS.h
libexec/tradcpp/array.h
libexec/login_ldap/aldap.h
libexec/spamd/grey.c
regress/lib/libm/msun/ctrig_test.c
regress/lib/libm/msun/invctrig_test.c
regress/lib/libc/popen/popen.c
regress/lib/libc/arch/alpha/divremtest/divremtest.c
regress/sys/kern/unveil/syscalls.c
regress/usr.bin/ssh/unittests/misc/test_strdelim.c
regress/usr.bin/tsort/tsort-check
regress/usr.bin/openssl/appstest.sh
regress/usr.sbin/pkg_add/Makefile
regress/bin/ksh/bksl-nl.t
regress/bin/ksh/th
sbin/dhcpleased/parse.y
sbin/ipsecctl/parse.y

Re: [patch] add show.c style flag descriptions to route(8)

[Paul Tagliamonte]

Good news, I've got my MUA sorted. Hopefully this fixes the issues with
the CVS diffs in my reply body.

On Wed, Dec 21, 2022 at 10:09:24PM +, Jason McIntyre wrote:
> i like the choice of "display" over "print out".
> i don;t like the "related metadata" bit though.
> 
> what about just
> 
>   Display the routing table.

done.

> you should start new sentences on new lines.

understood, done.

> i would not remove the Xr. i think if we go ahead with this, we can make
> a separate commit where we point people to route(8) rather than
> netstart(8), but i suspect many pages will both want references to both.

makes sense, done.

> except for that, diff seems fine.

updated patch for review attached; thank you for your (very fast!) review.
On the off-chance I've dorked it up, i've attached it, but I think we
should be sorted.

  paultag

-- 
:wq

Index: sbin/route/route.8
===
RCS file: /cvs/src/sbin/route/route.8,v
retrieving revision 1.106
diff -u -p -r1.106 route.8
--- sbin/route/route.8  19 Nov 2022 19:23:37 -  1.106
+++ sbin/route/route.8  21 Dec 2022 22:12:12 -
@@ -197,10 +197,7 @@ the given interface is sent.
 .Op Fl label Ar label
 .Op Fl priority Ar priority
 .Xc
-Print out the routing table, in a fashion similar to "netstat -r".
-The output is documented in more detail towards the end of the
-.Xr netstat 1
-manual.
+Display the routing table.
 .Pp
 If
 .Fl gateway
@@ -224,6 +221,31 @@ or
 .Cm bgp .
 If the priority is negative, then routes that do not match the numeric
 priority are shown.
+.Pp
+The "Flags" column indicates what flags are set on the route.
+The mapping between letters and flags is:
+.Bl -column "1" "RTF_BLACKHOLE" "Protocol specific routing flag #1."
+.It 1 Ta Dv RTF_PROTO1 Ta "Protocol specific routing flag #1."
+.It 2 Ta Dv RTF_PROTO2 Ta "Protocol specific routing flag #2."
+.It 3 Ta Dv RTF_PROTO3 Ta "Protocol specific routing flag #3."
+.It B Ta Dv RTF_BLACKHOLE Ta "Just discard pkts (during updates)."
+.It b Ta Dv RTF_BROADCAST Ta "Correspond to a local broadcast address."
+.It C Ta Dv RTF_CLONING Ta "Generate new routes on use."
+.It c Ta Dv RTF_CLONED Ta "Cloned routes (generated from RTF_CLONING)."
+.It D Ta Dv RTF_DYNAMIC Ta "Created dynamically (by redirect)."
+.It G Ta Dv RTF_GATEWAY Ta "Destination requires forwarding by intermediary."
+.It H Ta Dv RTF_HOST Ta "Host entry (net otherwise)."
+.It h Ta Dv RTF_CACHED Ta "Referenced by gateway route."
+.It L Ta Dv RTF_LLINFO Ta "Valid protocol to link address translation."
+.It l Ta Dv RTF_LOCAL Ta "Correspond to a local address."
+.It M Ta Dv RTF_MODIFIED Ta "Modified dynamically (by redirect)."
+.It m Ta Dv RTF_MULTICAST Ta "Correspond to a multicast address."
+.It n Ta Dv RTF_CONNECTED Ta "Interface route."
+.It P Ta Dv RTF_MPATH Ta "Multipath route."
+.It R Ta Dv RTF_REJECT Ta "Host or net unreachable."
+.It S Ta Dv RTF_STATIC Ta "Manually added."
+.It T Ta Dv RTF_MPLS Ta "MPLS route."
+.It U Ta Dv RTF_UP Ta "Route usable."
 .El
 .Pp
 .Bl -tag -width Fl -compact
Index: usr.bin/netstat/netstat.1
===
RCS file: /cvs/src/usr.bin/netstat/netstat.1,v
retrieving revision 1.95
diff -u -p -r1.95 netstat.1
--- usr.bin/netstat/netstat.1   8 Sep 2022 13:18:47 -   1.95
+++ usr.bin/netstat/netstat.1   21 Dec 2022 22:12:13 -
@@ -343,31 +343,6 @@ and
 .Xr route 4
 manual pages.
 .Pp
-The mapping between letters and flags is:
-.Bl -column "1" "RTF_BLACKHOLE" "Protocol specific routing flag #1."
-.It 1 Ta Dv RTF_PROTO1 Ta "Protocol specific routing flag #1."
-.It 2 Ta Dv RTF_PROTO2 Ta "Protocol specific routing flag #2."
-.It 3 Ta Dv RTF_PROTO3 Ta "Protocol specific routing flag #3."
-.It B Ta Dv RTF_BLACKHOLE Ta "Just discard pkts (during updates)."
-.It b Ta Dv RTF_BROADCAST Ta "Correspond to a local broadcast address."
-.It C Ta Dv RTF_CLONING Ta "Generate new routes on use."
-.It c Ta Dv RTF_CLONED Ta "Cloned routes (generated from RTF_CLONING)."
-.It D Ta Dv RTF_DYNAMIC Ta "Created dynamically (by redirect)."
-.It G Ta Dv RTF_GATEWAY Ta "Destination requires forwarding by intermediary."
-.It H Ta Dv RTF_HOST Ta "Host entry (net otherwise)."
-.It h Ta Dv RTF_CACHED Ta "Referenced by gateway route."
-.It L Ta Dv RTF_LLINFO Ta "Valid protocol to link address translation."
-.It l Ta Dv RTF_LOCAL Ta "Correspond to a local address."
-.It M Ta Dv RTF_MODIFIED Ta "Modified dynamically (by redirect)."
-.It m Ta Dv RTF_MULTICAST Ta "Correspond to a multicast address."
-.It n Ta Dv RTF_CONNECTED Ta "Interface route."
-.It P Ta Dv RTF_MPATH Ta "Multipath route."
-.It R Ta Dv RTF_REJECT Ta "Host or net unreachable."
-.It S Ta Dv RTF_STATIC Ta "Manually added."
-.It T Ta Dv RTF_MPLS Ta "MPLS route."
-.It U Ta Dv RTF_UP Ta "Route usable."
-.El
-.Pp
 Direct routes are created for each interface attached to the local host;
 the gateway field for such entries shows the address of the outgoing 

Bug#1025210: ITP: rtlamr -- RTL-SDR receiver for smart utility meters

[Paul Tagliamonte]

Hey John,

Debian Developer, Amateur Radio nerd (K3XEC), and Go team member here.

I use rtlamr. I'm not a very good sponsor right now, but I can step in if
no one else has bandwidth; my time is a bit more limited than I'd like, and
it'd be cool to have rtlamr in the repos. It'd certainly help save me time
too! Give it a few days to see if anyone here has bandwidth, and if not,
send me your dsc or git repo for review.

On your other points:

rtlamr talks to the rtlsdr via rtltcp (rtl_tcp(1)). It's a simple protocol
I documented at https://hz.tools/rtl_tcp/ . I've also written a daemon for
myself while learning about radio (not released yet; for a few reasons)
that will serve a few radios over rtl_tcp; namely, my Ettus B210/B200mini,
LimeSDR, RTL-SDR, HackRF, PlutoSDR, an airspyhf, or hilariously, another
rtl_tcp endpoint (yo dawg).

The hardest part of this exercise (and to be clear; it's straightforward),
are two big things:

  - translating IQ formats; which I've done a bit of documentation on
https://k3xec.com/packrat-processing-iq/ including some exemplar files to
test with to build confidence in your code
  - accepting rtl_tcp commands (such as AGC enable, Set Gain) - which don't
always translate 1:1. For instance ,some radios don't have automatic gain
control, so the command isn't supported; but the client will expect it to
be enabled. Other radios (like the HackRF, for instance) have multiple gain
stages -- which you can kinda cobble together if you pretend to be a
RTL-SDR E4k (https://hz.tools/e4k/) in the rtl_tcp header, and store the IF
gain stages in memory, compute the net gain, and scale the gain from min to
max -- proxying that into the real radio's gain from min to max.

   paultag



On Wed, Nov 30, 2022 at 6:06 PM John Scott  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: John Scott 
> X-Debbugs-Cc: debian-de...@lists.debian.org, debian-h...@lists.debian.org,
> debian...@lists.debian.org
>
> * Package name: rtlamr
>   Version : 0.9.1
>   Upstream Author : Douglas Hall
> * URL : https://github.com/bemasher/rtlamr
> * License : AGPLv3 only
>   Programming Lang: Go
>   Description : RTL-SDR receiver for smart utility meters
>
> rtlamr is a program for using an RTL-SDR (and maybe other SDRs?) to
> receive readings from smart utility meters. I use this software, an willing
> to maintain it, and will make sure it stays in good shape. I have confirmed
> that it works with commonly available meters.
>
> This is useful for a variety of creative purposes, such as analyzing one's
> own energy usage, or even energy usage within a community, or to identify
> water leaks. As far as I know, no other packages provide similar
> functionality. The closest package is rtl_433, and it doesn't support these
> devices.
>
> I'm neither DD nor DM and will need a sponsor. I will maintain this either
> within the Go Team or the Ham Radio Team. I've CC'ed both of them to see if
> it piques their interest or if they have a preference.
>
> I would really like it if a fellow ham would see about getting it to work
> with an alternate SDR.
>


-- 
:wq

Bug#1025210: ITP: rtlamr -- RTL-SDR receiver for smart utility meters

[Paul Tagliamonte]

Hey John,

Debian Developer, Amateur Radio nerd (K3XEC), and Go team member here.

I use rtlamr. I'm not a very good sponsor right now, but I can step in if
no one else has bandwidth; my time is a bit more limited than I'd like, and
it'd be cool to have rtlamr in the repos. It'd certainly help save me time
too! Give it a few days to see if anyone here has bandwidth, and if not,
send me your dsc or git repo for review.

On your other points:

rtlamr talks to the rtlsdr via rtltcp (rtl_tcp(1)). It's a simple protocol
I documented at https://hz.tools/rtl_tcp/ . I've also written a daemon for
myself while learning about radio (not released yet; for a few reasons)
that will serve a few radios over rtl_tcp; namely, my Ettus B210/B200mini,
LimeSDR, RTL-SDR, HackRF, PlutoSDR, an airspyhf, or hilariously, another
rtl_tcp endpoint (yo dawg).

The hardest part of this exercise (and to be clear; it's straightforward),
are two big things:

  - translating IQ formats; which I've done a bit of documentation on
https://k3xec.com/packrat-processing-iq/ including some exemplar files to
test with to build confidence in your code
  - accepting rtl_tcp commands (such as AGC enable, Set Gain) - which don't
always translate 1:1. For instance ,some radios don't have automatic gain
control, so the command isn't supported; but the client will expect it to
be enabled. Other radios (like the HackRF, for instance) have multiple gain
stages -- which you can kinda cobble together if you pretend to be a
RTL-SDR E4k (https://hz.tools/e4k/) in the rtl_tcp header, and store the IF
gain stages in memory, compute the net gain, and scale the gain from min to
max -- proxying that into the real radio's gain from min to max.

   paultag



On Wed, Nov 30, 2022 at 6:06 PM John Scott  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: John Scott 
> X-Debbugs-Cc: debian-de...@lists.debian.org, debian-h...@lists.debian.org,
> debian...@lists.debian.org
>
> * Package name: rtlamr
>   Version : 0.9.1
>   Upstream Author : Douglas Hall
> * URL : https://github.com/bemasher/rtlamr
> * License : AGPLv3 only
>   Programming Lang: Go
>   Description : RTL-SDR receiver for smart utility meters
>
> rtlamr is a program for using an RTL-SDR (and maybe other SDRs?) to
> receive readings from smart utility meters. I use this software, an willing
> to maintain it, and will make sure it stays in good shape. I have confirmed
> that it works with commonly available meters.
>
> This is useful for a variety of creative purposes, such as analyzing one's
> own energy usage, or even energy usage within a community, or to identify
> water leaks. As far as I know, no other packages provide similar
> functionality. The closest package is rtl_433, and it doesn't support these
> devices.
>
> I'm neither DD nor DM and will need a sponsor. I will maintain this either
> within the Go Team or the Ham Radio Team. I've CC'ed both of them to see if
> it piques their interest or if they have a preference.
>
> I would really like it if a fellow ham would see about getting it to work
> with an alternate SDR.
>


-- 
:wq

Re: [pkg-go] Bug#1025210: ITP: rtlamr -- RTL-SDR receiver for smart utility meters

[Paul Tagliamonte]

Hey John,

Debian Developer, Amateur Radio nerd (K3XEC), and Go team member here.

I use rtlamr. I'm not a very good sponsor right now, but I can step in if
no one else has bandwidth; my time is a bit more limited than I'd like, and
it'd be cool to have rtlamr in the repos. It'd certainly help save me time
too! Give it a few days to see if anyone here has bandwidth, and if not,
send me your dsc or git repo for review.

On your other points:

rtlamr talks to the rtlsdr via rtltcp (rtl_tcp(1)). It's a simple protocol
I documented at https://hz.tools/rtl_tcp/ . I've also written a daemon for
myself while learning about radio (not released yet; for a few reasons)
that will serve a few radios over rtl_tcp; namely, my Ettus B210/B200mini,
LimeSDR, RTL-SDR, HackRF, PlutoSDR, an airspyhf, or hilariously, another
rtl_tcp endpoint (yo dawg).

The hardest part of this exercise (and to be clear; it's straightforward),
are two big things:

  - translating IQ formats; which I've done a bit of documentation on
https://k3xec.com/packrat-processing-iq/ including some exemplar files to
test with to build confidence in your code
  - accepting rtl_tcp commands (such as AGC enable, Set Gain) - which don't
always translate 1:1. For instance ,some radios don't have automatic gain
control, so the command isn't supported; but the client will expect it to
be enabled. Other radios (like the HackRF, for instance) have multiple gain
stages -- which you can kinda cobble together if you pretend to be a
RTL-SDR E4k (https://hz.tools/e4k/) in the rtl_tcp header, and store the IF
gain stages in memory, compute the net gain, and scale the gain from min to
max -- proxying that into the real radio's gain from min to max.

   paultag



On Wed, Nov 30, 2022 at 6:06 PM John Scott  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: John Scott 
> X-Debbugs-Cc: debian-de...@lists.debian.org, debian-h...@lists.debian.org,
> debian...@lists.debian.org
>
> * Package name: rtlamr
>   Version : 0.9.1
>   Upstream Author : Douglas Hall
> * URL : https://github.com/bemasher/rtlamr
> * License : AGPLv3 only
>   Programming Lang: Go
>   Description : RTL-SDR receiver for smart utility meters
>
> rtlamr is a program for using an RTL-SDR (and maybe other SDRs?) to
> receive readings from smart utility meters. I use this software, an willing
> to maintain it, and will make sure it stays in good shape. I have confirmed
> that it works with commonly available meters.
>
> This is useful for a variety of creative purposes, such as analyzing one's
> own energy usage, or even energy usage within a community, or to identify
> water leaks. As far as I know, no other packages provide similar
> functionality. The closest package is rtl_433, and it doesn't support these
> devices.
>
> I'm neither DD nor DM and will need a sponsor. I will maintain this either
> within the Go Team or the Ham Radio Team. I've CC'ed both of them to see if
> it piques their interest or if they have a preference.
>
> I would really like it if a fellow ham would see about getting it to work
> with an alternate SDR.
>


-- 
:wq
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: Results for Voting secrecy

[Paul Tagliamonte]

> Please reconsider. Otherwise the project's sole alternative may be to
> replace the Project Secretary.
>

Let me get this straight --

You (a seconder of the winning option) now believe that we need to stop and
re-open
discussion on a closed matter  that the whole project voted on (which I
believe you've
been a staunch advocate for in the past - GRs are good, democracy, etc,
right?),
single-handedly overturning the results, because you now have changed your
views
on your own amendment that won, and you now believe the constitution is
weakened
such that you're now threatening to remove the Secretary because you
disagree with
their reading of the rules (who's executed the role of reading those rules
since 2009
without prior issue) that is their role in the project to read?

Just checking. Do I have that right?

  Paul



-- 
:wq

Re: Please avoid using ambiguous language

[Paul Tagliamonte]

No fighting words, I think - it really just means kibi is doing the
work of 1,024 others!

On Wed, Mar 23, 2022 at 11:18 AM Adam Borowski  wrote:
>
> On Wed, Mar 23, 2022 at 03:05:09PM +, Samuel Henrique wrote:
> > On Wed 23 Mar 2022, 14:55 Paul Tagliamonte,  wrote:
> >
> > > According to nm.d.o, we have 1.022 kilomembers (kDd).
> >
> > So we're only 2 DD's away from 1 kibimember (KiDd)?
>
> Redefining the pi^Wbinary prefix is fighting words!
>
> (No hostility meant towards Cyril Brulebois, just towards his nick :p)
>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀ Eight legs good, four legs bad! -- when your drider pwns a
> ⣾⠁⢠⠒⠀⣿⡁ smelly goodie centaur.
> ⢿⡄⠘⠷⠚⠋⠀ Rearkick OP -- my grandpa's brother-in-law got one-shotted
> ⠈⠳⣄ from full hp in RL, please nerf!
>


-- 
All programmers are playwrights, and all computers are lousy actors.

#define sizeof(x) rand()
:wq

Re: Banning Norbert Preining from planet.d.o

[Paul Tagliamonte]

I was also very very surprised to hear we allow members removed
because of their toxic behavior still allowed to use project resources
to amplify the very things that got them removed in the first place.

No idea why we wouldn't have removed the blog of anyone expelled from
planet.d.o as part of that action. It seems wholly inappropriate to
keep any expelled member of Debian's blog on the planet.


On Wed, Mar 23, 2022 at 11:02 AM Wouter Verhelst  wrote:
>
> On Wed, Mar 23, 2022 at 02:51:10PM +0100, Adam Borowski wrote:
> > On Wed, Mar 23, 2022 at 08:38:02AM +0200, Jonathan Carter wrote:
> > > > Can we delete him from planet?
> > >
> > > Any DD can do that... oh wait that includes me... done!
> >
> > I went bold and reverted this removal; the detailed reason why and the
> > Planet rules I believe Jonathan has breached are in the commit message.
>
> I'm not going to play commit ping pong, but why do you think it is
> appropriate to continue to have someone on Planet Debian whom we have
> banned from the project, and whose appeal for that ban was rejected?
>
> Honestly, I was surprised to learn he still *was* on Planet. I don't
> think it makes any sense at all to keep people on Planet Debian who we
> threw out for cause.
>
> --
>  w@uter.{be,co.za}
> wouter@{grep.be,fosdem.org,debian.org}
>


-- 
:wq

Re: Please avoid using ambiguous language

[Paul Tagliamonte]

According to nm.d.o, we have 1.022 kilomembers (kDd).

The udd is tracking roughly 2.28 megapackages (Mdeb) built from 218
kilosources (kDsc).

On Wed, Mar 23, 2022 at 10:43 AM Elena ``of Valhalla''
 wrote:
>
> On debian-private somebody wrote (leaked with permission):
> > some billion(*)
> > (*) German: Milliarden
>
> Can we please decide as a project to avoid using ambiguous English words
> like billion or trillion and move to proper SI prefixes or exponential
> notation, as appropriate?
>
> We would also have to decide how to decide this, of course, and then how
> to enforce the decision, whatever that is.
>
> I believe this would be enough material for at least a baker's dozen new
> threads on the appropriate mailing lists, plus the spurious ones on
> inappopriate ones. :D
>
> --
> Elena ``of Valhalla''



-- 
All programmers are playwrights, and all computers are lousy actors.

#define sizeof(x) rand()
:wq

Bug#938987: Hit this as well on sid

[Paul Tagliamonte]

Hey folks,

I hit this on sid. nsd is failing to start with a sensible config,
done within the bounds of allowed NSD configuration, and fails to
start. This has taken me a huge amount of time to track down.

What is the NSD maintainer's opinion of the correct way to get nsd to
behave with a sensible config, here? I'm reluctant to trim caps, since
tightening them seems good, but they're too tight, it appears.

  paultag

-- 
:wq

Re: Compiled list

[Paul Tagliamonte]

STIGs are maintained by DISA, not by Debian

  Paul

On Wed, Mar 2, 2022 at 9:42 AM Stephanie Hall  wrote:

> Good morning,
>
> Do you have an excel version of a STIG for Debian 9 & 10 that you would be
> willing to share?
>
> Thank you in advance!
>
> --
>
> Stephanie Hall
>
> Oteemo, Inc. 
>
> Sr. Consultant, Cybersecurity
>
> m: (315)-723-9951
>
> e: sh...@oteemo.com
>
>
> 
> 
>
> Oteemo Customer Love 
>
>
>


-- 
All programmers are playwrights, and all computers are lousy actors.

#define sizeof(x) rand()
:wq

History doesn't repeat itself, but it often rhymes

[Paul Tagliamonte]

Hello, Debianites,

Allow me, if you will, to talk a bit about something that's been on my mind
a bit over the last handful of years in Debian. It's something that's pretty
widely circulated in particular circles, but I don't think I've seen it on
a Debian list before, so here's some words that I've decided to put together.


I've intentionally not drawn lines to the 'discussions' going on (or the
'discussions' in the past I could point to) to avoid getting dragged into more
thrash, so if you reply, please do try to keep this clear of any specific
argument that you feel this may or may not apply to. This is a more general
note that I think could use some thought from anyone who's interested.


During World War II, the OSS (Office of Strategic Services)[1] distributed a
manual[2] (the Simple Sabotage Field Manual), which was used to train
"citizen-saboteur" resistance fighters, some of whom were told, not to pick up
arms, but to confound the bureaucracy by tying it up with an unmanageable
tangle of "innocent" behavior.

While no one is working within the Debian community member attempting to
subvert us sent from the shady conglomerate of nonfree operating systems by
following this playbook, this playbook is an outstanding illustration of how
some innocent behavior can destroy the effectiveness of an organization.  It's
effective, precisely *because* it's not overly malicious, and these behaviors
-- while harmful -- are explainable or innocent. Section (3) covers this in
detail.

Most of the OSS Simple Sabotage Field Manual covers things like breaking
equipment or destroying tanks, but section (11) is "General Interference with
Organizations and Production". I'm just going to focus here.

Let's take a look at section (11):

> (1) Insist on doing everything through "channels." Never permit short-cuts
> to be taken in order to expedite decisions.
>
> (2) Make "speeches." Talk as frequently as possible and at great length.
> Illustrate your "points" by long anecdotes and accounts of personal
> experiences. Never hesitate to make a few appropriate "patriotic" 
> comments.
>
> (3) When possible, refer all matters to committees for "further study and
> consideration." Attempt to make committees as large as possible -- never
> less than five.
>
> (4) Bring up irrelevant issues as frequently as possible.
>
> (5) Haggle over precise wordings of communications, minutes, resolutions.
>
> (6) Refer back to matters decided upon at the last meeting and attempt to
> re-open the advisability of that decision.
>
> (7) Advocate "caution." Be "reasonable" and urge your fellow co-conferees to
> be "reasonable" and avoid haste which might result in embarrassments or
> difficulties later on.
>
> (8) Be worried about the propriety of any decision - raise the question of
> whether such action as is contemplated lies within the jurisdiction of
> the group or whether it might conflict with the policy of some higher
> echelon.

I won't go through each of these point-by-point since everyone reading this is
likely sharp enough to see how this relates to Debian (although I will point
out I find it particularly interesting to replace "patrotic" here with the
Debian-specific-patriotism -- Debianism? -- and re-read some of the more
heated threads)



I have a theory of large organizations I've been thinking a lot about that came
from conversations with a colleague, which is to think about an organization's
"metabolic overhead" -- i.e., the amount of energy that an organization
devotes to intra-organization communication. If you think about a car
manufacturing plant, the "metabolic overhead" is all the time spent on things
like paperwork, communication, planning. It's not possible (or desirable!) for
an organization to have 0% overhead, nor is it desirable (although this one *is*
possible) to spend 100% time on overhead. I think it *may* be possible to get
to above 100% overhead, if workplace contention spills out into drinks after
work.

All of the points in the OSS Simple Sabotage Manual are things designed to
increase the metabolic overhead of an organization, and to force organization
members to spend time *not* doing their core function (like making cars,
running trash pickup or ensuring the city has electricity), but rather, spend
their time litigating amongst themselves as the core function begins to
become harder and harder to maintain. This has the effect of degrading the
output/core function of an organization, without any specific cause
(like a power loss, etc).

I'd ask those who are reading this to consider how this relates to their time
spent in Debian. Is what you find something you're happy about with a hobby
project you're choosing to spend your free time on? Are you taking actions to
be a good participant?



To do a bit of grandstanding myself, do remember that it's not just your time
here -- when we spend significant resources litigating and playing bureaucracy
games, we spend 

History doesn't repeat itself, but it often rhymes

[Paul Tagliamonte]

Hello, Debianites,

Allow me, if you will, to talk a bit about something that's been on my mind
a bit over the last handful of years in Debian. It's something that's pretty
widely circulated in particular circles, but I don't think I've seen it on
a Debian list before, so here's some words that I've decided to put together.


I've intentionally not drawn lines to the 'discussions' going on (or the
'discussions' in the past I could point to) to avoid getting dragged into more
thrash, so if you reply, please do try to keep this clear of any specific
argument that you feel this may or may not apply to. This is a more general
note that I think could use some thought from anyone who's interested.


During World War II, the OSS (Office of Strategic Services)[1] distributed a
manual[2] (the Simple Sabotage Field Manual), which was used to train
"citizen-saboteur" resistance fighters, some of whom were told, not to pick up
arms, but to confound the bureaucracy by tying it up with an unmanageable
tangle of "innocent" behavior.

While no one is working within the Debian community member attempting to
subvert us sent from the shady conglomerate of nonfree operating systems by
following this playbook, this playbook is an outstanding illustration of how
some innocent behavior can destroy the effectiveness of an organization.  It's
effective, precisely *because* it's not overly malicious, and these behaviors
-- while harmful -- are explainable or innocent. Section (3) covers this in
detail.

Most of the OSS Simple Sabotage Field Manual covers things like breaking
equipment or destroying tanks, but section (11) is "General Interference with
Organizations and Production". I'm just going to focus here.

Let's take a look at section (11):

> (1) Insist on doing everything through "channels." Never permit short-cuts
> to be taken in order to expedite decisions.
>
> (2) Make "speeches." Talk as frequently as possible and at great length.
> Illustrate your "points" by long anecdotes and accounts of personal
> experiences. Never hesitate to make a few appropriate "patriotic" 
> comments.
>
> (3) When possible, refer all matters to committees for "further study and
> consideration." Attempt to make committees as large as possible -- never
> less than five.
>
> (4) Bring up irrelevant issues as frequently as possible.
>
> (5) Haggle over precise wordings of communications, minutes, resolutions.
>
> (6) Refer back to matters decided upon at the last meeting and attempt to
> re-open the advisability of that decision.
>
> (7) Advocate "caution." Be "reasonable" and urge your fellow co-conferees to
> be "reasonable" and avoid haste which might result in embarrassments or
> difficulties later on.
>
> (8) Be worried about the propriety of any decision - raise the question of
> whether such action as is contemplated lies within the jurisdiction of
> the group or whether it might conflict with the policy of some higher
> echelon.

I won't go through each of these point-by-point since everyone reading this is
likely sharp enough to see how this relates to Debian (although I will point
out I find it particularly interesting to replace "patrotic" here with the
Debian-specific-patriotism -- Debianism? -- and re-read some of the more
heated threads)



I have a theory of large organizations I've been thinking a lot about that came
from conversations with a colleague, which is to think about an organization's
"metabolic overhead" -- i.e., the amount of energy that an organization
devotes to intra-organization communication. If you think about a car
manufacturing plant, the "metabolic overhead" is all the time spent on things
like paperwork, communication, planning. It's not possible (or desirable!) for
an organization to have 0% overhead, nor is it desirable (although this one *is*
possible) to spend 100% time on overhead. I think it *may* be possible to get
to above 100% overhead, if workplace contention spills out into drinks after
work.

All of the points in the OSS Simple Sabotage Manual are things designed to
increase the metabolic overhead of an organization, and to force organization
members to spend time *not* doing their core function (like making cars,
running trash pickup or ensuring the city has electricity), but rather, spend
their time litigating amongst themselves as the core function begins to
become harder and harder to maintain. This has the effect of degrading the
output/core function of an organization, without any specific cause
(like a power loss, etc).

I'd ask those who are reading this to consider how this relates to their time
spent in Debian. Is what you find something you're happy about with a hobby
project you're choosing to spend your free time on? Are you taking actions to
be a good participant?



To do a bit of grandstanding myself, do remember that it's not just your time
here -- when we spend significant resources litigating and playing bureaucracy
games, we spend 

Bug#1004602: RFS: fluxbox/1.3.5-2.1 [NMU] [RC] -- Highly configurable and low resource X11 Window manager

[Paul Tagliamonte]

Does it have to be an NMU? :)

I must have missed the request for sponsorship directly; feel free to
revamp this as a regular upload and we can push it up.

  Paul

On Sun, Jan 30, 2022 at 3:54 PM Mateusz Łukasik  wrote:
>
> Package: sponsorship-requests
> Severity: important
>
> Dear mentors,
>
> I am looking for a sponsor for my package "fluxbox":
>
>  * Package name: fluxbox
>Version : 1.3.5-2.1
>Upstream Author : fluxbox maintainers
>  * URL : http://fluxbox.org
>  * License : CC-BY-SA-3, Expat
>  * Vcs : 
> http://git.debian.org/?p=collab-maint/fluxbox.git;a=summary
>Section : x11
>
> It builds those binary packages:
>
>   fluxbox - Highly configurable and low resource X11 Window manager
>
> To access further information about this package, please visit the following 
> URL:
>
>   https://mentors.debian.net/package/fluxbox/
>
> Alternatively, one can download the package with dget using this command:
>
>   dget -x 
> https://mentors.debian.net/debian/pool/main/f/fluxbox/fluxbox_1.3.5-2.1.dsc
>
> Changes since the last upload:
>
>  fluxbox (1.3.5-2.1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* Add debian/patches/fluxbox-1.3.7-c++17.patch from Gentoo for fix FTBFS
>  with GCC-11. (Closes: #984134)
>
> Regards,
> --
>   Mateusz Łukasik



-- 
:wq

Bug#1004602: RFS: fluxbox/1.3.5-2.1 [NMU] [RC] -- Highly configurable and low resource X11 Window manager

[Paul Tagliamonte]

Does it have to be an NMU? :)

I must have missed the request for sponsorship directly; feel free to
revamp this as a regular upload and we can push it up.

  Paul

On Sun, Jan 30, 2022 at 3:54 PM Mateusz Łukasik  wrote:
>
> Package: sponsorship-requests
> Severity: important
>
> Dear mentors,
>
> I am looking for a sponsor for my package "fluxbox":
>
>  * Package name: fluxbox
>Version : 1.3.5-2.1
>Upstream Author : fluxbox maintainers
>  * URL : http://fluxbox.org
>  * License : CC-BY-SA-3, Expat
>  * Vcs : 
> http://git.debian.org/?p=collab-maint/fluxbox.git;a=summary
>Section : x11
>
> It builds those binary packages:
>
>   fluxbox - Highly configurable and low resource X11 Window manager
>
> To access further information about this package, please visit the following 
> URL:
>
>   https://mentors.debian.net/package/fluxbox/
>
> Alternatively, one can download the package with dget using this command:
>
>   dget -x 
> https://mentors.debian.net/debian/pool/main/f/fluxbox/fluxbox_1.3.5-2.1.dsc
>
> Changes since the last upload:
>
>  fluxbox (1.3.5-2.1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* Add debian/patches/fluxbox-1.3.7-c++17.patch from Gentoo for fix FTBFS
>  with GCC-11. (Closes: #984134)
>
> Regards,
> --
>   Mateusz Łukasik



-- 
:wq

Re: Renaming the FTP Masters

[Paul Tagliamonte]

I agree. I also don't know if this is something we can just do with the DPL
or not.

The name master isn't great, as is ftp.

No one has suggested a name yet. If this was my proposal, I'd suggest the
debian archive team.

Why can't we just change the name without a GR between the ftpteam and DPL?

Paul

On Wed, Nov 3, 2021, 6:45 PM Scott Kitterman  wrote:

>
>
> On November 3, 2021 9:27:08 PM UTC, Felix Lechner <
> felix.lech...@lease-up.com> wrote:
> >Hi,
> >
> >I would like to rename the FTP Masters team—ideally via a General
> Resolution.
> >
> >Since the murder of George Floyd, the average fate of Black lives has
> >received much attention. Even the tech sector picked up the
> >"master/slave" topic over a year ago. [2][3][4]
> >
> >There should be little controversy. With a high pass rate, we could
> >all come together as a group—for our shared love of Debian and free
> >software!
> >
> >What do you think about the text below, please? Thanks for reading!
> >
> >Kind regards
> >Felix Lechner
> >
> >[1] https://en.wikipedia.org/wiki/Murder_of_George_Floyd
> >[2] https://www.wired.com/story/tech-confronts-use-labels-master-slave/
> >[3]
> https://www.cnet.com/news/master-and-slave-tech-terms-face-scrutiny-amid-anti-racism-efforts/
> >[4]
> https://www.nytimes.com/2021/04/13/technology/racist-computer-engineering-terms-ietf.html
> >
> >* * *
> >
> >PROPOSED TEXT
> >
> >In recognizance of the awful history of slavery, the Debian project
> >will rename the "FTP Masters" team. For a long time, the word "master"
> >has been associated with the grave injustices of slavery. [1]
> >
> >While there is a tradition in computing to label primary equipment as
> >a "master" and replicated equipment as "slaves" [2] the use of the
> >word "masters" for a group of people with special privileges [3]
> >shocks the conscience.
> >
> >Within that context, the team's use of the title "wizard" [4] was also
> >problematic. The Ku Klux Klan and its spinoffs used the title "wizard"
> >to style high officials. [5] The team will likewise discontinue the
> >use of the term "wizard" to designate any current or former members.
> >
> >Nothing in this resolution shall impair the continued use of the
> >"master/slave" analogy for technical equipment.
> >
> >"Without a struggle, there can be no progress." (Frederick Douglass)
> >
> >[1] https://en.wikipedia.org/wiki/History_of_slavery
> >[2] https://en.wikipedia.org/wiki/Master/slave_(technology)
> >[3] "The FTP masters can do everything in the archive.",
> >https://wiki.debian.org/Teams/FTPMaster
> >[4] "The FTP Wizard role consists of former team members",
> >https://ftp-master.debian.org/
> >[5] https://en.wikipedia.org/wiki/Grand_Wizard
> >
>
> I'd suggest if you want to change the name via GR, the text of the GR
> should give the new name.  Otherwise, it could drag on for a very long time.
>
> Regardless of how one might feel about changing the names, it should be
> done quickly if it's to be done.
>
> Scott K
>
>

Bug#995491: ath11k regression for Dell XPS 13 9310 breaks WiFi

[Paul Tagliamonte]

Package: linux
Version: 5.14.6-3
Tags: fixed-upstream
Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=214455
thanks

After updating my kernel, my Dell XPS 13's WiFi stopped working. This
is related to an upstream changeset introduced in 5.14.5 and 5.13.18;
and is fixed in 5.14.7.

The patch is present in
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/patch/net/qrtr?id=d2cabd2dc8da78faf9b690ea521d03776686c9fe

I suspect we don't want to carry this patch, I'm opening this bug to
make this a bit more discoverable to other Dell XPS ath11k users, and
to have any related discussion in one place. I suspect we'll all have
to wait until 5.14.7+ is sent up to sid; which should be fine.

Thanks for your work maintaining Linux,
  Paul


-- 
:wq

Bug#995491: ath11k regression for Dell XPS 13 9310 breaks WiFi

[Paul Tagliamonte]

Package: linux
Version: 5.14.6-3
Tags: fixed-upstream
Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=214455
thanks

After updating my kernel, my Dell XPS 13's WiFi stopped working. This
is related to an upstream changeset introduced in 5.14.5 and 5.13.18;
and is fixed in 5.14.7.

The patch is present in
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/patch/net/qrtr?id=d2cabd2dc8da78faf9b690ea521d03776686c9fe

I suspect we don't want to carry this patch, I'm opening this bug to
make this a bit more discoverable to other Dell XPS ath11k users, and
to have any related discussion in one place. I suspect we'll all have
to wait until 5.14.7+ is sent up to sid; which should be fine.

Thanks for your work maintaining Linux,
  Paul


-- 
:wq

Re: Debian package manager privilege escalation attack

[Paul Tagliamonte]

> The focus of the article is "sudo access *only* to apt". When we talk
> about unrestricted sudo access it doesn't even make sense to talk about
> privilege escalation because unrestricted sudo is by design a privilege
> escalation.

Similarly, sudo access *only* to bash enables execution of loads of things.

Hand-installing a user-provided deb could do things like put suid root
binaries on the filesystem, too.


  Paul

--
:wq

Re: General resolution: ratify https://github.com/rms-open-letter/rms-open-letter.github.io

[Paul Tagliamonte]

Confirmed.

On Wed, Mar 24, 2021, 5:33 PM Steve Langasek  wrote:

> On Wed, Mar 24, 2021 at 10:16:44PM +0100, Nicolas Dandrimont wrote:
> > On Wed, Mar 24, 2021 at 01:54:16PM -0700, Steve Langasek wrote :
> > > Under 4.1.5 of the Constitution, the developers by way of GR are the
> body
> > > who has the power to issue nontechnical statements.
> > >
> > >
> https://github.com/rms-open-letter/rms-open-letter.github.io/blob/main/index.md
> > > is a statement which I believe Debian as a project, and not just
> individual
> > > Debian developers, should consider signing on to.
> > >
> > > This is a proposal for Debian to sign on to the statement, by adopting
> the
> > > text from that open letter via GR.
> > >
> > >  Text of GR 
> > >
> > > The Debian Project co-signs the statement regarding Richard Stallman's
> > > readmission to the FSF seen at
> > >
> https://github.com/rms-open-letter/rms-open-letter.github.io/blob/main/index.md.
>
> > > The text of this statement is given below.
> > >
> > > [...]
> > >
> > >  End Text of GR 
>
> > Seconded.
>
> > (I'll also second an amended text with s/FSF/FSF board/ or equivalent
> > correction)
>
> I accept an amendment to include the word "board" (which was missed on
> accident by me) and would ask the seconders to confirm their acceptance of
> this amendment so we can avoid any unnecessary extra variations on the GR
> ballot.
>
> --
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org
>

Bug#985149: debootstrap stumbles over tabs in include parameter

[Paul Tagliamonte]

>From a quick glance, it looks like `leftoverdebs` is initially a list of
packages, but in the suite/compoenent loop, leftoverdebs is assigned to the
package sizes.

...
leftoverdebs=$(printf "$leftoverdebs"|tr ' ' '\n'|sort -u|tr '\n' ' ')

leftoverdebs="$(get_package_sizes "$m1" "$pkgdest" $leftoverdebs)"

error 1 LEFTOVERDEBS "Couldn't find these debs: %s" "$leftoverdebs"

The output number appears to be the package sizes. Very confusing output
error message indeed!

  paultag

-- 
:wq

Bug#985149: debootstrap stumbles over tabs in include parameter

[Paul Tagliamonte]

>From a quick glance, it looks like `leftoverdebs` is initially a list of
packages, but in the suite/compoenent loop, leftoverdebs is assigned to the
package sizes.

...
leftoverdebs=$(printf "$leftoverdebs"|tr ' ' '\n'|sort -u|tr '\n' ' ')

leftoverdebs="$(get_package_sizes "$m1" "$pkgdest" $leftoverdebs)"

error 1 LEFTOVERDEBS "Couldn't find these debs: %s" "$leftoverdebs"

The output number appears to be the package sizes. Very confusing output
error message indeed!

  paultag

-- 
:wq

Bug#977004: Please enable CONFIG_ATH11K for the XPS 13 9310

[Paul Tagliamonte]

Makes total sense! I will file a bug there as well!

Paul

On Thu, Dec 10, 2020 at 9:06 AM Vincent Blut  wrote:

> Hi Paul,
>
> Le 2020-12-09T17:48-0500, Paul Tagliamonte a écrit :
> >Package: linux
> >Severity: wishlist
> >thanks
> >
> >Hello Linux maintainers,
> >
> >The spiffy new Dell XPS 13 9310 is shipping, but is not sold as supporting
> >linux yet -- but appears to work great, with the exception of the Qualcomm
> >Technologies 802.11ax chipset.
> >
> >I installed Linux from experimental, and am able to confirm the driver is
> >not loaded. I believe CONFIG_ATH11K could be enabled to support this
> >platform.
> >
> >Happy to reproduce and/or try images out to confirm! This isn't a daily
> >machine yet.
>
> Newer version of firmware-atheros will be needed too since the one we
> currently provide contains no ath11k firmware blobs.
>
> >Thank you very much!
> >  Paul
>
> Cheers,
> Vincent
>


-- 
:wq

Bug#977004: Please enable CONFIG_ATH11K for the XPS 13 9310

[Paul Tagliamonte]

Makes total sense! I will file a bug there as well!

Paul

On Thu, Dec 10, 2020 at 9:06 AM Vincent Blut  wrote:

> Hi Paul,
>
> Le 2020-12-09T17:48-0500, Paul Tagliamonte a écrit :
> >Package: linux
> >Severity: wishlist
> >thanks
> >
> >Hello Linux maintainers,
> >
> >The spiffy new Dell XPS 13 9310 is shipping, but is not sold as supporting
> >linux yet -- but appears to work great, with the exception of the Qualcomm
> >Technologies 802.11ax chipset.
> >
> >I installed Linux from experimental, and am able to confirm the driver is
> >not loaded. I believe CONFIG_ATH11K could be enabled to support this
> >platform.
> >
> >Happy to reproduce and/or try images out to confirm! This isn't a daily
> >machine yet.
>
> Newer version of firmware-atheros will be needed too since the one we
> currently provide contains no ath11k firmware blobs.
>
> >Thank you very much!
> >  Paul
>
> Cheers,
> Vincent
>


-- 
:wq

Bug#977004: Please enable CONFIG_ATH11K for the XPS 13 9310

[Paul Tagliamonte]

Package: linux
Severity: wishlist
thanks

Hello Linux maintainers,

The spiffy new Dell XPS 13 9310 is shipping, but is not sold as supporting
linux yet -- but appears to work great, with the exception of the Qualcomm
Technologies 802.11ax chipset.

I installed Linux from experimental, and am able to confirm the driver is
not loaded. I believe CONFIG_ATH11K could be enabled to support this
platform.

Happy to reproduce and/or try images out to confirm! This isn't a daily
machine yet.

Thank you very much!
  Paul

Bug#977004: Please enable CONFIG_ATH11K for the XPS 13 9310

[Paul Tagliamonte]

Package: linux
Severity: wishlist
thanks

Hello Linux maintainers,

The spiffy new Dell XPS 13 9310 is shipping, but is not sold as supporting
linux yet -- but appears to work great, with the exception of the Qualcomm
Technologies 802.11ax chipset.

I installed Linux from experimental, and am able to confirm the driver is
not loaded. I believe CONFIG_ATH11K could be enabled to support this
platform.

Happy to reproduce and/or try images out to confirm! This isn't a daily
machine yet.

Thank you very much!
  Paul

Re: License of "debian/" directories

[Paul Tagliamonte]

Hey Joel,

It should be outlined in the debian/copyright file for the package in
question

  Paul

On Thu, Oct 8, 2020 at 6:33 PM Joel Ray Holveck  wrote:

> I'm currently asking my employer to let me upstream some changes I've
> got to some Debian packaging.  Usually, they like to know what the
> license is.
>
> What's the license of "debian/" directories in source packages?  Not for
> native packages, but the packaging for third-party software.  Is it the
> same as the upstream code, or does Debian own the copyright and have a
> particular license for that, or what?
>
> I looked over the Policy Manual and the Legal FAQ, but didn't see an
> answer.  Is this something that's been discussed before?
>
> Best,
> joelh
>
>

-- 
All programmers are playwrights, and all computers are lousy actors.

#define sizeof(x) rand()
:wq

Re: [DSE-Dev] Question regarding shipping a SELinux Policy in Package

[Paul Tagliamonte]

> I think there aren't docs about how to ship SELinux policies with
> application packages, because that's not the way it's done.
> There are several reasons:
> * The package shipped policy module might not compile/load on the
> system, cause the system policy can use different types/attributes
> etc.
> * The system administrator might not want to install policy modules
> shipped by applications, because of
> trust/compatibility/maintainability/integrity.
> * The shipped policy module might not fit everyone's needs: for one it
> might be too permissive, for the next to restricted

I see. That makes some amount of sense!

> You can try to introduce a policy for your package into the official
> upstream Reference Policy [1], which is the base for the Debian
> policy.

Hurm, ok! That also sounds sensible. It also sounds very heavy-weight.

> (If necessary you could ship the SELinux policy source files under
> /usr/share/my_package/selinux/ and hint users at it.)

Ah, this is a great idea! I wasn't sure if there was some system that
would allow for loading of SELinux modules automatically (not unlike
how vim does configuration -- if you're using the system config, the
system module loading can handle it, otherwise you have your own setup,
I didn't know if SELinux made the same assumption about "targeted" and
"mls" being "from the distro" and therefore trust all distro packages to provide
sensible policy) It does sound like like that is expressly not supported by
design -- which, fair enough!

> Best regards,
>   Christian Göttsche
>
> [1]: https://github.com/SELinuxProject/refpolicy
>
>
> p.s.: IRC is available at #selinux on Freenode

Ah yes, I joined that last night after sending this mail - wasn't sure if
Debian-specific questions were appropriate there. Are they? I assumed
this was a packaging related question, because I did not understand
our relation to the upstream policy.

Thank you very much!
  paultag


-- 
:wq

___
SELinux-devel mailing list
SELinux-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/selinux-devel

[DSE-Dev] Question regarding shipping a SELinux Policy in Package

[Paul Tagliamonte]

Hello, SELinux folks,

Does anyone on this list have a pointer todocs on how packages should ship
SELinux policies in application packages for SELinux enabled systems? If
not, is there a good IRC channel to ask in, or mailing list to ask if this
is the wrong one?

Thanks!
  paultag

-- 
:wq
___
SELinux-devel mailing list
SELinux-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/selinux-devel

Bug#959806: already done.

[Paul Tagliamonte]

I uploaded this package to NEW last week. This bug should likely be
closed.

   Paul

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3
 `- http://people.debian.org/~paultag


signature.asc
Description: PGP signature

Bug#959806: already done.

[Paul Tagliamonte]

I uploaded this package to NEW last week. This bug should likely be
closed.

   Paul

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3
 `- http://people.debian.org/~paultag


signature.asc
Description: PGP signature

Re: Comments regarding xnnpack_0.0~git20200425.54f5917-1_amd64.changes

[Paul Tagliamonte]

On Tue, Apr 28, 2020 at 03:23:41AM +, Mo Zhou wrote:
> Could you please accept it first? I'm sure it will be fixed in the next
> upload? :-)

Hurm, I wouldn't reject over this, and I think I said I accepted it. Are
you not seeing it yet?

I just ssh'd into ftp-master, and it's showing up on an ls[1], but tracker
and friends aren't responding to me right now. Are you sure it's not
already been acccepted and built? Buildds look to have it.

>  
> > Thanks for your work,
> >   Paul (and a Trainee)
> > 
> > 

[1]: 
xnnpack| 0.0~git20200425.54f5917-1 | buildd-experimental | source
xnnpack| 0.0~git20200425.54f5917-1 | experimental| source
xnnpack| 0.0~git20200425.54f5917-1 | experimental-debug  | source


-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3
 `- http://people.debian.org/~paultag


signature.asc
Description: PGP signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#958804: Please enable CONFIG_NETLABEL

[Paul Tagliamonte]

Package: src:linux
Severity: wishlist
Tags: patch
kthxbye

Howdy, maintainers,

It'd be great to set CONFIG_NETLABEL=y. I'm interested in packaging some
tools that depend on this flag.

This feature enables the usage of tools such as CIPSO, RIPSO, or CALIPSO,
which enable the tagging of IP packets between two cooperating hosts.

I submitted an MR to Salsa[1]

Thank you for your work!

[1]: https://salsa.debian.org/kernel-team/linux/-/merge_requests/235

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3
 `- http://people.debian.org/~paultag


signature.asc
Description: PGP signature

Bug#958804: Please enable CONFIG_NETLABEL

[Paul Tagliamonte]

Package: src:linux
Severity: wishlist
Tags: patch
kthxbye

Howdy, maintainers,

It'd be great to set CONFIG_NETLABEL=y. I'm interested in packaging some
tools that depend on this flag.

This feature enables the usage of tools such as CIPSO, RIPSO, or CALIPSO,
which enable the tagging of IP packets between two cooperating hosts.

I submitted an MR to Salsa[1]

Thank you for your work!

[1]: https://salsa.debian.org/kernel-team/linux/-/merge_requests/235

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3
 `- http://people.debian.org/~paultag


signature.asc
Description: PGP signature

Re: My analysis of the proposals

[Paul Tagliamonte]

On Tue, Dec 03, 2019 at 01:31:53AM +0200, Uoti Urpala wrote:
> The relevant question now is not "should Debian support anything that
> is not systemd", but "should Debian support sysvinit". In case any
> promising systems appear in the future, decisions about them are best
> left for when it's not arguing about hypotheticals.

I know I'm going to regret wading in here -- but maybe I can help?

Uoti -- Remember when reading this rest of this message that from what I
can understand from what you've written, we will likely vote nearly the
same way on this GR. I've not hid the fact that I vastly prefer systemd
to sysvinit, and don't really care about sysv anymore (sorry not sorry?).

However:

This is not the right place to have this discussion. I don't think
trying to hash this out here is productive, and largely isn't adding to
the substance here.

We need to have this GR **not** to rehash the last god knows how many
years since "the bug" was filed, but to provide direction to the project
on what we should be doing (on a technical level) when it comes to
supporting multiple init systems.

The options provided are to show us a way out of this mess. I don't
think trying to comapre and contrast is helpful or even relevant to this
vote at all. The technical merits are largely not in play and shouldn't
factor in to the vote too much.

Please can we stop this discussion and getting baited into talking about
the technical merits of pid 1?

   paultag

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3
 `- http://people.debian.org/~paultag


signature.asc
Description: PGP signature

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Paul Tagliamonte]

On Sat, Nov 30, 2019, 4:41 PM Bernd Zeimetz  wrote:

> Hi,
>
> > X<
> > Title: Reaffirm our commitment to support portability and multiple
> implementations
>
> ... so how does this help the project? We are all wasting lots of time
> in discussing policy and if we want to support init and friends and if
> bugs are RC or not. You are basically saying that this needs to continue.
>
> I really hope that people vote this far below FD and I fail to
> understand why fellow developers actually second this.
>

I strongly agree. This proposal sounds nice as an aspirational set of
values to write proposals off of, but is deeply unhelpful in helping
resolve the rats nest we find ourselves in. I will be putting this option
below FD.

Paul

Re: Modern best practice packaging tutorial?

[Paul Tagliamonte]

On Tue, Nov 19, 2019 at 11:14 AM Xavier  wrote:
>
> Hi,
>
> Here is a JS tuto. Some things are available for other teams: 
> https://wiki.debian.org/Javascript/Tutorial

Very useful, thank you! Do you know how representative the JavaScript
team is of Debian writ large
these days? I understand each team has their quirks, but is the
average collab-maint style
package maintained this way?

Thanks, Xavier!
  paultag

>
> Cheers,
> Xavier
>
> Le 19 novembre 2019 15:57:59 GMT+01:00, Paul Tagliamonte  
> a écrit :
>>
>> Hey -devel!
>>
>> I've been less active on the packaging side for a while; has anyone
>> written up a modern packaging guide covering salsa best practices,
>> gbp best practices, and the commonly accepted strategy for tracking
>> upstreams (still uscan or are we doing something fancy with branches?)
>> for new packages?
>>
>> Much love to everyone!
>>   paultag
>
>
> --
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
> brièveté.



-- 
:wq

Re: Modern best practice packaging tutorial?

[Paul Tagliamonte]

On Tue, Nov 19, 2019 at 10:53 AM  wrote:
>
> Hi Paul,
>
> I gave a talk on this as the SE Linux Fest in Charlotte earlier this
> year.  My presentation, notes, and sample project are here, in case
> that's helpful:
> https://bitbucket.org/elimtaft/debian-packaging-from-scratch-demo-project/src/master/.
> Good luck!

Thanks, Eli!

I've been doing things this way for about 10 years or so, I'm very happy to
do the dget/dput dance, or package something using a debian directory
I build locally - do you happen to have any talk materials about
specifically the
modern Debian way to use salsa, gbp best practices, and the commonly accepted
strategy for tracking upstreams on those git repos?

I don't want to package something in line with best practices from 2015 by
mistake :)

I've been out of the game so long that I'd be tempted to fall back on my
workflow from years ago.

Thank you!
  Paul


>
>
> Sincerely
>
> Eli
>
> --
>
> Eli Taft
>
> Partner, Senior Software Engineer
>
> Quoin, Inc.
>
> www.quoininc.com
>
>


-- 
:wq

Modern best practice packaging tutorial?

[Paul Tagliamonte]

Hey -devel!

I've been less active on the packaging side for a while; has anyone
written up a modern packaging guide covering salsa best practices,
gbp best practices, and the commonly accepted strategy for tracking
upstreams (still uscan or are we doing something fancy with branches?)
for new packages?

Much love to everyone!
  paultag

-- 
:wq

Re: I forgot my password and Debian need password when booting

[Paul Tagliamonte]

On Sun, Oct 27, 2019 at 05:05:44PM -0400, Craig wrote:
>Can you get grub to appear? If you can an easy way to get in
> 
>Go to the end of the line with options and add to the end I think
>shell=/bin/sh

`init=/bin/sh` is what you're thinking of, but it won't work here,
since the drive is encrypted.

Cheers,
  paultag


signature.asc
Description: PGP signature

Re: Standing behind GNOME Foundation against Rothschild Patent Imaging LLC?

[Paul Tagliamonte]

Aye aye! We should distribute a fundraising site more widely among Debian
for anyone in our community who is willing to donate to the collective
defense of our tools.

paultag

On Sat, Sep 28, 2019, 8:28 PM Norbert Preining 
wrote:

> On Sat, 28 Sep 2019, Chris Lamb wrote:
> > that the Debian Project would publically stand with the GNOME
> > Foundation against this attack on a cherished sister project of ours
> > and, by extension, on free software in general?
>
> Totally agreed, thanks a lot.
> I have invested lots of code into Shotwell over the years, and it hurts
> to see these patent trolls.
>
> Norbert
>
> --
> PREINING Norbert   http://www.preining.info
> Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
>
>

Bug#935057: RM: afl -- ROM; upstream not actively developed anymore

[Paul Tagliamonte]

Amazing! Thank you for your hard work and willingness to help! Very cool!

Cc'ing ftpmaster so no one actions it while its in limbo

Paul

On Sun, Sep 8, 2019, 2:39 PM Nils Dagsson Moskopp <
nils+debian-report...@dieweltistgarnichtso.net> wrote:

> Paul Tagliamonte  writes:
>
> > Well, seeing as how Daniel Is the maintainer, perhaps one of you can take
> > over as maintainer and rename / reassign this bug to an adoption.
> >
> > How does that sound, all?
>
> If no one is willing, I can be a maintainer, but I have no experience.
>
> I have been asking around for maintainers for some days now.
>
> Please reassign this bug to an adoption soon.
>

Bug#935057: RM: afl -- ROM; upstream not actively developed anymore

[Paul Tagliamonte]

On Fri, Aug 30, 2019, 9:06 PM Nils Dagsson Moskopp <
nils+debian-report...@dieweltistgarnichtso.net> wrote:

> Package: ftp.debian.org
> Followup-For: Bug #935057
>
>
> According to this, there were 5 commits today:
> 
>

Well, seeing as how Daniel Is the maintainer, perhaps one of you can take
over as maintainer and rename / reassign this bug to an adoption.

How does that sound, all?

paultag

>

Re: dropping python2 [was Re: scientific python stack transitions]

[Paul Tagliamonte]

On Tue, Jul 16, 2019 at 11:20 AM Matthias Klose  wrote:
>
> On 16.07.19 16:52, Paul Tagliamonte wrote:
> > I lost some of this thread - should we request a transition
> > from the release team? I was looking for the list of blockers
> > to dropping Python 2 and couldn't find anything except this
> > thread (where we're still figuring out what to do, of course)
>
> #931659

Perfect, thank you!

>
> > I do want to keep in mind that Python 2 is EOL and dead
> > in 5 months, 15 days and 12 hours.
>
> yes, that's the upstream status, not the distro status.

Does this mean we plan to commit to providing security updates
to Python 2 alone? Do we have the bandwidth and willing maintainers?

Thank you!
  paultag

-- 
:wq

Bug#927477: ITS: fluxbox -- low resource X11 Window manager

[Paul Tagliamonte]

As an uploader - I'm happy to just mark you as an uploader without all this
paperwork. I say just add yourself and go ahead!

Paul


On Sat, Apr 20, 2019, 10:42 AM Tong Sun 
wrote:

> Package: fluxbox
> Severity: important
> Owner:  Dmitry E. Oboukhov 
>
> (closed #927457 & redoing it again)
>
> * Package name: fluxbox
> * URL : http://git.fluxbox.org/fluxbox.git
> * License : MIT
>   Programming Lang: C++
>   Description : Highly configurable and low resource X11 Window manager
>
> Reason to pack: to salvage the package, because
>
> - The last version is over 5 years old
> - There are
>   * 3 action needed that are "high"
>   * 4 bugs tagged patch in the BTS
>   * 13 lintian warnings
>
> I contacted the package owner more than 2 years ago:
>
> -- Forwarded message -
> From: Tong Sun 
> Date: Sat, May 27, 2017 at 11:31 AM
> Subject: Re: About Fluxbox
> To: Dmitry E. Oboukhov 
>
>
> Hi Dmitry,
>
> I'd like to push forward the Fluxbox version in Debian to the
> latest. If you are too busy, I can take a stab.
>
> If so, will you sponsor me to review & upload it when I'm
> done? (I'm currently maintaining two Debian packages and am in
> the process of getting being officially recognized as DM)
> -- Forwarded message -
>
> but didn't get any reply until now.
>
> Thus, I'm officially requesting to salvage the package now,
> taking over the maintainership.
>
> Thanks
>
>

Bug#924705: Please enable PKCS8_PRIVATE_KEY_PARSER

[Paul Tagliamonte]

Package: linux
Severity: wishlist
thanks

It would be nice to add the PKCS8_PRIVATE_KEY_PARSER to the Debian
build. Currently, importing a private key is not possible, and
generates the error `add_key: Bad message` when a key is attempted to
be loaded.

Thanks for your hard work and maintenance of such an important package!
  Paul


-- 
:wq

Bug#924705: Please enable PKCS8_PRIVATE_KEY_PARSER

[Paul Tagliamonte]

Package: linux
Severity: wishlist
thanks

It would be nice to add the PKCS8_PRIVATE_KEY_PARSER to the Debian
build. Currently, importing a private key is not possible, and
generates the error `add_key: Bad message` when a key is attempted to
be loaded.

Thanks for your hard work and maintenance of such an important package!
  Paul


-- 
:wq

Bug#908681: libsane1: pointless package rename

[Paul Tagliamonte]

Was this a hijack or NMU? I saw a NMU to DELAYED with a log in the bug
announcing it. I may have missed something

paultag

Bug#908681: libsane1: pointless package rename

[Paul Tagliamonte]

Was this a hijack or NMU? I saw a NMU to DELAYED with a log in the bug
announcing it. I may have missed something

paultag

Re: Bug#908681: libsane1: pointless package rename

[Paul Tagliamonte]

Was this a hijack or NMU? I saw a NMU to DELAYED with a log in the bug
announcing it. I may have missed something

paultag

Re: [PATCH] Add support for the NanoPiNeo

[Paul Tagliamonte]

Hey all,

I can confirm this patch still works, and the resulting stock image
has a working NIC on a NanoPi Neo. Install completed, no issues, and
the machine is ssh'able over my network.

Thanks, all! I'm one happy camper!
   Paul


On Wed, Dec 27, 2017 at 8:52 PM, Paul Tagliamonte <paul...@debian.org> wrote:
> It looks like the Debian package may be carrying the dwmac-sun8i
> driver. I'm going to test it out locally.
>
> On Mon, Sep 4, 2017 at 3:20 PM, Karsten Merker <mer...@debian.org> wrote:
>> On Wed, Aug 23, 2017 at 08:23:52AM +0200, Karsten Merker wrote:
>>> On Tue, Aug 22, 2017 at 11:11:56PM -0400, Paul Tagliamonte wrote:
>>
>>> > vagrantc added support for the NanoPi in u-boot in version
>>> > 2016.03~rc3+dfsg1-1, and i've been playing with it since.
>>> > Finally, with Linux 4.13, the NanoPi emac driver has been
>>> > mainlined, and it (finally!) is starting to look sensible.
>>> >
>>> > I've got my NanoPi booted and the eth looking happy, but I've
>>> > not completed an install yet.  Attached is a patch to
>>> > generate the firmware image.  I was able to test the
>>> > generated image, and it booted.
>>> >
>>> > Attached is a patch against debian-installer/installer,
>>> > adding the NanoPiNeo to the u-boot-image-config.
>> [...]
>>> many thanks for the patch.  I will apply it to the d-i
>>> repository, but I would prefer to wait until we have have
>>> kernel 4.13 in unstable and can change the d-i kernel ABI
>>> setting accordingly.  Currently we build d-i based on kernel
>>> 4.12 which doesn't support the H3 EMAC, so a 4.12-based netboot
>>> image wouldn't be usable on a "plain" NanoPi Neo (i.e. without
>>> adding a USB-ethernet-adaptor).
>>
>> Hello,
>>
>> unfortunately some issues regarding the devicetree bindings for
>> the H3 EMAC driver couldn't be sorted out before the final
>> release of kernel 4.13.  As a result, the sunxi port maintainers
>> and the ARM-SoC maintainer have decided to revert the
>> corresponding patches and work on a proper solution during the
>> 4.14 development cycle:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fabed5ad230a5ff8320b2928ec20a52e59a9bf60
>>
>> I'll keep your patch on my todo list and revisit it again once
>> the H3 EMAC driver is completely upstream (hopefully in kernel
>> 4.14).
>>
>> Regards,
>> Karsten
>> --
>> Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
>> sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
>> Werbung sowie der Markt- oder Meinungsforschung.
>
>
>
> --
> :wq



-- 
:wq

Re: [PATCH] Add support for the NanoPiNeo

[Paul Tagliamonte]

It looks like the Debian package may be carrying the dwmac-sun8i
driver. I'm going to test it out locally.

On Mon, Sep 4, 2017 at 3:20 PM, Karsten Merker <mer...@debian.org> wrote:
> On Wed, Aug 23, 2017 at 08:23:52AM +0200, Karsten Merker wrote:
>> On Tue, Aug 22, 2017 at 11:11:56PM -0400, Paul Tagliamonte wrote:
>
>> > vagrantc added support for the NanoPi in u-boot in version
>> > 2016.03~rc3+dfsg1-1, and i've been playing with it since.
>> > Finally, with Linux 4.13, the NanoPi emac driver has been
>> > mainlined, and it (finally!) is starting to look sensible.
>> >
>> > I've got my NanoPi booted and the eth looking happy, but I've
>> > not completed an install yet.  Attached is a patch to
>> > generate the firmware image.  I was able to test the
>> > generated image, and it booted.
>> >
>> > Attached is a patch against debian-installer/installer,
>> > adding the NanoPiNeo to the u-boot-image-config.
> [...]
>> many thanks for the patch.  I will apply it to the d-i
>> repository, but I would prefer to wait until we have have
>> kernel 4.13 in unstable and can change the d-i kernel ABI
>> setting accordingly.  Currently we build d-i based on kernel
>> 4.12 which doesn't support the H3 EMAC, so a 4.12-based netboot
>> image wouldn't be usable on a "plain" NanoPi Neo (i.e. without
>> adding a USB-ethernet-adaptor).
>
> Hello,
>
> unfortunately some issues regarding the devicetree bindings for
> the H3 EMAC driver couldn't be sorted out before the final
> release of kernel 4.13.  As a result, the sunxi port maintainers
> and the ARM-SoC maintainer have decided to revert the
> corresponding patches and work on a proper solution during the
> 4.14 development cycle:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fabed5ad230a5ff8320b2928ec20a52e59a9bf60
>
> I'll keep your patch on my todo list and revisit it again once
> the H3 EMAC driver is completely upstream (hopefully in kernel
> 4.14).
>
> Regards,
> Karsten
> --
> Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
> sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
> Werbung sowie der Markt- oder Meinungsforschung.



-- 
:wq

Bug#872293: nmu: loads of golang stuff

[Paul Tagliamonte]

> What's outdated here, built-using? If so, we rebuild those before or during 
> the
> freeze. Not sure we need to do it more often than that, as things will get out
> of date again before the freeze.

Due to the way golang binaries get built, not rebuilding them outside
of freeze results in binaries that become buggy during freeze and
trigger more uploads and rebuilds.

buildd time is cheep, and ensuring we can both get rid of old sources
and find bugs is important during development.

The other way we can do this is I can do routine empty uploads -- we
need them rebuilt either way

Thanks!
  Paul

>
> Cheers,
> Emilio



-- 
:wq