Bug#901963: [pkg-go] Bug#901963: git-lfs: "git lfs help" doesn't work

[Stephen Gelman]

I confirmed that this is a bug with the debian package (also exists in 
upstream’s debian package).  “git lfs help” should work and does with 
upstream’s binaries.  A bug happened to have been recently filed upstream at 
https://github.com/git-lfs/git-lfs/issues/3043 
.  I am investigating this.

Stephen

> On Jun 20, 2018, at 2:25 PM, Kenyon Ralph  wrote:
> 
> Package: git-lfs
> Version: 2.4.2-1~bpo9+1
> Severity: minor
> 
> Dear Maintainer,
> 
> git lfs help doesn't work. It just says 'Sorry, no usage text found
> for "git-lfs"', either when doing "git lfs help" or when doing "git
> lfs help ", such as "git lfs help track".
> 
> Probably the right thing to do would be show the manual pages (which
> are indeed installed and usable), just like "git help" does, e.g.,
> "git lfs help" runs "man git-lfs", "git lfs help track" runs "man
> git-lfs-track", etc.
> 
> -- System Information:
> Debian Release: 9.4
>  APT prefers stable-updates
>  APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.16.0-0.bpo.1-amd64 (SMP w/24 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages git-lfs depends on:
> ii  git1:2.17.1-1~bpo9+1
> ii  libc6  2.24-11+deb9u3
> 
> git-lfs recommends no packages.
> 
> git-lfs suggests no packages.
> 
> -- no debconf information
> 
> 

Bug#980179: ITP: kubecolor -- colorizes kubectl output

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: kubecolor
  Version : 0.0.9-1
  Upstream Author : Hidetatsu Yaginuma
* URL : https://github.com/dty1er/kubecolor
* License : Expat
  Programming Lang: Go
  Description : colorizes kubectl output

 kubecolor is a wrapper for the kubernetes kubectl command that colorizes its
 output

This package will be group maintained by the golang team

Bug#906518: qa.debian.org: Missing manpages webpage links to seemingly dead project

[Stephen Gelman]

Package: qa.debian.org
Severity: normal

It seems that the "Missing Man Pages Project" [1] linked to from the missing 
manpages qa page [2] is no longer an active project.  The project page linked 
is gone (and seems to have been gone since 2013 at least) and I can't seem to 
find any replacement for it.  Therefore, it seems that the link, along with the 
suggestion to submit man pages to it, should be removed.

[1] http://www.netmeister.org/misc/m2p2/index.html
[2] http://qa.debian.org/man-pages.html

--
Stephen

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

Kernel: Linux 4.17.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#906524: man page for muttdown

[Stephen Gelman]

Package: muttdown
Severity: wishlist
Tags: patch

Hi,

I wrote a man page for muttdown as it was missing one.  It is attached
 Please consider adding it the package!  I am also submitting the man
page upstream in case they are interested in adding it.

--
Stephen


muttdown.1
Description: Binary data

Bug#906524:

[Stephen Gelman]

Submitted upstream at https://github.com/Roguelazer/muttdown/pull/10

Bug#905281: Patch to fix FTBFS

[Stephen Gelman]

Control: tags 905281 + patch

Here is a patch to fix the FTBFS.  Looks like this was added in 
https://salsa.debian.org/debian/dracut/commit/9f9ec325b9d2960cb1efc92335ad941a2addd141,
 however it causes the package to FTBFS and seems unnecessary since the file 
still ends up in the package even with this patch:

$ dpkg -c dracut-core_047+31-2_amd64.deb | grep README.Debian
-rw-r--r-- root/root  1453 2018-08-18 21:48 
./usr/share/doc/dracut-core/README.Debian

diff -Nru dracut-047+31/debian/dracut-core.docs 
dracut-047+31/debian/dracut-core.docs
--- dracut-047+31/debian/dracut-core.docs 2018-05-22 14:24:45.0 +
+++ dracut-047+31/debian/dracut-core.docs 2018-08-18 21:48:37.0 +
@@ -2,7 +2,6 @@
 HACKING
 NEWS
 README
-README.Debian
 README.generic
 README.kernel
 README.modules

— 
Stephen

Bug#874751: blktap-dkms: module FTBFS for Linux 4.12

[Stephen Gelman]

I took a stab at creating a patch to get this to build on a 4.17 kernel.  It 
builds, but when I tried to actually use it, it caused a kernel panic.  (FYI I 
used the instructions at 
https://wiki.xenproject.org/wiki/Mounting_a_.vhd_disk_image_using_blktap/tapdisk
 to attempt to mount the disk).  I’m a little out of my depth debugging this 
one so I wanted to submit the patch I have in case anyone else can benefit from 
it.

Having said that I’m not sure this package should even stay in Debian.  Popcon 
reports 55 installs and I can’t even find the upstream sources.  The closest I 
can find is https://github.com/xapi-project/blktap/tree/master/drivers but that 
doesn’t actually have a version 2.0.93…  Also, the last maintainer upload was 
in 2013 and the package has had 10 consecutive NMUs.  Some brief searching 
indicates that this may now be part of Xen itself anyway…




blktap-compile-on-4.17.patch
Description: Binary data

Bug#903058: [pkg-go] Bug#903058: git-lfs FTBFS: update Build-Depends: ruby-ronn -> ronn

[Stephen Gelman]

Helmut,

Thanks so much for the heads up.  I’ll fix that now!

Stephen

> On Jul 5, 2018, at 1:18 PM, Helmut Grohne  wrote:
> 
> Source: git-lfs
> Version: 2.4.2-1
> Severity: serious
> 
> Since ronn got split out of ruby-ronn, git-lfs fails to build from
> source. It was not possible to have ruby-ronn temporarily depend on
> ronn, because that would have created a dependency cycle. Please update
> Build-Depends and replace ruby-ronn with ronn as git-lfs uses the
> command line tool.
> 
> Helmut
> 
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#810890: caddy in Debian, git repo at Salsa

[Stephen Gelman]

Geert,

You should be able to create the repos with “dh-make-golang 
create-salsa-project”

Stephen

> On Dec 20, 2020, at 8:48 PM, Geert Stappers  wrote:
> 
> On Sun, 25 Dec 2016 15:41:37 +0100 Andrew Shadura  wrote:
>> (I have done base for cloudflare package but didn't check any new
>> version in some time nor did I track if there is any other dependency
>> packaged and they were quite a bit of them). I can send you the
>> cloudflare work if you're interested in it or wait for me to finish
>> it.
>> 
>> 
>> I think it'd be great if you uploaded what you've done somewhere. Or
>> at least mailed me a tarball :)
> 
> 
> Hello Debian Go  People,
> Hello Debian Go  People with create privilege at Salsa,
> 
> 
> Please create git repo 
> https://salsa.debian.org/go-team/packages/golang-github-caddyserver
> in addition to 
> https://salsa.debian.org/go-team/packages/golang-github-caddyserver-certmagic
> 
> It is for packaging Caddy.
> ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810890 )
> 
> 
> Thanks
> 
> Geert Stappers
> 
> 
> P.S.
> The extra copy of this you might got, is due Bcc



signature.asc
Description: Message signed with OpenPGP

Bug#940485: git-lfs: FTBFS: tests fail

[Stephen Gelman]

Ah good catch, thanks for that!

On Mon, Jan 13, 2020 at 5:45 PM Andreas Beckmann  wrote:
>
> Followup-For: Bug #940485
> Control: tag -1 pending
>
> buster-pu request: https://bugs.debian.org/948854
>
>
> Andreas
>

Bug#992836: bullseye-pu: package termshark/2.2.0-1+deb11u1

[Stephen Gelman]

On Sep 4, 2021 at 10:10:55 AM, Adam D. Barratt 
wrote:

> Control: tags -1 + confirmed
>
> On Mon, 2021-08-23 at 23:16 -0500, Stephen Gelman wrote:
>
> Themes were inadvertently not built into the termshark package,
>
> causing the UI to fail to render. This was reported upstream at
>
> https://github.com/gcla/termshark/issues/114, then reported to Debian
>
> in #992831. This is a regression, and also makes the package
>
> generally unusable.
>
>
>
> Please go ahead.
>
> Regards,
>
> Adam
>

Uploaded. Thanks!

Stephen

Bug#993498: Checkinstall should use dpkg-shlibdeps

[Stephen Gelman]

 I will look into adding this, but due to the way checkinstall manually
creates debs, dpkg-shlibdeps doesn’t like its control file so there is
likely some extra work that would need to be done.

Stephen

On Sep 2, 2021 at 3:55:39 AM, chrysn  wrote:

> Package: checkinstall
> Version: 1.6.2+git20170426.d24a630-2
> Severity: wishlist
> Tags: upstream
>
> When creating a deb on Debian using checkinstall (eg. to get a working
> distributable version of software whose build dependencies are so
> compilcated[1] it stands little chances in regular packaging), several
> dependencies could be detected automatically using shlibdeps, as is done
> eg. by debhelper dh_shlibdeps. When binaries are installed, that would
> detect the necessary libc versions as well as any other shared libraries
> the installed binaries depend on.
>
> The correct dependency information would help both cleaning up the local
> system (otherwise uninstalling the -dev packages might autoremove also
> the libraries that are now depended on) and using it on a different
> system (where now one has to read linker errors and add files on demand).
>
> [1]: https://github.com/immunant/c2rust/issues/326
>
>
> Minimal test case:
>
> $ fakeroot checkinstall --pkgname test --default --install=no -- cp -a
> /usr/bin/ssh /bin
> $ dpkg-deb --info test_20??-1_*.deb | grep Depends
> (no results)
>
> If shlibdeps were extracted, it should print at least something about
> libc.
>
> A minimal working example of how to arrive at the relevant shlibdeps is:
>
> $ mkdir debian
> $ touch debian/control
> $ dpkg-shlibdeps /usr/bin/ssh
> $ cat debian/substvars
> shlibs:Depends=libc6 (>= 2.26), libgssapi-krb5-2 (>= 1.17), libselinux1
> (>= 3.1~), libssl1.1 (>= 1.1.0), zlib1g (>= 1:1.1.4)
>
>
> -- System Information:
> Debian Release: bookworm/sid
>  APT prefers unstable
>  APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.13.0 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages checkinstall depends on:
> ii  dpkg-dev1.20.9
> ii  file1:5.39-3
> ii  libc6   2.31-17
> ii  sensible-utils  0.0.17
>
> Versions of packages checkinstall recommends:
> ii  make  4.3-4.1
>
> Versions of packages checkinstall suggests:
> ii  gettext  0.21-4
>
> -- no debconf information
>

Bug#991193: ITP: opentracing-cpp -- OpenTracing API for C++

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 
X-Debbugs-Cc: debian-de...@lists.debian.org, ssg...@debian.org

* Package name: opentracing-cpp
  Version : 1.6.0
  Upstream Author : The OpenTracing Authors
* URL : https://github.com/opentracing/opentracing-cpp/
* License : Apache-2.0
  Programming Lang: C++
  Description : OpenTracing API for C++

C++ implementation of the OpenTracing API. See http://opentracing.io for 
additional information.

This is being packaged as part of an effort to add opentracing support
to haproxy.

Bug#991194: ITP: opentracing-c-wrapper -- C wrapper for the C++ impl of the OpenTracing API

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 
X-Debbugs-Cc: debian-de...@lists.debian.org, ssg...@debian.org

* Package name: opentracing-c-wrapper
  Version : 1.1.0
  Upstream Author : HAProxy Technologies
* URL : https://github.com/haproxytech/opentracing-c-wrapper/
* License : Apache-2.0
  Programming Lang: C/C++
  Description : C wrapper for the C++ impl of the OpenTracing API

OpenTracing C Wrapper library was created due to the need to use distributed
tracing within C programs.

The OpenTracing project (https://opentracing.io/) has published a
C-language implementation on https://github.com/opentracing/opentracing-c
but that implementation is incomplete, with the last update on Jun
27th 2018

This library takes inspiration from the header files in that project but
implements the proposed functionality fully by wrapping the functional
C++ library.

This is a dependency of building haproxy with opentracing support.

Bug#991671: ITP: dd-opentracing-cpp -- Datadog OpenTracing C++ Client

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 
X-Debbugs-Cc: debian-de...@lists.debian.org, ssg...@debian.org

* Package name: dd-opentracing-cpp
  Version : 1.3.0
  Upstream Author : Datadog
* URL : https://github.com/DataDog/dd-opentracing-cpp
* License : Apache-2.0
  Programming Lang: C++
  Description : Datadog OpenTracing C++ Client

An OpenTracing client to collect OpenTracing data in a format that can be
parsed locally by Datadog's agent. This is used as a plugin in conjunction
with lib-opentracing1 in applications that support OpenTracing.

I plan on maintaining this myself.

Bug#992831: termshark: missing DH_GOLANG_INSTALL_EXTRA for termshark themes

[Stephen Gelman]

 Ah great catch! Sorry to have caused you extra troubleshooting effort.
I’ll upload the fix to unstable asap, upload it to bullseye-backports once
it reaches testing in a few days, then I’ll work to get it into the next
bullseye release!

Stephen

On Aug 23, 2021 at 9:21:38 PM, Graham Clark  wrote:

> Package: termshark
> Version: 2.2.0-1+b5
> Severity: important
> X-Debbugs-Cc: grcl...@gmail.com
>
> Dear Maintainer,
>
> There is an open issue against termshark on github that I believe is
> down to a small packaging omission on Debian. Here's a link to the
> bug: https://github.com/gcla/termshark/issues/114
>
> The symptom reported by users is that when termshark starts, most or
> all of the terminal is black and no information is visible. Termshark
> 2.2 can be "themed" and should have compiled-in to the binary a
> default set of themes. If no user-theme is provided, termshark loads
> the built-in default. Due to a small omission in the debian packaging
> rules for termshark, the default themes are not made available at
> compile-time and so termshark is unable to resolve many theme
> settings. Since this is not expected to fail, the defaults are
> unhelpful and result in large areas of the terminal screen showing up
> blank.
>
> I believe this problem can be fixed by adding this line to
> debian/rules:
>
> export DH_GOLANG_INSTALL_EXTRA := assets/themes
>
> Thanks!
> Graham
>
> -- System Information:
> Debian Release: 11.0
>  APT prefers testing
>  APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.8.0-59-generic (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /bin/dash
> Init: unable to detect
>
> Versions of packages termshark depends on:
> ii  libc6 2.31-13
> ii  tshark3.4.7-1
> ii  wireshark-common  3.4.7-1
>
> termshark recommends no packages.
>
> termshark suggests no packages.
>
> -- no debconf information
>
>

Bug#992836: bullseye-pu: package termshark/2.2.0-1+deb11u1

[Stephen Gelman]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ssg...@debian.org

[ Reason ]
Themes were inadvertently not built into the termshark package, causing
the UI to fail to render. This was reported upstream at
https://github.com/gcla/termshark/issues/114, then reported to Debian in
#992831. This is a regression, and also makes the package generally
unusable.

[ Impact ]
If this update isn't approved the user will have to follow the
workaround provided by the author at
https://github.com/gcla/termshark/issues/114#issuecomment-904273172
While not a deal-breaker it requires a non-zero amount of effort by the
end user.

[ Tests ]
Due to the nature of the bug (display issue) it is hard to test using
automated tests (which, of course, is how it was missed). Realistically
the best way to test it is by running the termshark command after
installing the package.

[ Risks ]
The only change is to the build flags, so I feel the risk is low.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
The only change is including the "assets/themes" directory in the build
process.

[ Other info ]
This is fixed in 2.2.0-2 which has been uploaded to unstable.
diff -Nru termshark-2.2.0/debian/changelog termshark-2.2.0/debian/changelog
--- termshark-2.2.0/debian/changelog2021-01-10 03:44:34.0 -0600
+++ termshark-2.2.0/debian/changelog2021-08-23 22:55:12.0 -0500
@@ -1,3 +1,10 @@
+termshark (2.2.0-1+deb11u1) bullseye; urgency=medium
+
+  * Team upload
+  * Include themes in package (Closes: #992831)
+
+ -- Stephen Gelman   Mon, 23 Aug 2021 22:55:12 -0500
+
 termshark (2.2.0-1) unstable; urgency=medium
 
   * Team upload
diff -Nru termshark-2.2.0/debian/rules termshark-2.2.0/debian/rules
--- termshark-2.2.0/debian/rules2021-01-10 03:44:34.0 -0600
+++ termshark-2.2.0/debian/rules2021-08-23 22:54:41.0 -0500
@@ -1,6 +1,7 @@
 #!/usr/bin/make -f
 
 export DH_GOLANG_GO_GENERATE := 1
+export DH_GOLANG_INSTALL_EXTRA := assets/themes
 
 include /usr/share/dpkg/pkg-info.mk
 

Bug#992836: bullseye-pu: package termshark/2.2.0-1+deb11u1

[Stephen Gelman]

 Also, given that this package is currently unusable it would be nice to
include this in bullseye-updates.

On Aug 23, 2021 at 11:16:03 PM, Stephen Gelman  wrote:

> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: ssg...@debian.org
>
> [ Reason ]
> Themes were inadvertently not built into the termshark package, causing
> the UI to fail to render. This was reported upstream at
> https://github.com/gcla/termshark/issues/114, then reported to Debian in
> #992831. This is a regression, and also makes the package generally
> unusable.
>
> [ Impact ]
> If this update isn't approved the user will have to follow the
> workaround provided by the author at
> https://github.com/gcla/termshark/issues/114#issuecomment-904273172
> While not a deal-breaker it requires a non-zero amount of effort by the
> end user.
>
> [ Tests ]
> Due to the nature of the bug (display issue) it is hard to test using
> automated tests (which, of course, is how it was missed). Realistically
> the best way to test it is by running the termshark command after
> installing the package.
>
> [ Risks ]
> The only change is to the build flags, so I feel the risk is low.
>
> [ Checklist ]
>  [x] *all* changes are documented in the d/changelog
>  [x] I reviewed all changes and I approve them
>  [x] attach debdiff against the package in stable
>  [x] the issue is verified as fixed in unstable
>
> [ Changes ]
> The only change is including the "assets/themes" directory in the build
> process.
>
> [ Other info ]
> This is fixed in 2.2.0-2 which has been uploaded to unstable.
>

Bug#934194: iwd: Missing directory prevents starting on initial install

[Stephen Gelman]

Package: iwd
Version: 0.19-1
Severity: important

Upon initial install iwd fails to start.  The (somewhat cryptic) error
from systemd is:

Aug 07 20:26:00 host systemd[19298]: iwd.service: Failed to set up mount 
namespacing: No such file or directory
Aug 07 20:26:00 host systemd[19298]: iwd.service: Failed at step NAMESPACE 
spawning /usr/libexec/iwd: No such file or directory

Upon a little investigation I realized that the missing directory is 
/var/lib/iwd.  Creating that directory allows the service to start.  Seems that 
the package should probably create that directory.

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages iwd depends on:
ii  libc6 2.28-10
ii  libreadline8  8.0-2

iwd recommends no packages.

iwd suggests no packages.

-- no debconf information

Bug#921156: etcd: CVE-2018-1098 CVE-2018-1099

[Stephen Gelman]

On Tue, 12 Feb 2019 09:32:48 +0700 Arnaud Rebillout
 wrote:
> I looked into this a bit yesterday.
>
> As mentioned in the issue upstream at
> https://github.com/etcd-io/etcd/issues/9353, the fix has been merged in
> the master branch of etcd in March 2018, almost a year ago. The
> conversation also mentions that this will be part of the next release
> v3.4. However v3.4 has not been released yet.
>
> And I don't think we want to package a random commit from the master
> branch of etcd. So if we want to solve this bug simply by updating the
> package, we'll have to wait for v3.4 to be released.
>
> The other alternative is to cherry-pick the patch.
>
> If I'm not mistaken, the fix can be found in this MR:
> https://github.com/etcd-io/etcd/pull/9372/files. It's not a trivial
> patch. It's unlikely that we can apply it without modification on the
> etcd currently packaged in debian.
>
> I personally can't do that, as I know nothing about etcd anyway. I don't
> know if someone feels up to the task, or have a better idea about how to
> solve that.
>
> Cheers,
>
>   Arnaud

Since upstream still hasn't released a version that fixes the CVE is
this still considered a RC bug?  Obviously it's better to fix it asap
but if upstream doesn't consider it critical I'm not sure this should
be RC.

Stephen

Bug#878487: checkinstall bug

[Stephen Gelman]

Thanks for reporting this and providing a patch!  I just uploaded checkinstall 
1.6.2-5 which includes your patch.  Unfortunately this didn’t make it into 
buster but once this fixed version migrates to testing I will upload it to 
buster-backports.

Thanks!

Stephen

Bug#785441: Support maintainer name and email address

[Stephen Gelman]

tags 785441 -patch
thanks
--

Viktor,

This seems like a reasonable idea, however I do not see a patch attached to the 
bug.  If you have one could you please send it?

Thanks!

Stephen

Bug#754498: checkinstall: module packaging includes unwanted files

[Stephen Gelman]

Hi Guillaume,

Sorry for the reply that is 5 years too late!  Responses inline:

On Fri, 11 Jul 2014 21:10:56 +0200 Guillaume Millet  wrote:
> Using checkinstall to create a Debian package that installs a kernel module
> adds three undesired files.
> 
> $ sudo checkinstall
> 
> The package created contained three unwanted files:
> /lib/modules/$(uname -r)/modules.softdep
> /lib/modules/$(uname -r)/modules.builtin.bin
> /lib/modules/$(uname -r)/modules.devname
> 
> As a workaround, I removed those files with the exclude option.

I’m not quite sure that this is a mistake.  I believe those files are, in fact, 
touched by installing a module.  Therefore, I think your workaround is the 
correct way to handle it.  If this answers your question please let me know and 
I will close this bug, otherwise definitely let me know if you disagree!

Thanks,

Stephen

Bug#754498: checkinstall: module packaging includes unwanted files

[Stephen Gelman]

Hi Guillaume,

Sorry for the reply that is 5 years too late!  Responses inline:

On Fri, 11 Jul 2014 21:10:56 +0200 Guillaume Millet  wrote:
> Using checkinstall to create a Debian package that installs a kernel module
> adds three undesired files.
> 
> $ sudo checkinstall
> 
> The package created contained three unwanted files:
> /lib/modules/$(uname -r)/modules.softdep
> /lib/modules/$(uname -r)/modules.builtin.bin
> /lib/modules/$(uname -r)/modules.devname
> 
> As a workaround, I removed those files with the exclude option.

I’m not quite sure that this is a mistake.  I believe those files are, in fact, 
touched by installing a module.  Therefore, I think your workaround is the 
correct way to handle it.  If this answers your question please let me know and 
I will close this bug, otherwise definitely let me know if you disagree!

Thanks,

Stephen

Bug#785441: Support maintainer name and email address

[Stephen Gelman]

On Oct 10, 2019, at 9:02 PM, Matthew Gabeler-Lee  wrote:
> 
> I think the patch _was_ the original bug report, specifically this:
> 
> MAINTAINER="`eval "echo '$1'"`"
> 
> As compared to what the checkinstall code does now:
> 
> MAINTAINER=`eval echo $1`
> 
> The suggested extra layer of quoting will help with many issues around the
> standard maintainer name format, I think. If you have single quotes in the
> argument values it will still have problems, but it's at least better than
> the current state of affairs.
> 
> It's unclear to me why this extra layer of indirection is happening at all,
> though, and why it can't just do:
> 
> MAINTAINER="$1"
> 
> I can only imagine that there's some desire to let you indirectly reference
> variables set by earlier arguments, but I have also seen anti-patterns like
> this before from folks that just have a brain fart and forget how bash
> works.
> 
> // extra frustration: whomever wrote this clearly knew this was an issue,
> // because the manpage says: "Be careful to correctly quote/escape the name,
> // to prevent shell expansion", but fails to note that "correct" is not well
> // defined and barely achievable here.

Great catch, I agree that does seem to be the problem.  I’ll try to patch this 
soon.

Stephen

Bug#906518: qa.debian.org: Missing manpages webpage links to seemingly dead project

[Stephen Gelman]

Great point I totally missed that before.  I'll contact them!

On Wed, Jun 19, 2019 at 9:02 PM Paul Wise  wrote:
>
> On Sat, Aug 18, 2018 at 5:03 AM Stephen Gelman wrote:
>
> > It seems that the "Missing Man Pages Project" [1] linked to from the 
> > missing manpages qa page [2] is no longer an active project.  The project 
> > page linked is gone (and seems to have been gone since 2013 at least) and I 
> > can't seem to find any replacement for it.  Therefore, it seems that the 
> > link, along with the suggestion to submit man pages to it, should be 
> > removed.
> >
> > [1] http://www.netmeister.org/misc/m2p2/index.html
> > [2] http://qa.debian.org/man-pages.html
>
> The link is 403, which implies that this is caused by (umask)
> misconfiguration rather than removal. Instead of removing the link, I
> suggest contacting the maintainer of the page and asking them about
> the status. Their blog is active and they list their contact
> information on the front page of their website.
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise

Bug#906518: qa.debian.org: Missing manpages webpage links to seemingly dead project

[Stephen Gelman]

I contacted him and the reply was:

> Thanks for contacting me, but I'm afraid those efforts
> are long dead.  Please remove the links.

On Wed, Jun 19, 2019 at 9:05 PM Stephen Gelman  wrote:
>
> Great point I totally missed that before.  I'll contact them!
>
> On Wed, Jun 19, 2019 at 9:02 PM Paul Wise  wrote:
> >
> > On Sat, Aug 18, 2018 at 5:03 AM Stephen Gelman wrote:
> >
> > > It seems that the "Missing Man Pages Project" [1] linked to from the 
> > > missing manpages qa page [2] is no longer an active project.  The project 
> > > page linked is gone (and seems to have been gone since 2013 at least) and 
> > > I can't seem to find any replacement for it.  Therefore, it seems that 
> > > the link, along with the suggestion to submit man pages to it, should be 
> > > removed.
> > >
> > > [1] http://www.netmeister.org/misc/m2p2/index.html
> > > [2] http://qa.debian.org/man-pages.html
> >
> > The link is 403, which implies that this is caused by (umask)
> > misconfiguration rather than removal. Instead of removing the link, I
> > suggest contacting the maintainer of the page and asking them about
> > the status. Their blog is active and they list their contact
> > information on the front page of their website.
> >
> > --
> > bye,
> > pabs
> >
> > https://wiki.debian.org/PaulWise

Bug#1020270: ITP: golang-debian-vasudev-gospake2 -- Go SPAKE2 Implementation

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-debian-vasudev-gospake2
  Version : 0.2.1+git20210510.d916299-1
  Upstream Author : Vasudev Kamath 
* URL : https://salsa.debian.org/vasudev/gospake2
* License : Expat or GPL-3
  Programming Lang: Go
  Description : Go SPAKE2 Implementation (library)

 Implementation of SPAKE2 key exchange protocol which interoperates with Rust
 Haskell and Python versions.

 This package defines the behavior of group and its element as package groups.
 It also implements 2 groups ed25519 and multiplicative group over integer as
 2 packages. SPAKE2 calculation uses ed25519 as default group and
 allows user to switch to group of his choice.

This is a dependency for wormhole-william, which is in turn a dependency for
the new release of termshark. This package will be team maintaned by the go
team.

Bug#1020271: ITP: golang-nhooyr-websocket -- Minimal and idiomatic WebSocket library for Go

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-nhooyr-websocket
  Version : 1.8.7-1
  Upstream Author : Anmol Sethi
* URL : https://github.com/nhooyr/websocket
* License : Expat
  Programming Lang: Go
  Description : Minimal and idiomatic WebSocket library for Go

 websocket is a minimal and idiomatic WebSocket library for Go.

 Highlights

  * Minimal and idiomatic API
  * First class context.Context (https://blog.golang.org/context) support
  * Fully passes the WebSocket autobahn-testsuite
(https://github.com/crossbario/autobahn-testsuite)
  * Single dependency
(https://pkg.go.dev/nhooyr.io/websocket?tab=imports)
  * JSON and protobuf helpers in the wsjson
(https://pkg.go.dev/nhooyr.io/websocket/wsjson) and wspb
(https://pkg.go.dev/nhooyr.io/websocket/wspb) subpackages
  * Zero alloc reads and writes
  * Concurrent writes
  * Close handshake (https://pkg.go.dev/nhooyr.io/websocket#Conn.Close)
  * net.Conn (https://pkg.go.dev/nhooyr.io/websocket#NetConn) wrapper
  * Ping pong (https://pkg.go.dev/nhooyr.io/websocket#Conn.Ping) API
  * RFC 7692 (https://tools.ietf.org/html/rfc7692) permessage-deflate
compression
  * Compile to Wasm (https://pkg.go.dev/nhooyr.io/websocket#hdr-Wasm)

This is a dependency for wormhole-william, which is in turn a dependency for
the new release of termshark. This package will be team maintaned by the go
team.

Bug#1020272: ITP: wormhole-william -- End-to-end encrypted file transfer. A magic wormhole CLI and API in Go (golang).

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: wormhole-william
  Version : 1.0.6-1
  Upstream Author : Peter Sanford
* URL : https://github.com/psanford/wormhole-william
* License : Expat
  Programming Lang: Go
  Description : End-to-end encrypted file transfer. A magic wormhole CLI 
and API in Go (golang).

 wormhole-william

 wormhole-william is a Go (golang) implementation of magic wormhole
 (https://magic-wormhole.readthedocs.io/en/latest/). It provides secure
 end-to-end encrypted file transfers between computers. The endpoints are
 connected using the same "wormhole code".

 wormhole-william is compatible with the official python magic wormhole
 cli tool (https://github.com/warner/magic-wormhole).

 Currently, wormhole-william supports:

  * sending and receiving text over the wormhole protocol
  * sending and receiving files over the transit protocol
  * sending and receiving directories over the transit protocol

This is a dependency of termshark 2.4.0. It will be team maintained by the go
team.

Bug#1020398: ITP: jqp -- A TUI playground to experiment with jq

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: jqp
  Version : 0.1.0-1
  Upstream Author : Noah Gorstein
* URL : https://github.com/noahgorstein/jqp
* License : Expat
  Programming Lang: Go
  Description : A TUI playground to experiment with jq

 A TUI tool that allows for experimentation with jq with fast iteration. This
 application utilizes itchny's (https://github.com/itchyny) implementation of
 jq written in Go, gojq (https://github.com/itchyny/gojq).

This package will be team maintained by the go team.

Bug#1020935: Old Version of go used to build git-lfs

[Stephen Gelman]

On Sep 28, 2022 at 4:49:29 PM, "Bower, Jesse (LNG-HBE)" <
jesse.bo...@lexisnexis.com> wrote:

> Package: git-lfs
>
> Version: 2.13.2-1+b5
>
> After I install git-lfs the docker image is seen as having the following 
> cve’s:
>
> CVE-2022-23806
> CVE-2021-38297
> CVE-2022-27664
> CVE-2022-30631
> CVE-2022-32189
> CVE-2022-30632
> CVE-2022-30635
> CVE-2022-28131
> CVE-2022-30630
> CVE-2022-30633
> CVE-2022-23773
> CVE-2022-24921
> CVE-2022-24675
> CVE-2022-28327
> CVE-2022-30580
> CVE-2021-41772
> CVE-2021-41771
> CVE-2021-44716
> CVE-2021-39293
> CVE-2022-23772
> CVE-2021-33194
> CVE-2021-33195
> CVE-2021-33196
> CVE-2021-33198
> CVE-2021-29923
>
> Seen from the version of go used to build git-lfs,
>
> "name": "go",
> "version": "1.15.9",
> "path": "/usr/bin/git-lfs",
> "layerTime": 0,
> "knownVulnerabilities": 72
>
> Example Dockerfile used for testing
>
> FROM debian:stable-slim
>
> RUN apt-get update && apt-get upgrade -y && apt-get install -y git-lfs
>
>
>
> I suggest that the version of go used to build git-lfs is updated to a
> current version.
>
>
>
> Thank you,
>
> Jesse Bower
>

Jesse,

The way that go packages are built in Debian is that they are required to
use the version of the go compiler in the current release. Therefore, any
CVEs that are patched there are also patched in this version of git-lfs. If
there are unpatched vulnerabilities with the debian go compiler, you will
instead need to file a bug against the golang-go package.

Stephen

Bug#912146: [pkg-go] Bug#912146: Symantec CT Log Servers have been EOL'd

[Stephen Gelman]

Thanks for the bug report.  I just uploaded 0.9-2 that includes this patch.

Stephen

> On Oct 28, 2018, at 9:56 AM, Sven Hartge  wrote:
> 
> Package: certspotter
> Version: 0.9-1
> Severity: normal
> Tags: upstream patch
> 
> Hi!
> 
> At the end of September Symantec EOL'd their CT log servers, which now
> cause certspotter to issue warning when trying to contact them
> 
> Upstream has a simple patch ready at
> https://github.com/SSLMate/certspotter/commit/20b1df83cc5b35e70141c5f40c23314011acaa16,
> please include this in Debian to get rid of the warnings.
> 
> Grüße,
> Sven.
> 
> -- System Information:
> Debian Release: buster/sid
>  APT prefers unstable-debug
>  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
> 'unstable'), (500, 'testing'), (200, 'experimental'), (1, 
> 'experimental-debug')
> Architecture: i386 (x86_64)
> Foreign Architectures: amd64
> 
> Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
> LANGUAGE=de_DE.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages certspotter depends on:
> ii  libc6  2.27-6
> 
> certspotter recommends no packages.
> 
> certspotter suggests no packages.
> 
> -- debconf-show failed
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#900746: xen toolstack xl causes a Segmentation fault on create domu

[Stephen Gelman]

Any chance this can make it into the next stretch point release?  We’re 
currently maintaining our own package and it’d be really nice to not have to.

Stephen

Bug#920009: golang-google-cloud FTBFS with golang-google-genproto-dev 0.0~git20190111.db91494-1

[Stephen Gelman]

> On Jan 21, 2019, at 9:14 AM, Adrian Bunk  wrote:
> 
> Source: golang-google-cloud
> Version: 0.9.0-7
> Severity: serious
> Tags: ftbfs
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-google-cloud.html
> 
> ...
> dh_auto_build
>   cd build && go install 
> -gcflags=all=\"-trimpath=/build/1st/golang-google-cloud-0.9.0/build/src\" 
> -asmflags=all=\"-trimpath=/build/1st/golang-google-cloud-0.9.0/build/src\" -v 
> -p 16 cloud.google.com/go cloud.google.com/go/bigquery 
> cloud.google.com/go/bigtable cloud.google.com/go/bigtable/bttest 
> cloud.google.com/go/bigtable/cmd/cbt 
> cloud.google.com/go/bigtable/cmd/emulator 
> cloud.google.com/go/bigtable/cmd/loadtest 
> cloud.google.com/go/bigtable/cmd/scantest 
> cloud.google.com/go/bigtable/internal/cbtconfig 
> cloud.google.com/go/bigtable/internal/gax 
> cloud.google.com/go/bigtable/internal/option 
> cloud.google.com/go/bigtable/internal/stat cloud.google.com/go/civil 
> cloud.google.com/go/compute/metadata cloud.google.com/go/container 
> cloud.google.com/go/datastore cloud.google.com/go/debugger/apiv2 
> cloud.google.com/go/errorreporting/apiv1beta1 cloud.google.com/go/errors 
> cloud.google.com/go/iam cloud.google.com/go/iam/admin/apiv1 
> cloud.google.com/go/internal cloud.google.com/go/internal/atomiccache 
> cloud.google.com/go/internal/fields cloud.google.com/go/internal/optional 
> cloud.google.com/go/internal/pretty cloud.google.com/go/internal/readme 
> cloud.google.com/go/internal/rpcreplay 
> cloud.google.com/go/internal/rpcreplay/proto/intstore 
> cloud.google.com/go/internal/rpcreplay/proto/rpcreplay 
> cloud.google.com/go/internal/testutil 
> cloud.google.com/go/internal/tracecontext 
> cloud.google.com/go/internal/version cloud.google.com/go/language/apiv1 
> cloud.google.com/go/language/apiv1beta2 cloud.google.com/go/logging 
> cloud.google.com/go/logging/apiv2 cloud.google.com/go/logging/internal 
> cloud.google.com/go/logging/internal/testing 
> cloud.google.com/go/logging/logadmin cloud.google.com/go/longrunning 
> cloud.google.com/go/longrunning/autogen cloud.google.com/go/monitoring/apiv3 
> cloud.google.com/go/profiler cloud.google.com/go/profiler/mocks 
> cloud.google.com/go/pubsub cloud.google.com/go/pubsub/apiv1 
> cloud.google.com/go/pubsub/loadtest cloud.google.com/go/pubsub/loadtest/cmd 
> cloud.google.com/go/pubsub/loadtest/pb cloud.google.com/go/spanner 
> cloud.google.com/go/spanner/admin/database/apiv1 
> cloud.google.com/go/spanner/admin/instance/apiv1 
> cloud.google.com/go/spanner/internal/testutil 
> cloud.google.com/go/speech/apiv1 cloud.google.com/go/speech/apiv1beta1 
> cloud.google.com/go/storage cloud.google.com/go/trace 
> cloud.google.com/go/trace/apiv1 cloud.google.com/go/translate 
> cloud.google.com/go/translate/internal/translate/v2 
> cloud.google.com/go/videointelligence/apiv1beta1
> src/cloud.google.com/go/speech/apiv1beta1/speech_client.go:29:2: cannot find 
> package "google.golang.org/genproto/googleapis/cloud/speech/v1beta1" in any 
> of:
>   
> /usr/lib/go-1.11/src/google.golang.org/genproto/googleapis/cloud/speech/v1beta1
>  (from $GOROOT)
>   
> /build/1st/golang-google-cloud-0.9.0/build/src/google.golang.org/genproto/googleapis/cloud/speech/v1beta1
>  (from $GOPATH)
> 

I have 0.34.1 almost ready to upload - just waiting on two deps to clear NEW.

Stephen

Bug#920009: golang-google-cloud FTBFS with golang-google-genproto-dev 0.0~git20190111.db91494-1

[Stephen Gelman]

> On Feb 4, 2019, at 11:59 PM, Martín Ferrari  wrote:
> 
> On 05/02/2019 04:44, Stephen Gelman wrote:
> 
>> I have 0.34.1 almost ready to upload - just waiting on two deps to clear NEW.
> 
> Sorry to be a killjoy, but are you sure a new version is needed to solve
> this problem? We are very close to the freeze, and way too many packages
> depend on this. I am working now with other breakage coming from
> genproto, so maybe this can be fixed in a different -and less risky- way.
> 
> 
> -- 
> Martín Ferrari (Tincho)
> 

I totally understand your concern.  I’m at least a few backported bug fixes 
deep and I am concerned the resulting package will have had so many changes 
applied that it will be a bit of a mess.  As a middle ground, I think I can get 
0.9.0 patched for now with the intention of uploading a new version once we are 
out of hot water here.  Do you think that is reasonable?  I apologize if I 
didn’t communicate my intentions better here - I emailed pkg-go a while back 
but I neglected to respond to this bug (oversight on my part, sorry!).

Stephen

Bug#920009: golang-google-cloud FTBFS with golang-google-genproto-dev 0.0~git20190111.db91494-1

[Stephen Gelman]

> On Feb 5, 2019, at 1:17 AM, Martín Ferrari  wrote:
> 
> On 05/02/2019 06:41, Stephen Gelman wrote:
> 
>> I totally understand your concern.  I’m at least a few backported bug fixes 
>> deep and I am concerned the resulting package will have had so many changes 
>> applied that it will be a bit of a mess.
> 
> Ouch. More reason to hold the upgrade then.

Sorry, I think you misinterpret what I mean: 0.34.1 works perfectly out of the 
box, I was referring to trying to get 0.9.0 working.  At this point there have 
already been 7 debian revisions of 0.9.0 so regardless of the outcome here I 
think we should plan to upload a newer version in the near future (though I 
agree with your point about getting 0.9.0 patched first).

>> As a middle ground, I think I can get 0.9.0 patched for now with the
> intention of uploading a new version once we are out of hot water here.
> Do you think that is reasonable?
> 
> Yesm that sounds good. In fact, I was writing an email to you telling
> you that I think the fix is pretty easy: the breakage is because
> genproto removed a deprecated API
> (google.golang.org/genproto/googleapis/cloud/speech/v1beta1) that this
> package depends on. The fix (as upstream did it) is to remove the
> packages that reflect that API, and it is easy to backport.
> 
> I have already been working on this for a while. That problem is fixed,
> but there are still a few discrepancies with bigtable and spanner, which
> I hope to fix soon and upload. Unless you had already fixed that?

I am still getting through the spanner tests but I am pretty close to being 
done (I really truly hope).  If you want to complete it I am happy to back off 
and let you but I’m also happy to finish going through them.  Just let me know!

Stephen

Bug#921637: [pkg-go] Bug#921637: FTBFS: /usr/lib/ruby/vendor_ruby/ronn/roff.rb:165:in `block_filter': undefined method

[Stephen Gelman]

I just reassigned this to ronn.  It looks like we are hitting the bug
https://github.com/apjanke/ronn-ng/issues/24.  Any man page with a
numbered list appears to fail.

On Thu, Feb 7, 2019 at 9:03 AM Shengjing Zhu  wrote:
>
> Package: git-lfs
> Version: 2.6.1-3
> Severity: serious
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
> When rebuild git-lfs, it FTBFS:
>
> warn: unrecognized inline tag: ["p"]
>  html: man/git-lfs-untrack.1.html+man
>  roff: man/git-lfs-update.1
>  html: man/git-lfs-update.1.html +man
>  roff: man/git-lfs.1
> /usr/lib/ruby/vendor_ruby/ronn/roff.rb:165:in `block_filter': undefined 
> method `position' for # 
> (NoMethodError)
> from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:88:in `block in 
> block_filter'
> from /usr/lib/ruby/vendor_ruby/nokogiri/xml/node_set.rb:204:in `block 
> in each'
> from /usr/lib/ruby/vendor_ruby/nokogiri/xml/node_set.rb:203:in `upto'
> from /usr/lib/ruby/vendor_ruby/nokogiri/xml/node_set.rb:203:in `each'
> from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:88:in `block_filter'
> from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:160:in `block_filter'
> from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:88:in `block in 
> block_filter'
> from /usr/lib/ruby/vendor_ruby/nokogiri/xml/node_set.rb:204:in `block 
> in each'
> from /usr/lib/ruby/vendor_ruby/nokogiri/xml/node_set.rb:203:in `upto'
> from /usr/lib/ruby/vendor_ruby/nokogiri/xml/node_set.rb:203:in `each'
> from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:88:in `block_filter'
> from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:91:in `block_filter'
> from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:18:in `initialize'
> from /usr/lib/ruby/vendor_ruby/ronn/document.rb:245:in `new'
> from /usr/lib/ruby/vendor_ruby/ronn/document.rb:245:in `to_roff'
> from /usr/lib/ruby/vendor_ruby/ronn/document.rb:240:in `convert'
> from /usr/bin/ronn:209:in `block (2 levels) in '
> from /usr/bin/ronn:199:in `each'
> from /usr/bin/ronn:199:in `block in '
> from /usr/bin/ronn:184:in `each'
> from /usr/bin/ronn:184:in `'
> make[1]: *** [debian/rules:28: override_dh_auto_build] Error 1
>
>
> I see ruby-ronn 0.8.0-1 was accepted on 2019-02-07, this may be the
> reason.
>
> Please reassign to ruby-ronn if you think it's the bug in ruby-ronn
> instead.
>
> - --
> Shengjing Zhu
>
> -BEGIN PGP SIGNATURE-
>
> iQFEBAEBCgAuFiEE85F2DZP0aJKsSKyHONAPABi+PjUFAlxcR7IQHHpoc2pAZGVi
> aWFuLm9yZwAKCRA40A8AGL4+NTqRB/0TMPE3oaR0kUXa78k6HUizl9f5+Npxawn9
> OU1fFYEbY4yh4wZcXigqitBavnF3KvYpOWb4KbrKb04FYK3KOSWW/eXVKnQraSQc
> YL57l2p2zEQVydKBt/9ADBskd13fxNLOVki/asiRN0MoHuiHw6vzZaWbCKyPlght
> LE3CxXMuKLhAuUG+0BSliKRxNDHidcALEqKvmzmajgNccMeDvDSqO8ePy33YDvW2
> 3x8QDpm8emgy5+V1DCRRQbchKhbsrYQp+ali6/UPV4aEV8Um7QBCVTytr0819kDr
> U2v+t8MCnBQiZ9a+znhvBfjRFi4cW6S0Gx+6hXKI6HvftepwV9zt
> =RKLP
> -END PGP SIGNATURE-
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#909644: Bug #909644: docker.io: dockerd warning: failed to retrieve docker-runc version: unknown output format: runc version spec: 1.0.1

[Stephen Gelman]

> On Mar 5, 2019, at 7:50 PM, Arnaud Rebillout  
> wrote:
> 
>   Dear Go team,
> 
> So let met sum up this bug now to avoid you reading the backlog:
> 
> In short, docker doesn't recognize the output of `runc --version`, and
> then it misbehaves and flood the log forever. To be more accurate,
> docker is not happy because it wants to know the git commit that was
> used to build runc. This information may or may not be part of the
> output of `runc --version`: it depends on how runc was built. Actually,
> there are two fields, `version` and `gitcommit`, that can be passed
> optionally to runc during the build (as ldflags). Therefore the output
> of `runc --version` varies accordingly.
> 
> So there's two ways out of that:
> 
> **Solution 1**
> 
> One is to patch docker, and fix their code so that it can handle various
> runc version outputs. This is the way chosen by buildroot for example:
> 
> https://github.com/buildroot/buildroot/blob/master/package/docker-engine/0001-Fix-faulty-runc-version-commit-scrape.patch
> 
> Note that this patch is not the definitive solution: it just allows
> docker to handle the output of runc *as built in buildroot*, and not in
> every case. If we go this way, we'll do something similar, supporting
> "debian's runc" output, and end up with a patch that has no chance to
> make it upstream.
> 
> Maybe the core of the issue is that the `runc --version` output is
> difficult to parse properly, and that's why docker upstream don't want
> to bother fixing their code...
> 
> 
> **Solution 2**
> 
> The other way is to modify the runc build so that we include the git
> commit. I've pushed such a change on a branch at:
> 
> https://salsa.debian.org/go-team/packages/runc/commit/033a60b549b0935861c92bf4e5118d03ef443a8f
> 
> It's actually not that bad, no patch involved, it's really just adding
> ldflags. The only downside I see is that there's an additional step when
> a maintainer wants to release a new upstream version: he has to look for
> the corresponding commit and add it to the file
> `debian/upstream-version-gitcommits`. I provided a helper script to do
> that, so it's really a small overhead.
> 
> 
> **What do you think?**
> 
> I'm in favor of solution 2, it seems the path of least trouble, and is
> also a correct thing to do IMHO. I'd like to have this fixed for buster,
> as this issue has been opened for a long while.
> 
> If you agree with solution 2 I'll need some DD to upload a new version
> of runc with this change (sorry to bother you...). Also this bug should
> be re-assigned to runc if we solve it in the runc package.
> 
> For more details you can also look at upstream discussion:
> https://github.com/moby/moby/issues/38709
> 
> 
> All the best,
> 
>   Arnaud

Based on the upstream bug linked it sounds like solution 2 is what they prefer, 
and also makes runc consistent with upstream releases.  If there’s consensus I 
am happy to sponsor an upload of runc for you.  Unfortunately, since we’re so 
close to the freeze it will not make it into buster unless there is an 
exception made.

Stephen

Bug#922618: Any plan to package bird 2.0 as a separate package?

[Stephen Gelman]

Ondřej,

What is your plan for uploading the bird2 package?  I am currently
looking at upgrading some hosts running old releases of bird and am
debating whether I should make the effort to go all the way to bird2
or not.

Thanks!

Stephen

Bug#922618: Any plan to package bird 2.0 as a separate package?

[Stephen Gelman]

On Tue, Mar 12, 2019 at 2:55 PM Ondřej Surý  wrote:
> It’s sitting in NEW queue: 
> https://ftp-master.debian.org/new/bird2_2.0.4-1.html
>
> The priority for ftp-masters is now getting buster out, so the NEW queue 
> might get a little bit longer before they clear it up.
>
> Ondrej
> --
> Ondřej Surý
> ond...@sury.org

Ah I totally missed that.  Thanks for the quick reply!

Stephen

Bug#900746: xen toolstack xl causes a Segmentation fault on create domu

[Stephen Gelman]

On Thu, 28 Jun 2018 18:58:24 +0200 Hans van Kranenburg  wrote:
> Hi,
>
> On 06/28/2018 09:58 AM, Damian Pietras wrote:
> > I've also hit it on one of my boxes with
> > 4.8.3+xsa267+shim4.10.1+xsa267-1+deb9u8
> >
> > This is related to too small stack size set for threads in XEN utils
> > which explicitly set it to use 16KB. Similar issue is reported here for
> > NTP: https://bugzilla.redhat.com/show_bug.cgi?id=1564527
> >
> > I've recompilled the package with the attached patch to increase the
> > stack size from 16KB to 32KB and it works.
>
> Thanks for doing "bug triaging"!
>
> > Technical details:
> >
> > The issue appears with modern CPU that support AVX-512 instruction set,
> > in my case it's Intel(R) Xeon(R) Gold 6148. More details are in this
> > bug report against glibc: https://bugzilla.redhat.com/show_bug.cgi?id=1
> > 527887#c18
> >
> > There was a post on xen-users acknowledging the bug that says it's
> > fixed in XEN 4.11: https://lists.xenproject.org/archives/html/xen-users
> > /2018-05/msg00034.html
>
> Following that post and what happened afterwards leads me to upstream
> commit 448c03b3cb "tools/xenstore: try to get minimum thread stack size
> for watch thread", which seems to solve this problem without hardcoding
> some size.
>
> Maybe this should be a nice candidate for upstream backport to stable
> branches, since users are buying newer hardware and otherwise cannot use
> Debian Stable without recompiling their Xen packages?
>
> Ian?
>
> Thanks,
> Hans

This patch fixed segfault problems for us on servers with Intel Xeon
Gold 6148 CPUs.  What would it take to get this patch included in the
next stretch update?  It's a pretty big deal for us right now and
while we'll be ok running this patched version for now it'd be great
to not have to maintain our own patch.

Thanks,

Stephen

Bug#920781: ITP: golang-github-ianlancetaylor-demangle -- C++ symbol name demangler written in Go

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-ianlancetaylor-demangle
  Version : 0.0~git20181102.5e5cf60-1
  Upstream Author : Ian Lance Taylor
* URL : https://github.com/ianlancetaylor/demangle
* License : BSD-3-clause
  Programming Lang: Go
  Description : C++ symbol name demangler written in Go

 A Go package that can be used to demangle C++ symbol names.

This is a dependency of golang-github-google-pprof (which is in turn a
dependency of a newer release of golang-google-cloud)

Bug#920782: ITP: golang-github-google-pprof -- pprof is a tool for visualization and analysis of profiling data

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-google-pprof
  Version : 0.0~git20190109.e84dfd6-1
  Upstream Author : Google
* URL : https://github.com/google/pprof
* License : Apache-2.0
  Programming Lang: Go
  Description : pprof is a tool for visualization and analysis of profiling 
data

 pprof is a tool for visualization and analysis of profiling data.
 .
 pprof reads a collection of profiling samples in profile.proto format
 and generates reports to visualize and help analyze the data. It can
 generate both text and graphical reports (through the use of the dot
 visualization package).
 .
 profile.proto is a protocol buffer that describes a set of callstacks
 and symbolization information. A common usage is to represent a set of
 sampled callstacks from statistical profiling. The format is described
 on the proto/profile.proto (./proto/profile.proto) file. For details on
 protocol buffers, see https://developers.google.com/protocol-buffers
 .
 Profiles can be read from a local file, or over http. Multiple profiles
 of the same type can be aggregated or compared.
 .
 If the profile samples contain machine addresses, pprof can symbolize
 them through the use of the native binutils tools (addr2line and nm).

This is a dependency of a newer version of golang-google-cloud.

Bug#920783: ITP: golang-go.opencensus -- A stats collection and distributed tracing framework

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-go.opencensus
  Version : 0.18.0+git20190117.2f39cd4-1
  Upstream Author : OpenCensus Authors
* URL : https://github.com/census-instrumentation/opencensus-go
* License : Apache-2.0
  Programming Lang: Go
  Description : A stats collection and distributed tracing framework

 OpenCensus Go is a Go implementation of OpenCensus, a toolkit for collecting
 application performance and behavior monitoring data. Currently it consists
 of three major components: tags, stats and tracing.

This is a dependency of an updated version of golang-google-cloud

Bug#920784: ITP: golang-github-google-martian -- Martian is a library for building custom HTTP/S proxies

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-google-martian
  Version : 2.1.0+git20181219.d0b5ad3-1
  Upstream Author : Google
* URL : https://github.com/google/martian
* License : Apache-2.0
  Programming Lang: Go
  Description : Martian is a library for building custom HTTP/S proxies

 Martian Proxy is a programmable HTTP proxy designed to be used for testing.

This package is a dependency of a new release of golang-google-cloud

Bug#920785: ITP: golang-github-openzipkin-zipkin-go -- Zipkin tracer library for go

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-openzipkin-zipkin-go
  Version : 0.1.5+git20190103.2fd7f4a-1
  Upstream Author : The OpenZipkin Authors
* URL : https://github.com/openzipkin/zipkin-go
* License : Apache-2.0
  Programming Lang: Go
  Description : Zipkin tracer library for go

 Zipkin Go is the official Go Tracer implementation for Zipkin, supported
 by the OpenZipkin community.  package organization zipkin-go is built
 with interoperability in mind within the OpenZipkin community and even
 3rd parties, the library consists of several packages.

This package is a dependency of golang-go.opencensus which is in turn a
dependency of a new version of golang-google-cloud.

Bug#904788: ITP: golang-github-git-lfs-gitobj -- gitobj reads and writes Git objects.

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-git-lfs-gitobj
  Version : 0.0~git20180705.5aa0c18-1
  Upstream Author : Git LFS
* URL : https://github.com/git-lfs/gitobj
* License : Expat
  Programming Lang: Go
  Description : gitobj reads and writes Git objects.

 Package gitobj reads and writes loose and packed Git objects.

This is a dependency of git-lfs.  It will be maintained by the debian go
packaging team.

Bug#899048: [pkg-go] Bug#899048: git-lfs: please consider uploading to stretch-backports

[Stephen Gelman]

I was planning on doing that soon actually.  I’ll try to get to it this 
weekend.  Thanks for the reminder! ;)

> On May 18, 2018, at 12:28 PM, Mattia Rizzolo  wrote:
> 
> Source: git-lfs
> Severity: wishlist
> 
> Dear maintainer,
> 
> I notice that sadly the first upload of git-lfs didn't make in time for
> stretch, so that now we can't easily use it there through the regular
> debian means.
> 
> I'm asking whether you could be so kind as to provide us with backports
> to stretch of git-lfs.
> I notice the current package declares a bunch of build-dependencies that
> are not available in stretch nor stretch-backports, but I also see you
> maintain all of them.
> If needed, I would be happy to sponsor the inital uploads of them (as
> you are a DM you could easily do the next ones).
> 
> For more information about backports, see https://backports.debian.org/
> 
> Thanks in advance!
> 
> -- 
> regards,
>Mattia Rizzolo
> 
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#900327: ITP: golang-github-git-lfs-go-netrc -- netrc file parser for Go programming language.

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-git-lfs-go-netrc
  Version : 0.0~git20180525.e0e9ca4-1
  Upstream Author : Git LFS
* URL : https://github.com/git-lfs/go-netrc
* License : Expat
  Programming Lang: Go
  Description : netrc file parser for Go programming language.

 go-netrc A Golang package for reading and writing netrc files. This
 package can parse netrc files, make changes to them, and then serialize
 them back to netrc format, while preserving any whitespace that was
 present in the source file.
 .
 GoDoc (https://godoc.org/github.com/bgentry/go-netrc)

This is a patched version of golang-github-bgentry-go-netrc that is used by
git-lfs.

Bug#915741: git-lfs: git push -n actually uploads LFS objects

[Stephen Gelman]

Andreas,

Thanks for reporting this.  I’ll look into it!

Stephen

Bug#915741: [pkg-go] Bug#915741: git-lfs: git push -n actually uploads LFS objects

[Stephen Gelman]

> I just noticed that 
>  git push -n origin --all
> started to upload LFS objects to the server ...

This appears to be an upstream bug.  Submitted upstream as 
https://github.com/git-lfs/git-lfs/issues/3418 
.

Stephen

Bug#906524: man page for muttdown

[Stephen Gelman]

On Fri, Aug 17, 2018 at 11:02 PM gustavo panizzo  wrote:
> I'll wait to see if upstream merges it otherwise I'll just ship it.

Looks like the upstream PR was merged, FYI

Stephen

Bug#943726: ITP: golang-github-ssgelm-cookiejarparser -- A Go library that parses a curl (netscape) cookiejar file into a Go http.CookieJar

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-ssgelm-cookiejarparser
  Version : 1.0.0-1
  Upstream Author : Stephen Gelman 
* URL : https://github.com/ssgelm/cookiejarparser
* License : Expat
  Programming Lang: Go
  Description : A Go library that parses a curl (netscape) cookiejar file 
into a Go http.CookieJar

 cookiejarparser cookiejarparser is a Go library that parses a curl
 (netscape) cookiejar file into a Go http.CookieJar.

This is a new dependency for git-lfs

Bug#964458: checkinstall: causes segfault of cmake

[Stephen Gelman]

On Jul 7, 2020, at 9:42 AM, Jiri Palecek  wrote:
> 
> Package: checkinstall
> Version: 1.6.2+git20170426.d24a630-2
> Severity: important
> File: /usr/bin/installwatch
> 
> Dear Maintainer,
> 
> while trying to use checkinstall to create a debianized package from a
> cmake based source, the build failed with a segfault. These are linked
> to installwatch and don't happen without it:
> 
> $ installwatch make cmake_check_build_system
> 
> INFO : Using a default root directory : /tmp/tmp.JBpq66zd4H
> 
> make: *** [Makefile:10806: cmake_check_build_system] Neoprávněný přístup do 
> paměti (SIGSEGV) (obraz paměti uložen)
> 
> There is a backtrace of the crash, which indicates it happens early in
> the initialization of cmake around a stat call:
> 
> (gdb) bt
> #0  0x in ?? ()
> #1  0xb6a3fbd3 in stat64 (__statbuf=, __path=0xb6b472bb 
> "/etc/gnutls/config") at /usr/include/i386-linux-gnu/sys/stat.h:455
> #2  _gnutls_update_system_priorities () at ../../lib/priority.c:1309
> #3  0xb6a534f5 in _gnutls_global_init (constructor=constructor@entry=1) at 
> ../../lib/global.c:387
> #4  0xb6a25950 in lib_init () at ../../lib/global.c:511
> #5  0xb7f35f5c in call_init (l=, argc=argc@entry=6, 
> argv=argv@entry=0xbfe33e64, env=0xbfe33e80) at dl-init.c:72
> #6  0xb7f36062 in call_init (env=0xbfe33e80, argv=0xbfe33e64, argc=6, 
> l=) at dl-init.c:30
> #7  _dl_init (main_map=, argc=6, argv=0xbfe33e64, 
> env=0xbfe33e80) at dl-init.c:119
> #8  0xb7f270fa in _dl_start_user () from /lib/ld-linux.so.2
> (gdb) frame 1
> #1  0xb6a3fbd3 in stat64 (__statbuf=, __path=0xb6b472bb 
> "/etc/gnutls/config") at /usr/include/i386-linux-gnu/sys/stat.h:455
> 455   return __xstat (_STAT_VER, __path, __statbuf);
> 
> Why did it end up with EIP=0 I don't know.
> 
> It seems there's some incompatibility between installwatch's LD_PRELOAD
> and glibc.
> 
> Could you have a look at it?
> 
> Regards
>Jiri Palecek

Jiri,

Thanks for the report. In order to help me narrow this down are you able to 
provide a simple test case to reproduce the problem?

Thanks!

Stephen

Bug#964458: checkinstall: causes segfault of cmake

[Stephen Gelman]

Perfect, thanks. I will take a look and see what I can do. I will warn
you that the original developer of checkinstall doesn't seem
interested in the project anymore so any fix will be limited to
anything I or any other Debian contributor can figure out so no
promises that this will be able to be fixed promptly.

Stephen

On Tue, Jul 7, 2020 at 7:30 PM Jiri Palecek  wrote:
>
> Hello,
>
> On 07. 07. 20 17:11, Stephen Gelman wrote:
> > On Jul 7, 2020, at 9:42 AM, Jiri Palecek  wrote:
> >> Package: checkinstall
> >> Version: 1.6.2+git20170426.d24a630-2
> >> Severity: important
> >> File: /usr/bin/installwatch
> >>
> >> Dear Maintainer,
> >>
> >> while trying to use checkinstall to create a debianized package from a
> >> cmake based source, the build failed with a segfault. These are linked
> >> to installwatch and don't happen without it:
> >>
> >> $ installwatch make cmake_check_build_system
> >>
> >> INFO : Using a default root directory : /tmp/tmp.JBpq66zd4H
> >>
> >> make: *** [Makefile:10806: cmake_check_build_system] Neoprávněný přístup 
> >> do paměti (SIGSEGV) (obraz paměti uložen)
> >>
> >> There is a backtrace of the crash, which indicates it happens early in
> >> the initialization of cmake around a stat call:
> >>
> >> (gdb) bt
> >> #0  0x in ?? ()
> >> #1  0xb6a3fbd3 in stat64 (__statbuf=, __path=0xb6b472bb 
> >> "/etc/gnutls/config") at /usr/include/i386-linux-gnu/sys/stat.h:455
> >> #2  _gnutls_update_system_priorities () at ../../lib/priority.c:1309
> >> #3  0xb6a534f5 in _gnutls_global_init (constructor=constructor@entry=1) at 
> >> ../../lib/global.c:387
> >> #4  0xb6a25950 in lib_init () at ../../lib/global.c:511
> >> #5  0xb7f35f5c in call_init (l=, argc=argc@entry=6, 
> >> argv=argv@entry=0xbfe33e64, env=0xbfe33e80) at dl-init.c:72
> >> #6  0xb7f36062 in call_init (env=0xbfe33e80, argv=0xbfe33e64, argc=6, 
> >> l=) at dl-init.c:30
> >> #7  _dl_init (main_map=, argc=6, argv=0xbfe33e64, 
> >> env=0xbfe33e80) at dl-init.c:119
> >> #8  0xb7f270fa in _dl_start_user () from /lib/ld-linux.so.2
> >> (gdb) frame 1
> >> #1  0xb6a3fbd3 in stat64 (__statbuf=, __path=0xb6b472bb 
> >> "/etc/gnutls/config") at /usr/include/i386-linux-gnu/sys/stat.h:455
> >> 455   return __xstat (_STAT_VER, __path, __statbuf);
> >>
> >> Why did it end up with EIP=0 I don't know.
> >>
> >> It seems there's some incompatibility between installwatch's LD_PRELOAD
> >> and glibc.
> >>
> >> Could you have a look at it?
> >>
> >> Regards
> >> Jiri Palecek
> > Jiri,
> >
> > Thanks for the report. In order to help me narrow this down are you able to 
> > provide a simple test case to reproduce the problem?
>
> I don't know if it's simple, but here goes. In an empty directory:
>
> $ touch CMakeLists.txt
>
> $ cmake .
>
> $ installwatch cmake .
>
>
> The last line crashes on my system.
>
> Regards
>
>  Jiri Palecek

Bug#961949: wrk FTCBFS: builds for the build architecture

[Stephen Gelman]

On May 31, 2020, at 12:41 AM, Helmut Grohne  wrote:
> 
> Source: wrk
> Version: 4.1.0-2
> Severity: minor
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> wrk fails to cross build from source, because it does not pass cross
> tools to make and the Makefile hard codes the build architecture
> pkg-config. An easy way to fix the former is using dh_auto_build. The
> attached patch fixes both. After applying it, wrk continues to fail
> cross building, because luajit still produces a build archtecture object
> file. It's not obvious how to fix that. However, it would help to see
> such failures in cross build logs. Therefore, I'm asking you to apply
> this partial solution to make the real issue more visible. Thanks for
> considering.
> 
> Helmut
> 

Helmut,

I just published 4.1.0-3 which applies your changes. If you’d be willing to 
point me in the right direction as to an easy way to reproduce the failures you 
were seeing I’d be happy to dig into the luajit issues you are seeing. I don’t 
have any experience cross-building packages (and minimal experience 
cross-building in general) but I’m always happy to learn something new!

Thanks,

Stephen

Bug#961949: wrk FTCBFS: builds for the build architecture

[Stephen Gelman]

On Jun 1, 2020, at 12:59 AM, Helmut Grohne  wrote:
> 
> Hi Stephen,
> 
> On Sun, May 31, 2020 at 11:47:38PM -0500, Stephen Gelman wrote:
>> I just published 4.1.0-3 which applies your changes. If you’d be willing to 
>> point me in the right direction as to an easy way to reproduce the failures 
>> you were seeing I’d be happy to dig into the luajit issues you are seeing. I 
>> don’t have any experience cross-building packages (and minimal experience 
>> cross-building in general) but I’m always happy to learn something new!
> 
> Thank you. Cross building Debian packages is relatively simple these
> days. If you are using sbuild, you pass --host=$SOMEARCH and if you are
> using pbuilder, you pass --host-arch $SOMEARCH. No special setup needed.
> Another easy way is waiting a few days and checking
> http://crossqa.debian.net/src/wrk to have it built by qa.
> 
> The luajit issue is none for the faint of heart unfortunately. The
> luajit tool produces ELF objects containing the byte code when being
> given the -b flag. Unfortunately, there doesn't seem to be a way to tell
> luajit which architecture we need ELF objects for. So this issue needs
> to be fixed on the luajit side first. It's not entirely clear whether
> this can be fixed with reasonable effort, but having build logs that
> show how this fails (such as wrk) makes it much easier to reason about
> this on the luajit side. I suggest that you leave it as is unless you
> look for a time sink.
> 
> I also think that luajit is wrongly marked Multi-Arch: foreign for this
> reason.
> 
> Helmut

Helmut,

Thad does sound pretty rough… I may let this one lie for a bit then, but this 
is very helpful info regardless!

Thanks!

Stephen

Bug#964921: RM: golang-x-text -- RoQA; Source package was renamed to golang-golang-x-text

[Stephen Gelman]

control: tags -1 - moreinfo

On Mon, 13 Jul 2020 16:56:39 -0700 Sean Whitton  
wrote:
> On Sun 12 Jul 2020 at 07:31PM +08, Shengjing Zhu wrote:
> 
>> I will amend this RM bug, after cleaning up the above packages.
>> But I'm not sure if the dependency problem is blocker for RM.
>> 
> It is.
> 
> Please remove tag when fixed.
> 
> -- 
> Sean Whitton

The above packages have been fixed to point to the new package. Dak rm is now 
happy:

> ssh mirror.ftp-master.debian.org "dak rm -Rn golang-x-text"
> Will remove the following packages from unstable:
> 
> golang-x-text |0.3.2-1 | source
> golang-x-text-dev |0.3.2-1 | all
> 
> Maintainer: Debian Go packaging team 
> 
> --- Reason ---
> 
> --
> 
> Checking reverse dependencies...
> No dependency problem found.

Please move forward with the removal.

Thanks!

Stephen

Bug#968103: [pkg-go] Bug#968103: Please package stable tagged release v1.0.0

[Stephen Gelman]

control: owner -1 !

On Aug 8, 2020, at 12:01 PM, Nicholas D Steeves  wrote:
> 
> Subject: Please package stable tagged release v1.0.0
> Source: golang-github-inconshreveable-mousetrap
> Severity: normal
> 
> Hi,
> 
> While investigating alternatives to "Afterwriting", a nodejs fountain2pdf 
> converter with a nightmare dependency chain, I found "Wrap", which has much 
> more reasonable deps.  It requires mousetrap v1.0.0.  
> 
> "rkt" appears to be the only package that would be affected ( 
> https://codesearch.debian.net/search?q=golang-github-inconshreveable-mousetrap-dev&literal=1
>  
> 
>  )
> 
> Regards,
> Nicholas

rkt FTBFS with the new package, however it also FTBFS in general 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964871 
). Additionally the 
version of this package vendored in rkt 1.0.0 so it seems safe to upload this. 
I will do so in a few minutes!

Stephen

Bug#1001672: ITP: certinfo -- print x509 certificate info

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: certinfo
  Version : 1.0.6-1
  Upstream Author : Peter Reisinger
* URL : https://github.com/pete911/certinfo
* License : Expat
  Programming Lang: Go
  Description : Print x509 certificate info

 Print x509 certificate info
 .
 Similar to openssl x509 -in  -text command, but handles chains,
 multiple files and TCP addresses. TLS/SSL version prints as well when
 using TCP address argument.

This package will be maintained by the go packaging team

Bug#1001673: ITP: golang-github-icza-gox -- Minimalistic extension to Go. It means to be a complement to the standard library.

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-icza-gox
  Version : 0.0~git20210726.cd40a3f-1
  Upstream Author : András Belicza
* URL : https://github.com/icza/gox
* License : Apache-2.0
  Programming Lang: Go
  Description : Minimalistic extension to Go. It means to be a complement 
to the standard library.

 The gox module is a minimalistic, lightweigt extension to Go. It
 contains constants, helpers and utilities which could have been part of
 Go itself.

This package will be maintained by the go team

Bug#1009715: ITP: golang-github-leonelquinteros-gotext -- Go (Golang) GNU gettext utilities package

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-leonelquinteros-gotext
  Version : 1.5.0-1
  Upstream Author : Leonel Quinteros
* URL : https://github.com/leonelquinteros/gotext
* License : Expat
  Programming Lang: Go
  Description : Go (Golang) GNU gettext utilities package

 GNU gettext utilities (https://www.gnu.org/software/gettext) for Go.
 .
 Features
 .
  * Implements GNU gettext support in native Go.
  * Complete support for PO files 
(https://www.gnu.org/software/gettext/manual/html_node/PO-Files.html) including:
* Support for multiline strings and headers.
* Support for variables inside translation strings using Go's fmt 
syntax (https://golang.org/pkg/fmt/).
* Support for pluralization rules

(https://www.gnu.org/software/gettext/manual/html_node/Translating-plural-forms.html).
* Support for message contexts 
(https://www.gnu.org/software/gettext/manual/html_node/Contexts.html).
  * Support for MO files.
  * Thread-safe: This package is safe for concurrent use across multiple 
goroutines.
  * It works with UTF-8 encoding as it's the default for Go language.
  * Unit tests available.
  * Language codes are automatically simplified from the form en_UK to en if 
the first isn't available.
  * Ready to use inside Go templates.
  * Objects are serializable to []byte to store them in cache.
  * Support for Go Modules.

This is a dependency of git-lfs and will be maintained by the go packaging
team.

Bug#1003120: git-lfs: After "git lfs install", "git push" doesn't work with an ssh key asking for a passphrase.

[Stephen Gelman]

On Jan 4, 2022 at 7:53:27 AM, Jean-Jacques Brucker <
jeanjacquesbruc...@gmail.com> wrote:

> "git push" was stuck asking forever the passphrase of my ssh key (even if
> I wrote it correcty).
>
> A workaround is to remove the passphrase (using "ssh-keygen -p"), but it
> is not an acceptable solution.
>
> It seems like a problem of closed or badly redirected stdin file
> descriptor.
>

I think there are two potential options here. The first option would be to
use an ssh-agent. If you add your key to the agent git-lfs will be able to
use it. The second option would be to install ssh-askpass and set the
SSH_ASKPASS environment variable so that it prompts you for your passphrase.

Stephen

Bug#1004678: git-lfs: allow offline operation

[Stephen Gelman]

 Thanks for reporting this. I agree that it sounds useful, though it might
be very challenging due to the decentralized nature of git-lfs. I’m happy
to keep this bug open, but it seems better served for the upstream tracker
at https://github.com/git-lfs/git-lfs/issues.

Stephen

On Jan 31, 2022 at 9:50:31 AM, Barak A. Pearlmutter 
wrote:

> Package: git-lfs
> Version: 3.0.2-1
> Severity: wishlist
> X-Debbugs-Cc: none, Barak A. Pearlmutter 
>
> I have a repo whose only remote is on a gitlab instance. I'm using
> git-lfs to manage large binary files in this repo. The remote goes down.
> Now "git add foo.pdf / git commit", when *.pdf files are tracked by lfs,
> freezes! Waits forever for the remote when trying to transfer the big
> blobs.
>
> This violates what I consider a central concept of git, namely that
> operations are local unless you explicitly fetch or push. It means you
> cannot work with lfs while offline, like on an aeroplane, or even (as
> above) when the gitlab instance is offline for maintenance.
>
> There is also a potential security issue. Users might reasonably assume
> they can safely do "git add/commit/rebase" operations locally, with
> intermediate steps exposing secret information that is later removed
> before doing a push. Nope!
>
> Anyway: I *wish* git-lfs allowed remote operation, like git-annex does.
> It seems like it should be technically possible to wait until an
> lfs-tracked file (well, its https://git-lfs.github.com/spec/v1 smudge
> stub) is actually pushed before transferring the associated big binary
> blob. Or at the very least, giving up and remembering to try again later
> if there's a big binary blob transfer problem.
>
> -- System Information:
> Versions of packages git-lfs depends on:
> ii  git1:2.34.1-1
> ii  libc6  2.33-5
>
>

Bug#1004678: git-lfs: allow offline operation

[Stephen Gelman]

On Feb 20, 2022 at 3:29:31 AM, Barak A. Pearlmutter 
wrote:

> I will file an issue upstream. But I don't expect them to care,
> because github (the company) probably views this issue as a feature,
> not a bug. This issue ties people to a single central repository and
> makes migration nearly impossible, at least for non-wizards. Which is
> basically their business model: come for the issue tracker and repo
> sharing, stay because you have no choice, you can't leave, you can't
> even commit without connecting.
>

Sorry, I realize I misspoke. I meant to say due to the _centralized_ nature
of git-lfs...

Bug#996548: ITP: golang-github-git-lfs-pktline -- Toolkit for the Git pkt-line format

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-git-lfs-pktline
  Version : 0.0~git20210330.06e9096-1
  Upstream Author : Git LFS
* URL : https://github.com/git-lfs/pktline
* License : Expat
  Programming Lang: Go
  Description : Toolkit for the Git pkt-line format

 Git pkt-line Toolkit is a Go language toolkit for reading
 and writing files using the Git pkt-line format used in various Git
 operations.

This is a new dependency of git-lfs and will be maintained under the Debian
Golang team

Bug#974547: ITP: golang-github-adam-hanna-arrayoperations -- Small library for performing union, intersect, difference and distinct operations on slices in golang

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-adam-hanna-arrayoperations
  Version : 0.2.6-1
  Upstream Author : Adam Hanna
* URL : https://github.com/adam-hanna/arrayOperations
* License : Expat
  Programming Lang: Go
  Description : Small library for performing union, intersect, difference 
and distinct operations on slices in goLang

 A small library for performing union, intersect, difference and distinct
 operations on slices in goLang

This is a dependency for the latest version of termshark

Bug#1017132: opentracing-cpp: diff for NMU version 1.6.0-2.1

[Stephen Gelman]

On Aug 28, 2022 at 4:29:03 AM, Luca Falavigna  wrote:

> Control: tags 1017132 + patch
> Control: tags 1017132 + pending
>
>
> Dear maintainer,
>
> I've prepared an NMU for opentracing-cpp (versioned as 1.6.0-2.1) and
> uploaded it to DELAYED/7. Please feel free to tell me if I
> should delay it longer.
>
> Regards,
> Luca
>

This is awesome, thanks so much! It was on my todo list to fix but I hadn’t
gotten around to it yet… Would you be interested in creating a MR for your
changes to salsa? If not that’s fine, just let me know and I will pull in
the changes myself.

Stephen

Bug#1017132: opentracing-cpp: diff for NMU version 1.6.0-2.1

[Stephen Gelman]

On Aug 29, 2022 at 6:52:06 AM, Luca Falavigna  wrote:

> Il giorno lun 29 ago 2022 alle ore 07:34 Stephen Gelman
>  ha scritto:
>
> Would you be interested in creating a MR for your changes to salsa? If not
> that’s fine, just let me know and I will pull in the changes myself.
>
>
> Sure, here it is:
> https://salsa.debian.org/ssgelm/opentracing-cpp/-/merge_requests/1
>
> --
> Cheers,
> Luca
>

This looks awesome; I merged it. Would you like to cancel your NMU and I
can release 1.6.0-3 now, or would you prefer to wait for your NMU? I don’t
have particularly strong feelings in either direction.

Stephen

Bug#1011189: partman-auto-lvm/guided_size defaults to invalid value

[Stephen Gelman]

Source: partman-auto-lvm
Version: 85
Severity: normal
Tags: d-i
X-Debbugs-Cc: ssg...@debian.org

While updating some d-i preseed configs from stretch to bullseye, I
found that previously working partman configs no longer produce the
expected output. For example, on a 3.5T disk, I have the following
partman config:

  boot-root :: \
538 538 538 ext4 \
  $primary{ } \
  $bootable{ } \
  method{ format } \
  format{ } \
  use_filesystem{ } \
  filesystem{ ext4 } \
  mountpoint{ /boot } \
. \
21475 21475 21475 ext4 \
  lv_name{ root } \
  method{ lvm } \
  format{ } \
  use_filesystem{ } \
  filesystem{ ext4 } \
  mountpoint{ / } \
  $lvmok{ } \
. \
1024 1024 -1 ext4 \
  lv_name{ var } \
  method{ lvm } \
  format{ } \
  use_filesystem{ } \
  filesystem{ ext4 } \
  mountpoint{ /var } \
  $lvmok{ } \
.

I would expect this to produce the following:
- 512M /boot
- LVM VG filling the rest of the disk with:
  - 20G /
  - 3.4T /var (rest of the disk)

That is what happens in stretch and earlier (and maybe buster, I haven't
tested). In the bullseye installer I end up with the following:

  $ lsblk
  NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
  sda8:00  3.5T  0 disk
  ├─sda1 8:10  512M  0 part /boot
  └─sda2 8:20  3.5T  0 part
├─vg0-root 254:00   20G  0 lvm  /
└─vg0-var  254:10  976M  0 lvm  /var

In trying to track down this bug, I found that
partman-auto-lvm/guided_size was added and according to
https://salsa.debian.org/installer-team/partman-auto-lvm/-/blob/master/debian/partman-auto-lvm.templates#L77-L79,
defaults to a value of "some number". Unsurprisingly, this is not a
valid number configuration option, so the maximum size doesn't get set
properly. Setting "d-i partman-auto-lvm/guided_size string max" in my
preseed restores the previous behavior. I believe there are two issues
here:

1. "partman-auto-lvm/guided_size" should default to "max" in order to
   maintain compatibility with previous releases.
2. When "partman-auto-lvm/guided_size" is set to an invalid value it
   seems that the code does not behave properly. I'm not sure what behavior
   I'd expect, but I don't think the behavior I am seeing of picking the
   minimum size for each partition is correct.

Thanks!

Stephen

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

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

Bug#1011189: partman-auto-lvm/guided_size defaults to invalid value

[Stephen Gelman]

On May 19, 2022 at 2:12:54 AM, Cyril Brulebois  wrote:

> Hi Stephen,
>
> Stephen Gelman  (2022-05-17):
>
> In trying to track down this bug, I found that
>
> partman-auto-lvm/guided_size was added and according to
>
>
> https://salsa.debian.org/installer-team/partman-auto-lvm/-/blob/master/debian/partman-auto-lvm.templates#L77-L79
> ,
>
> defaults to a value of "some number". Unsurprisingly, this is not a
>
> valid number configuration option, so the maximum size doesn't get set
>
> properly. Setting "d-i partman-auto-lvm/guided_size string max" in my
>
> preseed restores the previous behavior. I believe there are two issues
>
> here:
>
>
> 1. "partman-auto-lvm/guided_size" should default to "max" in order to
>
>maintain compatibility with previous releases.
>
> 2. When "partman-auto-lvm/guided_size" is set to an invalid value it
>
>seems that the code does not behave properly. I'm not sure what behavior
>
>I'd expect, but I don't think the behavior I am seeing of picking the
>
>minimum size for each partition is correct.
>
>
> Without trying to second guess why this default value is there instead
> of something else, you can check partman-auto-lvm/perform_recipe_by_lvm
> and the few db_subst calls.
>
> I suppose the big difference between preseeding and not preseeding is the
> seen flag checked at the top of the while loop. I don't remember all the
> details around preseeding but I'd think "auto" means most questions are
> flagged as seen, which means you don't get the default replacement you'd
> get with an interactive installation.
>
>
> I'm not too sure how to best approach a possible fix. While the issue
> has cost you some debugging time, having to be explicit about how much
> space should be used for LVM doesn't look /that/ bad to me (even if that
> means that recipes that had been working for some releases no longer
> do).
>
> That being said, maybe there are some places in the documentation and/or
> examples where we should add that.
>
>
> Cheers,
> --
> Cyril Brulebois (k...@debian.org)<https://debamax.com/>
> D-I release manager -- Release team member -- Freelance Consultant
>

Understood. I do think that newer example preseeds
have partman-auto-lvm/guided_size set to max, so there shouldn’t be a
documentation issue (other than the general lack of documentation around
the preseed file but that is unrelated to this!) My personal preference
would be for the debian-installer to raise an error if this value is
missing - that would have saved me a ton of debugging time. Expecting it to
be set does seem very reasonable to me, but I think if an older preseed
isn’t going to work properly we at least owe it to the user to surface a
proper error message.

Stephen

Bug#1010538: gdu: FTBFS on ppc64el

[Stephen Gelman]

 It seems rebuilding the package fixed this…
https://buildd.debian.org/status/logs.php?pkg=gdu&ver=5.13.2-1%2Bb1&arch=ppc64el

On May 3, 2022 at 4:07:00 PM, Sebastian Ramacher 
wrote:

> Source: gdu
> Version: 5.13.2-1
> Severity: serious
> Tags: ftbfs sid bookworm
> Justification: fails to build from source (but built successfully in the
> past)
> X-Debbugs-Cc: sramac...@debian.org
>
>
> https://buildd.debian.org/status/fetch.php?pkg=gdu&arch=ppc64el&ver=5.13.2-1%2Bb1&stamp=1651439537&raw=0
>
> === RUN   TestMin
> --- PASS: TestMin (0.00s)
> PASS
> ok   github.com/dundee/gdu/v5/tui 0.229s
> FAIL
> dh_auto_test: error: cd _build && go test -vet=off -v -p 8
> github.com/dundee/gdu/v5/build github.com/dundee/gdu/v5/cmd/gdu
> github.com/dundee/gdu/v5/cmd/gdu/app
> github.com/dundee/gdu/v5/internal/common
> github.com/dundee/gdu/v5/internal/testanalyze
> github.com/dundee/gdu/v5/internal/testapp
> github.com/dundee/gdu/v5/internal/testdev
> github.com/dundee/gdu/v5/internal/testdir
> github.com/dundee/gdu/v5/pkg/analyze github.com/dundee/gdu/v5/pkg/device
> github.com/dundee/gdu/v5/pkg/fs github.com/dundee/gdu/v5/report
> github.com/dundee/gdu/v5/stdout github.com/dundee/gdu/v5/tui returned
> exit code 1
> make: *** [debian/rules:14: binary-arch] Error 25
> dpkg-buildpackage: error: debian/rules binary-arch subprocess returned
> exit status 2
>
> Cheers
> --
> Sebastian Ramacher
>
>

Bug#976645: git-lfs: please create golang-github-git-lfs-git-lfs-dev binary package

[Stephen Gelman]

On Dec 6, 2020, at 7:28 AM, Pirate Praveen  wrote:
> 
> Package: git-lfs
> Version: 2.12.1-1
> Severity: wishlist
> 
> Hi,
> 
> Please create golang-github-git-lfs-git-lfs-dev binary package in addition to 
> git-lfs binary package.
> 
> New version of gitaly needs github.com/git-lfs/git-lfs as a build dependency.
> 
> Thanks
> Praveen
> 

This has been uploaded and is sitting in NEW 
(https://ftp-master.debian.org/new/git-lfs_2.12.1-2.html 
)

Stephen

Bug#910125: dh-golang: DH_GOLANG_INSTALL_EXTRA does not preserve file permissions

[Stephen Gelman]

Package: dh-golang
Version: 1.36
Severity: normal

When using DH_GOLANG_INSTALL_EXTRA to install some test fixtures in
https://github.com/hashicorp/go-slug I noticed that one of the files has
an execute bit that is not preserved, causing the test to fail.  This
seems to be caused by dh-golang using "copy" instead of "cp".  From
http://perldoc.perl.org/File/Copy.html:

You may use the syntax use File::Copy "cp" to get at the cp alias
for this function. The syntax is exactly the same. The behavior is
nearly the same as well: as of version 2.15, cp will preserve the
source file's permission bits like the shell utility cp(1) would do,
while copy uses the default permissions for the target file (which
may depend on the process' umask, file ownership, inherited ACLs,
etc.).

Testing locally switching to "cp" fixed my issue and I don't know of any
cases where it would break things.  I'm planning on submitting a MR to
fix this but I wanted to make sure a bug was created to track this.

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

Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dh-golang depends on:
ii  debhelper 11.4.1
ii  dpkg  1.19.1
ii  libdpkg-perl  1.19.1
ii  perl  5.26.2-7

dh-golang recommends no packages.

dh-golang suggests no packages.

-- no debconf information

Bug#910125: dh-golang: DH_GOLANG_INSTALL_EXTRA does not preserve file permissions

[Stephen Gelman]

MR submitted at
https://salsa.debian.org/go-team/packages/dh-golang/merge_requests/5

Stephen

Bug#907907: golang-google-cloud: FTBFS randomly (failing tests)

[Stephen Gelman]

> On Apr 14, 2019, at 4:04 PM, Santiago Vila  wrote:
> 
> Please, please, please, let us not release buster with packages
> failing randomly like this.

Santiago,

I agree with you that this should not ship with this issue in buster and will 
upload a new release with your patch (and then request an unblock).  Sorry for 
ignoring this bug for so long - I remember looking at this months ago but 
managed to forget about it.

Stephen

Bug#927099: unblock: golang-google-cloud/0.9.0-10

[Stephen Gelman]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package golang-google-cloud

Fixes intermittent FTBFS (tests that fail more than 90% of the time).
More info in bug #907907

unblock golang-google-cloud/0.9.0-10

Thanks!

Stephen


diff -Nru golang-google-cloud-0.9.0/debian/changelog 
golang-google-cloud-0.9.0/debian/changelog
--- golang-google-cloud-0.9.0/debian/changelog  2019-02-06 19:02:17.0 
-0600
+++ golang-google-cloud-0.9.0/debian/changelog  2019-04-14 23:59:37.0 
-0500
@@ -1,3 +1,11 @@
+golang-google-cloud (0.9.0-10) unstable; urgency=medium
+
+  * Team upload.
+  * Skip very flaky test (Closes: #907907)
+Thanks to Santiago Vila for the patch
+
+ -- Stephen Gelman   Sun, 14 Apr 2019 23:59:37 -0500
+
 golang-google-cloud (0.9.0-9) unstable; urgency=high

   * Team upload.
diff -Nru golang-google-cloud-0.9.0/debian/patches/0012-skip-flaky-test.patch 
golang-google-cloud-0.9.0/debian/patches/0012-skip-flaky-test.patch
--- golang-google-cloud-0.9.0/debian/patches/0012-skip-flaky-test.patch 
1969-12-31 18:00:00.0 -0600
+++ golang-google-cloud-0.9.0/debian/patches/0012-skip-flaky-test.patch 
2019-04-14 23:59:37.0 -0500
@@ -0,0 +1,18 @@
+From: Stephen Gelman 
+Date: Sun, 14 Apr 2019 23:57:00 -0500
+Subject: skip flaky test
+
+We are way behind on upstream so no benefit to filing a bug on this until we 
get there.
+
+Forwarded: no
+---
+--- a/bigtable/bttest/inmem_test.go
 b/bigtable/bttest/inmem_test.go
+@@ -30,6 +30,7 @@
+ )
+
+ func TestConcurrentMutationsReadModifyAndGC(t *testing.T) {
++  t.Skip("test is extremely flaky")
+   s := &server{
+   tables: make(map[string]*table),
+   }
diff -Nru golang-google-cloud-0.9.0/debian/patches/series 
golang-google-cloud-0.9.0/debian/patches/series
--- golang-google-cloud-0.9.0/debian/patches/series 2019-02-05 
02:10:24.0 -0600
+++ golang-google-cloud-0.9.0/debian/patches/series 2019-04-14 
23:54:44.0 -0500
@@ -9,3 +9,4 @@
 0009-bigtable-fix-client-changes.patch
 0010-profiler-add-createofflineprofile-mock.patch
 0011-spanner-fix-tests.patch
+0012-skip-flaky-test.patch

Bug#907907: golang-google-cloud: FTBFS randomly (failing tests)

[Stephen Gelman]

FYI, unblock request filed as #927099.

Stephen

Bug#927973: ncurses-base: Please move tmux and tmux-256color to ncurses-base

[Stephen Gelman]

Package: ncurses-base
Version: 6.1+20181013-2
Severity: wishlist

Tmux has gotten very popular and seems to be at a similar level of
popularity as screen (which is already in ncurses-base). We currently
have to install ncurses-term on all our servers because of this which
seems like overkill for this.

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#928372: ITP: golang-github-anacrolix-dms-dev -- a UPnP DLNA Digital Media Server that includes basic video transcoding

[Stephen Gelman]

> On Fri, 3 May 2019, Drew Parsons wrote:
> How important do you consider dlna support in rclone?

In a perfect world it would be nice but I don't think it necessarily
blocks updating it since it's a very new feature.  Maybe upload it
without then file a bug with severity wishlist?

Stephen

Bug#951812: ITP: golang-gopkg-jcmturner-rpc.v0 -- Remote Procedure Call libraries

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-gopkg-jcmturner-rpc.v0
  Version : 0.0.2-1
  Upstream Author : Jonathan Turner
* URL : https://github.com/jcmturner/rpc
* License : Apache-2.0
  Programming Lang: Go
  Description : Remote Procedure Call libraries

 A partial implementation that mainly focuses on unmarshaling NDR
 encoded byte streams into Go structures.

Dependency of new version of git-lfs

Bug#951813: ITP: golang-gopkg-jcmturner-gokrb5.v5 -- Pure Go Kerberos library for clients and services

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-gopkg-jcmturner-gokrb5.v5
  Version : 5.3.0-1
  Upstream Author : Jonathan Turner
* URL : https://github.com/jcmturner/gokrb5
* License : Apache-2.0
  Programming Lang: Go
  Description : Pure Go Kerberos library for clients and services

 Features
   - Pure Go - no dependency on external libraries
   - No platform specific code
   - Server Side
   - HTTP handler wrapper implements SPNEGO Kerberos authentication
   - HTTP handler wrapper decodes Microsoft AD PAC authorization data
   - Client Side
   - Client that can authenticate to an SPNEGO Kerberos authenticated web 
service
   - Ability to change client's password
   - General
   - Kerberos libraries for custom integration
   - Parsing Keytab files
   - Parsing krb5.conf files
   - Parsing client credentials cache files such as /tmp/krb5cc_$(id -u 
$(whoami))

Dependency of new version of git-lfs

Bug#951814: ITP: golang-gopkg-jcmturner-goidentity.v2 -- A golang library for managing identities

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-gopkg-jcmturner-goidentity.v2
  Version : 2.0.0-1
  Upstream Author : Jonathan Turner
* URL : https://github.com/jcmturner/goidentity
* License : Apache-2.0
  Programming Lang: Go
  Description : A golang library for managing identities

 Standard interface for holding authenticated identities and
 their attributes.

Dependency of new version of git-lfs

Bug#951811: ITP: golang-gopkg-jcmturner-dnsutils.v1 -- Golang library of DNS utilities

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-gopkg-jcmturner-dnsutils.v1
  Version : 1.0.1-1
  Upstream Author : Jonathan Turner
* URL : https://github.com/jcmturner/dnsutils
* License : Apache-2.0
  Programming Lang: Go
  Description : Golang library of DNS utilities

 A golang library of DNS utilities, mostly for the purposes of reading SRV
 records

Dependency of new version of git-lfs

Bug#951817: ITP: golang-gopkg-jcmturner-aescts.v1 -- AES CBC Ciphertext Stealing mode for Go

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-gopkg-jcmturner-aescts.v1
  Version : 1.0.1-1
  Upstream Author : Jonathan Turner
* URL : https://github.com/jcmturner/aescts
* License : Apache-2.0
  Programming Lang: Go
  Description : AES CBC Ciphertext Stealing mode for Go

 Golang library to encrypt and decrypt data using AES CBC Ciphertext stealing 
mode.

Dependency of new version of git-lfs

Bug#951816: ITP: golang-github-jcmturner-gofork -- forked and modified go standard libary packages to work around issues

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-jcmturner-gofork
  Version : 1.0.0-1
  Upstream Author : Jonathan Turner
* URL : https://github.com/jcmturner/gofork
* License : BSD-3-clause
  Programming Lang: Go
  Description : forked and modified go standard libary packages to work 
around issues

 This repository contains modified Go standard library packages
 for use as work arounds until issues are addressed in the official
 distribution.

Dependency of new version of git-lfs

Bug#951815: ITP: golang-github-dpotapov-go-spnego -- Wraps gokrb5 and sspi libraries to provide cross-platform way to make HTTP calls with Kerberos authentication

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-dpotapov-go-spnego
  Version : 0.0~git20190506.c2c6091-1
  Upstream Author : Daniel Potapov
* URL : https://github.com/dpotapov/go-spnego
* License : Expat
  Programming Lang: Go
  Description : Wraps gokrb5 and sspi libraries to provide cross-platform 
way to make HTTP calls with Kerberos authentication

 go-spnego The package extends Go's HTTP Transport allowing
 Kerberos authentication through Negotiate mechanism (see RFC4559
 (https://tools.ietf.org/html/rfc4559)).
 .
 Internally it is implemented by wrapping 2 libraries: gokrb5
 (https://github.com/jcmturner/gokrb5) on Linux and sspi
 (https://github.com/alexbrainman/sspi) on Windows.
 .
 There is no pre-authenticaion yet, so the library assumes you have
 Kerberos ticket obtained.
 .
 Linux implementation requires MIT or Heimdal Kerberos to be
 present. Windows implementation utilizes credentials of currently logged
 in user.
 .
 Currently it allows only to make HTTP calls, no server side support yet.

Dependency of new version of git-lfs

Bug#923819: golang-github-google-martian: FTBFS randomly (failing tests)

[Stephen Gelman]

> On Mar 5, 2019, at 1:09 PM, Santiago Vila  wrote:
> 
> Package: src:golang-github-google-martian
> Version: 2.1.0+git20181219.d0b5ad3-2
> Severity: important
> Tags: ftbfs
> 
> Dear maintainer:
> 
> I tried to build this package in buster but it failed:
> 
> …….
> 
> The failure happens randomly, i.e. sometimes it fails, sometimes it does not,
> so I don't have a "recipe" to reproduce it as such, but the "randomness"
> is reproducible in my autobuilders (i.e. when I build it a lot of times,
> there are always some failed builds).
> 
> I've put several failed build logs here for reference:
> 
> https://people.debian.org/~sanvila/build-logs/golang-github-google-martian/
> 
> If you need a test machine to reproduce this, please contact me
> privately and I could provide ssh access to a machine where it happens
> (caveat: randomly and maybe with low probability).
> 
> If this is really a bug in one of the build-depends, please use reassign and 
> affects,
> so that this is still visible in the BTS web page for this package.
> 
> Thanks.
> 

I’ve actually been able to reproduce this pretty reliably by just running the 
test on its own so I reported this upstream at 
https://github.com/google/martian/issues/282 
.  I’ll give them a few days to 
respond and if they don’t I’ll just disable the flaky test.

Stephen

Bug#1019856: ITP: golang-github-flytam-filenamify -- Convert a string to a valid safe filename on Golang

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-github-flytam-filenamify
  Version : 1.1.1-1
  Upstream Author : tanjiahui
* URL : https://github.com/flytam/filenamify
* License : Expat
  Programming Lang: Go
  Description : Convert a string to a valid safe filename

 Converts a string to a valid safe filename.

Package will be team maintained by the go team. A new dependency of termshark
2.4.0

Bug#1019859: ITP: golang-gitlab-jonas.jasas-condchan -- TODO

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: golang-gitlab-jonas.jasas-condchan
  Version : 0.0~git20190210.36637ad-1
  Upstream Author : Jonas Jasas
* URL : https://gitlab.com/jonas.jasas/condchan
* License : Expat
  Programming Lang: Go
  Description : Cancellable sync.Cond

 CondChan is a sync.Cond with the ability to wait in select statement.

 - Adds waiting in select statement feature
 - Implements all sync.Cond interface
 - Passes all sync.Cond tests
 - Implemented using channels
 - Just ~37% slower comparing to sync.Cond

This package will be team-maintaned. This is a dependency of termshark

Bug#1019867: ITP: qrterminal -- Display QR Codes in terminal

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: qrterminal
  Version : 3.0.0-1
  Upstream Author : Mark Percival
* URL : https://github.com/mdp/qrterminal
* License : Expat
  Programming Lang: Go
  Description : Display QR Codes in terminal

 A golang library for generating QR codes in the terminal.
 
 Originally this was a port of the NodeJS version. Recently it's been updated
 to allow for smaller code generation using ASCII 'half blocks'

This package will be team maintained by the go team. This is a dependency of
wormhole-william, which is in turn a dependency of termshark 4.2.0

Bug#1042415: ruby-aws-partitions: Package missing partitions.json

[Stephen Gelman]

Package: ruby-aws-partitions
Version: 1.653.0-1
Severity: grave
Tags: patch
Justification: renders package unusable
X-Debbugs-Cc: ssg...@debian.org

In version 1.653.0-1, 
/usr/share/rubygems-integration/all/gems/aws-partitions-1.653.0/partitions.json 
is not present. It is there in version 1.354.0-2 in bullseye. Without that 
file, any actual use of this gem fails:

$ irb
irb(main):001:0> require 'aws-partitions'
=> true
irb(main):002:1* Aws::Partitions.each do |partition|
irb(main):003:1*   puts partition.name
irb(main):004:0> end
/usr/share/rubygems-integration/all/gems/aws-partitions-1.653.0/lib/aws-partitions.rb:225:in
 `read': No such file or directory @ rb_sysopen - 
/usr/share/rubygems-integration/all/gems/aws-partitions-1.653.0/partitions.json 
(Errno::ENOENT)
from 
/usr/share/rubygems-integration/all/gems/aws-partitions-1.653.0/lib/aws-partitions.rb:225:in
 `defaults'
from 
/usr/share/rubygems-integration/all/gems/aws-partitions-1.653.0/lib/aws-partitions.rb:214:in
 `default_partition_list'
from 
/usr/share/rubygems-integration/all/gems/aws-partitions-1.653.0/lib/aws-partitions.rb:137:in
 `each'
from (irb):2:in `'
from /usr/lib/ruby/gems/3.1.0/gems/irb-1.4.1/exe/irb:11:in `'
from /usr/bin/irb:25:in `load'
from /usr/bin/irb:25:in `'

Patch to fix is attached


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

Kernel: Linux 6.3.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.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 ruby-aws-partitions depends on:
ii  ruby  1:3.1

ruby-aws-partitions recommends no packages.

ruby-aws-partitions suggests no packages.

-- no debconf information
diff -Nru ruby-aws-partitions-1.653.0/debian/changelog 
ruby-aws-partitions-1.653.0/debian/changelog
--- ruby-aws-partitions-1.653.0/debian/changelog2022-10-30 
08:49:35.0 -0500
+++ ruby-aws-partitions-1.653.0/debian/changelog2023-07-27 
17:39:10.0 -0500
@@ -1,3 +1,11 @@
+ruby-aws-partitions (1.653.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Change DH_RUBY_GEM_INSTALL_WHITELIST_APPEND to DH_RUBY_GEM_INSTALL_INCLUDE
+in debian/rules to work with newer gem2deb
+
+ -- Stephen Gelman   Thu, 27 Jul 2023 17:39:10 -0500
+
 ruby-aws-partitions (1.653.0-1) unstable; urgency=medium
 
   * Team Upload
diff -Nru ruby-aws-partitions-1.653.0/debian/rules 
ruby-aws-partitions-1.653.0/debian/rules
--- ruby-aws-partitions-1.653.0/debian/rules2022-10-30 08:49:35.0 
-0500
+++ ruby-aws-partitions-1.653.0/debian/rules2023-07-27 17:36:38.0 
-0500
@@ -2,7 +2,7 @@
 
 export GEM2DEB_TEST_RUNNER = --check-dependencies
 export DH_RUBY = --gem-install
-export DH_RUBY_GEM_INSTALL_WHITELIST_APPEND := partitions.json
+export DH_RUBY_GEM_INSTALL_INCLUDE := partitions.json
 
 %:
dh $@ --buildsystem=ruby --with ruby

Bug#793171: RFS: git-lfs/0.5.2-1 [ITP]

[Stephen Gelman]

Package: sponsorship-requests
Severity: wishlist

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

I am looking for a sponsor for my package "git-lfs"

 Package name: git-lfs
 Version : 0.5.2-1
 Upstream Author : Github
 URL : http://git-lfs.github.com
 License : Expat
 Section : vcs

It builds those binary packages:

  git-lfs- Git Large File Support

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

http://mentors.debian.net/package/git-lfs


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

  dget -x 
http://mentors.debian.net/debian/pool/main/g/git-lfs/git-lfs_0.5.2-1.dsc

More information about git-lfs can be obtained from http://git-lfs.github.com.


Regards,
 Stephen Gelman


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#792075: ITP: git-lfs -- Git Large File Support. An open source Git extension for versioning large files

[Stephen Gelman]

Package: wnpp
Severity: wishlist
Owner: Stephen Gelman 

* Package name: git-lfs
  Version : 0.5.2
  Upstream Author : Github
* URL : http://git-lfs.github.com/
* License : Expat
  Programming Lang: Golang
  Description : Git Large File Support.

An open source Git extension for versioning large files

I am looking to maintain this myself with a sponsor.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#792075: ITP: git-lfs -- Git Large File Support. An open source Git extension for versioning large files

[Stephen Gelman]

Github provides a reference implementation:

https://github.com/github/lfs-test-server 


I believe that qualifies it to go in main.  In addition the API is open source.

> On Jul 10, 2015, at 6:27 PM, Asheesh Laroia  wrote:
> 
> Hi Stephen! I'm excited to see this land in Debian.
> 
> I'm curious if you know if there a free software backend that is compatible 
> with the git-lfs protocol.​ If so, that'd be great to see in Debian as well 
> one day.
> 
> If not, if I understand Policy correctly, you would need to take care to set 
> the package's section to "contrib". See 
> https://www.debian.org/doc/debian-policy/ch-archive.html 
>  for more 
> information.
> 
> (As I understand policy, if there *is* a git-lfs compatible backend that is 
> free software, it's fine to have git-lfs in main, even if that backend isn't 
> currently available in Debian.)
> 
> Again, nice to see your enthusiasm, and I hope you can find a sponsor for 
> this package.

Bug#792075: ITP: git-lfs -- Git Large File Support. An open source Git extension for versioning large files

[Stephen Gelman]

Ian,

As it stands the package currently vendors its dependencies so they currently 
need to be split out into separate packages.  I haven’t confirmed recently, but 
last I checked none of them were in Debian already.  The package is also a few 
versions behind of upstream but that should be pretty easy to fix as nothing 
major has changed in the build process.  I will try and update the package soon 
and also package its dependencies.  Do I need to file an ITP for each one?

Thanks!

Stephen

> On May 19, 2016, at 6:46 AM, Ian Campbell  wrote:
> 
> Hi Stephen,
> 
> On Fri, 2015-07-10 at 19:35 -0500, Stephen Gelman wrote:
> 
> We are just about to start using git-lfs at work so I was wondering
> what the status of this ITP is? Looks like the RFS in #793171 was
> stalled due to the vendoring.
> 
> I've taken the liberty of also CCing the go packaging team.
> 
> Cheers,
> Ian.

Bug#792075: ITP: git-lfs -- Git Large File Support. An open source Git extension for versioning large files

[Stephen Gelman]

Great to hear!  I’ll try and take a stab at it as soon as I can.

> On May 19, 2016, at 8:09 AM, Ian Campbell  wrote:
> 
> On Thu, 2016-05-19 at 07:52 -0700, Stephen Gelman wrote:
>> Do I need to file an ITP for each one?
> 
> AIUI, yes, I was hoping pkg-go-maintainers might be able to advice but
> it seems I (and I pressume, you) cannot post there (subscribers ony I
> guess).
> 
> Good news is that it looks like about half the stuff in vendor/_nuts/*
> is now in Debian.
> 
> Ian.

Bug#793171: RFS: git-lfs/0.5.2-1 [ITP]

[Stephen Gelman]

Responses inline.  New package available at
http://mentors.debian.net/debian/pool/main/g/git-lfs/git-lfs_0.5.4-1.dsc.

On Mon, Aug 17, 2015 at 4:24 AM, Hugo Lefeuvre  wrote:
> Hi Stephen,
>
> Here are some remaining problems I'd like to see solved before sponsoring
> the package.
>
> (1) debian/control:
> ---
>
>   - Concerning git "(>= 1.8.0)": The version in jessie-backports is
> 2.1, so anyway this condition will be verified in case of a
> backport to stable. This condition would also be verified in case
> of a backport to oldstable since the version in wheezy-backports is
> 1.9.1.
>   - Concerning golang-go "(>= 1.3.0)": The version in jessie is
> 1.3.3, so anyway this condition will be verified in case of a
> backport to stable. This condition would also be verified in case
> of a backport to oldstable since the version in wheezy-backports is
> 1.3.3.
>
> FYI, the Release Team doesn't always accepts backports to stable.
> However, if the backport of your package is accepted, it will go
> to the jessie-backports archive[0].

I completely understand that.  My point was that I think it is
beneficial to keep the version requirements there in case someone
wants to backport it.  That way they will not run into unexpected
problems.  If you don't think that is beneficial I can remove it.

>
> (2) debian/changelog:
> -
>
>   - Why have you increased the debian revision number ? This package is
> the first debian release, so the complete package version number should
> be 0.5.4-1.
>   - Why have you made three changelog entries ? This package haven't
> been uploaded to the Debian archive so, only one entry is allowed.
>   - Usually, the changelog entry for an initial release looks like:
>
>   * Initial release. (Closes: ITPBUG)
>

I increased it as I was updating the package and publishing to
mentors.  In retrospect that was not necessary or correct.  I have
pushed 0.5.4-1 which incorporates all these changes.

> (3) debian/copyright:
> -
>
>   - Please, specify an e-mail adress after your name in the Copyright
> field of d/copyright, like so:
>
>   Files: debian/*
>   Copyright: 2015 Stephen Gelman 
>   License: Expat
>

Email added.

> Thanks !
>
> Regards,
>  Hugo
>
> [0] http://backports.debian.org/Contribute/
>
> --
>   Hugo Lefeuvre (hugo6390)|www.hugo6390.org
> 4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E

Bug#793171: RFS: git-lfs/0.5.2-1 [ITP]

[Stephen Gelman]

Hugo,

Sounds good.  New package uploaded in the same place 
(http://mentors.debian.net/debian/pool/main/g/git-lfs/git-lfs_0.5.4-1.dsc 
) 
with the new copyright file.  What are the next steps?

Stephen

> On Aug 19, 2015, at 11:13 AM, Hugo Lefeuvre  > wrote:
> 
> Hi Stephen,
> 
>>> (1) debian/control:
>>> ---
>>> 
>>>  - Concerning git "(>= 1.8.0)": The version in jessie-backports is
>>>2.1, so anyway this condition will be verified in case of a
>>>backport to stable. This condition would also be verified in case
>>>of a backport to oldstable since the version in wheezy-backports is
>>>1.9.1.
>>>  - Concerning golang-go "(>= 1.3.0)": The version in jessie is
>>>1.3.3, so anyway this condition will be verified in case of a
>>>backport to stable. This condition would also be verified in case
>>>of a backport to oldstable since the version in wheezy-backports is
>>>1.3.3.
>>> 
>>> FYI, the Release Team doesn't always accepts backports to stable.
>>> However, if the backport of your package is accepted, it will go
>>> to the jessie-backports archive[0].
>> 
>> I completely understand that.  My point was that I think it is
>> beneficial to keep the version requirements there in case someone
>> wants to backport it.  That way they will not run into unexpected
>> problems.  If you don't think that is beneficial I can remove it.
> 
> Anyway, I'm nitpicking. Let it if you want.
> 
> I've made a new review of your package and I've found a last problem 
> in your d/copyright file: The Expat license paragraph is malformed. 
> I've attached a correct version.
> 
> Regards,
> Hugo
> 
> -- 
>  Hugo Lefeuvre (hugo6390)|www.hugo6390.org 
> 
> 4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E
>