Bug#1068230: automatic suspend regression with gnome-settings-daemon 46

[Pirate Praveen]

Package: gnome-settings-daemon,phosh
severity: serious

Recently automatic suspend stopped working. I think this was after 
gnome settings daemon 46 was available. Some background



Not sure if phosh needs some adjustments with recent changes in gnome 
settings daemon. For now assigned to both.


On kde plasma mobile, automatic suspend still works, so this appears to 
be gnome specific regression.

Bug#1025084: ruby-graphlient fails to rebuild after updating ruby-faraday to upstream

[Pirate Praveen]

Control: fixed -1 0.7.0-1

On Wed, 7 Feb 2024 14:03:34 +0530 Praveen Arimbrathodiyil 
 wrote:

Control: severity -1 serious

On Sun, 18 Jun 2023 13:14:21 +0530 Pirate Praveen 
 wrote:
> 
> Since ruby-faraday-middleware is deprecated, we should update to 
> graphlient 0.7

ruby-faraday 2 is in unstable now.


Fixed in ruby-graphlient 0.7.0

Bug#1063654: ruby-graphql-errors - upstream dead and incompatible with ruby-graphql 2.x

[Pirate Praveen]

Package: ruby-graphql-errors
Version:  0.4.0-2
Severity: serious

source package has 1 unsatisfiable build dependency

Build dependencies in unstable cannot be satisfied on amd64 
because: unsatisfied dependency on ruby-graphql (< 2)


Last commint was 4 years ago and 
https://github.com/exAspArk/graphql-errors has a banner "This repository 
has been archived by the owner on Apr 8, 2020. It is now read-only."


This was originally packaged as build dependency for ruby-graphlient 
which no longer needs it.

Bug#1052730: ruby-delayed-job: FTBFS: ERROR: Test "ruby3.1" failed: ArgumentError:

[Pirate Praveen]

Control: forwarded -1 
https://github.com/collectiveidea/delayed_job/pull/1203


On Tue, 26 Sep 2023 14:40:49 +0200 Lucas Nussbaum  wrote:


Relevant part (hopefully):
>  ArgumentError:
>Invalid Timezone: US/Eastern


Forwarded fix upstream 
https://github.com/collectiveidea/delayed_job/pull/1203

Bug#1063478: gem2deb rails assets smoke test should handle links or skip the test during build

[Pirate Praveen]

Control: severity -1 important

On 9/2/24 6:48 PM, Pirate Praveen wrote:
Without libjs-underscore in build depends, the test should fail, but it 
is passing.


ruby-rails-assets-underscore source package includes underscore.js and 
it is replaced by symlink to libjs-underscore only in dh_install stage 
so rake assets:precompile can still find it.


So it looks like gem2deb test is working as expected, but we still need 
to figure out a way out for symlinks. May be we should just link them in 
the build target itself as a solution. If that is the recommended 
solution, we can close this bug with a note in dh_ruby documentation.

Bug#1060658: [Debian-on-mobile-maintainers] Bug#1060658: megapixels don't start could not find any config file

[Pirate Praveen]

On 16/01/24 10:01 pm, Arnaud Ferraris wrote:

Hi,

Le 12/01/2024 à 10:37, Pirate Praveen a écrit :

Package: megapixels
Version: 1.7.0-1
Severity: grave

Running megapixels from commandline on mobian trixie fails with this error

/usr/share/megapixels/config/purism,librem5r4.ini not found.


This is expected, megapixels doesn't support the L5 (yet?).


I was looking at a blog post for QR code readers and mega pixel was 
mentioned


https://forums.puri.sm/t/qr-code-scanning-via-megapixels/14408

Found another reference now https://blog.brixit.nl/megapixels-2-0/

but seems this never finished.

Bug#1060658: megapixels don't start could not find any config file

[Pirate Praveen]

Package: megapixels
Version: 1.7.0-1
Severity: grave

Running megapixels from commandline on mobian trixie fails with this 
error


/usr/share/megapixels/config/purism,librem5r4.ini not found.

Bug#958682: node-jsonld: Remove dependency to node-request

[Pirate Praveen]

On Sun, 29 Oct 2023 21:37:08 +0100 Jonas Smedegaard  wrote:

Yes, I still want to work on node-jsonld - I will make time to look at
this soon...


yarnpkg 4.0.2 was recently uploaded to unstable, so this and 
node-matrix-js-sdk are the only remaining reverse dependencies for 
node-request. We have an ack from its maintainer to remove it 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958692#42 so this is 
the only real blocker remaining to remove node-request.

Bug#1058596: yarnpkg broken on bookworm - yarnpkg --help fails with TypeError: commander.on is not a function

[Pirate Praveen]

Package: yarnpkg
Version: 1.22.19+~cs24.27.18-2
severity: grave
justification: breaks any options passed to yarnpkg

yarnpkg install also fails with similar errors due to incompatible 
node-commander


We should backport the patches in unstable to bookworm as well.

# cat /usr/share/nodejs/yarn-error.log
Arguments:
  /usr/bin/node /usr/bin/yarnpkg --help

PATH:
  /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Yarn version:
  1.22.19

Node version:
  18.13.0

Platform:
  linux x64

Trace:
  TypeError: commander.on is not a function
  at Object.run (/usr/share/nodejs/yarn/lib/cli/commands/help.js:75:13)
  at run (/usr/share/nodejs/yarn/lib/cli/index.js:494:30)
  at /usr/share/nodejs/yarn/lib/cli/index.js:732:24

npm manifest:
  No manifest

yarn manifest:
  No manifest

Lockfile:
  No lockfile


# yarnpkg --frozen-lockfile install
TypeError: _commander(...).default.optionFor is not a function
at /usr/share/nodejs/yarn/lib/cli/index.js:355:88
at Array.findIndex ()
at _callee$ (/usr/share/nodejs/yarn/lib/cli/index.js:352:38)
at tryCatch 
(/usr/share/nodejs/@babel/runtime/helpers/regeneratorRuntime.js:44:17)
at Generator. 
(/usr/share/nodejs/@babel/runtime/helpers/regeneratorRuntime.js:125:22)
at Generator.next 
(/usr/share/nodejs/@babel/runtime/helpers/regeneratorRuntime.js:69:21)
at asyncGeneratorStep 
(/usr/share/nodejs/@babel/runtime/helpers/asyncToGenerator.js:3:24)
at _next 
(/usr/share/nodejs/@babel/runtime/helpers/asyncToGenerator.js:22:9)

at /usr/share/nodejs/@babel/runtime/helpers/asyncToGenerator.js:27:7
at new Promise ()

Bug#1056298: riseup-vpn dns configuration don't work with systemd-resolved

[Pirate Praveen]

package: riseup-vpn
severity: grave
version: 0.21.11+ds1-5+b4

It misses a dependency on openvpn-systemd-resolved and on boomworm it 
was working after installing it. But on mobian trixie, which has 
systemd-resolved installed by default (through mobian-base), dns 
resolution fails when riseup vpn is connected.


error log attached



;; communications error to 127.0.0.53#53: timed out
;; communications error to 127.0.0.53#53: timed out
;; no servers could be reached

Bug#1055880: kaidan missing two dependencies

[Pirate Praveen]

Package: kaidan
version: 0.9.1-1
severity: grave
justification: fails to start

Though fix is easy, missing dependencies are

qml-module-org-kde-kquickimageeditor and
qml-module-org-kde-kirigami-addons-labs-mobileform

After installing these manually, kaidan starts as expected.

Bug#958692: node-matrix-js-sdk: Remove dependency to node-request

[Pirate Praveen]

On 2/11/23 10:27 PM, Hubert Chathi wrote:

On Sun, 29 Oct 2023 22:43:55 +0530, Praveen Arimbrathodiyil 
 said:


On Fri, 24 Apr 2020 13:52:39 +0200 y...@debian.org wrote:

Upstream has deprecated node-request:
https://github.com/request/request/issues/3142 It can be replaced by
node-got



Hi Jonas, Hubert,



Are you planning to update matrix-js-sdk? We'd like to remove
deprecated node-request from the archive and this package is a
blocker.


I don't currently have time to update matrix-js-sdk.  Feel free to
remove it from testing so that it doesn't block anything else.  I can
always upload a new version later.



This is already not in testing for 525 days. We can't remove a package 
from the archive if any package (build) depends on it.

Bug#1042967: nheko crashes on first launch in arm64 (librem 5)

[Pirate Praveen]

Package: nheko
Version: 0.11.3-2+b1
severity: grave
justification: makes the app unusable

I initially noticed this on mobian bookworm (then I switched to 
chatty). Now I can reliable reproduce it on trixie as well.


Crash log attached.

To reproduce rm -rf .local/share/nheko .config/nheko .cache/nheko
and run nheko from terminal

First noticed when I reinstalled, flatpack also fails same way so looks 
like an upstream issue.


Second time, nheko starts but initial sync never completes. Both chatty 
and gomuks works with same matrix id.


[2023-08-03 17:42:55.678] [ui] [info] Restoring window size 0x0
[2023-08-03 17:42:55.759] [ui] [info] WebRTC: initialised GStreamer 1.22.4
[2023-08-03 17:42:55.883] [ui] [info] jdenticon plugin not found.
[2023-08-03 17:42:57.976] [ui] [info] starting nheko 0.11.3
[2023-08-03 17:42:57.986] [ui] [info] Unity service available: false
Error: signal 11:
nheko(_Z17stacktraceHandleri+0x40)[0xd55ee940]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0xa06be7ac]
nheko(+0x973940)[0xd5433940]
nheko(+0x977090)[0xd5437090]
nheko(+0x9783bc)[0xd54383bc]
/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0(+0x55270)[0x9da25270]
/lib/aarch64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x148)[0x9d83a6c8]
/lib/aarch64-linux-gnu/libglib-2.0.so.0(+0x5aaa0)[0x9d83aaa0]
/lib/aarch64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x34)[0x9d83ab44]
/lib/aarch64-linux-gnu/libQt5Core.so.5(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x54)[0x9deef6d8]
/lib/aarch64-linux-gnu/libQt5Core.so.5(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x13c)[0x9de89d2c]
/lib/aarch64-linux-gnu/libQt5Core.so.5(_ZN16QCoreApplication4execEv+0x98)[0x9de933f8]
nheko(main+0xd14)[0xd526b684]
/lib/aarch64-linux-gnu/libc.so.6(+0x26dc0)[0x9d2a6dc0]
/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98)[0x9d2a6e98]
nheko(_start+0x30)[0xd526c770]
Error: signal 6:
nheko(_Z17stacktraceHandleri+0x40)[0xd55ee940]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0xa06be7ac]
/lib/aarch64-linux-gnu/libc.so.6(+0x7fd30)[0x9d2ffd30]
/lib/aarch64-linux-gnu/libc.so.6(gsignal+0x1c)[0x9d2b9e2c]
nheko(_Z17stacktraceHandleri+0xd8)[0xd55ee9d8]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0xa06be7ac]
nheko(+0x973940)[0xd5433940]
nheko(+0x977090)[0xd5437090]
nheko(+0x9783bc)[0xd54383bc]
/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0(+0x55270)[0x9da25270]
/lib/aarch64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x148)[0x9d83a6c8]
/lib/aarch64-linux-gnu/libglib-2.0.so.0(+0x5aaa0)[0x9d83aaa0]
/lib/aarch64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x34)[0x9d83ab44]
/lib/aarch64-linux-gnu/libQt5Core.so.5(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x54)[0x9deef6d8]
/lib/aarch64-linux-gnu/libQt5Core.so.5(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x13c)[0x9de89d2c]
/lib/aarch64-linux-gnu/libQt5Core.so.5(_ZN16QCoreApplication4execEv+0x98)[0x9de933f8]
nheko(main+0xd14)[0xd526b684]
/lib/aarch64-linux-gnu/libc.so.6(+0x26dc0)[0x9d2a6dc0]
/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98)[0x9d2a6e98]
nheko(_start+0x30)[0xd526c770]

Bug#1030932: golang-github-go-enry-go-license-detector: FTBFS on mipsel: test failures

[Pirate Praveen]

Control: fixed -1 4.3.0+git20221007.a3a1cc6-3

On Thu, 13 Jul 2023 23:49:56 +0800 Shengjing Zhu  
wrote:

> You look at the wrong log, it's golang-github-hhatto-gorst, not
> golang-github-go-enry-go-license-detector.
> It FTBFS on buildd currently.

After increasing the timeout to 150m, the build is now succeeding on 
armel and mipsel.


https://buildd.debian.org/status/fetch.php?pkg=golang-github-go-enry-go-license-detector=armel=4.3.0%2Bgit20221007.a3a1cc6-3=1689278197=0

https://buildd.debian.org/status/fetch.php?pkg=golang-github-go-enry-go-license-detector=mipsel=4.3.0%2Bgit20221007.a3a1cc6-3=1689281650=0

Bug#1030932: golang-github-go-enry-go-license-detector: FTBFS on mipsel: test failures

[Pirate Praveen]

On Thu, Jul 13 2023 at 11:49:56 PM +08:00:00 +08:00:00, Shengjing Zhu 
 wrote:

Control: reopen -1



Thanks, I noticed the failure on buildd and was going to reopen it and 
found you did it aready.



Hi,

On Thu, Jul 13, 2023 at 6:09 PM Pirate Praveen 
 wrote:


 On Thu, 9 Feb 2023 14:40:48 +0100 Sebastian Ramacher
  wrote:
  > Source: golang-github-go-enry-go-license-detector
  > Version: 4.3.0+git20221007.a3a1cc6-1
  > Severity: serious
  > Tags: ftbfs
  > Justification: fails to build from source (but built 
successfully in

 the past)
  >
  >
 
https://buildd.debian.org/status/fetch.php?pkg=golang-github-go-enry-go-license-detector=mipsel=4.3.0%2Bgit20221007.a3a1cc6-1%2Bb2=1675941345=0

  >

 This looks like a temporary error, last build was passing

 
https://buildd.debian.org/status/fetch.php?pkg=golang-github-hhatto-gorst=mipsel=0.0%7Egit20181029.ca9f730-2%2Bb6=1681037294=0


You look at the wrong log, it's golang-github-hhatto-gorst, not
golang-github-go-enry-go-license-detector.
It FTBFS on buildd currently.



Thanks for pointing out the mistake. I was looking at both failures and 
got confused.

--
Shengjing Zhu

Bug#1030955: golang-github-hhatto-gorst: autopkgtest failure

[Pirate Praveen]

On Thu, 13 Jul 2023 21:24:53 +0530 Nilesh Patra  
wrote:

> Control: tags -1 patch
>
> On Thu, Jul 13, 2023 at 03:10:40PM +0530, Pirate Praveen wrote:
> > On Fri, 10 Feb 2023 00:07:51 +0200 Adrian Bunk  
wrote:
> > > The Ubuntu diff contains a patch that looks like a workaround 
(untested).

> >
> > This patch says data directory is reserved for golang autopkgtest 
in Ubuntu.
> > Is this the same on debian too? If yes, that looks like a bad idea 
to me.

>
> AFAIK, it uses the standard AUTOPKGTEST_TMP directory which is the
> standard across debian. I got the same impression on skimming through
> dh-golang code.
>
> As far as fix for your package is concerned, it is as simple as 
avoiding
> to remove entire data directory (which is just 28K in size). I'm 
able to get

> autopkgtests passing locally. Patch pasted
> inline.

Thanks. I guess I was over enthusiastic to suppress

I: golang-github-hhatto-gorst-dev: 
package-contains-documentation-outside-usr-share-doc 
[usr/share/gocode/src/github.com/hhatto/gorst/data/autopep8.readme.rst]


and did not notice the autopkgtest failure then.

I'm uploading the fix you suggested.

Bug#1030955: golang-github-hhatto-gorst: autopkgtest failure

[Pirate Praveen]

On Fri, 10 Feb 2023 00:07:51 +0200 Adrian Bunk  wrote:
> The Ubuntu diff contains a patch that looks like a workaround 
(untested).


This patch says data directory is reserved for golang autopkgtest in 
Ubuntu. Is this the same on debian too? If yes, that looks like a bad 
idea to me.

Bug#1034565: fixed in 0.23

[Pirate Praveen]

Control: fixed -1 0.23.1-3

Bug#1034565: ftbfs tests fail on ppc64el and mips64el

[Pirate Praveen]

On Tue, 18 Apr 2023 17:08:34 +0530 Pirate Praveen  
wrote:

> Failures:
>
>1) Prometheus::Client::Helper::MmapedFile file does not exist 
creates

> a file with minimum initial size
>   Failure/Error: expect(File.size(subject.filepath)).to
> eq(subject.send(:initial_mmap_file_size))
>
> expected: 4096
>  got: 16384
>
> (compared using ==)
>   # ./spec/prometheus/client/helpers/mmaped_file_spec.rb:30:in
> `block (3 levels) in '

Fixed upstream in 0.20 and 0.23 is being uploaded to experimental. We 
can close this once we confirm the failures are fixed.

Bug#1039916: ruby-derailed-benchmarks: autopkgtest needs update for new version of ruby-memory-profiler: Could not find 'memory_profiler' (~> 0)

[Pirate Praveen]

On Thu, 29 Jun 2023 16:03:13 +0200 Paul Gevers  
wrote:


> 
┌──┐

>   19s │ Checking Rubygems dependency resolution on ruby3.1
>  │
>   19s
> 
└──┘

>   19s  19s GEM_PATH= ruby3.1 -e gem\ \"derailed_benchmarks\"
>   19s /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in
> `rescue in block in activate_dependencies': Could not find
> 'memory_profiler' (~> 0) among 102 total gem(s) 
(Gem::MissingSpecError)

>   19s Checked in

This is fixed upstream but the new upstream version adds a new 
dependency dead_end gem. Also gitlab has moved this dependency from 
production to test group in Gemfile, so we can remove this once the 
dependency is dropped from gitlab.

Bug#1033705: golang-gitaly-proto: autopkgtest regression: test dependency ruby-gitaly-proto doesn't exist

[Pirate Praveen]

On Thu, 30 Mar 2023 19:19:44 +0200 Paul Gevers  
wrote:

> autopkgtest [15:18:15]: test command1: preparing testbed
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Correcting dependencies...Starting pkgProblemResolver with broken 
count: 1

> Starting 2 pkgProblemResolver with broken count: 1
> Investigating (0) autopkgtest-satdep:amd64 < 0 @iU K Nb Ib >
> Broken autopkgtest-satdep:amd64 Depends on ruby-gitaly-proto:amd64 <
> none @un H >
>Removing autopkgtest-satdep:amd64 because I can't find
> ruby-gitaly-proto:amd64

ruby-gitaly-proto used to be provided by ruby-gitaly binary package 
built from this source package. But ruby-gitaly binary package is now 
built from gitaly source package which does not provide 
ruby-gitaly-proto.


This was originally packaged as a dependency of gitlab-shell, which no 
longer need golang-gitaly-proto-dev build dependency.


So we can remove this package. I will file an rm request once the build 
dependency is removed from gitlab-shell in unstable.

Bug#1039915: ruby-benchmark-memory: autopkgtest needs update for new version of ruby-memory-profiler: Could not find 'memory_profiler' (~> 0.9)

[Pirate Praveen]

Control: fixed -1 0.2.0-1

On Thu, 29 Jun 2023 16:01:57 +0200 Paul Gevers  
wrote:

> Currently this regression is blocking the migration of
> ruby-memory-profiler to testing [1]. Of course, ruby-memory-profiler
> shouldn't just break your autopkgtest (or even worse, your package), 
but
> it seems to me that the change in ruby-memory-profiler was intended 
and

> your package needs to update to the new situation.

ruby-benchmark-memory 0.2.0-1 was ready in experimental, but missed a 
reupload to unstable. I'm reuploading it to unstable now.

Bug#1040405: ruby-gollum-lib: incompatible with newer ruby-rouge

[Pirate Praveen]

On Wed, 5 Jul 2023 16:44:31 +0200 Gianfranco Costamagna 
 wrote:

> Can you please have a look?

We no longer need ruby-gollum-lib for gitaly, so requested removal of 
ruby-gollum-lib in #1040461.

Bug#1037409: golang-golang-x-exp ftbfs with gccgo-go (both gccgo-12 and gccgo-13)

[Pirate Praveen]

Package: src:golang-golang-x-exp
Version: 0.0~git20221028.83b7d23-2
Severity: serious

Building with golang-any changed to gccgo-go to force gccgo on amd64, 
build fails with error. Full build log attached. Either this should be 
fixed or dependency should be updated to golang-go instead of golang-any.


golang.org/x/exp/maps
# golang.org/x/exp/maps
src/golang.org/x/exp/maps/maps.go:10:10: error: expected ‘(’
   10 | func Keys[M ~map[K]V, K comparable, V any](m M) []K {
  |  ^
src/golang.org/x/exp/maps/maps.go:10:13: error: invalid character 0x7e 
in input file

   10 | func Keys[M ~map[K]V, K comparable, V any](m M) []K {
  | ^
src/golang.org/x/exp/maps/maps.go:11:9: error: expected ‘]’
   11 | r := make([]K, 0, len(m))
  | ^
src/golang.org/x/exp/maps/maps.go:11:9: error: expected ‘;’ or newline 
after top level declaration

src/golang.org/x/exp/maps/maps.go:12:9: error: expected declaration
   12 | for k := range m {
  | ^
src/golang.org/x/exp/maps/maps.go:14:9: error: expected declaration
   14 | }
  | ^
src/golang.org/x/exp/maps/maps.go:15:9: error: expected declaration
   15 | return r
  | ^
src/golang.org/x/exp/maps/maps.go:16:1: error: expected declaration
   16 | }
  | ^
sbuild (Debian sbuild) 0.85.2 (11 March 2023) on mahishi

+===+
| golang-golang-x-exp 0.0~git20221028.83b7d23-2 (amd64) Mon, 12 Jun 2023 
12:47:20 + |
+===+

Package: golang-golang-x-exp
Version: 0.0~git20221028.83b7d23-2
Source Version: 0.0~git20221028.83b7d23-2
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-24a3fad7-52f9-45d5-ba4b-67774cece214'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/golang-golang-x-exp-PqPMEI/resolver-ugb2fS' with '<>'

+--+
| Update chroot|
+--+

Hit:1 http://deb.debian.org/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/home/pravi/forge/go-team/golang-golang-x-exp_0.0~git20221028.83b7d23-2.dsc 
exists in /home/pravi/forge/go-team; copying to chroot
I: NOTICE: Log filtering will replace 
'build/golang-golang-x-exp-PqPMEI/golang-golang-x-exp-0.0~git20221028.83b7d23' 
with '<>'
I: NOTICE: Log filtering will replace 'build/golang-golang-x-exp-PqPMEI' with 
'<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper-compat (= 13), dh-sequence-golang, gccgo-go (>= 
2:1.18~), gccgo-13, build-essential, fakeroot
Filtered Build-Depends: debhelper-compat (= 13), dh-sequence-golang, gccgo-go 
(>= 2:1.18~), gccgo-13, build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [609 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [670 B]
Get:5 copy:/<>/apt_archive ./ Packages [702 B]
Fetched 1981 B in 0s (0 B/s)
Reading package lists...
Reading package lists...

Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  autoconf automake autopoint autotools-dev bsdextrautils cpp-13 debhelper
  dh-autoreconf dh-golang dh-strip-nondeterminism dwz file gcc-13 gccgo-12
  gccgo-13 gccgo-go gettext gettext-base groff-base intltool-debian
  libarchive-zip-perl libdebhelper-perl libelf1
  libfile-stripnondeterminism-perl libgcc-13-dev libgo-12-dev libgo-13-dev
  libgo21 libgo22 libhwasan0 libicu72 libmagic-mgc libmagic1 libpipeline1
  libsub-override-perl libtool libuchardet0 libxml2 m4 man-db po-debconf
  sensible-utils
Suggested packages:
  autoconf-archive 

Bug#1021583: golang-gitlab-gitlab-org-labkit: FTBFS (test failure): gitlab.com/gitlab-org/labkit/metrics/http_round_tripper

[Pirate Praveen]

Control: fixed -1 1.17.0-1

On Tue, 11 Oct 2022 13:24:32 +0200 Cyril Brulebois  
wrote:

> Source: golang-gitlab-gitlab-org-labkit
> Version: 1.16.0-1
> Severity: serious
> Justification: FTBFS
>
> Hi,
>
> While preparing an update for the golang-github-gin-gonic-gin 
package,

> I noticed golang-gitlab-gitlab-org-labkit FTBFSes within unstable
> (with or without the updated golang-github-gin-gonic-gin package).
>

1.17.0-1 in experimental builds fine. I'm reuploading it to unstable.

Bug#1034996: libomemo0: missing Breaks+Replaces for libomemo-dev when upgrading from bullseye

[Pirate Praveen]

On Thu, 27 Apr 2023 14:59:11 +0200 Helmut Grohne  
wrote:

> Package: libomemo0
> Version: 0.8.1-1
> Severity: serious
> Justification: dpkg unpack error
>
> Attempting to unpack libomemo0/0.8.1-1 from Debian bookworm
> on a minimal Debian bullseye with libomemo-dev/0.7.0-1
> installed, causes an unpack error from dpkg due to
> /usr/lib/x86_64-linux-gnu/libomemo.so being contained in both 
packages.

>
> | (Reading database ... 12426 files and directories currently 
installed.)

> | Preparing to unpack ./libomemo0_0.8.1-1_amd64.deb ...
> | Unpacking libomemo0:amd64 (0.8.1-1) over (0.7.0-1) ...
> | dpkg: error processing archive ./libomemo0_0.8.1-1_amd64.deb 
(--unpack):
> |  trying to overwrite '/usr/lib/x86_64-linux-gnu/libomemo.so', 
which is also in package libomemo-dev:amd64 0.7.0-1

> | Processing triggers for libc-bin (2.31-13+deb11u5) ...
> | Errors were encountered while processing:
> |  ./libomemo0_0.8.1-1_amd64.deb
>
>
> Please ensure that libomemo0 has sufficient Breaks and Replaces 
declarations.

>
> Helmut
>
>

I could add the Breaks and Replaces, but looks like moving .so link out 
of -dev package is wrong as per lintian warning.


W: libomemo0: lacks-unversioned-link-to-shared-library example: 
usr/lib/x86_64-linux-gnu/libomemo.so 
[usr/lib/x86_64-linux-gnu/libomemo.so.0.8.1]
W: libomemo0: link-to-shared-library-in-wrong-package 
usr/lib/x86_64-linux-gnu/libomemo.so.0.8.1 
[usr/lib/x86_64-linux-gnu/libomemo.so]


This was moved to libomemo-dev in commit 
6ebca2f07eed072226503432b6149e671341f2c4 Should we move back 
libomemo.so to libomemo-dev ?

Bug#1034565: ftbfs tests fail on ppc64el and mips64el

[Pirate Praveen]

Package: ruby-prometheus-client-mmap
Version: 0.17.0+spec-1
Severity: serious
Control: forwarded -1 
https://gitlab.com/gitlab-org/ruby/gems/prometheus-client-mmap/-/issues/43


Version in testing is not affected as we did not have tests enabled.

Failures:

  1) Prometheus::Client::Helper::MmapedFile file does not exist creates 
a file with minimum initial size
 Failure/Error: expect(File.size(subject.filepath)).to 
eq(subject.send(:initial_mmap_file_size))


   expected: 4096
got: 16384

   (compared using ==)
 # ./spec/prometheus/client/helpers/mmaped_file_spec.rb:30:in 
`block (3 levels) in '


  2) Prometheus::Client::MmapedDict#initialize empty mmap'ed file is 
initialized with correct size
 Failure/Error: expect(File.size(tmp_file.path)).to 
eq(tmp_mmaped_file.send(:initial_mmap_file_size))


   expected: 4096
got: 16384

   (compared using ==)
 # ./spec/prometheus/client/mmaped_dict_spec.rb:19:in `block (4 
levels) in '


  3) Prometheus::Client::MmapedDict#initialize mmap'ed file that is 
above minimum size is initialized with the a page size

 Failure/Error: expect(tmp_file.size).to eq(4096);

   expected: 4096
got: 16384

   (compared using ==)
 # ./spec/prometheus/client/mmaped_dict_spec.rb:34:in `block (4 
levels) in '


Full build logs 
https://buildd.debian.org/status/fetch.php?pkg=ruby-prometheus-client-mmap=ppc64el=0.19.1-1=1681745611=0 
https://buildd.debian.org/status/fetch.php?pkg=ruby-prometheus-client-mmap=mips64el=0.19.1-1=1681745649=0


Forwarded upstream at 
https://gitlab.com/gitlab-org/ruby/gems/prometheus-client-mmap/-/issues/43


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034230: fail2ban: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Pirate Praveen]

Control: tags -1 patch

On Tue, 11 Apr 2023 15:43:51 +0200 Andreas Henriksson 
 wrote:

> Wrong path is used at:
> https://sources.debian.org/src/fail2ban/1.0.2-1/debian/rules/#L50
>
> Note that the path will likely change again in the future, so rather
> than hard-coding a path please consider finding the path via:
> pkg-config --variable=systemdsystemunitdir systemd
>
> (Note: you'll need to build-dep on pkg-config and systemd, for
> systemd.pc)
>
> Regards,
> Andreas Henriksson
>
>

Attaching a patch, the git repo seems to be in an inconsistent 
state/diverged from the archive.


diff --git a/debian/control b/debian/control
index fe386199..0b8c5421 100644
--- a/debian/control
+++ b/debian/control
@@ -13,6 +13,8 @@ Build-Depends:
  , python3-pyinotify
  , sqlite3
  , 2to3
+ , pkg-config
+ , systemd
 Homepage: https://www.fail2ban.org
 Vcs-Git: https://salsa.debian.org/python-team/packages/fail2ban.git
 Vcs-Browser: https://salsa.debian.org/python-team/packages/fail2ban
diff --git a/debian/rules b/debian/rules
index a2dd769c..3c0391ef 100755
--- a/debian/rules
+++ b/debian/rules
@@ -16,7 +16,7 @@ export PYBUILD_DISABLE_python2=1
 
 DESTDIR=$(CURDIR)/debian/fail2ban
 PYVERSION=$(shell py3versions -dv)
-
+SYSTEMD_SYSTEM_UNIT_DIR = $(shell pkg-config --variable=systemdsystemunitdir systemd)
 override_dh_clean:
 	rm -rf fail2ban.egg-info
 	-rm debian/fail2ban.init
@@ -45,11 +45,11 @@ override_dh_install:
 	install -d $(DESTDIR)/usr/share/bash-completion/completions
 	install -m 644 files/bash-completion $(DESTDIR)/usr/share/bash-completion/completions/fail2ban
 	: # Install systemd files
-	install -d $(DESTDIR)/usr/lib/systemd/system/
+	install -d $(DESTDIR)$(SYSTEMD_SYSTEM_UNIT_DIR)
 	install -d $(DESTDIR)/usr/lib/tmpfiles.d
-	install -m 644 build/fail2ban.service $(DESTDIR)/usr/lib/systemd/system
+	install -m 644 build/fail2ban.service $(DESTDIR)$(SYSTEMD_SYSTEM_UNIT_DIR)
 	install -m 644 files/fail2ban-tmpfiles.conf $(DESTDIR)/usr/lib/tmpfiles.d
-	install -d $(DESTDIR)/usr/lib/systemd/system
+	install -d $(DESTDIR)$(SYSTEMD_SYSTEM_UNIT_DIR)
 	: # Install default jail enabler
 	install -m 644 debian/debian-files/jail.d_defaults-debian.conf $(DESTDIR)/etc/fail2ban/jail.d/defaults-debian.conf
 	dh_install

Bug#1031716: Generating stricter dependencies on python3-protobuf rdeps

[Pirate Praveen]

On Tue, 7 Mar 2023 12:09:35 +0200 Adrian Bunk  wrote:
> 2. packages using python3-protobuf (e.g. python3-bernhard) ship files
>that were generated with protobuf-compiler during their build
>(e.g. /usr/lib/python3/dist-packages/bernhard/pb.py )

Can this generation be moved to postinst and use a dpkg trigger to 
regenerate it when protobuf is updated?


An example is 
https://sources.debian.org/src/node-constants-browserify/1.0.0%2Bdfsg-8/debian/postinst/


Though it would mean runtime dependency on protobuf-compiler.

Bug#999726: ruby-omniauth-shibboleth: FTBFS with ruby-omniauth 2.0.x: ERROR: Test "ruby2.7" failed: Failure/Error: expect(last_response.status).to eq(302)

[Pirate Praveen]

On Tue, 10 May 2022 01:14:01 +0530 Mohd Bilal  
wrote:

> If you feel there's any other
> workaround for this please suggest. The upstream hasn't been active 
and

> I dont think they'll have new version anytime soon

as discussed in 
https://git.fosscommunity.in/debian-ruby/TaskTracker/-/issues/192#note_9797 
we can remove dependency on omniauth-shibboleth from gitlab and request 
removal from archive.


Removing the dependency here 
https://salsa.debian.org/ruby-team/gitlab/-/commit/a7773b9ac08a3c341982129c201d3a254f4561cb


I will file ROM shortly.

Bug#1019643: ruby-omniauth-oauth2-generic: FTBFS with ruby3.1: ERROR: Test "ruby3.0" failed: Failure/Error: expect(last_response.headers["Location"]).to match(%r{redirect_uri=https%3A%2F%2Fmy_se

[Pirate Praveen]

Control: forwarded -1 
https://gitlab.com/satorix/omniauth-oauth2-generic/-/issues/37


On Mon, 12 Sep 2022 22:08:30 -0300 Antonio Terceiro 
 wrote:
> We are about to start the ruby3.1 transition in unstable. While 
trying to

> rebuild ruby-omniauth-oauth2-generic with ruby3.1 enabled, the build
> failed. This does not look related to ruby3.1 though, as the failure
> happens yet at the ruby3.0 tests.

This looks like a test only failure as gitlab confirmed everything 
works with ruby 3.0 here 
https://gitlab.com/gitlab-org/gitlab/-/issues/386908


The upstream seems inactive though, still reported as 
https://gitlab.com/satorix/omniauth-oauth2-generic/-/issues/37

Bug#980316: Update on packaging corepack

[Pirate Praveen]

On Tue, Mar 21 2023 at 09:06:41 PM +01:00:00 +01:00:00, Paul Gevers 
 wrote:

Hi Pirate,

Thanks for reaching out.

On 20-03-2023 16:44, Pirate Praveen wrote:

I request bookworm-ignore tags for these bugs (as such there is
no immediate breakage, just unmaintained upstreams for these 
packages).


> yarnpkg: 980316,958686, 1002902, 980316
> node-har-validator: 1024575
> node-request: 956423
> node-request-capture-har: 1002901

As the packages in question are key packages, we can't easily remove
them. Hence adding a bookworm-ignore tag doesn't really change the
situation in bookworm in any way. Hence, the question is whether 
fixing

it now and adding an exception is better or worse than letting the bug
ship in bookworm. If I understand correctly, than the required change
would mean a new complex package (corepack) which (again, if I
understand correctly) is considered also by you as inappropriate at 
this

time. If you confirm my understanding, I agree that those bugs can be
marked bookworm-ignore (I already marked them as bookworm-can-defer,
which is less strong and less official).


We won't be able to complete corepack in a few weeks or months. So we 
have to ship bookworm with these bugs and get this fixed in time for 
trixie.




Paul

Bug#980316: Update on packaging corepack

[Pirate Praveen]

On Thu, 16 Mar 2023 10:23:53 +0100 Israel Galadima 
 wrote:

> Hi,
>
> Michael and I have done some packaging work for corepack.
> Of note, we have updated clipanion and packaged some dependencies of
> proxy-agent.
>
> Although, some of our work is awaiting uploads because of the freeze.
>
> Regards.

We tried to update yarnpkg as part of an outreachy project (in two 
rounds), but we could not complete it in time for bookworm. As shared 
by Israel, we made some good progress and we hope to be able to do it 
in trixie. I request bookworm-ignore tags for these bugs (as such there 
is no immediate breakage, just unmaintained upstreams for these 
packages). Hopefully we can handle any security updates ourselves.


Additionally, even though yarnpkg itself is old, the presence of the 
package makes it easy to obtain a newer yarnpkg. In gitlab, I already 
use the packaged yarnpkg command to install a newer yarnpkg[1]. It is 
also very common in nodejs world to use specific version of yarnpkg for 
each project, these are typically installed in .yarn directory for each 
project.


yarnpkg: 980316,958686, 1002902, 980316
node-har-validator: 1024575
node-request: 956423
node-request-capture-har: 1002901

[1] 
https://salsa.debian.org/ruby-team/gitlab/-/blob/master/debian/rake-tasks.sh#L44

runuser -u ${gitlab_user} -- sh -c 'yarnpkg set version berry'

Bug#1031441: Potential RM candidate ?

[Pirate Praveen]

On Mon, 13 Mar 2023 23:17:02 +0530 Mohd Bilal  
wrote:

> Hello,
>
> The upstream[1] for ruby-github-api has been inactive for over 2 
years

> now and this is affecting other packages like ruby-oauth2[2] and
> ruby-faraday[3] from migrating.
>
> $ reverse-depends -b ruby-github-api
> Reverse-Build-Depends
> * ruby-jeweler
>
> $ reverse-depends -b ruby-jeweler
> No reverse dependencies found
>
> So should we remove these 2 packages ? or as a workaround we could 
relax
> the versions in Gemfile to actually fix this bug since the Debian 
source

> doesn't ship the upstream test suite.

I think we can remove these two packages.

Bug#1032048: d3-dsv-tools: Dangling symlinks in /usr/bin/

[Pirate Praveen]

On Mon, 27 Feb 2023 00:51:52 +0100 Axel Beckert  wrote:
> Package: d3-dsv-tools
> Version: 1.1.1-8
> Severity: grave
> Justification: renders package unusable
>
> $ symlinks -tv /usr/bin* | fgrep dangling
> dangling: /usr/bin/csv2json -> ../share/nodejs/d3-dsv/bin/dsv2json.js
> dangling: /usr/bin/csv2tsv -> ../share/nodejs/d3-dsv/bin/dsv2dsv.js
> dangling: /usr/bin/dsv2dsv -> ../share/nodejs/d3-dsv/bin/dsv2dsv.js
> dangling: /usr/bin/json2csv -> ../share/nodejs/d3-dsv/bin/json2dsv.js
> dangling: /usr/bin/json2dsv -> ../share/nodejs/d3-dsv/bin/json2dsv.js
> dangling: /usr/bin/tsv2csv -> ../share/nodejs/d3-dsv/bin/dsv2dsv.js
> dangling: /usr/bin/json2tsv -> ../share/nodejs/d3-dsv/bin/json2dsv.js
> dangling: /usr/bin/dsv2json -> ../share/nodejs/d3-dsv/bin/dsv2json.js
> dangling: /usr/bin/tsv2json -> ../share/nodejs/d3-dsv/bin/dsv2json.js
>
> Looking at where those files actually might be, I figured that the
> symlinks probably should point to the same target without the .js
> suffix — or that those files need to be renamed:
>
> /usr/share/nodejs/d3-dsv/bin/dsv2dsv
> /usr/share/nodejs/d3-dsv/bin/dsv2json
> /usr/share/nodejs/d3-dsv/bin/json2dsv

debian/nodejs/links should be modified to drop the .js suffix.



since master branch is used for experimental, a new branch for bookworm 
should be created from debian/1.1.1-8 tag


> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (600, 'testing')
> merged-usr: yes
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not 
set

> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> LSM: AppArmor: enabled
>
> Versions of packages d3-dsv-tools depends on:
> ii  node-d3-dsv  1.1.1-8
> ii  nodejs   18.13.0+dfsg1-1
>
> d3-dsv-tools recommends no packages.
>
> d3-dsv-tools suggests no packages.
>
> -- no debconf information
>
>

Bug#1029523: ruby-net-http-persistent want Ruby (~> 2.1)

[Pirate Praveen]

Control: severity -1 important

On Thu, 23 Feb 2023 21:33:31 +0100 Paul Gevers  
wrote:

> Hi,
>
> On Tue, 24 Jan 2023 00:21:06 +0530 Pirate Praveen
>  wrote:
> >   net-http-persistent (~> 3.0, >= 3.0.0) was resolved to 3.1.0,
> > which depends on
> > Ruby (~> 2.1)
>
> This doesn't seem to be an issue on reproducible builds [1] when
> building ruby-faraday. Does that make sense?

Only bundler or rubygems checks this dependency requirement. It might 
just work fine on ruby 3.1. For now the easiest fix was to update to 
4.0 (for gitlab, where this bug appeared - in gitlab postinst, we use 
bundle install --local to verify all dependency requirements are 
satisfied), in which upstream has removed this constraint. May be we 
can ignore it for now (lowered the severity, as gitlab is not in 
bookworm).

Bug#1016732: [Pkg-javascript-devel] Bug#1016732: Please help to reproduce (Was: shiny-server: server-function? don't run)

[Pirate Praveen]

On ഞാ, ഫെബ്രു 26 2023 at 02:33:31 രാവിലെ 
+05:30:00 +05:30:00, Pirate Praveen  wrote:



On ഞാ, ഫെബ്രു 26 2023 at 02:24:00 രാവിലെ 
+05:30:00 +05:30:00, Nilesh Patra  wrote:

On Sun, Feb 26, 2023 at 12:46:15AM +0530, Pirate Praveen wrote:
Thanks for the pointer. However, unfortunately even after propagating
the "-t" flag with coffee, the generated code does not work to fine 
(the

UI is not functional).

For now I have vendored coffee1 generated code itself. Do you have 
any

other ideas?


I can see we are using rollup to generate iife format files, which 
may not be what npm dist tarball ships.


https://salsa.debian.org/js-team/node-sockjs/-/blob/master/debian/rules#L8

Upstream directly uses the output from coffee 
https://salsa.debian.org/js-team/node-sockjs/-/blob/master/Makefile#L9


You could play around with rollup output format options I think. Try 
umd format or try using webpack. You will have to inspect the npm 
dist tarball to see what format it has. Copying Akshay if he has some 
ideas.


Since we are using only lib directory in node, ignore the rollup part 
above. In sockjs 0.4 rc1 they removed coffee script dependency, so one 
thing we can try is to see if sockjs 0.4 rc1 works with shiny-server, 
though getting a new upstream version to bookworm may be a hard thing, 
but it may be a better option that vendoring what we have right now.

Bug#1016732: Please help to reproduce (Was: shiny-server: server-function? don't run)

[Pirate Praveen]

On ഞാ, ഫെബ്രു 26 2023 at 02:24:00 രാവിലെ 
+05:30:00 +05:30:00, Nilesh Patra  wrote:

On Sun, Feb 26, 2023 at 12:46:15AM +0530, Pirate Praveen wrote:
Thanks for the pointer. However, unfortunately even after propagating
the "-t" flag with coffee, the generated code does not work to fine 
(the

UI is not functional).

For now I have vendored coffee1 generated code itself. Do you have any
other ideas?


I can see we are using rollup to generate iife format files, which may 
not be what npm dist tarball ships.


https://salsa.debian.org/js-team/node-sockjs/-/blob/master/debian/rules#L8

Upstream directly uses the output from coffee 
https://salsa.debian.org/js-team/node-sockjs/-/blob/master/Makefile#L9


You could play around with rollup output format options I think. Try 
umd format or try using webpack. You will have to inspect the npm dist 
tarball to see what format it has. Copying Akshay if he has some ideas.

Bug#1016732: Please help to reproduce (Was: shiny-server: server-function don't run)

[Pirate Praveen]

On Sun, 12 Feb 2023 23:16:06 +0530 Nilesh Patra  
wrote:
> Sorry for pinging you again, but would you be able to take a look at 
this please?

> I don't know enough coffeescript to be able to check this and it'd be
> awesome if you could consider taking a look.

Coffeescript 2 creates ESM format js by default, adding -t option to 
coffee command should give you the old ES5 javascript like coffeescript 
1.x


See 
https://salsa.debian.org/js-team/node-sockjs/-/blob/master/Makefile#L11

Bug#1030873: ruby-coffee-script is deprecated, please remove the dependency

[Pirate Praveen]

Package: ruby-jekyll-coffeescript
Version: 1.2.2-3
severity: serious
Control: block 1019927 by -1

ruby-coffee-script is deprecated #1019927 and we are trying to remove 
it from bookworm.


coffee command line provided by coffeescript package still works (and 
using node version via webpack is recommended by rails), so using that 
could be an option, or alternatively if ruby-coffee-script is still 
useful, someone will need to take over the upstream maintenance.

Bug#1030870: Drop unneeded dependency on ruby-coffee-script

[Pirate Praveen]

Package: tdiary-core
Version: 5.2.3-1
Severity: serious
Justification: ruby-coffee-script is deprecated and we want to remove 
it in bookworm

Control: block 1019927 by -1

ruby-coffee-script is deprecated (#1019927) and we'd like to remove it 
from bookworm (this and ruby-jekyll-coffeescript are the lats two 
packages still depending on ruby-coffee-script).


It looks 
https://salsa.debian.org/ruby-team/tdiary/-/blob/master/tdiary.gemspec 
does not list ruby-coffee-script, so it should be easy to drop it from 
Depends.


If you really want to use coffeescript in this package, you can still 
use the coffee command line (which also supports -t option to generate 
ES5 output, which is no longer the default in coffeescript 2).

Bug#1019927: Remove ruby-coffee-script - deprecated upstream

[Pirate Praveen]

On Fri, 16 Sep 2022 16:38:52 +0530 Pirate Praveen 
 wrote:
> As per upstream [1], this project is deprecated and last release was 
on
>  Apr 7, 2015 (7 years ago), so I think we should try to remove it 
from

> bookworm, but if we can't get there close to freeze, we can ask for
> bookworm-ignore or lower severity.

Current list of dependencies (with dependencies removed from ruby-blade 
and ruby-hamlit):

Reverse-Depends
===
* ruby-jekyll-coffeescript
* tdiary-core

Reverse-Build-Depends
=
* ruby-sprockets

Bug#1019924: Remove build dependency on ruby-blade

[Pirate Praveen]

Control: rettile -1 remove ruby-coffee-script* dependencies
Control: reassign -1 src:ruby-blade

On Fri, 16 Sep 2022 16:13:41 +0530 Pirate Praveen 
 wrote:

> Package: src:rails
> Version: 2:6.1.7+dfsg-1
> Severity: important
> Control: forwarded -1 https://github.com/rails/rails/pull/45546
>
> ruby-blade depends on now deprecated ruby-coffee-script and rails is
> only reverse build dependency of ruby-blade. Upstream has already 
moved

> to rollup, filing this to track progress of ruby-blade removal.

An alternate solution here is to drop ruby-coffee-script and 
ruby-coffee-script-source dependencies from ruby-blade as rails 
switched to using coffee commandline (provided by coffeescript/node 
package).

Bug#1005628: add fixed version info

[Pirate Praveen]

Control: fixed -1 5.2.0+dfsg-2

Bug#981878: ruby-gitlab-pg-query downloads from the internet during the build

[Pirate Praveen]

On Tue, 22 Feb 2022 21:16:22 +0100 Paul Gevers  
wrote:

> Hi Pirate,
>
> On Sun, 07 Mar 2021 00:47:46 +0530 Pirate Praveen
>  wrote:
> > Once ruby-pg-query is accepted
> > and its reverse dependencies switch to the new package, I will 
request

> > removal of this package.
>
> What's the status on this?

ruby-gitlab-pg-query can be removed now. ruby team will soon file RM 
requests for packages we don't want to keep in the archives. 
https://lists.debian.org/debian-ruby/2023/02/msg00010.html has the list.


> Paul
> PS: please CC, I'm not subscribed

Bug#1019927: Remove ruby-coffee-script - deprecated upstream

[Pirate Praveen]

May be with rails 7.1, we may be able to remove coffee_script
https://github.com/rails/rails/issues/46292#issuecomment-1332882941

Bug#1029523: there is a new upstream major version that relaxes ruby requirement

[Pirate Praveen]

so updating to 4.0.1 could fix this
https://github.com/drbrain/net-http-persistent/blob/75574f2546a08aa2663b06a2e005bcf2ee304f13/Rakefile#L16

Bug#1029523: ruby-net-http-persistent want Ruby (~> 2.1)

[Pirate Praveen]

Package: ruby-net-http-persistent
Severity: grave
Justification: unable to install gitlab or use with bundler

Just add this to Gemfile.
gem "telesign"

and run,
bundle install --local
Don't run Bundler as root. Bundler can ask for sudo if it is needed, 
and installing your bundle as root will

break this application for all non-root users on this machine.
[DEPRECATED] This Gemfile does not include an explicit global source. 
Not using an explicit global source may result in a different lockfile 
being generated depending on the gems you have installed locally before 
bundler is run. Instead, define a global source in your Gemfile like 
this: source "https://rubygems.org;.

Resolving dependencies...
Bundler found conflicting requirements for the Ruby version:
 In Gemfile:
   Ruby

   telesign was resolved to 2.2.3, which depends on
 net-http-persistent (~> 3.0, >= 3.0.0) was resolved to 3.1.0, 
which depends on

   Ruby (~> 2.1)


This comes from the gemspec
https://salsa.debian.org/ruby-team/ruby-net-http-persistent/-/blob/master/net-http-persistent.gemspec#L23

Bug#1029459: hp-plugin crashes when trying to download plugin with error NameError: name 'get_distro_std_name' is not defined. Did you mean: 'get_distro_name'?

[Pirate Praveen]

Control: severity -1 important

On Mon, Jan 23 2023 at 04:57:16 PM +00:00:00 +00:00:00, Brian Potkin 
 wrote:

On Mon 23 Jan 2023 at 01:39:46 +0530, Pirate Praveen wrote:


 Package: hplip
 Version: 3.22.10+dfsg0-1
 Severity: grave
 Justification: makes it unusable

 $ hp-plugin

 HP Linux Imaging and Printing System (ver. 3.22.10)
 Plugin Download and Install Utility ver. 2.1

 Copyright (c) 2001-18 HP Development Company, LP
 This software comes with ABSOLUTELY NO WARRANTY.
 This is free software, and you are welcome to distribute it
 under certain conditions. See COPYING file for more details.


 HP Linux Imaging and Printing System (ver. 3.22.10)
 Plugin Download and Install Utility ver. 2.1

 Copyright (c) 2001-18 HP Development Company, LP
 This software comes with ABSOLUTELY NO WARRANTY.
 This is free software, and you are welcome to distribute it
 under certain conditions. See COPYING file for more details.

 QSocketNotifier: Can only be used with threads started with QThread
 Checking for network connection...
 Downloading plug-in from:
 Traceback (most recent call last):
   File "/usr/share/hplip/ui5/plugindialog.py", line 248, in
 NextButton_clicked
 status, download_plugin_file, error_str =
 
self.pluginObj.download(self.plugin_path,self.plugin_download_callback)


 
^^^
   File "/usr/share/hplip/installer/pluginhandler.py", line 257, in 
download

 core = core_install.CoreInstall()
^^
   File "/usr/share/hplip/installer/core_install.py", line 240, in 
__init__

 self.passwordObj = password.Password(ui_mode)
^^
   File "/usr/share/hplip/base/password.py", line 94, in __init__
 self.__readAuthType()  # self.__authType
 ^
   File "/usr/share/hplip/base/password.py", line 119, in 
__readAuthType

 distro_name = get_distro_std_name(os_name)
   ^^^
 NameError: name 'get_distro_std_name' is not defined. Did you mean:
 'get_distro_name'?
 Aborted


Thank you for you report, Pirate Praveen.

My attempt with

  sh -i hplip-3.22.10-plugin.run

failed over an ssh link. This is an upstream issue.
get_distro_std_name is not used in hplip-3.22.6.
Please report at

  https://bugs.launchpad.net/hplip/+bugs



If you are already familiar with launchpad, can you file it?


I would query the severity of grave rather than
imortant. Plugin files can be installed with

  sh hplip--plugin.run --tar vxf
  python3 installPlugin.py



Lowered severity to important. Though we probably have to document it 
somewhere more visible until this is fixed.



Regards,

Brian.

Bug#964607: Massive update necessary

[Pirate Praveen]

On Thu, 25 Nov 2021 18:54:24 +0100 Daniel Leidert  
wrote:
> This gem is out-of-date. Upstream is at 3.2.2, which requires 
packaging for
> google-cloud-translate-v2 and google-cloud-translate-v3 and updating 
google-

> cloud-core to >= 1.6. The tests require packageing google-style.

This is a leaf package, likely packaged for loomio. I think we can 
ignore this for bookworm. May be we should use a usertag to mark such 
packages which can ignore rc bugs for bookworm (it could be useful in 
future if loomio packaging is revived, since upstream is still active, 
we can probably keep it in unstable).

Bug#1029459: manually editing the file fixes the issue

[Pirate Praveen]

after replacing get_distro_std_name(os_name) with get_distro_name() in 
/usr/share/hplip/base/password.py


the plugin got installed


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029459: after downloading the plugin manually and trying to install, it still fails

[Pirate Praveen]

Downloaded from 
https://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/


$ ./hplip-3.22.10-plugin.run
Verifying archive integrity...  100%   All good.
Uncompressing HPLIP 3.22.10 Plugin Self Extracting Archive  100%

HP Linux Imaging and Printing System (ver. 3.22.10)
Plugin Installer ver. 3.0

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Plug-in version: 3.22.10
Installed HPLIP version: 3.22.10
Number of files to install: 64

note: Using PyQt5
QSocketNotifier: Can only be used with threads started with QThread
Traceback (most recent call last):
  File "/tmp/selfgz92927/./plugin_install.py", line 276, in 
ok = installPlugin()
 ^^^
  File "/tmp/selfgz92927/./plugin_install.py", line 85, in installPlugin
passwordObj = password.Password(mode)
  ^^^
  File "/usr/share/hplip/base/password.py", line 94, in __init__
self.__readAuthType()  # self.__authType
^
  File "/usr/share/hplip/base/password.py", line 119, in __readAuthType
distro_name = get_distro_std_name(os_name)
  ^^^
NameError: name 'get_distro_std_name' is not defined. Did you mean: 
'get_distro_name'?


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029459: hp-plugin crashes when trying to download plugin with error NameError: name 'get_distro_std_name' is not defined. Did you mean: 'get_distro_name'?

[Pirate Praveen]

Package: hplip
Version: 3.22.10+dfsg0-1
Severity: grave
Justification: makes it unusable

$ hp-plugin

HP Linux Imaging and Printing System (ver. 3.22.10)
Plugin Download and Install Utility ver. 2.1

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.


HP Linux Imaging and Printing System (ver. 3.22.10)
Plugin Download and Install Utility ver. 2.1

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

QSocketNotifier: Can only be used with threads started with QThread
Checking for network connection...
Downloading plug-in from:
Traceback (most recent call last):
  File "/usr/share/hplip/ui5/plugindialog.py", line 248, in 
NextButton_clicked
status, download_plugin_file, error_str = 
self.pluginObj.download(self.plugin_path,self.plugin_download_callback)


^^^
  File "/usr/share/hplip/installer/pluginhandler.py", line 257, in download
core = core_install.CoreInstall()
   ^^
  File "/usr/share/hplip/installer/core_install.py", line 240, in __init__
self.passwordObj = password.Password(ui_mode)
   ^^
  File "/usr/share/hplip/base/password.py", line 94, in __init__
self.__readAuthType()  # self.__authType
^
  File "/usr/share/hplip/base/password.py", line 119, in __readAuthType
distro_name = get_distro_std_name(os_name)
  ^^^
NameError: name 'get_distro_std_name' is not defined. Did you mean: 
'get_distro_name'?

Aborted



OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020913: looks like a temporary issue during ruby 3.1 transition

[Pirate Praveen]

Control: fixed -1 2.2.0-1

likely caused by ruby-google-protobuf in experimental not being rebuilt 
with ruby 3.1. This built fine in buildd after ruby-google-protobuf was 
reuploaded to unstable.

Bug#1028730: fixed in last upload and built on buildd

[Pirate Praveen]

Control: fixed -1 1.7.0+dfsg-6

Bug#1005631: new restriction in rubygems: installing symlink pointing to parent path not allowed - causes ruby-handlebars-assets to ftbfs

[Pirate Praveen]

On Fri, 03 Jun 2022 21:52:17 +0530 Pirate Praveen 
 wrote:

> May be we can copy during build and replace it by symlink in install?

This fixes the earlier issue, but now some tests fail

# Running:

..E.E..E

Finished in 18.138080s, 1.5437 runs/s, 2.4810 assertions/s.

 1) Error:
HandlebarsAssets::HamlbarsTest#test_render_haml:
ArgumentError: wrong number of arguments (given 2, expected 0..1)
   /usr/lib/ruby/vendor_ruby/temple/engine.rb:44:in `initialize'
   
/<>/lib/handlebars_assets/handlebars_template.rb:106:in 
`new'
   
/<>/lib/handlebars_assets/handlebars_template.rb:106:in 
`choose_engine'
   /<>/lib/handlebars_assets/handlebars_template.rb:26:in 
`prepare'

   /usr/lib/ruby/vendor_ruby/tilt/template.rb:99:in `initialize'
   /<>/test/handlebars_assets/hamlbars_test.rb:23:in `new'
   /<>/test/handlebars_assets/hamlbars_test.rb:23:in 
`test_render_haml'


 2) Error:
HandlebarsAssets::HandlebarsTemplateTest#test_multiple_frameworks_with_ember_render:
ArgumentError: wrong number of arguments (given 2, expected 0..1)
   /usr/lib/ruby/vendor_ruby/temple/engine.rb:44:in `initialize'
   
/<>/lib/handlebars_assets/handlebars_template.rb:106:in 
`new'
   
/<>/lib/handlebars_assets/handlebars_template.rb:106:in 
`choose_engine'
   /<>/lib/handlebars_assets/handlebars_template.rb:26:in 
`prepare'

   /usr/lib/ruby/vendor_ruby/tilt/template.rb:99:in `initialize'
   
/<>/test/handlebars_assets/tilt_handlebars_test.rb:14:in 
`new'
   
/<>/test/handlebars_assets/tilt_handlebars_test.rb:14:in 
`render_it'
   
/<>/test/handlebars_assets/shared/adapter_tests.rb:191:in 
`test_multiple_frameworks_with_ember_render'


 3) Error:
HandlebarsAssets::HandlebarsProcessorTest#test_multiple_frameworks_with_ember_render:
ArgumentError: wrong number of arguments (given 2, expected 0..1)
   /usr/lib/ruby/vendor_ruby/temple/engine.rb:44:in `initialize'
   
/<>/lib/handlebars_assets/handlebars_template.rb:106:in 
`new'
   
/<>/lib/handlebars_assets/handlebars_template.rb:106:in 
`choose_engine'
   /<>/lib/handlebars_assets/handlebars_template.rb:64:in 
`call'
   /<>/lib/handlebars_assets/handlebars_template.rb:49:in 
`call'
   
/<>/test/handlebars_assets/handlebars_processor_test.rb:14:in 
`render_it'
   
/<>/test/handlebars_assets/shared/adapter_tests.rb:191:in 
`test_multiple_frameworks_with_ember_render'


28 runs, 45 assertions, 0 failures, 3 errors, 0 skips
rake aborted!
Command failed with status (1)

Bug#1028201: riseup-vpn unable to find a usable polkit agent under phosh

[Pirate Praveen]

Package: riseup-vpn,phosh
severity: grave

On mobian under phosh (librem 5), riseup-vpn gives error.
output of riseup-vpn attached.

phosh provides polkit-1-auth-agent

phosh 0.23
riseup-vpn 0.21.11+ds1-2+b1

No systray icon available.
qml: flavor: riseup-vpn
QSystemTrayIcon::setVisible: No Icon set
QObject::connect: No such signal QPlatformNativeInterface::systemTrayWindowChanged(QScreen*)
2023/01/08 18:44:03 Client expects anon auth
2023/01/08 18:44:03 Checking for updates...
qml: delay...
2023/01/08 18:44:14 Get "https://downloads.leap.se/RiseupVPN/linux/lastver": net/http: TLS handshake timeout
2023/01/08 18:44:14 Fetching MOTD for riseup.net
2023/01/08 18:44:16 There are 4 pending messages
2023/01/08 18:44:16 firewall stop
2023/01/08 18:44:17 Fetching gateways...
2023/01/08 18:44:17 Cannot find any usable polkit
2023/01/08 18:44:17 ERROR: no polkit
qml: errors, setting root.error
qrc:/components/InitErrors.qml:39: ReferenceError: splashSpinner is not defined
qrc:/components/InitErrors.qml:38:13: QML PropertyChanges: Cannot assign to non-existent property "visible"
qml: errors, setting root.error
qml: errors, setting root.error
2023/01/08 18:44:38 Close: cleanup and vpn shutdown...
2023/01/08 18:44:38 firewall stop
2023/01/08 18:44:38 openvpn stop

Catched signal(2): quitting

Bug#1024627: Acknowledgement (gitlab: Fails to install)

[Pirate Praveen]

On Tue, Nov 22 2022 at 02:39:40 PM +01:00:00 +01:00:00, Kurt Roeckx 
 wrote:
fasttrack contains a 1.7.3 version that's new enough. The 1.8.0 
version

from backports is too new it seems, and it what gets installed when
you just do: apt install gitlab



Some of the version requirements for omniauth-oauth2 is too strict, 
which should be fixed. But as a workaround, you can install 1.7.3 
version, till we fix this properly.

Bug#1021265: golang-github-libgit2-git2go ftbfs with libgit2 1.5

[Pirate Praveen]

Package: golang-github-libgit2-git2go
Version: 33.0.9-2
Severity: serious
Control: forwarded -1 https://github.com/libgit2/git2go/pull/929

This is also seen in autopkgtest failure 
https://ci.debian.net/data/autopkgtest/unstable/amd64/g/golang-github-libgit2-git2go/26651971/log.gz


Upstream recently merged https://github.com/libgit2/git2go/pull/929 and 
hopefully they will release a new version.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021113: libgrpc22 in experimental needs a rebuild with newer libabsl

[Pirate Praveen]

Package: libgrpc22
Severity: serious
Version: 1.44.0-3

Setting up sbuild-build-depends-dose3-dummy (0.invalid.0) ...
(I)Doseparse: Parsing and normalizing...
(I)Dose_deb: Parsing Packages file -...
(I)Dose_common: total packages 69949
(I)Dose_applications: Cudf Universe: 69949 packages
(I)Dose_applications: --checkonly specified, consider all packages as 
background packages

(I)Dose_applications: Solving...
output-version: 1.2
native-architecture: amd64
report:
-
 package: sbuild-build-depends-main-dummy
 version: 0.invalid.0
 architecture: amd64
 status: broken
 reasons:
  -
   missing:
pkg:
 package: libgrpc22
 version: 1.44.0-3
 architecture: amd64
 unsat-dependency: libabsl20210324:amd64 (>= 0~20210324.2-1)
depchains:
 -
  depchain:
   -
package: sbuild-build-depends-main-dummy
version: 0.invalid.0
architecture: amd64
depends: ruby-grpc:amd64 (>= 1.42~)
   -
package: ruby-grpc
version: 1.44.0-3
architecture: amd64
depends: libgrpc22:amd64 (>= 1.44.0)

background-packages: 69948
foreground-packages: 1
total-packages: 69949

Bug#1015302: Upgrading 14.10.5 to 15.0.4 aborts on db:migrate

[Pirate Praveen]

2022, ജൂലൈ 19 12:05:37 PM GMT+02:00, "Patrick Matthäi" ൽ 
എഴുതി
>Package: gitlab
>Version: 15.0.4+ds1-1
>Severity: serious
>
>Hey,
>
>on upgrading gitlab I always end up with this error:
>
>(1055 rows) = Did not find any relations. ]
>+ echo gitlab_production database is not empty, skipping gitlab setup
>gitlab_production database is not empty, skipping gitlab setup
>+ runuser -u gitlab -- sh -c /usr/bin/bundle exec rake db:migrate
>Attention: used pure ruby version of MurmurHash3
>/usr/share/gitlab/lib/gitlab.rb:47: warning: already initialized constant 
>Gitlab::APP_DIRS_PATTERN
>/usr/share/gitlab/lib/gitlab.rb:47: warning: previous definition of 
>APP_DIRS_PATTERN was here
>/usr/share/gitlab/lib/gitlab.rb:48: warning: already initialized constant 
>Gitlab::VERSION
>/usr/share/gitlab/lib/gitlab.rb:48: warning: previous definition of VERSION 
>was here
>/usr/share/gitlab/lib/gitlab.rb:49: warning: already initialized constant 
>Gitlab::INSTALLATION_TYPE
>/usr/share/gitlab/lib/gitlab.rb:49: warning: previous definition of 
>INSTALLATION_TYPE was here
>/usr/share/gitlab/lib/gitlab.rb:50: warning: already initialized constant 
>Gitlab::HTTP_PROXY_ENV_VARS
>/usr/share/gitlab/lib/gitlab.rb:50: warning: previous definition of 
>HTTP_PROXY_ENV_VARS was here
>== 20220213103859 RemoveIntegrationsType: migrating ===
>rake aborted!
>StandardError: An error has occurred, all later migrations canceled:
>

On two of my test machines, it was successful. May be you can try running the 
migration manually with --trace option.

gitlab-rake db:migrate --trace

May be ask upstream as well.

Bug#995722: Not running tests because tests miss source code is not useful

[Pirate Praveen]

On വെ, ഒക്ടോ 8 2021 at 10:31:16 രാവിലെ +0200 
+0200, Thomas Goirand  wrote:

On 10/7/21 11:40 AM, Pirate Praveen wrote:



 On 7 October 2021 3:02:55 am IST, Thomas Goirand  
wrote:

 On 10/6/21 6:53 PM, Pirate Praveen wrote:

 [adding -devel]

 On ബു, ഒക്ടോ 6 2021 at 12:16:07 വൈകു +0200 
+0200, Jonas Smedegaard

  wrote:

 Quoting Yadd (2021-10-06 11:43:40)

  On Lu, 04 oct 21, 16:40:48, Bastien Roucari�s wrote:
  > Source: src:node-lodash
  > Version: 4.17.21+dfsg+~cs8.31.173-1
  > Severity: serious
  > Justification: do not compile from source
  >
  > Dear Maintainer,
  >
  > The vendor directory should be emptied
  >
  > The debug version is compiled without source (lintian warn) 
and

 moreover the
  > rest of file are already packaged
  >
  > grep -R vendor * gives only a few hit that could be cured by
 symlinking
  >
  > Bastien
  Hi,

  this files are used for test only, maybe severity could be 
decreased.


 I find the severity accurate: Relying on non-source code is a 
severe
 violation of Debian Policy, not matter the purpose of relying on 
it.


 I think we should change the policy here. Running tests helps 
improve
 the quality of the software we ship. Many times the vendored code 
is
 used to ensure the code does not break in a specific situation. I 
don't

 think reducing test coverage in such situations is really helpful.


 Right, running tests helps improve the quality of software we ship.
 Which is why you probably need to test using what's shipped in 
Debian

 rather than using a vendored source-less code.


 We are not shipping the source less code.


You are: Debian also ships source code.


I meant, not shipping in any binary package. Though as Russ mentioned 
in his reply. I will propose a GR.


 This is used only during tests. I don't think we are not gaining 
anything by removing tests here. Just making it harder for the 
package maintainer to run tests.


You would not gain anything by removing tests, but you would win by
making these tests completely free software.


I am just saying it increases the work required to run tests and when 
disabling tests is an option, the incentive is to disable tests.


 If we rely on non-free code for tests, that's really bad too, and 
that
 must be avoided just like we're avoiding source-less code 
everywhere

 else in Debian. The policy shall not change, please.



 The code is not non-free here, just a specific version of a Free 
Software code built outside Debian.


We build from source...


We build the binary packages from source. I don't think it is useful to 
extend that to tests without considering the tradeoffs involved.


 I think tools required for tests should be considered separately 
from tools required to compile. I think it should be treated similar 
to test data.


I don't agree.


ok, lets see how the whole project feels via a GR and settle it. I just 
expressed my opinion, you expressed yours and we need to make a 
decision now.


 What you are proposing would require the package maintainer to 
adapt these tests to versions available (many times with different 
API versions) in Debian and the easier choice is disabling tests.


No. I believe it's ok to have an embedded version of the JS files in 
the
upstream code. This is a *very* different issue, please do not mix 
them.

What I don't like is using a minified version of the JS files. That's
*very* easy (hum... trivial?) to add a non-minified version in your
Debian folder, and use that for tests. You don't care if running the
tests is a little bit slower (because using a source-full version), 
do you?


I don't think you really understand the complexities here. Building the 
minified version is not just running the minifier against the non 
minified code. The non minified code itself is generated using many 
other tools (typescript, transpiled using babel, bundled using rollup 
or webpack etc - many times the versions of these tools are very much 
different versions as well).




However, there's this:

On 10/7/21 6:17 PM, Richard Laager wrote:
 Running tests against vendored dependencies one isn't going to use 
at

 run-time is of limited usefulness.


Best is, if you can, use the library packaged separately, in Debian,
both for tests, and runtime. This way, you do ensure that:
- patching Debian for security is still a thing
- the package can run with the Debian version of the lib



You are completely missing the reality here as well. The runtime 
dependencies are already used from the packaged versions. These 
vendored libraries are used only to create specific test cases or 
sometimes using alternative implementations to test the shipped code.


I think it's less grave than just saying "oh, we don't care about 
these

binary blobs, there's just for tests...". It's even worse, because by
using a different version for tests and runtime, you're faking 
tests...




See above. All runtime dependencies are packaged a

Bug#995722: Not running tests because tests miss source code is not useful

[Pirate Praveen]

On 7 October 2021 3:02:55 am IST, Thomas Goirand  wrote:
>On 10/6/21 6:53 PM, Pirate Praveen wrote:
>> [adding -devel]
>> 
>> On ബു, ഒക്ടോ 6 2021 at 12:16:07 വൈകു +0200 +0200, Jonas Smedegaard
>>  wrote:
>>> Quoting Yadd (2021-10-06 11:43:40)
>>>>  On Lu, 04 oct 21, 16:40:48, Bastien Roucari�s wrote:
>>>>  > Source: src:node-lodash
>>>>  > Version: 4.17.21+dfsg+~cs8.31.173-1
>>>>  > Severity: serious
>>>>  > Justification: do not compile from source
>>>>  >
>>>>  > Dear Maintainer,
>>>>  >
>>>>  > The vendor directory should be emptied
>>>>  >
>>>>  > The debug version is compiled without source (lintian warn) and
>>>> moreover the
>>>>  > rest of file are already packaged
>>>>  >
>>>>  > grep -R vendor * gives only a few hit that could be cured by
>>>> symlinking
>>>>  >
>>>>  > Bastien
>>>>  Hi,
>>>>
>>>>  this files are used for test only, maybe severity could be decreased.
>>>
>>> I find the severity accurate: Relying on non-source code is a severe
>>> violation of Debian Policy, not matter the purpose of relying on it.
>> 
>> I think we should change the policy here. Running tests helps improve
>> the quality of the software we ship. Many times the vendored code is
>> used to ensure the code does not break in a specific situation. I don't
>> think reducing test coverage in such situations is really helpful.
>
>Right, running tests helps improve the quality of software we ship.
>Which is why you probably need to test using what's shipped in Debian
>rather than using a vendored source-less code.

We are not shipping the source less code. This is used only during tests. I 
don't think we are not gaining anything by removing tests here. Just making it 
harder for the package maintainer to run tests.

>If we rely on non-free code for tests, that's really bad too, and that
>must be avoided just like we're avoiding source-less code everywhere
>else in Debian. The policy shall not change, please.
>

The code is not non-free here, just a specific version of a Free Software code 
built outside Debian.

I think tools required for tests should be considered separately from tools 
required to compile. I think it should be treated similar to test data.

What you are proposing would require the package maintainer to adapt these 
tests to versions available (many times with different API versions) in Debian 
and the easier choice is disabling tests.

I think blindly applying a rule without thinking of any consequences is bad 
too. Just because it is bad in one situation does not mean it will be bad in 
every situation. We should evaluate pros and cons of each situation before 
making a decision. Blind faith is more suitable for religions and not for a 
project like ours.

I think a nocheck build profile which excludes these files from build is 
sufficient to ensure we are not using these to create binary package. This way 
we guarantee only packages in main is used to generate the binary, but still 
allows to run tests optionally making it easy to find problems, especially 
during transitions. Currently when tests are missing transitions are harder 
because we can't find breakages easily since tests are disabled.

The current policy is not making Debian better.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#995722: Not running tests because tests miss source code is not useful

[Pirate Praveen]

[adding -devel]

On ബു, ഒക്ടോ 6 2021 at 12:16:07 വൈകു +0200 +0200, 
Jonas Smedegaard  wrote:

Quoting Yadd (2021-10-06 11:43:40)

 On Lu, 04 oct 21, 16:40:48, Bastien Roucari�s wrote:
 > Source: src:node-lodash
 > Version: 4.17.21+dfsg+~cs8.31.173-1
 > Severity: serious
 > Justification: do not compile from source
 >
 > Dear Maintainer,
 >
 > The vendor directory should be emptied
 >
 > The debug version is compiled without source (lintian warn) and 
moreover the

 > rest of file are already packaged
 >
 > grep -R vendor * gives only a few hit that could be cured by 
symlinking

 >
 > Bastien
 Hi,

 this files are used for test only, maybe severity could be 
decreased.


I find the severity accurate: Relying on non-source code is a severe
violation of Debian Policy, not matter the purpose of relying on it.


I think we should change the policy here. Running tests helps improve 
the quality of the software we ship. Many times the vendored code is 
used to ensure the code does not break in a specific situation. I don't 
think reducing test coverage in such situations is really helpful.

Bug#995702: Updating caniuse-lite (was: Re: TypeError: Cannot read property 'prefix_exceptions' of undefined)

[Pirate Praveen]

On തി, ഒക്ടോ 4 2021 at 03:17:03 വൈകു +0200 +0200, 
Dominik George  wrote:

Hi,

concerning the update of node-caniuse-lite, I fixed upstream's
deployment script, so that uscan will find new upstream versions
again:

  https://github.com/browserslist/caniuse-lite/issues/84

Shall I update caniuse-lite and upload the new version once uscan is
satisfied again?



Yes, please. You can take a snapshot of the git commit manually (the 
commit logs have version in comments) if you don't want to wait for 
next version. From next version we can continue using uscan.



Cheers,
Nik

Bug#995702: [Pkg-javascript-devel] TypeError: Cannot read property 'prefix_exceptions' of undefined

[Pirate Praveen]

On 4 October 2021 6:02:19 pm IST, Dominik George  
wrote:
>>   - let autoprefixerData = { browsers: agents, prefixes: dataPrefixes }
>>   + let autoprefixerData = { browsers: agents.agents, prefixes: dataPrefixes 
>> }
>
>It's
>https://github.com/browserslist/caniuse-lite/commit/fde289588b2ccb129ba3d1552134be2c78fee8b7
>
>So, this happened with a recent update of node-autoprefixer, because
>the new autoprefixer relies on the new API of caniuse-lite.
>
>caniuse-lite should, and will at some point, be updated in Debian as
>well. However, this will break node-browserslist, because that relies
>on the old API. Oh the joy!

Is there a new version of browserslist that uses the new API?

>Proposal:
>
> 1. Add a patch to node-autoprefixer to use the old API
> 2. Add a version constraint to the node-caniuse-lite dependency in
>node-autoprefixer (<< 1.0.30001226~)
> 3. Report a bug against node-caniuse-lite to update to the current
>upstream version, with a gentle hint on what will break if updated
> 4. Once updated, drop the patch, and remove the version constraint
>
>@ JavaScript team, shall I proceed with that?

I think updating node-caniuse-lite and patching node-browserslist may be 
better. But if that is difficult, you can go ahead with this.

BTW I had noticed the breakage while updating gitlab and filed a bug, but did 
not get time to dig deeper. Thanks for these details.

>-nik

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#995487: ruby-autoprefixer-rails: broken build, breaks gitlab

[Pirate Praveen]

Package: ruby-autoprefixer-rails
version:10.3.1.0+dfsg1+~cs14.6.19-1
Severity: grave

gitlab 14.1 installation fails when using this version. Exact error message 
will be shared after reproducing the error (filing rc bug to block migration to 
testing), downgrading to 10.2 worked.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#995073: gitlab: yarnpkg fails with error An unexpected error occurred: "Release not found: 2.4.2".

[Pirate Praveen]

On 26 September 2021 8:14:08 pm IST, Ondrej Zary  wrote:
>> yarn 3.0 needs nodejs 12. So this was a work around used to force yarn
>> 2.x. Looks like there is no way to install 2.x versions of yarn anymore :(
>>
>> So we will have to update minimum version of nodejs to 12 (already done
>> for latest versions in bullseye) and use yarn set version berry. I guess
>> you will have to use nodejs from official repos or we will have to
>> backport nodejs 12 to buster.
>
>I've built nodejs 12 and added "yarnpng set version berry" before
>"yarnpkg set version 2.4.2".
>It downloaded tons of random crap from somewhere during the "fetch step".
>Is that normal?

Not sure which packages it pulls in that step.

>Otherwise it seems to work.
>Webpack failed, as always...3 kinds of errors this time.
>
>Installing node modules...
>(node:22064) [DEP0005] DeprecationWarning: Buffer() is deprecated due to 
>security and usability issues. Please use the Buffer.alloc(), 
>Buffer.allocUnsafe(), or Buffer.from() methods instead.
>Resolving berry to a url...
>Downloading 
>https://github.com/yarnpkg/berry/raw/master/packages/berry-cli/bin/berry.js...
>Saving it into /var/lib/gitlab/.yarn/releases/yarn-berry.js...
>Updating /var/lib/gitlab/.yarnrc.yml...
>Done!
>➤ YN: Retrieving 
>https://repo.yarnpkg.com/2.4.2/packages/yarnpkg-cli/bin/yarn.js
>➤ YN: Saving the new release in .yarn/releases/yarn-2.4.2.cjs
>➤ YN: Done in 1s 327ms
>➤ YN: ┌ Resolution step
>➤ YN0061: │ document-register-element@npm:1.14.3 is deprecated: V0 is gone and 
>the best V1 polyfill is now @ungap/custom-elements
>➤ YN0061: │ axios@npm:0.20.0 is deprecated: Critical security vulnerability 
>fixed in v0.21.1. For more information, see 
>https://github.com/axios/axios/pull/3410
>➤ YN0061: │ urix@npm:0.1.0 is deprecated: Please see 
>https://github.com/lydell/urix#deprecated
>➤ YN0061: │ smooshpack@npm:0.0.62 is deprecated: Package moved to 
>@codesandbox/sandpack-client
>➤ YN0061: │ resolve-url@npm:0.2.1 is deprecated: 
>https://github.com/lydell/resolve-url#deprecated
>➤ YN0061: │ uuid@npm:3.3.2 is deprecated: Please upgrade  to version 7 or 
>higher.  Older versions may use Math.random() in certain circumstances, which 
>is known to be problematic.  See https://v8.dev/blog/math-random for details.
>➤ YN0061: │ popper.js@npm:1.16.1 is deprecated: You can find the new Popper v2 
>at @popperjs/core, this package is dedicated to the legacy v1
>➤ YN0061: │ querystring@npm:0.2.0 is deprecated: The querystring API is 
>considered Legacy. new code should use the URLSearchParams API instead.
>➤ YN0032: │ fsevents@npm:2.3.2: Implicit dependencies on node-gyp are 
>discouraged
>➤ YN0032: │ fsevents@npm:2.3.2: Implicit dependencies on node-gyp are 
>discouraged
>➤ YN0032: │ evp_bytestokey@npm:1.0.3: Implicit dependencies on node-gyp are 
>discouraged
>➤ YN0002: │ apollo-link-batch@npm:1.1.15 doesn't provide graphql (pf2c3f), 
>requested by apollo-link
>➤ YN0002: │ bootstrap-vue@npm:2.17.3 doesn't provide jquery (p8724c), 
>requested by bootstrap
>➤ YN0002: │ bootstrap-vue@npm:2.17.3 doesn't provide vue (p74d19), requested 
>by portal-vue
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides @babel/core (p8d5b6) 
>with version 0.0.0, which doesn't satisfy what babel-loader requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides popper.js (pb3b3d) with 
>version 0.0.0, which doesn't satisfy what bootstrap requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides vue (p02edf) with 
>version 0.0.0, which doesn't satisfy what portal-vue requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides vue (pa125f) with 
>version 0.0.0, which doesn't satisfy what tiptap requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides vue (p6c5ff) with 
>version 0.0.0, which doesn't satisfy what @gitlab/ui requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides vue (p4a08d) with 
>version 0.0.0, which doesn't satisfy what @tiptap/vue-2 requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides vue (pc6a59) with 
>version 0.0.0, which doesn't satisfy what @toast-ui/vue-editor requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides vue (p082e1) with 
>version 0.0.0, which doesn't satisfy what tiptap-extensions requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides vue (paa947) with 
>version 0.0.0, which doesn't satisfy what vue-resize requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides vue (p1dfac) with 
>version 0.0.0, which doesn't satisfy what vuex requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides vue-template-compiler 
>(pb49ea) with version 0.0.0, which doesn't satisfy what tiptap requests
>➤ YN0060: │ root-workspace-0b6124@workspace:. provides vue-template-compiler 
>(p659ff) with version 0.0.0, which doesn't satisfy what tiptap-extensions 
>requests
>➤ YN: │ Some peer dependencies are incorrectly met; run yarn explain 
>peer-requirements  for details, where  is the 

Bug#995073: gitlab: yarnpkg fails with error An unexpected error occurred: "Release not found: 2.4.2".

[Pirate Praveen]

On 25/9/21 11:11 PM, Ondrej Zary wrote:
> Package: gitlab
> Version: 13.12.9+ds1-1~fto10+1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
> installing gitlab 13.12.9+ds1-1~fto10+1 on buster amd64 fails with:
>
> Installing node modules...
> Resolving 2.4.2 to a url...
> error An unexpected error occurred: "Release not found: 2.4.2".
> info If you think this is a bug, please open a bug report with the 
> information provided in "/var/lib/gitlab/yarn-error.log".
> info Visit https://yarnpkg.com/en/docs/cli/policies for documentation about 
> this command.

yarn 3.0 needs nodejs 12. So this was a work around used to force yarn
2.x. Looks like there is no way to install 2.x versions of yarn anymore :(

So we will have to update minimum version of nodejs to 12 (already done
for latest versions in bullseye) and use yarn set version berry. I guess
you will have to use nodejs from official repos or we will have to
backport nodejs 12 to buster.




signature.asc
Description: OpenPGP digital signature

Bug#994624: libreoffice fail to start with error undefined symbol: _ZNK11LanguageTag20getGlibcLocaleStringESt17basic_string_viewIDsSt11char_traitsIDsEE

[Pirate Praveen]

Package: libreoffice
Version: 1:7.2.1-1
Severity: grave
Justification: the package is unusable

$ libreoffice
/usr/lib/libreoffice/program/soffice.bin: symbol lookup error: 
/usr/lib/libreoffice/program/libmergedlo.so: undefined symbol: 
_ZNK11LanguageTag20getGlibcLocaleStringESt17basic_string_viewIDsSt11char_traitsIDsEE

Bug#993964: gitaly 14.0 fails to start with error panic: failed to open gzip reader: EOF

[Pirate Praveen]

On ബു, സെപ്റ്റം 8 2021 at 10:46:06 വൈകു 
+0530 +0530, Pirate Praveen  wrote:
Sep 08 16:02:18 gitlab gitaly[4823]: panic: failed to open gzip 
reader: EOF


Fixed by updating golang-goprotobuf to 1.5.2 (Thanks to Nilesh for help 
with troubleshooting).

Bug#993964: gitaly 14.0 fails to start with error panic: failed to open gzip reader: EOF

[Pirate Praveen]

Package: gitaly
Version: 14.0.10+dfsg-1
Severity: grave

gitaly 14.0.10 from https://wiki.debian.org/gitlab/devel fails to start 
and


journalctl -xel -u gitaly --no-pager

gives the following error

Sep 08 16:02:18 gitlab gitaly[4823]: panic: failed to open gzip reader: 
EOF

Sep 08 16:02:18 gitlab gitaly[4823]: goroutine 1 [running]:
Sep 08 16:02:18 gitlab gitaly[4823]: 
gitlab.com/gitlab-org/gitaly/internal/praefect/protoregistry.init.0()
Sep 08 16:02:18 gitlab gitaly[4823]: 
gitlab.com/gitlab-org/gitaly/internal/praefect/protoregistry/protoregistry.go:32 
+0x227
Sep 08 16:02:18 gitlab systemd[1]: gitaly.service: Main process exited, 
code=exited, status=2/INVALIDARGUMENT

Bug#993818: ruby-nokogiri: WARNING: Nokogiri was built against libxml version 2.9.12, but has dynamically loaded 2.9.10

[Pirate Praveen]

Package: ruby-nokogiri
Version: 1.11.7+dfsg-2
Severity: serious
Justification: migration to testing blocked

autopkgtest for cewl is failing in testing

https://ci.debian.net/data/autopkgtest/testing/amd64/c/cewl/15073435/log.gz

terceiro on irc:
this type of warning is a PITA; I usually patch them out
(after checking that the package does work with whatever version we 
have in debian :))
just checked, the dependency is automatically generated; probably 
patching to remove the check and warning is the way to go

Bug#993817: ruby-licensee: autopkgtest regression on 9386

[Pirate Praveen]

Package: ruby-licensee
Version: 9.14.1-3
Severity: serious
Control: forwarded -1 https://github.com/licensee/licensee/issues/503

Autopkgtest regression on i386 is blocking the migration to testing

https://ci.debian.net/data/autopkgtest/testing/i386/r/ruby-licensee/15051694/log.gz

Reported upstream https://github.com/licensee/licensee/issues/503

Bug#991606: ruby-libxml: test failures with libxml2 2.9.12

[Pirate Praveen]

Control: forwarded -1 https://github.com/xml4r/libxml-ruby/issues/172

On Wed, 28 Jul 2021 15:35:58 +0200 Mattia Rizzolo  
wrote:

> Source: ruby-libxml
> Version:  3.2.0-1
> Severity: serious

Do we keep serious severity for failure only in experimental? Don't we 
wait till libxml2 2.9.12 hits unstable to raise severity?


> Tags: sid bookworm
>
> Dear maintainer,
>
> running autopkgtest against libxml2/2.9.12 (as currently found in
> experimental) fails:
> 
https://ci.debian.net/data/autopkgtest/unstable/amd64/r/ruby-libxml/13882963/log.gz



Reported upstream here https://github.com/xml4r/libxml-ruby/issues/172

Bug#992008: ruby-google-protobuf: Missing lib/google/protobuf directory and fails require

[Pirate Praveen]

2021, ഓഗസ്റ്റ് 10 5:44:35 PM IST, Pirate Praveen ൽ 
എഴുതി
>
>
>2021, ഓഗസ്റ്റ് 10 12:44:39 PM IST, "László Böszörményi (GCS)" 
>ൽ എഴുതി
>>Control: tags -1 +pending
>>
>>Hi Pirate,
>>
>>On Mon, Aug 9, 2021 at 8:51 PM Pirate Praveen  
>>wrote:
>>> Can you upload this change? Or if you are okay with this change, I can
>>> upload it as well. Once this is fixed, I can switch back to the
>>> packaged version (currently using gem install google-protobuf as work
>>> around).
>> Sure, I can. Will do it soon.

Thanks.

>>> I had seen this bug earlier
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989774 but I thought
>>> it was something similar/related to
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966653 (between, this
>>> bug also seems to be fixed with newer protobuf/grpc versions in
>>> experimental).
>> You know, my question is, how and why it was and still working for
>>3.12.4 but nor for 3.17.3?

One change that I can think of is adding noruby build profile between these two 
versions.

>>Regards,
>>Laszlo/GCS

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#992008: ruby-google-protobuf: Missing lib/google/protobuf directory and fails require

[Pirate Praveen]

Control: tags -1 patch

On Mon, 09 Aug 2021 01:35:43 +0530 Pirate Praveen 
 wrote:

> Adding,
> ruby/lib/google usr/lib/ruby/vendor_ruby
> to debian/ruby-google-protobuf.install makes require 
'google/protobuf'

> to pass. This can be used as a workaround until we figure out why
> gem2deb is not installing these files even though gemspec includes 
them

> in files.

Hi Laszlo,

Can you upload this change? Or if you are okay with this change, I can 
upload it as well. Once this is fixed, I can switch back to the 
packaged version (currently using gem install google-protobuf as work 
around).


I had seen this bug earlier 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989774 but I thought 
it was something similar/related to 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966653 (between, this 
bug also seems to be fixed with newer protobuf/grpc versions in 
experimental).


diff -Nru protobuf-3.17.3/debian/changelog 
protobuf-3.17.3/debian/changelog

--- protobuf-3.17.3/debian/changelog 2021-06-23 21:06:44.0 +0530
+++ protobuf-3.17.3/debian/changelog 2021-08-09 21:32:33.0 +0530
@@ -1,3 +1,10 @@
+protobuf (3.17.3-1.1) experimental; urgency=medium
+
+ * Non-maintainer upload.
+ * Include ruby/lib in ruby-google-protobuf binary (Closes: #992008)
+
+ -- Pirate Praveen  Mon, 09 Aug 2021 21:32:33 +0530
+
protobuf (3.17.3-1) experimental; urgency=medium

  * New upstream release.
diff -Nru protobuf-3.17.3/debian/ruby-google-protobuf.install 
protobuf-3.17.3/debian/ruby-google-protobuf.install
--- protobuf-3.17.3/debian/ruby-google-protobuf.install 1970-01-01 
05:30:00.0 +0530
+++ protobuf-3.17.3/debian/ruby-google-protobuf.install 2021-08-09 
21:30:39.0 +0530

@@ -0,0 +1 @@
+ruby/lib/google usr/lib/ruby/vendor_ruby

Bug#992008: ruby-google-protobuf: Missing lib/google/protobuf directory and fails require

[Pirate Praveen]

On Mon, Aug 9, 2021 at 1:50 pm, Antonio Terceiro  
wrote:

On Mon, Aug 09, 2021 at 01:35:43AM +0530, Pirate Praveen wrote:
 On Mon, Aug 9, 2021 at 12:12 am, Pirate Praveen 


 wrote:
 > [copying debian-ruby list]
 >
 > On Sun, 08 Aug 2021 22:08:39 +0530 Akshay S Dinesh
 >  wrote:
 > > Package: ruby-google-protobuf
 > > Version: 3.17.3-1
 > > Severity: grave
 > > Justification: renders package unusable
 > >
 > > Dear Maintainer,
 > >
 > > I was trying to install gitlab to reproduce #966653
 > >
 > > Installed ruby-google-protobuf from experimental
 > >
 > > The pg_query library was erroring at startup,
 > > with failure to require 'google/protobuf'
 > >
 > > I tried to isolate it to debian by `gem install google-protobuf`
 > >
 > > It worked correctly with that.
 > >
 > > On comparing stable version
 > > 
http://ftp.debian.org/debian/pool/main/p/protobuf/ruby-google-protobuf_3.12.4-1_amd64.deb

 > > with the experimental version
 > > 
http://ftp.debian.org/debian/pool/main/p/protobuf/ruby-google-protobuf_3.17.3-1_amd64.deb

 > >
 > > I could see that the latter lacks the
 > /2.7.0/gems/lib/google/protobuf directory altogether
 > >
 > > The upstream gem at
 > https://rubygems.org/downloads/google-protobuf-3.17.3.gem includes
 > > this lib directory with lots of ruby files
 > >
 > > I'm suspecting that this folder is critical to the functioning 
of this

 > package
 > >
 >
 > I think this is a problem with gem2deb not including the pure 
ruby files
 > along with the extention. I think we have seen such issues 
before, but

 > don't remember how we fixed it.
 >
 > Another possibility is that the rules is calling ruby build only 
in

 > override_dh_auto_build-arch.

 Adding,
 ruby/lib/google usr/lib/ruby/vendor_ruby
 to debian/ruby-google-protobuf.install makes require 
'google/protobuf' to
 pass. This can be used as a workaround until we figure out why 
gem2deb is
 not installing these files even though gemspec includes them in 
files.


protobuf is nothing like an usual Ruby package.

The top of debian/rules has this:

export DH_RUBY = --gem-install
export DH_RUBY_USE_DH_AUTO_INSTALL_DESTDIR = 
debian/ruby-google-protobuf

export GEM2DEB_TEST_RUNNER = --check-dependencies


But this is completely misleading, since the part that seems to 
actually

do the Ruby build does not use gem2deb at all, and looks like this:

ifeq (,$(filter noruby,$(DEB_BUILD_PROFILES)))
# Ruby build
cd ruby && rake package genproto
endif

So this has definitively nothing to do with gem2deb.


Well, I tried with

dh_auto_build -O--buildsystem=ruby -O--package=ruby-google-protobuf

after this rake command without any change

Also it has the following lines below it and

dh_auto_install -O--buildsystem=ruby -O--package=ruby-google-protobuf 
--destdir=$(CURDIR)/debian/ruby-google-protobuf


and you can see in the build logs at 
https://buildd.debian.org/status/fetch.php?pkg=protobuf=amd64=3.17.3-1=1624466935=0 
this looks to me pretty much gem2deb's doing.


dh_auto_install -O--buildsystem=ruby -O--package=ruby-google-protobuf 
--destdir=/<>/debian/ruby-google-protobuf

dh_ruby --install /<>/debian/ruby-google-protobuf
  dh_ruby --install
/usr/bin/ruby2.7 -S gem build --config-file /dev/null --verbose 
/tmp/d20210623-865026-7jt4fj/gemspec

Failed to load /dev/null because it doesn't contain valid YAML hash
 Successfully built RubyGem
 Name: google-protobuf
 Version: 3.17.3
 File: google-protobuf-3.17.3.gem
/usr/bin/ruby2.7 -S gem install --config-file /dev/null --verbose 
--local --verbose --no-document --ignore-dependencies --install-dir 
/<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0 
/tmp/d20210623-865026-7jt4fj/google-protobuf-3.17.3.gem

Failed to load /dev/null because it doesn't contain valid YAML hash
/<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/google-protobuf-3.17.3/ruby/ext/google/protobuf_c/convert.c
/<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/google-protobuf-3.17.3/ruby/ext/google/protobuf_c/convert.h
/<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/google-protobuf-3.17.3/ruby/ext/google/protobuf_c/defs.c
/<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/google-protobuf-3.17.3/ruby/ext/google/protobuf_c/defs.h
/<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/google-protobuf-3.17.3/ruby/ext/google/protobuf_c/extconf.rb
/<>/debian/ruby-google-protobuf/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/gems/google-protobuf-3.17.3/ruby/ext/google/proto

Bug#992008: ruby-google-protobuf: Missing lib/google/protobuf directory and fails require

[Pirate Praveen]

On Mon, Aug 9, 2021 at 12:12 am, Pirate Praveen 
 wrote:

[copying debian-ruby list]

On Sun, 08 Aug 2021 22:08:39 +0530 Akshay S Dinesh 
 wrote:

> Package: ruby-google-protobuf
> Version: 3.17.3-1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> I was trying to install gitlab to reproduce #966653
>
> Installed ruby-google-protobuf from experimental
>
> The pg_query library was erroring at startup,
> with failure to require 'google/protobuf'
>
> I tried to isolate it to debian by `gem install google-protobuf`
>
> It worked correctly with that.
>
> On comparing stable version
> 
http://ftp.debian.org/debian/pool/main/p/protobuf/ruby-google-protobuf_3.12.4-1_amd64.deb

> with the experimental version
> 
http://ftp.debian.org/debian/pool/main/p/protobuf/ruby-google-protobuf_3.17.3-1_amd64.deb

>
> I could see that the latter lacks the 
/2.7.0/gems/lib/google/protobuf directory altogether

>
> The upstream gem at 
https://rubygems.org/downloads/google-protobuf-3.17.3.gem includes

> this lib directory with lots of ruby files
>
> I'm suspecting that this folder is critical to the functioning of 
this package

>

I think this is a problem with gem2deb not including the pure ruby 
files along with the extention. I think we have seen such issues 
before, but don't remember how we fixed it.


Another possibility is that the rules is calling ruby build only in 
override_dh_auto_build-arch.


Adding,
ruby/lib/google usr/lib/ruby/vendor_ruby
to debian/ruby-google-protobuf.install makes require 'google/protobuf' 
to pass. This can be used as a workaround until we figure out why 
gem2deb is not installing these files even though gemspec includes them 
in files.

Bug#992008: ruby-google-protobuf: Missing lib/google/protobuf directory and fails require

[Pirate Praveen]

[copying debian-ruby list]

On Sun, 08 Aug 2021 22:08:39 +0530 Akshay S Dinesh 
 wrote:

> Package: ruby-google-protobuf
> Version: 3.17.3-1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> I was trying to install gitlab to reproduce #966653
>
> Installed ruby-google-protobuf from experimental
>
> The pg_query library was erroring at startup,
> with failure to require 'google/protobuf'
>
> I tried to isolate it to debian by `gem install google-protobuf`
>
> It worked correctly with that.
>
> On comparing stable version
> 
http://ftp.debian.org/debian/pool/main/p/protobuf/ruby-google-protobuf_3.12.4-1_amd64.deb

> with the experimental version
> 
http://ftp.debian.org/debian/pool/main/p/protobuf/ruby-google-protobuf_3.17.3-1_amd64.deb

>
> I could see that the latter lacks the 
/2.7.0/gems/lib/google/protobuf directory altogether

>
> The upstream gem at 
https://rubygems.org/downloads/google-protobuf-3.17.3.gem includes

> this lib directory with lots of ruby files
>
> I'm suspecting that this folder is critical to the functioning of 
this package

>

I think this is a problem with gem2deb not including the pure ruby 
files along with the extention. I think we have seen such issues 
before, but don't remember how we fixed it.


Another possibility is that the rules is calling ruby build only in 
override_dh_auto_build-arch.

Bug#990889: gitlab-workhorse: contains non-free image testdata/image.svg

[Pirate Praveen]

Control: clone -1 -2
Control: reassign -2 gitlab

On Sat, 10 Jul 2021 18:20:03 +0200 Jonas Smedegaard  wrote:
> Package: gitlab-workhorse
> Version: 8.54.2+debian-1
> Severity: serious
> Justification: Policy 2.3
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> The SVG image testdata/image.svg in the source package declares in 
its
> RDF metadata that 
http://www.w3.org/2007/10/sw-logos.html#LogoWithoutW3C

> is its license.
>
> That license is limited to non-commercial distribution.

Forwarded it upstream 
https://gitlab.com/gitlab-org/gitlab/-/issues/337373


Though gitlab-workhorse binary is now built from gitlab source package, 
so src:gitlab-workhorse should be removed (I'll file a removal request).

Bug#991651: twitter-bootstrap4: FTBFS: Browserslist: caniuse-lite is outdated. Please run: npx browserslist@latest --update-db

[Pirate Praveen]

Control: retitle -1 FTBFS: Replace Autoprefixer browsers option to 
Browserslist config


On Thu, 29 Jul 2021 17:19:34 +0200 Lucas Nussbaum  
wrote:

> Source: twitter-bootstrap4
> Version: 4.5.2+dfsg1-6
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20210728 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in bullseye, your package failed to 
build

> on amd64.
>
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > mkdir -p dist/css dist/js dist/tmp
> > sassc --sourcemap=auto scss/bootstrap.scss dist/tmp/bootstrap.css
> > sassc --sourcemap=auto scss/bootstrap-grid.scss 
dist/tmp/bootstrap-grid.css
> > sassc --sourcemap=auto scss/bootstrap-reboot.scss 
dist/tmp/bootstrap-reboot.css

> > node debian/postcss.js
> >
> >   Replace Autoprefixer browsers option to Browserslist config.
> >   Use browserslist key in package.json or .browserslistrc file.
> >
> >   Using browsers option can cause errors. Browserslist config can
> >   be used for Babel, Autoprefixer, postcss-normalize and other 
tools.

> >
> >   If you really need to use option, rename it to 
overrideBrowserslist.

> >
> >   Learn more at:
> >   https://github.com/browserslist/browserslist#readme
> >   https://twitter.com/browserslist

Dropping this line should fix the bug I think,

https://salsa.debian.org/js-team/twitter-bootstrap4/-/blob/master/debian/postcss.js#L28

It already ships a .browserslistrc file 
https://salsa.debian.org/js-team/twitter-bootstrap4/-/blob/master/.browserslistrc

Bug#991656: node-superagent: FTBFS: Browserslist: caniuse-lite is outdated. Please run: npx browserslist@latest --update-db

[Pirate Praveen]

Control: retitle -1  Unknown browser query `> 1%`. Maybe you are using 
old Browserslist or made typo in query.


On Thu, 29 Jul 2021 17:14:42 +0200 Lucas Nussbaum  
wrote:

> Source: node-superagent
> Version: 6.1.0-3
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20210728 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in bullseye, your package failed to 
build

> on amd64.
>
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > babeljs --config-file ./.lib.babelrc src --out-dir lib
> > Browserslist: caniuse-lite is outdated. Please run:
> > npx browserslist@latest --update-db
> >
> > Why you should do it regularly:
> > https://github.com/browserslist/browserslist#browsers-data-updating
> > Error [BrowserslistError]: [BABEL] 
/<>/src/agent-base.js: Unknown browser query `> 1%`. Maybe 
you are using old Browserslist or made typo in query. (While 
processing: "/usr/share/nodejs/@babel/preset-env/lib/index.js")


The actual error that caused failure is,
Unknown browser query `> 1%`. Maybe you are using old Browserslist or 
made typo in query.


This patch fixes the build failure, .browserslistrc already has these 
values and babel-preset-env recommends using this option as per 
https://babeljs.io/docs/en/babel-preset-env#browserslist-integration


--- a/.lib.babelrc
+++ b/.lib.babelrc
@@ -2,8 +2,7 @@
  "presets": [
["@babel/env", {
  "targets": {
- "node": "6.4.0",
- "browsers": [ "> 1%", "last 2 versions", "ie 9" ]
+ "node": "6.4.0"
  }
}]
  ],

But later down in the same doc it says,

By default @babel/preset-env will use browserslist config sources 
unless either the targets or ignoreBrowserslistConfig options are set.


and we have targets option set here. One option would be to drop 
targets entirely as we need to support only the nodejs version shipped 
with debian.

Bug#991245: diaspora fails to handle triggers in postinst

[Pirate Praveen]

Package: diaspora
Version: 0.7.15.0-7
severity: grave

Processing triggers for diaspora (0.7.15.0-7~bpo11+1) ...
Updating bundler configuration for migration from diaspora-installer...
postinst called with unknown argument `triggered'
dpkg: error processing package diaspora (--configure):
installed diaspora package post-installation script subprocess 
returned error exit status 1

Processing triggers for libc-bin (2.31-12) ...
Errors were encountered while processing:
diaspora

postinst script should be adapted to handle this case like gitlab does 
in


https://salsa.debian.org/ruby-team/gitlab/-/blob/master/debian/gitlab.postinst#L342

and 
https://salsa.debian.org/ruby-team/gitlab/-/blob/master/debian/gitlab.postinst#L82

Bug#991015: Acknowledgement (cannot execute due to incorrect shebang line)

[Pirate Praveen]

Control: severity -1 important

On Mon, 12 Jul 2021 21:10:15 -0400 Ryan Kavanagh  wrote:
> This bug seems to be, in part, due to a potentially (?) broken ruby
> upgrade behaviour. I've been running unstable on this laptop for ~6
> years, but still had
> 
> ii  ruby2.1 [ruby-interpreter]  2.1.5-4
> ii  ruby2.2 [ruby-interpreter]  2.2.4-1
> 
> installed as my only ruby interpreters. These are no longer available in
> unstable, and ruby2.1 was last available in:
> 
> ruby2.1| 2.1.5-2+deb8u3 | oldoldstable | source, amd64, armel, armhf, i386
> 
> Will users upgrading from buster to bullseye will encounter a similar
> issue if they've dist-upgraded from jessie to stretch to buster?

rubyX.Y no longer provides ruby-interpreter from ruby2.3

See https://lists.debian.org/debian-ruby/2021/07/msg2.html
Since it affects only very old releases, reducing severity.

-- 
Sent from my p≡p for Android.

Bug#966212: autopkgtest fails with rails 6 in experimental

[Pirate Praveen]

Control: severity -1 important

Sat, 25 Jul 2020 00:29:54 +0530 Pirate Praveen 
 wrote:
> This package's autopkgtest and rebuilds failed with rails 6 
currently in
> experimental. rails 6 will be uploaded to unstable in a weeks time, 
so

> please make sure this package is ready for rails 6. The severity of
> this bug will be raised to serious after rails 6 is uploaded to
> unstable.

Its only reverse dependency diaspora now embeds rail 5 so we can ignore 
this version check. I will keep the bug open if somoene wants verify 
rails 6 compatibility or if upstream confirms it. I have relaxed the 
dependency with a patch for now.

Bug#966549: autopkgtest fails with rails 6 in experimental

[Pirate Praveen]

Control: severity -1 important

On Thu, 30 Jul 2020 19:18:09 +0530 Kartik Kulkarni 
 wrote:

> Hi,
>
> This package's autopkgtest and rebuilds failed with rails 6 
currently in
> experimental. rails 6 will be uploaded to unstable in a weeks time, 
so

> please make sure this package is ready for rails 6. The severity of
> this bug will be raised to serious after rails 6 is uploaded to
> unstable.

Its only reverse dependency diaspora now embeds rails 5 and the test 
failures during build is ignored and autopkgtest is disabled in 
1.1.0-4. I will keep the bug open in case someone is interested to fix 
the rails 6 support. Alternatively, if diaspora switches to another gem 
like premailer-rails we could remove this package.

Bug#981224: ruby-uglifier: FTBFS: tests fail: uglifier_spec.rb:383, uglifier_spec.rb:751

[Pirate Praveen]

On Wed, 27 Jan 2021 23:18:24 +0100 Andreas Beckmann  
wrote:
> ruby-uglifier/experimental recently started to FTBFS, probably after 
some

> build-dependency was updated:

I think switching to ruby-terser is a good idea (gitlab and diaspora 
moved already). This should be a drop in replacement (moving gitlab and 
diaspora was pretty easy).


See https://github.com/diaspora/diaspora/pull/8268 for an idea. I think 
rails need it only for the newapp autopkgtests,ruby-sprockets I have 
not checked.


Should we target removal of ruby-uglifier from bookworm?

$ reverse-depends ruby-uglifier
Reverse-Recommends
* nanoc

Reverse-Depends
* diaspora
* gitlab
* obs-api
* rails

$ reverse-depends -b ruby-uglifier
Reverse-Build-Depends
* nanoc
* open-build-service
* rails
* ruby-sprockets

Bug#990458: babel umd support is limited

[Pirate Praveen]

On Sat, 03 Jul 2021 23:01:35 +0530 Pirate Praveen 
 wrote:
> I switched to rollup for generating umd and removed 
add-module-exports
> plugin and it is working now. Possibly defining "autosize" global 
with

> @babel/plugin-transform-modules-umd without add-module-exports plugin
> would have worked as well.

I tried this option today and it did not work. Looks like this is a 
known limitaion of babel umd plugin. 
https://github.com/babel/babel/issues/10696 so we will stick with 
rollup.

Bug#990458: libjs-autosize is not fixed by node-babel-plugin-add-module exports update

[Pirate Praveen]

On Sat, 03 Jul 2021 18:11:20 +0530 Pirate Praveen 
 wrote:
> But this is babel 6 to babel 7 migration. The code transpiled by 
babel

> 6 works fine, but moving to babel 7 broke it.

One possibility is that the add-module-exports plugin is not compatible 
with babel 7's umd plugin (@babel/plugin-transform-modules-umd).

Bug#990458: libjs-autosize is not fixed by node-babel-plugin-add-module exports update

[Pirate Praveen]

On Sat, Jul 3, 2021 at 12:29 pm, Akshay S Dinesh  
wrote:

https://stackoverflow.com/questions/33505992/babel-6-changes-how-it-exports-default

But most importantly 
https://kentcdodds.com/blog/misunderstanding-es6-modules-upgrading-babel-tears-and-a-solution


But this is babel 6 to babel 7 migration. The code transpiled by babel 
6 works fine, but moving to babel 7 broke it.


and looks like autosize upstream moved their build system to 
microbundle (an absctraction of rollup and babel with a set of plugins) 
which is not packaged yet.

Bug#990458: libjs-autosize is not fixed by node-babel-plugin-add-module exports update

[Pirate Praveen]

Control: reopen -1

On Wed, 30 Jun 2021 22:40:13 +0530 Pirate Praveen 
 wrote:

> and this is working with diaspora. Thanks again for tracking down the
> issue.

Looks like I was wrong here and it is still failing with libjs-autosize 
built with latest node-babel-plugin-add-module-exports.


You can see this on browser console of 
https://diaspora.publicvm.com/statistics (setup by Rojin for testing).

Bug#990493: node-babel-plugin-add-module-exports broken with babel-preset-env 7

[Pirate Praveen]

On Wed, 30 Jun 2021 21:23:37 +0530 Pirate Praveen 
 wrote:

> $ reverse-depends -b node-babel-plugin-add-module-exports
> Reverse-Build-Depends
> * autosize.js
> * node-babel-plugin-lodash
> * node-colormin
> * node-css-loader
> * node-deep-for-each
> * node-es6-promise
> * node-handlebars
> * node-i18next-http-backend

Using
https://wiki.debian.org/Javascript/Nodejs/Transitions/Babel7#Reverse_build_dependencies_of_node-babel-plugin-add-module-exports 
to track status of reverse build dependencies. If you'd like to help, 
please pick one from the list and add your name in the wiki.

Bug#990458: [Pkg-javascript-devel] Bug#990458: Bug#990458: Bug#990458: Attaching the files from buster vs bullseye

[Pirate Praveen]

On Wed, Jun 30, 2021 at 9:44 pm, Pirate Praveen 
 wrote:



On Wed, Jun 30, 2021 at 9:38 pm, Pirate Praveen 
 wrote:
Looks like we are already using the dist tarballs and does not 
involve any build, we can just take the latest 1.0.4 from npmjs.com.


Scratch that, the new versions use babel to build, so I think using 
https://github.com/lijunle/babel-plugin-add-module-exports/ is the 
best option, though the latest version tagged is 1.0.2 and latest npm 
release is 1.0.4 (basically completely messed up release workflow).


With babel-plugin-add-module-exports 1.0.4 from the above repo,

$ diff -u autosize-current.js autosize.js
--- autosize-current.js 2021-06-30 22:30:00.391798535 +0530
+++ autosize.js 2020-12-14 17:42:45.0 +0530
@@ -284,5 +284,5 @@

  var _default = autosize;
  _exports["default"] = _default;
-  module.exports = exports["default"];
+  module.exports = exports.default;
});
\ No newline at end of file

and this is working with diaspora. Thanks again for tracking down the 
issue.

Bug#990458: [Pkg-javascript-devel] Bug#990458: Bug#990458: Attaching the files from buster vs bullseye

[Pirate Praveen]

On Wed, Jun 30, 2021 at 9:38 pm, Pirate Praveen 
 wrote:
Looks like we are already using the dist tarballs and does not 
involve any build, we can just take the latest 1.0.4 from npmjs.com.


Scratch that, the new versions use babel to build, so I think using 
https://github.com/lijunle/babel-plugin-add-module-exports/ is the best 
option, though the latest version tagged is 1.0.2 and latest npm 
release is 1.0.4 (basically completely messed up release workflow).

Bug#990458: [Pkg-javascript-devel] Bug#990458: Attaching the files from buster vs bullseye

[Pirate Praveen]

On Wed, Jun 30, 2021 at 9:30 pm, Pirate Praveen 
 wrote:



On Wed, Jun 30, 2021 at 8:27 pm, Akshay S Dinesh 
 wrote:
Either, update this plugin in Debian to the fork that's pushed only 
to npm (or switch to 
https://github.com/lijunle/babel-plugin-add-module-exports/ I guess)




I think we can take the last tagged version 1.0.0 and apply a patch 
to make it 1.0.2.


Looks like we are already using the dist tarballs and does not involve 
any build, we can just take the latest 1.0.4 from npmjs.com.

Bug#990458: Attaching the files from buster vs bullseye

[Pirate Praveen]

On Wed, Jun 30, 2021 at 8:27 pm, Akshay S Dinesh  
wrote:
This is most likely due to babel-plugin-add-module-exports being 
broken.


See 
https://github.com/59naga/babel-plugin-add-module-exports/issues/72


and 
https://github.com/59naga/babel-plugin-add-module-exports/issues/80


and 
https://github.com/59naga/babel-plugin-add-module-exports/issues/73



That 73 points to a new version that's put only on npm and not on 
github. I'm not exactly sure how it works with fakeupstream at 
https://salsa.debian.org/js-team/node-babel-plugin-add-module-exports/-/tree/master/


Either way, the version in salsa seems to be 0.2.1 which is 
definitely outdated (as per the github description of 
babel-plugin-add-module-exports



Two ways I see are:

Either, update this plugin in Debian to the fork that's pushed only 
to npm (or switch to 
https://github.com/lijunle/babel-plugin-add-module-exports/ I guess)




I think we can take the last tagged version 1.0.0 and apply a patch to 
make it 1.0.2.




OR

Try removing this plugin altogether and changing the
"export default autosize" statement in the last line of autosize.js to
"module.exports = autosize"



It looks like many packages build depend on this module and those are 
also likely broken. I opened 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990493 to track this.



I'm NOT sure whether either of these will work.


Thanks for the pointers, at least we know what is broken and what the 
fix is. We just have to figure out the best way to include it.

Bug#990493: node-babel-plugin-add-module-exports broken with babel-preset-env 7

[Pirate Praveen]

Package: node-babel-plugin-add-module-exports
Version: 0.2.1-3
Severity: grave
Justification: creates broken build output
Control: forwarded -1 
https://github.com/59naga/babel-plugin-add-module-exports/issues/73

Control: block 990458 by -1

Upstream has released a fix in major update. Since we are in freeze I'm 
not sure how to proceed here. This affects many packages.


$ reverse-depends -b node-babel-plugin-add-module-exports
Reverse-Build-Depends
* autosize.js
* node-babel-plugin-lodash
* node-colormin
* node-css-loader
* node-deep-for-each
* node-es6-promise
* node-handlebars
* node-i18next-http-backend

Bug#990458: Attaching the files from buster vs bullseye

[Pirate Praveen]

On Tue, 29 Jun 2021 23:54:30 +0530 Pirate Praveen 
 wrote:

> I can confirm libjs-autosize from buster works fine with diaspora.

So workaround is to install the buster version from snapshot.debian.org

http://snapshot.debian.org/archive/debian/20190209T090056Z/pool/main/a/autosize.js/libjs-autosize_4.0.2~dfsg1-3_all.deb

Bug#990458: Attaching the files from buster vs bullseye

[Pirate Praveen]

On Tue, 29 Jun 2021 23:54:30 +0530 Pirate Praveen 
 wrote:

> I can confirm libjs-autosize from buster works fine with diaspora.
>
> Buster version has this,
>
> (function (global, factory) {
> if (typeof define === "function" && define.amd) {
>   define(['module', 'exports'], factory);
>
> But bullseye version is missing definition for module,
>
> (function (global, factory) {
> if (typeof define === "function" && define.amd) {
>   define(["exports"], factory);

Akshay,

Any ideas about this? Basically it is a behavior change from babel 6 to 
babel 7 and we'd like to restore the babel 6 behavior.