Bug#1004913: closing 1004913

[Marcin Kulisz]

close 1004913 2.1.6-1
thanks

Bug#987353: CVE-2020-8903 CVE-2020-8907 CVE-2020-8933

[Marcin Kulisz]

On 2021-05-10 12:16:09, Noah Meyerhans wrote:
> On Mon, May 10, 2021 at 09:00:34PM +0200, Moritz Mühlenhoff wrote:
> > > Hi, since this package was brought into Debian in ~2018, there have been
> > > several transformations in the GCE guest software stack and thus the
> > > current landscape is very different. Google doesn't actually maintain the
> > > official Debian package and we're not sure who is, if anyone. The Google
> > > provided packages are shipped separately and will override the Debian
> > > package if you use them from our repositories. Please see either our 
> > > Google
> > > Cloud docs 
> > > 
> > > or github readme
> > >  for info 
> > > on
> > > the packages we are maintaining and shipping for Debian systems and on the
> > > base Google provided GCE Debian images. Unfortunately, we never did find a
> > > DD sponsor to help maintain our guest packages in Debian on the cadence
> > > that we needed. I would advocate for removing this package from Debian if
> > > we can't find a set of maintainers.
> > 
> > Hi Zach,
> > as it stands google-compute-image-packages won't be part of the next Debian
> > stable release. Givem the last upload was in Oct 2019 the package seems
> > unmaintained anyway, so if noone steps up to maintain it in the next months
> > it's probably best to remove it entirely.
> 
> If we ever want to get to a point where the Debian cloud team is able to
> publish useful images to the Google cloud service, we'll need to get
> this package into shape for inclusion in a stable release.  The lack of
> good maintenance of packages such as this one is a big factor in us not
> being able to do so.  The package is nominally maintained by the cloud
> team, but none of the current members is active in working with it.

I hope that we're be able to change it, but for me fundamental question is if
Google is interested in participating in effort to keep those packages in
Debian main and if so what resources can be committed to do so.
From my side I can say that I'll try to find time to work on the relevant
packages or to sponsor uploads if somebody else want to take on this task.

So for me fist step for restarting this work would be to have a conversation
with Zach about agreeing what need to be done, how are we going to do it and
what commitments are we going to put in place to make it relevant in the long
run.

> As there seems to be interest within some members of the Debian
> community in having Debian-published images available for GCE, we should
> try to solicit help with package maintenance before we kick it out for
> good.

Thanks Noah for motivating me to reply to this email. I think this is worthy 
cause
thus I hope we can have sorted without removing those packages from Debian.
-- 

|_|0|_|  |
|_|_|0|  "Panta rei" |
|0|0|0|  kuLa    |

gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3
3DF1  A4DF  C732  4688  38BC  F121  6869  30DD  58C3  38B3


signature.asc
Description: PGP signature

Bug#864657: ca-certificates-java: Can we have fix for this in Stretch as well, please.

[Marcin Kulisz]

Package: ca-certificates-java
Followup-For: Bug #864657

Hi I just want to add that at the moment Stretch current stable has this broken
to the point that neither openjdk nor ca-certificates-java packages can be
installed making all java dependant apps useless.

It's due to ca-certificates-java dependencies be:
openjdk-7-jre-headless | java7-runtime-headless
and those packages are not available anymore in Stretch.

Instead only openjdk for java8 is available so please provide update to stable
fixing those dependencies by replacing:
openjdk-7-jre-headless | java7-runtime-headless
with
openjdk-8-jre-headless

Bug#920295: buku: No module named buku

[Marcin Kulisz]

Package: buku
Version: 4.1+ds-1
Severity: grave
Justification: renders package unusable

Looks like binary package doesn't contain required modules. When trying to run 
buku
following error pops up:

Traceback (most recent call last):
  File "/usr/bin/buku", line 11, in 
load_entry_point('buku==4.1', 'console_scripts', 'buku')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 487, in 
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2728, 
in load_entry_point
return ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2346, 
in load
return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2352, 
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
ModuleNotFoundError: No module named 'buku

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

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

Versions of packages buku depends on:
ii  python3   3.7.1-3
ii  python3-bs4   4.6.3-2
ii  python3-certifi   2018.8.24-1
ii  python3-cryptography  2.3-1
ii  python3-html5lib  1.0.1-1
ii  python3-urllib3   1.24-1

buku recommends no packages.

buku suggests no packages.

-- no debconf information

Bug#852245: python2-pyro4: Pyro4 require python selectors or selectors34 which are unavailable

[Marcin Kulisz]

Package: python2-pyro4
Version: 4.53-1
Severity: grave
Justification: renders package unusable

When trying to import Pyro4 in python2.7 following pops up (example is from
ipython but exactly the same output is from the app when trying to use it):

In [1]: import Pyro4
---
ImportError   Traceback (most recent call last)
 in ()
> 1 import Pyro4

/usr/lib/python2.7/dist-packages/Pyro4/__init__.pyc in ()
 64
 65 # import the required Pyro symbols into this package
---> 66 from Pyro4.core import URI, Proxy, Daemon, callback, batch, async, 
oneway, expose, behavior, current_context
 67 from Pyro4.naming import locateNS, resolve
 68 from Pyro4.futures import Future

/usr/lib/python2.7/dist-packages/Pyro4/core.py in ()
 19 from Pyro4 import errors, threadutil, socketutil, util, constants, 
message
 20 from Pyro4.socketserver.threadpoolserver import SocketServer_Threadpool
---> 21 from Pyro4.socketserver.multiplexserver import SocketServer_Multiplex
 22
 23 __all__ = ["URI", "Proxy", "Daemon", "current_context", "callback", 
"batch", "async", "expose", "behavior", "oneway"]

/usr/lib/python2.7/dist-packages/Pyro4/socketserver/multiplexserver.py in 
()
 16 import selectors
 17 except ImportError:
---> 18 import selectors34 as selectors
 19 from Pyro4 import socketutil, errors, util
 20 import Pyro4.constants

ImportError: No module named selectors34


'selectors34' is a backport of python3.4 'selectors' to python2.7, which is
replacement for python2.7 'select'.
Problem is that 'selectors34' is not packaged thus not available in Stretch and
I'm afraid it's too late for it to be allowed in.

Therefore I see following options:
1. Revert python2-pyro4 (src:Pyro4) to 4.43-1 this one is using 'select' thus
  doesn't require 'selectors34'.
2. Patch 4.53-1 with something like this:

if sys.version_info[:2] == (2,7):
   import select as selectors
else:
import selectors

in the socetserver/multiplexserver.py instead of try except for importing it
and purge requires.txt file from the egg-info.

3. Package selectors34 and convince release managers to allow it in.

Bug#804642: (no subject)

[Marcin Kulisz]

Hi Andreas,

thx for this bug report.

I think I have patch ready once I'll test it I'll ask sponsor for upload.
Hopefully it's not going to be too long.

BTW can you share what tool allowed you to discover this bug?
-- 

|_|0|_|  |
|_|_|0| "Heghlu'Meh QaQ jajVam"  |
|0|0|0|  kuLa -  |

gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3
3DF1 A4DF C732 4688 38BC F121 6869 30DD  58C3 38B3


signature.asc
Description: PGP signature

Bug#724105: Is package gone from mentors?

[Marcin Kulisz]

Hi,

I'm not capable of uploading it but I'd like to have a look into this package.
Unfortunately it looks like it's gone from mentors and there is no provided VCS
for this package in the PTS.

Can you re-upload it or send a link to VCS?

BTW pls cc me in as I'm not subscribing this bug.
-- 

|_|0|_|  |
|_|_|0| Heghlu'Meh QaQ jajVam  |
|0|0|0|  kuLa -  |

gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3
3DF1 A4DF C732 4688 38BC F121 6869 30DD  58C3 38B3


signature.asc
Description: Digital signature

Bug#724105: Is package gone from mentors?

[Marcin Kulisz]

On 2014-10-14 10:22:17, Roy Marples wrote:
 Hi

Hello,

 All of my packages (dhcpcd, dhcpcd-gtk, openresolv) are timing out on
 mentors.
 I've tried asking various people to upload it or do something with it but
 nothing happens.

Well, unfortunately with Debian community people have to be very patient as to
have anything done in timely manner you have to do it your self.

 It seems Debian no longer cares about my software, or the mentor process is
 not working.

I'd say the latter and I'd like to say do not give up but unfortunately I know
the feeling when unproductively waiting for sponsor to upload your package.

 As a result of this, I've re-purposed my non booting debian partition (non
 booting thanks to systemd) for something else and no longer have the package
 updates available.

Shame to see this reply but there is not too much I can do about it.

If you don't intend to maintain above packages anymore can you fill ITO bugs
against them?
I'm not sure yet but maybe I'll take over of openresolv if you want to get rid
of it.
-- 

|_|0|_|  |
|_|_|0| Heghlu'Meh QaQ jajVam  |
|0|0|0|  kuLa -  |

gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3
3DF1 A4DF C732 4688 38BC F121 6869 30DD  58C3 38B3


signature.asc
Description: Digital signature

Bug#751264: Confirmation

[Marcin Kulisz]

I can confirm that behaviour on fully updated (at the time of sending this
emai) sid with awscli_1.2.9-2.
-- 

|_|0|_|  |
|_|_|0| Heghlu'Meh QaQ jajVam  |
|0|0|0|  kuLa -  |

gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3
3DF1 A4DF C732 4688 38BC F121 6869 30DD  58C3 38B3


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

Bug#741522: python-libcloud in sid

[Marcin Kulisz]

Looks like in jessie and sid we already have python-libcloud_0.14.1-1, so this
issue should go.
-- 

|_|0|_|  |
|_|_|0| Heghlu'Meh QaQ jajVam  |
|0|0|0|  kuLa -  |

gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3
3DF1 A4DF C732 4688 38BC F121 6869 30DD  58C3 38B3


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

Bug#741448: Downgrading severity to important

[Marcin Kulisz]

severity 741448 important
stop

Hi Andreas, hi all,

I can't reproduce your problem I'm using grive my self and it's working for me,
therefore I'm convinced that it's not grave for sure in my opinion it's not
severe either.

Andreas as Michael suggested can you remove all grive metadata and
re-authenticate it with gdrive and share if it's working now for you?
-- 

|_|0|_|  |
|_|_|0| Heghlu'Meh QaQ jajVam  |
|0|0|0|  kuLa -  |

gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3
3DF1 A4DF C732 4688 38BC F121 6869 30DD  58C3 38B3


signature.asc
Description: Digital signature

Bug#730632: calligra: FTBFS with libpqxx-4.0

[Marcin Kulisz]

On 2013-11-27 13:02:08, Lisandro Damián Nicanor Pérez Meyer wrote:
 CCing the release.d.o bug.
 
 Marcin: As you already stated, Calligra won't switch to libpqxx4 but to 
 libpq. 
 But that will happen (hopefully) early next year.
 
 We really don't want to drop psql support. Is there any chance to have 
 libpqxx3 back with a bigger epoch until that release? The dev package is 
 libpqxx3-dev, so I think there will be no problem in having both versions 3 
 and 4 in the archive (you will have to drop the dummy package).

Lisandro,

Dropping versioning from *-dev *-doc and *-dbg was a conclusion to my decision
of not going with support for more then one libpqxx version in Debian. Having
above in mind I'm not saying that there is now way back for libpqxx3-dev etc..

But we have to consider at least 2 below points:
1. Calligra is switching to libpq according to you 'early next year' so even if
  early mean end of March it's only 4 months away. This is rather short time
  from now. 
2. On 2012-06-03 I sent an email to debian-qt-...@lists.debian.org with
  information that libpqxx4 is in experimental. In the same email I attached
  calligra build log against libpqxx4 and an information that it FTBFS. None of
  debian-qt-kde team members act on this email (at least I'm not aware of it)
  or ever replied to me for example with the request you just made.
  Ok, there is partially my fault, as I didn't filed bug against calligra at
  this time but still it was 16 months ago.
  
So, for now my position on having 2 libpqxx versions in Debian is as follow
(unless you convince me otherwise):
I'm going to maintain only libpqxx4 in Debian for now, as for me uploading
libpqxx3 for 3-4 months and then removing it is just additional work for for my
sponsor, ftp and release teams and me of course and I prefer to avoid this as
for now much as I can.
I'm happy to reconsider re-uploading libpqxx3 but no earlier then 2 months
before freeze, if there will be risk that calligra with libpq support won't make
to Jessie.

All above are my thoughts about this subject but they are not set in stone, so
if you have anything to add which may make me change my mind just please let me
know, I'm really opened for other solutions if they exist.

I'm not sure if I am in the position to suggest you what to do now but, if I
were you I would drop postgres support for this 3-4 months, inform users about
it and try push upstream to release new version with libpq support as fast as
they can or at least declare when are they going to do so.
-- 

|_|0|_|  |
|_|_|0| Heghlu'Meh QaQ jajVam  |
|0|0|0|  kuLa -  |

gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3
3DF1 A4DF C732 4688 38BC F121 6869 30DD  58C3 38B3


signature.asc
Description: Digital signature

Bug#730632: calligra: FTBFS with libpqxx-4.0

[Marcin Kulisz (kuLa)]

Package: calligra
Version: 1:2.6.4-1
Severity: serious

Hi Guys,
I'm maintaining libpqxx and as it just made to testing transition is now in
progress. Unfortunately Calligra is having problems with it. I suppose it's
caused by this (300871[1]) upstream bug.

As the upstream is preparing to abandon libpqxx in favor of libpq I'm not sure
what your further actions are going to be, thus letting you know about this
FTBFS.

1. https://bugs.kde.org/show_bug.cgi?id=300871


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

Bug#729785: Copyright review for the package libpqxx 4.0.1-2.

[Marcin Kulisz]

On 2013-11-17 20:43:05, Charles Plessy wrote:
 Package: libpqxx
 Version: 4.0.1-1
 Severity: serious
 Control: user debian-le...@lists.debian.org
 Control: usertags -1 one-copyright-review
 
 Dear Marcin,
 
Hi Charles

 In the hope of speeding up and strenghtening the processing of the NEW queue I
 had a look at your package libpqxx 4.0.1-2.  The rationale is explained in
 the proposal in the following wiki page.

Thx a lot for taking time and doing so.

 I found that libpqxx 4.0.1 contains at least one minified JavaScript file,
 doc/html/Reference/jquery.js, for which there is no coresponding source, and
 that is mentionned in the Debian copyright file.  If it works, it would be
 better to replace this file with a link to the same file provided by
 libjs-jquery.  You may find other advices on the debian-mentors mailing list 
 on
 how to deal with the situation.
 
I'm already providing link for jquery.js in libpqxx-doc.links, it is documented
in README.Debian, sorry for not giving explicit information about it in dch.
If you think it'll be beneficial for the future I'll add such information in to
dch with the next commit. Hopefully this is sorting this problem.

On the other hand can you tell me how did you found this problem as according
to the files listing from
http://ftp-master.debian.org/new/libpqxx_4.0.1-2.html,
my build logs and actual package check link is there, lintian is not
complaining (and it used to before), so I'm a bit confused.

 On a more minor side, the copyright statement of Bart Samwel in
 tools/template2mak.py is also missing from the Debian copyright file.

I'll fixed soon as alioth is up again.

 Have a nice Sunday,

It's already Tuesday :-)
Thx a lot for good wishes (the same for you) and one more thx for the review.
-- 

|_|0|_|  |
|_|_|0| Heghlu'Meh QaQ jajVam  |
|0|0|0|  kuLa -  |

gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3
3DF1 A4DF C732 4688 38BC F121 6869 30DD  58C3 38B3


signature.asc
Description: Digital signature

Bug#672021: libpqxx4 waiting for upload

[Marcin Kulisz]

As promised latest version just have been committed into repo and now is
waiting to be uploaded.
My sponsor promised to do it as soon as possible, once it's done this bug will
be closed.
-- 

|_|0|_|  |
|_|_|0| Heghlu'Meh QaQ jajVam  |
|0|0|0|  kuLa -  |

gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3
3DF1 A4DF C732 4688 38BC  F121 6869 30DD 58C3 38B3



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

Bug#672021: new version (4.0)

[Marcin Kulisz]

Hi all, 
Thx Lucas for reporting this and thx Matthias for a patch, I'm thinking about
persuading my sponsor to upload v4.0 which is ready for last few months and is
fixing this bug, but non the less I'm going to apply this nice cxxflags
variable into HEAD so it's going to appear with 4.0.
Please be patient for few more days.
-- 

|_|0|_|  |
|_|_|0| Heghlu'Meh QaQ jajVam  |
|0|0|0|  kuLa -  |

gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3
3DF1 A4DF C732 4688 38BC  F121 6869 30DD 58C3 38B3



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

Bug#655480: Info received (Bug#655480 closed by Aron Xu a...@debian.org (Bug#655480: fixed in axis2c 1.6.0-2.2))

[Marcin Kulisz]

reopen 655480
thanks

As stated in my previous email and due to lack of reply I'm reopening it.
-- 
Marcin Kulisz



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

Bug#655480: closed by Aron Xu a...@debian.org (Bug#655480: fixed in axis2c 1.6.0-2.2)

[Marcin Kulisz]

On 12/01/12 19:21, Debian Bug Tracking System wrote:
 Closes: 594707 625309 655214 655480
 Changes: 
  axis2c (1.6.0-2.2) unstable; urgency=low
  .
* Non-maintainer upload.
* Fix ftbfs with gcc-4.6 -Werror (Closes: #625309)
  Thanks to Peter Green for most of the work.


* Remove Build-Depends on libxml2, since use of guththila is
  the expected behaviour. (Closes: #655480).

I don't think that this bug (#655480) should be closed that way.
Removing one of the build options just like this is only a getting rid
of symptoms not a problem it self.
Some people (including me) will need libxml2 parser not guththila, thus
provided solution is unfortunately not a valid resolution for this issue.

* Install libaxis2*.[so,a]*
* Update debian/axis2c.load to make it load correctly.
  (Closes: #594707, #655214)

--
Marcin Kulisz



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

Bug#655480: axis2c: FTBFS with --enable-libxml2=yes

[Marcin Kulisz (kuLa)]

Source: axis2c
Version: 1.6.0-2.1
Severity: serious
Justification: 4

error is cused by lack of libaxis2_parser.la and libaxis2_parser.so, files are
compiled but not copyied into relevant directories (paths)

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.1.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



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