Bug#1009107: node-npm-run-path tries to write file packaged by node-execa

2022-04-07 Thread Santiago R.R.
Package: node-npm-run-path
Version: 5.1.0+~4.0.0-5
Severity: serious

Dear maintainer,

I got this error when upgrading my system:

Preparing to unpack .../node-npm-run-path_5.1.0+~4.0.0-5_all.deb ...
Unpacking node-npm-run-path (5.1.0+~4.0.0-5) over (4.0.1-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/node-npm-run-path_5.1.0+~4.0.0-5_all.deb (--unpack):
 trying to overwrite '/usr/share/nodejs/path-key/index.d.ts', which is also in 
package node-execa 5.1.1+repack+~cs17.3.6-1
Errors were encountered while processing:
 /var/cache/apt/archives/node-npm-run-path_5.1.0+~4.0.0-5_all.deb

You can reproduce it by trying to install both packages at the same
time.

Could you please take a look at it?

Cheers,

 -- S

-- System Information:
Debian Release: bookworm/sid
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages node-npm-run-path depends on:
iu  node-execa [node-path-key]  5.1.1+repack+~cs17.3.6-1

node-npm-run-path recommends no packages.

node-npm-run-path suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature


Bug#951329: FTBFS in buster with linux-source-4.19 4.19.98-1

2020-03-05 Thread Santiago R.R.
El 26/02/20 a las 11:10, Santiago R.R. escribió:
> Hi Ritesh,
> 
> I've just made another MR to modify the changelog entry.
> 
> Also, please, remember to create a tag for the release once it get
> approved (and uploaded).

Hi Ritesh,

When trying to upload I realized the format of the package is that of a
native package, but the version has a revision at the same time. Which I
think it is unusual.
I don't understand how the package is built (at least using gbp). Could
you please tell me how to do you build the package? And even, fell free
to upload it yourself, to avoid duplicating work.

Thanks,

 -- Santiago


signature.asc
Description: PGP signature


Bug#951329: FTBFS in buster with linux-source-4.19 4.19.98-1

2020-02-26 Thread Santiago R.R.
Hi Ritesh,

I've just made another MR to modify the changelog entry.

Also, please, remember to create a tag for the release once it get
approved (and uploaded).

Cheers,

 -- Santiago


signature.asc
Description: PGP signature


Bug#951329: Bug#952441: buster-pu: package user-mode-linux/4.19-1um-1+b1

2020-02-26 Thread Santiago R.R.
Control: fixed 951329 user-mode-linux/5.4-1um-2

El 25/02/20 a las 21:05, Adam D. Barratt escribió:
> Control: tags -1 + moreinfo
> 
> On Mon, 2020-02-24 at 14:49 +0100, Santiago R.R. wrote:
> > I would like to upload user-mode-linux to buster to fix this FTBFS:
> > https://bugs.debian.org/951329. Ritesh Raj Sarraf (rrs) has already
> > given his ACK.
> > 
> 
> The metadata for that bug suggests that it affects the package in
> unstable, and is not currently fixed there. Is that correct?
> 
> If it is, the issue should be fixed in unstable first. If not, the bug
> report should have an appropriate "fixed" version added, indicating the
> earliest upload that's unaffected.

Hi Adam,

Thanks! I forgot clarifying that this didn't affect unstable. Hopefully
the above control command fix that.

Also, I realised the changelog did not describe how the bug was fixed.
So please, consider the new debdiff.

Cheers,

 -- S
diff -Nru user-mode-linux-4.19-1um/debian/changelog 
user-mode-linux-4.19-1um/debian/changelog
--- user-mode-linux-4.19-1um/debian/changelog   2018-12-27 08:46:23.0 
+0100
+++ user-mode-linux-4.19-1um/debian/changelog   2020-02-26 10:53:51.0 
+0100
@@ -1,3 +1,11 @@
+user-mode-linux (4.19-1um-1+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * [00f54af] Fix FTBFS in buster with linux-source-4.19 4.19.98-1.
+Remove fix-port-helper-path.patch (Closes: #951329).
+
+ -- Santiago Ruano Rincón   Wed, 26 Feb 2020 10:32:01 
+0100
+
 user-mode-linux (4.19-1um-1) unstable; urgency=medium
 
   * [a505b8d] Update to Linux 4.19 (Closes: #916958)
diff -Nru user-mode-linux-4.19-1um/debian/patches/series 
user-mode-linux-4.19-1um/debian/patches/series
--- user-mode-linux-4.19-1um/debian/patches/series  2018-12-27 
08:46:23.0 +0100
+++ user-mode-linux-4.19-1um/debian/patches/series  2020-02-26 
10:53:51.0 +0100
@@ -3,4 +3,3 @@
 05_fix_static_build.patch
 06-fix-linkage-on-386-arch.patch
 07-remove-rpath.patch
-fix-port-helper-path.patch


signature.asc
Description: PGP signature


Bug#951329: FTBFS in buster with linux-source-4.19 4.19.98-1

2020-02-24 Thread Santiago R.R.
El 24/02/20 a las 15:29, Ritesh Raj Sarraf escribió:
> Sorry. I hadn't realized that you already had MRs on Salsa. But I
> wasn't aware of the extra configuration needed for notifications.

Mmm, maybe I had to continue using the BTS, instead of the MR. At least
for communicating with you.

> 
> Please go ahead with the upload.

Thanks! I've just filed a bug report against release.d.o to ask for an
OK from the RMs.

...
> On Mon, 2020-02-24 at 15:16 +0530, Ritesh Raj Sarraf wrote:
> > Hi Santiago,
> > 
> > Do you have the MR ready ?
> > 
> > Your bug report against the package in Buster has caused a trigger to
> > auto-remove UML from Debian Testing. I don't know how removing the
> > package from testing solves any problem with the package in Buster.
...

Good question. But anyway, I hope I will be able to upload before the
automatic auto-removal deadline.


Cheers,

 - srr



signature.asc
Description: PGP signature


Bug#951329: FTBFS in buster with linux-source-4.19 4.19.98-1

2020-02-14 Thread Santiago R.R.
Package: user-mode-linux
Version: 4.19-1um-1
Severity: serious
Tags: patch

Dear maintainer,

The current user-mode-linux package in buster fails to build the latest
linux kernel in buster due to the fix-port-helper-path.patch:

Applying patch 
/build/user-mode-linux-4.19-1um/debian/patches/fix-port-helper-path.patch
patching file arch/um/drivers/port_user.c
Hunk #1 FAILED at 168.
1 out of 1 hunk FAILED -- rejects in file arch/um/drivers/port_user.c
Patch /build/user-mode-linux-4.19-1um/debian/patches/fix-port-helper-path.patch 
can be reverse-applied
make: *** [debian/rules:54: patch-stamp] Error 1
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
I: copying local configuration
E: Failed autobuilding of package

Removing it solves the issue:

diff --git a/debian/patches/series b/debian/patches/series
index 5f98481..29faa0f 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,4 +3,3 @@
 05_fix_static_build.patch
 06-fix-linkage-on-386-arch.patch
 07-remove-rpath.patch
-fix-port-helper-path.patch

BTW, I will prepare a git branch in my personal salsa namespace. But I
am not sure against which branch should I propose a MR.

Cheers,

 -- Santiago


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_CO.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages user-mode-linux depends on:
ii  libc6  2.29-10

Versions of packages user-mode-linux recommends:
ii  uml-utilities  20070815.3-1

Versions of packages user-mode-linux suggests:
ii  rootstrap 0.3.25-1
ii  rxvt-unicode [x-terminal-emulator]9.22-6+b2
pn  slirp 
ii  terminator [x-terminal-emulator]  1.91-4
ii  user-mode-linux-doc   20060501-3
pn  vde2  
ii  xfce4-terminal [x-terminal-emulator]  0.8.9.1-1
ii  xterm [x-terminal-emulator]   353-1

-- no debconf information



Bug#940723: java-package requires libgtk-3-0 and libcairo-gobject2 to build java8 221

2019-09-19 Thread Santiago R.R.
Package: java-package
Version: 0.62
Severity: serious

Dear java-package maintainers,

When trying to build the deb package of jdk-8u221-linux-x64.tar.gz on a
clean sid pbuilder, I got the following errors:

…
dpkg-shlibdeps: error: cannot find library libgtk-3.so.0 needed by 
debian/oracle-java8-jdk/usr/lib/jvm/oracle-java8-jdk-amd64/jre/lib/amd64/libglassgtk3.so
 (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '')
dpkg-shlibdeps: error: cannot find library libgdk-3.so.0 needed by 
debian/oracle-java8-jdk/usr/lib/jvm/oracle-java8-jdk-amd64/jre/lib/amd64/libglassgtk3.so
 (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '')
dpkg-shlibdeps: error: cannot find library libcairo-gobject.so.2 needed by 
debian/oracle-java8-jdk/usr/lib/jvm/oracle-java8-jdk-amd64/jre/lib/amd64/libglassgtk3.so
 (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '')
…
dpkg-shlibdeps: error: cannot continue due to the errors listed above
Note: libraries are not searched in other binary packages that do not have any 
shlibs or symbols file.
To help dpkg-shlibdeps find private libraries, you might need to use -l.
…
dh_shlibdeps: Aborting due to earlier error
make[1]: *** [debian/rules:17: override_dh_shlibdeps] Error 255
make: *** [debian/rules:11: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


Installing libcairo-gobject2 and libgtk-3-0 makes make-jpkg happy.

Cheers,

 -- Santiago

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_CO.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages java-package depends on:
ii  build-essential  12.8
ii  debhelper12.6.1
ii  dpkg-dev 1.19.7
ii  fakeroot 1.24-1
ii  libasound2   1.1.8-1
ii  libfontconfig1   2.13.1-2+b1
ii  libgl1-mesa-glx  19.1.6-1
ii  libgtk2.0-0  2.24.32-4
ii  libx11-6 2:1.6.7-1
ii  libxslt1.1   1.1.32-2.1
ii  libxtst6 2:1.2.3-1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  unzip6.0-25

java-package recommends no packages.

Versions of packages java-package suggests:
pn  openjdk-7-jre  


signature.asc
Description: PGP signature


Bug#908903: zonecheck unusable in buster/sid

2018-09-15 Thread Santiago R.R.
Package: zonecheck
Version: 3.0.5-3
Severity: grave

Dear Sebastien,

zonecheck in my sid environment is unusable. It ends up in ERROR when
e.g. checking debian.org:

/usr/lib/ruby/vendor_ruby/dnsruby.rb:413: warning: constant ::TimeoutError is 
deprecated
/usr/lib/ruby/vendor_ruby/Dnsruby/code_mapper.rb:110: warning: constant 
::Fixnum is deprecated
[… removing duplicated warnings]
ZONE  : debian.org
NS <= : dnsnode.debian.org [194.146.106.126, 2001:67C:1010:32::53]
NS: sec2.rcode0.net [176.97.158.100, 2001:67C:10B8::100]
NS: sec1.rcode0.net [192.174.68.100, 2001:67C:1BC::100]

/usr/share/zonecheck/test/connectivity.rb:128: warning: Object#timeout is 
deprecated, use Timeout.timeout instead.
[… removing duplicated warnings]
# terminated with exception (report_on_exception is true):
/usr/lib/ruby/vendor_ruby/Dnsruby/dnssec.rb:260:in `try_validation': comparison 
of Integer with Dnsruby::Message::SecurityLevel failed (ArgumentError)
from /usr/lib/ruby/vendor_ruby/Dnsruby/dnssec.rb:229:in 
`validate_with_query'
from /usr/lib/ruby/vendor_ruby/Dnsruby/validator_thread.rb:108:in 
`validate'
from /usr/lib/ruby/vendor_ruby/Dnsruby/validator_thread.rb:60:in 
`do_validate'
from /usr/lib/ruby/vendor_ruby/Dnsruby/validator_thread.rb:37:in `block 
in run'
ERROR: comparison of Integer with Dnsruby::Message::SecurityLevel failed


In stretch, I am getting the same Object#timeout warnings, but at least
it returns no error, and debian.org gets a SUCCESS :)

/usr/lib/ruby/vendor_ruby/dnsruby.rb:413: warning: constant ::TimeoutError is 
deprecated
ZONE  : debian.org
NS <= : dnsnode.debian.org [194.146.106.126, 2001:67C:1010:32::53]
NS: sec1.rcode0.net [192.174.68.100, 2001:67C:1BC::100]
NS: sec2.rcode0.net [176.97.158.100, 2001:67C:10B8::100]

/usr/share/zonecheck/test/connectivity.rb:128:in `chk_udp': Object#timeout is 
deprecated, use Timeout.timeout instead.
[… removing duplicated warnings]
   ___
 ,---.|
 |warning|| ~
 `---'
w> The 'refresh' period should be between 1H and 2D
 | Adv: default registry policy
 |   The registry requires the SOA fields to be inside a defined range:
 | the 'expire' should be between 1W and 6W, the 'minimum' between 3M and
 | 1W, the 'refresh' between 1H and 2D, and at last the 'retry' between
 | 15M and 1D.
 `- -- -- - -  -
 :   The refresh value is 30M and should be between 1H and 2D.
 `. .. .. . .  .
=> dnsnode.debian.org/2001:67C:1010:32::53
=> dnsnode.debian.org/194.146.106.126
=> sec1.rcode0.net/192.174.68.100
=> sec2.rcode0.net/176.97.158.100
=> sec2.rcode0.net/2001:67C:10B8::100
=> sec1.rcode0.net/2001:67C:1BC::100

w> The 'retry' period should be between 15M and 1D
 | Adv: default registry policy
 |   The registry requires the SOA fields to be inside a defined range:
 | the 'expire' should be between 1W and 6W, the 'minimum' between 3M and
 | 1W, the 'refresh' between 1H and 2D, and at last the 'retry' between
 | 15M and 1D.
 `- -- -- - -  -
 :   The retry value is 10M and should be between 15M and 1D.
 `. .. .. . .  .
=> dnsnode.debian.org/2001:67C:1010:32::53
=> dnsnode.debian.org/194.146.106.126
=> sec1.rcode0.net/192.174.68.100
=> sec2.rcode0.net/176.97.158.100
=> sec2.rcode0.net/2001:67C:10B8::100
=> sec1.rcode0.net/2001:67C:1BC::100

==> SUCCESS (but 12 warning(s))


JFTR, according to
https://www.nic.cz/public_media/IT15/prezentace/Patrik_Wallstrom.pdf
(slide 3), zonecheck (in ruby) is considered as old code. It has been
deprecated in favor of zonemaster (in perl), currently RFP:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780184

Cheers,

 -- Santiago


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

Kernel: Linux 4.18.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_CO.utf8, LC_CTYPE=es_CO.utf8 (charmap=UTF-8), LANGUAGE=es_CO:es 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages zonecheck depends on:
ii  iputils-ping  3:20180629-2
ii  ruby  1:2.5.1
ii  ruby-dnsruby  1.54-2

Versions of packages zonecheck recommends:
pn  libopenssl-ruby  

zonecheck suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature


Bug#906158: intel-microcode: Update intel-microcode to 20180807

2018-08-23 Thread Santiago R.R.
Hi,

I cannot talk for the maintainer either, but AFAIU the new license
doesn't make it possible for Debian to distribute the binaries.
Gentoo has concluded that also, and that the files cannot be mirrored. 

El 19/08/18 a las 09:36, Markus Schade escribió:
…
> could you please clarify what concerns Debian has with the license?

AFAICS, there are different points that Debian would be concerned about.
Starting with:

DO NOT DOWNLOAD, INSTALL, ACCESS, COPY, OR USE ANY PORTION OF THE SOFTWARE 
UNTIL YOU HAVE READ AND ACCEPTED THE TERMS AND CONDITIONS OF THIS AGREEMENT.

(I didn't have to read the agreement to download, install…)

And then:

2. LIMITED LICENSE. Conditioned on Your compliance with the terms and 
conditions of this Agreement, Intel grants to You … to (iii) distribute an 
object code representation of the Software, provided by Intel, through multiple 
levels of distribution, solely as embedded in or for execution on an 
Intel-based product and subject to these license terms, and if to an end user, 
pursuant to a license agreement with terms and conditions at least as 
restrictive as those contained in the Intel End User Software License Agreement 
in Appendix A hereto.


Distribution to derivatives is problematic:

3. LICENSE RESTRICTIONS. …
Unless expressly permitted under the 
Agreement, You will not, and will not allow any third party to (i) use, copy, 
distribute, sell or offer to sell the Software or associated documentation;
… (iii) use or make the Software 
available for the use or benefit of third parties;

And then, there are some restrictions, for which I am not sure we
(Debian) would be concerned, such as 13. export, directly or
indirectly", to some countries, or 14. "You will not provide the
Software to the U.S. Government."


Maybe it would be needed to change the package to provide a download
helper from the intel servers? The user should have to be asked to
accept or not the license and its appendix A.

Cheers,

 -- S


signature.asc
Description: PGP signature


Bug#898694: FTBFS with cowbuilder when network access is disabled

2018-05-15 Thread Santiago R.R.
Source: ruby2.3
Version: 2.3.3-1+deb9u2
Severity: serious

Other than the Failures in #889117, current ruby2.3 package fails to
build due to Rinda TestRingFinger and TestRingServer trying to access
network ressources:

…
  6) Error:
Rinda::TestRingFinger#test_make_socket_ipv4_multicast:
Errno::ENETUNREACH: Network is unreachable - connect(2) for 239.0.0.1:7647
/build/ruby2.3-2.3.3/lib/rinda/ring.rb:431:in `connect'
/build/ruby2.3-2.3.3/lib/rinda/ring.rb:431:in `make_socket'
/build/ruby2.3-2.3.3/test/rinda/test_rinda.rb:782:in 
`test_make_socket_ipv4_multicast'

  7) Error:
Rinda::TestRingFinger#test_make_socket_ipv4_multicast_hops:
Errno::ENETUNREACH: Network is unreachable - connect(2) for 239.0.0.1:7647
/build/ruby2.3-2.3.3/lib/rinda/ring.rb:431:in `connect'
/build/ruby2.3-2.3.3/lib/rinda/ring.rb:431:in `make_socket'
/build/ruby2.3-2.3.3/test/rinda/test_rinda.rb:809:in 
`test_make_socket_ipv4_multicast_hops'

  8) Error:
Rinda::TestRingServer#test_make_socket_ipv4_multicast:
Errno::ENODEV: No such device - setsockopt(2)
/build/ruby2.3-2.3.3/lib/rinda/ring.rb:154:in `setsockopt'
/build/ruby2.3-2.3.3/lib/rinda/ring.rb:154:in `make_socket'
/build/ruby2.3-2.3.3/test/rinda/test_rinda.rb:626:in 
`test_make_socket_ipv4_multicast'

  9) Error:
Rinda::TestRingServer#test_ring_server_ipv4_multicast:
Errno::ENODEV: No such device - setsockopt(2)
/build/ruby2.3-2.3.3/lib/rinda/ring.rb:154:in `setsockopt'
/build/ruby2.3-2.3.3/lib/rinda/ring.rb:154:in `make_socket'
/build/ruby2.3-2.3.3/lib/rinda/ring.rb:108:in `block in initialize'
/build/ruby2.3-2.3.3/lib/rinda/ring.rb:106:in `each'
/build/ruby2.3-2.3.3/lib/rinda/ring.rb:106:in `initialize'
/build/ruby2.3-2.3.3/test/rinda/test_rinda.rb:667:in `new'
/build/ruby2.3-2.3.3/test/rinda/test_rinda.rb:667:in 
`test_ring_server_ipv4_multicast'

15919 tests, 2236057 assertions, 5 failures, 4 errors, 82 skips
…

I am preparing a commit to solve this in the stretch git branch.

cheers,

Santiago


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

Kernel: Linux 4.16.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_CO:es (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


signature.asc
Description: PGP signature


Bug#891932: CVE-2018-7440 gplotMakeOutput() command injection vulnerability

2018-03-02 Thread Santiago R.R.
Source: leptonlib
Version: 1.75.3-2
Severity: grave
Tags: security patch

Hi,

the following vulnerability was published for leptonlib.

CVE-2018-7440[0]:
| An issue was discovered in Leptonica through 1.75.3. The
| gplotMakeOutput function allows command injection via a $(command)
| approach in the gplot rootname argument. This issue exists because of
| an incomplete fix for CVE-2018-3836.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-7440
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7440

An upstream patch is available at:


https://github.com/DanBloomberg/leptonica/pull/313/commits/49ecb6c2dfd6ed5078c62f4a8eeff03e3beced3b

Please adjust the affected versions in the BTS as needed.


signature.asc
Description: PGP signature


Bug#891596: CVE-2018-7409

2018-02-26 Thread Santiago R.R.
Source: unixodbc
Version: 2.3.4-1.1
Severity: grave
Tags: security

Hi,

the following vulnerability was published for unixodbc.

CVE-2018-7409[0]:
| In unixODBC before 2.3.5, there is a buffer overflow in the
| unicode_to_ansi_copy() function in DriverManager/__info.c.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-7409
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7409

Please adjust the affected versions in the BTS as needed.



signature.asc
Description: PGP signature


Bug#881328: mininet requires missing ovs-controller

2017-12-04 Thread Santiago R.R.
El 03/12/17 a las 14:38, Tomasz Buchert escribió:
> On 30/11/17 09:26, Santiago R.R. wrote:
> > Control: tags -1 + patch fixed-upstream
> >
> > On Fri, 10 Nov 2017 12:15:39 +0100 "Santiago R.R." <santiag...@riseup.net> 
> > wrote:
> >
> > It seems I am wrong about this.
> 
> The bug was only happening if you would have
> openvswitch-testcontroller installed. The reason is that mininet fails
> to detect the path of the test controller. The patch you provided fixes
> the issue.

Just for the record:
If you are talking about package names, it happened in unstable if you
had openvswith-common installed:

dpkg -S /usr/bin/ovs-testcontroller 
openvswitch-common: /usr/bin/ovs-testcontroller

LANG=C.UTF-8 dpkg -l openvswitch-common
ii  openvswitch-common   2.8.1+dfsg1-3   amd64   Open vSwitch common 
components

...
> > P.S. Question for openvswitch maintainers: does it make sense to include
> > back /usr/bin/ovs-testcontroller in the -testcontroller package?
> 
> Thanks, I've added the patch and will upload the package later today.

Thanks for uploading it!

Cheers,

 -- Santiago



Bug#881328: mininet requires missing ovs-controller

2017-11-30 Thread Santiago R.R.
Control: tags -1 + patch fixed-upstream

On Fri, 10 Nov 2017 12:15:39 +0100 "Santiago R.R." <santiag...@riseup.net> 
wrote:
…
> mn tries to run ovs-controller, which has been renamed to
> /usr/bin/ovs-testcontroller according to
> https://github.com/openvswitch/ovs/blob/9a180f2c002adf73951e0ee9990c44e5e5cd4a0f/NEWS#L600

ovs-controller -> test-controller -> ovs-testcontroller

https://github.com/openvswitch/ovs/blob/9a180f2c002adf73951e0ee9990c44e5e5cd4a0f/NEWS#L471

> mininet should Depends or Recomends on openvswitch-testcontroller

It seems I am wrong about this.

> 
> $ sudo mn --topo tree,depth=2,fanout=3
> *** Creating network
> *** Adding controller
> *** Adding hosts:
> h1 h2 h3 h4 h5 h6 h7 h8 h9
> *** Adding switches:
> s1 s2 s3 s4
> *** Adding links:
> (s1, s2) (s1, s3) (s1, s4) (s2, h1) (s2, h2) (s2, h3) (s3, h4) (s3, h5) (s3, 
> h6) (s4, h7) (s4, h8) (s4, h9)
> *** Configuring hosts
> h1 h2 h3 h4 h5 h6 h7 h8 h9
> *** Starting controller
> c0 Cannot find required executable ovs-controller.
> Please make sure that it is installed and available in your $PATH:
> (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)
…
> Versions of packages mininet depends on:
> ii  cgroup-bin0.41-8
> ii  iperf 2.0.10+dfsg1-1
> ii  libc6 2.24-17
> ii  net-tools 1.60+git20161116.90da8a0-1
> ii  openvswitch-switch2.8.1+dfsg1-3
> ii  python2.7.14-1
> ii  python-pkg-resources  36.6.0-1
> ii  socat 1.7.3.2-1
> ii  telnet0.17-41

(I am new on this, and I am trying to understand how mininet relies on
openvswitch, so sorry if what I say doesn't make any sense.)

Actually, the issue doesn't happen in stretch or buster, or more
precisely, with openvswitch-switch 2.6.2~pre+git20161223-3.

As far as I understand, the reason why mininet complains against
openvswtich is because openvswith-common includes
/usr/bin/ovs-testcontroller since 2.8.1+dfsg1-1. Binary that was part of
openvswitch-testcontroller before. Installing -testcontroller in stretch
or buster makes that mininet also complains.

And it also seems that it was already fixed by upstream in commit
57abd9baef8b3ec3ce3c349829b37022cfef724a. Patch attached to this mail.

Cheers,

  -- Santiago

P.S. Question for openvswitch maintainers: does it make sense to include
back /usr/bin/ovs-testcontroller in the -testcontroller package?
From a5a3485edbb15d2442eb42d776fb9ba370526e7a Mon Sep 17 00:00:00 2001
From: Santiago <santiago.ruano-rin...@telecom-bretagne.eu>
Date: Wed, 29 Nov 2017 18:30:12 +0100
Subject: [PATCH] Add
 debian/patches/upstream_0001-Use-correct-command-name-in-OVSController.patch
 to take into account the three possible names of ovs-testcontroller

Signed-off-by: Santiago <santiago.ruano-rin...@telecom-bretagne.eu>
---
 debian/patches/series  |  1 +
 ...Use-correct-command-name-in-OVSController.patch | 38 ++
 2 files changed, 39 insertions(+)
 create mode 100644 debian/patches/series
 create mode 100644 debian/patches/upstream_0001-Use-correct-command-name-in-OVSController.patch

diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..54f122c
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+upstream_0001-Use-correct-command-name-in-OVSController.patch
diff --git a/debian/patches/upstream_0001-Use-correct-command-name-in-OVSController.patch b/debian/patches/upstream_0001-Use-correct-command-name-in-OVSController.patch
new file mode 100644
index 000..e91ea01
--- /dev/null
+++ b/debian/patches/upstream_0001-Use-correct-command-name-in-OVSController.patch
@@ -0,0 +1,38 @@
+From 57abd9baef8b3ec3ce3c349829b37022cfef724a Mon Sep 17 00:00:00 2001
+From: Bob Lantz <rla...@cs.stanford.edu>
+Date: Tue, 24 May 2016 17:40:00 -0700
+Subject: [PATCH] Use correct command name in OVSController
+
+---
+ mininet/node.py | 10 +-
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/mininet/node.py b/mininet/node.py
+index ea7851b..1e50b51 100644
+--- a/mininet/node.py
 b/mininet/node.py
+@@ -1423,16 +1423,16 @@ def isAvailable( cls ):
+ 
+ class OVSController( Controller ):
+ "Open vSwitch controller"
+-def __init__( self, name, command='ovs-controller', **kwargs ):
+-if quietRun( 'which test-controller' ):
+-command = 'test-controller'
+-Controller.__init__( self, name, command=command, **kwargs )
++def __init__( self, name, **kwargs ):
++kwargs.setdefault( 'command', self.isAvailable() or
++   'ovs-controller' )
++Controller.__init__( self, name, **kwargs )
+ 
+ @classmethod
+ def isAvailable( cls ):
+ return ( quietRun( 'which ovs-controller' ) or
+  quietRun( 'which test-controller' ) or

Bug#881328: mininet requires missing ovs-controller

2017-11-10 Thread Santiago R.R.
Package: mininet
Version: 2.2.2-1
Severity: grave

Hi,

mn tries to run ovs-controller, which has been renamed to
/usr/bin/ovs-testcontroller according to
https://github.com/openvswitch/ovs/blob/9a180f2c002adf73951e0ee9990c44e5e5cd4a0f/NEWS#L600
mininet should Depends or Recomends on openvswitch-testcontroller

$ sudo mn --topo tree,depth=2,fanout=3
*** Creating network
*** Adding controller
*** Adding hosts:
h1 h2 h3 h4 h5 h6 h7 h8 h9
*** Adding switches:
s1 s2 s3 s4
*** Adding links:
(s1, s2) (s1, s3) (s1, s4) (s2, h1) (s2, h2) (s2, h3) (s3, h4) (s3, h5) (s3, 
h6) (s4, h7) (s4, h8) (s4, h9)
*** Configuring hosts
h1 h2 h3 h4 h5 h6 h7 h8 h9
*** Starting controller
c0 Cannot find required executable ovs-controller.
Please make sure that it is installed and available in your $PATH:
(/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)

cheers,

Santiago

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

Kernel: Linux 4.13.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_CO.utf8, LC_CTYPE=es_CO.utf8 (charmap=UTF-8), LANGUAGE=es_CO:es 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mininet depends on:
ii  cgroup-bin0.41-8
ii  iperf 2.0.10+dfsg1-1
ii  libc6 2.24-17
ii  net-tools 1.60+git20161116.90da8a0-1
ii  openvswitch-switch2.8.1+dfsg1-3
ii  python2.7.14-1
ii  python-pkg-resources  36.6.0-1
ii  socat 1.7.3.2-1
ii  telnet0.17-41

mininet recommends no packages.

mininet suggests no packages.

-- no debconf information