Bug#1072934: shadowsocks-libev: Consider removing the package

[Andrea Pappacoda]

On Mon, 10 Jun 2024 11:55:30 -0400 Boyuan Yang  wrote:
> Following the previous communication in March, I am considering to take action
> and remove related packages in the ss-libev ecosystem. Package 
> shadowsocks-libev
> will be removed together with simple-obfs.

Hi Boyuan, I don't know what previous communication you are referring
to, but I support your proposal! shadowsocks-libev has been deprecated
upstream for quite a while in favour of shadowsocks-rust, and while this
isn't an issue for me personally, the fact that the package builds only
with MbedTLS 2.x and fails to build with 3.6 (which I'm trying to
transition to) kinda bothers me.

Hence, if there were reasons to remove shadowsocks-libev from the
archive, now there is one more :)

Thanks again for your efforts! Bye.

Bug#1069357: cpp-httplib: FTBFS fixed on mentors

[Andrea Pappacoda]

Hi all, I've uploaded a fixed version on Mentors, available here: 
https://mentors.debian.net/package/cpp-httplib/


If you're a DD, I'd greatly appreciate a sponsored upload :D

Bye.

--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Bug#1069357: marked as pending in cpp-httplib

[Andrea Pappacoda]

Control: tag -1 pending

Hello,

Bug #1069357 in cpp-httplib reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/cpp-httplib/-/commit/da7a05c0c81b4105baf63a8919ed2806132aabf8


d/patches: use static certs for tests

Closes: #1069357
Closes: #1073440


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1069357

Bug#1073440: marked as pending in cpp-httplib

[Andrea Pappacoda]

Control: tag -1 pending

Hello,

Bug #1073440 in cpp-httplib reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/cpp-httplib/-/commit/da7a05c0c81b4105baf63a8919ed2806132aabf8


d/patches: use static certs for tests

Closes: #1069357
Closes: #1073440


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1073440

Bug#1069357: marked as pending in cpp-httplib

[Andrea Pappacoda]

Control: tag -1 pending

Hello,

Bug #1069357 in cpp-httplib reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/cpp-httplib/-/commit/b1ac1a8091c049edf533dc92fce345005508998c


d/patches: use static certs for tests

Closes: #1069357
Closes: #1073440


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1069357

Bug#1073440: marked as pending in cpp-httplib

[Andrea Pappacoda]

Control: tag -1 pending

Hello,

Bug #1073440 in cpp-httplib reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/cpp-httplib/-/commit/b1ac1a8091c049edf533dc92fce345005508998c


d/patches: use static certs for tests

Closes: #1069357
Closes: #1073440


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1073440

Bug#1069357: OpenSSL 3.2 breaks cpp-httplib

[Andrea Pappacoda]

Control: forwarded -1 https://github.com/yhirose/cpp-httplib/issues/1798

Hi all, a Gentoo developer has confirmed that this issue has been 
caused by the OpenSSL 3.2 update, as I suspected. In almost two months, 
nobody has been able to provide a fix. What should I do?

Bug#1067303: trash-cli in Debian: test problems again

[Andrea Francia]

Hi Jonathan and Lucas,
  I solved the problem in the new release (0.24.5.26).

I tested it with these commands:
git clone https://salsa.debian.org/debian/trash-cli.git
cd trash-cli
git remote add upstream https://github.com/andreafrancia/trash-cli
git fetch upstream
git merge 0.24.5.26
debuild -b -uc -us

Here the results of the build:
andrea@lima-default:~/trash-cli$ debuild -b -uc -us
 dpkg-buildpackage -us -uc -ui -b
dpkg-buildpackage: info: source package trash-cli
dpkg-buildpackage: info: source version 0.23.11.10-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Jonathan Dowland 
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture arm64
 fakeroot debian/rules clean
dh clean --with python3 --buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
   dh_autoreconf_clean -O--buildsystem=pybuild
   dh_clean -O--buildsystem=pybuild
 debian/rules build
dh build --with python3 --buildsystem=pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
   dh_auto_build -O--buildsystem=pybuild
I: pybuild plugin_pyproject:107: Building wheel for python3.11 with "build"
module
I: pybuild base:240: python3.11 -m build --skip-dependency-check
--no-isolation --wheel --outdir
/home/andrea.linux/trash-cli/.pybuild/cpython3_3.11
* Building wheel...
running bdist_wheel
running build
running build_py
creating build
creating build/lib
creating build/lib/trashcli
copying trashcli/trash.py -> build/lib/trashcli
copying trashcli/fs.py -> build/lib/trashcli
copying trashcli/file_system_reader.py -> build/lib/trashcli
copying trashcli/trash_dirs_scanner.py -> build/lib/trashcli
copying trashcli/shell_completion.py -> build/lib/trashcli
copying trashcli/__init__.py -> build/lib/trashcli
copying trashcli/compat.py -> build/lib/trashcli
creating build/lib/trashcli/empty
copying trashcli/empty/existing_file_remover.py -> build/lib/trashcli/empty
copying trashcli/empty/empty_action.py -> build/lib/trashcli/empty
copying trashcli/empty/errors.py -> build/lib/trashcli/empty
copying trashcli/empty/guard.py -> build/lib/trashcli/empty
copying trashcli/empty/parser.py -> build/lib/trashcli/empty
copying trashcli/empty/parse_reply.py -> build/lib/trashcli/empty
copying trashcli/empty/delete_according_date.py -> build/lib/trashcli/empty
copying trashcli/empty/prepare_output_message.py -> build/lib/trashcli/empty
copying trashcli/empty/main.py -> build/lib/trashcli/empty
copying trashcli/empty/console.py -> build/lib/trashcli/empty
copying trashcli/empty/empty_cmd.py -> build/lib/trashcli/empty
copying trashcli/empty/top_trash_dir_rules_file_system_reader.py ->
build/lib/trashcli/empty
copying trashcli/empty/is_input_interactive.py -> build/lib/trashcli/empty
copying trashcli/empty/description.py -> build/lib/trashcli/empty
copying trashcli/empty/clock.py -> build/lib/trashcli/empty
copying trashcli/empty/older_than.py -> build/lib/trashcli/empty
copying trashcli/empty/file_system_dir_reader.py -> build/lib/trashcli/empty
copying trashcli/empty/emptier.py -> build/lib/trashcli/empty
copying trashcli/empty/__init__.py -> build/lib/trashcli/empty
copying trashcli/empty/print_time_action.py -> build/lib/trashcli/empty
copying trashcli/empty/user.py -> build/lib/trashcli/empty
creating build/lib/trashcli/lib
copying trashcli/lib/my_input.py -> build/lib/trashcli/lib
copying trashcli/lib/my_permission_error.py -> build/lib/trashcli/lib
copying trashcli/lib/enum_repr.py -> build/lib/trashcli/lib
copying trashcli/lib/trash_dirs.py -> build/lib/trashcli/lib
copying trashcli/lib/logger.py -> build/lib/trashcli/lib
copying trashcli/lib/user_info.py -> build/lib/trashcli/lib
copying trashcli/lib/dir_checker.py -> build/lib/trashcli/lib
copying trashcli/lib/print_version.py -> build/lib/trashcli/lib
copying trashcli/lib/environ.py -> build/lib/trashcli/lib
copying trashcli/lib/exit_codes.py -> build/lib/trashcli/lib
copying trashcli/lib/__init__.py -> build/lib/trashcli/lib
copying trashcli/lib/trash_dir_reader.py -> build/lib/trashcli/lib
copying trashcli/lib/dir_reader.py -> build/lib/trashcli/lib
copying trashcli/lib/path_of_backup_copy.py -> build/lib/trashcli/lib
creating build/lib/trashcli/list
copying trashcli/list/fs.py -> build/lib/trashcli/list
copying trashcli/list/parser.py -> build/lib/trashcli/list
copying trashcli/list/main.py -> build/lib/trashcli/list
copying trashcli/list/list_trash_action.py -> build/lib/trashcli/list
copying trashcli/list/trash_dir_selector.py -> build/lib/trashcli/list
copying trashcli/list/extractors.py -> build/lib/trashcli/list
copying trashcli/list/__init__.py -> build/lib/trashcli/list
creating build/lib/trashcli/list/minor_actions
copying trashcli/list/minor_actions/debug_volumes.py -

Bug#1069357: cpp-httplib: FTBFS: Test SSLClientServerTest.ClientCertPresent fails with timeout

[Andrea Pappacoda]

Hi all,

it indeed seems that this issue hasn't been caused by any recent
cpp-httplib update, since I've been able to reproduce it on versions as
old as 0.10.8+ds-1.

I suspect maybe an OpenSSL update broke something for this package? Why
didn't ci.d.n notice the breakage?

I'll try to see if I can find the breaking update...

Bug#1067303: trash-cli in Debian: test problems again

[Andrea Francia]

Hi Jonathan,
  I think I could solve this problem if only I knew how to reproduce the
problem on my machine.

I am not an expert on how package builds work on Debian but I can get a
virtual machine with a Debian on it.
I would just need the steps to reproduce the error reported by Lucas.

I will also try to better document the use of tox in trash-cli, I am using
it but I am not familiar with it, it is likely that I need to improve the
use of tox in trash-cli.

If someone can send me the commands to reproduce your results I am sure I
can solve it in no time.

Regards and thanks for the report

Il giorno mer 8 mag 2024 alle ore 15:13 Jonathan Dowland 
ha scritto:

> Hi Andrea
>
> I'm afraid we've hit problems running the trash-cli test suite in Debian
> again. Our automated processes have removed the package from "testing"
> for the time being.
>
> A trace of the errors is available here:
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067303>
>
> It looks like the Debian packaging invokes pytest to run the test suite.
> Does that make sense today?
>
> The errors are all of the form
>
> > E   ModuleNotFoundError: No module named 'scripts'
>
> which implies an import path issue. Any clues?
>
> I've explored moving to your latest tag, and also trying to use tox for
> running the test suite, but I haven't got something that passes yet.
> (For tox the issue is that the test suite needs to run offline, so it
> behaves very differently to if I just ran "tox" on my developer machine,
> which worked after I adjusted Python 3.10 to 3.11 in tox.ini and changed
> one test.)
>
> If you've got any time or clues or suggestions about what to try next
> I'd really appreciate it. I don't do much Python packaging (trash-cli
> is currently my own Python package) and I have trouble keeping up with
> what the current Python test, build, project, configure fashions are, as
> well as the same for the Debian packaging layer (we've had several
> Debian/Python build integrations over the years too).
>
>
>
> Best wishes,
>
> --
> Jonathan Dowland
> ✎j...@debian.org
>   https://jmtd.net
>
>

-- 
Andrea Francia http://andreafrancia.it

Bug#1070498: marked as pending in libvirt

[Andrea Bolognani]

Control: tag -1 pending

Hello,

Bug #1070498 in libvirt reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/libvirt-team/libvirt/-/commit/13f1f61aacf4277b0496049fd2df78352b4c5c30


patches: Add backport/vsh-Don-t-init-history-in-cmdComplete.patch

Fixes FTBFS.

Closes: #1070498


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1070498

Bug#1069357: Fwd: Re: Bug#1069357: cpp-httplib: FTBFS on arm64: dh_auto_test: error: cd obj-aarch64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test --timeout-m

[Andrea Pappacoda]

 Messaggio originale 
Da: Andrea Pappacoda 
Inviato il: 3 maggio 2024 07:39:59 CEST
A: Stuart Prescott 
Oggetto: Re: Bug#1069357: cpp-httplib: FTBFS on arm64: dh_auto_test: error: cd 
obj-aarch64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 
MESON_TESTTHREADS=4 meson test --timeout-multiplier=3 
--test-args=--gtest_filter=-\*_Online returned exit code 1

Hi Stuart, thanks for the ping.

I've been aware of these test failures for a while, but haven't been able to 
determine the cause of them. They actually ran successfully when I first 
uploaded the package, but broke after some package upload which I haven't yet 
identified.

It is possible that this is indeed a bug in cpp-httplib, but it has only showed 
up after an unknown package has been updated in unstable.

Citing a previous mail of mine, sent to Bastian Germann the 7th of April:

> When I uploaded the package to mentors the tests ran fine in an unstable 
> chroot, and still do when running them on my local machine (which runs 
> Testing). I haven't yet tried running them in a chroot which pulls things 
> from experimental, but if I run them now in an unstable chroot I get a 
> failure in the SSLClientServerTest.ClientCertPresent test, and a timeout 
> afterwards.

The issue shows up in cpp-httplib's Server::listen() function.

Do you have any suggestions regarding how I can "bisect" such an issue?

Thanks!

P.S. this mail may look broken - I've sent it from my phone.

Bug#1068203: spectrwm: hard-coded dependency on pre-t64 library

[Andrea Bolognani]

On Tue, Apr 02, 2024 at 12:02:53AM +0200, Sebastian Ramacher wrote:
> On 2024-04-01 23:39:37 +0200, Andrea Bolognani wrote:
> > The problem with it, and the reason why a manual dependency is used
> > in that case, is that ${shlib:Depends} will not pick it up, since
> > it's dlopen()ed rather than linked against.
> > 
> > Do you have any suggestions on how to handle this in a way that plays
> > well with the 64-bit time_t transition?
> 
> You could derive it from the the dependencies of libxt-dev during the
> build or for the time being simply change the dependency based on the
> rename of the libxt6 -- provided that spectrwm is compatible with the
> new ABI.

I just created [1] which should take care of the issue. It would be
nice if you could take a look.

To be honest, I haven't followed the 64-bit time_t transition very
closely. Do I understand correctly that the SONAME has been changed
without renaming the files on disk at the same time? That feels kinda
weird, but I guess it has the nice side-effect of not breaking [2],
so that's good :)

I also see that libxt6t64 Provides: libxt6, so I'm not sure why the
dependency on the old name would be a problem? Wasn't that introduced
specifically to take care of this sort of things?


[1] https://salsa.debian.org/debian/spectrwm/-/merge_requests/7
[2] 
https://salsa.debian.org/debian/spectrwm/-/blob/debian/latest/debian/patches/debian/Adapt-libswmhack.patch#L71-72
-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1068203: spectrwm: hard-coded dependency on pre-t64 library

[Andrea Bolognani]

On Mon, Apr 01, 2024 at 10:37:03PM +0200, Sebastian Ramacher wrote:
> Source: spectrwm
> Version: 3.5.1-1
> Severity: serious
> X-Debbugs-Cc: sramac...@debian.org
> 
> spectrwm builds a packages with a hard-coded dependency on a library
> package involved in the time_t 64 transition. This dependency needs to
> be updated.

It would be useful if you could be more specific. I guess you're
talking about the dependency on libxt6?

The problem with it, and the reason why a manual dependency is used
in that case, is that ${shlib:Depends} will not pick it up, since
it's dlopen()ed rather than linked against.

Do you have any suggestions on how to handle this in a way that plays
well with the 64-bit time_t transition?

Thanks.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1063252: Proposed fix broke pristine-tar for me

[Andrea Pappacoda]

Hi, thanks for your fix!

Unfortunately it seems that your patch has broke tarball generation for 
one of the packages I maintain, dynarmic.


   $ gbp export-orig
   gbp:info: Creating /home/tachi/dev/deb/dynarmic_6.5.0+ds.orig.tar.xz
   gbp:error: Pristine-tar couldn't verify 
"dynarmic_6.5.0+ds.orig.tar.xz": pristine-tar: 
/home/tachi/dev/deb/dynarmic/../dynarmic_6.5.0+ds.orig.tar.xz does not 
match stored hash (expected 
46a18274c7d15c9bcc9eced74d050af412728ebf03083b76fb650b70acf8, got 
7b56e580ab2c12003490dc2e2708106f37d51ebe4588b377f7557d5f7db34a6b)


I've been able to solve this issue locally by manually editing the `if 
(!$threads_set)` check to push `-T2` instead of `-T1` if no `-T` option 
was previously set, but I don't fully understand why this solves the 
issue.


Wouldn't it be better to unconditionally pass `-T0` and depend on 
xz-utils >= 5.3.0 so that the multi-threaded compressor is always used 
and the output format is the same regardless of the machine used to 
generate the compressed archive?


Thanks again!

Bug#1055517: opensysusers: modifies host system instead of target environment

[Andrea Pappacoda]

Hi Ansgar,

On Tue, 07 Nov 2023 19:38:25 +0100 Ansgar  wrote:
> opensysusers doesn't really implement the `--root` option (though it
> pretends a bit).  Functions like `add_group` always access
> `/etc/group` and use tools like `groupadd`:
> 
> ```sh
> grep -q "^$1:" /etc/group || groupadd -r "$1"
> ```
> 
> So they will always modify the host system, even when supposed to
> operate on some chroot environment.
> 
> Applying changes intended for some other environment to the host
> system looks like a potential security issue.

Thanks for the report, I wasn't aware of this issue and I agree with you
that yeah, this can be a security issue, and quite an unexpeted
behaviour.

How do you think this should be handled? opensysusers is pretty much
dead upstream (they accept patches, but the Artix Linux community isn't
working on it anymore), so I don't expect them to fix this bug. I'll
report it though.

Still, groupadd and useradd support a "--root" option which seems to do
exactly what we need here, so writing a patch to fix the issue looks
reasonable. I'm not sure how to test such patch though.

> AFAIR there are other incompatibilities with systemd-sysusers so that
> opensysusers should arguably not claim to be a compatible drop-in
> replacement.

This has been discussed both recently and some years ago, and while
using opensysusers as a drop-in replacement seemed appropriate in the
past, I don't think it still is *that* compelling, not because using a
systemd-sysusers alternative doesn't make sense (I have personally
worked to develop one in the past), but because opensysusers is
Linux-only, and it can be used in the same exact scenarios as the
standalone version of systemd-sysusers, so from a technical point of
view I don't really see opensysusers' usefulness anymore (a standalone
version of systemd-sysusers hasn't always existed). You could say that
opensysusers is "more secure" because it isn't written in C, but the
sh scripting language isn't exactly that secure compared to e.g. Rust
or Go.

In conclusion, I'm still not sure what the best thing to do right now
is. For now, I'll limit myself at fixing this bug.

Thanks again! Bye :)

Bug#1055514: opensysusers: ineffective diversion of /bin/systemd-sysusers due to /usr-merge and DEP17

[Andrea Pappacoda]

Hi Helmut, thanks for your report!

Il giorno mar 7 nov 2023 alle 18:07:56 +01:00:00, Helmut Grohne 
 ha scritto:
opensysusers diverts /bin/systemd-sysusers. systemd has moved this 
file
to /usr/bin/systemd-sysusers in version 255~rc1-1. While this change 
is
not visible in an installation, the diversion no longer matches it. 
Thus

what ends up at systemd-sysusers now depends on the order of unpacks.
The diversion has become ineffective. This is a known problem category
and documented in DEP17[1] as P3.

Usually, the recommended mitigation for this kind of problem is
duplicating the diversion (M18) such that both /bin/systemd-sysusers 
and

/usr/bin/systemd-sysusers are diverted. I'm attaching a patch for this
approach, but I think this is not the preferred solution for this 
case.


I dug deeper as to why opensysusers would divert systemd-sysusers,
talked to systemd maintainers and Thomas Goirand and read about 
#947847

in the process. Given this background, I believe that the use of a
diversion is not a good solution and this was echoed by the CTTE
decision, which declined to overrule and considered diversion a
mechanism for experimentation. Three years later and with two stable
releases including opensysusers I hope we are past the experimentation
phase. The diversion setup bears a significant downside: While the API
existing API of the sysusers interface is relatively stable, systemd
keeps adding features and when systemd calls systemd-sysusers it wants
to be able to rely on its latest features. A diverted systemd-sysusers
may not provide what is needed here. Looking deeper into policy 
sections

7.4 and 7.5, the virtual package systemd-sysusers looks similar to
mail-transport-agent where each implementation
provides+conflicts+replaces mail-transport-agent. I think opensysusers
should do the same. Once doing so, the diversion (and thus this bug)
goes away entirely. The downside is that opensysusers and systemd are 
no

longer coinstallable. I'm also attaching a patch for this.


I do agree with this reasoning. As mentioned in one of the old threads 
about this, in my opinion it would've been better to have a general, 
more restricted "sysusers" alternative command which could've been 
provided by opensysusers and systemd-sysusers, and would be used by 
things like dh_installsysusers and the like. Stepping into the 
"systemd-" namespace without actually supporting all the features *and* 
closely following new feature additions is asking for trouble. And, 
since the upstream developers (i.e. the Artix Linux maintainers) 
stopped development in favour of systemd-standalone-sysusers[1], I'm 
now more inclined to change approach and drop diversions.



I caution that Thomas Goirand disagrees with this approach and
recommends that these packages remain coinstallable and that users may
choose the implementation. On the flip side, a user cannot choose to
have systemd as the provider of systemd-sysusers when opensysusers is
installed.


I get Thomas' point, and I'd really like if I could keep offering 
opensysusers as a valid alternative to systemd-sysusers, but given its 
current state I don't think it's reasonable to keep doing so, 
especially considering that there's systemd-standalone-sysusers. One 
use case which systemd-standalone-sysusers doesn't cover though is 
support for non-Linux OSes, but to be fair opensysusers doesn't either. 
I did start working on a POSIX reimplemetation of the sysusers concept 
so that it could replace opensysusers entirely and also run on (the now 
dead) Debian/kFreeBSD and also Hurd, but never actually finished it.



A possible compromise could be that opensysusers stops diverting
systemd-sysusers and installs the symbolic link without diversion such
that systemd becomes the preferred provider when coinstalled. It could
detect removal of systemd using file triggers and then reinstate the
link. Such a setup also requires little cooperation from systemd
maintainers, but it relies on an symbolic link that is completely
untracked by dpkg, so there is some fragility to be found here whereas
the conflict is conceptually simpler.


I'm not sure I follow, but choosing an approach which isn't tracked by 
dpkg doesn't sound right to me.


In any case, something needs to be done here. The latest systemd 
upload

now declares an unversioned conflict with opensysusers. It can become
versioned once opensysusers has addressed this bug in some way.


I want to fix this too, and I really thank you for the help. I'm 
inclined to drop the diversions, but I'd first like to fully understand 
the consequences (e.g. would something break for someone?).


Bye :D

[1]: https://forum.artixlinux.org/index.php/topic,1839.0.html

Bug#1041249: cpp-httplib: FTBFS on s390x: ../test/test.cc:5462: Failure

[Andrea Pappacoda]

Hi Emanuele, thank you for the info. I'm aware of that, and even reported the 
issue upstream[1], but the maintainer isn't interested in fixing it.

I would debug and maybe fix the issue myself, but as a DM I don't have easy 
access to porter boxes and honestly the long wait and inability to get access 
to all of them is quite demotivating. I have asked for an s390x porter box a 
couple of days ago and still didn't get access to it, and I'd now have to 
re-ask for and armhf one, and wait again... I'll eventually fix this, but I 
cannot now for factors outside of my control.

If you could please help debug the issue on the architectures you have access 
to I'd be very grateful. If you don't have time, no worries, I fully understand 
it, but please be patient :)

Thanks!

[1]: https://github.com/yhirose/cpp-httplib/issues/1199

Il 21 agosto 2023 10:53:23 CEST, Emanuele Rocca  ha scritto:
>I've bumped into a very similar failure on armhf too, so the problem is
>probably not s390x-specific.
>
>Note that the build succeeded on a second try.

Bug#1043297: src:dynarmic: fails to migrate to testing for too long: unresolved RC issue

[Andrea Pappacoda]

On Tue, 8 Aug 2023 20:28:16 +0200 Paul Gevers  wrote:
> Source: dynarmic
> Version: 6.4.5+ds-1
> Severity: serious
> Control: close -1 6.4.8+ds-2
> Tags: sid trixie
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> Control: block -1 by 1041270
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing 
> and unstable for more than 30 days as having a Release Critical bug in 
> testing [1]. Your package src:dynarmic has been trying to migrate for 33 
> days [2]. Hence, I am filing this bug. The version in unstable has an 
> unresolved RC issue as reported in bug 1041270.
> 
> If a package is out of sync between unstable and testing for a longer 
> period, this usually means that bugs in the package in testing cannot be 
> fixed via unstable. Additionally, blocked packages can have impact on 
> other packages, which makes preparing for the release more difficult. 
> Finally, it often exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that 
> hamper the migration of their package in a timely manner.
> 
> This bug will trigger auto-removal when appropriate. As with all new 
> bugs, there will be at least 30 days before the package is auto-removed.
> 
> I have immediately closed this bug with the version in unstable, so if 
> that version or a later version migrates, this bug will no longer affect 
> testing. I have also tagged this bug to only affect sid and trixie, so 
> it doesn't affect (old-)stable.
> 
> If you believe your package is unable to migrate to testing due to 
> issues beyond your control, don't hesitate to contact the Release Team.

Hi, I have fixed this issue a while ago, and uploaded the fixed package to 
Mentors since it consists in a SONAME bump and I cannot upload it myself.

If you could please upload the package for me, it'd be really nice. There's not 
much to review anyway. You can find it on 
.

Sorry for the possibly broken reply, I'm on my phone.

Thanks!

Bug#1041491: marked as done (yuzu: FTBFS: Unmet build dependencies: glslang-tools:native)

[Andrea Pappacoda]

Il 13 agosto 2023 23:16:23 CEST, Debian Bug Tracking System 
 ha scritto:
>Your message dated Sun, 13 Aug 2023 23:13:56 +0200
>with message-id <0aa416df-8488-49ee-a38a-b57dbb2cf...@debian.org>
>and subject line Re: yuzu: FTBFS: Unmet build dependencies: 
>glslang-tools:native
>has caused the Debian Bug report #1041491,
>regarding yuzu: FTBFS: Unmet build dependencies: glslang-tools:native
>to be marked as done.
>
>This means that you claim that the problem has been dealt with.
>If this is not the case it is now your responsibility to reopen the
>Bug report if necessary, and/or fix the problem forthwith.
>
>(NB: If you are a system administrator and have no idea what this
>message is talking about, this may indicate a serious mail system
>misconfiguration somewhere. Please contact ow...@bugs.debian.org
>immediately.)
>
>

Bug#1041270: dynarmic: broke ABI without SONAME bump

[Andrea Pappacoda]

Hi all, I've uploaded a fixed Dynarmic package a while back on mentors, if 
somebody could upload it for me it'd be great.

I'm currently on vacation, so I don't have access to a computer and won't be 
able to make changes to it, but it should be fine.

https://mentors.debian.net/package/dynarmic/

Thanks!

Il 21 luglio 2023 16:50:01 CEST, Andrea Pappacoda  ha 
scritto:
>> Hi Sebastian, thanks for your report. I've uploaded a new version with 
>> a possible fix on Mentors, you can find it at 
>> <https://mentors.debian.net/package/dynarmic/>. I've also attached a 
>> debdiff for your convenience.
>> 
>> Feel free to upload it to unstable if you find this solution 
>> reasonable. Since this is only a soname change, without any actual 
>> library change, I believe that uploading to experimental first is 
>> unnecessary.
>> 
>> If it doesn't look right to you, I'll be happy to hear your feedback :)
>
>My previous solution was broken since it introduced a new package with
>the same contents as the older libdynarmic6 package, causing an unpack
>error. Luckly upstream has merged my patch and tagged a new release,
>so I simply updated to the new upstream version, getting rid of the file
>conflict and bumping the ABI.
>
>I don't have access to my private OpenPGP keys right now, so I can't upload
>the new release on Mentors, but I'll attach a debdiff nonetheless containing
>the 6.5.0-1 release. You can also find it on Salsa at
><https://salsa.debian.org/debian/dynarmic/-/tags/debian%2F6.5.0+ds-1>.

Bug#1041249: cpp-httplib: FTBFS on s390x: ../test/test.cc:5462: Failure

[Andrea Pappacoda]

Il giorno lun 24 lug 2023 alle 09:05:30 +02:00:00, Sebastian Ramacher 
 ha scritto:
Please prepare transitions in experimental first. This would avoid 
such

issues.

If there are no news regarding a fix for this bug, please revert
cpp-httplib 0.11.4 to get back to a good state.


Hi, I'll be sure to do it next time. I've looked into this, but I 
couldn't find any change which would cause test failures on s390x 
specifically. cpp-httplib's test suite is a bit flaky though, so it may 
have been just an unlucky run (this is an issue in itself, but I have 
already reported it upstream and it didn't get much attention). Is it 
possible to re-try the build?


Thanks :)

--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Bug#1041270: dynarmic: broke ABI without SONAME bump

[Andrea Pappacoda]

> Hi Sebastian, thanks for your report. I've uploaded a new version with 
> a possible fix on Mentors, you can find it at 
> . I've also attached a 
> debdiff for your convenience.
> 
> Feel free to upload it to unstable if you find this solution 
> reasonable. Since this is only a soname change, without any actual 
> library change, I believe that uploading to experimental first is 
> unnecessary.
> 
> If it doesn't look right to you, I'll be happy to hear your feedback :)

My previous solution was broken since it introduced a new package with
the same contents as the older libdynarmic6 package, causing an unpack
error. Luckly upstream has merged my patch and tagged a new release,
so I simply updated to the new upstream version, getting rid of the file
conflict and bumping the ABI.

I don't have access to my private OpenPGP keys right now, so I can't upload
the new release on Mentors, but I'll attach a debdiff nonetheless containing
the 6.5.0-1 release. You can also find it on Salsa at
.

dynarmic_6.5.0+ds-1.debdiff
Description: Binary data

Bug#1041270: dynarmic: broke ABI without SONAME bump

[Andrea Pappacoda]

On Sun, 16 Jul 2023 18:34:16 +0200 Sebastian Ramacher 
 wrote:

> Source: dynarmic
> Version: 6.4.8+ds-2
> Severity: serious
>
> 
https://ci.debian.net/data/autopkgtest/testing/amd64/y/yuzu/35884387/log.gz

>
>  60s yuzu-cmd: symbol lookup error: yuzu-cmd: undefined symbol: 
_ZN8Dynarmic3A327Context4RegsEv


Hi Sebastian, thanks for your report. I've uploaded a new version with 
a possible fix on Mentors, you can find it at 
<https://mentors.debian.net/package/dynarmic/>. I've also attached a 
debdiff for your convenience.


Feel free to upload it to unstable if you find this solution 
reasonable. Since this is only a soname change, without any actual 
library change, I believe that uploading to experimental first is 
unnecessary.


If it doesn't look right to you, I'll be happy to hear your feedback :)

Thanks again!

--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

diff -Nru dynarmic-6.4.8+ds/debian/changelog dynarmic-6.4.8+ds/debian/changelog
--- dynarmic-6.4.8+ds/debian/changelog	2023-07-05 22:03:58.0 +0200
+++ dynarmic-6.4.8+ds/debian/changelog	2023-07-20 19:13:04.0 +0200
@@ -1,3 +1,9 @@
+dynarmic (6.4.8+ds-3) unstable; urgency=medium
+
+  * d/{control,patches}: set soversion to major.minor (Closes: #1041270)
+
+ -- Andrea Pappacoda   Thu, 20 Jul 2023 19:13:04 +0200
+
 dynarmic (6.4.8+ds-2) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru dynarmic-6.4.8+ds/debian/control dynarmic-6.4.8+ds/debian/control
--- dynarmic-6.4.8+ds/debian/control	2023-07-05 22:03:58.0 +0200
+++ dynarmic-6.4.8+ds/debian/control	2023-07-20 19:11:30.0 +0200
@@ -25,7 +25,7 @@
  In the pursuit of speed, some behavior not commonly depended upon is elided.
  Therefore this emulator does not match spec.
 
-Package: libdynarmic6
+Package: libdynarmic6.4
 Architecture: any-amd64 any-arm64
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
@@ -39,7 +39,7 @@
 Section: libdevel
 Architecture: any-amd64 any-arm64
 Depends: libboost-dev,
- libdynarmic6 (= ${binary:Version}),
+ libdynarmic6.4 (= ${binary:Version}),
  llvm-dev,
  ${misc:Depends}
 Description: ${source:Synopsis} - development
diff -Nru dynarmic-6.4.8+ds/debian/libdynarmic6.4.install dynarmic-6.4.8+ds/debian/libdynarmic6.4.install
--- dynarmic-6.4.8+ds/debian/libdynarmic6.4.install	1970-01-01 01:00:00.0 +0100
+++ dynarmic-6.4.8+ds/debian/libdynarmic6.4.install	2023-07-20 19:11:30.0 +0200
@@ -0,0 +1 @@
+usr/lib/*/libdynarmic.so.6.4*
diff -Nru dynarmic-6.4.8+ds/debian/libdynarmic6.install dynarmic-6.4.8+ds/debian/libdynarmic6.install
--- dynarmic-6.4.8+ds/debian/libdynarmic6.install	2023-07-05 22:03:58.0 +0200
+++ dynarmic-6.4.8+ds/debian/libdynarmic6.install	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-usr/lib/*/libdynarmic.so.6*
diff -Nru dynarmic-6.4.8+ds/debian/patches/series dynarmic-6.4.8+ds/debian/patches/series
--- dynarmic-6.4.8+ds/debian/patches/series	2023-07-05 22:03:58.0 +0200
+++ dynarmic-6.4.8+ds/debian/patches/series	2023-07-20 19:04:31.0 +0200
@@ -1 +1,2 @@
 revert-catch2-v3.patch
+soname.patch
diff -Nru dynarmic-6.4.8+ds/debian/patches/soname.patch dynarmic-6.4.8+ds/debian/patches/soname.patch
--- dynarmic-6.4.8+ds/debian/patches/soname.patch	1970-01-01 01:00:00.0 +0100
+++ dynarmic-6.4.8+ds/debian/patches/soname.patch	2023-07-20 19:06:45.0 +0200
@@ -0,0 +1,28 @@
+Description: build: set SOVERSION to major.minor
+ Dynarmic uses semantic versioning, restricting backwards-incompatible
+ changes to major releases. This backwards compatibility, though, refers
+ to API changes, and disregards ABI stability. Since having to maintain a
+ compatible ABI between major releases is somewhat of a pain, and it
+ arguably doesn't matter that much for dynarmic, setting the SOVERSION to
+ major.minor allows for breaking ABI changes to be made between feature
+ releases, and not only major ones.
+ .
+ To be clear, this patch doesn't try to enforce a new policy, but just
+ reflects how the project has handled ABI changes in the past. That is,
+ these kind of changes have been made already.
+Author: Andrea Pappacoda 
+Origin: upstream, https://github.com/merryhime/dynarmic/pull/758
+Bug-Debian: https://bugs.debian.org/1041270
+Last-Update: 2023-07-20
+
+--- dynarmic-6.4.8+ds.orig/src/dynarmic/CMakeLists.txt
 dynarmic-6.4.8+ds/src/dynarmic/CMakeLists.txt
+@@ -455,7 +455,7 @@ target_include_directories(dynarmic PUBL
+ )
+ set_target_properties(dynarmic PROPERTIES
+ VERSION ${dynarmic_VERSION}
+-SOVERSION ${dynarmic_VERSION_MAJOR}
++SOVERSION ${dynarmic_VERSION_MAJOR}.${dynarmic_VERSION_MINOR}
+ )
+ target_compile_options(dynarmic PRIVATE ${DYNARMIC_CXX_FLAGS})
+ target_link_libraries(dynarmic

Bug#1041270: marked as pending in dynarmic

[Andrea Pappacoda]

Control: tag -1 pending

Hello,

Bug #1041270 in dynarmic reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/dynarmic/-/commit/0b8afc2381e9fd8b8e5186100a68d189b1cfd957


d/{control,patches}: set soversion to major.minor

Closes: #1041270


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1041270

Bug#1041249: cpp-httplib: FTBFS on s390x: ../test/test.cc:5462: Failure

[Andrea Pappacoda]

On Sun, 16 Jul 2023 16:07:00 +0200 Sebastian Ramacher 
 wrote:

> Source: cpp-httplib
> Version: 0.13.1+ds-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in 
the past)

>
> When starting an uncoordinated transition, please at least ensure 
that

> the package at least builds on all suported platforms.

Hi Sebastian, thanks for the report. It isn't easy for me to test that 
cpp-httplib's test suite passes on all architectures, since I only have 
access to amd64 machines. Nonetheless, I'll look into this as soon as 
possible.


Thanks again!

--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Bug#1034226: marked as pending in cloudflare-ddns

[Andrea Pappacoda]

Control: tag -1 pending

Hello,

Bug #1034226 in cloudflare-ddns reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/tachi/cloudflare-ddns/-/commit/f82000e4cc2f6b71c504935862371ba5b6cdc0a7


d/patches: use systemd.pc to get systemd paths

Using systemd.pc to get systemd unit and sysusers.d paths avoids having
to hardcode paths, which leads to issues when files have to be installed
outside of /usr, like with unit files in bookworm.

Closes: #1034226
Thanks: Andreas Henriksson for the patch!


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1034226

Bug#1034226: cloudflare-ddns: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Andrea Pappacoda]

Hi all,

Il giorno mar 11 apr 2023 alle 09:37:27 +02:00:00, bi...@debian.org ha 
scritto:
It seems that your package cloudflare-ddns is shipping files 
(.service, .socket or

.timer) in /usr/lib/systemd/system.

This is not supported by the version of dh_installsystemd/debhelper 
currently
in unstable and bookworm (See: #1031695). That means that currently 
your

service might not be enabled at boot and/or started as expected.


Thanks for the info! Having to install stuff outside of /usr kinda 
sucks, but I guess we don't have alternatives :/


Il giorno mar 11 apr 2023 alle 16:31:32 +02:00:00, Andreas Henriksson 
 ha scritto:

The culprit seems to be hard-coded paths in the upstream build system
at:
https://sources.debian.org/src/cloudflare-ddns/2.0.0-3/exe/meson.build/#L70

Since I wasn't sure about how configure_file directive in meson works
and the documentation at
https://mesonbuild.com/Reference-manual_functions.html#configure_file
says install_dir takes a subdirectory I had to try it out.

The attached debdiff should solve the problem.


Thanks you very much for the patch! Using systemd.pc certainly is the 
most appropriate thing to do, but the way you've approached this makes 
systemd a required dependency on Linux, which I'd prefer to avoid. I'll 
simply make th dependency `required: false`, so that files get 
installed only if systemd.pc is found on the system; this has the 
advantage of not making systemd required, and could also potentially 
work on non-Linux systems with systemd-compatible software (yeah, 
InitWare[1] is, or was, a thing).


I'll fix this upstream and in the Debian package as soon as possible, 
thanks again :)


[1]: https://github.com/InitWare/InitWare

--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Bug#1030670: Does not depend on libspng0

[Andrea Pappacoda]

Hi Jordi, thanks for the fast report!

On Mon Feb 6, 2023 at 12:09 PM CET, Jordi Mallach wrote:
> While trying to build against the new libspng-dev, I found that even my
> build was issuing -lspng, it would fail because it could not find it.
>
> It turns out you're missing a dependency against libspng0 itself.

Whoops, I wonder how I missed that. I thought lintian had a check for
this too, but aparently it doesn't.

> Additionally, I've seen the following too:
>
> - spng.pc declares:
>
> Requires.private: zlib
>
> If I understand correctly, this is not a public dependency, which means
> libspng-dev does not need to depend on zlib-dev. In fact, that's one of
> the features SPNG advertises.

Yeah, it's not part of the public interface (i.e. not exposed in the
header file), but it's still required to statically link to the library.
Not only that, but even if shared linking is required, pkg-config
requires all the Requires.private dependencies if the --cflags flag is
specified. If you try to remove zlib.pc and ask pkgconf to find spng,
here's what happens:

$ pkg-config --cflags --libs spng   
Package zlib was not found in the pkg-config search path.
Perhaps you should add the directory containing `zlib.pc'
to the PKG_CONFIG_PATH environment variable
Package 'zlib', required by 'spng', not found

In short, zlib-dev is a required dependency. As for what spng
advertises, yeah, you _can_ avoid zlib, but by using minz instead.

> - I would downgrade the Recommends on libspng-doc to a Suggests, to
>   avoid pulling in fonts and other unneeded packages on the 95% of
>   cases.

I'd prefer to keep it a recommendation instead. I find offline
documentation extremely important, as you don't always have internet
access; not only that, you can only grep it for what you're looking for,
etc, etc. Some make documentation part of the -dev package itself, but
with a Recommends it won't pulled in by a buildd, where it really is
unneeded.

That being said, I find pulling in an extra font package annoying too,
so I'll look into dropping that.

Thanks again for the report and suggestions! I've pushed the fix to
Salsa, and I'll do an upload ASAP.

Bug#1028252: tomlplusplus FTBFS: dpkg-checkbuilddeps: error: Unmet build dependencies: cmark-gfm:native

[Andrea Pappacoda]

On Mon, 09 Jan 2023 00:23:21 +0200 Adrian Bunk  wrote:
> Source: tomlplusplus
> Version: 3.2.0+ds-1
> Severity: serious
> Tags: ftbfs
>
> cmark-gfm is not Multi-Arch: allowed

Hi Adrian, thanks for the report. When I tagged the 3.2.0+ds-1 release 
I had to mark cmark-gfm with :native to make cross-builds work. 
cmark-gfm (and cmark) have been marked as Multi-Arch: foreign since 
then, so the :native thing should be indeed removed now.


Bastian has already pushed the fix to Salsa, and I've now uploaded -2 
to Mentors.

Bug#1027913: marked as pending in howardhinnant-date

[Andrea Pappacoda]

Control: tag -1 pending

Hello,

Bug #1027913 in howardhinnant-date reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/howardhinnant-date/-/commit/b8e4338b25d9ac5ace44ed6797cbd1bf77cbf51d


d/control: depend on tzdata

Closes: #1027913


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1027913

Bug#1023420: marked as pending in libvirt

[Andrea Bolognani]

Control: tag -1 pending

Hello,

Bug #1023420 in libvirt reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/libvirt-team/libvirt/-/commit/3f2985672fd96f945e71373e477ca92b3ae2f86c


control: Add (build) dependency on mount

mount is no longer essential, so we need to explicitly depend
on it.

We should be able to drop the build dependency later, after
patching out the check upstream, but the runtime dependency is
here to stay.

Closes: #1023420


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1023420

Bug#1024355: opensysusers: fails to first-install

[Andrea Pappacoda]

Hi Samuel, thank you very much for the report.

On Fri, 18 Nov 2022 09:40:11 +0100 Samuel Thibault 
 wrote:

> Version 0.7.3-1 of opensysusers made it uninstallable:
>
> (Reading database ... 936343 files and directories currently 
installed.)

> Preparing to unpack .../opensysusers_0.7.3-1_all.deb ...
> Adding 'diversion of /bin/systemd-sysusers to 
/bin/systemd-sysusers.real by opensysusers'

> /var/lib/dpkg/tmp.ci/preinst: 15: 2: parameter not set
> dpkg: error processing archive 
/var/cache/apt/archives/opensysusers_0.7.3-1_all.deb (--unpack):
>  new opensysusers package pre-installation script subprocess 
returned error exit status 2

>
> Indeed, preinst uses set -u, and then tries [ -n "$2" ] (expanded 
from

> dh_installinit), thus deemed to fail under first installation.

Strange... I too noticed that version 0.7.3-1 introduced a piuparts 
error, but the release is pretty much identical to 0.7.2-1, as 0.7.2-1 
already contained the only new upstream commit in 0.7.3.


Anyway, would you simply suggest to drop the `u` shell option? I added 
it only because I usually do so, but there's no strong motivation 
behind it.


Thanks again :)

Bug#1023420: libvirt FTBFS: missing Build-Depends: mount

[Andrea Bolognani]

On Wed, Nov 16, 2022 at 01:11:51PM +0100, Helmut Grohne wrote:
> On Wed, Nov 16, 2022 at 12:34:40PM +0100, Andrea Bolognani wrote:
> > Can you please tell me how you created the very minimal chroot in
> > which you reproduced the issue? A fresh one created today with
> > cowbuilder still contains mount, and even adding
> > 
> >   DEBOOTSTRAPOPTS="--variant=minbase"
> > 
> > to pbuilderrc doesn't change this. I just want to make sure there are
> > no other commands that need the same treatment.
> 
> I'm using mmdebstrap rather than debootstrap. While debootstrap's
> --variant=minbase includes all "Priority: required" packages, you still
> have to depend on them according to policy. mmdebstrap provides two
> smaller variants "essential", which really is only essential packages
> and "apt", which includes the apt package in addition to essential
> packages. The apt variant is the one I use most often. It recently got
> rid of adduser, which also exhibits bugs here and there. These days,
> sbuild can deal with such minimal chroots.

Okay, adding

  DEBOOTSTRAP="mmdebstrap"
  DEBOOTSTRAPOPTS="--variant=apt"

to my pbuilder configuration did the trick.

I'm going to make sure that there are no other missing Build-Depends,
and address this bug as part of the upcoming 8.9.0-1 upload.

Cheers :)

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1023420: libvirt FTBFS: missing Build-Depends: mount

[Andrea Bolognani]

On Wed, Nov 16, 2022 at 12:34:40PM +0100, Andrea Bolognani wrote:
> In the meantime, adding an explicit build time (and runtime!)
> dependency on mount will do the trick.

If I'm reading the NEWS.Debian file for mount correctly, it hasn't
been essential since 2017. So why is this only showing up now?

Not questioning the need to add the new dependencies, just trying to
fully understand the situation :)

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1023420: libvirt FTBFS: missing Build-Depends: mount

[Andrea Bolognani]

On Thu, Nov 03, 2022 at 08:12:53PM +0100, Helmut Grohne wrote:
> Source: libvirt
> Version: 8.5.0-1
> Severity: serious
> Tags: ftbfs
> 
> libvirt fails to build from source in unstable on a minimal chroot.
> mount is no longer essential nor build-essential, so you must add it to
> Build-Depends explicitly.

Hi Helmut,

thanks for the report!

The handling of mount and other similar commands is currently not
ideal: none of them should be required to be present at build time,
since libvirt is perfectly capable of finding them at runtime. This
is, in fact, what we already do for several other programs. I will
write a patch fixing this and submit it upstream.

In the meantime, adding an explicit build time (and runtime!)
dependency on mount will do the trick.

Can you please tell me how you created the very minimal chroot in
which you reproduced the issue? A fresh one created today with
cowbuilder still contains mount, and even adding

  DEBOOTSTRAPOPTS="--variant=minbase"

to pbuilderrc doesn't change this. I just want to make sure there are
no other commands that need the same treatment.

Cheers.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

[Andrea Corallo]

Eli Zaretskii  writes:

>> From: Andrea Corallo 
>> Cc: Vincent Lefevre , spwhit...@spwhitton.name,
>> 58...@debbugs.gnu.org, 1017...@bugs.debian.org
>> Date: Thu, 03 Nov 2022 21:25:08 +
>> 
>> AFAIU the Emacs subprocess we use to compile should behave like a
>> regular Emacs.
>
> Basically, you are saying that if the sub-process that runs
> async-compilation gets SIGHUP, it should abort and dump core, like a
> normal Emacs session does, right?
>
> The backtrace posted to the Debian bug tracker, here:
>
>   
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1017711;filename=gdb.txt;msg=5
>
> indicates that Emacs was in the middle of comp-copy-insn which was
> called from comp-fwprop.  Then Emacs performed GC, and SIGHUP was
> received during GC.  IOW, we were in our Lisp code, not in a libgccjit
> code, when the signal arrived.
>
> Another backtrace, posted here:
>
>   
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1017711;filename=gdb.txt;msg=45
>
> tells a somewhat different story: it doesn't show Emacs in the middle
> of a native compilation, but just inside substitute-command-keys that
> was called from command-line.

Sorry I missed those traces.  Okay so for both cases if libgccjit is not
involved the behaviour of Emacs here is just the plain one and should
not be related to native compilation.  It's just that native compilation
makes it more likely to be identify this condition.

>> Now, the only option that comes to my mind is that libgccjit (being
>> strictly derived from the GCC codebase) might be registering a signal
>> handler of some kind that alters the behaviour we expect.  But if this
>> is the case we should find trace of it the strace, or we can use gdb
>> setting a break point into 'signal' as well to check.
>> 
>> Indeed if this theory is true I think should be classified as a
>> libgccjit bug.
>
> I don't think it's true, see above.
>
> Paul, can you help here, please?  We need to establish what is the
> source of SIGHUP in these cases.  "These cases" mean, AFAIU, the
> situations where Emacs launched an async subprocess to do native
> compilation (which is another Emacs process in a --batch session), and
> the parent Emacs session is terminated by the user before the async
> compilation runs to completion.  Would the child Emacs process get
> SIGHUP in this scenario?  If yes, then I think we should treat SIGHUP
> differently in non-interactive invocations: instead of dumping core,
> we should catch the signal and exit with a non-zero exit status.
>
> Does this make sense?

To me yes.

> Andrea, if we do the above as I suggest, is there any cleanup that we
> need to do before exiting?  For example, what if the subprocess that
> does the async compilation already started writing the .eln file when
> the signal arrives?  What do we do today when the parent interactive
> Emacs is terminated by the user?

I think we have no special handling for this case, so yeah we might
leave some traces of the compilation.  Other than the .eln we should
also remove the lisp file we write to be loaded by the async compilation
process.  I'm not sure where and how would be best to handle all of this
tho.

Best Regards

  Andrea

Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

[Andrea Corallo]

Eli Zaretskii  writes:

>> Date: Thu, 3 Nov 2022 11:13:08 +0100
>> From: Vincent Lefevre 
>> Cc: spwhit...@spwhitton.name, 58...@debbugs.gnu.org,
>>  1017...@bugs.debian.org
>> 
>> On 2022-11-03 08:47:06 +0200, Eli Zaretskii wrote:
>> > > On 2022-11-02 14:24:51 +0200, Eli Zaretskii wrote:
>> > > > Signal 1 is SIGHUP, AFAIU.  Why should Emacs receive SIGHUP in the
>> > > > middle of GC, I have no idea.  Maybe ask the user what was he doing at
>> > > > that time.  E.g., could that be a remote Emacs session?
>> > > 
>> > > No, it is on my local machine.
>> > 
>> > So how come Emacs gets a SIGHUP?  This is the crucial detail that is
>> > missing here.  Basically, if SIGHUP is delivered to Emacs, Emacs is
>> > supposed to die a violent death.
>> 
>> I suspect the SIGHUP comes from Emacs itself. According to strace
>> output, the only processes started by Emacs are "/usr/bin/emacs"
>> (there are many of them). I don't see what other process could be
>> aware of the situation. Unfortunately, I couldn't reproduce the
>> issue with strace (I suspect some race condition).
>> 
>> > > I run emacs, and quit it immediately. The generation of the core dump
>> > > is almost 100% reproducible. Ditto with "emacs -nw".
>> > 
>> > Wait, you mean the crash is during exiting Emacs?
>> 
>> For this test, yes. In general, I don't know.
>> 
>> > That could mean Emacs receives some input event when it's half-way
>> > through the shutdown process, and the input descriptor is already
>> > closed.
>> 
>> Note that the process that crashes is not the Emacs I started,
>> but a subprocess run by Emacs itself, since it has arguments like
>> "-no-comp-spawn --batch -l /tmp/emacs-async-comp-url.el-FGov4z.el".
>
> Andrea, could you please look into this?  The SIGHUP could be because
> the parent process exits, but that shouldn't cause a crash in the
> sub-process that performs native compilation?

Hi Eli,

AFAIU the Emacs subprocess we use to compile should behave like a
regular Emacs.

Now, the only option that comes to my mind is that libgccjit (being
strictly derived from the GCC codebase) might be registering a signal
handler of some kind that alters the behaviour we expect.  But if this
is the case we should find trace of it the strace, or we can use gdb
setting a break point into 'signal' as well to check.

Indeed if this theory is true I think should be classified as a
libgccjit bug.

  Andrea

Bug#1023178: microprofile: Contains non-free source

[Andrea Pappacoda]

Control: tag -1 + pending

I've just fixed the mentioned issues and uploaded the package to 
mentors.

Bug#1023178: microprofile: Contains non-free source

[Andrea Pappacoda]

On Mon, 31 Oct 2022 11:02:55 +0100 Bastian Germann  
wrote:
> The files src/microprofile*.html contain JavaScript code from 
https://gist.github.com/mjackson/5311256
> which never got a license even though people have asked for it. So 
please exclude them.


Hi Bastian, thank you for the report. I'll fix it as soon as possible, 
possibly in the 4.0 release. I've already uploaded the latest release 
to mentors, but it doesn't contain this fix.


As a sidenote, the BTS doesn't send me emails, probably because of its 
broken DMARC/DKIM setup. In the future, please Cc me in emails you send 
to the BTS.


Thanks, as always!

Bug#1017739: emacs-lucid cannot start after upgrade

[Andrea Corallo]

Stefan Monnier  writes:

> Russ Allbery [2022-08-19 11:42:30] wrote:
>> The 28.1 version of emacs-lucid fails on startup with a cryptic error
>> message:
>>
>> % emacs
>> Cannot find suitable directory for output in ‘comp-native-load-path’.
>>
>> Running emacs -q allows it to start, but it still reports the same error
>> immediately during startup, and attempting to do someting as basic as
>> M-x set-variable (to try to enable debug-on-error) fails with a similar
>> error message:
>>
>> defalias: Cannot find suitable directory for output in 
>> ‘comp-native-load-path’.
>>
>> emacs -q --no-site-file avoids the error on startup, but M-x set-variable
>> still immediately fails with the same error.
>
> This error is signaled by `comp-el-to-eln-filename` and it usually
> indicates that that function was unable to find a writable directory in
> which to put the auto-generated `.eln` native-compiled files.
>
> I don't know why it fails to find a writable directory.  Maybe
>
> emacs --debug-init` would help
> or
> emacs -e '(message "%S" comp-native-load-path)'
>
> might help track down the origin of the problem.
>
> This said, Emacs shouldn't become unusable in such a circumstance, so we
> should maybe use a patch along the lines of the one below (not sure if
> it wraps the relevant invocation of `comp-el-to-eln-filename`, tho).

Agree Emacs should stay usable and I think the one you've identified
should be the right invocation to be wrapped.

Best Regards

  Andrea

Bug#1014435: libvirt-daemon-system-systemd: virbr0 default fails to connect

[Andrea Bolognani]

On Tue, Jul 05, 2022 at 08:06:44PM -0500, Tim McConnell wrote:
> Package: libvirt-daemon-system-systemd
> Version: 8.4.0-1
> Severity: grave
> Justification: renders package unusable

This doesn't feel right. According to [1], "grave" means that the bug

  makes the package in question unusable or mostly so, or causes data
  loss, or introduces a security hole allowing access to the accounts
  of users who use the package

The fact that a single libvirt feature (the default network) has been
reported as not working by a single person (I just tested it on my
machine and it seems okay) doesn't match the description of the
severity IMO. I'll lower it to "important", which indicates

  a bug which has a major effect on the usability of a package,
  without rendering it completely unusable to everyone

and seems to describe the actual impact much more accurately.

> Virbr0 won't connect to external network.It did once, I was able to install
> Debian from a net install image. Now it tells me the Virtual Machine can't
> connect.

Please be more specific. Does the VM fail to start? If so, what is
the exact error message? Or does the VM boot up, but the guest OS is
unable to connect to the Internet? Can the guest OS ping the host, or
does that not work either? If you try performing another
installation, does that work?


[1] https://www.debian.org/Bugs/Developer#severities
-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1010340: git: Fails to clone and pull from existign repositories

[Andrea Palazzi]

Hi,
> Maybe some hiccup at Github?Seems unlikely since on Windows I could clone and 
> pull everything without issues, but I'll try again tomorrow.

Thanks,Andrea

Bug#1006300: marked as pending in libvirt

[Andrea Bolognani]

Control: tag -1 pending

Hello,

Bug #1006300 in libvirt reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/libvirt-team/libvirt/-/commit/a06d5e56fb01acf2765700c9ad2a1bdce0454178


control: Drop i386 from Xen arches

Starting with Xen version 4.16, Xen is no longer built on
the i386 architecture in Debian.

Closes: #1006300


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1006300

Bug#995242: isc-dhcp-server: omshell returns inconsistent results or segfaults

[Andrea Turbiglio]

Nearly all crashes for omshell happen at an instruction pointer ending with 
...6dc.
Therefore I guess all crashes happen at the same source code location.
Unfortunately with just the segfault line it is difficult to find out this 
source code line.
Therefore the kernel emits one line below the segfault line a line showing the
surrounding bytes of the crashing instruction (at amd64).
Having this line too it is likely possible to find the exact source code line. 
[1]
Example:
 [13092.694183] omshell[11741]: segfault at ...
 [13092.694202] Code: 64 ff ff ff c6 05 15 2f 00 ...
So maybe you could at least retrieve from the log
one "segfault" line with following "Code:" line?
Even better would be to get a backtrace of the crash.
If this system is systemd based, the simplest might be to install 
systemd-coredump.
With this package such a backtrace is written directly to the journal.
Otherwise there are other core-dump-handler available, but the
core has to be analyzed separately.
Kind regards,
Bernhard


Thanks for the reply.

The problem now is that those systems are not available anymore.

I had this issue only on production.
When I was testing Debian 11 with DHCPD on a small testing environment (with 
few dhcp clients) everything was fine.

So to recreate the issue, I should clone one of our 2 DHCPDs (that now are 
running fine from ISC source), remove the source package and reconfigure the 
Debian package version... and then redeploy one of them on production.
And then hope that the other server (the one running with the SRC-pkg version) 
will be able to do all the work, when the other dhcpd will crash because of 
omshell.

I had a snapshot of the servers with the Debian-dhcpd-pkg, kept for testing 
purposes, but I had to delete them for disk space management (I kept them for a 
while, but 6 monts has passed from the issue's opening).

I'll try to recreate a similar environment, but I don't know when I will be 
able to.


Thanks for your support.

Regards

--
______
Andrea Turbiglio
Università degli Studi dell’Insubria
Centro Sistemi Informativi e Comunicazione
Servizio Telecomunicazioni - Gestione Rete Dati di Ateneo

Via Valleggio, 11
22100 - COMO
tel. +39 031 238 9784
fax +39 031 238 9709
webwww.uninsubria.it
mailandrea.turbig...@uninsubria.it
mailnetw...@uninsubria.it

Bug#995242: isc-dhcp-server: omshell returns inconsistent results or segfaults

[Andrea Turbiglio]

I temporarily switched our servers to the source package version of 
isc-dhcp-server (4.4.2) and the same issue doesn't happens, so I assume 
this is a problem with the Debian version of the package.
The servers are now running on Debian 11 without issues (the only 
problematic package in the transition  from debian 10 to debian 11 was 
isc-dhcp-server).


--
__
Andrea Turbiglio
Università degli Studi dell’Insubria
Centro Sistemi Informativi e Comunicazione
Servizio Telecomunicazioni - Gestione Rete Dati di Ateneo

Via Valleggio, 11
22100 - COMO
tel. +39 031 238 9784
fax +39 031 238 9709
web   www.uninsubria.it
mail  andrea.turbig...@uninsubria.it
mail  netw...@uninsubria.it

Bug#995242: isc-dhcp-server: omshell returns inconsistent results or segfaults

[Andrea Turbiglio]

00]
kern.info-20210925.log.gz:Sep 25 05:47:35 Sep 25 05:47:35 $hostname2 
kernel: [68804.784942] omshell[137990]: segfault at 0 ip 
56472bca06dc sp 7ffe99eb8b98 error 4 in omshell[56472bc67000+45000]
kern.info-20210925.log.gz:Sep 25 06:18:10 Sep 25 06:18:10 $hostname2 
kernel: [70639.905566] isc-worker[141620]: segfault at f ip 
5603f2b4055d sp 7fa3159bade0 error 4 in omshell[5603f2b09000+45000]
kern.info-20210925.log.gz:Sep 25 09:04:25 Sep 25 09:04:25 $hostname2 
kernel: [80614.985424] omshell[161240]: segfault at 0 ip 
558a78a7a6dc sp 7fff9df4ba38 error 4 in omshell[558a78a41000+45000]
kern.info-20210925.log.gz:Sep 25 09:34:25 Sep 25 09:34:25 $hostname2 
kernel: [82415.276674] isc-worker[164586]: segfault at f ip 
55ef12b0155d sp 7fb4b4cf1de0 error 4 in omshell[55ef12aca000+45000]
kern.info-20210925.log.gz:Sep 25 16:09:22 Sep 25 16:09:21 $hostname2 
kernel: [106111.475212] omshell[211831]: segfault at 0 ip 
560317b156dc sp 7ffdfb021528 error 4 in omshell[560317adc000+45000]
kern.info-20210925.log.gz:Sep 25 17:20:22 Sep 25 17:20:22 $hostname2 
kernel: [110371.859670] isc-worker[220054]: segfault at f ip 
55b63700255d sp 7f4d70571de0 error 4 in omshell[55b636fcb000+45000]
kern.info-20210925.log.gz:Sep 25 18:06:07 Sep 25 18:06:07 $hostname2 
kernel: [113117.309279] omshell[225562]: segfault at 0 ip 
56064acc46dc sp 7fffa83d6298 error 4 in omshell[56064ac8b000+45000]
kern.info-20210928.log.gz:Sep 28 11:05:01 Sep 28 11:05:22 $hostname2 
kernel: [ 1458.755006] omshell[4604]: segfault at 0 ip 55623cdd06dc 
sp 7ffd5a2c7c78 error 4 in omshell[55623cd97000+45000]
kern.info-20210928.log.gz:Sep 28 14:38:17 Sep 28 14:38:17 $hostname2 
kernel: [14233.628306] omshell[52163]: segfault at fcf56f25bf0 ip 
7fc656ded717 sp 00007ffe733c09b0 error 4 in 
libc-2.31.so[7fc656d8c000+14b000]



--
__
Andrea Turbiglio
Università degli Studi dell’Insubria
Centro Sistemi Informativi e Comunicazione
Servizio Telecomunicazioni - Gestione Rete Dati di Ateneo

Via Valleggio, 11
22100 - COMO
tel. +39 031 238 9784
fax +39 031 238 9709
web   www.uninsubria.it
mail  andrea.turbig...@uninsubria.it
mail  netw...@uninsubria.it

Bug#993783: snapd: AppArmor profile breaks snaps

[Andrea V]

Package: snapd
Version: 2.51.7-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: andreakarim...@gmail.com

Dear Maintainer,

   * What led up to the situation? Trying to run a "classic" snap.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Just tried to run the snap.
   * What was the outcome of this action? AppArmor DENIED and snap not starting
   * What outcome did you expect instead? Snap to run properly

The AppArmor profile for /usr/lib/snapd/snap-confine prevents snaps such
as slack and spotify to run at all:


$ slack
cannot change profile for the next exec call: No such file or directory

$ spotify 
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
cannot change profile for the next exec call: No such file or directory
snap-update-ns failed with code 1



Sep 06 13:47:04 XXX kernel: audit: type=1400 audit(1630928824.498:38): 
apparmor="DENIED" operation="change_onexec" info="label not found" error=-2 
profile="/usr/lib/snapd/snap-confine" name="snap-update-ns.spotify" pid=10039 
comm="snap-confine"
Sep 06 13:47:04 XXX kernel: audit: type=1400 audit(1630928824.498:37): 
apparmor="DENIED" operation="capable" profile="/usr/lib/snapd/snap-confine" 
pid=10025 comm="snap-confine" capability=4  capname="fsetid"
Sep 06 13:47:04 XXX audit[10039]: AVC apparmor="DENIED" 
operation="change_onexec" info="label not found" error=-2 
profile="/usr/lib/snapd/snap-confine" name="snap-update-ns.spotify" pid=10039 
comm="snap-confine"
Sep 06 13:47:04 XXX audit[10025]: AVC apparmor="DENIED" operation="capable" 
profile="/usr/lib/snapd/snap-confine" pid=10025 comm="snap-confine" 
capability=4  capname="fsetid"
Sep 06 13:46:59 XXX audit[9942]: AVC apparmor="DENIED" 
operation="change_onexec" info="label not found" error=-2 
profile="/usr/lib/snapd/snap-confine" name="snap.slack.slack" pid=9942 
comm="snap-confine"
Sep 06 13:46:59 XXX kernel: audit: type=1400 audit(1630928819.269:36): 
apparmor="DENIED" operation="change_onexec" info="label not found" error=-2 
profile="/usr/lib/snapd/snap-confine" name="snap.slack.slack" pid=9942 
comm="snap-confine"


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages snapd depends on:
ii  adduser  3.118
ii  apparmor 3.0.3-2
ii  ca-certificates  20210119
ii  gnupg2.2.27-2
ii  libapparmor1 3.0.3-2
ii  libc62.32-1
ii  libcap2  1:2.44-1
ii  libseccomp2  2.5.1-1
ii  libudev1 247.9-1
ii  openssh-client   1:8.4p1-6
ii  squashfs-tools   1:4.5-2
ii  systemd  247.9-1
ii  udev 247.9-1

Versions of packages snapd recommends:
ii  gnupg  2.2.27-2

Versions of packages snapd suggests:
ii  zenity  3.32.0-7

-- no debconf information

Bug#980609: missing i386-cpuinfo.h

[Andrea Pappacoda]

Followup-For: Bug #980609
source: gcc-10

Is this fix going to be backported to bullseye/sid? I'm too facing this issue 
with gcc-10 10.2.1-6.

Bug#981435: libvirt: stops on upgrade: internal error: Failed to load module 'libvirt_driver_qemu.so': libvirt.so.0: version `LIBVIRT_PRIVATE_6.9.0' not found (required by libvirt_driver_qemu.so)

[Andrea Bolognani]

On Sun, Jan 31, 2021 at 04:36:21PM +0100, Andrea Bolognani wrote:
> I've opened
> 
>   https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/98
> 
> with the proposed patch, and I'm going to use the information you
> provided above to give it some testing now.

I've added a few extra Depends to make sure everything is really
updated in lockstep and tested with unattended-upgrades: the result
was much better this time!

  Log started: 2021-01-31  18:20:43
  (Reading database ... 87062 files and directories currently installed.)
  Preparing to unpack .../00-libnss-libvirt_7.0.0-1_amd64.deb ...
  Unpacking libnss-libvirt:amd64 (7.0.0-1) over (6.9.0-4) ...
  Preparing to unpack .../01-libvirt-sanlock_7.0.0-1_amd64.deb ...
  Unpacking libvirt-sanlock (7.0.0-1) over (6.9.0-4) ...
  Preparing to unpack .../02-libvirt-login-shell_7.0.0-1_amd64.deb ...
  Unpacking libvirt-login-shell (7.0.0-1) over (6.9.0-4) ...
  Preparing to unpack .../03-libvirt-dev_7.0.0-1_amd64.deb ...
  Unpacking libvirt-dev:amd64 (7.0.0-1) over (6.9.0-4) ...
  Preparing to unpack .../04-libvirt-daemon-config-nwfilter_7.0.0-1_all.deb ...
  Unpacking libvirt-daemon-config-nwfilter (7.0.0-1) over (6.9.0-4) ...
  Preparing to unpack .../05-libvirt-daemon-config-network_7.0.0-1_all.deb ...
  Unpacking libvirt-daemon-config-network (7.0.0-1) over (6.9.0-4) ...
  Preparing to unpack .../06-libvirt-daemon-system_7.0.0-1_amd64.deb ...
  Unpacking libvirt-daemon-system (7.0.0-1) over (6.9.0-4) ...
  Preparing to unpack .../07-libvirt-daemon-driver-qemu_7.0.0-1_amd64.deb ...
  Unpacking libvirt-daemon-driver-qemu (7.0.0-1) over (6.9.0-4) ...
  Preparing to unpack .../08-libvirt-clients_7.0.0-1_amd64.deb ...
  Unpacking libvirt-clients (7.0.0-1) over (6.9.0-4) ...
  Preparing to unpack .../09-libvirt0_7.0.0-1_amd64.deb ...
  Unpacking libvirt0:amd64 (7.0.0-1) over (6.9.0-4) ...
  Preparing to unpack .../10-libvirt-daemon-driver-xen_7.0.0-1_amd64.deb ...
  Unpacking libvirt-daemon-driver-xen (7.0.0-1) over (6.9.0-4) ...
  Preparing to unpack .../11-libvirt-daemon-driver-vbox_7.0.0-1_amd64.deb ...
  Unpacking libvirt-daemon-driver-vbox (7.0.0-1) over (6.9.0-4) ...
  Preparing to unpack 
.../12-libvirt-daemon-driver-storage-zfs_7.0.0-1_amd64.deb ...
  Unpacking libvirt-daemon-driver-storage-zfs (7.0.0-1) over (6.9.0-4) ...
  Preparing to unpack 
.../13-libvirt-daemon-driver-storage-rbd_7.0.0-1_amd64.deb ...
  Unpacking libvirt-daemon-driver-storage-rbd (7.0.0-1) over (6.9.0-4) ...
  Preparing to unpack 
.../14-libvirt-daemon-driver-storage-gluster_7.0.0-1_amd64.deb ...
  Unpacking libvirt-daemon-driver-storage-gluster (7.0.0-1) over (6.9.0-4) ...
  Preparing to unpack .../15-libvirt-daemon_7.0.0-1_amd64.deb ...
  Unpacking libvirt-daemon (7.0.0-1) over (6.9.0-4) ...
  Preparing to unpack .../16-libvirt-daemon-driver-lxc_7.0.0-1_amd64.deb ...
  Unpacking libvirt-daemon-driver-lxc (7.0.0-1) over (6.9.0-4) ...
  Preparing to unpack .../17-libvirt-daemon-system-systemd_7.0.0-1_all.deb ...
  Unpacking libvirt-daemon-system-systemd (7.0.0-1) over (6.9.0-4) ...
  Setting up libvirt-daemon-config-network (7.0.0-1) ...
  Setting up libvirt-daemon-system-systemd (7.0.0-1) ...
  Setting up libvirt0:amd64 (7.0.0-1) ...
  Setting up libvirt-daemon-config-nwfilter (7.0.0-1) ...
  Setting up libvirt-clients (7.0.0-1) ...
  Setting up libvirt-dev:amd64 (7.0.0-1) ...
  Setting up libvirt-sanlock (7.0.0-1) ...
  Setting up libnss-libvirt:amd64 (7.0.0-1) ...
  Setting up libvirt-daemon-driver-qemu (7.0.0-1) ...
  Setting up libvirt-daemon (7.0.0-1) ...
  Setting up libvirt-daemon-driver-vbox (7.0.0-1) ...
  Setting up libvirt-daemon-driver-storage-rbd (7.0.0-1) ...
  Setting up libvirt-daemon-driver-lxc (7.0.0-1) ...
  Setting up libvirt-login-shell (7.0.0-1) ...
  Setting up libvirt-daemon-driver-storage-gluster (7.0.0-1) ...
  Setting up libvirt-daemon-driver-xen (7.0.0-1) ...
  Setting up libvirt-daemon-driver-storage-zfs (7.0.0-1) ...
  Setting up libvirt-daemon-system (7.0.0-1) ...
  Installing new version of config file 
/etc/apparmor.d/abstractions/libvirt-lxc ...
  Installing new version of config file 
/etc/apparmor.d/abstractions/libvirt-qemu ...
  Installing new version of config file /etc/default/libvirt-guests ...
  Installing new version of config file /etc/libvirt/qemu.conf ...
  virtlockd.service is a disabled or a static unit, not starting it.
  virtlogd.service is a disabled or a static unit, not starting it.
  Processing triggers for man-db (2.9.3-2) ...
  Processing triggers for libc-bin (2.31-9) ...
  Log ended: 2021-01-31  18:20:48

  Log started: 2021-01-31  18:20:49
  (Reading database ... 87071 files and directories currently installed.)
  Preparing to unpack .../libvirt-wireshark_7.0.0-1_amd64.deb ...
  Unpacking libvirt-wireshark (7.0.0-1) over (6.9.0-4) ...
  Setting up libvirt-wireshark (7.0.0-1) ...
  Log ended: 2021-01-31  18:20:49

  Log started: 2021-01-31  18:20:49
  (Reading database ... 87071 files and dir

Bug#981435: libvirt: stops on upgrade: internal error: Failed to load module 'libvirt_driver_qemu.so': libvirt.so.0: version `LIBVIRT_PRIVATE_6.9.0' not found (required by libvirt_driver_qemu.so)

[Andrea Bolognani]

On Sun, Jan 31, 2021 at 11:04:13PM +0800, Paul Wise wrote:
> On Sun, 2021-01-31 at 15:34 +0100, Andrea Bolognani wrote:
> > As I've never used unattended-upgrades myself, I'm not familiar with
> > it. Is there any chance you could provide some quick tips on how to
> > set up a reproducer environment? Specifically how to set up the same
> > upgrade strategy you're using, and whether it's possible to manually
> > trigger an unattended-upgrades run? That would help a lot!
> 
> You can probably also reproduce it without unattended-upgrades by just
> upgrading libvirt-daemon itself using apt but with unattended-upgrades
> the key is to enable the minimal steps option, but do this overall:
> 
> Install a Debian system that has the old libvirt using the Debian
> wayback machine (snapshot.debian.org), install unattended-upgrades and
> add something like the following in /etc/apt/apt.conf.d/99override-u-u.conf
> and then run this command: systemctl start apt-daily{,-upgrade}.service
> 
>    APT::Periodic::Update-Package-Lists "always";
>    APT::Periodic::Download-Upgradeable-Packages "always";
>    APT::Periodic::AutocleanInterval "always";
>    APT::Periodic::Unattended-Upgrade "always";
>    Unattended-Upgrade::Origins-Pattern { "origin=Debian"; };
>    Unattended-Upgrade::MinimalSteps "true";
>    Unattended-Upgrade::Mail "root";
>    Unattended-Upgrade::Remove-Unused-Dependencies "true";
>    Unattended-Upgrade::Automatic-Reboot "false";
>    // Temporary options for debugging
>    //Unattended-Upgrade::Verbose "true";
>    //Unattended-Upgrade::Debug "true";

Thanks, I'll try this.

> > As for the issue itself, I think it's caused by some of the
> > dependencies not being strict enough
> 
> I'm not sure but I think the issue is caused by the libvirt0 symbol
> file generating incorrect dependencies for the private symbols,
> probably it should be much more restrictive for those.
> 
> The missing symbols are pretty concerning, those look like broken ABI?

The exact error is

  Failed to load module 
'/usr/lib/x86_64-linux-gnu/libvirt/connection-driver/libvirt_driver_qemu.so': 
/usr/lib/x86_64-linux-gnu/libvirt.so.0: version `LIBVIRT_PRIVATE_6.9.0' not 
found (required by 
/usr/lib/x86_64-linux-gnu/libvirt/connection-driver/libvirt_driver_qemu.so)

Note how it's talking about LIBVIRT_PRIVATE_x.y.z rather than
LIBVIRT_x.y.z: the latter contains the public API, while the former
is used for internal symbols that are not exposed publicly and are
only needed by other libvirt components, such as utility functions
that are provided by libvirt.so for use in the various drivers.

This is part of the reason why we want upgrades to happen in
lockstep: for any given version of libvirt, its various components
are really only meant to work with other components when these come
from the very same build.

I've opened

  https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/98

with the proposed patch, and I'm going to use the information you
provided above to give it some testing now.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#981435: libvirt: stops on upgrade: internal error: Failed to load module 'libvirt_driver_qemu.so': libvirt.so.0: version `LIBVIRT_PRIVATE_6.9.0' not found (required by libvirt_driver_qemu.so)

[Andrea Bolognani]

mor_parser"
> Jan 31 17:08:34 audit[1318234]: AVC apparmor="STATUS" 
> operation="profile_replace" info="same as current profile, skipping" 
> profile="unconfined" name="libvirtd//qemu_bridge_helper" pid=1318234 
> comm="apparmor_parser"
> Jan 31 17:08:34 systemd[1]: Reloading.
> Jan 31 17:08:36 systemd[1]: Stopping Virtualization daemon...
> Jan 31 17:08:36 systemd[1]: libvirtd.service: Succeeded.
> Jan 31 17:08:36 systemd[1]: Stopped Virtualization daemon.
> Jan 31 17:08:36 systemd[1]: Starting Virtualization daemon...
> Jan 31 17:08:36 libvirtd[1318287]: libvirt version: 7.0.0, package: 1 (Andrea 
> Bolognani  Thu, 28 Jan 2021 22:06:43 +0100)
> Jan 31 17:08:36 libvirtd[1318287]: hostname: chianamo
> Jan 31 17:08:36 libvirtd[1318287]: internal error: Failed to load module 
> '/usr/lib/x86_64-linux-gnu/libvirt/connection-driver/libvirt_driver_qemu.so': 
> /usr/lib/x86_64-linux-gnu/libvirt.so.0: version `LIBVIRT_PRIVATE_6.9.0' not 
> found (required by 
> /usr/lib/x86_64-linux-gnu/libvirt/connection-driver/libvirt_driver_qemu.so)
> Jan 31 17:08:36 systemd[1]: libvirtd.service: Main process exited, 
> code=exited, status=3/NOTIMPLEMENTED
> Jan 31 17:08:36 systemd[1]: libvirtd.service: Failed with result 'exit-code'.
> Jan 31 17:08:36 systemd[1]: Failed to start Virtualization daemon.

Thanks for your report, Paul!

As I've never used unattended-upgrades myself, I'm not familiar with
it. Is there any chance you could provide some quick tips on how to
set up a reproducer environment? Specifically how to set up the same
upgrade strategy you're using, and whether it's possible to manually
trigger an unattended-upgrades run? That would help a lot!

As for the issue itself, I think it's caused by some of the
dependencies not being strict enough: in particular we have

  Package: libvirt-daemon
  Depends: libvirt-daemon-driver-qemu

In your case, libvirt-daemon-driver-qemu 6.9.0-4 satisifies the
constraint for libvirt-daemon 7.0.0-1, and so the first upgrade step
only upgrades the latter and leaves the former for later: what I
believe we really want instead is

  Package: libvirt-daemon
  Depends: libvirt-daemon-driver-qemu (= ${binary:Version})

so that we can be sure that all libvirt packages are upgraded in
lockstep. We already have this for some inter-source-package
dependencies, we're just not entirely consistent about it.

I'll start working on a MR right away.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#977656: zfs-dkms: Fail to build with 5.10 kernel

[Andrea Palazzi]

Hi,


Can someone give an estimated timeline for this fix to get into testing 
(bullseye)?



Bye

Andrea

Bug#960762: [Pkg-libvirt-maintainers] Bug#960762: libvirt: random (?) test hangs

[Andrea Bolognani]

On Fri, Jul 03, 2020 at 12:04:16AM +0200, Andrea Bolognani wrote:
> On Wed, Jul 01, 2020 at 09:24:00AM +0200, Guido Günther wrote:
> > On Tue, Jun 30, 2020 at 09:28:34PM +0200, Andrea Bolognani wrote:
> > > Has anyone managed to reproduce this? I've built 6.0.0-7 from source
> > > in a tight loop 100 times, both in a sid:i386 chroot via cowbuilder
> > > and in a sid:i386 VM, without encountering a single failure.
> > 
> > I tried to reproduce too when this came in and couldn't.
> 
> Okay, let's assume it was a temporary glitch then - at least until
> another build fails for the same reason.

We've made three uploads in a row now with zero issues on i386, so
at this point I would say it's fair to assume this one failure was
just a fluke. I vote for closing the bug and unblocking migrations
to testing.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#960762: [Pkg-libvirt-maintainers] Bug#960762: libvirt: random (?) test hangs

[Andrea Bolognani]

On Wed, Jul 01, 2020 at 09:24:00AM +0200, Guido Günther wrote:
> On Tue, Jun 30, 2020 at 09:28:34PM +0200, Andrea Bolognani wrote:
> > Has anyone managed to reproduce this? I've built 6.0.0-7 from source
> > in a tight loop 100 times, both in a sid:i386 chroot via cowbuilder
> > and in a sid:i386 VM, without encountering a single failure.
> 
> I tried to reproduce too when this came in and couldn't.

Okay, let's assume it was a temporary glitch then - at least until
another build fails for the same reason.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#960762: libvirt: random (?) test hangs

[Andrea Bolognani]

On Sat, May 16, 2020 at 03:00:46PM +0300, Adrian Bunk wrote:
> Source: libvirt
> Version: 6.0.0-7
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/fetch.php?pkg=libvirt=all=6.0.0-7=1589452859=0
> https://buildd.debian.org/status/fetch.php?pkg=libvirt=i386=6.0.0-7=1589494701=0
> 
> ...
> make  check-TESTS
> make[4]: Entering directory '/<>/debian/build/tests'
> make[5]: Entering directory '/<>/debian/build/tests'
> PASS: sockettest
> PASS: virbuftest
> PASS: virhostcputest
[...]
> PASS: virsh-vcpupin
> PASS: virsh-optparse
> PASS: virt-aa-helper-test
> E: Build killed with signal TERM after 150 minutes of inactivity

Has anyone managed to reproduce this? I've built 6.0.0-7 from source
in a tight loop 100 times, both in a sid:i386 chroot via cowbuilder
and in a sid:i386 VM, without encountering a single failure.

The latest build attempt on i386 also failed:

  
https://buildd.debian.org/status/fetch.php?pkg=libvirt=i386=6.4.0-1=1593097042=0

However, the failure in this case was not limited to i386 and the
error was completely different, caused this time by

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963704

All I can think of at this point is a temporary glitch of the
buildd. In a couple of weeks, when we upload 6.5.0, we'll hopefully
see that build fine on all architectures, i386 included...

Does anyone have any better theories? Or a way to dig further?

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#952200: libvirt-dbus: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Andrea Bolognani]

On Tue, Apr 14, 2020 at 08:25:53PM +0300, Adrian Bunk wrote:
> On Sun, Mar 29, 2020 at 10:18:05PM +0200, Andrea Bolognani wrote:
> >...
> > Adrian, I see you tagged the bug as fixed-upstream: can you please
> > share any additional information you might have and that convinced
> > you the bug is no longer present upstream? Thanks in advance!
> 
> Sorry for failing to include this information,
> please see the commit linked above.

Thanks Adrian!

I had already tracked down the commit myself in the meantime, and I
have prepared an updated libvirt-dbus package that's pending review:

  https://salsa.debian.org/libvirt-team/libvirt-dbus/-/merge_requests/1

Hopefully we'll be able to upload it soon :)

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#951934: closed by Debian FTP Masters (reply to Andrea Capriotti ) (Bug#951934: fixed in autoradio 3.4-1)

[Andrea Capriotti]

Il giorno mar, 31/03/2020 alle 12.55 +0300, Adrian Bunk ha scritto:
> On Tue, Mar 17, 2020 at 11:24:09PM +, Debian Bug Tracking System
> wrote:
> > ...
> > Architecture: source all
> > ...
> >  autoradio (3.4-1) unstable; urgency=medium
> >  .
> >* New upstream release (Closes: #951934)
> > ...
> 
> Thanks a lot for fixing this bug.
> 
> Could you make a source-only upload to allow the fix to migrate
> to testing?
> 

Done. 

Bye
-- 
Andrea Capriotti 

Bug#952200: libvirt-dbus: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Andrea Bolognani]

On Sun, Feb 23, 2020 at 02:09:46PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > test_connect.py F.   
> > [100%]
> > 
> > === FAILURES 
> > ===
> > ___ TestConnect.test_connect_node_device_create_xml 
> > 
> > Fixture "node_device_create" called directly. Fixtures are not meant to be 
> > called directly,
> > but are created automatically when test functions request them as 
> > parameters.
> > See https://docs.pytest.org/en/latest/fixture.html for more information 
> > about fixtures, and
> > https://docs.pytest.org/en/latest/deprecations.html#calling-fixtures-directly
> >  about how to update your code.
> > = 1 failed, 33 passed in 3.89 seconds 
> > ==
> > FAIL test_connect.py (exit status: 1)
> 
> The full build log is available from:
>http://qa-logs.debian.net/2020/02/22/libvirt-dbus_1.3.0-1_unstable.log

Lucas, thanks for the report, and sorry for not noticing it earlier!
I'll look into it.

Adrian, I see you tagged the bug as fixed-upstream: can you please
share any additional information you might have and that convinced
you the bug is no longer present upstream? Thanks in advance!

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#908827: mesa: Fails to build on Stretch, missing min build dep

[Andrea Vettorello]

Source: mesa
Version: 18.2.0-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

Mesa 18.2.0-1 fails to build on Stretch, I can't find the relevant bug report
on freedesktop.org but now it requires xcb-proto >= 1.13.

After compiling and installing xcb-proto and libxcb 1.13-1 from unstable, the
package was built succesfully.



-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-rc2-test1 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#902637: fixed in autoradio 3.1-1

[Andrea Capriotti]

Il giorno mer, 05/09/2018 alle 14.23 +0200, Santiago Vila ha scritto:
> found 902637 3.1-1
> thanks
> 
> Hi. I'm going to recycle this bug instead of filing a new one because
> the old subject ("FTBFS in buster/sid") still applies.
> 
> Now it fails this way:
> 
> ModuleNotFoundError: No module named 'magic'
> 
> which suggests a missing build-depends.
> 
> Please see:
> 
> 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/autoradio.html

Hi Santiago, 

I already fixed it in version 3.1-3:

https://salsa.debian.org/debian/autoradio/commit/6477aa1dd4ca16cb16f1a7581fddb781abd8095f

Bye

Bug#896888: panics during start on protocol.DeviceIDFromBytes

[Andrea Villa]

Package: syncthing
Version: 0.14.46+ds1-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Syncthing refuses to start with the following error:

[edited] 14:47:33 INFO: syncthing v0.14.46-ds1 "Dysprosium Dragonfly"
(go1.10.1 linux-amd64) debian@debian 2018-04-04 18:28:29 UTC [noupgrade]
[edited] 14:47:33 INFO: My ID: [edited]
[edited] 14:47:34 INFO: Single thread SHA256 performance is 344 MB/s using
minio/sha256-simd (287 MB/s using crypto/sha256).
[edited] 14:47:34 INFO: Hashing performance with weak hash is 249.13 MB/s
[edited] 14:47:34 INFO: Hashing performance without weak hash is 335.79 MB/s
[edited] 14:47:34 INFO: Weak hash disabled, as it has an unacceptable
performance impact.
...
Panic at 2018-04-25T14:47:35+02:00
panic: incorrect length of byte slice representing device ID

goroutine 1 [running]:
github.com/syncthing/syncthing/lib/protocol.DeviceIDFromBytes(0x234,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
/build/syncthing-PqLcAU/syncthing-0.14.46+ds1/_build/src/
github.com/syncthing/syncthing/lib/protocol/deviceid.go:44 +0xa7
github.com/syncthing/syncthing/lib/db.readWriteTransaction.updateGlobal(...)
/build/syncthing-PqLcAU/syncthing-0.14.46+ds1/_build/src/
github.com/syncthing/syncthing/lib/db/leveldb_transactions.go:89 +0x8d
github.com/syncthing/syncthing/lib/db.(*Instance).updateSchema0to1(0xc42021b7a0)
/build/syncthing-PqLcAU/syncthing-0.14.46+ds1/_build/src/
github.com/syncthing/syncthing/lib/db/leveldb_dbinstance.go:593 +0x651
github.com/syncthing/syncthing/lib/db.(*Instance).UpdateSchema(0xc42021b7a0)
/build/syncthing-PqLcAU/syncthing-0.14.46+ds1/_build/src/
github.com/syncthing/syncthing/lib/db/leveldb_dbinstance.go:92 +0xf1
main.syncthingMain(0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xb349d4, 0x1, 0x0, 0x0,
...)
/build/syncthing-PqLcAU/syncthing-0.14.46+ds1/_build/src/
github.com/syncthing/syncthing/cmd/syncthing/main.go:774 +0x11cd
main.main()
/build/syncthing-PqLcAU/syncthing-0.14.46+ds1/_build/src/
github.com/syncthing/syncthing/cmd/syncthing/main.go:440 +0x3e9

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

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

Versions of packages syncthing depends on:
ii  libc6  2.27-3

syncthing recommends no packages.

syncthing suggests no packages.

-- no debconf information

Bug#894736: Checker config files allow arbitrary code execution scenarios

[Andrea Capriotti]

Il giorno mar, 03/04/2018 alle 20.03 +0200, Enrico Zini ha scritto:
> Package: vim-syntastic
> Version: 3.8.0-1
> Severity: serious
> 
> Hello,
> 
> syntastic has a Configuration Files[1] feature enabled for several
> checkers, where:
> 
>   a configuration file is looked up in the directory of the file
> being
>   checked, then upwards in parent directories.  The search stops
> either
>   when a file with the right name is found, or when the root of the
>   filesystem is reached.[1]
> 
> [1] https://github.com/vim-syntastic/syntastic/blob/master/doc/syntas
> tic-checkers.txt#L7744
> 
> Each line found in the configuration file is escaped as a single
> argument and appended to the checker command being run.
> 
> I am not an expert on the various possibly dangerous command line
> options of all possible checkers, but I played with one I knew how to
> play with, and what follows is a possible attack. There might be
> easier
> attacks on checkers that are enabled by default, since the
> configuration
> files features, as it is now, leaves a pretty wide attack surface
> open.

Hi Enrico, 

you are right and the attack works. I opened this upstream issue:

https://github.com/vim-syntastic/syntastic/issues/2170

and he fixed the problem in 3.9.0 release. I'll build and upload it as
soon as possible.

Best Regards
-- 
Andrea Capriotti <capri...@debian.org>

signature.asc
Description: This is a digitally signed message part

Bug#878246: lxc package uninstallable

[Andrea]

Package: lxc
Version: 1:2.0.8-2
Severity: grave
Justification: renders package unusable

lxc package depends on python3-lxc package, which is currently
uninstallable because it depends on python3 <3.6

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

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

Versions of packages lxc depends on:
ii  init-system-helpers  1.49
ii  libapparmor1 2.11.0-11
ii  libc62.24-17
ii  libcap2  1:2.25-1
ii  libgnutls30  3.5.15-2
pn  liblxc1  
ii  libseccomp2  2.3.1-2.1
ii  libselinux1  2.7-2
ii  lsb-base 9.20170808
ii  python3  3.6.3-1
pn  python3-lxc  

Versions of packages lxc recommends:
ii  bridge-utils  1.5-14
ii  debootstrap   1.0.91
ii  dirmngr   2.2.1-2
ii  dnsmasq-base  2.78-1
ii  gnupg 2.2.1-2
ii  iptables  1.6.1-2
pn  libpam-cgfs   
ii  lxcfs 2.0.7-2
ii  openssl   1.1.0f-5
pn  rsync 
ii  uidmap1:4.5-1

Versions of packages lxc suggests:
pn  apparmor 
ii  btrfs-tools  4.12-1
ii  lvm2 2.02.173-1

Bug#869670: Dependency missing

[Andrea Villa]

The reason for this bug is a dependency problem:

The current sid kernel is linux-image-4.11.0-2-amd64
->
corresponding headers are linux-headers-4.11.0-2-amd64:
->
they depend on linux-headers-4.11.0-2-common (= 4.11.11-1+b1)
->
there is no such version (only 4.11.11-1 *NO +b1*), maybe never made it
from experimental?

Only work around is to boot to an older kernel and install the
corresponding linux-headers-VERSION package.

Do not try to fix by installing/upgrading meta-package linux-headers-amd64
since in sid this depends on linux-headers-4.11.0-2-amd64 thus initiating
the broken dependency links described above.
Don't try to fix 4.11 kernel (it's EOL anyway), we should probably just
wait for 4.12 coming from experimental soon.

Hope this helps you folks!

Bests,

Andrea

Bug#847542: libmozjs-24-0 24.2.0-4 breaks gnome-shell, preventing gdm3 from starting

[Andrea Zagli]

same here; downgraded to testing version and everything works again

Bug#846898: Only works with Gnome wayland from gdm3

[Andrea Zagli]

same here

Bug#841634: virtualbox: Package unusable

[Andrea]

Package: virtualbox
Version: 5.1.8-dfsg-4
Followup-For: Bug #841634

Tried purging and reinstalling virtualbox and virtualbox-qt, problem persists.
Package is unusable.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages virtualbox depends on:
ii  adduser   3.115
ii  init-system-helpers   1.45
ii  libc6 2.24-5
ii  libcurl3-gnutls   7.50.1-1
ii  libdevmapper1.02.12:1.02.133-1
ii  libgcc1   1:6.2.0-9
ii  libgsoap102.8.35-3
ii  libpng16-16   1.6.25-2
ii  libpython3.5  3.5.2-6+b1
ii  libsdl1.2debian   1.2.15+dfsg1-4
ii  libssl1.0.2   1.0.2j-1
ii  libstdc++66.2.0-9
ii  libvncserver1 0.9.10+dfsg-3+b1
ii  libvpx4   1.6.0-2
ii  libx11-6  2:1.6.3-1
ii  libxcursor1   1:1.1.14-1+b1
ii  libxext6  2:1.3.3-1
ii  libxml2   2.9.4+dfsg1-2
ii  libxmu6   2:1.1.2-2
ii  libxt61:1.1.5-1
ii  procps2:3.3.12-2
ii  python3   3.5.1-4
pn  python3:any   
ii  virtualbox-dkms [virtualbox-modules]  5.1.8-dfsg-4
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages virtualbox recommends:
ii  libgl1-mesa-glx [libgl1]  12.0.3-1
ii  libqt5core5a  5.6.1+dfsg-3+b1
ii  libqt5opengl5 5.6.1+dfsg-3+b1
ii  libqt5widgets55.6.1+dfsg-3+b1
ii  virtualbox-qt 5.1.8-dfsg-4

Versions of packages virtualbox suggests:
pn  vde2
ii  virtualbox-guest-additions-iso  5.1.8-1

-- no debconf information

Bug#811691: FTBFS with GCC 6: enumerator value for... is not

[Andrea Musuruane]

Hi!
Leigh Scott made a patch to fix the FTBFS with GCC 6 for desmume.

It's available in RPM Fusion:
https://pkgs.rpmfusion.org/cgit/free/desmume.git/tree/gcc6_fixes.patch

Bye,

Andrea

Bug#831039: totem crash on startup, can't start it

[Andrea Zagli]

yes it works!!! thanks a lot!!!

also rhythmbox and epiphany-browser work

but it doesn't work for steam client; but i don't know if it is the  
same problem; it doesn't crash but it doesn't show "web pages"  
(everything except list of buyed games), and it is started to not work  
in the same moment of totem/rhythmbox/epipany-browser

Bug#831039: totem crash on startup, can't start it

[Andrea Zagli]

same here

and i have the same problem with rhytmnbox and epiphany (if i open  
some video, as in youtube)


it seems the problem is "solved" using locale C

Bug#830419: Patch for Debian bug #830419

[Andrea Claudi]

Hello,
I think this bug can be fixed simply adding texlive-generic-extra to the 
build-depends, as in the attached patch.

Please, let me know if I can further help with this.

Regards,
Andrea Claudi




La seguente informativa e' inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente. 



INVESTI NELLA RICERCA 

il 5 per mille all'Universita' Politecnica delle Marche e' un investimento per i giovani, per il loro futuro - C.F. 00382520427 

http://www.univpm.it/5_per_mille 
diff -Nru debomatic-0.21/debian/changelog debomatic-0.21/debian/changelog
--- debomatic-0.21/debian/changelog	2015-10-07 21:19:45.0 +0200
+++ debomatic-0.21/debian/changelog	2016-07-19 12:23:00.0 +0200
@@ -1,3 +1,11 @@
+debomatic (0.21-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/control:
+- Add build-depends on texlive-generic-extra (Closes: #830419)
+
+ -- Andrea Claudi <em...@andreaclaudi.it>  Tue, 19 Jul 2016 12:21:06 +0200
+
 debomatic (0.21-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru debomatic-0.21/debian/control debomatic-0.21/debian/control
--- debomatic-0.21/debian/control	2015-04-26 12:05:23.0 +0200
+++ debomatic-0.21/debian/control	2016-07-19 12:20:48.0 +0200
@@ -12,6 +12,7 @@
texlive-latex-recommended,
texlive-fonts-recommended,
texlive-latex-extra,
+   texlive-generic-extra,
gettext
 X-Python3-Version: >= 3.2
 Standards-Version: 3.9.6

Bug#811655: Patch for Debian bug #811655

[Andrea Claudi]

Hello,
This simple patch fix the build issue with gcc-6.
Please, let me know if it needs improvements.

Regards,
Andrea Claudi




La seguente informativa e' inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente. 



INVESTI NELLA RICERCA 

il 5 per mille all'Universita' Politecnica delle Marche e' un investimento per i giovani, per il loro futuro - C.F. 00382520427 

http://www.univpm.it/5_per_mille 
diff -Nru starplot-0.95.5/debian/changelog starplot-0.95.5/debian/changelog
--- starplot-0.95.5/debian/changelog	2014-05-23 19:43:35.0 +0200
+++ starplot-0.95.5/debian/changelog	2016-07-12 12:13:32.0 +0200
@@ -1,3 +1,10 @@
+starplot (0.95.5-8.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS in convert.cc for gcc-6. (Closes: #811655)
+
+ -- Andrea Claudi <a.cla...@univpm.it>  Tue, 12 Jul 2016 12:12:51 +0200
+
 starplot (0.95.5-8.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru starplot-0.95.5/debian/patches/03-fix-ftbfs-convert.diff starplot-0.95.5/debian/patches/03-fix-ftbfs-convert.diff
--- starplot-0.95.5/debian/patches/03-fix-ftbfs-convert.diff	1970-01-01 01:00:00.0 +0100
+++ starplot-0.95.5/debian/patches/03-fix-ftbfs-convert.diff	2016-07-12 11:14:26.0 +0200
@@ -0,0 +1,40 @@
+Index: starplot-0.95.5/src/convert/convert.cc
+===
+--- starplot-0.95.5.orig/src/convert/convert.cc
 starplot-0.95.5/src/convert/convert.cc
+@@ -49,7 +49,7 @@ void parse_star_file(istream & infile, o
+ 		 bool using_stdout, bool add_sun)
+ {
+   int lineno = 0;
+-  bool sun_found = false, moredata = true;
++  bool sun_found = false;
+   char record[1000];
+   Star * tempstar = 0, * currentstar = 0, * previousstar = 0;
+ 
+@@ -64,7 +64,7 @@ available on the StarPlot web page, you
+ in that package for more information.") << endl << endl;
+ 
+   do {
+-moredata = infile.getline(record, 999, '\n');
++infile.getline(record, 999, '\n');
+ record[999] = 0;
+ 
+ // $ ; and , have special meanings to StarPlot, so purge them:
+@@ -73,7 +73,7 @@ in that package for more information.")
+ record[i] = ' ';
+   
+ tempstar = parse_star_record(record, format);
+-if (tempstar || !moredata) {
++if (tempstar || infile.eof()) {
+   delete previousstar;
+   previousstar = currentstar;
+   currentstar = tempstar;
+@@ -111,7 +111,7 @@ in that package for more information.")
+ if (!using_stdout && !(lineno % 1000))
+   cout << starstrings::ssprintf(_("%d records converted."), lineno) << endl;
+ 
+-  } while (moredata) ;
++  } while (!infile.eof()) ;
+ 
+   delete previousstar;
+ 
diff -Nru starplot-0.95.5/debian/patches/series starplot-0.95.5/debian/patches/series
--- starplot-0.95.5/debian/patches/series	2012-06-26 21:12:55.0 +0200
+++ starplot-0.95.5/debian/patches/series	2016-07-12 12:12:29.0 +0200
@@ -1,2 +1,3 @@
 01-starplot_desktop_file.diff
 02-fix-ftbfs-and-hrdiagram-opts.diff
+03-fix-ftbfs-convert.diff

Bug#822407: enscript: FTBFS: error: automatic de-ANSI-fication support has been removed

[Andrea Bolognani]

On Sat, Apr 23, 2016 at 09:10:51PM -0700, Martin Michlmayr wrote:
> Package: enscript
> Version: 1.6.5.90-2
> Severity: serious
> 
> This package fails to build in unstable:
> 
> > sbuild (Debian sbuild) 0.68.0 (15 Jan 2016) on dl580gen9-02.hlinux
> ...
> >debian/rules override_dh_auto_configure
> > make[1]: Entering directory '/<>'
> > AUTOMAKE=automake-1.11 autoreconf -fis
> > Copying file intl/Makefile.in
> > Copying file m4/intldir.m4
> > Copying file po/Makevars.template
> > configure.ac:14: error: automatic de-ANSI-fication support has been removed
> > /usr/share/aclocal-1.15/obsolete.m4:26: AM_C_PROTOTYPES is expanded from...
> > configure.ac:14: the top level
> > autom4te: /usr/bin/m4 failed with exit status: 1
> > aclocal: error: echo failed with exit status: 1
> > autoreconf: aclocal failed with exit status: 1
> > debian/rules:13: recipe for target 'override_dh_auto_configure' failed
> > make[1]: *** [override_dh_auto_configure] Error 1
> > make[1]: Leaving directory '/<>'
> > debian/rules:6: recipe for target 'build' failed
> > make: *** [build] Error 2

The attached patch makes the package build again.

Tested using cowbuilder with an up-to-date sid chroot.

-- 
Andrea Bolognani <e...@kiyuko.org>
Resistance is futile, you will be garbage collected.
From 453531070fd2b44dbef28c01763ad1836bb51fad Mon Sep 17 00:00:00 2001
From: Andrea Bolognani <e...@kiyuko.org>
Date: Sat, 28 May 2016 17:53:06 +0200
Subject: [PATCH] Force use of aclocal 1.11

debian/rules is set up so that automake 1.11 will
always be used - even on unstable, where the default
version is 1.15. However, the same is not true for
aclocal, which will be always used in its default
version.

The version mismatch between automake 1.11 and
aclocal 1.15 causes a FTBFS.

Fix the issue by forcing the use of aclocal 1.11.

Signed-off-by: Andrea Bolognani <e...@kiyuko.org>
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index c6e729f..a6fa59f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,7 +10,7 @@ override_dh_auto_clean:
 	find -name Makefile.in -exec rm {} \;
 
 override_dh_auto_configure:
-	AUTOMAKE=automake-1.11 autoreconf -fis
+	AUTOMAKE=automake-1.11 ACLOCAL=aclocal-1.11 autoreconf -fis
 	dh_auto_configure
 
 override_dh_auto_install:
-- 
2.8.1



signature.asc
Description: PGP signature

Bug#818590: irssi-plugin-otr: mismatching ABI version with current irssi

[Andrea Lusuardi]

Package: irssi-plugin-otr
Version: 1.0.0-1+b2
Severity: grave
Justification: renders package unusable

Hi,
as of latest update the otr plugin is unloadable (/load otr fail in relation 
with https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817172 )
but even if the plugin is manually loaded via

/load /usr/lib/irssi/modules/libotr.so

you get the error

Irssi: otr/otr is ABI version 0 but Irssi is version 1, cannot load

rendering the plugin completely useless.
Let me know how/if i can help,
thanks

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

Kernel: Linux 4.5.0-x86_64-linode65 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages irssi-plugin-otr depends on:
ii  irssi0.8.18-1
ii  libc62.22-3
ii  libgcrypt20  1.6.5-2
ii  libotr5  4.1.1-1

irssi-plugin-otr recommends no packages.

irssi-plugin-otr suggests no packages.

-- no debconf information

Bug#806212: monodevelop: Program will not start

[Andrea Stacchiotti]

Package: monodevelop
Version: 5.5.0.227-1
Severity: grave
Justification: renders package unusable

The program will simply fail to start, leaving no info even on a terminal
window.

Using command-line flags will make some text appear, but there is no way of
running the GUI.

Probably related to #802406



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

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages monodevelop depends on:
ii  gnome-icon-theme  3.12.0-1
ii  gnome-terminal [x-terminal-emulator]  3.18.2-1
ii  libc6 2.19-22
ii  libcairo2 1.14.4-1
ii  libgconf2.0-cil   2.24.2-4
ii  libglade2.0-cil   2.12.10-5.1
ii  libglib2.0-0  2.46.2-1
ii  libglib2.0-cil2.12.10-5.1
ii  libgnome-vfs2.0-cil   2.24.2-4
ii  libgnome2.24-cil  2.24.2-4
ii  libgtk2.0-0   2.24.28-1
ii  libgtk2.0-cil 2.12.10-5.1
ii  libgtkspell0  2.0.16-1.1
ii  libmono-cairo4.0-cil  4.0.4.1+dfsg-1
ii  libmono-corlib4.5-cil 4.0.4.1+dfsg-1
ii  libmono-microsoft-build-engine4.0-cil 4.0.4.1+dfsg-1
ii  libmono-microsoft-build-framework4.0-cil  4.0.4.1+dfsg-1
ii  libmono-microsoft-build-utilities-v4.0-4.0-cil4.0.4.1+dfsg-1
ii  libmono-microsoft-csharp4.0-cil   4.0.4.1+dfsg-1
ii  libmono-posix4.0-cil  4.0.4.1+dfsg-1
ii  libmono-sharpzip4.84-cil  4.0.4.1+dfsg-1
ii  libmono-system-componentmodel-dataannotations4.0-cil  4.0.4.1+dfsg-1
ii  libmono-system-configuration4.0-cil   4.0.4.1+dfsg-1
ii  libmono-system-core4.0-cil4.0.4.1+dfsg-1
ii  libmono-system-data-services-client4.0-cil4.0.4.1+dfsg-1
ii  libmono-system-data4.0-cil4.0.4.1+dfsg-1
ii  libmono-system-design4.0-cil  4.0.4.1+dfsg-1
ii  libmono-system-drawing4.0-cil 4.0.4.1+dfsg-1
ii  libmono-system-runtime-serialization4.0-cil   4.0.4.1+dfsg-1
ii  libmono-system-runtime4.0-cil 4.0.4.1+dfsg-1
ii  libmono-system-security4.0-cil4.0.4.1+dfsg-1
ii  libmono-system-servicemodel4.0a-cil   4.0.4.1+dfsg-1
ii  libmono-system-web-mvc3.0-cil 4.0.4.1+dfsg-1
ii  libmono-system-web-razor2.0-cil   4.0.4.1+dfsg-1
ii  libmono-system-web-services4.0-cil4.0.4.1+dfsg-1
ii  libmono-system-web-webpages-razor2.0-cil  4.0.4.1+dfsg-1
ii  libmono-system-web4.0-cil 4.0.4.1+dfsg-1
ii  libmono-system-windows-forms4.0-cil   4.0.4.1+dfsg-1
ii  libmono-system-xaml4.0-cil4.0.4.1+dfsg-1
ii  libmono-system-xml-linq4.0-cil4.0.4.1+dfsg-1
ii  libmono-system-xml4.0-cil 4.0.4.1+dfsg-1
ii  libmono-system4.0-cil 4.0.4.1+dfsg-1
ii  libmono-windowsbase4.0-cil4.0.4.1+dfsg-1
ii  libpango-1.0-01.38.1-1
ii  libpangocairo-1.0-0   1.38.1-1
ii  libwebkitgtk-1.0-02.4.9-2+b1
ii  mono-runtime  4.0.4.1+dfsg-1
ii  mono-runtime-sgen 4.0.4.1+dfsg-1
ii  monodoc-base  4.0.4.1+dfsg-1
ii  monodoc-manual4.0.4.1+dfsg-1
ii  pkg-config0.29-2
ii  terminator [x-terminal-emulator]  0.97-4
ii  xterm [x-terminal-emulator]   320-1

Versions of packages monodevelop recommends:
ii  libglade2.0-cil-dev  2.12.10-5.1
ii  libgtk2.0-cil-dev2.12.10-5.1
ii  mono-devel   4.0.4.1+dfsg-1

Versions of packages monodevelop suggests:
ii  exuberant-ctags 1:5.9~svn20110310-10
ii  gcc 4:5.2.1-4
ii  gettext 0.19.6-1
ii  make4.0-8.2
pn  mono-vbnc   
pn  mono-xsp | mono-xsp4
pn  monodevelop-database
pn  monodevelop-debugger-gdb

Bug#791604: python-z3: __init__.py is missing in the base module folder. This makes the module not importable.

[Andrea Villa]

Package: python-z3
Version: 4.4.0-1
Severity: grave
Tags: patch
Justification: renders package unusable

It is enough to touch a __init__.py file inside 
/usr/lib/python2.7/dist-packages/z3/ to make the module importable.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-z3 depends on:
ii  libc6   2.19-18
ii  libgcc1 1:5.1.1-12
ii  libgomp15.1.1-12
ii  libstdc++6  5.1.1-12
ii  python  2.7.9-1

python-z3 recommends no packages.

python-z3 suggests no packages.

-- no debconf information


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

Bug#789121: segfaults in libc6 when accessing ssl keys and signatures

[Andrea Lusuardi]

Package: claws-mail
Version: 3.11.1-3
Severity: grave

Hi,
since latest update claws-mail on my debian sid starts up correctly and i can 
access emails
and even send one, until i try to fetch unread emails from any ssl/tls 
protected source, it
then immediately segfaults. I am attaching some of the final strace output 
hoping this helps.
Thanks and let me know how i can help with the debugging, i have some 
experience with gdb and related.

recvmsg(4, 0x7ffd98850f30, 0)   = -1 EAGAIN (Resource temporarily 
unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN|POLLPRI}, {fd=6, 
events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=11, 
events=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN|POLLOUT}], 8, 
42331) = 1 ([{fd=6, revents=POLLIN}])
recvmsg(4, 0x7ffd98850f30, 0)   = -1 EAGAIN (Resource temporarily 
unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN|POLLPRI}, {fd=6, 
events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=11, 
events=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN|POLLOUT}], 8, 
42330) = 1 ([{fd=6, revents=POLLIN}])
read(6, \4\0\0\0\0\0\0\0, 16) = 8
recvmsg(4, 0x7ffd98850f30, 0)   = -1 EAGAIN (Resource temporarily 
unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN|POLLPRI}, {fd=6, 
events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=11, 
events=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN|POLLOUT}], 8, 
42330) = 1 ([{fd=15, revents=POLLOUT}])
read(6, 0x7ffd988510e0, 16) = -1 EAGAIN (Resource temporarily 
unavailable)
write(6, \1\0\0\0\0\0\0\0, 8) = 8
getsockopt(15, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
fstat(15, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
fcntl(15, F_GETFL)  = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(15, F_GETFL)  = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(15, F_SETFL, O_RDWR)  = 0
stat(/etc/pki/tls/certs/ca-bundle.crt, 0x7ffd98850ee0) = -1 ENOENT (No such 
file or directory)
stat(/etc/certs/ca-bundle.crt, 0x7ffd98850ee0) = -1 ENOENT (No such file or 
directory)
stat(/etc/ssl/ca-bundle.pem, 0x7ffd98850ee0) = -1 ENOENT (No such file or 
directory)
stat(/usr/share/ssl/certs/ca-bundle.crt, 0x7ffd98850ee0) = -1 ENOENT (No such 
file or directory)
stat(/etc/ssl/certs/ca-certificates.crt, {st_mode=S_IFREG|0644, 
st_size=286339, ...}) = 0
stat(/etc/pki/tls/certs/ca-bundle.crt, 0x7ffd98850ee0) = -1 ENOENT (No such 
file or directory)
stat(/etc/certs/ca-bundle.crt, 0x7ffd98850ee0) = -1 ENOENT (No such file or 
directory)
stat(/etc/ssl/ca-bundle.pem, 0x7ffd98850ee0) = -1 ENOENT (No such file or 
directory)
stat(/usr/share/ssl/certs/ca-bundle.crt, 0x7ffd98850ee0) = -1 ENOENT (No such 
file or directory)
stat(/etc/ssl/certs/ca-certificates.crt, {st_mode=S_IFREG|0644, 
st_size=286339, ...}) = 0
open(/etc/ssl/certs/ca-certificates.crt, O_RDONLY) = 18
fstat(18, {st_mode=S_IFREG|0644, st_size=286339, ...}) = 0
fstat(18, {st_mode=S_IFREG|0644, st_size=286339, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fad8b7f2000
lseek(18, 0, SEEK_CUR)  = 0
read(18, -BEGIN CERTIFICATE-\nMIIF..., 282624) = 282624
read(18, KZhcEmVeq5CSS2bf1XUS\nU1QYpt6K1rt..., 4096) = 3715
read(18, , 4096)  = 0
close(18)   = 0
munmap(0x7fad8b7f2000, 4096)= 0
clone(child_stack=0x7fad79691cf0, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x7fad796929d0, tls=0x7fad79692700, child_tidptr=0x7fad796929d0) 
= 27068
recvmsg(4, 0x7ffd98850d10, 0)   = -1 EAGAIN (Resource temporarily 
unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN|POLLPRI}, {fd=6, 
events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=11, 
events=POLLIN}, {fd=13, events=POLLIN}], 7, 0) = 1 ([{fd=6, revents=POLLIN}])
nanosleep({0, 5000}, 0x7ffd98850fe0) = 0
recvmsg(4, 0x7ffd98850d10, 0)   = -1 EAGAIN (Resource temporarily 
unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN|POLLPRI}, {fd=6, 
events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=11, 
events=POLLIN}, {fd=13, events=POLLIN}], 7, 0) = 1 ([{fd=6, revents=POLLIN}])
read(6, \1\0\0\0\0\0\0\0, 16) = 8
nanosleep({0, 5000},  unfinished ...
+++ killed by SIGSEGV +++
Segmentation fault


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

Kernel: Linux 4.0.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=it_IT, LC_CTYPE=it_IT (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages claws-mail depends on:
ii  libarchive13 3.1.2-11+b1
ii  libassuan0   2.2.1-1
ii  libatk1.0-0

Bug#786519:

[Andrea Villa]

Pinning to the stable libwine (1.6.2-20) might be the only option for now:

--
Package: libwine libwine:i386
Pin: release a=stable
Pin-Priority: 700
--

You may want to either remove and install against pin or increase Priority
to force downgrade from installed package, although broken packages might
make your life hard.

Cheers

Bug#784587: [Pkg-utopia-maintainers] Bug#784587: network-manager: does not set up resolv.conf

[Andrea Capriotti]

On Thu, 07 May 2015 01:09:53 +0200 Michael Biebl bi...@debian.org wrote:
 Control: tags -1 moreinfo

 Please provide more informatin about your network setup:
 a/ which interfaces are managed by NM, which are managed elsewhere
 (ifupdown)
 b/ please provide a verbose debug log of NetworkManager

Same problem here.

# grep resolvconf /var/log/syslog
May  7 01:16:15 nb-capriotti NetworkManager[13437]: warn  could not commit 
DNS changes: /sbin/resolvconf is not executable

I fixed it installing resolvconf.

Bye
-- 
Andrea Capriotti capri...@debian.org


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

Bug#773583: vim-tlib: purging removes directories owned by vim-common: /var/lib/vim/addons/, /var/lib/vim/

[Andrea Capriotti]

Package: vim-tlib
Version: 1.12-2
Severity: serious
Justification: Policy 6.8

Hi,

same problem of bug #773184.

This part of the postrm is faulty:

case $1 in
purge)
if [ -d /var/lib/vim/addons/samples/ ]; then
  rmdir -p --ignore-fail-on-non-empty /var/lib/vim/addons/samples || :
fi
;;

I'm uploading the fixed package.



-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vim-tlib depends on:
ii  vim2:7.4.488-3
ii  vim-addon-manager  0.5.3
ii  vim-gnome [vim]2:7.4.488-3

vim-tlib recommends no packages.

vim-tlib suggests no packages.

-- no debconf information


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

Bug#773184: vim-addon-mw-utils: purging removes directories owned by vim-common: /var/lib/vim/addons/, /var/lib/vim/

[Andrea Capriotti]

Il giorno lun, 15/12/2014 alle 12.50 +0100, Andreas Beckmann ha scritto:

 during a test with piuparts I noticed your package removes directories
 that were installed by another package.
 
 If a directory is used by several packages, all should ship it as part
 of the package (possibly empty, using $package.dirs to create it), and
 no package should mkdir/rmdir it in the maintainer scripts as dpkg will
 take care of this.
 Do not work around dpkg bugs failing to do the removal properly.
 
 From the attached log (scroll to the bottom...):
 
 0m42.5s ERROR: FAIL: After purging files have disappeared:
   /var/lib/vim/owned by: vim-common
   /var/lib/vim/addons/ owned by: vim-common
 
 This part of the postrm looks faulty:
 
 case $1 in
 purge)
 if [ -d /var/lib/vim/addons/autoload/ ]; then
   rmdir -p --ignore-fail-on-non-empty /var/lib/vim/addons/autoload || 
 :
 fi
 ;;
 
 * /var/lib/vim/addons/autoload does not sound specific to this package
 * -p removes parent directories

Hi Andreas,

you are right. I fixed it:

http://anonscm.debian.org/cgit/collab-maint/vim-addon-mw-utils.git/commit/?id=5131ae8be7b5a05ada40154511e0d0e98502f8ba

I'll ask for an unblock.

Best Regards
-- 
Andrea Capriotti capri...@debian.org


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

Bug#772673: libjerasure-dev: missing dependency on libgf-complete-dev

[Andrea Claudi]

Hello,
This patch should solve the problem reported by Dmitry.
I tested it compiling a dummy program including galois.h and gcc gives no 
error.

Hope this helps.

Regards.
Andreadiff -Nru jerasure-2.0.0/debian/changelog jerasure-2.0.0/debian/changelog
--- jerasure-2.0.0/debian/changelog	2014-06-16 19:18:55.0 +0200
+++ jerasure-2.0.0/debian/changelog	2014-12-10 01:03:15.0 +0100
@@ -1,3 +1,11 @@
+jerasure (2.0.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: add Depends on libgf-complete-dev for
+libjerasure-dev (Closes: #772673).
+
+ -- Andrea Claudi a.cla...@univpm.it  Wed, 10 Dec 2014 01:01:05 +0100
+
 jerasure (2.0.0-1) unstable; urgency=low
 
   * Initial release (Closes: #750766).
diff -Nru jerasure-2.0.0/debian/control jerasure-2.0.0/debian/control
--- jerasure-2.0.0/debian/control	2014-06-16 19:18:55.0 +0200
+++ jerasure-2.0.0/debian/control	2014-12-10 01:01:01.0 +0100
@@ -14,7 +14,9 @@
 Package: libjerasure-dev
 Section: libdevel
 Architecture: any
-Depends: libjerasure2 (= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends}
+Depends: libjerasure2 (= ${binary:Version}),
+ libgf-complete-dev,
+ ${misc:Depends}, ${shlibs:Depends}
 Description: forward error correction erasure channel library - development files
  In information theory, an erasure code is a forward error correction (FEC)
  code for the binary erasure channel, which transforms a message of symbols

Bug#771461: /var/state/samhain/

[Andrea Claudi]

Hi,
This patch should fix the problem, moving the non-volatile state for the 
samhain package to /var/lib/samhain.

Please, tell me if I need to fix something to make this acceptable.

Cheers,
Andrea

bts tags 771461 + patch
thanksdiff -u samhain-3.1.0/debian/changelog samhain-3.1.0/debian/changelog
--- samhain-3.1.0/debian/changelog
+++ samhain-3.1.0/debian/changelog
@@ -1,3 +1,11 @@
+samhain (3.1.0-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Move all non-volatile package state in /var/lib/package, according
+to the FHS (Closes: #771461)
+
+ -- Andrea Claudi a.cla...@univpm.it  Tue, 02 Dec 2014 00:36:33 +0100
+
 samhain (3.1.0-6) unstable; urgency=medium
 
   * debian/rules: Add an option to disable the ASM code when building
diff -u samhain-3.1.0/debian/dirs samhain-3.1.0/debian/dirs
--- samhain-3.1.0/debian/dirs
+++ samhain-3.1.0/debian/dirs
@@ -5,3 +5,3 @@
 var/log/samhain
-var/state/samhain
+var/lib/samhain
 etc/logrotate.d
diff -u samhain-3.1.0/debian/postrm samhain-3.1.0/debian/postrm
--- samhain-3.1.0/debian/postrm
+++ samhain-3.1.0/debian/postrm
@@ -7,7 +7,7 @@
 
 case $1 in
 	purge)
-		for dir in /var/log/samhain/supervise /var/log/samhain /var/state/samhain /var/run/samhain
+		for dir in /var/log/samhain/supervise /var/log/samhain /var/lib/samhain /var/run/samhain
 		do
 			[ -d $dir ]   {
 			 	find $dir -type f -exec rm -f {} \;
diff -u samhain-3.1.0/debian/rules samhain-3.1.0/debian/rules
--- samhain-3.1.0/debian/rules
+++ samhain-3.1.0/debian/rules
@@ -51,7 +51,7 @@
 endif
 	./configure --prefix=/usr --mandir=\$${prefix}/share/man \
 		--with-config-file=/etc/samhain/samhainrc \
-		--with-state-dir=/var/state/samhain  \
+		--with-state-dir=/var/lib/samhain  \
 		--with-prelude \
 		$(DNMALLOC) \
 		$(DISABLE_ASM) \
@@ -69,7 +69,7 @@
 #	dh_autoreconf
 	./configure --prefix=/usr --mandir=\$${prefix}/share/man \
 		--with-config-file=/etc/yule/yulerc \
-		--with-state-dir=/var/state/yule  \
+		--with-state-dir=/var/lib/yule  \
 		--with-prelude \
 		$(DNMALLOC) \
 		--enable-network=server  \
@@ -85,7 +85,7 @@
 #	dh_autoreconf
 	./configure --prefix=/usr --mandir=\$${prefix}/share/man \
 		--with-config-file=/etc/samhain/samhainrc \
-		--with-state-dir=/var/state/samhain  \
+		--with-state-dir=/var/lib/samhain  \
 		--with-prelude \
 		$(DNMALLOC) \
 		--enable-network=client \
@@ -112,7 +112,7 @@
 	dh_installdirs
 	# Fix the permissions
 	chmod o-rX `pwd`/debian/samhain/var/log/samhain \
-		`pwd`/debian/samhain/var/state/samhain \
+		`pwd`/debian/samhain/var/lib/samhain \
 		`pwd`/debian/samhain/etc/samhain
 
 	$(MAKE) install install-boot DESTDIR=`pwd`/debian/samhain
diff -u samhain-3.1.0/debian/samhain.init samhain-3.1.0/debian/samhain.init
--- samhain-3.1.0/debian/samhain.init
+++ samhain-3.1.0/debian/samhain.init
@@ -49,10 +49,10 @@
 {
 # Initialize the database only if does not exist yet, abort if
 # it cannot be created
- [  -f /var/state/samhain/samhain_file ]  return
+ [  -f /var/lib/samhain/samhain_file ]  return
  log_progress_msg Creating integrity database (this can take some minutes).
  samhain -t init /var/log/samhain/samhain-init.log 21
- if [  ! -f /var/state/samhain/samhain_file ] ; then
+ if [  ! -f /var/lib/samhain/samhain_file ] ; then
 log_failure_msg Database could not be created. Review /var/log/samhain/samhain-init.log
 log_end_msg 1
 exit 1
only in patch2:
unchanged:
--- samhain-3.1.0.orig/rules.deb.in
+++ samhain-3.1.0/rules.deb.in
@@ -51,7 +51,7 @@
 	# Fix the permissions
 	#chmod o-rX `pwd`/debian/tmp/var/log/samhain \
 	#	`pwd`/debian/tmp/var/run/samhain \
-	#	`pwd`/debian/tmp/var/state/samhain \
+	#	`pwd`/debian/tmp/var/lib/samhain \
 	#	`pwd`/debian/tmp/etc/samhain
 
 	# $(MAKE) install install-boot DESTDIR=`pwd`/debian/tmp

Bug#735822: Patch: fixed sphinx documentation build path

[Andrea Colangelo]

On Sat, May 31, 2014 at 12:17:03PM +0200, Pietro Battiston wrote:
 Il giorno sab, 31/05/2014 alle 12.07 +0200, Domenico Iezzi ha scritto:
  Hi,
  FTBFS can be fixed by changing doc/build/sphinx/html to 
  build/sphinx/html in
  debian/python-sqlkit-doc.docs
  
  Regards,
  Domenico Iezzi
 
 Hi Domenico, thanks a lot for your patch. Unfortunately I am very busy
 at the moment, but I should be able to take care of this package at the
 latest in July. By the way, I wouldn't object to an NMU.

Great, uploading to archive right now (no DELAYED, given the RC-bug and
consent from maintainer). Thank you for your contribution to Debian!

Best,
Andrea.


-- 
Andrea Colangelo  |   http://andreacolangelo.com
Debian Developer war...@debian.org  |   Ubuntu Developer war...@ubuntu.com


signature.asc
Description: Digital signature

Bug#743122: Patch: add a build-dependency on dh-autoreconf

[Andrea Claudi]

Hello,
The FTBFS can be fixed adding a build-dependency on dh-autoreconf.

diff -Nru starplot-0.95.5/debian/changelog starplot-0.95.5/debian/changelog
--- starplot-0.95.5/debian/changelog2014-03-03 23:24:20.0 +0100
+++ starplot-0.95.5/debian/changelog2014-05-21 00:22:13.0 +0200
@@ -1,3 +1,11 @@
+starplot (0.95.5-8.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/control: Add Build-Depends on dh-autoreconf
+This fixes the FTBFS  for the amd64 architecture (Closed: #743122)
+
+ -- Andrea Claudi a.cla...@univpm.it  Wed, 21 May 2014 00:19:13 +0200
+
 starplot (0.95.5-8) unstable; urgency=medium

   * Update Maintainer's address 
diff -Nru starplot-0.95.5/debian/control starplot-0.95.5/debian/control
--- starplot-0.95.5/debian/control  2014-03-03 23:25:13.0 +0100
+++ starplot-0.95.5/debian/control  2014-05-21 00:25:05.0 +0200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Francisco Manuel Garcia Claramonte franci...@debian.org
 Uploaders: Javier Fernández-Sanguino Peña j...@debian.org, Kevin B. McCarty 
kmcca...@debian.org
-Build-Depends: debhelper ( 9.0.0), libgtk2.0-dev, autotools-dev
+Build-Depends: debhelper ( 9.0.0), libgtk2.0-dev, dh-autoreconf
 Standards-Version: 3.9.3
 Homepage: http://starplot.org

Regards,
Andrea Claudi


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

Bug#743122: #743122 patch

[Andrea Claudi]

tags 743122 + patch
thanks

-- 
Andrea Claudi, PhD - Post-doc Research Fellow
Computer Engineering Department
Faculty of Engineering
Università Politecnica delle Marche
via Brecce Bianche, 60131 Ancona, Italy

Web: http://airtlab.dii.univpm.it
Phone: (+39) 071-2204372 | (+39) 071-2204473
Fax: (+39) 071-2204474


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

Bug#743122: Patch: add a build-dependency on dh-autoreconf

[Andrea Colangelo]

On Fri, May 23, 2014 at 09:58:45AM +0200, Andrea Claudi wrote:
 Hello,
 The FTBFS can be fixed adding a build-dependency on dh-autoreconf.

Andrea, thank you for taking the time to report this patch and helping
to make Debian better.

Your patch looks good, I just slightly reowrded the changelog. BTW: it's
Closes, not Closed. :)

Uploading to archive right now. Enjoy!


-- 
Andrea Colangelo  |   http://andreacolangelo.com
Debian Developer war...@debian.org  |   Ubuntu Developer war...@ubuntu.com


signature.asc
Description: Digital signature

Bug#748742: liferea: Crashes some seconds after launch even without user interaction (segfault in libpthread)

[Andrea Lusuardi]

On Tue, 20 May 2014 18:22:20 -0500
David Smith sidic...@gmail.com wrote:

 Please install the liferea-dbg package and then start liferea as
 follows: gdb liferea
 ...
 ...
 [crash]
 bt full

i had to run the run command to gdb or it would stay blocked
indefinitely, hope that does not mess up the backtrace. You can find
the trace attached, tia.

-- 
Andrea Lusuardi  -  uovobw GPG: 313C1073


liferea_crash
Description: Binary data


signature.asc
Description: PGP signature

Bug#748742: liferea: Crashes some seconds after launch even without user interaction (segfault in libpthread)

[Andrea Lusuardi]

Package: liferea
Version: 1.10.8-1
Severity: grave
Justification: renders package unusable

Hi,
the package liferea crashes predictably after 3 to 10 seconds from launch, in 
the dmesg
i can see the problem as follows:

[46072.157858] pool[8262]: segfault at 10 ip 7f80fc8fa224 sp 
7f80ecb8e540 error 4 in libpthread-2.18.so[7f80fc8f+18000]

i tried removing the config ($HOME/.liferea*) but the problem persists as soon 
as i add the first feed.
This makes the package mostly unusable. If there are other information you need 
or ways i can assist in triaging
the bug please let me know,
thanks


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

Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ISO-8859-15) (ignored: 
LC_ALL set to it_IT@euro)
Shell: /bin/sh linked to /bin/dash

Versions of packages liferea depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.20.0-2
ii  gir1.2-gtk-3.0   3.12.2-1
ii  gir1.2-peas-1.0  1.10.0-2
ii  libatk1.0-0  2.12.0-1
ii  libc62.18-7
ii  libcairo21.12.16-2
ii  libgdk-pixbuf2.0-0   2.30.7-1
ii  libgirepository-1.0-11.40.0-2
ii  libglib2.0-0 2.40.0-3
ii  libgtk-3-0   3.12.2-1
ii  libindicate5 0.6.92-2
ii  libjson-glib-1.0-0   1.0.0-1
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.36.3-1
ii  libpeas-1.0-01.10.0-2
ii  libsoup2.4-1 2.46.0-2
ii  libsqlite3-0 3.8.4.3-3
ii  libwebkitgtk-3.0-0   2.4.2-1
ii  libxml2  2.9.1+dfsg1-3
ii  libxslt1.1   1.1.28-2
ii  liferea-data 1.10.8-1
ii  python-gi3.12.1-1
pn  python:any   none

Versions of packages liferea recommends:
ii  dbus 1.8.2-1
ii  dbus-x11 1.8.2-1
pn  gir1.2-gnomekeyring-1.0  none
pn  gnome-icon-theme none
pn  gnome-keyringnone
pn  steadyflow | kgetnone

Versions of packages liferea suggests:
pn  network-manager  none

-- no debconf information


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

Bug#718134: freetalk: diff for NMU version 3.2-11.1

[Andrea Colangelo]

On Fri, Feb 7, 2014 at 8:52 PM, Andreas Moog andreas.m...@warperbbs.de wrote:
 On 10.10.2013 13:27, Andrea Colangelo wrote:
 I've prepared an NMU for freetalk (versioned as 3.2-11.1). Please find the
 attached debdiff.

 ping? ;)

Sorry, forgot to upload this one after I got my DD superpowers.
dputting right now to DELAYED/2.


-- 
Andrea Colangelo  |   http://andreacolangelo.com
Debian Developer war...@debian.org  |   Ubuntu Developer war...@ubuntu.com


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

Bug#707882: uploaded to DELAYED/2

[Andrea Colangelo]

Uploaded to DELAYED/2, thanks.

-- 
Andrea Colangelo  |   http://andreacolangelo.com
Debian Developer war...@debian.org  |   Ubuntu Developer war...@ubuntu.com


signature.asc
Description: Digital signature

Bug#725546: numptyphysics: NMU uploaded to DELAYED/2

[Andrea Colangelo]

Uploaded to DELAYED/2, thank you for the NMU.

Regards,

-- 
Andrea Colangelo  |   http://andreacolangelo.com
Debian Developer war...@debian.org  |   Ubuntu Developer war...@ubuntu.com


signature.asc
Description: Digital signature

Bug#731458: alacarte: New items always placed in other category with no icon

[Andrea]

Package: alacarte
Version: 3.10.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,
I tried to add some new application on my menù, but every time the new one is
placed in other and always without icon, even though I had set it.



-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages alacarte depends on:
ii  gir1.2-gdkpixbuf-2.0  2.28.2-1
ii  gir1.2-glib-2.0   1.36.0-2+b1
ii  gir1.2-gmenu-3.0  3.8.0-2
ii  gir1.2-gtk-3.03.8.4-1
ii  gnome-menus   3.8.0-2
ii  python-gi 3.8.2-1
pn  python:anynone

alacarte recommends no packages.

alacarte suggests no packages.

-- no debconf information


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

Bug#731458:

[Andrea Scarparo]

I tried to open alacarte from terminal:
$ alacarte

(alacarte:21887): Gtk-CRITICAL **: gtk_accel_label_set_accel_closure:
assertion `gtk_accel_group_from_accel_closure (accel_closure) != NULL'
failed

(alacarte:21887): Gtk-CRITICAL **: gtk_accel_label_set_accel_closure:
assertion `gtk_accel_group_from_accel_closure (accel_closure) != NULL'
failed

Bug#713475: [Pkg-ayatana-devel] Bug#713475: libindicator: diff for NMU version 0.5.0-1.1

[Andrea Colangelo]

On Fri, Oct 25, 2013 at 05:05:46PM -0400, Andrew Starr-Bochicchio wrote:
 Thanks for the patch. I'm about to sponsor it. In the future note that
 you shouldn't tag a bug as pending if you are looking for a sponsor.

You're right, sorry. I always forgot to edit the nmudiff template WRT the tags.
BTW, thanks for sponsoring!

Regards,
Andrea,

-- 
Andrea Colangelo |   http://andreacolangelo.com
Ubuntu Developer  www.ubuntu.com   |   Debian Maintainer  www.debian.org


signature.asc
Description: Digital signature

Bug#726661: Does not permit login as root from version 1:6.2p2-6

[Andrea Lusuardi]

Package: openssh-server
Version: 1:6.0p1-4
Severity: grave

Installed openssh-server on debian stable. As soon as i update the
package to latest version (it is reported for the other version as 
i cannot login if the package is not at that version) login becomes impossible 
with the error

Oct 17 20:11:34 nl-01 sshd[25206]: Accepted password for root from IP port 
44676 ssh2
Oct 17 20:11:34 nl-01 sshd[25206]: pam_loginuid(sshd:session): set_loginuid 
failed
Oct 17 20:11:34 nl-01 sshd[25206]: pam_unix(sshd:session): session opened for 
user root by (uid=0)
Oct 17 20:11:34 nl-01 sshd[25206]: error: PAM: pam_open_session(): Cannot 
make/remove an entry for the specified session
Oct 17 20:11:34 nl-01 sshd[25206]: Received disconnect from IP: 11: 
disconnected by user

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

Kernel: Linux 2.6.32-5-vserver-amd64 (SMP w/24 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages openssh-server depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.51
ii  dpkg   1.17.1
ii  libc6  2.17-93
ii  libcomerr2 1.42.8-1
ii  libgssapi-krb5-2   1.11.3+dfsg-3
ii  libkrb5-3  1.11.3+dfsg-3
ii  libpam-modules 1.1.3-7.1
ii  libpam-runtime 1.1.3-7.1
ii  libpam0g   1.1.3-7.1
ii  libselinux12.1.13-3
ii  libssl1.0.01.0.1e-3
ii  libwrap0   7.6.q-24
ii  lsb-base   4.1+Debian12
ii  openssh-client 1:6.0p1-4
ii  procps 1:3.3.8-2
ii  zlib1g 1:1.2.8.dfsg-1

Versions of packages openssh-server recommends:
ii  ncurses-term 5.9+20130608-1
ii  openssh-blacklist0.4.1+nmu1
ii  openssh-blacklist-extra  0.4.1+nmu1
ii  xauth1:1.0.7-1

Versions of packages openssh-server suggests:
pn  molly-guard   none
pn  monkeysphere  none
pn  rssh  none
pn  ssh-askpass   none
pn  ufw   none

-- debconf information:
  ssh/vulnerable_host_keys:
  ssh/encrypted_host_key_but_no_keygen:
* ssh/use_old_init_script: true
  ssh/disable_cr_auth: false


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

Bug#713475: libindicator: diff for NMU version 0.5.0-1.1

[Andrea Colangelo]

tags 713475 + patch
tags 713475 + pending
thanks

Dear maintainer(s),

I've prepared an NMU for libindicator (versioned as 0.5.0-1.1). Please, find the
attached debdiff, ready for sponsorship.

Regards,

-- 
Andrea Colangelo |   http://andreacolangelo.com
Ubuntu Developer  www.ubuntu.com   |   Debian Maintainer  www.debian.org
diff -Nru libindicator-0.5.0/debian/changelog libindicator-0.5.0/debian/changelog
--- libindicator-0.5.0/debian/changelog	2012-05-20 16:34:12.0 +0200
+++ libindicator-0.5.0/debian/changelog	2013-10-12 10:47:10.0 +0200
@@ -1,3 +1,11 @@
+libindicator (0.5.0-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/patches/gtk_icon_info_free-deprecated.patch: add to fix FTFBS.
+(Closes: #713475)
+
+ -- Andrea Colangelo war...@ubuntu.com  Sat, 12 Oct 2013 10:46:31 +0200
+
 libindicator (0.5.0-1) unstable; urgency=low
 
   * Import new upstream version from Ubuntu.
diff -Nru libindicator-0.5.0/debian/patches/gtk_icon_info_free-deprecated.patch libindicator-0.5.0/debian/patches/gtk_icon_info_free-deprecated.patch
--- libindicator-0.5.0/debian/patches/gtk_icon_info_free-deprecated.patch	1970-01-01 01:00:00.0 +0100
+++ libindicator-0.5.0/debian/patches/gtk_icon_info_free-deprecated.patch	2013-10-12 10:45:57.0 +0200
@@ -0,0 +1,16 @@
+Description: Fix FTBFS due to gtk_icon_info_free () deprecated since Gtk 3.8
+Author: Andrea Colangelo war...@ubuntu.com
+Bug-Debian: http://bugs.debian.org/713475
+Last-Update: 2013-10-12
+
+--- libindicator-0.5.0.orig/libindicator/indicator-image-helper.c
 libindicator-0.5.0/libindicator/indicator-image-helper.c
+@@ -69,7 +69,7 @@ refresh_image (GtkImage * image)
+ 	GdkPixbuf * pixbuf = gdk_pixbuf_new_from_file(icon_filename, error);
+ 
+ 	if (icon_info != NULL) {
+-		gtk_icon_info_free(icon_info);
++		g_object_unref(icon_info);
+ 	}
+ 
+ 	if (pixbuf == NULL) {
diff -Nru libindicator-0.5.0/debian/patches/series libindicator-0.5.0/debian/patches/series
--- libindicator-0.5.0/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ libindicator-0.5.0/debian/patches/series	2013-10-12 10:43:10.0 +0200
@@ -0,0 +1 @@
+gtk_icon_info_free-deprecated.patch


signature.asc
Description: Digital signature

Bug#707352: dee: diff for NMU version 1.0.10-3.1

[Andrea Colangelo]

tags 707352 + patch
tags 707352 + pending
thanks

Dear maintainer,

I've prepared an NMU for dee (versioned as 1.0.10-3.1). Please find the attached
debdiff, based on the fix suggested by pochu in his replies to this bug report.

Regards.

-- 
Andrea Colangelo |   http://andreacolangelo.com
Ubuntu Developer  www.ubuntu.com   |   Debian Maintainer  www.debian.org
diff -Nru dee-1.0.10/debian/changelog dee-1.0.10/debian/changelog
--- dee-1.0.10/debian/changelog	2012-06-02 19:01:13.0 +0200
+++ dee-1.0.10/debian/changelog	2013-10-11 11:36:54.0 +0200
@@ -1,3 +1,11 @@
+dee (1.0.10-3.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Add versioned B-D on valac to fix FTBFS with the new gobject-introspection.
+(Closes: #707352 )
+
+ -- Andrea Colangelo war...@ubuntu.com  Fri, 11 Oct 2013 11:35:08 +0200
+
 dee (1.0.10-3) unstable; urgency=low
 
   * debian/control:
diff -Nru dee-1.0.10/debian/control dee-1.0.10/debian/control
--- dee-1.0.10/debian/control	2012-06-02 18:17:00.0 +0200
+++ dee-1.0.10/debian/control	2013-10-11 11:35:06.0 +0200
@@ -14,7 +14,7 @@
libglib2.0-dev (= 2.26.0),
libicu-dev (= 4.8),
python (= 2.6.5),
-   valac
+   valac (= 0.20)
 Standards-Version: 3.9.3
 Section: libs
 Homepage: https://launchpad.net/dee


signature.asc
Description: Digital signature

Bug#718134: freetalk: diff for NMU version 3.2-11.1

[Andrea Colangelo]

tags 718134 + patch
tags 718134 + pending
thanks

Dear maintainer,

I've prepared an NMU for freetalk (versioned as 3.2-11.1). Please find the
attached debdiff.

Regards.

-- 
Andrea Colangelo |   http://andreacolangelo.com
Ubuntu Developer  www.ubuntu.com   |   Debian Maintainer  www.debian.org
diff -Nru freetalk-3.2/debian/changelog freetalk-3.2/debian/changelog
--- freetalk-3.2/debian/changelog	2012-06-16 14:21:56.0 +0200
+++ freetalk-3.2/debian/changelog	2013-10-10 13:18:37.0 +0200
@@ -1,3 +1,11 @@
+freetalk (3.2-11.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/patches/03_texinfo5.diff add to fix FTBFS.
+(Closes: 718134)
+
+ -- Andrea Colangelo war...@ubuntu.com  Thu, 10 Oct 2013 13:11:19 +0200
+
 freetalk (3.2-11) unstable; urgency=low
 
   * debian/copyright:
diff -Nru freetalk-3.2/debian/patches/03_texinfo5.diff freetalk-3.2/debian/patches/03_texinfo5.diff
--- freetalk-3.2/debian/patches/03_texinfo5.diff	1970-01-01 01:00:00.0 +0100
+++ freetalk-3.2/debian/patches/03_texinfo5.diff	2013-10-10 13:17:09.0 +0200
@@ -0,0 +1,42 @@
+Description: Fix FTFBS against textinfo5
+Author: Andrea Colangelo war...@ubuntu.com
+Bug-Debian: http://bugs.debian.org/718134
+Last-Update: 2013-10-10
+
+Index: freetalk-3.2/doc/freetalk.texi
+===
+--- freetalk-3.2.orig/doc/freetalk.texi	2013-10-10 13:15:47.818075240 +0200
 freetalk-3.2/doc/freetalk.texi	2013-10-10 13:16:33.602074187 +0200
+@@ -824,14 +824,16 @@
+ You are free to use complete Readline keys inside freetalk.
+ Frequently used Readline keys inside freetalk are,
+ 
++@section Cursor motion
+ @multitable @columnfractions 0.33 0.33 0.33
+-@item @subsection Cursor motion
+ @item character @tab C-b @tab C-f
+ @item word @tab M-b @tab M-f
+ @item line up/down @tab C-p  @tab C-n
+ @item line start/end @tab C-a @tab C-e
+-@item
+-@item @subsection Editing
++@end multitable
++
++@section Editing
++@multitable @columnfractions 0.33 0.33 0.33
+ @item delete char @tab C-d
+ @item delete char backwards @tab C-h
+ @item delete word @tab M-d
+@@ -843,8 +845,10 @@
+ @item paste @tab C-y
+ @item undo @tab C-_
+ @item repeat prefix @tab M-number
+-@item
+-@item @subsection Case change
++@end multitable
++
++@section Case change
++@multitable @columnfractions 0.33 0.33 0.33
+ @item uppercase word @tab M-u
+ @item lowercase word @tab M-l
+ @item capitalize word @tab M-c
diff -Nru freetalk-3.2/debian/patches/series freetalk-3.2/debian/patches/series
--- freetalk-3.2/debian/patches/series	2011-06-30 15:31:34.0 +0200
+++ freetalk-3.2/debian/patches/series	2013-10-10 13:15:36.0 +0200
@@ -1,2 +1,3 @@
 01_callbacks_const_fix.diff
 02_link_options.diff
+03_texinfo5.diff


signature.asc
Description: Digital signature