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

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#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#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#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

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#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#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#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#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#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

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#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#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]

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#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#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#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

>

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#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#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

Bug#873608: patch

[Paul Tagliamonte]

Whoops, I only just read the comment about this not being standard in
armhf. I misread that and also assumed it was standard (likely because,
as a Coretex-A* user, I always had it), so this patch will likely be
inappropriate (or incomplete). Maybe this patch plus an AND on an
ENABLE_NEON or something, which is disabled by default in the packaging.

  Paul


On Tue, Aug 29, 2017 at 04:10:30PM -0400, Paul Tagliamonte wrote:
> tags 873608 + patch
> thanks
> 
> Attached is a patch that will enable neon if arm_neon.h is present. I
> didn't upstream this or anything, I figure you have a better
> relationship with them, but this ought to fix the ftbfs.
> 
> I'm running a test build now, but it's past the old ftbfs point
> 
>   Paul
> 
> -- 



-- 

Bug#873608: patch

[Paul Tagliamonte]

tags 873608 + patch
thanks

Attached is a patch that will enable neon if arm_neon.h is present. I
didn't upstream this or anything, I figure you have a better
relationship with them, but this ought to fix the ftbfs.

I'm running a test build now, but it's past the old ftbfs point

  Paul

-- 
Description: When building for armhf, enable NEON
 NEON is part of the armhf baseline, so this will always be enabled on
 armhf.
Author: Paul Tagliamonte <paul...@debian.org>
Bug-Debian: https://bugs.debian.org/873608
Origin: vendor
Last-Update: 2017-08-29

--- uhd-3.10.2.0.orig/host/lib/convert/CMakeLists.txt
+++ uhd-3.10.2.0/host/lib/convert/CMakeLists.txt
@@ -67,6 +67,8 @@ IF(HAVE_ARM_NEON_H AND (${CMAKE_SIZEOF_V
 ${CMAKE_CURRENT_SOURCE_DIR}/convert_with_neon.cpp
 ${CMAKE_CURRENT_SOURCE_DIR}/convert_neon.S
 )
+
+SET ( CMAKE_CXX_FLAGS "-mfpu=neon" )
 ENDIF()
 
 

Bug#866005: Backport TLS Client Certificate fixes

[Paul Tagliamonte]

retitle 866005 Backport TLS Client Certificate fixes
thanks

A few more changes I sent upstream have been accepted. I'm maintaining
the delta locally, is there any chance you could backport these patches
to the Debian package?

Since there was an upload since I filed the debdiff, I just attached the
patch, as fit for the debian/patches series. If the team is OK with it,
I can go ahead and upload this.

Thanks!
 Paul


-- 
Description: Multiple fixes to Client Certifciate handling
 The first is a fix to the verify-depth flag, which allows Client
 Certificates to be signed off an intermediary Certificate Authority.
 .
 Additionally, this will write x509 DER to the uwsgi buffer
 This will write the full x.509 DER into the buffer for use by clients
 during runtime. This feature is intended to allow clients to handle
 per-user ACL with the direct x.509 Certificate, without having to
 configure the webserver to extract the right bits, which may or may not
 be custom extensions.
 .
 One such example would be using and extracting the UPN SAN, or some
 other exotic extension.
Author: Paul Tagliamomnte 
Origin: upstream, https://github.com/unbit/uwsgi/pull/1562, https://github.com/unbit/uwsgi/issues/1563
Last-Update: 2017-08-21

diff --git a/core/ssl.c b/core/ssl.c
index 02e5449..c5e3ae7 100644
--- a/core/ssl.c
+++ b/core/ssl.c
@@ -326,8 +326,7 @@ SSL_CTX *uwsgi_ssl_new_server_context(char *name, char *crt, char *key, char *ci
 else {
 SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, uwsgi_ssl_verify_callback);
 }
-// in the future we should allow to set the verify depth
-SSL_CTX_set_verify_depth(ctx, 1);
+SSL_CTX_set_verify_depth(ctx, uwsgi.ssl_verify_depth);
 
 		if (uwsgi.ssl_tmp_dir && !uwsgi_starts_with(client_ca, strlen(client_ca), "-BEGIN ", 11)) {
 			if (!name) {
diff --git a/core/uwsgi.c b/core/uwsgi.c
index f2fdc0f..816dcbc 100644
--- a/core/uwsgi.c
+++ b/core/uwsgi.c
@@ -653,6 +653,7 @@ static struct uwsgi_option uwsgi_base_options[] = {
 	{"snmp-community", required_argument, 0, "set the snmp community string", uwsgi_opt_snmp_community, NULL, 0},
 #ifdef UWSGI_SSL
 	{"ssl-verbose", no_argument, 0, "be verbose about SSL errors", uwsgi_opt_true, _verbose, 0},
+	{"ssl-verify-depth", optional_argument, 0, "set maximum certificate verification depth", uwsgi_opt_set_int, _verify_depth, 1},
 #ifdef UWSGI_SSL_SESSION_CACHE
 	// force master, as ssl sessions caching initialize locking early
 	{"ssl-sessions-use-cache", optional_argument, 0, "use uWSGI cache for ssl sessions storage", uwsgi_opt_set_str, _sessions_use_cache, UWSGI_OPT_MASTER},
diff --git a/plugins/http/https.c b/plugins/http/https.c
index 1d04666..dc629e3 100644
--- a/plugins/http/https.c
+++ b/plugins/http/https.c
@@ -187,6 +187,12 @@ int hr_https_add_vars(struct http_session *hr, struct corerouter_peer *peer, str
 #endif
 hr->ssl_client_cert = SSL_get_peer_certificate(hr->ssl);
 if (hr->ssl_client_cert) {
+int client_cert_len;
+unsigned char *client_cert_der = NULL;
+client_cert_len = i2d_X509(hr->ssl_client_cert, _cert_der);
+if (client_cert_len < 0) return -1;
+if (uwsgi_buffer_append_keyval(out, "HTTPS_CLIENT_CERTIFICATE", 24, (char*)client_cert_der, client_cert_len)) return -1;
+
 X509_NAME *name = X509_get_subject_name(hr->ssl_client_cert);
 if (name) {
 hr->ssl_client_dn = X509_NAME_oneline(name, NULL, 0);
diff --git a/uwsgi.h b/uwsgi.h
index 069e240..c706e2f 100644
--- a/uwsgi.h
+++ b/uwsgi.h
@@ -2791,6 +2791,10 @@ struct uwsgi_server {
 	// uWSGI 2.1 backport
 	int new_argc;
 	char **new_argv;
+
+#ifdef UWSGI_SSL
+	int ssl_verify_depth;
+#endif
 };
 
 struct uwsgi_rpc {
-- 
2.14.1

Bug#872293: nmu: loads of golang stuff

[Paul Tagliamonte]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal
X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org
thanks

Howdy, release!

Due to the way that Go packages are built, I've started keeping an eye
on packages that were built using an out of date version of another
corner of the archive.

I've written a script that generates a list of things to binNMU, but
I've only just written it on the flight back from DebConf, and I am not
super sure of it yet.

So, here's a list of some things that look sensible by eye. I've got
a *lot* more, so if this turns out OK, I'll send another bug with more.

  nmu sia . any . -m 'out of date'
  nmu prometheus-node-exporter . any . -m 'out of date'
  nmu go-md2man . any . -m 'out of date'
  nmu webhook . any . -m 'out of date'
  nmu kcptun . any . -m 'out of date'
  nmu acbuild . any . -m 'out of date'
  nmu notary . any . -m 'out of date'
  nmu dh-make-golang . any . -m 'out of date'
  nmu robustirc-bridge . any . -m 'out of date'
  nmu runc . any . -m 'out of date'
  nmu prometheus . any . -m 'out of date'
  nmu skydns . any . -m 'out of date'
  nmu gb . any . -m 'out of date'
  nmu golang-golang-x-tools . any . -m 'out of date'
  nmu systemd-docker . any . -m 'out of date'
  nmu golang-github-xordataexchange-crypt . any . -m 'out of date'
  nmu abci . any . -m 'out of date'
  nmu prometheus-varnish-exporter . any . -m 'out of date'
  nmu gosu . any . -m 'out of date'
  nmu rclone . any . -m 'out of date'
  nmu docker-registry . any . -m 'out of date'
  nmu golang-petname . any . -m 'out of date'
  nmu prometheus-mongodb-exporter . any . -m 'out of date'
  nmu prometheus-mysqld-exporter . any . -m 'out of date'
  nmu consul . any . -m 'out of date'
  nmu minica . any . -m 'out of date'
  nmu gitlab-ci-multi-runner . any . -m 'out of date'
  nmu ratt . any . -m 'out of date'

Thank you!
  Paul

Bug#860608: [pkg-golang-devel] Bug#860608: Bug#860608: Bug#860608: golang: FTBFS: Go version is "go1.6.1", ignoring -next /<>/api/next.txt

[Paul Tagliamonte]

On Tue, May 2, 2017 at 4:23 AM, Michael Hudson-Doyle
 wrote:
> As you can see these are all -dev packages, so the Built-Using is bogus and
> should simply be dropped from the package.
>
> There are quite a few more packages that reference obsolete golang packages
> in their Built-Using...

Indeed. Thanks for pointing that out, I totally forgot this was a thing.

I wrote a script to grab all packages pkg-go maintains that are
arch:all and have a B-U in source.

I went through each one, and I've patched them all in VCS, and they
should be fixed on next upload(s).

  Paul

Bug#870643: [pkg-go] Bug#870643: Bug#870643: golang-github-pierrec-lz4-dev: please split off test data

[Paul Tagliamonte]

Ah yeah, of course! Thanks for caring about the archive size :)

Yeah, most people work off git clones (via `go get`) in a GOPATH
that's usually per-project

Paul


On Tue, Aug 8, 2017 at 11:21 AM, Aaron M. Ucko <u...@debian.org> wrote:
> Paul Tagliamonte <paul...@debian.org> writes:
>
>> As with the other bug, I don't see the point in this. This package is
>> used as a Build-Dependency, and not used by either end-users, or
>> developers working on Go source code on Debian, so splitting this off
>> will add space in the archive, and add a lot of complexity.
>
> Hi, Paul.
>
> Thanks for clarifying; I'd thought there was more of a use case for
> having these packages installed locally.  Does everyone just use private
> GitHub checkouts?
>
> --
> Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
> http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers



-- 
:wq

Bug#871448: [pkg-go] Bug#871448: golang-github-mattn-go-sqlite3-dev: please unbundle SQLite

[Paul Tagliamonte]

Unvendoring a code copy from shipping in a binary deb is a good idea
-- thanks for the bug! Doubly so with sqlite.

However, I don't see the point in removing it from the source if it's
at all anywhere close to more work to remove it. It's DFSG free and
it's not a huge deal to keep in source -- honestly, I'd rather keep
deltas with upstream minimal with source trees.

On Mon, Aug 7, 2017 at 11:15 PM, Aaron M. Ucko  wrote:
> Package: golang-github-mattn-go-sqlite3-dev
> Version: 1.2.0+git20170710.100.47fc4e5~dfsg1-1
> Severity: normal
>
> golang-github-mattn-go-sqlite3-dev now includes a full copy of the
> SQLite3 amalgamation, roughly 7.5 MB in size.  Per Policy 4.13, please
> omit it from the binary package, and consider dropping it from the
> source package (which you're evidently already repacking) as well.
>
> Thanks!
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, x32
>
> Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages golang-github-mattn-go-sqlite3-dev depends on:
> ii  libsqlite3-dev  3.19.3-3
>
> golang-github-mattn-go-sqlite3-dev recommends no packages.
>
> golang-github-mattn-go-sqlite3-dev suggests no packages.
>
> -- no debconf information
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers



-- 
:wq

Bug#870643: [pkg-go] Bug#870643: golang-github-pierrec-lz4-dev: please split off test data

[Paul Tagliamonte]

As with the other bug, I don't see the point in this. This package is
used as a Build-Dependency, and not used by either end-users, or
developers working on Go source code on Debian, so splitting this off
will add space in the archive, and add a lot of complexity.

I'm against splitting this unless there's seriously good cause.

   Paul

On Thu, Aug 3, 2017 at 2:06 PM, Aaron M. Ucko  wrote:
> Package: golang-github-pierrec-lz4-dev
> Version: 0.0~git20170519.0.5a3d224-1
> Severity: minor
>
> The golang-github-pierrec-lz4-dev binary package now consists of 9+ MB
> of test data and a much smaller quantity of actual code.  I acknowledge
> the value of automated regression testing, but would appreciate it if
> you could please split the test data into a separate binary package.
>
> Thanks!
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, x32
>
> Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> -- no debconf information
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers



-- 
:wq

Bug#871447: [pkg-go] Bug#871447: golang-github-gogo-protobuf-dev: please split off test data

[Paul Tagliamonte]

Seeing as how these are development headers for building go debian
packages (as a Build-Dependency), and not
something users would ever install (including go developers working on
Debian, since these system -dev packages aren't useful to use there
either), I don't see the added complexity worth the space savings.

In fact, splitting this off may even result in more archive space to
store another .deb. I'd be against splitting this package unless there
was seriously good cause.

   Paul

On Mon, Aug 7, 2017 at 10:35 PM, Aaron M. Ucko  wrote:
> Package: golang-github-gogo-protobuf-dev
> Version: 0.3+git20170120.144.265e960d-1
> Severity: minor
>
> Following up on #870643, I see that several other go packages, notably
> golang-github-gogo-protobuf-dev, contain much more test data (nearly
> 22M in this case) than actual code.  Once again, I acknowledge the
> value of automated regression testing, but would appreciate it if you
> could please split the test data into a separate binary package.
>
> Thanks!
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, x32
>
> Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> golang-github-gogo-protobuf-dev depends on no packages.
>
> Versions of packages golang-github-gogo-protobuf-dev recommends:
> ii  gogoprotobuf  0.3+git20170120.144.265e960d-1
>
> golang-github-gogo-protobuf-dev suggests no packages.
>
> -- no debconf information
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers



-- 
:wq

Bug#866005: Backport TLS Client Certificate wsgi blob

[Paul Tagliamonte]

Package: uwsgi
Severity: wishlist
thanks

Thanks for maintaining uwsgi,

Attached is a debdiff adding the ability to write the full x.509 DER
into the buffer for use by clients during runtime. This feature is
intended to allow clients to handle per-user ACL with the direct x.509
Certificate, without having to configure the webserver to extract the
right bits, which may or may not be custom extensions.

One such example would be using and extracting the UPN SAN, or some
other exotic extension at runtime.

This patch is already merged in master, and can be dropped when the next
release is tared up.

-- 
diff -Nru uwsgi-2.0.15/debian/changelog uwsgi-2.0.15/debian/changelog
--- uwsgi-2.0.15/debian/changelog   2017-06-20 06:00:19.0 -0400
+++ uwsgi-2.0.15/debian/changelog   2017-06-26 02:00:00.0 -0400
@@ -1,3 +1,14 @@
+uwsgi (2.0.15-2.1) UNRELEASED; urgency=medium
+
+  [ Paul Tagliamonte ]
+  * Backport an upstreamed patch to insert the validated x509 client
+Certificate in the wsgi object.
+
+  [ Jonas Smedegaard ]
+  * 
+
+ -- Jonas Smedegaard <d...@jones.dk>  Tue, 26 Jun 2017 08:00:00 +0200
+
 uwsgi (2.0.15-2) unstable; urgency=medium
 
   * Add patches cherry-picked upstream:
diff -Nru uwsgi-2.0.15/debian/patches/1015_write_x509_der.patch 
uwsgi-2.0.15/debian/patches/1015_write_x509_der.patch
--- uwsgi-2.0.15/debian/patches/1015_write_x509_der.patch   1969-12-31 
19:00:00.0 -0500
+++ uwsgi-2.0.15/debian/patches/1015_write_x509_der.patch   2017-06-26 
02:00:00.0 -0400
@@ -0,0 +1,30 @@
+Description: Write x509 DER to the uwsgi buffer
+ This will write the full x.509 DER into the buffer for use by clients
+ during runtime. This feature is intended to allow clients to handle
+ per-user ACL with the direct x.509 Certificate, without having to
+ configure the webserver to extract the right bits, which may or may not
+ be custom extensions.
+ .
+ One such example would be using and extracting the UPN SAN, or some
+ other exotic extension.
+Author: Paul Tagliamomnte <paul...@debian.org>
+Origin: upstream, https://github.com/unbit/uwsgi/pull/1562
+Last-Update: 2017-06-26
+
+diff --git a/plugins/http/https.c b/plugins/http/https.c
+index 4bb04c90..836ce09a 100644
+--- a/plugins/http/https.c
 b/plugins/http/https.c
+@@ -179,6 +179,12 @@ int hr_https_add_vars(struct http_session *hr, struct 
corerouter_peer *peer, str
+ #endif
+ hr->ssl_client_cert = SSL_get_peer_certificate(hr->ssl);
+ if (hr->ssl_client_cert) {
++int client_cert_len;
++unsigned char *client_cert_der = NULL;
++client_cert_len = i2d_X509(hr->ssl_client_cert, 
_cert_der);
++if (client_cert_len < 0) return -1;
++if (uwsgi_buffer_append_keyval(out, 
"HTTPS_CLIENT_CERTIFICATE", 24, (char*)client_cert_der, client_cert_len)) 
return -1;
++
+ X509_NAME *name = 
X509_get_subject_name(hr->ssl_client_cert);
+ if (name) {
+ hr->ssl_client_dn = X509_NAME_oneline(name, 
NULL, 0);
diff -Nru uwsgi-2.0.15/debian/patches/series uwsgi-2.0.15/debian/patches/series
--- uwsgi-2.0.15/debian/patches/series  2017-06-20 05:59:17.0 -0400
+++ uwsgi-2.0.15/debian/patches/series  2017-06-26 02:00:00.0 -0400
@@ -8,3 +8,4 @@
 1005_avoid_auto_ptr.patch
 1009_fix_java_paths.patch
 1010_support_java_pass_includes.patch
+1015_write_x509_der.patch


signature.asc
Description: PGP signature

Bug#863896: Can confirm bugs(s) and fixes

[Paul Tagliamonte]

I got around to doing some network maintaince, and upgraded the
non-critical packages on my router, along with dns-root-data. dnsmasq's
version did not change during this operation.

After restarting dnsmasq, the dhcpd was down, and clients weren't
getting IPs. After digging a bit (set -x on the init script, and
friends), I was able to work back to dns-root-data, and confirmed the
package version did change.

I saw these bugs, and I saw dnsmasq handles this better in sid -
thankfully, I keep sid pinned down for just such a bug :)

I upgraded dnsmasq, and I can confirm clients are happy again.

Hopefully we can push the migration to testing before more folks get
caught in this (although, I guess folks who run their own dhcpd tend to
be able to find bug reports such as this -- hey there, other nerds!)

Thanks for the fix, and thanks for maintaining these packages,
  Paul

-- 


signature.asc
Description: PGP signature

Bug#845932: Please enable FriendlyARM NanoPi NEO

[Paul Tagliamonte]

My UART chip just showed up, so I had a chance to actually try this out
tonight!

So, hot off the presses: Success! I did need to borrow the .dtb, but it
booted and I saw d-i!

However, it appears to not like the USB or Ethernet port (tried a USB
adapter, and it didn't like that either).

saw an Ubuntu image, tried booting that, and that brought up a sane
userland with network connectivity. It's likely a matter of just teaching
d-i about the right firmware

/me digs
  paul



On Sun, Nov 27, 2016 at 2:09 PM, Vagrant Cascadian <vagr...@debain.org>
wrote:

> On 2016-11-27, Paul Tagliamonte wrote:
> > Awesome. I preformed these steps, but I haven't attached a Serial
> > device to it yet.
> >
> > I'll continue testing further after I hook this up to serial
>
> Looks like you may also have to borrow a .dtb from linux 4.9.x:
>
>   https://packages.debian.org/search?suite=experimental;
> section=all=armhf=contents=sun8i-h3-nanopi-neo.dtb
>
> Just copy that onto the debian-installer media in the dtbs
> directory. Not sure if it'll work, but if it does, you might want to
> request a backport of it to the linux kernel packages.
>
>
> Happy testing!
>
>
> live well,
>   vagrant
>
> > On Sun, Nov 27, 2016 at 3:25 AM, Vagrant Cascadian <vagr...@aikidev.net>
> wrote:
> >> On 2016-11-26, Paul Tagliamonte wrote:
> >>> Please enable FriendlyARM NanoPi NEO
> >>
> >> Thanks for taking a stab at it!
> >>
> >>
> >> Built a test package for you, should be available here:
> >>
> >>   deb http://cascadia.debian.net/~vagrant/debian UNRELEASED main
> >>
> >> Install u-boot-sunxi:armhf from there, which has nanopi_neo included (in
> >> fact, all other builds are disabled).
> >>
> >>
> >> To test, you could use debian-installer's daily images:
> >>
> >>   https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-
> card-images/
> >>
> >> Download firmware.none.img.gz and partition.img.gz, and then something
> >> like (just like it says in the README*):
> >>
> >>   zcat firmware.none.img.gz partition.img.gz | dd of=/dev/mmcblk0
> >>
> >>
> >> Then, reading /usr/share/doc/u-boot-sunxi/README.Debian, you can
> install
> >> the nanopi_neo u-boot image:
> >>
> >>   dd if=/usr/lib/u-boot/nanopi_neo/u-boot-sunxi-with-spl.bin
> of=/dev/mmcblk0 bs=1024 seek=8
> >>
> >>
> >> Then you ought to be able to see u-boot load on the serial console, and
> >> if you're lucky, boot into debian-installer. You may need a USB network
> >> adapter to get very far...
> >>
> >>
> >> If the u-boot bits at least work, I'll be happy to add it to the
> >> package, and add you to our list of testers. A rough guide to testing is
> >> available here:
> >>
> >>   https://wiki.debian.org/U-boot
> >>
> >>
> >> Hmmm, now that I've written this email, some of it would be generally
> >> useful to add to the wiki page...
> >>
> >>
> >> live well,
> >>   vagrant
> >
> >
> >
> > --
> > :wq
>



-- 
:wq

Bug#845932: Please enable FriendlyARM NanoPi NEO

[Paul Tagliamonte]

Awesome. I preformed these steps, but I haven't attached a Serial
device to it yet.

I'll continue testing further after I hook this up to serial

On Sun, Nov 27, 2016 at 3:25 AM, Vagrant Cascadian <vagr...@aikidev.net> wrote:
> On 2016-11-26, Paul Tagliamonte wrote:
>> Please enable FriendlyARM NanoPi NEO
>
> Thanks for taking a stab at it!
>
>
> Built a test package for you, should be available here:
>
>   deb http://cascadia.debian.net/~vagrant/debian UNRELEASED main
>
> Install u-boot-sunxi:armhf from there, which has nanopi_neo included (in
> fact, all other builds are disabled).
>
>
> To test, you could use debian-installer's daily images:
>
>   https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/
>
> Download firmware.none.img.gz and partition.img.gz, and then something
> like (just like it says in the README*):
>
>   zcat firmware.none.img.gz partition.img.gz | dd of=/dev/mmcblk0
>
>
> Then, reading /usr/share/doc/u-boot-sunxi/README.Debian, you can install
> the nanopi_neo u-boot image:
>
>   dd if=/usr/lib/u-boot/nanopi_neo/u-boot-sunxi-with-spl.bin of=/dev/mmcblk0 
> bs=1024 seek=8
>
>
> Then you ought to be able to see u-boot load on the serial console, and
> if you're lucky, boot into debian-installer. You may need a USB network
> adapter to get very far...
>
>
> If the u-boot bits at least work, I'll be happy to add it to the
> package, and add you to our list of testers. A rough guide to testing is
> available here:
>
>   https://wiki.debian.org/U-boot
>
>
> Hmmm, now that I've written this email, some of it would be generally
> useful to add to the wiki page...
>
>
> live well,
>   vagrant



-- 
:wq

Bug#845932: Please enable FriendlyARM NanoPi NEO

[Paul Tagliamonte]

Package: u-boot-sunxi
Severity: wishlist
thanks

Please enable FriendlyARM NanoPi NEO

Thanks for all your work!
  Paul

-- 
:wq

Bug#839109: [pkg-go] Bug#839109: closed by Paul Tagliamonte <paul...@gmail.com> (RE: dh-golang: Possibly wrong XS- prefix for Go-Import-Path field)

[Paul Tagliamonte]

Control: owner -1 !
thanks

On Tue, Oct 25, 2016 at 05:00:27PM +0200, Guillem Jover wrote:
> Then, in that case, I'd appreciate if the function and its rationale
> could be documented instead in the "Debian Go packaging policy". :)

Super sensible, great idea. I'll own this. Thanks, Guillem!

> Thanks,
> Guillem

   Paul


signature.asc
Description: PGP signature

Bug#838386: moreinfo

[Paul Tagliamonte]

I had a second to poke around a bit more, so I looked a bit more at
what other error messages I could have it give me. Here's some followup:

I opened nm-connection-editor again and tried to edit the VPN I have
already set up. I clicked on 'edit', and the UI showed me this:

http://i.imgur.com/Ty3sLCi.png

Seeing as how that looked like a dbus name, I checked d-feet to see if
such a service was riding the bus.

Seems like yes: http://i.imgur.com/ikklOhq.png

When I hit the dbus interface as root, I could introspect it. Seems like
it's on the bus and responding to requests. This is funny to me. So, I
looked for where this came from, and saw it was defined in
/etc/NetworkManager/VPN/nm-strongswan-service.name

I opened it and double checked the paths. They seem good, except one
file needed a `.so` appenended to it. This seems sane enough for a path
you'd expect to be a .so, so I don't think it's a likely lead. Here's
shell output:

| [paultag@cassiel:~][⌚ 01:39 PM] ♥  cat 
/etc/NetworkManager/VPN/nm-strongswan-service.name 
| [VPN Connection]
| name=strongswan
| service=org.freedesktop.NetworkManager.strongswan
| program=/usr/lib/ipsec/charon-nm
| 
| [GNOME]
| auth-dialog=/usr/lib/NetworkManager/nm-strongswan-auth-dialog
| properties=/usr/lib/NetworkManager/libnm-strongswan-properties
| [paultag@cassiel:~][⌚ 01:39 PM] ♥  ls -l /usr/lib/ipsec/charon-nm
| -rwxr-xr-x 1 root root 30896 Jul 16 09:32 /usr/lib/ipsec/charon-nm
| [paultag@cassiel:~][⌚ 01:39 PM] ♥  ls -l 
/usr/lib/NetworkManager/nm-strongswan-auth-dialog
| -rwxr-xr-x 1 root root 14816 Aug 28 04:47 
/usr/lib/NetworkManager/nm-strongswan-auth-dialog
| [paultag@cassiel:~][⌚ 01:40 PM] ♥  ls -l 
/usr/lib/NetworkManager/libnm-strongswan-properties
| ls: cannot access '/usr/lib/NetworkManager/libnm-strongswan-properties': No 
such file or directory
| [paultag@cassiel:~][⌚ 01:40 PM] ♥  ls -l 
/usr/lib/NetworkManager/libnm-strongswan-properties.so 
| -rw-r--r-- 1 root root 23128 Aug 28 04:47 
/usr/lib/NetworkManager/libnm-strongswan-properties.so

Nothing totally broken. Not sure why it isn't talking with this service.
Maybe the API of the dbus service changed? Could this be a strongswan-nm
bug?

Not sure where to look next,
   Paul


signature.asc
Description: PGP signature

Bug#774153: Seems to still be present

[Paul Tagliamonte]

On Tue, Sep 20, 2016 at 06:27:14PM -0400, Paul Tagliamonte wrote:
> I'm not totally sure what's going on here since this is a Jessie ->
> Jessie upgrade, and the version went from 215-17+deb8u4 ->
> 215-17+deb8u5, which makes mismatches in systemctl and the running
> systemd a bit suspect in my mind (same upstream version, right?)

One thing that was bugging me was that the system was restarted after
the change, but upon further reflection, I had a thought that since
udev.postinst never runs, initramfs is never updated, and pid 1 would
still be the "old" initramfs systemd. I wonder if that's part of it?

Also; attached the actual strace. I forgot in my last mail.

Cheers,
  Paul
4475  execve("/bin/systemctl", ["systemctl", "stop", "udev.service"], [/* 12 
vars */]) = 0
4475  brk(0)= 0x7f2905cc4000
4475  access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
4475  mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7f290597c000
4475  access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
4475  open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
4475  fstat(3, {st_mode=S_IFREG|0644, st_size=51491, ...}) = 0
4475  mmap(NULL, 51491, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f290596f000
4475  close(3)  = 0
4475  access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
4475  open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
4475  read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20o\0\0\0\0\0\0"..., 832) = 832
4475  fstat(3, {st_mode=S_IFREG|0755, st_size=137440, ...}) = 0
4475  mmap(NULL, 2213008, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
= 0x7f29052c
4475  mprotect(0x7f29052d8000, 2093056, PROT_NONE) = 0
4475  mmap(0x7f29054d7000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7f29054d7000
4475  mmap(0x7f29054d9000, 13456, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f29054d9000
4475  close(3)  = 0
4475  access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
4475  open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
4475  read(3, 
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\34\2\0\0\0\0\0"..., 832) = 832
4475  fstat(3, {st_mode=S_IFREG|0755, st_size=1738176, ...}) = 0
4475  mmap(NULL, 3844640, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
= 0x7f2904f15000
4475  mprotect(0x7f29050b6000, 2097152, PROT_NONE) = 0
4475  mmap(0x7f29052b6000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a1000) = 0x7f29052b6000
4475  mmap(0x7f29052bc000, 14880, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f29052bc000
4475  close(3)  = 0
4475  access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
4475  open("/lib/x86_64-linux-gnu/libselinux.so.1", O_RDONLY|O_CLOEXEC) = 3
4475  read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20c\0\0\0\0\0\0"..., 832) = 832
4475  fstat(3, {st_mode=S_IFREG|0644, st_size=142728, ...}) = 0
4475  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7f290596e000
4475  mmap(NULL, 2246896, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
= 0x7f2904cf
4475  mprotect(0x7f2904d11000, 2097152, PROT_NONE) = 0
4475  mmap(0x7f2904f11000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x21000) = 0x7f2904f11000
4475  mmap(0x7f2904f13000, 6384, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f2904f13000
4475  close(3)  = 0
4475  access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
4475  open("/lib/x86_64-linux-gnu/liblzma.so.5", O_RDONLY|O_CLOEXEC) = 3
4475  read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P(\0\0\0\0\0\0"..., 832) = 832
4475  fstat(3, {st_mode=S_IFREG|0644, st_size=141752, ...}) = 0
4475  mmap(NULL, 2236936, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
= 0x7f2904acd000
4475  mprotect(0x7f2904aef000, 2093056, PROT_NONE) = 0
4475  mmap(0x7f2904cee000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x21000) = 0x7f2904cee000
4475  close(3)  = 0
4475  access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
4475  open("/lib/x86_64-linux-gnu/libgcrypt.so.20", O_RDONLY|O_CLOEXEC) = 3
4475  read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\216\0\0\0\0\0\0"..., 832) = 
832
4475  fstat(3, {st_mode=S_IFREG|0644, st_size=924096, ...}) = 0
4475  mmap(NULL, 3020448, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
= 0x7f29047eb000
4475

Bug#774153: Seems to still be present

[Paul Tagliamonte]

found 774153 215-17+deb8u5
tags 774153 - moreinfo
retitle 774153 systemd-tty-ask-password hangs udev postinst until daemon-reexec 
is run
thanks

A friend of mine hit this bug, and it presented in a pretty nasty way.
Some details:

The system was running Jessie, and upgraded from Wheezy when Jessie came
out. The system was restarted 8 days ago, and had this issue present
itself when systemd/udev was updated. The system was running
215-17+deb8u4 before installing 215-17+deb8u5.

In udev's postinst, it asks for a udev stop, which winds up hanging
because systemctl is asking systemd-tty-ask-password-agent for something.

This causes dpkg to hang because the postinst hangs. This wound up
causing a bit of a headache in an (routine!) stable upgrade, and this
caused a friend bunch of lost time to strace trying to track this one
down.

After a bit of digging, I came accross this bug which sounded similar
enough that I tried a `systemctl daemon-reexec`. This wound up fixing
udev from blocking, and let my friend finish the system upgrade.

I'm not totally sure what's going on here since this is a Jessie ->
Jessie upgrade, and the version went from 215-17+deb8u4 ->
215-17+deb8u5, which makes mismatches in systemctl and the running
systemd a bit suspect in my mind (same upstream version, right?)

As such, I've retitled the bug according to my latest understanding of
this problem. I've also removed the moreinfo tag.

I've attached an strace of the stop that was sent to me, I've CC'd
weaver as well. Happy to provide more thoughts, but I don't know how to
reproduce this, so I tried to dump as much as I know about the failure
mode.


FWIW, this seems like it is still a bug that impacts stable -- I don't
want to play severity ping-pong, but bumping this above normal might be
worth it.

<3,
   paultag


signature.asc
Description: PGP signature

Bug#829583: RM: golang-clockwork-dev -- ROM; replaced by golang-github-jonboulle-clockwork

[Paul Tagliamonte]

Package: ftp.debian.org
Severity: important
thanks

golang-clockwork-dev was replaced by something with a fancier source and
binary name.

I'll remove this in a minute.

 Paul


signature.asc
Description: PGP signature

Bug#819703: Let's NOT remove xscreensaver (+1)

[Paul Tagliamonte]

On Sat, Apr 02, 2016 at 03:17:11PM +0200, Axel Beckert wrote:
> > Sounds fine, let's file a RoM
> 
> Are you nuts? You just said, it's your favourite! Why do you want to
> kill it?

Well, yes, I am a bit nuts, but here's why.


I think we can all agree the current situation is broken. Fixes in newer
versions aren't getting backported, which means either the maintainer
isn't interested in backporting bugfixes to stable (it's a lot of work,
I understand it), or users don't report bugs to the BTS, going right
upstream, and the maintainer isn't aware of them (which might explain
why upstream is seeing bugs from users in Ubuntu and Debian).


Even if it's just from testing and the next stable release.

However, ore and more, I'm becoming a bit concerend about leaf packages
we maintain in stable that have their own release schedule, where they
do significat testing to ensure no regressions or breakages. We don't
have a good story for updating a package like this (short of backports,
but even that isn't a clear win).


This wouldn't be the first removal because an upstream isn't happy, and
it won't be the last.


At the very least, CC'ing ftpmaster@ and asking what they think, the
obvious response is "Sure, remove it".

I'm not going to tell someone with any fancy hat I might have hanging up
to maintain something against their will, or back a decision to piss off
your upstream.


So, let's make a deal. I see a two outcomes that are tolerable:

  - ${BUGS} in xscreensaver get a backport to the version in stable, and
a s-p-u, and upstream tells distro users to report bugs with the distros.

  - xscreensaver is removed from stable, unstable stays up to date. This
doesn't make upstream happy until next release.


The SRMs might have something to say about the first ("Is this a RC bug,
why are you backportting a papercut bug"), and I've started to become
annoyed with the second type of package.


Anyway, my two cents. This entire discussion appears to be a pit of
angry emotions and no real communication. That's a shame. So this will
be the last I'll say on this until (if?) you file a RoM. In that case,
likely dak will reply on my behalf.

Cheers,
  Paul


signature.asc
Description: PGP signature

Bug#819697: timezone parsing bug on Valid-Until

[Paul Tagliamonte]

Package: apt
Severity: important
thanks

apt appears to consider Valid-Until without proper timezone support.

From a Release file:

| Date:Thu, 31 Mar 2016 19:16:26 -0400
| Valid-Until: Thu, 31 Mar 2016 19:16:27 -0400
   ^ 1s expiry

I checked this three seconds (literally, heh) after signing it, and ran
apt-get update.

I was supprised to see the following:

| E: Release file for http://localhost/infra/dists/unstable/InRelease is expired
| (invalid since 4h 0min 2s). Updates for this repository will not be applied.

4 hours! At the time of writing the wall clock says:

| Thu Mar 31 19:19:53 EDT 2016 (where EDT is -0400)

So, not four hours!


I strongly suspected that apt did this correctly, and that this was
purely cosmetic, so I checked, I set a Valid-Until to 1h, and got:

| E: Release file for http://localhost/infra/dists/unstable/InRelease is
| expired (invalid since 3h 0min 3s). Updates for this repository will not
| be applied.

But it's still valid!

Just for clarity:

| (debian)[paultag@cassiel:~/tmp][⌚ 07:21 PM] ♥  cat 
infra/dists/unstable/InRelease | grep Valid-Until
| Valid-Until: Thu, 31 Mar 2016 20:20:54 -0400
| (debian)[paultag@cassiel:~/tmp][⌚ 07:21 PM] ♥  date
| Thu Mar 31 19:21:53 EDT 2016



In the case where our machines are often in UTC, this might not actually
hit Debian all that hard, but it could be an issue if someone Baker
Island's -12:00 timezone was being attacked by keeping a view of the
archive stale for a day, for their target over in New Zealand's +13:45
timezone.



Anyway, enough trouble for me tonight. Thanks for working on apt.

Cheers,
  Paul


signature.asc
Description: PGP signature

Bug#816741: getfem++ has a funny Build-Depends line

[Paul Tagliamonte]

Package: getfem++
Severity: normal
thanks

getfem++ has a funny B-D. In particular:

scilab [!mips !kfreebsd-amd64 !kfreebsd-i386 !hurd-i386 !s390x !armel!arm64]

The `!armel!arm64` is misunderstood by dpkg to mean "Not armel!arm64",
not a negation of both. I filed a bug against dpkg (#784808 - cc'ing it
just so we have one documented case of this in the wild).

You can see this in your arm64 build log[1]

Merged Build-Depends: [] python-numpy, python-scipy, scilab

Compare that with the s390x log[2]:

Merged Build-Depends: [] python-numpy, python-scipy

The fix should be adding a space between your armel and arm64 entry.


Thanks!
  Paul


[1]: 
https://buildd.debian.org/status/fetch.php?pkg=getfem%2B%2B=arm64=4.2.1~beta1~svn4635~dfsg-5%2Bb1=1455620756
[2]: 
https://buildd.debian.org/status/fetch.php?pkg=getfem%2B%2B=s390x=4.2.1~beta1~svn4635~dfsg-5%2Bb1=1455621409


signature.asc
Description: PGP signature

Bug#815478: getfem++ hilariously already enabled on arm64

[Paul Tagliamonte]

Hey tbm,

I found a bug when parsing the archive and thinking hard about dpkg's
perl parser (bugs #784808[1] and another bug I filed bug don't have a
bug number for yet), and checked the build logs -- this
package is already built with scilab in armel and arm64.

Yes, it's a typo, but hey, you wanted it enabled anyway, right? :)

Cheers,
  Paul

[1]: https://bugs.debian.org/784808
[2]: https://bugs.debian.org/getfem++ "getfem++ has a funny Build-Depends line"


signature.asc
Description: PGP signature

Bug#816515: Disallow (< ...) and (> ...) package relations

[Paul Tagliamonte]

Package: debian-policy
Severity: normal
thanks

For a while now, the (< ..) and (> ...) Dependency relation has been
discouraged, and not allowed for new packages, since it's confusing (it
actually means <= and >= not >> and <<).


There are only two packages left with this in their source entry. I've
filed two bugs on it, since it's easy to fix.


Once they're fixed, would it be wise to adjust Policy to disallow this
globally?


Thanks!
  Paul

Bug#816476: rp-pppoe contains (> ...) Depends relationship

[Paul Tagliamonte]

Package: rp-pppoe
Severity: important
thanks

It looks like rp-pppoe Build-Depends: debhelper (> 4), which actually
hilariously means (>> 4). Also 4 is hella old. Can haz more compat?

This was discouraged a while ago, could this get updated?

Thanks, aba,
  Paul


signature.asc
Description: PGP signature

Bug#816475: Contains Depends relationship (> ...)

[Paul Tagliamonte]

Package: inform-mode
Severity: important
thanks

This package Build-Depends: debhelper (> 5), which means (>= 5), not
(>> 5).

This was discouraged eons ago, and needs to be fixed. Please use (>> 5).

Thanks,
  Paul


signature.asc
Description: PGP signature

Bug#816474: Add a Lintian check for insane Depends relations

[Paul Tagliamonte]

Package: lintian
Severity: normal
thanks

I'd be great if Lintian could detect garbage such as:

Build-Depends: foo [amd64 !hurd-amd64]

Since Depends lines must be "all in".

I'd also like this to be an autoreject :)

Thanks for all your work,
  Paul


signature.asc
Description: PGP signature

Bug#816473: dpkg-dev should validate arch constrained dependencies better

[Paul Tagliamonte]

Package: dpkg
Severity: normal
thanks

dpkg-dev only allows all-or-none in arch qualified depends relations,
so:

  foo [bar baz]

Is fine. As is:

  foo [!bar !baz]

However, this is not:

  foo [!bar baz]



I'm validating this in a parser I have, and I had clisp break my parser
in Sources on the archive due to this. I see they fixed it in git
master[1], but this got through all of our infra and all that happened
was that it was bd-uninstallable in the end.


This is vaugely related to a bug I filed a year ago:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784808


Thanks for all your work,
  Paul

[1]: 
http://anonscm.debian.org/cgit/pkg-common-lisp/clisp.git/patch/?id=e4591c4cd0171d50010946e2e985a9dbe8bd052a


signature.asc
Description: PGP signature

Bug#813157: git: please default fsckobjects to true in transfer, fetch, and receive

[Paul Tagliamonte]

Yeah, I was a bit supprised to learn this wasn't on by default,
and I can't imagine this is common (or expected), since I'd like to
think I know a fair amount about Git.


Thanks for bring it upstream!

This seems like a big deal for Debian, since a large number of our
repos[1] still use an insecure transport, which means it's *trivial* to
actively tamper with the source that we see post-clone, without even giving
them a split view of the repo (and showing a problem on push)!


It's vital we turn on fsck to true for transfer.fsckobjects on developer
~/.gitconfigs while we wait back about this.


Thanks for all your work!
  Paul

[1]: Currently 28,932 source packages; as seen on
 https://lintian.debian.org/tags/vcs-field-uses-insecure-uri.html


signature.asc
Description: PGP signature

Bug#812962: vcs-field-uses-insecure-uri sometimes misses things

[Paul Tagliamonte]

Package: lintian
Severity: normal
thanks

Hey, lintian folks!

Holy crap, the vcs-field-uses-insecure-uri tag is already in sid! I'm so
happy, I don't have words. MASSIVE HUGS.

However, I see the patch has::

| if ($parts[0] =~ m%^(?:git|http)://%) {

Which might miss some things, like "nosmart+http"[1].

Oodles of love,
  Paul

[1]: as seen in the wild on ltsp[2][3]
[2]: https://sources.debian.net/src/ltsp/5.5.5-1/debian/control/#L18
[3]: Hi, vagrantc! You're great![4]
[4]: Did you ever realize you could use links like a tree? Me either.


signature.asc
Description: PGP signature

Bug#811101: Vcs-Git uses clone URL for non-anon checkout

[Paul Tagliamonte]

Package: tcos
Severity: normal
thanks

Heyya,

your Vcs-Git tag appears to use `g...@github.com`. I also notice this is
not in the Debian GitHub organization; you should feel free to move
packages into the Debian GitHub organization if you find that you
absolutely must be on GitHub.

Please change Vcs-Git to HTTPS. Something like:


```
Vcs-Git: https://github.com/mariodebian/tcos.git
```

Thanks!
  Paul



signature.asc
Description: PGP signature

Bug#811100: Vcs-Git uses clone URL for non-anon checkout

[Paul Tagliamonte]

Package: rkflashtool
Severity: normal
thanks

Heyya,

your Vcs-Git tag appears to use `g...@github.com`. I also notice this is
not in the Debian GitHub organization; you should feel free to move
packages into the Debian GitHub organization if you find that you
absolutely must be on GitHub.

Please change Vcs-Git to HTTPS. Something like:


```
Vcs-Git: https://github.com/linux-rockchip/rkflashtool.git
```

Thanks!
  Paul


signature.asc
Description: PGP signature

Bug#809165: Patch attached

[Paul Tagliamonte]

tags 809165 - moreinfo
thanks

Confirmed the diff as attached works to solve the regression.

Cheers,
  Paul

On Sun, Dec 27, 2015 at 06:22:14PM -0500, Paul Tagliamonte wrote:
> tags 809165 + patch moreinfo
> thanks
> 
> Heyya,
> 
> Thinned out my patch to something a bit more digestable. Added a blank
> changelog entry, so you can just `dch -rm` if it looks good. I had to
> refresh the patch against the package, so the line offsets look
> different than the PR. Content should match, though.
> 
> Added DEP3 headers, but I just noticed other patches don't have them.
> Feel free to strip out the headers if they bother you.
> 
> I got most of the way through a compile, but I had to run. This patch
> still needs testing. I'll try and get that done and follow up.
> 
> Cheers,
>   Paul

> diff -u gcc-5-5.3.1/debian/changelog gcc-5-5.3.1/debian/changelog
> --- gcc-5-5.3.1/debian/changelog
> +++ gcc-5-5.3.1/debian/changelog
> @@ -1,3 +1,11 @@
> +gcc-5 (5.3.1-5) UNRELEASED; urgency=medium
> +
> +  [ Paul Tagliamonte ]
> +  * Apply PR 68668, which fixes a regression in detecting the type of an
> +array of consts in some situations. (Closes: #809165)
> +
> + -- Paul Tagliamonte <paul...@debian.org>  Sun, 27 Dec 2015 14:01:21 -0500
> +
>  gcc-5 (5.3.1-4) unstable; urgency=medium
>  
>* Update to SVN 20151219 (r231847, 5.3.1) from the gcc-5-branch.
> diff -u gcc-5-5.3.1/debian/rules.patch gcc-5-5.3.1/debian/rules.patch
> --- gcc-5-5.3.1/debian/rules.patch
> +++ gcc-5-5.3.1/debian/rules.patch
> @@ -92,6 +92,7 @@
>   gcc-configure-pie \
>   ada-gnattools-ldflags \
>   libjit-ldflags \
> +pr68668 \
>  
>  # this is still needed on powerpc, e.g. firefox and insighttoolkit4 will 
> ftbfs.
>  ifneq (,$(filter $(DEB_TARGET_ARCH),powerpc))
> --- gcc-5-5.3.1.orig/debian/patches/pr68668.diff
> +++ gcc-5-5.3.1/debian/patches/pr68668.diff
> @@ -0,0 +1,19 @@
> +Description: Clean up handling of arrays of constants not being groked
> + correctly.
> +Forwarded: not-needed
> +Origin: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68668
> +Bug-Debian: https://bugs.debian.org/809165
> +Author: Marek Polacek
> +Reviewed-By: Paul Tagliamonte <paul...@debian.org>
> +
> +--- a/src/gcc/c/c-decl.c
>  b/src/gcc/c/c-decl.c
> +@@ -6444,6 +6444,8 @@ grokdeclarator (const struct c_declarato
> +   {
> + /* Transfer const-ness of array into that of type pointed to.  */
> + type = TREE_TYPE (type);
> ++if (orig_qual_type != NULL_TREE)
> ++  orig_qual_type = TREE_TYPE (orig_qual_type);
> + if (type_quals)
> +   type = c_build_qualified_type (type, type_quals, orig_qual_type,
> +  orig_qual_indirect);





signature.asc
Description: PGP signature

Bug#809165: Regression with arrays of constants as function arguments being misinterpreted

[Paul Tagliamonte]

Package: gcc-5
Severity: important
Version: 5.3.1-4
Tag: fixed-upstream
thanks

Heyya doko,

Upstream bug is at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69037 - I
didn't want to bother with Forwarded, since I didn't forward it.

The latest upload of gcc-5 seems to break on 

```c
typedef const int array_t[3];
int allocate_with_allocator(array_t ar)
{
int a = ar[0];
int b = ar[1];
return a + b;
}
```

Breaks with:

```
test.c: In function ‘allocate_with_allocator’:
test.c:5:13: warning: initialization makes integer from pointer without a cast 
[-Wint-conversion]
 int a = ar[0];
 ^
test.c:6:13: warning: initialization makes integer from pointer without a cast 
[-Wint-conversion]
 int b = ar[1];
 ^
```

on 5.3.1-4 (but the old 5.2.1-23 is fine)

Fix commited to svn in r231374, but I couldn't quickly apply the trunk patches,
so I figured I'd let you do what you usually do with this stuff :)

Cheers,
  Paul


signature.asc
Description: PGP signature

Bug#809165: Patch attached

[Paul Tagliamonte]

tags 809165 + patch moreinfo
thanks

Heyya,

Thinned out my patch to something a bit more digestable. Added a blank
changelog entry, so you can just `dch -rm` if it looks good. I had to
refresh the patch against the package, so the line offsets look
different than the PR. Content should match, though.

Added DEP3 headers, but I just noticed other patches don't have them.
Feel free to strip out the headers if they bother you.

I got most of the way through a compile, but I had to run. This patch
still needs testing. I'll try and get that done and follow up.

Cheers,
  Paul
diff -u gcc-5-5.3.1/debian/changelog gcc-5-5.3.1/debian/changelog
--- gcc-5-5.3.1/debian/changelog
+++ gcc-5-5.3.1/debian/changelog
@@ -1,3 +1,11 @@
+gcc-5 (5.3.1-5) UNRELEASED; urgency=medium
+
+  [ Paul Tagliamonte ]
+  * Apply PR 68668, which fixes a regression in detecting the type of an
+array of consts in some situations. (Closes: #809165)
+
+ -- Paul Tagliamonte <paul...@debian.org>  Sun, 27 Dec 2015 14:01:21 -0500
+
 gcc-5 (5.3.1-4) unstable; urgency=medium
 
   * Update to SVN 20151219 (r231847, 5.3.1) from the gcc-5-branch.
diff -u gcc-5-5.3.1/debian/rules.patch gcc-5-5.3.1/debian/rules.patch
--- gcc-5-5.3.1/debian/rules.patch
+++ gcc-5-5.3.1/debian/rules.patch
@@ -92,6 +92,7 @@
 	gcc-configure-pie \
 	ada-gnattools-ldflags \
 	libjit-ldflags \
+pr68668 \
 
 # this is still needed on powerpc, e.g. firefox and insighttoolkit4 will ftbfs.
 ifneq (,$(filter $(DEB_TARGET_ARCH),powerpc))
--- gcc-5-5.3.1.orig/debian/patches/pr68668.diff
+++ gcc-5-5.3.1/debian/patches/pr68668.diff
@@ -0,0 +1,19 @@
+Description: Clean up handling of arrays of constants not being groked
+ correctly.
+Forwarded: not-needed
+Origin: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68668
+Bug-Debian: https://bugs.debian.org/809165
+Author: Marek Polacek
+Reviewed-By: Paul Tagliamonte <paul...@debian.org>
+
+--- a/src/gcc/c/c-decl.c
 b/src/gcc/c/c-decl.c
+@@ -6444,6 +6444,8 @@ grokdeclarator (const struct c_declarato
+ 	  {
+ 	/* Transfer const-ness of array into that of type pointed to.  */
+ 	type = TREE_TYPE (type);
++if (orig_qual_type != NULL_TREE)
++  orig_qual_type = TREE_TYPE (orig_qual_type);
+ 	if (type_quals)
+ 	  type = c_build_qualified_type (type, type_quals, orig_qual_type,
+ 	 orig_qual_indirect);


signature.asc
Description: PGP signature

Bug#806481: [pkg-go] Bug#806481: Backport etcd to Jessie

[Paul Tagliamonte]

> I don't have any uploads anywhere, as I was just trying to do a build from
> the
> git repos of each repository.  I did read a bit over the steps to make
> things
> ready for backports, but I didn't try any of that yet.  Is it just a
> matter of
> changing the version number with an appropriate Changelog message?  If so,
> I
> can try starting with one to get the hang of it.  Is there any easy howtos
> for
>

Basically, yeah! Give one a shot and send it to me, and I can help make sure
everything looks great!


> beginners?  Most documentation I've seen is more reference material
> orientated, which I find a little hard to parse to get started.
>

Yeah, it's not great. Give it a best-whack and i'll provide some feedback,
it sounds like you're already doing it!


>
> If you want, I can stick my other files somewhere to download.  I don't
> know
> if they will be useful.
> --
> Matthew


Cheers,
  Paul



-- 
:wq

Bug#806481: [pkg-go] Bug#806481: Backport etcd to Jessie

[Paul Tagliamonte]

On Sat, Nov 28, 2015 at 03:40:19PM -0500, Matthew Dawson wrote:
> On November 28, 2015 03:14:16 PM Dmitry Smirnov wrote:
> > On Friday 27 November 2015 21:56:36 Paul Tagliamonte wrote:
> > > Mind if I do it?
> > 
> > Not at all, if you have time... I have no objections. :)
> > 
> > > After it's in Jessie, it might be easier to keep up to date, too.
> > 
> > Unfortunately I can't promise that I will be of help with maintaining
> > backport...
> Hi Paul,
> 
> If I can help with this effort, let me know as I'm also interested in having 
> etcd in Jessie.  I already started trying to get everything to compile 
> against 
> a stock Jessie, and was mostly successful.  To get everything working did 
> require a newer golang (1.4 in my case).  I'm not currently a Debian project 
> member, so I'm not sure how I can help.  Let me know either way.

Yay! Golang (as tianon noted) is in backports now!

I'd be happy to sponsor you work - are the source uploads anywhere I can
dget?

Thanks!
  Tag

> -- 
> Matthew




signature.asc
Description: PGP signature

Bug#806481: Backport to Jessie

[Paul Tagliamonte]

Package: etcd
Severity: wishlist
thanks

It'd be great to backport this to Jessie!

Thanks for your work,
  Paul


signature.asc
Description: PGP signature

Bug#806481: Backport etcd to Jessie

[Paul Tagliamonte]

On Sat, Nov 28, 2015 at 12:19:54PM +1100, Dmitry Smirnov wrote:
> On Friday 27 November 2015 14:55:30 Paul Tagliamonte wrote:
> Hi Paul,
> 
> Without funding I won't be able to backport Etcd.
> A significant amount of work is required. I estimate that about 20 dependency 
> packages need to be backported as well. Frankly I doubt that the effort is 
> worth it -- etcd is a statically linked binary so it would work just fine if 
> installed straight from "testing" to Jessie (which could be facilitated by 
> trivial apt pinning). At least that's how I use etcd on Jessie at the 
> moment...

Understandable. Mind if I do it? After it's in Jessie, it might be
easier to keep up to date, too.

Cheers,
  Paul



signature.asc
Description: PGP signature

Bug#795046: Add dependency on ruby-rspec-its

[Paul Tagliamonte]

Hey friends!

this looks like a missing dependency on ruby-rspec-its -- I added it
in (patch attached), but it still fails -- but with new failures!

Thanks for all your hard work,
  Paul
Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 ruby-parslet (1.6.1-1.1) UNRELEASED; urgency=medium
 .
   * Non-maintainer upload.
   * Add missing dependency on ruby-rspec-its
Author: Paul Tagliamonte <paul...@debian.org>

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: <vendor|upstream|other>, 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: <no|not-needed|url proving that it has been forwarded>
Reviewed-By: 
Last-Update: 

--- ruby-parslet-1.6.1.orig/spec/parslet/atoms/dsl_spec.rb
+++ ruby-parslet-1.6.1/spec/parslet/atoms/dsl_spec.rb
@@ -1,4 +1,5 @@
 require 'spec_helper'
+require 'rspec/its'
 
 describe Parslet::Atoms::DSL do
   describe "deprecated methods" do
@@ -14,4 +15,4 @@ describe Parslet::Atoms::DSL do
   its(:positive) { should == true }
 end
   end
-end
\ No newline at end of file
+end
--- ruby-parslet-1.6.1.orig/spec/parslet/position_spec.rb
+++ ruby-parslet-1.6.1/spec/parslet/position_spec.rb
@@ -1,10 +1,11 @@
 # Encoding: UTF-8
 
 require 'spec_helper'
+require 'rspec/its'
 
 describe Parslet::Position do
   slet(:position) { described_class.new('öäüö', 4) }
 
   its(:charpos) { should == 2 }
   its(:bytepos) { should == 4 } 
-end
\ No newline at end of file
+end


signature.asc
Description: Digital signature

Bug#799014: d/copyright DEP5 slug is slightly wrong

[Paul Tagliamonte]

Package: perl
Severity: normal
X-Debbug-CC: ftpmas...@debian.org
thanks

The block quoted below is marked as BSD-4-Clause, but is actually a BSD-3
(without advertising), and is missing point 3

License: BSD-4-clause
 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions
 are met:
 1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
 2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
 4. Neither the name of the University nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.
 .
 THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
 ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
 FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 SUCH DAMAGE.


signature.asc
Description: Digital signature

Bug#798708: golang.*-dev packages should be arch:all

[Paul Tagliamonte]

Package: golang-gogoprotobuf-dev
Severity: wishlist
thanks

As discussed in the thread starting at
<55f1f19b.7000...@alexandreviau.net>, there's a very rough feeling that
golang-.*-dev packages ought to be arch:all, witih binaries split out.

Thoughts? Should we switch this package to arch:all?

Cheers,
  Paul


signature.asc
Description: Digital signature

Bug#795937: NMU uploaded to DELAYED/5

[Paul Tagliamonte]

Heyya!

I've sponsored Bradley's NMU to DELAYED/5 -- feel free to dcut cancel
the upload or beat it to sid.

Debdiff attached!
   Paul
diff -Nru mairix-0.23+git20131125/debian/changelog 
mairix-0.23+git20131125/debian/changelog
--- mairix-0.23+git20131125/debian/changelog2014-08-03 04:41:40.0 
-0400
+++ mairix-0.23+git20131125/debian/changelog2015-09-10 17:23:34.0 
-0400
@@ -1,3 +1,12 @@
+mairix (0.23+git20131125-0.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add fix-256-char-limit-on-filenames.patch to handle some of the
+stack-smashing bugs that have been mentioned in upstream's
+bugtracker. Closes: #795937
+
+ -- Bradley M. Kuhn   Wed, 09 Sep 2015 13:34:04 -0700
+
 mairix (0.23+git20131125-0.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
mairix-0.23+git20131125/debian/patches/fix-256-char-limit-on-filenames.patch 
mairix-0.23+git20131125/debian/patches/fix-256-char-limit-on-filenames.patch
--- 
mairix-0.23+git20131125/debian/patches/fix-256-char-limit-on-filenames.patch
1969-12-31 19:00:00.0 -0500
+++ 
mairix-0.23+git20131125/debian/patches/fix-256-char-limit-on-filenames.patch
2015-09-10 17:25:22.0 -0400
@@ -0,0 +1,25 @@
+Description: Partial fix for stack smashing bug.
+ As the author of the patch mentions, this may not be the only
+ place in mairix where a stack smash may occur, but this change does
+ correct a few static-sized buffers to be dynamically sized based on
+ inputs.
+Bug: https://github.com/rc0/mairix/issues/10
+Bug-Debian: http://bugs.debian.org/795937
+Author: Daniel Silverstone 
+Last-Update: 2015-08-18
+
+--- mairix-0.23+git20131125.orig/nvp.c
 mairix-0.23+git20131125/nvp.c
+@@ -146,9 +146,9 @@ struct nvp *make_nvp(struct msg_src *src
+   unsigned int tok;
+   char *q;
+   unsigned char qq;
+-  char name[256];
+-  char minor[256];
+-  char value[256];
++  char name[strlen(s)+1];
++  char minor[strlen(s)+1];
++  char value[strlen(s)+1];
+   enum nvp_action last_action, current_action;
+   struct nvp *result;
+   size_t pfxlen;
diff -Nru mairix-0.23+git20131125/debian/patches/series 
mairix-0.23+git20131125/debian/patches/series
--- mairix-0.23+git20131125/debian/patches/series   2014-08-03 
04:24:52.0 -0400
+++ mairix-0.23+git20131125/debian/patches/series   2015-09-10 
17:24:21.0 -0400
@@ -1,2 +1,3 @@
 #fix-test-suite.patch
 fix-search-with-equal-in-msgid.patch
+fix-256-char-limit-on-filenames.patch


signature.asc
Description: Digital signature

Bug#798474: sbuild uses wrong arch in .changes and .build filenames

[Paul Tagliamonte]

Package: sbuild
Severity: normal
thanks

When building with --arch-all-only, the resulting .changes and .build
have the chroot arch (in my case, amd64) in filenames, rather than
'all'.

'all' is also not a sane --arch, or that might have worked. Perhaps
allow it as a --build-arch ?

Seems funny that the architectures control header is mismatched :)

cheers,
  Paul


signature.asc
Description: Digital signature

Bug#785363: I let this guy through NEW

[Paul Tagliamonte]

I've pushed this through NEW, but there was a note that it wasn't being
processed because of this bug.

Perhaps it's time to clarify this with the ftp-masters, clear up policy
or close this bug. Leaving it as an idle blocker and playing pingpong
makes no sense.

Thanks,
  Paul


signature.asc
Description: Digital signature

Bug#796539: Friendly patch ping

[Paul Tagliamonte]

Heyya all --

I've seen no further feedback, would someone either provide further
review or merge this changeset?

Thanks!
  Paul


signature.asc
Description: Digital signature

Bug#796539: [buildd-tools-devel] Bug#796539: Friendly patch ping

[Paul Tagliamonte]

On Mon, Sep 07, 2015 at 09:19:50PM +0200, Johannes Schauer wrote:
> Hi Paul,
> 
> your current patch looks good to me and I'll merge it probably within a week.
> 
> Thanks!
> 
> cheers, josch

Hooray! Thanks, josch!

  Paul


signature.asc
Description: Digital signature

Bug#798031: [pkg-go] Bug#798031: influxdb: incorrectly named -dev package

[Paul Tagliamonte]

On Sat, Sep 05, 2015 at 02:40:19AM +1000, Dmitry Smirnov wrote:
> I'd use "golang-influxdb-dev" (it is most intuitive and easy to guess).

That's wrong, don't do that. We have a policy, please follow it. Helpers
can create correct relations, unless we have special snowflakes. Please
don't introduce any.

Cheers,
   Paul


signature.asc
Description: Digital signature

Bug#798031: [pkg-go] Bug#798031: influxdb: incorrectly named -dev package

[Paul Tagliamonte]

On Fri, Sep 04, 2015 at 12:21:13PM -0400, Alexandre Viau wrote:
> Hello Dimitry,
> 
> On 04/09/15 12:04 PM, Dmitry Smirnov wrote:
> > There is an "influxdb-dev" but it ships golang sources so it probably 
> > should 
> > have been named "golang-influxdb-dev". Please consider adding 
> > 
> > Provides: golang-influxdb-dev
> > 
> > to "influxdb-dev" and/or eventually rename the latter.
> > 
> > Thanks.
> > 
> 
> I'll quote tianon from IRC on a discussion we had on runc:
> >  "runc-dev" should probably be named "golang-github-opencontainers
> >  -runc-dev" instead :)
> 
> So, what should be the name of the influxdb dev package?
> 
> - golang-influxdb-dev?
> - golang-github-influxdb-influxdb-dev?
> 
> I would vote for golang-github-influxdb-influxdb-dev. Its easier to
> search for packages if there is only one naming scheme.

This isn't a vote. We have a policy. Please follow it.

The correct name is golang-github-influxdb-influxdb-dev for the dev
package. Source should be golang-github-influxdb-influxdb.


signature.asc
Description: Digital signature

Bug#798031: [pkg-go] Bug#798031: influxdb: incorrectly named -dev package

[Paul Tagliamonte]

On Sat, Sep 05, 2015 at 03:11:33AM +1000, Dmitry Smirnov wrote:
> On Friday 04 September 2015 12:50:34 Paul Tagliamonte wrote:
> > Source should be golang-github-influxdb-influxdb.
> 
> I agree that policy regarding naming of -dev packages is important but I also 
>  
> believe that there is no reason to rename source package. It is unnecessary 
> and I'd much like to keep it as "influxdb" -- if this is against the policy 
> than I suggest to amend policy to avoid enforcing name of the source package.

I said "should" not "must" -- I was just putting that in the mail in
case someone in the future found it looking for how to name a package.

influxdb makes sense, since it builds a binary called that.

Thanks,
Paul


signature.asc
Description: Digital signature

Bug#796539: [buildd-tools-devel] Bug#796539: Bug#796539: Forgot the patch (thanks josch)

[Paul Tagliamonte]

On Tue, Sep 01, 2015 at 06:54:12AM +0200, Johannes Schauer wrote:
> any extra repositories are written to
> /etc/apt/sources.list.d/sbuild-build-depends-archive.list inside the
> chroot. This path is also stored in the configuration key 'Dummy
> archive list file' and you can see the function 'cleanup_apt_archive'
> removes the file pointed to by that key.

Ah! That explains that. Thanks for that, Perl's not my first language, I
was trying to keep my focus on the small parts I thought I'd be using, I
totally missed that.

> I only just read the man page of apt-key, and maybe something similar
> to the sources.list can be done with keys too, by just dumping them
> into /etc/apt/trusted.gpg.d/sbuild-build-depends-archive.gpg (or
> similar) and then removing just that file in the end.

Good call. Updated patch attached.

> 
> I imagine it would be more difficult to use "apt-key del" to clean up
> because running that command requires you to know the key ID(s).
> 
> cheers, josch

Cheers,
  Paul
From 55717aa86c7c85fad1cad4025755a27ea8ef02eb Mon Sep 17 00:00:00 2001
From: Paul Tagliamonte <paul...@debian.org>
Date: Wed, 2 Sep 2015 10:41:05 -0400
Subject: [PATCH] Add --extra-repository-key flag for extra apt keys

This will allow users to specify which OpenPGP key should be added
to the trusted keys inside the chroot. This is particularly useful
if the target --extra-repository is not signed with a key that's
trusted by the base chroot.
---
 lib/Sbuild/Conf.pm |  6 +
 lib/Sbuild/Options.pm  |  3 +++
 lib/Sbuild/ResolverBase.pm | 58 ++
 man/sbuild.1.in| 20 ++--
 4 files changed, 85 insertions(+), 2 deletions(-)

diff --git a/lib/Sbuild/Conf.pm b/lib/Sbuild/Conf.pm
index 763ecaa..ffce72f 100644
--- a/lib/Sbuild/Conf.pm
+++ b/lib/Sbuild/Conf.pm
@@ -1069,6 +1069,12 @@ sub setup ($) {
 	DEFAULT => [],
 	HELP => 'Additional per-build packages available as build dependencies.  Do not set by hand.'
 	},
+	'EXTRA_REPOSITORY_KEYS'=> {
+	TYPE => 'ARRAY:STRING',
+	GROUP => '__INTERNAL',
+	DEFAULT => [],
+	HELP => 'Additional per-build apt repository keys.  Do not set by hand.'
+	},
 	'EXTRA_REPOSITORIES'=> {
 	TYPE => 'ARRAY:STRING',
 	GROUP => '__INTERNAL',
diff --git a/lib/Sbuild/Options.pm b/lib/Sbuild/Options.pm
index 587acad..b47b3f5 100644
--- a/lib/Sbuild/Options.pm
+++ b/lib/Sbuild/Options.pm
@@ -313,6 +313,9 @@ sub set_options {
 			"extra-repository=s" => sub {
 			   push(@{$self->get_conf('EXTRA_REPOSITORIES')}, $_[1]);
 		   },
+			"extra-repository-key=s" => sub {
+			   push(@{$self->get_conf('EXTRA_REPOSITORY_KEYS')}, $_[1]);
+		   },
 			"build-path=s" => sub {
 			   $self->set_conf('BUILD_PATH', $_[1]);
 			},
diff --git a/lib/Sbuild/ResolverBase.pm b/lib/Sbuild/ResolverBase.pm
index 5d85f60..5eae24f 100644
--- a/lib/Sbuild/ResolverBase.pm
+++ b/lib/Sbuild/ResolverBase.pm
@@ -67,6 +67,9 @@ sub new {
 '/etc/apt/sources.list.d/sbuild-build-depends-archive.list';
 $self->set('Dummy archive list file', $dummy_archive_list_file);
 
+my $dummy_archive_key_file = $session->get('Location') .
+'/etc/apt/trusted.gpg.d/sbuild-build-depends-archive.gpg';
+$self->set('Dummy archive key file', $dummy_archive_key_file);
 
 return $self;
 }
@@ -1000,6 +1003,54 @@ EOF
 }
 }
 
+# Now, we'll add in any provided OpenPGP keys into the archive, so that
+# builds can (optionally) trust an external key for the duration of the
+# build.
+if (@{$self->get_conf('EXTRA_REPOSITORY_KEYS')}) {
+my $dummy_archive_key_file = $self->get('Dummy archive key file');
+my ($tmpfh, $tmpfilename) = tempfile(DIR => $session->get('Location') . "/tmp");
+# Right, so, in order to copy the keys into the chroot (since we may have
+# a bunch of them), we'll open up a tempfile, and write *all* of the
+# given keys to the tempfile. After we're clear, we'll move that file
+# into the correct location by importing the .asc into a .gpg file.
+
+for my $repokey (@{$self->get_conf('EXTRA_REPOSITORY_KEYS')}) {
+debug("Adding archive key: $repokey\n");
+if (!-f $repokey) {
+$self->log("Failed to add archive key '${repokey}' - it doesn't exist!\n");
+$self->cleanup_apt_archive();
+return 0;
+}
+copy($repokey, $tmpfh);
+print $tmpfh "\n";
+}
+close($tmpfh);
+
+# Now that we've concat'd all the keys into the chroot, we're going
+# to use GPG to import the keys into a single keyring. We've stubbed
+# out the secret ring and home to ensure we don't store anything

Bug#796539: [buildd-tools-devel] Bug#796539: Bug#796539: Forgot the patch (thanks josch)

[Paul Tagliamonte]

Noticed some style issues -- also updated the manpage to not mention
apt-key anymore. Patch updated.
From 4b3cc9a63c89527bc7502a7576227e9fd7d187eb Mon Sep 17 00:00:00 2001
From: Paul Tagliamonte <paul...@debian.org>
Date: Wed, 2 Sep 2015 10:41:05 -0400
Subject: [PATCH] Add --extra-repository-key flag for extra apt keys

This will allow users to specify which OpenPGP key should be added
to the trusted keys inside the chroot. This is particularly useful
if the target --extra-repository is not signed with a key that's
trusted by the base chroot.
---
 lib/Sbuild/Conf.pm |  6 +
 lib/Sbuild/Options.pm  |  3 +++
 lib/Sbuild/ResolverBase.pm | 58 ++
 man/sbuild.1.in| 21 +++--
 4 files changed, 86 insertions(+), 2 deletions(-)

diff --git a/lib/Sbuild/Conf.pm b/lib/Sbuild/Conf.pm
index 763ecaa..ffce72f 100644
--- a/lib/Sbuild/Conf.pm
+++ b/lib/Sbuild/Conf.pm
@@ -1069,6 +1069,12 @@ sub setup ($) {
 	DEFAULT => [],
 	HELP => 'Additional per-build packages available as build dependencies.  Do not set by hand.'
 	},
+	'EXTRA_REPOSITORY_KEYS'=> {
+	TYPE => 'ARRAY:STRING',
+	GROUP => '__INTERNAL',
+	DEFAULT => [],
+	HELP => 'Additional per-build apt repository keys.  Do not set by hand.'
+	},
 	'EXTRA_REPOSITORIES'=> {
 	TYPE => 'ARRAY:STRING',
 	GROUP => '__INTERNAL',
diff --git a/lib/Sbuild/Options.pm b/lib/Sbuild/Options.pm
index 587acad..b47b3f5 100644
--- a/lib/Sbuild/Options.pm
+++ b/lib/Sbuild/Options.pm
@@ -313,6 +313,9 @@ sub set_options {
 			"extra-repository=s" => sub {
 			   push(@{$self->get_conf('EXTRA_REPOSITORIES')}, $_[1]);
 		   },
+			"extra-repository-key=s" => sub {
+			   push(@{$self->get_conf('EXTRA_REPOSITORY_KEYS')}, $_[1]);
+		   },
 			"build-path=s" => sub {
 			   $self->set_conf('BUILD_PATH', $_[1]);
 			},
diff --git a/lib/Sbuild/ResolverBase.pm b/lib/Sbuild/ResolverBase.pm
index 5d85f60..c171405 100644
--- a/lib/Sbuild/ResolverBase.pm
+++ b/lib/Sbuild/ResolverBase.pm
@@ -67,6 +67,9 @@ sub new {
 '/etc/apt/sources.list.d/sbuild-build-depends-archive.list';
 $self->set('Dummy archive list file', $dummy_archive_list_file);
 
+my $dummy_archive_key_file = $session->get('Location') .
+'/etc/apt/trusted.gpg.d/sbuild-build-depends-archive.gpg';
+$self->set('Dummy archive key file', $dummy_archive_key_file);
 
 return $self;
 }
@@ -1000,6 +1003,54 @@ EOF
 }
 }
 
+# Now, we'll add in any provided OpenPGP keys into the archive, so that
+# builds can (optionally) trust an external key for the duration of the
+# build.
+if (@{$self->get_conf('EXTRA_REPOSITORY_KEYS')}) {
+my $dummy_archive_key_file = $self->get('Dummy archive key file');
+my ($tmpfh, $tmpfilename) = tempfile(DIR => $session->get('Location') . "/tmp");
+# Right, so, in order to copy the keys into the chroot (since we may have
+# a bunch of them), we'll append to a tempfile, and write *all* of the
+# given keys to the same tempfile. After we're clear, we'll move that file
+# into the correct location by importing the .asc into a .gpg file.
+
+for my $repokey (@{$self->get_conf('EXTRA_REPOSITORY_KEYS')}) {
+debug("Adding archive key: $repokey\n");
+if (!-f $repokey) {
+$self->log("Failed to add archive key '${repokey}' - it doesn't exist!\n");
+$self->cleanup_apt_archive();
+return 0;
+}
+copy($repokey, $tmpfh);
+print $tmpfh "\n";
+}
+close($tmpfh);
+
+# Now that we've concat'd all the keys into the chroot, we're going
+# to use GPG to import the keys into a single keyring. We've stubbed
+# out the secret ring and home to ensure we don't store anything
+# except for the public keyring.
+
+my $tmpgpghome = tempdir('extra-repository-keys' . '-XX',
+DIR => $session->get('Location') . "/tmp");
+
+my @gpg_command = ('gpg', '--import', '--no-default-keyring',
+   '--homedir', $session->strip_chroot_path($tmpgpghome),
+   '--secret-keyring', '/dev/null',
+   '--keyring', $session->strip_chroot_path($dummy_archive_key_file),
+   $session->strip_chroot_path($tmpfilename));
+
+$session->run_command(
+{ COMMAND => \@gpg_command,
+  USER => 'root',
+  PRIORITY => 0});
+if ($?) {
+$self->log("Failed to import archive keys to the trusted keyring");
+$self->cleanup_apt_archive();
+return 0;
+}
+}
+
 # Write a list f

Bug#796539: [buildd-tools-devel] Bug#796539: Forgot the patch (thanks josch)

[Paul Tagliamonte]

On Mon, Aug 31, 2015 at 10:23:28AM +0200, Raphael Hertzog wrote:
> Hi,

Hey Raphaël! Thanks for the review, that's really awesome of you to do.
Thanks for helping review the backlog of sbuild bugs.

> On Sun, 30 Aug 2015, Paul Tagliamonte wrote:
> I note that you never remove the key at the end of the build.
> And sbuild does not always use throw-away chroots...

Yeah, I'm mirroring the behavior of the --extra-repository flag -- I
don't see any cleanup code for that, but I may have missed it. Thoughts?

> It would be nice to either fix this or document the limitation of the
> option... but your patch does not include any documentation either.

Updated to fix the manpage.

Cheers,
  Paul
From c5f43eb311449f08b2a84843f9f0c63cbde2d8fb Mon Sep 17 00:00:00 2001
From: Paul Tagliamonte <paul...@debian.org>
Date: Mon, 31 Aug 2015 11:03:57 -0400
Subject: [PATCH] Add --extra-repository-key flag for extra apt keys

This will allow users to specify which OpenPGP key should be added
to the trusted keys inside the chroot. This is particularly useful
if the target --extra-repository is not signed with a key that's
trusted by the base chroot.
---
 lib/Sbuild/Conf.pm |  6 ++
 lib/Sbuild/Options.pm  |  3 +++
 lib/Sbuild/ResolverBase.pm | 21 +
 man/sbuild.1.in| 20 ++--
 4 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/lib/Sbuild/Conf.pm b/lib/Sbuild/Conf.pm
index 763ecaa..ffce72f 100644
--- a/lib/Sbuild/Conf.pm
+++ b/lib/Sbuild/Conf.pm
@@ -1069,6 +1069,12 @@ sub setup ($) {
 	DEFAULT => [],
 	HELP => 'Additional per-build packages available as build dependencies.  Do not set by hand.'
 	},
+	'EXTRA_REPOSITORY_KEYS'=> {
+	TYPE => 'ARRAY:STRING',
+	GROUP => '__INTERNAL',
+	DEFAULT => [],
+	HELP => 'Additional per-build apt repository keys.  Do not set by hand.'
+	},
 	'EXTRA_REPOSITORIES'=> {
 	TYPE => 'ARRAY:STRING',
 	GROUP => '__INTERNAL',
diff --git a/lib/Sbuild/Options.pm b/lib/Sbuild/Options.pm
index 587acad..b47b3f5 100644
--- a/lib/Sbuild/Options.pm
+++ b/lib/Sbuild/Options.pm
@@ -313,6 +313,9 @@ sub set_options {
 			"extra-repository=s" => sub {
 			   push(@{$self->get_conf('EXTRA_REPOSITORIES')}, $_[1]);
 		   },
+			"extra-repository-key=s" => sub {
+			   push(@{$self->get_conf('EXTRA_REPOSITORY_KEYS')}, $_[1]);
+		   },
 			"build-path=s" => sub {
 			   $self->set_conf('BUILD_PATH', $_[1]);
 			},
diff --git a/lib/Sbuild/ResolverBase.pm b/lib/Sbuild/ResolverBase.pm
index 5d85f60..07b92eb 100644
--- a/lib/Sbuild/ResolverBase.pm
+++ b/lib/Sbuild/ResolverBase.pm
@@ -1000,6 +1000,27 @@ EOF
 }
 }
 
+for my $repokey (@{$self->get_conf('EXTRA_REPOSITORY_KEYS')}) {
+debug("Adding apt-key: $repokey\n");
+if (!-f $repokey) {
+$self->log("Failed to add apt-key '${repokey}' - it doesn't exist!\n");
+$self->cleanup_apt_archive();
+return 0;
+}
+my ($tmpfh, $tmpfilename) = tempfile(DIR => $session->get('Location') . "/tmp");
+copy($repokey, $tmpfh);
+close($tmpfh);
+$session->run_command(
+{ COMMAND => ['apt-key', 'add', $session->strip_chroot_path($tmpfilename)],
+  USER => 'root',
+  PRIORITY => 0});
+if ($?) {
+$self->log("Failed to add external apt key.\n");
+$self->cleanup_apt_archive();
+return 0;
+}
+}
+
 # Write a list file for the dummy archive if one not create yet.
 if (! -f $dummy_archive_list_file) {
 my ($tmpfh, $tmpfilename) = tempfile(DIR => $session->get('Location') . "/tmp");
diff --git a/man/sbuild.1.in b/man/sbuild.1.in
index e5d1e4a..39cae07 100644
--- a/man/sbuild.1.in
+++ b/man/sbuild.1.in
@@ -80,6 +80,7 @@ sbuild \- build debian packages from source
 .RB [ \-\-resolve\-alternatives \[or] \-\-no\-resolve\-alternatives ]
 .RB [ \-\-extra\-package=\fIpackage.deb\fP ]
 .RB [ \-\-extra\-repository=\fIspec\fP ]
+.RB [ \-\-extra\-repository\-key=\fIfile.asc\fP ]
 .RB [ \-\-build\-path=\fIstring\fP ]
 .RB [ PACKAGE [ .dsc ]]
 .SH DESCRIPTION
@@ -450,8 +451,23 @@ file. For instance, you might use
 .hy
 to allow packages in the experimental distribution to fulfill
 build-dependencies. Note that the build chroot must already trust the
-key of this repository (see
-.BR apt-secure (8)).
+key of this repository or a key must be given with the
+.nh
+.B \-\-extra\-repository-key
+.hy
+flag. (see
+.BR apt-secure (8))
+.TP
+.BR \-\-extra\-repository-key=\fIfile.asc\fP
+Add \fIfile.asc\fP to the list of trusted keys inside the chroot. The key is
+read from the filename given, and added using
+.BR apt-key (8).
+This flag is particularly useful if the target in
+.nh
+.B --extra-repository
+.hy

Bug#797452: Support TLS Client Certificiates + HTTPS upload

[Paul Tagliamonte]

Package:dput-ng
Severity: wishlist
thanks

It'd be great to support TLS Client Certs, doubly so as we start to
support DD sso certs.

We already support TLS, but we need to support a custom CA to verify the
server cert, and define client cert(s) to use.

urllib2 sucks for this, perhaps time to switch to use requests for the
http uploader


Paul


signature.asc
Description: Digital signature

Bug#796539: Forgot the patch (thanks josch)

[Paul Tagliamonte]

Attached
From f84255ee696a393e2a9dc576fc0d39d5199eb6c0 Mon Sep 17 00:00:00 2001
From: Paul Tagliamonte paul...@debian.org
Date: Sat, 22 Aug 2015 12:07:15 +0200
Subject: [PATCH] Add --extra-repository-key flag for extra apt keys

This will allow users to specify which OpenPGP key should be added
to the trusted keys inside the chroot. This is particularly useful
if the target --extra-repository is not signed with a key that's
trusted by the base chroot.
---
 lib/Sbuild/Conf.pm |  6 ++
 lib/Sbuild/Options.pm  |  3 +++
 lib/Sbuild/ResolverBase.pm | 21 +
 3 files changed, 30 insertions(+)

diff --git a/lib/Sbuild/Conf.pm b/lib/Sbuild/Conf.pm
index af89f60..d5b9ca3 100644
--- a/lib/Sbuild/Conf.pm
+++ b/lib/Sbuild/Conf.pm
@@ -1061,6 +1061,12 @@ sub setup ($) {
 	DEFAULT = [],
 	HELP = 'Additional per-build packages available as build dependencies.  Do not set by hand.'
 	},
+	'EXTRA_REPOSITORY_KEYS'= {
+	TYPE = 'ARRAY:STRING',
+	GROUP = '__INTERNAL',
+	DEFAULT = [],
+	HELP = 'Additional per-build apt repository keys.  Do not set by hand.'
+	},
 	'EXTRA_REPOSITORIES'= {
 	TYPE = 'ARRAY:STRING',
 	GROUP = '__INTERNAL',
diff --git a/lib/Sbuild/Options.pm b/lib/Sbuild/Options.pm
index c9fe01f..940aad1 100644
--- a/lib/Sbuild/Options.pm
+++ b/lib/Sbuild/Options.pm
@@ -313,6 +313,9 @@ sub set_options {
 			extra-repository=s = sub {
 			   push(@{$self-get_conf('EXTRA_REPOSITORIES')}, $_[1]);
 		   },
+			extra-repository-key=s = sub {
+			   push(@{$self-get_conf('EXTRA_REPOSITORY_KEYS')}, $_[1]);
+		   },
 	);
 }
 
diff --git a/lib/Sbuild/ResolverBase.pm b/lib/Sbuild/ResolverBase.pm
index ae1bfcf..fa0316a 100644
--- a/lib/Sbuild/ResolverBase.pm
+++ b/lib/Sbuild/ResolverBase.pm
@@ -1010,6 +1010,27 @@ EOF
 }
 }
 
+for my $repokey (@{$self-get_conf('EXTRA_REPOSITORY_KEYS')}) {
+debug(Adding apt-key: $repokey\n);
+if (!-f $repokey) {
+$self-log(Failed to add apt-key '${repokey}' - it doesn't exist!\n);
+$self-cleanup_apt_archive();
+return 0;
+}
+my ($tmpfh, $tmpfilename) = tempfile(DIR = $session-get('Location') . /tmp);
+copy($repokey, $tmpfh);
+close($tmpfh);
+$session-run_command(
+{ COMMAND = ['apt-key', 'add', $session-strip_chroot_path($tmpfilename)],
+  USER = 'root',
+  PRIORITY = 0});
+if ($?) {
+$self-log(Failed to add external apt key.\n);
+$self-cleanup_apt_archive();
+return 0;
+}
+}
+
 # Write a list file for the dummy archive if one not create yet.
 if (! -f $dummy_archive_list_file) {
 my ($tmpfh, $tmpfilename) = tempfile(DIR = $session-get('Location') . /tmp);
-- 
2.5.0



signature.asc
Description: Digital signature

Bug#797021: ITP: midicsv -- translate MIDI file to CSV

[Paul Tagliamonte]

On Sat, Aug 29, 2015 at 11:24:12PM +0200, Santiago Vila wrote:
 Everything boils down to an ITP bug?

In the case of a dispite, well, yeah, that's clearly why they exist.

 I think this clearly shows my intent to package it:

Sure, *your* intent, but that's not you getting the global mutex. If I
want to package something, I'll search for a RFP or ITP, and use that.
If I don't see anything, I put it in NEW.

 https://people.debian.org/~sanvila/wip/

... I surely don't look at every DD's people.d.o for a .dsc 

When two threads do work without both checking the mutex, you end up with
a race condition when both try to write data back out.

Live and learn. This is literally why ITPs exist.


Frankly, you're assuming malice. That's out of line, Why not be friendly
and create something positive out of this.

  Paul


signature.asc
Description: Digital signature

Bug#797021: ITP: midicsv -- translate MIDI file to CSV

[Paul Tagliamonte]

On Sun, Aug 30, 2015 at 01:07:15AM +0200, Santiago Vila wrote:
 On Sat, Aug 29, 2015 at 03:28:44PM -0700, Kamal Mostafa wrote:
  Santiago, it is disappointing that you'd jump to the (wholly incorrect)
  conclusion that I had somehow hijacked your package or your work.  Its
  just a coincidence that we both happened to package this on the same day
  (but I followed proper ITP upload procedures, whereas you didn't).
 
 It was not really my package or my work. Before your ITP, my plan
 was to file a RFP with Víctor as the owner. He asked me in Debconf for

FWIW, an RFP isn't right either. That's a request for packaging. Kamal
would have just turned it into an ITP and set himself as the owner.

You should have filed an *ITP* with your mentee.

I suggest you do a WNPP touch-up and re-read the devref.

 something to work, and I suggested this package which I had in a
 private repo for years.
 
 But if the package is not going to be maintained by him because I
 didn't file an ITP in time, so be it.
 
 Thanks.

There's no reason you can't work together. Why not try to be helpful and
work together? Three is better than two or one.

Cheers,
  Paul


signature.asc
Description: Digital signature

Bug#797021: ITP: midicsv -- translate MIDI file to CSV

[Paul Tagliamonte]

On Sun, Aug 30, 2015 at 01:45:32AM +0200, Santiago Vila wrote:
 I'm confused now.
 
 Please note that I said with Víctor as the owner.
 
 Do you mean that the owner of a bug report is not a mutex,
 much like the person filing the ITP?

Owning a RFP basically means nothing. It might be weird enough to
someone looking at it that they'd ask, but here's a workflow (again, I
invite you to re-read the devref)

RFPs, when they get an owner are turned into an ITP, since you're no
longer requesting someone package it, but rather, intend to actually
upload it.

If someone sees an RFP, the idea is they retitle to an ITP and set
owner. I'd likely do it without reading the RFP, so I'd miss any
owner.

If you stall on the ITP, it's polite to turn the ITP (back?) into an
RFP.

 Until now I believed that the following two bugs were equivalent:
 
 From: A
 Subject: RFP: foo
 Owner: B
 
 From: B
 Subject: ITP: foo

Yay! So, they're not. So, misconception corrected! If you intend to
upload, you should, well, show that with the bug. By making it an intent
to upload bug. Since you intend to upload. It's not a request anymore.

 but now you say that anybody can change the owner in the first report.

I likely would without checking, but someone more careful might check,
say Hunh, that's weird and email.

 If that's the case, what do we have this Owner thing for, then?

It's a general feature of the BTS. Owner has meaning for ITPs, but RFPs,
that's weird. You can't really own the request like someone owns the
intent.

 (Speaking about the BTS in general, not about ITPs in particular).
 
 Thanks.

Cheers,
  Paul


signature.asc
Description: Digital signature

Bug#796539: [PATCH] Add --extra-repository-key flag for extra apt keys

[Paul Tagliamonte]

Package: sbuild
Severity: wishlist
Tags: patch
kthanksbye

This will allow users to specify which OpenPGP key should be added
to the trusted keys inside the chroot. This is particularly useful
if the target --extra-repository is not signed with a key that's
trusted by the base chroot.

Thanks,
  Paul

-- 
 .''`.   Paul Tagliamonte paul...@debian.org|   Proud Debian Developer
: :'  :  https://people.debian.org/~paultag   |   https://pault.ag/
`. `'`   Debian - the Universal Operating System
 `-4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87


signature.asc
Description: Digital signature

Bug#786302: NMU Uploaded

[Paul Tagliamonte]

Attached is the debdiff i've uploaded to DELAYED/2

This changeset removes python-support, and switches to dh-python

Thanks for your work!
  Paul

-- 
 .''`.   Paul Tagliamonte paul...@debian.org|   Proud Debian Developer
: :'  :  https://people.debian.org/~paultag   |   https://pault.ag/
`. `'`   Debian - the Universal Operating System
 `-4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
diff -u yagtd-0.3.4/debian/changelog yagtd-0.3.4/debian/changelog
--- yagtd-0.3.4/debian/changelog
+++ yagtd-0.3.4/debian/changelog
@@ -1,3 +1,10 @@
+yagtd (0.3.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove dependency on python-support (Closes: #786302).
+
+ -- Paul Tagliamonte paul...@debian.org  Tue, 18 Aug 2015 16:54:30 +0200
+
 yagtd (0.3.4-1) unstable; urgency=low
 
   * New upstream release
diff -u yagtd-0.3.4/debian/rules yagtd-0.3.4/debian/rules
--- yagtd-0.3.4/debian/rules
+++ yagtd-0.3.4/debian/rules
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 %:
-	dh $@
+	dh $@ --with=python2 --buildsystem=pybuild
 
 override_dh_install:
 	dh_install
diff -u yagtd-0.3.4/debian/control yagtd-0.3.4/debian/control
--- yagtd-0.3.4/debian/control
+++ yagtd-0.3.4/debian/control
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Max Vozeler x...@debian.org
-Build-Depends: debhelper (= 7.0.50~), python (= 2.3), python-support
+Build-Depends: debhelper (= 7.0.50~), python (= 2.3), dh-python
 Standards-Version: 3.9.1
 Homepage: https://gna.org/projects/yagtd/
 


signature.asc
Description: Digital signature

Bug#793732: ITP: golang-golang-x-crypto -- supplementary cryptography libraries for Go

[Paul Tagliamonte]

Package: wnpp
Severity: wishlist
Owner: Paul Tagliamonte paul...@debian.org

* Package name: golang-golang-x-crypto
  Version : 0.0~git20150716.0.7d5b0be-1
  Upstream Author : The Go Authors
* URL : https://godoc.org/golang.org/x/crypto
* License : BSD-3
  Programming Lang: Go
  Description : supplementary cryptography libraries for Go

 This package contains support for additional cryptography routines for
 Go that are not present in the standard Go library.
 .
  - bcrypt
  - blowfish
  - bn256
  - cast5
  - curve25519
  - hkdf
  - md4
  - nacl (nacl/box, nacl/secretbox)
  - ocsp
  - openpgp (openpgp/armor, openpgp/clearsign, openpgp/elgamal, openpgp/errors,
 openpgp/packet, openpgp/s2k)
  - otr
  - pbkdf2
  - poly1305
  - ripemd160
  - salsa20 (salsa20/salsa)
  - scrypt
  - sha3
  - ssh (ssh/agent, ssh/terminal, ssh/test)
  - twofish
  - xtea
  - xts


signature.asc
Description: Digital signature