Bug#1013480: hyperkitty: FTBFS: TypeError: __init__() got an unexpected keyword argument 'providing_args'

[Jonas Meurer]

Dear Charlemagne,

Charlemagne Lasse wrote:

Am Mo., 14. Nov. 2022 um 10:53 Uhr schrieb Pierre-Elliott Bécue
:

I really don't need reminders about the bugs on my packages.


This is not a reminder. I was just going through the mailman3 packages
to understand what is currently blocking the migration of packages.
And when I found out what is blocking it, I've only checked if this
problem is solved upstream or not. And if it was solved upstream, I
added information about the situation in the already existing bug.


Please refrain from putting pressure on people with the expectation that 
they'll do what you want at the tine you want.

This is the last time I reply to such sollicitations.


I don't understand why you are so unfriendly.


Some small feedback from my side: I don't find your emails unfriendly at 
all, quite the contrary I appreciate that you do the triaging and try to 
contribute :)


Cheers
Jonas

Bug#989183: CVE-2021-33038

[Jonas Meurer]

Hey Moritz,

Moritz Muehlenhoff wrote:

This was assigned CVE-2021-33038:
https://gitlab.com/mailman/hyperkitty/-/issues/380

Patch is here:
https://gitlab.com/mailman/hyperkitty/-/commit/9025324597d60b2dff740e49b70b15589d6804fa


Thanks a lot for reporting the security bug!

I'll upload hyperkitty 1.3.4-4 in a few minutes with the patch applied. Will
open an unblock request for Bullseye as soon as the package hit the archive.

Do you want to take care of preparing an upload to buster-security or shall
I prepare that one as well?


Please do! Version number should be 1.2.2-1+deb10u1


Done now. The sources for 1.2.2-1+deb10u1 can be found hier:

https://salsa.debian.org/mailman-team/hyperkitty/-/tree/debian/buster-security

Will you handle the upload or shall I upload to buster-security as well?


Thanks! Update looks fine, please upload to security-security.

I'll release the DSA later the evening or tomorrow.


Great, I just uploaded hyperkitty 1.2.2-1+deb10u1 targeting 
buster-security to security-master. Hope that I didn't miss anything.


Cheers
 jonas




OpenPGP_signature
Description: OpenPGP digital signature

Bug#989183: CVE-2021-33038

[Jonas Meurer]

Hey Moritz,

Moritz Muehlenhoff wrote:

On Fri, May 28, 2021 at 11:06:31AM +0200, Jonas Meurer wrote:

Moritz Muehlenhoff wrote:

This was assigned CVE-2021-33038:
https://gitlab.com/mailman/hyperkitty/-/issues/380

Patch is here:
https://gitlab.com/mailman/hyperkitty/-/commit/9025324597d60b2dff740e49b70b15589d6804fa


Thanks a lot for reporting the security bug!

I'll upload hyperkitty 1.3.4-4 in a few minutes with the patch applied. Will
open an unblock request for Bullseye as soon as the package hit the archive.

Do you want to take care of preparing an upload to buster-security or shall
I prepare that one as well?


Please do! Version number should be 1.2.2-1+deb10u1


Done now. The sources for 1.2.2-1+deb10u1 can be found hier:

https://salsa.debian.org/mailman-team/hyperkitty/-/tree/debian/buster-security

Will you handle the upload or shall I upload to buster-security as well?

Kind regards
 jonas




OpenPGP_signature
Description: OpenPGP digital signature

Bug#989183: CVE-2021-33038

[Jonas Meurer]

Hey Moritz,

Moritz Muehlenhoff wrote:

This was assigned CVE-2021-33038:
https://gitlab.com/mailman/hyperkitty/-/issues/380

Patch is here:
https://gitlab.com/mailman/hyperkitty/-/commit/9025324597d60b2dff740e49b70b15589d6804fa


Thanks a lot for reporting the security bug!

I'll upload hyperkitty 1.3.4-4 in a few minutes with the patch applied. 
Will open an unblock request for Bullseye as soon as the package hit the 
archive.


Do you want to take care of preparing an upload to buster-security or 
shall I prepare that one as well?


Kind regards
 jonas



OpenPGP_signature
Description: OpenPGP digital signature

Bug#987654: [Pkg-mailman-hackers] Bug#987654: Adjusting severity

[Jonas Meurer]

Hey Kunal,

Kunal Mehta wrote:

severity 987654 serious
thanks

Upping priority to serious as this is technically a violation of policy 


that all software in main should be self-contained to main, and I 
believe there is a general acceptance in Debian that such privacy 
breaches are not acceptable (see also #726998).


I can also confirm that I finished testing the upstream patch and it 
worked as expected after running "sudo mailman-web collectstatic --clear 
&& sudo mailman-web compress".


thanks a lot for your bugreport and the testing! I just prepared and 
uploaded hyperkitty 1.3.4-3 which applies the upstream fix.


It should hit unstable within the next hours and I hope to get into 
Bullseye soon.


> I've already prepared a fixed package for our Mailman3 install at
> Wikimedia.

I'm happy to learn that the Debian mailman3 packages are of usage for 
Wikimedia :)



Kind regards,
 jonas




OpenPGP_signature
Description: OpenPGP digital signature

Bug#971093: closed by Debian FTP Masters (reply to Jonas Meurer ) (Bug#971093: fixed in lazr.config 2.2.2-1)

[Jonas Meurer]

Hey Colin,

Am 26.01.21 um 11:12 schrieb Colin Watson:

On Mon, Jan 25, 2021 at 10:59:28PM +, Colin Watson wrote:

On Sat, Jan 02, 2021 at 12:24:05AM +, Debian Bug Tracking System wrote:

* Disable test `test_not_stackable` which fails for python3.9
  (Closes: #970148)


Thanks for sorting out the immediate issue, but this should really have
been reported upstream for a proper fix.  I've proposed a better fix
just now:

   
https://code.launchpad.net/~cjwatson/lazr.config/zope.interface-5.0.0/+merge/396876


Fixed upstream now in lazr.config 2.2.3, and I've uploaded 2.2.3-1 to
Debian.


Thanks a lot for taking care Colin, that's much appreciated!

Indeed I had reporting it upstream on my todo list, but I was too busy 
with other stuff in the meantime.


Cheers
 jonas



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977061: djangorestframework FTBFS with pytest 6

[Jonas Meurer]

Control: tag -1 moreinfo
Control: severity -1 important

Hey Christian,

On Thu, 10 Dec 2020 19:40:08 +0100 Christian Kastner  wrote:

djangorestframework FTBFS with pytest 6 in experimental.


I'm unable to reproduce the bug with pytest 6.0.2-2 from unstable. Also, 
according to ci.debian.net, the unit tests pass on all suites:


https://ci.debian.net/packages/d/djangorestframework/

Can you please provide further information on how to reproduce the bug? 
Or maybe it was a temporary error that's been resolved in the meantime?


Anyway, I'm lowering the bug severity for now in order to prevent 
djangorestframework from being removed from testing.


Kind regards
 jonas




The error log below has more details.

> === FAILURES 
===
> __ TestViewNamesAndDescriptions.test_markdown 
__
> tests/test_description.py:184: in test_markdown
> assert gte_21_match or lt_21_match
> E   AssertionError: assert (False or False)
> === warnings summary 
===
> /usr/lib/python3/dist-packages/_pytest/config/__init__.py:1148
>   /usr/lib/python3/dist-packages/_pytest/config/__init__.py:1148: 
PytestConfigWarning: Unknown config ini key: testspath
>   
> self._warn_or_fail_if_strict("Unknown config ini key: {}\n".format(key))
> 
> tests/test_serializer_nested.py::TestNestedSerializerWithMany::test_null_is_not_allowed_if_allow_null_is_not_set

> 
tests/test_serializer_nested.py::TestNestedSerializerWithMany::test_empty_not_allowed_if_allow_empty_is_set_to_false
>   /<>/rest_framework/exceptions.py:77: DeprecationWarning: 
NotImplemented should not be used in a boolean context
> return r and self.code == other.code
> 
> -- Docs: https://docs.pytest.org/en/stable/warnings.html

> === short test summary info 

> SKIPPED [1] tests/test_model_serializer.py:445: condition: not postgres_fields
> SKIPPED [1] tests/test_model_serializer.py:430: condition: not postgres_fields
> SKIPPED [1] tests/test_model_serializer.py:462: condition: not postgres_fields
> SKIPPED [1] tests/test_model_serializer.py:487: no models.JSONField
> SKIPPED [1] tests/test_serializer_nested.py:325: psycopg2 is not installed
> SKIPPED [1] tests/test_serializer_nested.py:343: psycopg2 is not installed
> FAILED tests/test_description.py::TestViewNamesAndDescriptions::test_markdown
>  1 failed, 1383 passed, 6 skipped, 3 warnings in 9.72s 
=
> E: pybuild pybuild:353: test: plugin custom failed with: exit code=1: python3.9 
/<>/runtests.py --nolint
> dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 
returned exit code 13
> make[1]: *** [debian/rules:31: override_dh_auto_test] Error 25
> make: *** [debian/rules:8: binary] Error 2
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2
> make[1]: Leaving directory '/<>'







OpenPGP_signature
Description: OpenPGP digital signature

Bug#945033: enigmail in Buster uninstallable due to thunderbird 1:68.2.2-1~deb10u1

[Jonas Meurer]

Package: enigmail
Version: 2:2.0.12+ds1-1~deb10u1
Severity: grave

Hello,

unfortunately, the latest security update of thunderbird (to
1:68.2.2-1~deb10u1) rendered enigmail uninstallable in Buster.

That's because thunderbird 1:68.2.2-1~deb10u1 has `enigmail (<< 2:2~)` listed
in its `Breaks` header.

Probably an upload of newer enigmail to stable or stable-security is needed to
resolve this issue.

Thanks a lot for maintaining enigmail in Debian!

Cheers
 jonas

Bug#930133: Postinst tries to invoke systemctl on non-systemd systems

[Jonas Meurer]

Package: mailman3-web
Version: 0+20180916-7
Severity: serious

Hello,

the mailman3-web postinst runs 'systemctl daemon-reload' during
upgrades, regardless of whether systemd is installed on the system or
not. This breaks installation of mailman3-web on systems with sysvinit.

Cheers
 jonas

Bug#924616: CVE-2018-15587

[Jonas Meurer]

Hi Salvatore, hi Evolution maintainers,

Salvatore Bonaccorso:
> Hi Jonas, hi Evolution maintainers,
> 
> What is the status here for buster?

Thanks for prodding :)

I'll take care of this via NMU during MiniDebCamp in Hamburg (this week)
if nobody objects.

Cheers
 jonas




signature.asc
Description: OpenPGP digital signature

Bug#924616: RFT and RFC: Updates for evolution{,-data-server}

[Jonas Meurer]

Hi Mike,

Mike Gabriel:
> On  Mi 24 Apr 2019 12:56:18 CEST, Jonas Meurer wrote:
> 
>> Jonas Meurer:
>>> With evolution-data-server, the situation is slightly more complicated.
>>> I'm still debugging issues with the patches[5] that are supposed to fix
>>> the "[GPG] Mails that are not encrypted look encrypted" issue.
>>>
>>> [5] https://gitlab.gnome.org/GNOME/evolution-data-server/commit/93306a29
>>> and https://gitlab.gnome.org/GNOME/evolution-data-server/commit/accb0e24
>>>
>>> My question: do you agree that these fixes are within the scope of
>>> CVE-2018-15587? If so, then I will continue working on the issue and
>>> upload both of evolution and evolution-data-server in a batch once I got
>>> the issues sorted out.
>>>
>>> Another option would be to upload evolution to jessie-security right now
>>> and decide that evolution-data-server is not affected by CVE-2018-15587,
>>> since it's only prone to "encrypted message spoofing", not to "signature
>>> spoofing". But in my eyes, that would be a sham.
>>
>> Looking more into the core issue[1] of "[GPG] Mails that are not
>> encrypted look encrypted", it became clear that a lot of applications
>> (GnuPG[2], Enigmail[3], Mutt[4]) are affected and it's not tracked as
>> security issue for any of them.
> 
> Is it required to coordinate an according update of those CVEs in
> data/CVE/list with the security team? Sounds like it.

Yep, you're correct. The Security Team is in the loop now and basically
agrees with my evaluation.

>> In fact it's tracked for evolution{,-data-server} in the debian security
>> tracker only because the issue is mentioned in the CVE-2018-15587
>> bugreport[5].
>>
>> Besides, I agree with the bug author that "this bug is certainly not in
>> the same category as a serious security vulnerability, such as a
>> plaintext leak or a signature spoof"[1].
>>
>> So I changed my mind and decided to ignore the "encryption spoofing" bug
>> and only care about "signature spoofing". This means that
>> evolution-data-server is unaffected and only evolution needs to be fixed.
> 
> Your choice of priority sounds good to me.

Thanks a lot for your comments! I just went ahead and uploaded a fixed
evolution to jessie-security. I also consequently removed
evolution-data-server from data/dla-needed.txt.

Cheers
 jonas




signature.asc
Description: OpenPGP digital signature

Bug#924616: RFT and RFC: Updates for evolution{,-data-server}

[Jonas Meurer]

Jonas Meurer:
> With evolution-data-server, the situation is slightly more complicated.
> I'm still debugging issues with the patches[5] that are supposed to fix
> the "[GPG] Mails that are not encrypted look encrypted" issue.
> 
> [5] https://gitlab.gnome.org/GNOME/evolution-data-server/commit/93306a29
> and https://gitlab.gnome.org/GNOME/evolution-data-server/commit/accb0e24
> 
> My question: do you agree that these fixes are within the scope of
> CVE-2018-15587? If so, then I will continue working on the issue and
> upload both of evolution and evolution-data-server in a batch once I got
> the issues sorted out.
> 
> Another option would be to upload evolution to jessie-security right now
> and decide that evolution-data-server is not affected by CVE-2018-15587,
> since it's only prone to "encrypted message spoofing", not to "signature
> spoofing". But in my eyes, that would be a sham.

Looking more into the core issue[1] of "[GPG] Mails that are not
encrypted look encrypted", it became clear that a lot of applications
(GnuPG[2], Enigmail[3], Mutt[4]) are affected and it's not tracked as
security issue for any of them.

In fact it's tracked for evolution{,-data-server} in the debian security
tracker only because the issue is mentioned in the CVE-2018-15587
bugreport[5].

Besides, I agree with the bug author that "this bug is certainly not in
the same category as a serious security vulnerability, such as a
plaintext leak or a signature spoof"[1].

So I changed my mind and decided to ignore the "encryption spoofing" bug
and only care about "signature spoofing". This means that
evolution-data-server is unaffected and only evolution needs to be fixed.

Cheers
 jonas

[1] https://neopg.io/blog/encryption-spoof/
[2] https://dev.gnupg.org/T4000
[3] https://sourceforge.net/p/enigmail/bugs/854/
[4] https://gitlab.com/muttmua/mutt/issues/39
[5] https://gitlab.gnome.org/GNOME/evolution/issues/120



signature.asc
Description: OpenPGP digital signature

Bug#924616: RFT and RFC: Updates for evolution{,-data-server}

[Jonas Meurer]

Hello,

The last days, I spent quite some hours on backporting and debugging
patches for CVE-2018-15587 (Signature Spoofing in PGP encrypted email)
to evolution and evolution-data-server packages for Jessie LTS. 

One problem is that the scope of CVE-2018-15587 is a bit blurry. While
the CVE description speaks specifically about the possibility to craft
emails in a way that they spuriously appear to be *signed* - a
vulnerability that got revealed in the aftermath of SigSpoof - the
corresponding bugreports link to several related OpenPGP weaknesses in
evolution{-data-server}.

E.g., our security tracker additionally links[1] to the upstream bugs
"[GPG] Mails that are not encrypted look encrypted"[2] and "Sometimes
fails to properly decrypt large GPG encrypted messages"[3].

[1] https://security-tracker.debian.org/tracker/CVE-2018-15587
[2] https://gitlab.gnome.org/GNOME/evolution-data-server/issues/3
[3] https://gitlab.gnome.org/GNOME/evolution-data-server/issues/75

I now have a working version of evolution - at least I tested it
thoroughly. It has both the signature spoofing and encryption spoofing
bugs fixed. You can find amd64 builds of the packages in my personal
repository[4], further testing much appreciated.

[4] https://people.debian.org/~mejo/debian/jessie-security/

With evolution-data-server, the situation is slightly more complicated.
I'm still debugging issues with the patches[5] that are supposed to fix
the "[GPG] Mails that are not encrypted look encrypted" issue.

[5] https://gitlab.gnome.org/GNOME/evolution-data-server/commit/93306a29
and https://gitlab.gnome.org/GNOME/evolution-data-server/commit/accb0e24

My question: do you agree that these fixes are within the scope of
CVE-2018-15587? If so, then I will continue working on the issue and
upload both of evolution and evolution-data-server in a batch once I got
the issues sorted out.

Another option would be to upload evolution to jessie-security right now
and decide that evolution-data-server is not affected by CVE-2018-15587,
since it's only prone to "encrypted message spoofing", not to "signature
spoofing". But in my eyes, that would be a sham.

Another problem is that I'm already five hours over my allocated LTS
time for April. I'm fine with doing some extra volunteer work on the
issue though.

Cheers
 jonas




signature.asc
Description: OpenPGP digital signature

Bug#924616: CVE-2018-15587

[Jonas Meurer]

Hello,

Tobias Frost  wrote:
> On Thu, 14 Mar 2019 23:18:39 +0100 Moritz Muehlenhoff 
> wrote:
> > Source: evolution
> > Severity: grave
> > Tags: security
> >
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15587:
> >
> > https://bugzilla.gnome.org/show_bug.cgi?id=796424
> >
>
https://gitlab.gnome.org/GNOME/evolution/commit/9c55a311325f5905d8b8403b96607e46cf343f21
>
>
https://gitlab.gnome.org/GNOME/evolution/commit/f66cd3e1db301d264563b4222a3574e2e58e2b85
>
> I was triaging into it, but unfortunatly cannot solve it...
>
> Summary:
> The second patch seems to be already applied, but the first one seems
> not to be... However, I'm not sure if it does the trick as the speciem
> attached to the forwarded bug shows still up as "verified"...
while working on this issue for Jessie LTS, I prepared a simple NMU
patch to fix the issue in evolution 3.30.5-1 from testing/buster.

Tobias is right that only 9c55a311325f5905d8b8403b96607e46cf343f21 is
missing for evolution, the other relevant commits are already in the
testing/buster version of evolution (3.30.5-1).

It turned out that the upstream commit applies cleanly to 3.30.5-1. I
did some smoke testing and the result was as expected: the security
header with information about encryption/signature of the message moved
above the headers section of the mail.

I opened a merge request[1] on salsa with a patch. I had to merge tag
debian/3.30.5-1 into the debian/buster branch first as it was out of date.
Anybody from the Debian Gnome Team ho wants to do the upload? Otherwise
I could as well do the NMU.

Cheers
 jonas

PS: All related commits for evolution-data-server[2] are already in the
Buster version of evolution-data-server.

[1] https://salsa.debian.org/gnome-team/evolution/merge_requests/1
[2]
https://gitlab.gnome.org/GNOME/evolution-data-server/commit/93306a296c64b48d12c356804f131048643eaa0a


https://gitlab.gnome.org/GNOME/evolution-data-server/commit/accb0e2415681565e4dac00cf1c4303c313ad29e


https://gitlab.gnome.org/GNOME/evolution-data-server/commit/5cd59aee67450e8750eb3cb2d357d0947f199f61



signature.asc
Description: OpenPGP digital signature

Bug#924591: this requires linking in libsparse, which is from Android sources

[Jonas Meurer]

Hans-Christoph Steiner:
> Theodore Ts'o:
>> So your choice --- we can either reassign this bug back to fastboot or
>> android-sdk-platforms-tools, or I can downgrade the severity of this
>> bug for e2fsprogs down to wishlist[1].  Let me know how you want to
>> handle this.
>>
>> [1] This is because I view this both as a "feature request" and "bugs
>> that are very difficult to fix due to major design considerations"
>> (per https://www.debian.org/Bugs/Developer#severities), not to mention
>> that it's going to affect a miniscule fraction of the e2fsprogs
>> package's users.
> 
> Makes sense to me.  I'm fine with this being done post-Buster or as a
> custom mke2fs in android-platform-system-core.

So the bottom line here is that the ext4 formatting support in fastboot
remains broken in Buster, right? That would be very unfortunate and a
regression compared to Stretch.

Cheers
 jonas



signature.asc
Description: OpenPGP digital signature

Bug#924591: fastboot format:ext4 misses /usr/lib/android-sdk/platform-tools/mke2fs

[Jonas Meurer]

Control: reopen -1

Hello,

Hans-Christoph Steiner:
> circular Depends:/Recommends: are easy, circular Build-Depends: are
> what's hard.  Plus using the /usr/bin/ method, that will make fastboot
> require e2fsprogs and other packages, rather than just recommend.


Unfortunately, the bug is not really fixed. The symlinks exist now, but
apparently /usr/bin/mke2fs doesn't work for fastboot format:

$ fastboot format:ext4:0xcd3771e00 userdata
Warning: userdata size is0xcd3779e00, but 0xcd3771e00 was requested
for formatting.
Invalid erase-block-size 512: must be a power of 2 and at least 4096.
Invalid logical-block-size 512: must be a power of 2 and at least 4096.
mke2fs 1.44.5 (15-Dec-2018)
/tmp/TemporaryFile-YMROG8: Unimplemented ext2 library function while
setting up superblock
/usr/lib/android-sdk/platform-tools/mke2fs failed with status 1
mke2fs failed: 1
error: Cannot generate image for userdata

Cheers,
 jonas



signature.asc
Description: OpenPGP digital signature

Bug#924591: fastboot format:ext4 misses /usr/lib/android-sdk/platform-tools/mke2fs

[Jonas Meurer]

Package: fastboot
Version: 1:8.1.0+r23-4
Severity: serious

Hello,

after dist-upgrade to Buster, 'fastboot format:ext4' is broken. It tries
to execute '/usr/lib/android-sdk/platform-tools/mke2fs' which doesn't
exist and is not available in the Debian archive:

$ fastboot format:ext4:0xcd3771e00 userdata
Warning: userdata size is0xcd3779e00, but 0xcd3771e00 was requested for 
formatting.
Invalid erase-block-size 512: must be a power of 2 and at least 4096.
Invalid logical-block-size 512: must be a power of 2 and at least 4096.
/usr/lib/android-sdk/platform-tools/mke2fs failed with status 1
mke2fs failed: 1
error: Cannot generate image for userdata

$ ls /usr/lib/android-sdk/platform-tools/mke2fs
ls: cannot access '/usr/lib/android-sdk/platform-tools/mke2fs': No such file or 
directory


I chose severity serious as this bug is a severe regression that makes
'fastboot format' unusable. Therefore, the bug should be fixed before
the release of Buster.

Cheers
 jonas


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

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

Versions of packages fastboot depends on:
ii  android-libadb 1:8.1.0+r23-4
ii  android-libbase1:8.1.0+r23-4
ii  android-libcutils  1:8.1.0+r23-4
ii  android-libf2fs-utils  8.1.0+r23-2
ii  android-libsparse  1:8.1.0+r23-4
ii  android-libutils   1:8.1.0+r23-4
ii  android-libziparchive  1:8.1.0+r23-4
ii  libc6  2.28-8
ii  libgcc11:8.3.0-2
ii  libstdc++6 8.3.0-2

fastboot recommends no packages.

fastboot suggests no packages.

-- no debconf information

Bug#909000: marked as done (Enigmail 2.0 needed in Stretch after Thunderbird 60 upload)

[Jonas Meurer]

Hi dkg,

Am 03.11.18 um 18:06 schrieb Debian Bug Tracking System:
> Source: enigmail
> Source-Version: 2:2.0.8-5~deb9u1
> 
> We believe that the bug you reported is fixed in the latest version of
> enigmail, which is due to be installed in the Debian FTP archive.
>> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Mon, 29 Oct 2018 00:41:43 -0400
> Source: enigmail
> Binary: enigmail
> Architecture: source
> Version: 2:2.0.8-5~deb9u1
> Distribution: stretch
> Urgency: medium
> Maintainer: Debian Mozilla Extension Maintainers 
> 
> Changed-By: Daniel Kahn Gillmor 
> Description:
>  enigmail   - GPG support for Thunderbird and Debian Icedove
> Closes: 909000
> Changes:
>  enigmail (2:2.0.8-5~deb9u1) stretch; urgency=medium
>  .
>* Rebuild for stretch (Closes: #909000)

Thanks a ton for your hard work on getting this solved, dkg!

I really appreciate it, and a lot of other enigmail users on Debian
Stretch as well, I'm sure.

Cheers
 jonas



signature.asc
Description: OpenPGP digital signature

Bug#909000: Thunderbird 60 cannot STILL be at stretch normal repository

[Jonas Meurer]

Hello,

On Wed, 10 Oct 2018 19:19:53 +0200 Narcis Garcia 
wrote:
> Stable packages aren't ready for Thunderbird 60 presence.
> It's better to wait for better repository consistence before adding this
> update.

With keeping Thunderbird at version 52 in stretch you mean to keep the
packages with known security vulnerabilites? For obvious reasons, that's
not an option.

Cheers
 jonas



signature.asc
Description: OpenPGP digital signature

Bug#909000: Enigmail 2.0 needed in Stretch after Thunderbird 60 upload

[Jonas Meurer]

Hi dkg,

Am 02.10.2018 um 21:31 schrieb Daniel Kahn Gillmor:
> On Mon 2018-09-17 15:44:03 -0400, Daniel Kahn Gillmor wrote:
>>  * i subsequently discovered that the enigmail test suite was inadequate
>>for the Autocrypt Setup Message -- i'm currently working on fixing
>>that. (this is #908510)
> 
> I'm happy to report that the enigmail test suite fully passes in both
> debian unstable and debian testing (buster) today, without OpenPGP.js.

That's great news! Thanks a ton for working so hard on getting Enigmail
2.0 to run without OpenPGP.js. Will these changes be adapted upstream or
will upstream keep using OpenPGP?

> I'm now working on figuring out what updates are needed to GnuPG in
> debian stable (stretch) to be able to get the enigmail test suite to
> pass.  Hopefully they'll be minor, and comprehensible.
> 
> Apologies for the slow progress.

No need to apologize at all. Again, thanks a lot for working on this.
It's much appreciated :)

Cheers
 jonas



signature.asc
Description: OpenPGP digital signature

Bug#909587: Bug #909587 in hyperkitty marked as pending

[Jonas Meurer]

Control: tag -1 pending

Hello,

Bug #909587 in hyperkitty 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/mailman-team/hyperkitty/commit/724eb3b700a49a0b75fb0d114db72af8f21b661a


d/tests/control: Add python3-all to dependencies. (Closes: #909587)



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/909587

Bug#909000: Enigmail 2.0 needed in Stretch after Thunderbird 60 upload

[Jonas Meurer]

Hi dkg,

Am 17.09.2018 um 21:44 schrieb Daniel Kahn Gillmor:
> On Mon 2018-09-17 10:14:31 +0200, Jonas Meurer wrote:
>> yesterday, Thunderbird 1:60.0-2~deb9u1 got uploaded to Stretch (via
>> security). This thunderbird version breaks enigmail (<< 2:2~), which
>> leads to uninstallable/unusable Enigmail in Debian Stretch.
>>
>> May I suggest to backport Enigmail 2.0 to Debian Stretch as well?
> 
> Thanks for this report, Jonas!  it's definitely correct.
> 
> It's important to fix, but the dependency on more recent versions of
> GnuPG will be needed as well.  There are several problems that i'm
> trying to work through for enigmail in the limited time that i've got
> for this.

Thanks a ton for the detailed explanation. I see that there's no easy
solution to this. Unfortunately I don't have any cacapities available to
help you with solving the issue.

Kind regards
 jonas




signature.asc
Description: OpenPGP digital signature

Bug#909000: Enigmail 2.0 needed in Stretch after Thunderbird 60 upload

[Jonas Meurer]

Source: enigmail
Version: 2:1.9.9-1~deb9u1
Severity: grave

Dear maintainers,

yesterday, Thunderbird 1:60.0-2~deb9u1 got uploaded to Stretch (via
security). This thunderbird version breaks enigmail (<< 2:2~), which
leads to uninstallable/unusable Enigmail in Debian Stretch.

May I suggest to backport Enigmail 2.0 to Debian Stretch as well?

Cheers
 jonas

-- 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.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#886756: [debian-mysql] Bug#886756: Regression: Specified key was too long; max key length is 767 bytes

[Jonas Meurer]

Hey Otto,

Am 06.08.2018 um 23:09 schrieb Otto Kekäläinen:
> I plan to have this commit included in the next upload of MariaDB
> 10.1.x into Debian:
> https://salsa.debian.org/mariadb-team/mariadb-10.1/commit/89ae638d1d3b5a7157d086a9be2468cae764aae7

Yay, that's great news. Thanks a ton!

Cheers
 jonas

> ti 9. tammik. 2018 klo 17.45 Jonas Meurer (jo...@freesources.org) kirjoitti:
>>
>> Package: mariadb-server-10.1
>> Version: 1:10.1.29-6
>> Severity: serious
>> Tags: upstream
>>
>> Control: -1 forwarded https://jira.mariadb.org/browse/MDEV-14904
>>
>> Hello,
>>
>> I just discovered that MariaDB 10.1 packages in Sid, Buster and Stretch
>> break applications that expect a maximum allowed size of 255 characters
>> for VARCHAR fields. E.g.:
>>
>>> django.db.utils.OperationalError: (1071, 'Specified key was too long;
>>> max key length is 767 bytes')
>>
>> This is due to the fact that MariaDB in Debian has `utf8mb4` set as
>> default character since version 10.0.20-2 which raises the required
>> amount of memory per character.
>>
>> To still allow fields with > 191 < 255 characters, `innodb_large_prefix`
>> has to be enabled, which in turn requires the following settings:
>>
>>> innodb_file_format  = Barracuda
>>> innodb_file_per_table   = On
>>> innodb_large_prefix = On
>>
>> Unfortunately even that is not enough. Additionally, the row format for
>> tables needs to be changed to `dynamic`.
>>
>> Starting with MariaDB 10.2, `innodb_default_row_format` was introduced,
>> which allows to set the default row format for the whole MariaDB server.
>> Unfortunately, this option is not available in MariaDB 10.1 yet. In
>> other words, there's no way to configure MariaDB 10.1 in Debian in a way
>> that it works with applications that expect things like VARCHAR(255) to
>> be possible.
>>
>> This is a severe regression. I discussed this topic with MariaDB
>> upstream developer Marko Mäkelä (dr-m) on IRC and he agreed that they
>> can backport `innodb_default_row_format` for the next upstream release
>> of MariaDB 10.1. I created an upstream bugreport to track this:
>>
>> https://jira.mariadb.org/browse/MDEV-14904
>>
>> I suggest that this fix should be backported to MariaDB 10.1 in Debian
>> Stable as well as it is a severe regression compared to MySQL and
>> earlier MariaDB versions (i.e. pre 10.0.20-2).
>>
>> PS: This problem doesn't exist with MariaDB >= 10.2 or MySQL 5.7 as
>> both switched to `Barracudea` as default `innodb_file_format` along
>> with `innodb_large_prefix` and `dynamic` as default row format.
>>
>> See the following bugreports and discussion threads for further details:
>>
>> * https://jira.mariadb.org/browse/MDEV-9646
>> * https://code.djangoproject.com/ticket/18392
>> * 
>> https://stackoverflow.com/questions/30761867/mysql-error-the-maximum-column-size-is-767-bytes




signature.asc
Description: OpenPGP digital signature

Bug#886756: [debian-mysql] Bug#886756: Regression: Specified key was too long; max key length is 767 bytes

[Jonas Meurer]

Am 07.08.2018 um 10:51 schrieb Jonas Meurer:
> Hey Otto,
> 
> Am 06.08.2018 um 23:09 schrieb Otto Kekäläinen:
>> I plan to have this commit included in the next upload of MariaDB
>> 10.1.x into Debian:
>> https://salsa.debian.org/mariadb-team/mariadb-10.1/commit/89ae638d1d3b5a7157d086a9be2468cae764aae7
> 
> Yay, that's great news. Thanks a ton!

One more question: do you intend to push this fix to
stretch-proposed-updates? I think this would be a good idea since the
regression is unfixed in Stretch so far.

Cheers,
 jonas

> 
> Cheers
>  jonas
> 
>> ti 9. tammik. 2018 klo 17.45 Jonas Meurer (jo...@freesources.org) kirjoitti:
>>>
>>> Package: mariadb-server-10.1
>>> Version: 1:10.1.29-6
>>> Severity: serious
>>> Tags: upstream
>>>
>>> Control: -1 forwarded https://jira.mariadb.org/browse/MDEV-14904
>>>
>>> Hello,
>>>
>>> I just discovered that MariaDB 10.1 packages in Sid, Buster and Stretch
>>> break applications that expect a maximum allowed size of 255 characters
>>> for VARCHAR fields. E.g.:
>>>
>>>> django.db.utils.OperationalError: (1071, 'Specified key was too long;
>>>> max key length is 767 bytes')
>>>
>>> This is due to the fact that MariaDB in Debian has `utf8mb4` set as
>>> default character since version 10.0.20-2 which raises the required
>>> amount of memory per character.
>>>
>>> To still allow fields with > 191 < 255 characters, `innodb_large_prefix`
>>> has to be enabled, which in turn requires the following settings:
>>>
>>>> innodb_file_format  = Barracuda
>>>> innodb_file_per_table   = On
>>>> innodb_large_prefix = On
>>>
>>> Unfortunately even that is not enough. Additionally, the row format for
>>> tables needs to be changed to `dynamic`.
>>>
>>> Starting with MariaDB 10.2, `innodb_default_row_format` was introduced,
>>> which allows to set the default row format for the whole MariaDB server.
>>> Unfortunately, this option is not available in MariaDB 10.1 yet. In
>>> other words, there's no way to configure MariaDB 10.1 in Debian in a way
>>> that it works with applications that expect things like VARCHAR(255) to
>>> be possible.
>>>
>>> This is a severe regression. I discussed this topic with MariaDB
>>> upstream developer Marko Mäkelä (dr-m) on IRC and he agreed that they
>>> can backport `innodb_default_row_format` for the next upstream release
>>> of MariaDB 10.1. I created an upstream bugreport to track this:
>>>
>>> https://jira.mariadb.org/browse/MDEV-14904
>>>
>>> I suggest that this fix should be backported to MariaDB 10.1 in Debian
>>> Stable as well as it is a severe regression compared to MySQL and
>>> earlier MariaDB versions (i.e. pre 10.0.20-2).
>>>
>>> PS: This problem doesn't exist with MariaDB >= 10.2 or MySQL 5.7 as
>>> both switched to `Barracudea` as default `innodb_file_format` along
>>> with `innodb_large_prefix` and `dynamic` as default row format.
>>>
>>> See the following bugreports and discussion threads for further details:
>>>
>>> * https://jira.mariadb.org/browse/MDEV-9646
>>> * https://code.djangoproject.com/ticket/18392
>>> * 
>>> https://stackoverflow.com/questions/30761867/mysql-error-the-maximum-column-size-is-767-bytes
> 
> 




signature.asc
Description: OpenPGP digital signature

Bug#900967: Security vulnerability: Stack overflow in BGP mask expressions

[Jonas Meurer]

Source: bird
Version: 1.6.3-2
Severity: critical
Tags: security

According to the upstream website[1] and changelog[2], bird release 1.6.4
includes an "important security bugfix".

The changelog mentions "Filter: Fixed stack overflow in BGP mask
expressions". A quick scan through the git history revealed a few
commits that mention overflow and use after free fixes:

e8bc64e308586b6502090da2775af84cd760ed0d
Filter: make bgpmask literals real constructors
30c734fc73648e4c43af4f45e68ac2de3d7ddea1
Static: Fix bug in static route filter expressions

Probably the best is to ask upstream about security relevant commits and
consider to either backport them to stretch-backports. Another option
would be to upload 1.6.4 to stretch-security as 1.6.4-0+deb9u1.

Cheers
 jonas

[1] http://bird.network.cz/
[2] https://gitlab.labs.nic.cz/labs/bird/blob/v1.6.4/NEWS#L11

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

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

Bug#897536: mustache.js: FTBFS: make[1]: rake: Command not found

[Jonas Meurer]

Control: tag -1 +moreinfo

Hello,

I just tried to reproduce the FTBFS and failed. rake is defined as
build-dependency and correctly pulled in according to linked the build logs.

My best guess is that rake 12.3.1-2 had some bug that got fixed in 12.3.1-3.

Lucas, could you trigger another rebuild to see whether this got fixed
by the latest rake upload?

In any case, it doesn't look like a bug in mustache.js package to me.

Cheers,
 jonas

On Wed, 2 May 2018 22:51:57 +0200 Lucas Nussbaum  wrote:
> Source: mustache.js
> Version: 2.3.0-2
> Severity: serious
> Tags: buster sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20180502 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> >  debian/rules build
> > dh build --builddirectory=/<>/build
> >dh_update_autotools_config -O--builddirectory=/<>/build
> >dh_auto_configure -O--builddirectory=/<>/build
> >debian/rules override_dh_auto_build
> > make[1]: Entering directory '/<>'
> > rake jquery
> > make[1]: rake: Command not found
> > make[1]: *** [debian/rules:13: override_dh_auto_build] Error 127
> 
> The full build log is available from:
>http://aws-logs.debian.net/2018/05/02/mustache.js_2.3.0-2_unstable.log
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#886756: Regression: Specified key was too long; max key length is 767 bytes

[Jonas Meurer]

Package: mariadb-server-10.1
Version: 1:10.1.29-6
Severity: serious
Tags: upstream

Control: -1 forwarded https://jira.mariadb.org/browse/MDEV-14904

Hello,

I just discovered that MariaDB 10.1 packages in Sid, Buster and Stretch
break applications that expect a maximum allowed size of 255 characters
for VARCHAR fields. E.g.:

> django.db.utils.OperationalError: (1071, 'Specified key was too long;
> max key length is 767 bytes')

This is due to the fact that MariaDB in Debian has `utf8mb4` set as
default character since version 10.0.20-2 which raises the required
amount of memory per character.

To still allow fields with > 191 < 255 characters, `innodb_large_prefix`
has to be enabled, which in turn requires the following settings:

> innodb_file_format  = Barracuda
> innodb_file_per_table   = On
> innodb_large_prefix = On

Unfortunately even that is not enough. Additionally, the row format for
tables needs to be changed to `dynamic`.

Starting with MariaDB 10.2, `innodb_default_row_format` was introduced,
which allows to set the default row format for the whole MariaDB server.
Unfortunately, this option is not available in MariaDB 10.1 yet. In
other words, there's no way to configure MariaDB 10.1 in Debian in a way
that it works with applications that expect things like VARCHAR(255) to
be possible.

This is a severe regression. I discussed this topic with MariaDB
upstream developer Marko Mäkelä (dr-m) on IRC and he agreed that they
can backport `innodb_default_row_format` for the next upstream release
of MariaDB 10.1. I created an upstream bugreport to track this:

https://jira.mariadb.org/browse/MDEV-14904

I suggest that this fix should be backported to MariaDB 10.1 in Debian
Stable as well as it is a severe regression compared to MySQL and
earlier MariaDB versions (i.e. pre 10.0.20-2).

PS: This problem doesn't exist with MariaDB >= 10.2 or MySQL 5.7 as
both switched to `Barracudea` as default `innodb_file_format` along
with `innodb_large_prefix` and `dynamic` as default row format.

See the following bugreports and discussion threads for further details:

* https://jira.mariadb.org/browse/MDEV-9646
* https://code.djangoproject.com/ticket/18392
* 
https://stackoverflow.com/questions/30761867/mysql-error-the-maximum-column-size-is-767-bytes

Cheers
 jonas

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

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

Versions of packages mariadb-server-10.1 depends on:
ii  adduser   3.115
ii  debconf [debconf-2.0] 1.5.61
pn  galera-3  
ii  gawk  1:4.1.4+dfsg-1
ii  init-system-helpers   1.48
ii  iproute2  4.9.0-1+deb9u1
ii  libaio1   0.3.110-3
ii  libc6 2.24-11+deb9u1
ii  libdbi-perl   1.636-1+b1
ii  libpam0g  1.1.8-3.6
ii  libstdc++66.3.0-18
ii  libsystemd0   232-25+deb9u1
ii  lsb-base  9.20161125
ii  lsof  4.89+dfsg-0.1
ii  mariadb-client-10.1   10.1.26-0+deb9u1
ii  mariadb-common10.1.26-0+deb9u1
pn  mariadb-server-core-10.1  
ii  passwd1:4.4-4.1
ii  perl  5.24.1-3+deb9u2
ii  psmisc22.21-2.1+b2
ii  rsync 3.1.2-1+deb9u1
ii  socat 1.7.3.1-2+deb9u1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages mariadb-server-10.1 recommends:
pn  libhtml-template-perl  

Versions of packages mariadb-server-10.1 suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20160123cvs-4
pn  mariadb-test   
ii  netcat-openbsd 1.130-3
pn  tinyca 

Bug#886489: FTBFS: json_object.c:554:5: error: this statement may fall through [-Werror=implicit-fallthrough=]

[Jonas Meurer]

Control: forcemerge 853462 886489

Hey again,

apparently I made a stupid mistake. This bug had already been filed and
fixed some months ago:

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

Since the NMU that fixed the bug had not been pushed to the packaging
Git repo, I didn't spot it when trying to build json-c.

Closing this bug as a duplicate of #853462.

Cheers
 jonas

Am 06.01.2018 um 18:41 schrieb Jonas Meurer:
> Source: json-c
> Version: 0.12.1-1
> Severity: serious
> Justification: fails to build from source
> 
> Dear Maintainer,
> 
> json-c fails to build from source due to a potential implicit
> fall-through in function json_object_get_int64() from json_object.c:
> 
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 
> -Wall -Werror -Wno-error=deprecated-declarations 
> -Wno-error=unused-but-set-variable -Wextra -Wwrite-strings 
> -Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -c json_object.c  -fPIC -DPIC -o .libs/json_object.o
> json_object.c: In function 'json_object_get_int64':
> json_object.c:554:5: error: this statement may fall through 
> [-Werror=implicit-fallthrough=]
>   if (json_parse_int64(jso->o.c_string.str, ) == 0) return cint;
>  ^
> json_object.c:555:3: note: here
>default:
>^~~
> cc1: all warnings being treated as errors
> Makefile:578: recipe for target 'json_object.lo' failed
> make[3]: *** [json_object.lo] Error 1
> make[3]: Leaving directory '/<>'
> 
> 
> A quick look at the latest upstream release gave me the impression that
> his might have been fixed upstream in release 0.13:
> 
> https://github.com/json-c/json-c/blob/json-c-0.13-20171207/json_object.c#L697-L703
> 
> Cheers
>  jonas
> 
> -- System Information:
> Debian Release: 9.3
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.9.0-5-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 




signature.asc
Description: OpenPGP digital signature

Bug#886489: FTBFS: json_object.c:554:5: error: this statement may fall through [-Werror=implicit-fallthrough=]

[Jonas Meurer]

Source: json-c
Version: 0.12.1-1
Severity: serious
Justification: fails to build from source

Dear Maintainer,

json-c fails to build from source due to a potential implicit
fall-through in function json_object_get_int64() from json_object.c:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 
-Wall -Werror -Wno-error=deprecated-declarations 
-Wno-error=unused-but-set-variable -Wextra -Wwrite-strings 
-Wno-unused-parameter -std=gnu99 -D_GNU_SOURCE -D_REENTRANT -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -c json_object.c  -fPIC -DPIC -o .libs/json_object.o
json_object.c: In function 'json_object_get_int64':
json_object.c:554:5: error: this statement may fall through 
[-Werror=implicit-fallthrough=]
  if (json_parse_int64(jso->o.c_string.str, ) == 0) return cint;
 ^
json_object.c:555:3: note: here
   default:
   ^~~
cc1: all warnings being treated as errors
Makefile:578: recipe for target 'json_object.lo' failed
make[3]: *** [json_object.lo] Error 1
make[3]: Leaving directory '/<>'


A quick look at the latest upstream release gave me the impression that
his might have been fixed upstream in release 0.13:

https://github.com/json-c/json-c/blob/json-c-0.13-20171207/json_object.c#L697-L703

Cheers
 jonas

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

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

Bug#862249: Mounting an SFTP share with path may lead to data being deleted

[Jonas Meurer]

Package: nautilus
Version: 3.22.3-1
Severity: critical

Hello,

I just discovered a severe bug in the sftp protocol support of nautilus:

I tried to mount a remote folder via SFTP/SSH by using a syntax similar
to the following:

'sftp:///path/to/directory'. Instead of displaying
'/path/to/directory' on the remote host, nautilus kept giving warnings
that it doesn't know what to do with file 'directory' and moved to the
home directory on the remote host.

I tried it with different syntax (colon between host and path, 'user@'
in front of host, using 'ssh://' instead of 'sftp://') and I tried both
using the 'Andere Orte' (something like 'different locations' in
english) and the address bar (+). One time nautilus even
crashed (the Files window got closed).

After some time, I went back to the remote console SSH session and was
shocked to realize that the whole directory '/path/to/directory' was
removed on the remote host. Luckily I had backups.

I don't have time to do further debugging right now as I'm quite busy,
but I will do further debugging and try to find a clear reproducer in
the following days.

Kind regards
 jonas

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

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

Versions of packages nautilus depends on:
ii  desktop-file-utils 0.23-1
ii  gsettings-desktop-schemas  3.22.0-1
ii  gvfs   1.30.4-1
ii  libatk1.0-02.22.0-1
ii  libc6  2.24-10
ii  libcairo-gobject2  1.14.8-1
ii  libcairo2  1.14.8-1
ii  libexempi3 2.4.1-1
ii  libexif12  0.6.21-2+b2
ii  libgail-3-03.22.11-1
ii  libgdk-pixbuf2.0-0 2.36.5-2
ii  libglib2.0-0   2.50.3-2
ii  libglib2.0-data2.50.3-2
ii  libgnome-autoar-0-00.1.1-4+b1
ii  libgnome-desktop-3-12  3.22.2-1
ii  libgtk-3-0 3.22.11-1
ii  libnautilus-extension1a3.22.3-1
ii  libpango-1.0-0 1.40.5-1
ii  libselinux12.6-3+b1
ii  libtracker-sparql-1.0-01.10.5-1
ii  libx11-6   2:1.6.4-3
ii  nautilus-data  3.22.3-1
ii  shared-mime-info   1.8-1

Versions of packages nautilus recommends:
ii  gnome-sushi  3.21.91-2
ii  gvfs-backends1.30.4-1
ii  librsvg2-common  2.40.16-1+b1

Versions of packages nautilus suggests:
ii  brasero  3.12.1-4
ii  eog  3.20.5-1+b1
ii  evince [pdf-viewer]  3.22.1-3
ii  nautilus-sendto  3.8.4-2+b1
ii  okular [pdf-viewer]  4:16.08.2-1+b1
ii  totem3.22.1-1
ii  tracker  1.10.5-1
ii  vlc [mp3-decoder]2.2.5-1
ii  xdg-user-dirs0.15-2+b1

-- no debconf information

Bug#855094: [pkg-cryptsetup-devel] Bug#855094: initramfs-tools-core: Error on upgrade if cryptsetup is installed, but a current busybox isn't

[Jonas Meurer]

Hi intigeri, hi Guilhem,

Am 02.04.2017 um 10:10 schrieb Guilhem Moulin:
> On Sun, 02 Apr 2017 at 09:50:55 +0200, intrigeri wrote:
>> So at this point, I suggest this bug is reassigned to cryptsetup, and
>> option 3 is implemented there. But downgrading to non-RC and leaving
>> things as-is seems acceptable to me as well.
>>
>> Thoughts?
> 
> I think the proper fix would be to split cryptsetup's initramfs bits to
> a separate package (depending on busybox), cf. #783297.  It's
> unfortunate that we didn't implement that in time for Stretch, but
> considering the impact of this, I'd favor downgrading the severity and
> merging the bugs for the time being.

I fully agree with Guilhem here. We should split out
cryptsetup-initramfs as soon as Stretch is released and make it depend
on initramfs-tools and busybox.

Cheers,
 jonas





signature.asc
Description: OpenPGP digital signature

Bug#856536: [Packaging] Bug#856536: munin: regression from DSA-3794-2: spams munin logs with unitialized warnings: [PERL WARNING] Use of uninitialized value $size_x in string eq at /usr/lib/munin/cgi/

[Jonas Meurer]

Hi Holger,

Am 06.03.2017 um 12:54 schrieb Holger Levsen:
> could you please be so kind and push your wheezy and jessie uploads to
> munin.git too? It's lives in collab-maint on alioth, so you both should
> have write access already :)
> 
> Please just push it as signed tags (based on previous tags), not as
> branches, and please use the debian/* tag namespace.
> 
> Thanks!
> 
> (If you insist, even mildly, I'd create those tags, but you'd help me if you'd
> did. And: you already helped, so choose your pick :)

done.

Kind regards,
 jonas




signature.asc
Description: OpenPGP digital signature

Bug#856536: munin: regression from DSA-3794-2: spams munin logs with unitialized warnings: [PERL WARNING] Use of uninitialized value $size_x in string eq at /usr/lib/munin/cgi/munin-cgi-graph line 453

[Jonas Meurer]

Hi Salvatore, hi Holger,

On Thu, 02 Mar 2017 08:12:24 +0100 Salvatore Bonaccorso
 wrote:
> Source: munin
> Version: 2.0.25-1+deb8u1
> Severity: serious
> Tags: upstream
> 
> Only after releasing the DSA, I noticed that the update introduced
> another regression, causing to spam the munin logs for
> munin-cgi-graph.log with:
> 
> [...]
> 2017/03/02 06:53:56 [PERL WARNING] Use of uninitialized value $size_x in 
> string eq at /usr/lib/munin/cgi/munin-cgi-graph line 453.
> [...]
> 
> We possibly should release another regression update for
> jessie-security, and have the fix included as well for stretch.

Upstream just released munin 2.0.33 which fixes this regression. The
relevant patch is
https://github.com/munin-monitoring/munin/commit/6373554b1cc8bee886947cee598e86d1d9ea1e4a

Cheers,
 jonas



signature.asc
Description: OpenPGP digital signature

Bug#855705: [munin-monitoring/munin] munin-cgi-graph CGI::param security problem (#721)

[Jonas Meurer]

Hi Holger, hi Steve,

first thanks for Steve to patching munin 2.0 upstream:
https://github.com/munin-monitoring/munin/commit/42ce18f24d3eae8be33526a198bf21e4f2330230

Am 24.02.2017 um 21:30 schrieb Holger Levsen:
> On Fri, Feb 24, 2017 at 09:00:00PM +0100, Jonas Meurer wrote:
>> I already prepared 2.0.6-4+deb7u3 with Thomaž' patch for
>> wheezy-security.
> 
> thanks for this, though maybe the patch from 2.0.31 will be better?
> 
> (once 2.0.31 is released which Steve planned to do today…)

Indeed, Steve's upstream fix is way less intrusive than I expected. So I
just uploaded muin 2.0.6+deb7u3 with his patch applied to wheezy-security.

Holger, do you also take care of munin 2.0.29-1~bpo8+1 from
jessie-backports?

Cheers,
 jonas




signature.asc
Description: OpenPGP digital signature

Bug#855705: [munin-monitoring/munin] munin-cgi-graph CGI::param security problem (#721)

[Jonas Meurer]

Hi Holger, hi Steve,

On Fri, 24 Feb 2017 11:24:42 + Holger Levsen 
wrote:
> On Fri, Feb 24, 2017 at 01:37:55AM -0800, mejo- wrote:
> > I just gave 2.0.6 (from Debian/Wheezy) a try and indeed it's
> > vulnerable too.
> > The proposed patch by Tomaž Šolc from Debian Bugreport #855705
> > fixes this particular vulnerability.
> 
> thanks, mejo, for confirming this both!

I already prepared 2.0.6-4+deb7u3 with Thomaž' patch for
wheezy-security. As Steve announced an upstream fix for the 2.4 branch
for today, I waited some longer with the upload.

On Thu, 23 Feb 2017 19:24:20 +0100 Steve Schnepp
 wrote:
> The patch is indeed quite minimal, and address the issue. It therefore
> looks very ok to me.
>
> Note that I did not plan to take it as is, but use the 2.999.x code
> snippet instead which doesn't have the bug.
>
> I'll plan to do a secfix upstream release tomorrow so you'll have the
> choice of which patch you take ;-)

Steve, do you still plan to do the upstream fix anytime soon? Also, as
you intend to backport the changes from munin 2.999, I gusss that your
fix will be much more intrusive, right?

I'm inclined to upload munin 2.0.6-4+deb7u3 with Thomaž' patch to
wheezy-security tomorrow.

Holger, do you take care of the upload to unstable yourself? Probably
there a straightforward patch (without too much new code) would be good
as well, to simplify/speed up the transition to Stretch.

Cheers,
 jonas



signature.asc
Description: OpenPGP digital signature

Bug#847751: lurker: FHS violation: default configuration writes to files in /usr

[Jonas Meurer]

Hi Dominic,

Am 11.12.2016 um 13:10 schrieb Dominic Hargreaves:
> Package: lurker
> Version: 2.3-5+b1
> Severity: serious
> Justification: Policy 9.1.1
> 
> As of 2.3-1 the Debian package of lurker unfortunately started
> violating the FHS, because it moved its HTML generation output to
> /usr/share/lurker/www. According to the FHS[1] /usr must not be
> written to in normal operations.

Thanks a lot for the bugreport. You're indeed right, that current lurker
package violated the FHS.

> I discovered this whilst migrating a lurker installation to a new host.
> As far as I can tell, this is a genuine cache, and so I rsynced
> /usr/share/lurker/www/ to /var/cache/lurker/www/ and updated the
> config file reference, and everything still worked.
> 
> Fixing this in the package would also involve cleaning up any
> left-over cache in /usr/share/lurker/www. It's probably not safe
> to do this in an automated way, so a similar news item as the one
> used in 2.3-1 would be needed.

In your patch you suggest to move the htdocs dir to
/var/cache/lurker/www. The Problem with this directory is that it's not
guaranteed to be kept. /var/cache is allowed to be a volatile
filesystem. See Section 5.5.1 of the FHS:

"The application must be able to regenerate or restore the data. Unlike
/var/spool, the cached files can be deleted without data loss. The data
must remain valid between invocations of the application and rebooting
the system."

(http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#varcacheApplicationCacheData)

Thus I suggest to move the htdocs to /var/lib/lurker/www instead. I'll
modify your patch accordingly.

Cheers,
 jonas

> 
> [1] 
> 
> 
> -- System Information:
> Debian Release: 8.6
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages lurker depends on:
> ii  adduser  3.113+nmu3
> ii  apache2 [httpd-cgi]  2.4.10-10+deb8u7
> ii  apache2-mpm-prefork [httpd-cgi]  2.4.10-10+deb8u7
> ii  debconf [debconf-2.0]1.5.56
> ii  libc62.19-18+deb8u6
> ii  libgcc1  1:4.9.2-10
> ii  libmimelib1c2a   5:1.1.4-2
> ii  libstdc++6   4.9.2-10
> ii  lighttpd [httpd-cgi] 1.4.35-4+deb8u1
> ii  passwd   1:4.2-3+deb8u1
> ii  ucf  3.0030
> ii  xsltproc 1.1.28-2+deb8u2
> ii  zlib1g   1:1.2.8.dfsg-2+b1
> 
> lurker recommends no packages.
> 
> Versions of packages lurker suggests:
> ii  gnupg1.4.18-7+deb8u3
> ii  mailman  1:2.1.18-2+deb8u1
> 
> -- Configuration Files:
> /etc/lurker/apache.conf 4c1675809ae49b7e0fe08dcca45f00f0 [Errno 2] No such 
> file or directory: u'/etc/lurker/apache.conf 4c1675809ae49b7e0fe08dcca45f00f0'
> /etc/lurker/lurker.conf.local changed [not included]
> 
> -- debconf information excluded
> 




signature.asc
Description: OpenPGP digital signature

Bug#847196: monit segfault on stop and start

[Jonas Meurer]

Hi Marco, Victor, Chris,

Am 06.12.2016 um 14:04 schrieb Chris Lamb:
> [Adding Jonas as they made the relevant upload]
> 
> Hey,
> 
>> monit segfault on stop and start
> 
> This appears to be a regression in the latest LTS upload so pinging
> the relevant people.


thanks to bugreport, patch and ping. I tested the updated package,
verified that it fixes the segfault and uploaded to wheezy-security. The
update should be there within the next hour. Sorry for any inconvenience.

Cheers,
 jonas




signature.asc
Description: OpenPGP digital signature

Bug#846649: Frequent segfaults of coturn

[Jonas Meurer]

Am 02.12.2016 um 23:52 schrieb Jonas Meurer:

> I encounter frequent segfaults of coturn on a Debian Squeeze VM with
> recent kernel (4.8.7-1).
> [...] 
> I'll gladly further debug the issue if you give me instructions.

I ran coturn in gdb now (with coturn-dbg and libssl1.0.2-dbg installed)
and it segfaulted again:

Thread 2 "turnserver" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x71709700 (LWP 26630)]
ssl3_get_message (s=0x7fffec007fd0, st1=0, stn=0, mt=26630,
max=140737152848544, ok=0x0)
at s3_both.c:364
364 s3_both.c: No such file or directory.

The full backtrace is attached.

Cheers,
 jonas


Thread 7 (Thread 0x7fffea7fc700 (LWP 26635)):
#0  0x75699fd3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x76bc1a48 in ?? () from /usr/lib/x86_64-linux-gnu/libevent_core-2.0.so.5
No symbol table info available.
#2  0x76babd2a in event_base_loop () from /usr/lib/x86_64-linux-gnu/libevent_core-2.0.so.5
No symbol table info available.
#3  0x55569593 in run_events (eb=0x7fffdc0008f0, e=e@entry=0x0)
at src/apps/relay/netengine.c:1550
timeout = {tv_sec = 5, tv_usec = 0}
#4  0x5556ad37 in run_admin_server_thread (arg=0x557f1540 )
at src/apps/relay/netengine.c:1788
__FUNCTION__ = "run_admin_server_thread"
#5  0x75956464 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#6  0x756999df in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.

Thread 6 (Thread 0x7fffeaffd700 (LWP 26634)):
#0  0x75699fd3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x76bc1a48 in ?? () from /usr/lib/x86_64-linux-gnu/libevent_core-2.0.so.5
No symbol table info available.
#2  0x76babd2a in event_base_loop () from /usr/lib/x86_64-linux-gnu/libevent_core-2.0.so.5
No symbol table info available.
#3  0x55569593 in run_events (eb=0x7fffd80008f0, e=e@entry=0x0)
at src/apps/relay/netengine.c:1550
timeout = {tv_sec = 5, tv_usec = 0}
#4  0x5556acfc in run_auth_server_thread (arg=0x557cd6a0 <authserver+96>)
at src/apps/relay/netengine.c:1763
pair = {0x7fffd8001210, 0x7fffd80015b0}
as = 0x557cd6a0 <authserver+96>
id = 
__FUNCTION__ = "run_auth_server_thread"
#5  0x75956464 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#6  0x756999df in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.

Thread 5 (Thread 0x7fffeb7fe700 (LWP 26633)):
#0  0x75699fd3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x76bc1a48 in ?? () from /usr/lib/x86_64-linux-gnu/libevent_core-2.0.so.5
No symbol table info available.
#2  0x76babd2a in event_base_loop () from /usr/lib/x86_64-linux-gnu/libevent_core-2.0.so.5
No symbol table info available.
#3  0x55569593 in run_events (eb=0x7fffe8f0, e=e@entry=0x0)
at src/apps/relay/netengine.c:1550
timeout = {tv_sec = 5, tv_usec = 0}
#4  0x5556acfc in run_auth_server_thread (arg=0x557cd670 <authserver+48>)
at src/apps/relay/netengine.c:1763
pair = {0x7fffe0001110, 0x7fffe00014b0}
as = 0x557cd670 <authserver+48>
id = 
__FUNCTION__ = "run_auth_server_thread"
#5  0x75956464 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#6  0x756999df in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.

Thread 4 (Thread 0x7fffebfff700 (LWP 26632)):
#0  0x7566908d in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x75668fda in sleep () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x5556ac3a in run_auth_server_thread (arg=0x557cd640 )
at src/apps/relay/netengine.c:1733
as = 0x557cd640 
id = 
__FUNCTION__ = "run_auth_server_thread"
#3  0x75956464 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#4  0x756999df in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.

Thread 3 (Thread 0x70d07700 (LWP 26631)):
#0  0x75699fd3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x76bc1a48 in ?? () from /usr/lib/x86_64-linux-gnu/libevent_core-2.0.so.5
No symbol table info available.
#2  0x76babd2a in event_base_loop () from /usr/lib/x86_64-linux-gnu/libevent_core-2.0.so.5
No symbol table info available.
#3  0x55569593 in run_events (eb=0x7fffe40008f0, e=0x70d081e8)
at src/apps/relay/netengine.c:1550

Bug#846649: Frequent segfaults of coturn

[Jonas Meurer]

Package: coturn
Version: 4.5.0.5-1
Severity: serious

Hi,

I encounter frequent segfaults of coturn on a Debian Squeeze VM with
recent kernel (4.8.7-1). I don't know much about coturn, just use it for
a Spreed.ME installation and so far it worked well. But recently it
started to segfault out of the blue. I'm pretty sure that it's not even
used when segfaulting as it is a test installation with very few users.

Here's the log output from syslog:

Nov 28 22:37:49 ld-test kernel: [3277040.519778] turnserver[4996]: segfault at 
8 ip 7fc8f6a38dc6 sp 7fc8f134bce0 error 4 in 
libssl.so.1.0.2[7fc8f6a1+5f000]

Nov 29 15:53:59 ld-test kernel: [3339210.639775] turnserver[4691]: segfault at 
8 ip 7f9afec9adc6 sp 7f9af95adce0 error 4 in 
libssl.so.1.0.2[7f9afec72000+5f000]

Dec  2 18:46:41 ld-test kernel: [14301.129202] turnserver[658]: segfault at 8 
ip 7f52b5932dc6 sp 7f52af843ce0 error 4 in 
libssl.so.1.0.2[7f52b590a000+5f000]

/var/log/turn/turn_.log and /var/log/turn__.log both
don't hold anything related to the segfault.

I'll gladly further debug the issue if you give me instructions.

Cheers,
 jonas

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

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

Versions of packages coturn depends on:
ii  adduser  3.115
ii  libc62.24-7
ii  libevent-core-2.0-5  2.0.21-stable-2.1
ii  libevent-extra-2.0-5 2.0.21-stable-2.1
ii  libevent-openssl-2.0-5   2.0.21-stable-2.1
ii  libevent-pthreads-2.0-5  2.0.21-stable-2.1
ii  libhiredis0.13   0.13.3-2
ii  libmariadbclient18   10.0.28-2
ii  libpq5   9.6.1-2
ii  libsqlite3-0 3.15.1-1
ii  libssl1.0.2  1.0.2j-4
ii  lsb-base 9.20161125
ii  telnet [telnet-client]   0.17-41

coturn recommends no packages.

Versions of packages coturn suggests:
pn  sip-router   
pn  xmpp-server  

-- Configuration Files:
/etc/default/coturn changed:
TURNSERVER_ENABLED=1

/etc/turnserver.conf changed:
listening-port=8443
alt-listening-port=3478


listening-ip=172.18.20.144
relay-ip=172.18.20.144


fingerprint
lt-cred-mech
use-auth-secret
static-auth-secret=
realm=XXX
total-quota=100
bps-capacity=0
stale-nonce=600
cert=/etc/letsencrypt/live/XX/fullchain.pem
pkey=/etc/letsencrypt/live/XX/privkey.pem
log-file=/var/log/turn/turn.log

no-loopback-peers
no-multicast-peers


-- no debconf information

Bug#844299: big $HISTSIZE causes exessive memory usage

[Jonas Meurer]

Package: bash
Version: 4.4-1
Severity: serious

Hello,

apparently bash 4.4 as available in Debian Stretch introduced a
regression compared to 4.3 from Debian Jessie: when setting $HISTSIZE to
a big value (e.g.  as suggested in a lot of docs out there on
the web), the resulting bash process seems to allocate way to much
memory, approximately 800MB each.

I consider this a severe memory leak/consumption bug, thus setting
severity to serious. Feel free to lower severity if you disagree.

It's not enough to set the environment variable $HISTSIZE in a running
bash session. Instead, it needs to set at invocation of the shell, e.g.
by setting it in the ~/.bashrc:

HISTSIZE=

Here's the process status page of a process with HISTSIZE=:

$ cat /proc/3156/status
Name:   bash
Umask:  0022
State:  S (sleeping)
Tgid:   3156
Ngid:   0
Pid:3156
PPid:   2796
TracerPid:  0
Uid:1000100010001000
Gid:1000100010001000
FDSize: 256
Groups: 24 25 27 29 30 44 46 107 111 123 125 126 127 1000 
NStgid: 3156
NSpid:  3156
NSpgid: 3156
NSsid:  3156
VmPeak:  1071904 kB
VmSize:  1071868 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM:787328 kB
VmRSS:787328 kB
RssAnon:  783640 kB
RssFile:3688 kB
RssShmem:  0 kB
VmData:  1050920 kB
VmStk:   136 kB
VmExe:  1024 kB
VmLib:  2116 kB
VmPTE:  1600 kB
VmPMD:16 kB
VmSwap:0 kB
HugetlbPages:  0 kB
Threads:1
SigQ:   0/45722
SigPnd: 
ShdPnd: 
SigBlk: 0001
SigIgn: 00380004
SigCgt: 4b817efb
CapInh: 
CapPrm: 
CapEff: 
CapBnd: 003f
CapAmb: 
Seccomp:0
Cpus_allowed:   ff
Cpus_allowed_list:  0-7
Mems_allowed:   ,0001
Mems_allowed_list:  0
voluntary_ctxt_switches:30
nonvoluntary_ctxt_switches: 13

And here you find the status page of a bash process with default
HISTSIZE=1000:

$ cat /proc/6888/status
Name:   bash
Umask:  0022
State:  S (sleeping)
Tgid:   6888
Ngid:   0
Pid:6888
PPid:   2796
TracerPid:  0
Uid:1000100010001000
Gid:1000100010001000
FDSize: 256
Groups: 24 25 27 29 30 44 46 107 111 123 125 126 127 1000 
NStgid: 6888
NSpid:  6888
NSpgid: 6888
NSsid:  6888
VmPeak:23220 kB
VmSize:23156 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM:  6028 kB
VmRSS:  6028 kB
RssAnon:2248 kB
RssFile:3780 kB
RssShmem:  0 kB
VmData: 2208 kB
VmStk:   136 kB
VmExe:  1024 kB
VmLib:  2116 kB
VmPTE:64 kB
VmPMD:12 kB
VmSwap:0 kB
HugetlbPages:  0 kB
Threads:1
SigQ:   0/45722
SigPnd: 
ShdPnd: 
SigBlk: 0001
SigIgn: 00380004
SigCgt: 4b817efb
CapInh: 
CapPrm: 
CapEff: 
CapBnd: 003f
CapAmb: 
Seccomp:0
Cpus_allowed:   ff
Cpus_allowed_list:  0-7
Mems_allowed:   ,0001
Mems_allowed_list:  0
voluntary_ctxt_switches:57
nonvoluntary_ctxt_switches: 7

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

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

Versions of packages bash depends on:
ii  base-files   9.6
ii  dash 0.5.8-2.3
ii  debianutils  4.8
ii  libc62.24-5
ii  libtinfo56.0+20160917-1

Versions of packages bash recommends:
ii  bash-completion  1:2.1-4.3

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#798080: mysql-server-5.6: service stop hangs forever on systemd -- fixed upstream

[Jonas Meurer]

Control: notfixed -1 5.6.30-1

Hello,

On Sun, 2 Oct 2016 15:07:31 -0400 "William L. DeRieux IV" wrote:
> I had an older version installed and could confirm the issue existed;
> but as of v5.6.30-1 this is no longer an issue.

unfortunately, this bug seems to be not fixed in the MySQL 5.6 packages
in Sid/Stretch. The systemd unit still uses mysqld_safe there and as a
result, systemd seems to fail to stop the MySQL daemon in certain
circumstances.

Giving mysqld directly to systemd (as done in the new mysql-5.7
packages) fixes this bug:

ExecStart=/usr/sbin/mysqld

Cheers,
 jonas




signature.asc
Description: OpenPGP digital signature

Bug#841289: [drm/i915] GPU HANG: ecode 9:0:0xfffffffe, in Xorg [2507], reason: Engine(s) hung, action: reset

[Jonas Meurer]

Package: src:linux
Version: 4.7.6-1
Severity: grave
Justification: renders package unusable

Hello,

recently, something on my system related to drm/i915 broke. Since no
xserver/drm packages have been upgraded, I strongly suspect the latest
linux kernel upgrade to be the culprit.

Since several days, the X server on my Lenovo Thinkpad T460 sometimes
freezes, apparently when gnome locks and turns of the screen after some
time of inactivity. This renders the system completely unusable, it
seems to not react at all anymore. Also changing to a text consoly
(tty) doesn't work.

Below you find a copy of the relevant syslog entries. Unfortunately,
since the system is rendered unusable, I'm not able to save the crash
details from /sys/class/drm/card0/error. After reboot, it obviously is
empty again.

Please tell me if I can do anything more to debug this bug. It's very
annoying as it sometimes implies loosing things that you just worked on.

Unfortunately, I don't know another way to reproduce the bug apart from
waiting for the automatic screen lock. Then you have to be (un)lucky
because it doesn't freeze every time.

Cheers,
 jonas

(Assumed) relevant logs from /var/log/syslog:

[...]
Oct 12 21:43:01 calvin2 kernel: [11219.762878] [drm] RC6 on
Oct 12 21:43:25 calvin2 kernel: [11243.760753] [drm] RC6 on
Oct 12 21:43:54 calvin2 kernel: [11272.758240] [drm] RC6 on
Oct 12 21:44:23 calvin2 kernel: [11301.754923] [drm] RC6 on
Oct 12 21:44:40 calvin2 kernel: [11318.753426] [drm] stuck on render ring
Oct 12 21:44:40 calvin2 kernel: [11318.754593] [drm] GPU HANG: ecode 
9:0:0xfffe, in Xorg [2507], reas
on: Engine(s) hung, action: reset
Oct 12 21:44:40 calvin2 kernel: [11318.754599] [drm] GPU hangs can indicate a 
bug anywhere in the entire 
gfx stack, including userspace.
Oct 12 21:44:40 calvin2 kernel: [11318.754603] [drm] Please file a _new_ bug 
report on bugs.freedesktop.o
rg against DRI -> DRM/Intel
Oct 12 21:44:40 calvin2 kernel: [11318.754607] [drm] drm/i915 developers can 
then reassign to the right c
omponent if it's not a kernel issue.
Oct 12 21:44:40 calvin2 kernel: [11318.754610] [drm] The gpu crash dump is 
required to analyze gpu hangs,
 so please always attach it.
Oct 12 21:44:40 calvin2 kernel: [11318.754614] [drm] GPU crash dump saved to 
/sys/class/drm/card0/error
Oct 12 21:44:40 calvin2 kernel: [11318.756979] drm/i915: Resetting chip after 
gpu hang
Oct 12 21:44:41 calvin2 kernel: [11319.761430] [drm] RC6 on
Oct 12 21:44:50 calvin2 kernel: [11328.752757] [drm] stuck on render ring
Oct 12 21:44:50 calvin2 kernel: [11328.753891] [drm] GPU HANG: ecode 
9:0:0xfffe, in Xorg [2507], reason: Engine(s) hung, action: reset
Oct 12 21:44:50 calvin2 kernel: [11328.756633] drm/i915: Resetting chip after 
gpu hang
Oct 12 21:44:51 calvin2 /usr/lib/gdm3/gdm-x-session[2505]: (II) modeset(0): 
EDID vendor "LGD", prod id 1188
Oct 12 21:44:51 calvin2 /usr/lib/gdm3/gdm-x-session[2505]: (II) modeset(0): 
Printing DDC gathered Modelines:
Oct 12 21:44:51 calvin2 /usr/lib/gdm3/gdm-x-session[2505]: (II) modeset(0): 
Modeline "1920x1080"x0.0  138.70  1920 1968 2000 2080  1080 1083 1088  
+hsync -vsync (66.7 kHz eP)
Oct 12 21:44:51 calvin2 /usr/lib/gdm3/gdm-x-session[2505]: (II) modeset(0): 
EDID vendor "LGD", prod id 1188
Oct 12 21:44:51 calvin2 /usr/lib/gdm3/gdm-x-session[2505]: (II) modeset(0): 
Printing DDC gathered Modelines:
Oct 12 21:44:51 calvin2 /usr/lib/gdm3/gdm-x-session[2505]: (II) modeset(0): 
Modeline "1920x1080"x0.0  138.70  1920 1968 2000 2080  1080 1083 1088  
+hsync -vsync (66.7 kHz eP)
Oct 12 21:44:51 calvin2 /usr/lib/gdm3/gdm-x-session[2505]: (II) modeset(0): 
EDID vendor "LGD", prod id 1188
Oct 12 21:44:51 calvin2 /usr/lib/gdm3/gdm-x-session[2505]: (II) modeset(0): 
Printing DDC gathered Modelines:
Oct 12 21:44:51 calvin2 /usr/lib/gdm3/gdm-x-session[2505]: (II) modeset(0): 
Modeline "1920x1080"x0.0  138.70  1920 1968 2000 2080  1080 1083 1088  
+hsync -vsync (66.7 kHz eP)
Oct 12 21:44:51 calvin2 kernel: [11329.760399] [drm] RC6 on
Oct 12 21:44:51 calvin2 /usr/lib/gdm3/gdm-x-session[2505]: 
intel_do_flush_locked failed: Input/output error
Oct 12 21:44:51 calvin2 firefox-esr.desktop[3113]: firefox-esr: Fatal IO error 
11 (Die Ressource ist zur Zeit nicht verfügbar) on X server :0.
Oct 12 21:44:51 calvin2 pidgin.desktop[2749]: Pidgin: Fatal IO error 11 (Die 
Ressource ist zur Zeit nicht verfügbar) on X server :0.
[...]
Oct 12 21:44:51 calvin2 kernel: [11329.834184] Qt bearer threa[2850]: segfault 
at 0 ip 7fd4d6fbe9e5 sp 7fd4b7b8e560 error 4 in 
libQt5DBus.so.5.6.1[7fd4d6f5c000+87000]
Oct 12 21:44:51 calvin2 nautilus-autostart.desktop[2779]: Server response: 
STATUS:OK:/home/user
Oct 12 21:44:51 calvin2 org.a11y.atspi.Registry[2589]: XIO:  fatal IO error 11 
(Resource temporarily unavailable) on X server ":0"
Oct 12 21:44:51 calvin2 org.a11y.atspi.Registry[2589]:   after 17393 
requests (17393 known processed) with 0 events remaining.
Oct 12 21:44:51 calvin2 

Bug#839888: [pkg-cryptsetup-devel] Bug#839888: closed by Jonas Meurer <m...@debian.org> (Bug#839888: fixed in cryptsetup 2:1.7.2-2)

[Jonas Meurer]

Hi Marc,

Am 06.10.2016 um 12:57 schrieb Marc Haber:
> thanks for the quick fix. I have, however, to add that my systems do
> have systemd as PID 1.

Interesting. So you use systemd and still the cryptdisks initscript is
invoked. I guess that you manually configured your system to do so
because you use some crypttab feature not supported by the systemd
cryptsetup helper - presumably keyscripts? ;)

Can you share the way you set up your system? I hope to find a solution
for supporting keyscripts with systemd in time for Stretch (see [1]) but
I fear that I will not have enough time. In that case I'd like to at
least provide some best-practice docs on how to use the cryptdisks
initscript again.

Cheers,
 jonas

[1]
https://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2016-September/012641.html



signature.asc
Description: OpenPGP digital signature

Bug#783297: [pkg-cryptsetup-devel] Bug#783297: breaks initramfs if BUSYBOX=n

[Jonas Meurer]

clone 783297 -1 -2
reassign -1 busybox
retitle -1 don't source initramfs.conf in busybox initramfs hook
reassign -2 initramfs-tools
retitle -2 remove busybox hook, leave responsibility to busybox package
severity -2 important
retitle 783297 split initramfs integration into a separate package
severity 783297 wishlist
thanks

This mail clones the original bugreport two times and reassigns the
clones to the busybox and initramfs-tools packages with appropriate
titles. See below for details.

Am 27.12.2015 um 07:35 schrieb Ben Hutchings:
> On Fri, 2015-12-25 at 14:46 +0100, Jonas Meurer wrote:
> [...]
>>
>>> /usr/share/initramfs-tools/hooks/busybox will see the BUSYBOX=y setting
>>> and copy the busybox binary.
>>>
>>> /usr/share/initramfs-tools/hooks/zz-busybox sources
>>> /etc/initramfs-tools/initramfs.conf, therefor BUSYBOX=n will be set
>>> again, and the symlinks are not created.
>>
>> Honestly, this looks like a bug in busybox to me. What's the reason for
>> the two busybox initramfs hook scripts at all?
>>
>> *) /usr/share/initramfs-tools/hooks/busybox copies bin/busybox to the
>>initramfs and links /bin/sh to it without sourcing initramfs.conf.
> 
> This is part of initramfs-tools.

So this busybox initramfs hook should be dropped from initramfs-tools
and responsibility for installing busybox into initramfs be handed over
to the busybox package.

>> *) /usr/share/initramfs-tools/hooks/zz-busybox-initramfs sources
>>initramfs.conf, removes busybox binary from initramfs if existent,
>>and copies bin/busybox to initramfs and links all aliases provided
>>by busybox to it.
> 
> This is actually called zz-busybox, and is part of busybox.  Somehow I
> failed to notice this exists. :-/
> 
>> I don't understand the following:
>>
>> What's the purpose of /usr/share/initramfs-tools/hooks/busybox at all,
>> if changes are reverted by
>> /usr/share/initramfs-tools/hooks/zz-busybox-initramfs later on anyway
>> and redone in a slightly different fashion?
> 
> Yes, this is stupid.  We should arrange to properly hand over
> responsibility for installing busybox, and adjust package dependencies
> accordingly.

Ack.

> 
>> Why does /usr/share/initramfs-tools/hooks/zz-busybox-initramfs source
>> initramfs.conf? The BUSYBOY variable is exported by mkinitramfs anyway.
>>
>> The simplest fix to this bug would be to stop sourcing initramfs.conf in
>> hooks/zz-busybox-initramfs.
> 
> It should certainly stop doing that.

This is about the bug in busybox: stop sourcing initramfs.conf from the
zz-busybox initramfs hook.

> [...]
>>> b/ /usr/share/initramfs-tools/conf-hooks.d/cryptsetup drops the
>>> BUSYBOX=y line. And if this is not an option, because cryptsetup
>>> requires busybox, then this should be reflected in the package
>>> dependencies accordingly by making the Recommends a Depends.
>>
>> Do you think that the cryptsetup packages should depend on
>> initramfs-tools and busybox despite the fact that they're usable without?
> 
> No, they should only recommend them.   The busybox hook script is
> changed in initramfs-tools 0.121~rc2 to hard fail if busybox is wanted
> but not installed.  If it's dropped in favour of the zz-busybox hook
> script, then I can move that check into mkinitramfs.

So indeed the check needs to be moved to mkinitramfs as soon as
responsibility for installing busybox is handed over to the busybox
package itself.

Am 27.12.2015 um 14:21 schrieb Michael Biebl:
> Am 25.12.2015 um 14:46 schrieb Jonas Meurer:
>> Yes, cryptsetup initramfs scripts do depend on busybox. At least this
>> was the case some years ago.
>>
>> As cryptsetup can be used without initramfs (e.g. only home
>> partition or removable storage encrypted), the cryptsetup package
>> doesn't depend on "initramfs-tools, busybox" but merely recommends
>> them.
>
> If you want to cleanly support those two different use cases, it looks
> like the cleanest solution would be, to ship the initramfs integration
> in a separate binary package, say cryptsetup-initramfs-tools.
>
> This subpackage would have a strict dependency on initramfs-tools and
> busybox. The main cryptsetup package could have a recommends on that
> subpackage.

This part is about the cryptsetup package itself: it is suggested to
split the initramfs stuff out into a seperate binary package (I prefer
the name 'cryptsetup-initramfs'). This is a wishlist bug.

Cheers,
 jonas




signature.asc
Description: OpenPGP digital signature

Bug#783297: [pkg-cryptsetup-devel] Bug#783297: breaks initramfs if BUSYBOX=n

[Jonas Meurer]

Hi Michael, hi Ben,

Am 26.04.2015 um 01:35 schrieb Michael Biebl:
> On Sat, 25 Apr 2015 16:22:13 +0200 Michael Biebl  wrote:
>> if the cryptsetup package is installed, it also installed a
>> initramfs-tools hook.
>>
>> I use BUSYBOX=no in initramfs.conf, but the  cryptroot hook copies
>> /bin/busybox to the initramfs nonetheless.
>>
>> As a result, the initramfs is unable to boot the system
> 
> I looked into this in more detail, and the culprit seems to be
> /usr/share/initramfs-tools/conf-hooks.d/cryptsetup
> which forcefully set's
> BUSYBOX=y.

Yes, cryptsetup initramfs scripts do depend on busybox. At least this
was the case some years ago.

As cryptsetup can be used without initramfs (e.g. only home partition or
removable storage encrypted), the cryptsetup package doesn't depend on
"initramfs-tools, busybox" but merely recommends them.

> /usr/share/initramfs-tools/hooks/busybox will see the BUSYBOX=y setting
> and copy the busybox binary.
> 
> /usr/share/initramfs-tools/hooks/zz-busybox sources
> /etc/initramfs-tools/initramfs.conf, therefor BUSYBOX=n will be set
> again, and the symlinks are not created.

Honestly, this looks like a bug in busybox to me. What's the reason for
the two busybox initramfs hook scripts at all?

*) /usr/share/initramfs-tools/hooks/busybox copies bin/busybox to the
   initramfs and links /bin/sh to it without sourcing initramfs.conf.
*) /usr/share/initramfs-tools/hooks/zz-busybox-initramfs sources
   initramfs.conf, removes busybox binary from initramfs if existent,
   and copies bin/busybox to initramfs and links all aliases provided
   by busybox to it.

I don't understand the following:

What's the purpose of /usr/share/initramfs-tools/hooks/busybox at all,
if changes are reverted by
/usr/share/initramfs-tools/hooks/zz-busybox-initramfs later on anyway
and redone in a slightly different fashion?

Why does /usr/share/initramfs-tools/hooks/zz-busybox-initramfs source
initramfs.conf? The BUSYBOY variable is exported by mkinitramfs anyway.

The simplest fix to this bug would be to stop sourcing initramfs.conf in
hooks/zz-busybox-initramfs.

> The result is a broken initramfs.
> 
> I'm not sure, what is supposed to take precedence in such a case: The
> configuration in /etc/initramfs-tools/initramfs.conf or
> /usr/share/initramfs-tools/conf-hooks.d/cryptsetup and if it's a bug in
> cryptsetup which forcefully overrides BUSYBOX= or if it's a bug in
> busybox, which sources /etc/initramfs-tools/initramfs.conf in
> /usr/share/initramfs-tools/hooks/zz-busybox and therefor doesn't respect
> the settings which are set via conf-hooks.d.

To my understanding, the purpose of
/usr/share/initramfs-tools/hooks-conf.d is to provide a place where
packages that include an initramfs hook script can overwrite settings to
initramfs.conf without altering the config file itself. In other words,
this directory is like an include directory for initramfs.conf. This
implies, that every script which explicitly uses/sources initramfs.conf,
needs to honour this include directory as well.

In fact, we (Guilhem Moulin and me) discuss a related topic with the
initramfs-tools maintainers in bugreport #807527[1] at the moment. In
our eyes, initramfs-tools should provide a clear API or best practice
for custom initramfs hook configuration.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807527

> If cryptsetup really requires busybox and forcefully sets BUSYBOX=y, why
> does the cryptsetup package not depend on busybox?

See above.

> I see several possible fixes here
> 
> a/ /usr/share/initramfs-tools/hooks/zz-busybox doesn't source
> /etc/initramfs-tools/initramfs.conf directly and as a result respects
> settings from hooks directories.

If there's no reason for sourcing initramfs.conf in hooks/zz-busybox,
then this definitely is the way to go.

> b/ /usr/share/initramfs-tools/conf-hooks.d/cryptsetup drops the
> BUSYBOX=y line. And if this is not an option, because cryptsetup
> requires busybox, then this should be reflected in the package
> dependencies accordingly by making the Recommends a Depends.

Do you think that the cryptsetup packages should depend on
initramfs-tools and busybox despite the fact that they're usable without?

Cheers
 jonas




signature.asc
Description: OpenPGP digital signature

Bug#782996: smsd: 'reload' function of initscript broken if used by systemd

[Jonas Meurer]

Am 21.04.2015 um 15:15 schrieb Jonas Meurer:
 I consider this bug as release-critical for Jessie, as it renders
 smmstools unusable on Jessie installations whenever logrotate is
 installed. Thus I suggest to push the fix into Jessie within the next
 days. I'll gladly do an NMU if the maintainer(s) don't have the time
 to push this fix into Jessie in time.
 
 According to release managers, this update won't make it into Jessie,
 which is already in the quiet period (shortly before release). Instead,
 a fixed package should be uploaded to stable-proposed-updates in order
 to make it into the first point release of Jessie (8.1).
 
 If nobody speaks up, then I intend to upload the NMU to unstable next
 week, wait one or two weeks and upload to stable-proposed-updates
 afterwards.

I just uploaded the NMU to unstable now. You find the final NMU diff
attached to this mail. Only difference to my last patch is that the
changelog entry contains the number of this bugreport now.

I'll go ahead with an upload to stable-proposed-updates within the next
days.

Cheers,
 jonas


diff -u smstools-3.1.15/debian/changelog smstools-3.1.15/debian/changelog
--- smstools-3.1.15/debian/changelog
+++ smstools-3.1.15/debian/changelog
@@ -1,3 +1,17 @@
+smstools (3.1.15-1.2) unstable; urgency=high
+
+  * NMU by Jonas Meurer to push the fix into Jessie.
+  * Fix initscript (debian/init.d):
+* drop action 'reload' as it does not what policy demands it to do. Use
+  'force-reload' in logrotate post-rotate action. This fixes 'force-reload'
+  action when used through systemd tools and prevents the smsd daemon
+  process from being killed at every log rotation. (closes: #782996)
+* source /lib/lsb/init-functions in order to make systemd tools aware of
+  status changes to the daemon that have been caused by invoking the
+  initscript directly.
+
+ -- Jonas Meurer m...@debian.org  Mon, 27 Apr 2015 20:45:40 +0200
+
 smstools (3.1.15-1.1) unstable; urgency=low
 
   * NMU - preventing smstools from entering jessie.
diff -u smstools-3.1.15/debian/init.d smstools-3.1.15/debian/init.d
--- smstools-3.1.15/debian/init.d
+++ smstools-3.1.15/debian/init.d
@@ -25,6 +25,8 @@
 
 test -x $DAEMON || exit 0
 
+. /lib/lsb/init-functions
+
 if [ ! -f /etc/default/$PACKAGE ]
 then
 	exit 1
@@ -218,17 +220,6 @@
 		echo $NAME.
 
 	;;
-	reload)
-		echo -n Reloading $DESC: 
-		status
-		if [ $? = 0 ]; then
-			stop restart
-			start
-		else
-			echo $NAME is not running.
-		fi
-		
-	;;
 
 	restart|force-reload)
 		echo -n Restarting $DESC: 
@@ -237,7 +228,7 @@
 	;;
 
 	*)
-		echo Usage: /etc/init.d/$NAME {start|stop|force-stop|reload|force-reload|restart|status}
+		echo Usage: /etc/init.d/$NAME {start|stop|force-stop|force-reload|restart|status}
 		exit 3
 	;;
 esac
diff -u smstools-3.1.15/debian/logrotate smstools-3.1.15/debian/logrotate
--- smstools-3.1.15/debian/logrotate
+++ smstools-3.1.15/debian/logrotate
@@ -5,5 +5,5 @@
 missingok
 postrotate
-invoke-rc.d smstools reload  /dev/null
+invoke-rc.d smstools force-reload  /dev/null
 endscript
 }

Bug#782996: smsd: 'reload' function of initscript broken if used by systemd

[Jonas Meurer]

Hi again,

Am 2015-04-20 11:55, schrieb Jonas MEURER:
The bug can be fixed by renaming the 'reload' function to 
'force-reload'
and dropping the original 'force-reload' alias for 'restart'. Please 
note,

that fixing the 'Usage:' line by dropping 'reload' from the list of
supported actions is important as well. Otherwise, systemd tools try to
invoke 'reload' even if 'force-reload' is given as argument.


in some further discussion on IRC channel #debian-systemd, Michael Biebl
made me aware that my fix was not policy-compliant. According to Debian
Policy, 'force-reload' should reload the service if this function is
available, and restart otherwise. Therefore I reverted the change to add
a separate 'force-reload' action and kept 'force-reload' as an alias to
'restart'. Only the 'reload' option was dropped.

Additionally, I added a line at the beginning of the initscript, 
sourcing

'/lib/lsb/init-functions'. This is necessary to make systemd aware of
status changes to the daemon that have been caused by running the
initscript directly (i.e. not through systemd helper tools). This change
is really non-intrusive and leads to a much better user experience.


See the attached patch for a proper fix.


I attached an updated patch.


I consider this bug as release-critical for Jessie, as it renders
smmstools unusable on Jessie installations whenever logrotate is
installed. Thus I suggest to push the fix into Jessie within the next
days. I'll gladly do an NMU if the maintainer(s) don't have the time
to push this fix into Jessie in time.


According to release managers, this update won't make it into Jessie,
which is already in the quiet period (shortly before release). Instead,
a fixed package should be uploaded to stable-proposed-updates in order
to make it into the first point release of Jessie (8.1).

If nobody speaks up, then I intend to upload the NMU to unstable next
week, wait one or two weeks and upload to stable-proposed-updates
afterwards.

Cheers,
 jonas


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

Bug#782996: smsd: 'reload' function of initscript broken if used by systemd

[Jonas Meurer]

Am 2015-04-21 15:15, schrieb Jonas Meurer:

See the attached patch for a proper fix.


I attached an updated patch.


Argh, this time with the updated patch :)

Cheers,
 jonasdiff -rNu smstools-3.1.15.orig/debian/changelog smstools-3.1.15/debian/changelog
--- smstools-3.1.15.orig/debian/changelog	2015-04-20 11:46:00.0 +0200
+++ smstools-3.1.15/debian/changelog	2015-04-21 15:13:32.668376587 +0200
@@ -1,3 +1,17 @@
+smstools (3.1.15-1.2) unstable; urgency=high
+
+  * NMU by Jonas Meurer to push the fix into Jessie.
+  * Fix initscript (debian/init.d):
+* drop action 'reload' as it does not what policy demands it to do. Use
+  'force-reload' in logrotate post-rotate action. This fixes 'force-reload'
+  action when used through systemd tools and prevents the smsd daemon
+  process from being killed at every log rotation. (closes: #XX)
+* source /lib/lsb/init-functions in order to make systemd tools aware of
+  status changes to the daemon that have been caused by invoking the
+  initscript directly.
+
+ -- Jonas Meurer jo...@freesources.org  Mon, 20 Apr 2015 11:46:53 +0200
+
 smstools (3.1.15-1.1) unstable; urgency=low
 
   * NMU - preventing smstools from entering jessie.
diff -rNu smstools-3.1.15.orig/debian/init.d smstools-3.1.15/debian/init.d
--- smstools-3.1.15.orig/debian/init.d	2015-04-20 11:46:00.0 +0200
+++ smstools-3.1.15/debian/init.d	2015-04-21 14:54:45.444351751 +0200
@@ -25,6 +25,8 @@
 
 test -x $DAEMON || exit 0
 
+. /lib/lsb/init-functions
+
 if [ ! -f /etc/default/$PACKAGE ]
 then
 	exit 1
@@ -218,17 +220,6 @@
 		echo $NAME.
 
 	;;
-	reload)
-		echo -n Reloading $DESC: 
-		status
-		if [ $? = 0 ]; then
-			stop restart
-			start
-		else
-			echo $NAME is not running.
-		fi
-		
-	;;
 
 	restart|force-reload)
 		echo -n Restarting $DESC: 
@@ -237,7 +228,7 @@
 	;;
 
 	*)
-		echo Usage: /etc/init.d/$NAME {start|stop|force-stop|reload|force-reload|restart|status}
+		echo Usage: /etc/init.d/$NAME {start|stop|force-stop|force-reload|restart|status}
 		exit 3
 	;;
 esac
diff -rNu smstools-3.1.15.orig/debian/logrotate smstools-3.1.15/debian/logrotate
--- smstools-3.1.15.orig/debian/logrotate	2015-04-20 11:46:00.0 +0200
+++ smstools-3.1.15/debian/logrotate	2015-04-20 11:46:50.426199696 +0200
@@ -4,6 +4,6 @@
 compress
 missingok
 postrotate
-invoke-rc.d smstools reload  /dev/null
+invoke-rc.d smstools force-reload  /dev/null
 endscript
 }

Bug#782996: smsd: 'reload' function of initscript broken if used by systemd

[Jonas MEURER]

Package: smstools
Version: 3.1.15-1.1
Severity: serious

Hello,

the smstools initscript has a wrong implementation of the 'reload'
function which breaks if used through systemd tools. In fact, the 'reload'
function in smstools initscript doesn't reload the configuration of the
service without actually stopping and restarting the service. Instead, it
stops the service if it runs and restarts it afterwards. This is, what
'force-reload' is for.

As a result, 'invoke-rc.d smstools reload', 'service smstools reload' and
'systemctl reload smstools.service' all result in the smsd daemon being
killed and not restarted afterwards.

The smstools logrotate script runs 'invoke-rc.d smstools reload' as post-
rotate action, which leads to the smsd daemon process being killed 

The bug can be fixed by renaming the 'reload' function to 'force-reload'
and dropping the original 'force-reload' alias for 'restart'. Please note,
that fixing the 'Usage:' line by dropping 'reload' from the list of
supported actions is important as well. Otherwise, systemd tools try to
invoke 'reload' even if 'force-reload' is given as argument.

See the attached patch for a proper fix.

I consider this bug as release-critical for Jessie, as it renders
smmstools unusable on Jessie installations whenever logrotate is
installed. Thus I suggest to push the fix into Jessie within the next
days. I'll gladly do an NMU if the maintainer(s) don't have the time
to push this fix into Jessie in time.

Cheers,
 jonas

-- System Information:
Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/20 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 smstools depends on:
ii  adduser  3.113+nmu3
ii  debconf  1.5.56
ii  libc62.19-18
ii  libmm14  1.4.2-5
ii  ucf  3.0030

smstools recommends no packages.

smstools suggests no packages.

-- debconf information:
  smstools/devicepin: (password omitted)
  smstools/modems/devicepin1: (password omitted)
  smstools/configureanothermodem: false
  smstools/eventhandler:
  smstools/modems/devicenode1: /dev/ttyS0
  smstools/configure: true
  smstools/modems/deviceinit1:
  smstools/modems/devicename1: GSM1
  smstools/devicebaudrate: 19200
  smstools/deviceinit:
  smstools/devicenode:
  smstools/configureanothermodem1: false
  smstools/devicename: GSM1
  smstools/modems/deviceincoming1: true
  smstools/devicenodeother:
  smstools/devicebaudrateother:
  smstools/modems/devicebaudrate1: 19200
  smstools/deviceincoming: true
diff -rNu smstools-3.1.15.orig/debian/changelog smstools-3.1.15/debian/changelog
--- smstools-3.1.15.orig/debian/changelog	2015-04-20 11:46:00.0 +0200
+++ smstools-3.1.15/debian/changelog	2015-04-20 11:52:23.746207040 +0200
@@ -1,3 +1,14 @@
+smstools (3.1.15-1.2) unstable; urgency=high
+
+  * NMU by Jonas Meurer to push the fix into Jessie.
+  * Fix initscript: rename action 'reload' to 'force-reload' and drop 'reload'
+from supported actions. Use 'force-reload' in logrotate post-rotate action.
+This fixes 'force-reload' function when used through systemd tools and
+prevents the smsd daemon process from being killed at every log rotation.
+(closes: #XX)
+
+ -- Jonas Meurer jo...@freesources.org  Mon, 20 Apr 2015 11:46:53 +0200
+
 smstools (3.1.15-1.1) unstable; urgency=low
 
   * NMU - preventing smstools from entering jessie.
diff -rNu smstools-3.1.15.orig/debian/init.d smstools-3.1.15/debian/init.d
--- smstools-3.1.15.orig/debian/init.d	2015-04-20 11:46:00.0 +0200
+++ smstools-3.1.15/debian/init.d	2015-04-20 11:46:38.266199428 +0200
@@ -218,7 +218,7 @@
 		echo $NAME.
 
 	;;
-	reload)
+	force-reload)
 		echo -n Reloading $DESC: 
 		status
 		if [ $? = 0 ]; then
@@ -230,14 +230,14 @@
 		
 	;;
 
-	restart|force-reload)
+	restart)
 		echo -n Restarting $DESC: 
 		stop restart
 		start
 	;;
 
 	*)
-		echo Usage: /etc/init.d/$NAME {start|stop|force-stop|reload|force-reload|restart|status}
+		echo Usage: /etc/init.d/$NAME {start|stop|force-stop|force-reload|restart|status}
 		exit 3
 	;;
 esac
diff -rNu smstools-3.1.15.orig/debian/logrotate smstools-3.1.15/debian/logrotate
--- smstools-3.1.15.orig/debian/logrotate	2015-04-20 11:46:00.0 +0200
+++ smstools-3.1.15/debian/logrotate	2015-04-20 11:46:50.426199696 +0200
@@ -4,6 +4,6 @@
 compress
 missingok
 postrotate
-invoke-rc.d smstools reload  /dev/null
+invoke-rc.d smstools force-reload  /dev/null
 endscript
 }

Bug#774700: [pkg-cryptsetup-devel] Bug#774700: Cryptsetup tools are not included by update-initramfs command

[Jonas Meurer]

Hi,

Am 16.02.2015 um 19:36 schrieb Musy Bite:
 Hello Jonas!
 
 We run into this bug, too.  There is mkinitramfs_debug.log you requested
 at message #25.
 Installation was performed from debian testing amd64 netinst ISO image
 built on unknown date, and apt-get dist-upgraded to jessie. cryptsetup
 version is 2:1.6.6-5.

please send the content of /etc/crypttab and /etc/fstab in order to
better understand what's going on here. It seems to me like as if a UUID
is treaten as dm device name instead of being treated as UUID.

Cheers,
 jonas


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

Bug#774700: initramfs-tools: Cryptsetup tools are not included by update-initramfs command

[Jonas Meurer]

Hi Michael,

On Tue, 06 Jan 2015 14:40 Michael P. wrote:
 The update-initramfs command create a initrd.img without cryptsetup
 tools, but my root partition is crypted.
 
 I tried to debug a little the
 /usr/share/initramfs-tools/hooks/cryptroot file and found that the
 add_device() function returned an empty string, when passing
 /faith--vg-root as first argument.
 
 I am on a new machine. Everything was fine after a fresh install from
 jessie beta 2 installer. But after an update, the machine didn't
 reboot anymore: grub halted after Waiting for root device.

I changed the logic of add_device() recently in order to fix another
bug. I fear that you discovered a new bug that I introduced by these
changes.

In order to help me to better understand what is going on, please do the
following (as root, on the broken system):

1) append '-x' to the end of the first line at
/usr/share/initramfs-tools/hooks/cryptroot, so that it is: '#/bin/sh -x'.

2) execute '/usr/sbin/mkinitramfs -o /tmp/initrd.img-$(uname -r) $(uname
-r) /tmp/mkinitramfs_debug.log 21'

3) send /tmp/mkinitramfs_debug.log to this bugreport.

4) change the first line of /usr/share/initramfs-tools/hooks/cryptroot
back to '#/bin/sh' (i.e. remove the trailing '-x').

5) remove the created files: 'rm /tmp/initrd.img-$(uname -r)
/tmp/mkinitramfs_debug.log'.

Thanks in advance.

Cheers,
 jonas


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

Bug#767832: please test updated cryptsetup packages

[Jonas Meurer]

Hello everyone,

I prepared updated cryptsetup packages that fix the following bugs:

#767832: cryptsetup: does not decrypt a split /usr as required by
initramfs-tools = 0.118
#767921: files with the same name installed in / and /usr
#764564: openrc: fail to boot when encryption + lvm are present

Please give them a try and report back whether they work for you and fix
the particular bug you discovered.

You can find the prepared packages here:

https://people.debian.org/~mejo/debian/mejo-unstable/

Cheers,
 jonas


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

Bug#758755: [pkg-cryptsetup-devel] Bug#758755: Bug#758756: libgcrypt20: missing udeb: libgcrypt20-udeb

[Jonas Meurer]

Hey Andreas and Cyril,

Am 21.08.2014 um 19:25 schrieb Cyril Brulebois:
 Andreas Metzler ametz...@bebt.de (2014-08-21):
 On 2014-08-21 Cyril Brulebois k...@debian.org wrote:
 Package: libgcrypt20
 [...]
 but there's no libgcrypt20-udeb! (in the archive or in NEW)
 [...]

 I have just uploaded 1.6.1-3 with the udeb included. I hope NEW
 processing works out well.

Thanks a lot Andreas, it's much appreciated!

 I'll try poking ftpmasters to see if it can get accepted soon. That'd
 avoid thinking about a revert on the cryptsetup side.

Thanks for your help Cyril. Does this mean, that you're ok with
cryptsetup keeping libgcrypt20 dependency now that the corresponding
udeb will be in Debian soon?

Sorry that I didn't coordinate with debian-boot. I simply didn't think
about the consequences enough. I guess that's due to me not being
involved in library transitions too often :-/ *sorry*

Kind regards,
 jonas


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

Bug#758755: [pkg-cryptsetup-devel] Bug#758755: libcryptsetup4-udeb: depends on libgcrypt20-udeb, which doesn't exist

[Jonas Meurer]

Hi Cyril,

Am 2014-08-21 01:10, schrieb Cyril Brulebois:

Package: libcryptsetup4-udeb
Version: 2:1.6.6-1
Severity: grave
Justification: renders package unusable

Hi,

your package is no longer installable, because it now depends on
libgcrypt20-udeb, which is nowhere to be found.


now that you report the bugs I realize that I should have checked 
myself.


@GnuTLS-Maint: what's the reason for not shipping a libgcrypt20-udev 
yet?

Do you intend to fix #758756 soon?

Likely a bug in libgcrypt20 (which builds no udeb but leads you to get 
a
dependency on it) which I'm about to file. I don't see it in the 
archive

or in NEW at least.

The switch to libgcrypt20 seems premature to me.


I see. Reason for the switch to gcrypt 1.6 was the recent Whirlpool 
cipher

bug in gcrypt 1.5.3:

http://lists.gnupg.org/pipermail/gcrypt-devel/2014-January/002889.html
http://www.saout.de/pipermail/dm-crypt/2014-January/003799.html
http://www.saout.de/pipermail/dm-crypt/2014-February/003956.html

Also see section '8.3 Gcrypt after 1.5.3 breaks Whirlpool' in cryptsetup 
FAQ:

https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#8._Issues_with_Specific_Versions_of_cryptsetup

Kind regards,
 jonas


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

Bug#710356: [Pkg-nagios-devel] Bug#710356: Info received (Fix for wheezy?)

[Jonas Meurer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 09.12.2013 12:09, schrieb Jasir Baftijari:
 Hi,

Hello Jasir,

 why I can't see the new Version 3.4.1-3+deb7u1?
 
 # aptitude versions nagios3
 
 Paket nagios3: i 3.4.1-3 stable 500

The package is in wheezy-proposed-updates. It's not part of the
official Debian Wheezy packages yet.

Very likely it will be included in wheezy with the next point release
though. Afaik this should happen within the next four weeks. In the
meantime you can install it from proposed-updates:
http://www.debian.org/releases/proposed-updates.html

Kind regards,
 jonas


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSpjdSAAoJEBvzc5c7ZRqnkwYP/itpyzHzjwee48YBresApytQ
t1NMwRMIVdfNlk0rkzm2uy3a+F3BQYiYayn6g48gA2s6HXofcDhgLWEFMOCexmOZ
hcT73npvEz7KNaVXccLNinKuM+3i8ldyc7eYAwI7oMnSqhc05GBT8bOcL7TXZ2Dg
MeZmx/Rb15QGTn95L80V0pCC4/GwvuVUTn6p3nNiGSjPaggUPFMh6ssqponHrCum
u5s1cThx1SCleDx9X8awZNv/vPkWC5VMMiGp3BqYPdu8WBhaGNIFaOZPMXPhfIsD
ZTaw0e76ApMo3qZ68h3vA/WaA9ODjU3g4zYzk4oqtyFbsz/AC1hm2Z3KI22u34F3
w7POefgydyCFMsdeLQ8T2c5sY09uxPYn4SH3XgvyggL7UgyRb9uUD11XVUgD8FLK
wSS9jj+Mn2StRUCURo5mlxMuWgWKemyxchNajVBeNGnpxm/0V+Eio4sSbV+Ua4/+
7P2ut7uEFAjNKGor6JQRQYN/Q3G3rfV9N8hacloi/1juK+MhTAdFCzpApGVCV8xb
jVVbtOWwxxnLoO1aOEijGhYa99vM5GNa6x8s4GBEoBw9LUVsa0nbZD2hJmiPuU8w
OoBc3rCBerelTJWDrCmxbIu9OlltgG9NoWtts/8xSBWPHyq1cMt4NQ3halxNniLI
s/4wd6G9lHCDX54TiGAm
=q9T/
-END PGP SIGNATURE-


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

Bug#710356: [Pkg-nagios-devel] Bug#710356: Fix for wheezy?

[Jonas Meurer]

Hello,

Am 2013-11-04 10:10, schrieb Jasir Baftijari:

Hello, i'm waiting for wheezy, too.

 Please Upload the fix to wheezy asap.


Hopefully this bug will be fixed through an upload to wheezy-updates 
within the next days. I'm awaiting the approval of debian-release for 
the upload at the moment.


Kind regards,
 jonas


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

Bug#710356: Duplicate bugreports, please include in next stable update

[Jonas Meurer]

Hello,

I believe that bugs #701084 and #710356 are duplicates. In other words, 
#710356 should be closed now that nagios3 3.4.1-4 was uploaded :)


And I would suggest to incorporate the patch into prospective uploads to 
stable-security and/or oldstable-security. It's a very nasty bug with an 
easy fix. The patch is unlikely to break anything else.


Kind regards,
 jonas


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

Bug#714210: DRBD 8.3 userland incompatible with 8.4 kernel modules

[Jonas Meurer]

Package: drbd8-utils
Version: 2:8.3.13-2
Severity: grave

Hello,

as the subject already mentions, DRBD 8.3 userland in jessie/testing is
incompatible with DRBD 8.4 kernel modules from the 3.9 linux package.
DRBD kernel modules are at 8.4 branch in upstream linux kernel since
kernel release 3.8.

Ubuntu already ships DRBD 8.4 userland for this reason within Raring
(13.04).

Please consider to upgrade DRBD userland to 8.4. For now DRBD is
unusable in Debian sid/unstable and jessie/testing.

Kind regards,
 jonas

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash


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

Bug#656552: zope2.12-sandbox: fails to upgrade from testing

[Jonas Meurer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey Arnau,

Am 22.11.2012 11:56, schrieb Arnaud Fontaine:
 Ivo De Decker ivo.dedec...@ugent.be writes:
 
 [...]
 In other  words: the package creates  an (empty) zope instance
 in the postinst, but fails to install if  such an instance
 exists. This makes a reinstall fail.
 
 
 It seems the relevant parts of these scripts come from
 zope-debhelper, so this bug probably originates there.
 
 Thank  you so  much  for investigating  this issue.   IMHO,  we can
 set 'zope-common/remove-instance-without-data'  to  remove  by
 default,  as there is no  point at aborting by  default if there is
 no  data. What do you think?

I fully agree with you. Thanks a lot for working on
zope2.12/zope-common packages for wheezy! Your work is much appreciated.

Kind regards,
 jonas


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQsIyaAAoJEFJi5/9JEEn+BEIP/Rs8AY6nGHPVV93w7WMhyUum
aLzHpZvbb8bcNWfKnhqWIWYIF2WMwq18yGsVUknIZiXl8F8Y+7I0lKktQtpzW+EG
RtN5jutC3tr+46qg7JbdQC4844phH39D0c31bsSpV3XF4E6BJ/Vq81qZKDfJRx7a
stH+wg2OSTdBdqHVIYJSqGUh1VnWtN48GMAFN3ssCWwjkn6WC4VsUVhD8tKg+Xls
o9CDqOq36rACUt+Z6oqYrOxmJf7chQVwEc8POzwi5siW61sl2+g2Ci30W0mp3Jf+
r7HzQ/KbIk4GX2kM+ua1IQ8wFyUowoDh6kFAWI8ONSWKQnJ46/cZQsF6ODEsghrd
3D/ssQ9V6rOHFBCzs+xah/BKrZCcApR7j1wuw7VNKn0qNhOh1iKjLaCJfLqyB8Ae
yYvVMmH05eV3XyEg84RaFcoJHMmbO+3QCOxNv2Gad2N56XmVrInXrYtDKI9RM5CF
pE6BXuv6XShWrRT/9FAXhL8YvTpd71j9YvUZoeHbbeP4Ste4w8d4CuQA9Dta/iPS
epKaTacR3Bm00SNlygcAPsFVyg0j58Ng/mX7Bbb5iV/VORE+6Vby5/c+wS68lB5d
mArN+EleXmj1L1Z2j5/rllOl0efukYhha2eW4weoMTPENVtmVWvQJjq/FJNmkjgw
1Vt5VW1WArywtvodkWQ0
=Li+z
-END PGP SIGNATURE-


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

Bug#682416: Bug renders package unusable

[Jonas Meurer]

severity 682416 grave
thanks

Hello,

this bug renders the package smstools mostly unusable for many users. I 
discovered the same bug. I can confirm, that the new upstream 3.1.15 
fixes the bug. 3.1.15 has no changes apart from this fix, thus I suggest 
to push it into wheezy despite the freeze.


Regards,
 jonas


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

Bug#677127: [pkg-cryptsetup-devel] Bug#677127: relocation error

[Jonas Meurer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey Milan,

Am 12.06.2012 17:43, schrieb Milan Broz:
 On 06/11/2012 09:31 PM, p...@spth.de wrote:
 /sbin/crpytsetup: relocation error: /sbin/cryptsetup: symbol 
 crypt_activate_by_key_file_offste, version CRYPTSETUP_1.0 not
 defined in file libcryptsetup.so.4 with link time reference
 
 
 just if it helps: crypt_activate_by_key_file_offset was added in
 1.4.2 libcryptsetup, library is backward compatible but not forward
 compatible of course.
 
 Isn't possible that you have in initramfs old libcryptsetup.4 but 
 new cryptsetup binary? (it should have proper version set, so it
 should be visible even for *.so symlink)

Yup, that might be the problem. I realized that cryptsetup-bin
(2:1.4.3-1) depends on libcryptsetup4 (= 2:1.4). Obviously this
versioned depenency is to lax.

It seems like the symbols file for libcryptsetup4 is broken. It lists
all symbols with a wildcard and gives libcryptsetup4 (= 2:1.4) as
minimum dependency. This is wrong as soon as new symbols are added to
the library without bumping the soname.

Investigating right now and trying to fix ;)

Regards,
 jonas


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP14HNAAoJEFJi5/9JEEn+PS0P/Rmz4oM6OYhn+/3ui9/O/dna
6bKNiKYMsq5p37Gc8ChXSSNkT8AQ44AkbYiowxmgap8F+nQF6vj547KwUbtCqIi6
2iwfiIHal6L/oKCc8r7vbDLZpSYf80Kyrw58+DsSpZuzlIqHAA8lK1gHMKT8g8yU
ABOB+WOdODhow3txDAScibZqZYXM3J12PjuHIKfEjZuJxJTVSZSck1/o8IXCdhiR
X3YdCMLcoBjhYc6nRjjlB3+HbJwt677fIGVv/aWQuogzjmZoQfyHMuU9B1X6kbJB
384zlPM6y2vKWoEKAMp1hqJDS0aKhopqUMLyyK6NW2YrMBjaUwyLksi5h/UNhyJC
wqdQhskXpBgm43Zp4FCKwUWJohc/qwJw/lpWmA124cqEF4oWzB1W6oWpvJLGst0W
XnwZn2xep8w7qLAqeUd90v16YtBSw5izoMt6NrC5hHgJUlJHg9yofxVUiO0sAqyA
icjJzmsHxrYg+uuyPO/pyp+QsGBmLRmyajmHq5uR0BYcf2QuZd5JZ71HtO/hDRmV
26VOiVZE5Vp2klhiasQZKY1gHRIQ8LSUkRVUUoZ1wdLLg7NX/bn5enr10eAzlOpe
bITk2VhRfQa3fiDcUpsS90F7sHIgqOSjRSljnz7cYbrBvqR7zd0j3L/v/PQ4+zk5
9mcnHtIqy1VCciCZsoqG
=5lVz
-END PGP SIGNATURE-



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

Bug#659688: [pkg-cryptsetup-devel] Bug#659688: cryptsetup: LVM on cryptsetup won't boot

[Jonas Meurer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey Roland,

Am 13.02.2012 09:35, schrieb Roland Mas:
 Package: cryptsetup Version: 2:1.4.1-2 Severity: critical

To be honest I don't agree with you on the severity of this bug. I
understand that the changes in LVM handling of cryptroot initramfs
script that I introduced in package version 2:1.4.1-1 may have brokeen
your setup. But on the other hand your setup is very special and
custom and I actually wasn't aware that it had been supported before.

 Note that although this bug was introduced at version 2:1.4.1-1,
 it is different from #659235: my PVs and LVs and VGs don't have
 dashes in their name.
 
 The current sequence: grub loads the kernel and the initramfs; the
  kernel boots; the initramfs looks for the root filesystem but 
 cannot find it because it's not available yet; cryptsetup asks for 
 a passphrase, which I type; cryptsetup: lvm fs found but no lvm 
 configured.  After some time I get dropped into a shell.  In that
  shell, I can see the LVs as inactive, and I enable them with lvm
  lvchange -P -a y vg_mirexpress/root (and ditto for 
 vg_mirexpress/swap), then ^D and the boot sequence starts again 
 normally (it reloads my hibernated system).

Are you confident that the bug didn't exist in 2:1.3.1-3 yet? Actually
the only change in activating LVM volume groups from 2:1.3.1-3 to
2:1.4.1-1 was, that the option --sysinit is given to vgchange now.

Please remove --sysinit option from line 156 of
/usr/share/initramfs-tools/scripts/local-top/cryptroot, update your
initramfs with 'update-initramfs -u' and see whether the problem
disappears.

2:1.4.1-1 introduced much more changes in the initramfs cryptroot hook
than in the initramfs cryptroot script. Maybe these changes introduced
the bug you reported. Any messages given by 'update-initramfs -u'
would be helpful to identify possible problems here.

 It's possible that the problem comes from the need for -P 
 (--partial) in the commands I quote: as may be found in the 
 configuration snippets below, the LUKS key to one of the PVs used 
 in LVM is stored on the filesystem on another LV of the same VG; 
 this means that the first activation of the VG needs to be done 
 with the -P/--partial flag, so the available LVs (including root) 
 are activated and the boot sequence may proceed.

Regards,
 jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPOZa9AAoJEFJi5/9JEEn+nWsQAI5M2V6A4tJPxuanMfedggZq
ZE6dvN6SBFUsQbCUKjHzVo4bGnPk4mhwYhsfdCOXzjBEvhfxfIYdwC62W92lm5fM
FJnFypnFKbQE6HnRHruDsKt5+is2KqYEcdIkeFpiuA+TXdEw9TE59oOgrSfOt3d2
SugWL7EleUvM+Ez0Sd9zLr8YyXAonh5v2hkDOPaLRMVra8rjtBzyT6sYbioGH4S6
VZX8buhWp7PiP6ziEkmAMgDp504Is1sK4semHfRtcHblu5Tgdv6sQmBzPUMqFcvL
tTlKBf08qzEVjunWX2RsCkyDMx1px6j32qgOezj1/vS3Pk/8bcp2dUbdrrkUjyYp
WITrsKLDtff1XIRXZ5ysQLl3f3SOqIMUPRORoa3a9N1dDdO5wOwYdK7PTsVQw9XG
LNLsECWftL6k9tTM7ruZZ3gp69dQXJQkoLdIlpROc4gUkHnCx7QawUUOwkH2JME4
hOY53YbNQP/z/iUihqT/YNnd+L/3NXDg+tNQNz94nH0irmMDfyq7KhEc0C4Jlfbe
FBQ8dmuBZ/pPBAxRsefrBKZkv2H/njqbLGrb6vn12ZVijz0x8RH8oO9ddIdF2CH7
hfK+U0F8X3gChz0yj7cOqhe62xjXRR6zJ0wsrSI8VZSKXnLGlaRg7eNBTW7JiLxV
WEAiZ+IflQtz+XnNA8hl
=dzpd
-END PGP SIGNATURE-



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

Bug#659182: [pkg-cryptsetup-devel] Bug#659182: dangling .so symlink

[Jonas Meurer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 12.02.2012 11:15, schrieb Michael Biebl:
 Hi Jonas,
 
 On 12.02.2012 00:29, Jonas Meurer wrote:
 Am 11.02.2012 04:54, schrieb Michael Biebl:
 If I should delay or cancel the NMU, please let me know.
 
 sorry for not replying earlier. I'll try to upload a fixed
 package tomorrow myself. Please cancel the NMU. Reason is that I
 invented another RC bug with 2:1.4.1-1 and would like to fix that
 one with the upload as well. It needs some testing first though.
 
 If you upload 2:1.4.1-2 before my NMU hits the archive, my NMU
 will automatically be rejected. No harm done. If you take more time
 to upload your package, my NMU will make it possible to rebuild the
 reverse dependencies so packages in unstable are installable
 again.
 
 Apparently you are ok with the technical solution for the fix, so I
 see no harm in letting the NMU just proceed?

You're right. Thanks for the hints.

Regards,
 jonas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPN7iAAAoJEFJi5/9JEEn+W1EP/3IkWBB2FTO/ucgfHICJ9g4i
nVNTtpH3z7/8Spwi4th97GzNWorl9lQU8WeCTihXoM+hg9X6RAkgymg82UH48JxY
GuLZ8S1zABR9E+GNXWgP8qHVJwWsU4PyiZQKDhVDfOhekLBlAQaQnU8ipkvW71jb
AvRn5nCD9gKESc15nMvl7pvwN9TWoWibW0mUMU/tnIDe/qZksVM0+6bAmjg65gMv
xkISmwGPhv5uql5o5oJa2qlCrrPVA0u5mWY9O9IRlJQdzYmzxUoCB+q2ranWJbJD
ySja91cvExH1yTYj4TKp4iAmI/tdSIwj3JRoHOO6N65D63Iy7dtY1Dea1+ygXVUp
BNpu5eHZe4TInfRJu/6nUohv/UhY0VPLnpVkLYBLaNOsAWLdSegh6qXEI0/VQp6N
eYZVizOYgj2T6uRFq7G8QGoZDHw0RnSlzX3kN+Zn5ybyDaxiNFqMRPyQ3rX+isRW
X7Bs5Pz98EoK7vgmHAZZw0fIyMEwoCPDxXccpd3nVGm5tOR5+hgofhrGM1hhdbRx
p6xf0IYOVvt7Y+7jZwk7HHa1FuMMRcoDVMQ4ksz8I8yidPqeIAy4Hida4g76HLfl
VFUB1522KMq+sacJry9Bghe7b/nnmY2JyqFH9LOkIPIC19N/+Oit/Is+DUsOQNlx
2vswcJPopSoHIqr2goW9
=9Kyw
-END PGP SIGNATURE-



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

Bug#659182: [pkg-cryptsetup-devel] Bug#659182: dangling .so symlink

[Jonas Meurer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey Michael,

Am 11.02.2012 04:54, schrieb Michael Biebl:
 tags 659182 + patch pending thanks
 
 Hi,
 
 as I haven't gotten a reply so far and seen no updates in the pkg
 svn, I've prepared a fix and uploaded to DELAYED/2. debdiff is
 attached.
 
 Please consider applying this patch in your next upload.
 
 If I should delay or cancel the NMU, please let me know.

sorry for not replying earlier. I'll try to upload a fixed package
tomorrow myself. Please cancel the NMU. Reason is that I invented
another RC bug with 2:1.4.1-1 and would like to fix that one with the
upload as well. It needs some testing first though.

Thanks for the patch, it's much better than my fix in the SVN
repository. I'll use it.

Regards,
 jonas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPNvnhAAoJEFJi5/9JEEn+Iu0QAIVGrVCqLzFrQDZuC7MCh0Tw
dJFlrAoPdxzAf0ktnQGzbjGRgfmVTzDrpSqRoGlM8O0KXf8XG39Y16S+ctPreo7a
Acp3bHvgCnYcOznVGRlF4aW4XzOZCFkUpD9Ons3/Pfm0iCkw67kzzG9Hmfe4uRG8
WqMBZzy5InLoD+EZDz6m3Sz1xKi3U7/YIMMM6J2+AuMFp/wt18PQD3cT2JeVSii5
BJcPaC3kK3/JW5ST5VyjhCQz8/Bx8HdJihx4eMffuh/+POHhdULZGyxPRVRd4ccg
cODASEyciZ2NtmwO++roUdvUXgrovhYPSz18Rp/Qv63Nlrp00nnUT+41N7hh2gUU
Uk7OIOwFvU1IIu8YA5XlJMX8n1HMPhyffs79ghrd+d5WumOkPqBoJY4/2fE0nSQE
0WHY4MbzPXN6lVIIGLcj/q2QID2fuF8izawQ4Moa1yzTleb3kIdzt1P+3uIfy4qi
kLH6Oj6oGQpA2BAlJWEVeEJBPR53MzTlJS4cysf/kZnzg0zqcTfFhcLFDx7iVz+B
Et+bKoANJ4bU8WaEvNt9sOxMEgzQbi6q/7enopdcOTGcHCrF2APnPY1n9VKHzCUe
7FQyKMSvchKtIrEcX8IRL/n6HB+MGfQPuragGTlYnPdqV9Njsw1Q6di+JG0HsA/Z
fVP0jGGgQfpN6RTsyU3G
=f45S
-END PGP SIGNATURE-



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

Bug#626711: convirt fails to start (config file missing)

[Jonas Meurer]

Package: convirt
Version: 2.0.1-5
Severity: grave

Hello,

Seems like convirt is missing the configuration file. /etc/convirt is
not created at installation time.
/usr/share/convirt/src/convirt/web/convirt/development.ini is a dangling
to /etc/convirt/development.ini.

For that reason, the daemon fails to start:

# /etc/init.d/convirt start
Starting Convirt:
PID file is /var/run/convirt/paster.pid
No virtualenv found, will try to use TG2 installed in the system
Log file: /var/log/convirt/paster.log

grep: /usr/share/convirt/src/convirt/web/convirt/development.ini: No such file 
or directory
 has no value.
/root/.ssh/id_rsa does not exist. Setting it to /root/.ssh/id_rsa.
/root/.ssh/id_rsa not found, Key based Authentication will not be used.
Starting ConVirt using virtualenv : 
Default character encoding is utf-8
Error starting ConVirt. Please consult /var/log/convirt/paster.log for more 
details.

Greetings,
 jonas

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

Kernel: Linux 2.6.38-1-amd64-resivo (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages convirt depends on:
ii  dbconfig-common 1.8.47   common framework for packaging dat
ii  debconf [debconf-2.0]   1.5.39   Debian configuration management sy
ii  dnsmasq 2.57-1   A small caching DNS proxy and DHCP
ii  expect  5.44.1.15-4  A program that can automate intera
ii  libjs-jquery1.5.1-1  JavaScript library for dynamic web
ii  libjs-mochikit  1.4.2-3  JavaScript library inspired by Pyt
ii  libmysqlclient-dev  5.1.56-1 MySQL database development files
ii  libxenstore3.0  4.1.0-3  Xenstore communications library fo
ii  python  2.6.6-14 interactive high-level object-orie
ii  python-babel0.9.6-1  tools for internationalizing Pytho
ii  python-beaker   1.5.4-4  cache and session library
ii  python-mysqldb  1.2.2-10+b3  A Python interface to MySQL
ii  python-paramiko 1.7.6-6  Make ssh v2 connections with Pytho
ii  python-paste1.7.5.1-1tools for using a Web Server Gatew
ii  python-setuptools   0.6.15-2 Python Distutils Enhancements (set
ii  python-support  1.0.13   automated rebuilding support for P
ii  python-turbogears2  2.0.3-2  Python web application framework
ii  python-zope.sqlalchemy  0.4-7Minimal Zope/SQLAlchemy transactio
ii  socat   1.7.1.3-1multipurpose relay for bidirection
ii  ssh 1:5.8p1-4secure shell client and server (me
ii  uml-utilities   20070815-1.1 User-mode Linux (utility programs)
ii  wget1.12-3.1 retrieves files from the web

Versions of packages convirt recommends:
ii  mysql-client-5.1 [mysql-clien 5.1.56-1   MySQL database client binaries
ii  mysql-server-5.1 [mysql-serve 5.1.56-1   MySQL database server binaries and

convirt suggests no packages.

-- Configuration Files:
/etc/default/convirt changed [not included]

-- debconf information:
  convirt/internal/reconfiguring: false
* convirt/mysql/method: unix socket
  convirt/passwords-do-not-match:
  convirt/missing-db-package-error: abort
  convirt/dbconfig-reinstall: false
* convirt/dbconfig-install: true
  convirt/dbconfig-upgrade: true
  convirt/upgrade-error: abort
* convirt/mysql/admin-user: root
  convirt/remove-error: abort
  convirt/install-error: abort
  convirt/dbconfig-remove:
  convirt/purge: false
* convirt/db/app-user: convirt
  convirt/upgrade-backup: true
  convirt/database-type: mysql
  convirt/internal/skip-preseed: true
  convirt/remote/port:
* convirt/db/dbname: convirt
  convirt/remote/host:
  convirt/remote/newhost:


signature.asc
Description: Digital signature

Bug#626715: convirt fails to start (sqlalchemy.exc.ArgumentError)

[Jonas Meurer]

Package: convirt
Version: 2.0.1-5
Severity: grave

Hey again,

after I copied development.ini from the convirt source package to
/etc/convirt/, convirt dies with another error:

# /etc/init.d/convirt start
Starting Convirt:
PID file is /var/run/convirt/paster.pid
No virtualenv found, will try to use TG2 installed in the system
Log file: /var/log/convirt/paster.log

 
Using  /var/lib/convirt/identity/cms_id_rsa
Agent pid 14803
Identity added: /var/lib/convirt/identity/cms_id_rsa 
(/var/lib/convirt/identity/cms_id_rsa)
ssh key added to agent.
Starting ConVirt using virtualenv : 
Default character encoding is utf-8
Error starting ConVirt. Please consult /var/log/convirt/paster.log for more 
details.


and /var/log/convirt/paster.log contains the following:

/usr/lib/pymodules/python2.6/tw/core/view.py:223: DeprecationWarning: 
object.__new__() takes no parameters
  obj = object.__new__(cls, *args, **kw)
Traceback (most recent call last):
  File /usr/bin/paster, line 18, in module
command.run()
  File /usr/lib/pymodules/python2.6/paste/script/command.py, line 84, in run
invoke(command, command_name, options, args[1:])
  File /usr/lib/pymodules/python2.6/paste/script/command.py, line 123, in 
invoke
exit_code = runner.run(args)
  File /usr/lib/pymodules/python2.6/paste/script/command.py, line 218, in run
result = self.command()
  File /usr/lib/pymodules/python2.6/paste/script/serve.py, line 276, in 
command
relative_to=base, global_conf=vars)
  File /usr/lib/pymodules/python2.6/paste/script/serve.py, line 313, in 
loadapp
**kw)
  File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 204, in 
loadapp
return loadobj(APP, uri, name=name, **kw)
  File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 224, in 
loadobj
global_conf=global_conf)
  File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 248, in 
loadcontext
global_conf=global_conf)
  File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 278, in 
_loadconfig
return loader.get_context(object_type, name, global_conf)
  File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 409, in 
get_context
section)
  File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 431, in 
_context_from_use
object_type, name=use, global_conf=global_conf)
  File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 361, in 
get_context
global_conf=global_conf)
  File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 248, in 
loadcontext
global_conf=global_conf)
  File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 285, in 
_loadegg
return loader.get_context(object_type, name, global_conf)
  File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 561, in 
get_context
object_type, name=name)
  File /usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py, line 587, in 
find_egg_entry_point
possible.append((entry.load(), protocol, entry.name))
  File /usr/lib/python2.6/dist-packages/pkg_resources.py, line 1954, in load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File 
/usr/share/convirt/src/convirt/web/convirt/convirt/config/middleware.py, line 
4, in module
from convirt.config.app_cfg import base_config
  File /usr/share/convirt/src/convirt/web/convirt/convirt/config/app_cfg.py, 
line 19, in module
from convirt import model
  File /usr/share/convirt/src/convirt/web/convirt/convirt/model/__init__.py, 
line 78, in module
from convirt.core.platforms.kvm.KVMNode import KVMNode
  File 
/usr/share/convirt/src/convirt/web/convirt/convirt/core/platforms/kvm/KVMNode.py,
 line 48, in module
class KVMNode(VNode):
  File /usr/lib/python2.6/dist-packages/sqlalchemy/ext/declarative.py, line 
1175, in __init__
_as_declarative(cls, classname, cls.__dict__)
  File /usr/lib/python2.6/dist-packages/sqlalchemy/ext/declarative.py, line 
1128, in _as_declarative
(c, cls, inherited_table.c[c.name])
sqlalchemy.exc.ArgumentError: Column 'migration_port' on class class 
'convirt.core.platforms.kvm.KVMNode.KVMNode' conflicts with existing column 
'managed_nodes.migration_port'
Removing PID file /var/run/convirt/paster.pid

Greetings,
 jonas

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

Kernel: Linux 2.6.38-1-amd64-resivo (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages convirt depends on:
ii  dbconfig-common 1.8.47   common framework for packaging dat
ii  debconf [debconf-2.0]   1.5.39   Debian configuration management sy
ii  dnsmasq 2.57-1   A small caching DNS proxy and DHCP
ii  expect  5.44.1.15-4  A program that can automate intera
ii  libjs-jquery1.5.1-1  JavaScript library for dynamic web
ii  libjs-mochikit   

Bug#626294: segmentation fault at opening imap folder

[Jonas Meurer]

Package: mutt
Version: 1.5.21-5
Severity: grave

Hello,

Since the upgrade to mutt 1.5.21-5, mutt occasionally crashes with a
segmentation fault at opening a IMAP maildir folder. It doesn't matter,
which IMAP folder is opened. I didn't discover this bug with mutt
1.5.21-4, with the exactly same configuration and IMAP server.

The IMAP server in question is a Courier IMAP SSL 4.4.0-2 on
debian/lenny.

The output of a strace of the segmentation fault is attached to this
mail.

Greetings,
 jonas

-- Package-specific info:
Mutt 1.5.21 (2010-09-15)
Copyright (C) 1996-2009 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 2.6.38-1-amd64-resivo (x86_64)
ncurses: ncurses 5.9.20110404 (compiled with 5.9)
libidn: 1.20 (compiled with 1.20)
hcache backend: tokyocabinet 1.4.37
Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +COMPRESSED  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET 
 +HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  +HAVE_GETSID  +USE_HCACHE  
-ISPELL
SENDMAIL=/usr/sbin/sendmail
MAILPATH=/var/mail
PKGDATADIR=/usr/share/mutt
SYSCONFDIR=/etc
EXECSHELL=/bin/sh
MIXMASTER=mixmaster
To contact the developers, please mail to mutt-...@mutt.org.
To report a bug, please visit http://bugs.mutt.org/.

misc/am-maintainer-mode
features/ifdef
features/xtitles
features/trash-folder
features/purge-message
features/imap_fast_trash
features/sensible_browser_position
features-old/patch-1.5.4.vk.pgp_verbose_mime
features/compressed-folders
features/compressed-folders.debian
debian-specific/Muttrc
debian-specific/Md.etc_mailname_gethostbyname.diff
debian-specific/use_usr_bin_editor.diff
debian-specific/correct_docdir_in_man_page.diff
debian-specific/dont_document_not_present_features.diff
debian-specific/document_debian_defaults
debian-specific/assumed_charset-compat
debian-specific/467432-write_bcc.patch
debian-specific/566076-build_doc_adjustments.patch
misc/define-pgp_getkeys_command.diff
misc/gpg.rc-paths
misc/smime.rc
upstream/531430-imapuser.patch
upstream/537818-emptycharset.patch
upstream/543467-thread-segfault.patch
upstream/542817-smimekeys-tmpdir.patch
upstream/548577-gpgme-1.2.patch
upstream/553321-ansi-escape-segfault.patch
upstream/568295-references.patch
upstream/547980-smime_keys-chaining.patch
upstream/528233-readonly-open.patch
upstream/228671-pipe-mime.patch
upstream/383769-score-match.patch
upstream/578087-header-strchr.patch
upstream/603288-split-fetches.patch
upstream/537061-dont-recode-saved-attachments.patch
upstream/608706-fix-spelling-errors.patch
upstream/620854-pop3-segfault.patch
upstream/611412-bts-regexp.patch
upstream/624058-gnutls-deprecated-set-priority.patch
upstream/624085-gnutls-deprecated-verify-peers.patch
upstream/584138-mx_update_context-segfault.patch
upstream/619216-gnutls-CN-validation.patch
upstream/611410-no-implicit_autoview-for-text-html.patch
upstream/path_max
mutt.org

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

Kernel: Linux 2.6.38-1-amd64-resivo (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mutt depends on:
ii  libc6 2.13-2 Embedded GNU C Library: Shared lib
ii  libcomerr21.41.12-4  common error description library
ii  libgnutls26   2.10.5-1+b1the GNU TLS library - runtime libr
ii  libgpg-error0 1.10-0.3   library for common error values an
ii  libgpgme111.2.0-1.3  GPGME - GnuPG Made Easy
ii  libgssapi-krb5-2  1.9+dfsg-1+b1  MIT Kerberos runtime libraries - k
ii  libidn11  1.20-1 GNU Libidn library, implementation
ii  libk5crypto3  1.9+dfsg-1+b1  MIT Kerberos runtime libraries - C
ii  libkrb5-3 1.9+dfsg-1+b1  MIT Kerberos runtime libraries
ii  libncursesw5  5.9-1  shared libraries for terminal hand
ii  libsasl2-22.1.23.dfsg1-8 Cyrus SASL - authentication abstra
ii  libtokyocabinet8  1.4.37-6.1 Tokyo Cabinet Database Libraries [

Versions of packages mutt recommends:
ii  exim4-daemon-light [mail- 4.76-1 lightweight Exim MTA (v4) daemon
ii  libsasl2-modules  2.1.23.dfsg1-8 Cyrus SASL - pluggable authenticat
ii  locales   

Bug#554506: (ugly) patch which should fix dm-crypt-on-lvm setups

[Jonas Meurer]

Hey Alasdair,

thanks for your comments.

On 04/11/2010 Alasdair G Kergon wrote:
 If the complex processing doesn't work for everyone then yes, simplify
 it and activate everything always.
 
 To do it the other way you need logic something like:
Every time you boot, check if the stack of devices necessary to be
 activated has changed, and if so, update the information for use next
 time it boots.
At boot time, try the last stack known to work first.  If it doesn't
 work, try any other different saved stacks from earlier boots.  If none
 of them work then fall back to activating everything.
 
 In other words make the initramfs code robust enough to cope with
 the unexpected!

I now changed the initramfs code to always activate all volume groups:
both before cryptsetup in case the source device is not available, and
after cryptsetup in case the unlocked device contains lvm data.

this way, the complicated and error-prone volume group -guessing code is
not needed anymore.

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#554506: (ugly) patch which should fix dm-crypt-on-lvm setups

[Jonas Meurer]

Hey Christoph,

On 04/11/2010 Christoph Anton Mitterer wrote:
 I haven't fully looked at this so perhaps it's unrelated,...
 
 But one main problem I see here (that may be related), is that lvm's
 init-scripts are simply wrong, and abusing some things.
 I've already told Bastian this and there are even several bugs open.
 
 The problem is that lvm's init script simply doesn't to an lvchange -ay
 but try to detect the LV holding root.
 And it does this in a wrong way by using the root= kernel param (which
 is the final device, containing the root-fs)
 
 Most lvm/dm-crypt realted I've seen were simply solvable by letting the
 lvm initscript just do an lvchange -ay (thereby making all LVs
 available) and then using dmcrypt/cryptsetup as normal.

while this bug is not related to init scripts at all, your suggestions
makes a lot of sense to me. after all, i don't see a reason to detect
the volume group with complicated dmsetup, sed and lvdisplay invokations
instead of just activating all volume groups globally in the initramfs.

attached patch removes any vg-guessing magic from the initramfs
cryptroot script, just invoking 'lvm vgchange -ay' instead.

thanks for the comment, Christoph!

greetings,
 jonas
--- /usr/share/initramfs-tools/scripts/local-top/cryptroot.orig
+++ /usr/share/initramfs-tools/scripts/local-top/cryptroot
@@ -141,46 +141,31 @@
 
 activate_vg()
 {
-	local vg
-	vg=${1#/dev/mapper/}
-
 	# Sanity checks
 	if [ ! -x /sbin/lvm ]; then
 		message cryptsetup: lvm is not available
 		return 1
- 	elif [ $vg = $1 ]; then
-		message cryptsetup: lvm device name ($vg) does not begin with /dev/mapper/
-		return 1
 	fi
 
-	# Make sure that the device contains at least one dash
-	if [ ${vg%%-*} = $vg ]; then
-		message cryptsetup: lvm device name ($vg) does not contain a dash
+	# Detect available volume groups
+	vgs=$(lvm vgs --noheadings -o vg_name | sed -e s/^[ \t]*\(.*\)[ \t]*$/\1/g)
+	if [ -z $vgs ]; then
+		message cryptsetup: no lvm volume groups found
 		return 1
 	fi
 
-	# Split volume group from logical volume.
-	vg=$(echo ${vg} | sed -e 's#\(.*\)\([^-]\)-[^-].*#\1\2#')
-
-	# Reduce padded --'s to -'s
-	vg=$(echo ${vg} | sed -e 's#--#-#g')
-
-	lvm vgchange -ay ${vg}
+	lvm vgchange -ay
 	return $?
 }
 
 activate_evms()
 {
 	local dev module
-	dev=${1#/dev/evms/}
 
 	# Sanity checks
 	if [ ! -x /sbin/evms_activate ]; then
 		message cryptsetup: evms_activate is not available
 		return 1
-	elif [ $dev = $1 ]; then
-		message cryptsetup: evms device name ($vg) does not begin with /dev/evms/
-		return 1
 	fi
 
 	# Load modules used by evms
@@ -219,8 +204,8 @@
 
 	# Make sure the cryptsource device is available
 	if [ ! -e $cryptsource ]; then
-		activate_vg $cryptsource
-		activate_evms $cryptsource
+		activate_vg
+		activate_evms
 	fi
 
 	# If the encrypted source device hasn't shown up yet, give it a
@@ -320,7 +305,7 @@
 			if [ -z $cryptlvm ]; then
 message cryptsetup: lvm fs found but no lvm configured
 return 1
-			elif ! activate_vg /dev/mapper/$cryptlvm; then
+			elif ! activate_vg; then
 # disable error message, LP: #151532
 #message cryptsetup: failed to setup lvm device
 return 1


signature.asc
Description: Digital signature

Bug#554506: (ugly) patch which should fix dm-crypt-on-lvm setups

[Jonas Meurer]

Hey Christoph,

On 04/11/2010 Christoph Anton Mitterer wrote:
 I haven't fully looked at this so perhaps it's unrelated,...
 
 But one main problem I see here (that may be related), is that lvm's
 init-scripts are simply wrong, and abusing some things.
 I've already told Bastian this and there are even several bugs open.
 
 The problem is that lvm's init script simply doesn't to an lvchange -ay
 but try to detect the LV holding root.
 And it does this in a wrong way by using the root= kernel param (which
 is the final device, containing the root-fs)
 
 Most lvm/dm-crypt realted I've seen were simply solvable by letting the
 lvm initscript just do an lvchange -ay (thereby making all LVs
 available) and then using dmcrypt/cryptsetup as normal.

while this bug is not related to init scripts at all, your suggestions
makes a lot of sense to me. after all, i don't see a reason to detect
the volume group with complicated dmsetup, sed and lvdisplay invokations
instead of just activating all volume groups globally in the initramfs.

attached patch removes any vg-guessing magic from the initramfs
cryptroot script, just invoking 'lvm vgchange -ay' instead.

thanks for the comment, Christoph!

greetings,
 jonas
--- /usr/share/initramfs-tools/scripts/local-top/cryptroot.orig
+++ /usr/share/initramfs-tools/scripts/local-top/cryptroot
@@ -141,46 +141,31 @@
 
 activate_vg()
 {
-	local vg
-	vg=${1#/dev/mapper/}
-
 	# Sanity checks
 	if [ ! -x /sbin/lvm ]; then
 		message cryptsetup: lvm is not available
 		return 1
- 	elif [ $vg = $1 ]; then
-		message cryptsetup: lvm device name ($vg) does not begin with /dev/mapper/
-		return 1
 	fi
 
-	# Make sure that the device contains at least one dash
-	if [ ${vg%%-*} = $vg ]; then
-		message cryptsetup: lvm device name ($vg) does not contain a dash
+	# Detect available volume groups
+	vgs=$(lvm vgs --noheadings -o vg_name | sed -e s/^[ \t]*\(.*\)[ \t]*$/\1/g)
+	if [ -z $vgs ]; then
+		message cryptsetup: no lvm volume groups found
 		return 1
 	fi
 
-	# Split volume group from logical volume.
-	vg=$(echo ${vg} | sed -e 's#\(.*\)\([^-]\)-[^-].*#\1\2#')
-
-	# Reduce padded --'s to -'s
-	vg=$(echo ${vg} | sed -e 's#--#-#g')
-
-	lvm vgchange -ay ${vg}
+	lvm vgchange -ay
 	return $?
 }
 
 activate_evms()
 {
 	local dev module
-	dev=${1#/dev/evms/}
 
 	# Sanity checks
 	if [ ! -x /sbin/evms_activate ]; then
 		message cryptsetup: evms_activate is not available
 		return 1
-	elif [ $dev = $1 ]; then
-		message cryptsetup: evms device name ($vg) does not begin with /dev/evms/
-		return 1
 	fi
 
 	# Load modules used by evms
@@ -219,8 +204,8 @@
 
 	# Make sure the cryptsource device is available
 	if [ ! -e $cryptsource ]; then
-		activate_vg $cryptsource
-		activate_evms $cryptsource
+		activate_vg
+		activate_evms
 	fi
 
 	# If the encrypted source device hasn't shown up yet, give it a
@@ -320,7 +305,7 @@
 			if [ -z $cryptlvm ]; then
 message cryptsetup: lvm fs found but no lvm configured
 return 1
-			elif ! activate_vg /dev/mapper/$cryptlvm; then
+			elif ! activate_vg; then
 # disable error message, LP: #151532
 #message cryptsetup: failed to setup lvm device
 return 1


signature.asc
Description: Digital signature

Bug#554506: (ugly) patch which should fix dm-crypt-on-lvm setups

[Jonas Meurer]

Hello,

Again I tried to work on this bugreport. I'm absolutely sure that
different bugs are spotted. Most people are hitting the following bug:

the debian-installer was changed to configure devices in fstab and
crypttab in the 'UUID=...' style some time ago. this works for most
systems, with the exception of 'dm-crypt on lvm' setups, where the
encrypted devices are on top of lvm.
the reason is, that the cryptroot initramfs script tries to determine
the volume group from the source device string if the source device is
not available at boot. in the past that was possible for source devices
like '/dev/mapper/vg01-root_crypt'. the lvm volume group is 'vg01'.
for source devices specified as 'UUID=...' this is not possible any
longer.

the only fix i can see, is make the cryptroot initramfs hook determine
the underlying lvm volume group (if any) at mkinitramfs time, and write
the name of the volume group to /conf/conf.d/cryptroot. this information
can be used by the initramfs script at boot time in order to activate
the volume group before trying to unlock the encrypted (logical volume)
device.

i now prepared some ugly patches against cryptroot-hook and
cryptroot-script, that implement what I described above.

the implementation is still very ugly but on my test systems it works.

please give the attached patches a try and see whether they finally fix
the issue for you.
even better would be suggestions on how to improve the implementations,
i.e. provide a more elegant solution.

comments #15, #40, #45, #82, #87, #113, #118 and #123 are about
different issues, which aren't related to this bug.

greetings,
 jonas
--- /usr/share/initramfs-tools/hooks/cryptroot.orig
+++ /usr/share/initramfs-tools/hooks/cryptroot
@@ -230,6 +230,9 @@
 			lvm=*)
 OPTIONS=$OPTIONS,$opt
 ;;
+			lvm_vg=*)
+OPTIONS=$OPTIONS,$opt
+;;
 			keyscript=*)
 opt=${opt#keyscript=}
 if [ ! -x /lib/cryptsetup/scripts/$opt ]  [ ! -x $opt ]; then
@@ -338,7 +341,7 @@
 }
 
 add_device() {
-	local node nodes opts lastopts i count
+	local node nodes node_deps node_maj node_min node_depnode node_vg opts lastopts i count
 	nodes=$1
 	opts= # Applied to all nodes
 	lastopts= # Applied to last node
@@ -374,6 +377,18 @@
 		nodes=$lvmnodes
 	fi
 
+	# Check for dm-crypt on lvm
+	node_deps=$(dmsetup deps $nodes 2/dev/null | sed 's/[^:]*: *//;s/[ (]//g;s/)/ /g')
+	if [ -n $node_deps ]; then
+		node_maj=$(echo ${node_deps%,*} | sed -e s/^[ \t]*//g)
+		node_min=$(echo ${node_deps#*,} | sed -e s/[ \t]*$//g)
+		node_depnode=$(dmsetup ls | sed -n s/\\([^ ]*\\) *($node_maj, $node_min)/\\1/p | sed -e s/[ \t]*$//)
+		node_vg=$(lvdisplay /dev/mapper/$node_depnode 2/dev/null | sed -r -e s|^ +VG Name +([^ ]+) *$|\1|;tx;d;:x)
+		if [ -n $node_vg ]; then
+			lastopts=lvm_vg=$node_vg
+		fi
+	fi
+
 	# Prepare to setup each node
 	count=$(echo $nodes | wc -w)
 	i=1
--- /usr/share/initramfs-tools/scripts/local-top/cryptroot.orig
+++ /usr/share/initramfs-tools/scripts/local-top/cryptroot
@@ -100,6 +100,9 @@
 		lvm=*)
 			cryptlvm=${x#lvm=}
 			;;
+		lvm_vg=*)
+			cryptlvm_vg=${x#lvm_vg=}
+			;;
 		keyscript=*)
 			cryptkeyscript=${x#keyscript=}
 			;;
@@ -142,28 +145,32 @@
 activate_vg()
 {
 	local vg
-	vg=${1#/dev/mapper/}
-
-	# Sanity checks
-	if [ ! -x /sbin/lvm ]; then
-		message cryptsetup: lvm is not available
-		return 1
- 	elif [ $vg = $1 ]; then
-		message cryptsetup: lvm device name ($vg) does not begin with /dev/mapper/
-		return 1
-	fi
+	if [ -n $cryptlvm_vg ]; then
+		vg=$cryptlvm_vg
+	else
+		vg=${1#/dev/mapper/}
+
+		# Sanity checks
+		if [ ! -x /sbin/lvm ]; then
+			message cryptsetup: lvm is not available
+			return 1
+	 	elif [ $vg = $1 ]; then
+			message cryptsetup: lvm device name ($vg) does not begin with /dev/mapper/
+			return 1
+		fi
 
-	# Make sure that the device contains at least one dash
-	if [ ${vg%%-*} = $vg ]; then
-		message cryptsetup: lvm device name ($vg) does not contain a dash
-		return 1
-	fi
+		# Make sure that the device contains at least one dash
+		if [ ${vg%%-*} = $vg ]; then
+			message cryptsetup: lvm device name ($vg) does not contain a dash
+			return 1
+		fi
 
-	# Split volume group from logical volume.
-	vg=$(echo ${vg} | sed -e 's#\(.*\)\([^-]\)-[^-].*#\1\2#')
+		# Split volume group from logical volume.
+		vg=$(echo ${vg} | sed -e 's#\(.*\)\([^-]\)-[^-].*#\1\2#')
 
-	# Reduce padded --'s to -'s
-	vg=$(echo ${vg} | sed -e 's#--#-#g')
+		# Reduce padded --'s to -'s
+		vg=$(echo ${vg} | sed -e 's#--#-#g')
+	fi
 
 	lvm vgchange -ay ${vg}
 	return $?


signature.asc
Description: Digital signature

Bug#586120: [pkg-cryptsetup-devel] Bug#586120: device-mapper: reload ioctl failed: Invalid argument

[Jonas Meurer]

Hey Clayton,

On 28/06/2010 Clayton wrote:
 On Sun, 27 Jun 2010 11:35:31 +0200
 Jonas Meurer jo...@freesources.org wrote:
 
  On 27/06/2010 Clayton wrote:
   On Sat, 26 Jun 2010 12:32:02 +0200
   Jonas Meurer jo...@freesources.org wrote:
  
  are you sure that this is the case? what does 'blkid /dev/sda' and
  'blkid /dev/sdb' return? for a plain dm-crypt encrypted device, no
  filesystem should be detected.
 
 desktop1:/media# blkid /dev/sdc1
 /dev/sdc1: LABEL=HDEXT115 UUID=8dd61b60-2aeb-4b00-a056-a86223d6e47c
 TYPE=ext3 
 desktop1:/media# blkid /dev/sdc2
 
 desktop1:/media# blkid /dev/sda1
 /dev/sda1: UUID=9fe8865b-d220-468b-b7a4-bf58b16fe562 TYPE=ext3 
 desktop1:/media# blkid /dev/sda2
 /dev/sda2: UUID=4102f17e-4c54-4ae7-bcfe-00fe90391454 TYPE=swap 
 
 So sdc2 is showing no file system, consistent with an encrypted
 device

ok, indeed /dev/sdc2 should be the one containing the encrypted device.

   So now: cryptsetup create backcrypt /dev/sdb2
   works.
  
  this should work for _any_ block device, regardless whether it
  contains encrypted fs or not. thus the success of above command does
  not indicate that /dev/sdb2 is the correct device.
 
 That possibility never occurred to me I am now seeing as well that
 it does not complain about a bad password, either
 
   BUT!!: when I try to mount the partition, this happens:
   
   # mount /media/backcrypt/
   mount: wrong fs type, bad option, bad superblock on /dev/dm-0,
  missing codepage or helper program, or other error
  In some cases useful info is found in syslog - try
  dmesg | tail  or so
  
  what does 'blkid /dev/mapper/backcrypt' return?
 
 # blkid /dev/mapper/backcrypt
 /dev/mapper/backcrypt: UUID=77f77add-7913-459a-bf81-d88b70323ad6
 SEC_TYPE=ext2 TYPE=ext3
 
 and then it gives me the above error message again when I try to mount
 it.

that's strange. what does 'fsck.ext3 /dev/mapper/backcrypt' return?

  the default key size and cipher mode changed for plain dm-crypt in
  cryptsetup package 2:1.1.0-1. it seems like you don't
  use /etc/crypttab at all, where key size and cipher mode can be
  configured.
 
 KISS has meant up until now: don't need crypttab, don't want to mess
 with it. I am guessing that this may be about to change

what is KISS? in my eyes it's better to use crypttab, as you can set
cipher, hash and key size as well as other options there, and the
cryptdisks initscript will unlock the device automatically at boot.

but in the end, it's your decision.

  again, 'cryptsetup create' doesn't fail if either passphrase or
  cipher/ hash/keysize are wrong. thus the only way to verify
  successfull setup is to check the content of unlocked device.
  
  try the following (these where the old defaults for cryptsetup before
  1.1.0):
  
  # cryptsetup --key-size 128 --cipher aes-cbc-plain create
  backcrypt /dev/sdb2
  and see what 'blkid /dev/mapper/backcrypt' returns in that case.
 
 Well, this is interesting, I too was expecting this to work but it did
 not:
 
 cryptsetup --key-size 128 --cipher aes-cbc-plain create
 backcrypt /dev/sdc2
 
 mount still fails in the same way, and now
 
 # blkid /dev/mapper/backcrypt
 outputs exactly nothing.
 
 If I remove the device and go back to
 # cryptsetup create backcrypt /dev/sdc2
 
 I then get, again
 # blkid /dev/mapper/backcrypt
 /dev/mapper/backcrypt: UUID=77f77add-7913-459a-bf81-d88b70323ad6
 SEC_TYPE=ext2 TYPE=ext3
 
 and still a broken mount command.
 
 This crypto partition was created several years ago. I wonder if
 creation defaults have changed more then once since then?

which cryptsetup version did you use before the upgrade? take a look at
/var/log/dpkg.log if you're unsure. did you already try to downgrade to
the old cryptsetup version and see, whether it works again?

ah, and i was wrong with the changed defaults. the only change to plain
dm-crypt was the cipher change from aes-cbc-plain to
aes-cbc-essiv:sha256. so you should try this one instead:

# cryptsetup -c aes-cbc-plain create backcrypt /dev/sdc2

 But, if the device has not been truly unlocked because of a crypto
 problem, should blkid be seeing an ext3 file system?

it's strange indeed. maybe your ext3 filesystem is damaged for some
reason?

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#586120: [pkg-cryptsetup-devel] Bug#586120: device-mapper: reload ioctl failed: Invalid argument

[Jonas Meurer]

Hey Clayton,

On 27/06/2010 Clayton wrote:
 On Sat, 26 Jun 2010 12:32:02 +0200
 Jonas Meurer jo...@freesources.org wrote:
 
  On 16/06/2010 clayton wrote:
   # cryptsetup create backcrypt /dev/sda2
   Enter passphrase:
   device-mapper: reload ioctl failed: Invalid argument
  Can you post dmsetup table when this fails?
 
 Hi Jonas,
 
 Sad to say, I think the original symptom I reported may have been due to
 finger problems associated with the recent shuffling of device names.
 The encrypted partition is on USB drive that used to be assigned sda
 when it was plugged in. Now the internal hard drive is assigned sda,
 and the USB drive gets assigned sdb. Not sure how I missed that

are you sure that this is the case? what does 'blkid /dev/sda' and
'blkid /dev/sdb' return? for a plain dm-crypt encrypted device, no
filesystem should be detected.

also you should take a look at /var/log/syslog, and at /dev/disk/by-id/
in order to find out which device is the encrypted partition on external
USB drive.

 So now: cryptsetup create backcrypt /dev/sdb2
 works.

this should work for _any_ block device, regardless whether it contains
encrypted fs or not. thus the success of above command does not indicate
that /dev/sdb2 is the correct device.

 BUT!!: when I try to mount the partition, this happens:
 
 # mount /media/backcrypt/
 mount: wrong fs type, bad option, bad superblock on /dev/dm-0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail  or so
 
 (Nothing at all is showing up in /var/log/messages associated with this
 event)
 
 /etc/fstab contains:
 /dev/mapper/backcrypt  /media/backcrypt  ext3  rw,,user  0 0
 
 # ll /dev/mapper/backcrypt
 lrwxrwxrwx 1 root root 7 Jun 27 11:50 /dev/mapper/backcrypt - ../dm-0
 
 Again, the fstab entry has not changed for years, and this is a monthly
 routine that has worked consistently for years. There is also another,
 unencrypted, ext3 partition on this USB drive that continues to mount
 just fine.

what does 'blkid /dev/mapper/backcrypt' return?

the default key size and cipher mode changed for plain dm-crypt in
cryptsetup package 2:1.1.0-1. it seems like you don't use /etc/crypttab
at all, where key size and cipher mode can be configured.

again, 'cryptsetup create' doesn't fail if either passphrase or cipher/
hash/keysize are wrong. thus the only way to verify successfull setup is
to check the content of unlocked device.

try the following (these where the old defaults for cryptsetup before
1.1.0):

# cryptsetup --key-size 128 --cipher aes-cbc-plain create backcrypt /dev/sdb2

and see what 'blkid /dev/mapper/backcrypt' returns in that case.

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#586120: [pkg-cryptsetup-devel] Bug#586120: device-mapper: reload ioctl failed: Invalid argument

[Jonas Meurer]

hey,

On 16/06/2010 clayton wrote:
 # cryptsetup create backcrypt /dev/sda2
 Enter passphrase:
 device-mapper: reload ioctl failed: Invalid argument

Can you post dmsetup table when this fails?

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#586161: bug#586162 [bash-completion,cryptsetup] decide who should ship completion for cryptsetup

[Jonas Meurer]

hey,

i just removed the bash-comletion file from cryptsetup svn. with the upload
of 2:1.1.2-2, cryptsetup will no longer ship this file. thus i suggest
to add a Conflicts: cryptsetup ( 2:1.1.2-2) to bash-completion in
order to fix bug #586161. i'll upload cryptsetup 2:1.1.2-2 within the
next days.

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#583387: no longer shipping static libraries causes cryptsetup FTBFS

[Jonas Meurer]

Package: libdevmapper-dev
Version: 2:1.02.47-1
Severity: grave

hey,

the most recent upload of lvm2 source package, which removed static
libraries from the lib*-dev packages breaks build process of cryptsetup.

cryptsetup staticly links against libdevmapper, as the library is
located in /usr/lib, and cryptsetup needs to be invoked before /usr is
mounted. please either bring brack the static library, or move the
dynamic library to /lib.

unfortunately i just uploaded a new version of cryptsetup which failed
to build on all architectures for that reason. thus a prompt fix would
be much appreciated.

don't know if other packages are affected as well.

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#583387: closed by Bastian Blank wa...@debian.org (Re: Bug#583387: no longer shipping static libraries causes cryptsetup FTBFS)

[Jonas Meurer]

hey,

On 27/05/2010 Bastian Blank wrote:
 On Thu, May 27, 2010 at 04:00:59PM +0200, Jonas Meurer wrote:
  cryptsetup staticly links against libdevmapper,
 
 This is not allowed under normal circumstances. Does the security team
 know about?
 
  as the library is
  located in /usr/lib, and cryptsetup needs to be invoked before /usr is
  mounted. please either bring brack the static library, or move the
  dynamic library to /lib.
 
 Please show evidence for this behaviour. Both lvm2 and dmsetup uses this
 library and works fine without /usr available and all the versions I
 know have the lib in /lib.
 
 Closing as no bug.

sorry, you're right. cryptsetup doesn't even link staticly against
devmapper libraries, it only does so for libgcrypt and libgpg-error.
security team is aware of that.

but still the most recent update of libdevmapper broke cryptsetup build.
see the build logs at https://buildd.debian.org/pkg.cgi?pkg=cryptsetup:

make[3]: Entering directory 
`/build/buildd-cryptsetup_1.1.1-1-i386-X7Uy0C/cryptsetup-1.1.1/src'
gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../lib -DDATADIR=\/usr/share\ 
-DLOCALEDIR=\/usr/share/locale\ -DLIBDIR=\/usr/lib\ -DPREFIX=\/usr\ 
-DSYSCONFDIR=\/usr/etc\ -DVERSION=\1.1.1\ -D_GNU_SOURCE   -Wall -Wall 
-g -O2 -MT cryptsetup-cryptsetup.o -MD -MP -MF .deps/cryptsetup-cryptsetup.Tpo 
-c -o cryptsetup-cryptsetup.o `test -f 'cryptsetup.c' || echo './'`cryptsetup.c
mv -f .deps/cryptsetup-cryptsetup.Tpo .deps/cryptsetup-cryptsetup.Po
/bin/sh ../libtool --tag=CC   --mode=link gcc -Wall -Wall -g -O2 -all-static  
-o cryptsetup cryptsetup-cryptsetup.o ../lib/libcryptsetup.la -lgcrypt 
-lgpg-error -lselinux -lsepol  -lpopt  
libtool: link: gcc -Wall -Wall -g -O2 -static -o cryptsetup 
cryptsetup-cryptsetup.o  ../lib/.libs/libcryptsetup.a -luuid -L/lib -ldevmapper 
-lpthread /usr/lib/libgcrypt.a /usr/lib/libgpg-error.a -lselinux -lsepol 
/usr/lib/libpopt.a
/usr/bin/ld: cannot find -ldevmapper
collect2: ld returned 1 exit status
make[3]: *** [cryptsetup] Error 1
make[3]: Leaving directory 
`/build/buildd-cryptsetup_1.1.1-1-i386-X7Uy0C/cryptsetup-1.1.1/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory 
`/build/buildd-cryptsetup_1.1.1-1-i386-X7Uy0C/cryptsetup-1.1.1'
make[1]: *** [all] Error 2
make[1]: Leaving directory 
`/build/buildd-cryptsetup_1.1.1-1-i386-X7Uy0C/cryptsetup-1.1.1'
make: *** [build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

i can reproduce this bug with libdevmapper-dev 2:1.02.47-1.

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#583387: closed by Bastian Blank wa...@debian.org (Re: Bug#583387: no longer shipping static libraries causes cryptsetup FTBFS)

[Jonas Meurer]

hey,

On 27/05/2010 Bastian Blank wrote:
 On Thu, May 27, 2010 at 07:13:01PM +0200, Jonas Meurer wrote:
  but still the most recent update of libdevmapper broke cryptsetup build.
  see the build logs at https://buildd.debian.org/pkg.cgi?pkg=cryptsetup:
 
  make[3]: Entering directory 
  `/build/buildd-cryptsetup_1.1.1-1-i386-X7Uy0C/cryptsetup-1.1.1/src'
  gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../lib -DDATADIR=\/usr/share\ 
  -DLOCALEDIR=\/usr/share/locale\ -DLIBDIR=\/usr/lib\ 
  -DPREFIX=\/usr\ -DSYSCONFDIR=\/usr/etc\ -DVERSION=\1.1.1\ 
  -D_GNU_SOURCE   -Wall -Wall -g -O2 -MT cryptsetup-cryptsetup.o -MD -MP -MF 
  .deps/cryptsetup-cryptsetup.Tpo -c -o cryptsetup-cryptsetup.o `test -f 
  'cryptsetup.c' || echo './'`cryptsetup.c
  mv -f .deps/cryptsetup-cryptsetup.Tpo .deps/cryptsetup-cryptsetup.Po
  /bin/sh ../libtool --tag=CC   --mode=link gcc -Wall -Wall -g -O2 
  -all-static  -o cryptsetup cryptsetup-cryptsetup.o ../lib/libcryptsetup.la 
  -lgcrypt -lgpg-error -lselinux -lsepol  -lpopt  
  libtool: link: gcc -Wall -Wall -g -O2 -static -o cryptsetup 
  cryptsetup-cryptsetup.o  ../lib/.libs/libcryptsetup.a -luuid -L/lib 
  -ldevmapper -lpthread /usr/lib/libgcrypt.a /usr/lib/libgpg-error.a 
  -lselinux -lsepol /usr/lib/libpopt.a
  /usr/bin/ld: cannot find -ldevmapper
  collect2: ld returned 1 exit status
  make[3]: *** [cryptsetup] Error 1
  make[3]: Leaving directory 
  `/build/buildd-cryptsetup_1.1.1-1-i386-X7Uy0C/cryptsetup-1.1.1/src'
  make[2]: *** [all-recursive] Error 1
  make[2]: Leaving directory 
  `/build/buildd-cryptsetup_1.1.1-1-i386-X7Uy0C/cryptsetup-1.1.1'
  make[1]: *** [all] Error 2
  make[1]: Leaving directory 
  `/build/buildd-cryptsetup_1.1.1-1-i386-X7Uy0C/cryptsetup-1.1.1'
  make: *** [build-stamp] Error 2
  dpkg-buildpackage: error: debian/rules build gave error exit status 2
  
  i can reproduce this bug with libdevmapper-dev 2:1.02.47-1.
 
 This is not the same version then already in unstable. So you can't even
 show on which side it break. As you link with -static, it will only
 consider static libs.

yes, this is the most recent devmapper version in unstable. at least it
is the one available at packages.debian.org, on my local system, and
being used on the buildds:

https://buildd.debian.org/fetch.cgi?pkg=cryptsetup;ver=2%3A1.1.1-1;arch=i386;stamp=1274915533
 Selecting previously deselected package libdevmapper1.02.1.
 Unpacking libdevmapper1.02.1 (from 
 .../libdevmapper1.02.1_2%3a1.02.47-1_i386.deb) ...
 [...]
 Selecting previously deselected package libdevmapper-dev.
 Unpacking libdevmapper-dev (from .../libdevmapper-dev_2%3a1.02.47-1_i386.deb) 
 ...
 [...]
 Setting up libdevmapper1.02.1 (2:1.02.47-1) ...
 [...]
 Setting up libdevmapper-dev (2:1.02.47-1) ...

 However the question is: why did it build on your system for the initial
 upload. Out-of-date system?

yes, i missed to update my pbuilder environment before building
cryptsetup, thus it used old libdevmapper. from local build-log:

 Selecting previously deselected package libdevmapper-dev.
 Unpacking libdevmapper-dev (from 
 .../libdevmapper-dev_2%3a1.02.45-1_amd64.deb) ...
 [...]
 Setting up libdevmapper-dev (2:1.02.45-1) ...

i just rechecked, and the now up-to-date pbuilder environment fails to
build cryptsetup, while after downgrading libdevmapper1.02.1 and
libdevmapper-dev the packages build fine. so it's definitely connected
to the devmapper package upgrade.

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#576488: [pkg-cryptsetup-devel] Bug#576488: still present

[Jonas Meurer]

hey,

On 06/05/2010 Frederik Vanrenterghem wrote:
 Package: cryptsetup
 Version: 2:1.1.0-2.1
 
 I still get this error (evmc_activate is not available) using kernel
 2.6.32-4 and 2.6.32-5 on AMD64. I can't boot the system.
 
 2.6.32-3 boots fine.

please provide more information about your setup, the used versions,
etc. do you use evms? does evms have a initramfs hook which installes
the evms binary into the initramfs? what is the exact output of
'update-initramfs -u'?

and please attach initramfs.log after executing 'sh -x mkinitramfs -o
/tmp/initramfs.debug 2initramfs.log'

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#576488: [pkg-cryptsetup-devel] Bug#576488: cryptroot: boot script assumes to be run in initramfs

[Jonas Meurer]

hey maks,

On 05/04/2010 maximilian attems wrote:
 initramfs-tools 0.94 will break cryptsetup cryptroot boot script.
 The Ubuntu feature of pre-cached order got merged,
 will add a versioned breaks on cryptsetup
 
 their is a patch in Ubuntu cryptsetup for the situation,
 including it here.
 
 thanks for merging.

i'm away on holidays right now, without access to gpg key. unfortunately
and additionally i've  troubles with my mail server as well. two raid5
harddisks decided to break at once.

in short: i'll not be able to upload a fixed cryptsetup package within
the next week. thus it would be great if you could NMU cryptsetup with
the patch for this bug applied.

greetings,
 jonas



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

Bug#566136: Removing packages which depend from Zope2 ?

[Jonas Meurer]

hey Andreas,

On 25/01/2010 Andreas Tille wrote:
 I did not followed the discussion closely any more about the Zope 2
 issue but apt-cache has no hits for zope2 any more.  This lets me
 assume that zope2 is not supported in Debian any more and so we
 should probably drop packages depending from it.
 
 Please tell me whether my assumption about Zope 2 is true and I'll turn
 this bug into a ROM bug for ftpmaster.

i still hope to have zope2.12 in debian in time for squeeze.
unfortunately the build system is rather complex for zope2.12, thus i
didn't have time to package zope2.12 yet.

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#548570: minirok segfaults

[Jonas Meurer]

hey adeodato,

On 15/10/2009 Adeodato Simó wrote:
 + Jonas Meurer (Sun, 27 Sep 2009 12:30:28 +0200):
 
  Package: minirok
  Version: 2.0-1
  Severity: grave
  Justification: renders package unusable
 
  hello,
 
  minirok segfaults on my up-to-date debian/unstable system:
 
 Hello Jonas, this was caused by an incompatibility in PyQt 4.6. I
 believe I have fixed the problem. Before doing an upload, would you
 mind testing the packages at [1] (they are sort of 2.1~rc1)? Thanks!
 
   [1]: 
 http://chistera.yi.org/~adeodato/tmp/2009-10-15/minirok_2.1~r768-1_all.deb

indeed, that package fixes the segfault for me. thanks for your great
work!

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#548861: upgrade fails with E: Internal Error, Could not perform immediate configuration (2) on perl

[Jonas Meurer]

Package: perl
Version: 5.10.1-3
Severity: serious

hello,

perl upgrade fails on my up-to-date debian/unstable system:

# apt-get install libperl5.10 perl-base perl perl-doc perl-modules
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Suggested packages:
  groff
The following packages will be upgraded:
  libperl5.10 perl perl-base perl-doc perl-modules
5 upgraded, 0 newly installed, 0 to remove and 6 not upgraded.
Need to get 0B/16.2MB of archives.
After this operation, 532kB of additional disk space will be used.
E: Internal Error, Could not perform immediate configuration (2) on perl

greetings,
 jonas

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

Kernel: Linux 2.6.30-6-amd64-resivo (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages perl depends on:
ii  libc6  2.9-26GNU C Library: Shared libraries
ii  libdb4.7   4.7.25-8  Berkeley v4.7 Database Libraries [
ii  libgdbm3   1.8.3-6   GNU dbm database routines (runtime
ii  perl-base  5.10.0-25 minimal Perl system
ii  perl-modules   5.10.0-25 Core Perl modules
ii  zlib1g 1:1.2.3.3.dfsg-15 compression library - runtime

Versions of packages perl recommends:
ii  make  3.81-6 An utility for Directing compilati
ii  netbase   4.37   Basic TCP/IP networking system

Versions of packages perl suggests:
ii  libterm-readline-gnu-perl 1.19-2 Perl extension for the GNU Readlin
ii  perl-doc  5.10.0-25  Perl documentation

-- no debconf information


signature.asc
Description: Digital signature

Bug#548570: minirok segfaults

[Jonas Meurer]

Package: minirok
Version: 2.0-1
Severity: grave
Justification: renders package unusable

hello,

minirok segfaults on my up-to-date debian/unstable system:

$ minirok 
Traceback (most recent call last):
  File /usr/bin/minirok, line 9, in module
minirok.main.main()
  File /usr/share/minirok/minirok/main.py, line 73, in main
main_window = mw.MainWindow()
  File /usr/share/minirok/minirok/main_window.py, line 31, in __init__
self.right_side = right_side.RightSide(self.main_view, main_window=self)
  File /usr/share/minirok/minirok/right_side.py, line 31, in __init__
self.playlist_view.setModel(self.proxy)
  File /usr/share/minirok/minirok/playlist.py, line 1011, in setModel
self.header().setup_from_config()
  File /usr/share/minirok/minirok/playlist.py, line 1308, in setup_from_config
self.CONFIG_OPTION, QtCore.QStringList()))
TypeError: argument 2 to map() must support iteration
KCrash: Application 'minirok' crashing...
sock_file=/home/resivo/.kde/socket-resivo/kdeinit4__0

the 'KDE Crash Handler' lists the following 'Developer Information':

Application: Minirok (minirok), signal: Segmentation fault
[Current thread is 1 (Thread 0x7f9aa6b9a6f0 (LWP 10842))]

Thread 2 (Thread 0x7f9a8f020950 (LWP 10844)):
#0  0x7f9aa678fb89 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib/libpthread.so.0
#1  0x7f9aa39d2469 in QWaitCondition::wait(QMutex*, unsigned long) () from 
/usr/lib/libQtCore.so.4
#2  0x7f9aa0062ce5 in ?? () from 
/usr/lib/pymodules/python2.5/PyQt4/QtCore.so
#3  0x0048efc5 in PyEval_EvalFrameEx ()
#4  0x0049023c in PyEval_EvalCodeEx ()
#5  0x004d9652 in ?? ()
#6  0x004186a3 in PyObject_Call ()
#7  0x0041f3a4 in ?? ()
#8  0x004186a3 in PyObject_Call ()
#9  0x004893e2 in PyEval_CallObjectWithKeywords ()
#10 0x7f9aa03ae7e5 in ?? () from /usr/lib/pymodules/python2.5/sip.so
#11 0x7f9aa007005f in ?? () from 
/usr/lib/pymodules/python2.5/PyQt4/QtCore.so
#12 0x7f9aa00852f1 in ?? () from 
/usr/lib/pymodules/python2.5/PyQt4/QtCore.so
#13 0x7f9aa39d1475 in ?? () from /usr/lib/libQtCore.so.4
#14 0x7f9aa678bf9a in start_thread () from /lib/libpthread.so.0
#15 0x7f9aa5e7656d in clone () from /lib/libc.so.6
#16 0x in ?? ()

Thread 1 (Thread 0x7f9aa6b9a6f0 (LWP 10842)):
[KCrash Handler]
#5  0x7f9aa3fc7833 in QWidget::releaseShortcut(int) () from 
/usr/lib/libQtGui.so.4
#6  0x7f9aa4343c98 in ?? () from /usr/lib/libQtGui.so.4
#7  0x7f9aa4344762 in QLabel::~QLabel() () from /usr/lib/libQtGui.so.4
#8  0x7f9aa4d5dd04 in ?? () from /usr/lib/pymodules/python2.5/PyQt4/QtGui.so
#9  0x7f9aa3ac5861 in QObjectPrivate::deleteChildren() () from 
/usr/lib/libQtCore.so.4
#10 0x7f9aa3fd06a2 in QWidget::~QWidget() () from /usr/lib/libQtGui.so.4
#11 0x7f9aa4edf3d6 in ?? () from /usr/lib/pymodules/python2.5/PyQt4/QtGui.so
#12 0x7f9aa4e8c772 in ?? () from /usr/lib/pymodules/python2.5/PyQt4/QtGui.so
#13 0x7f9aa03acf79 in ?? () from /usr/lib/pymodules/python2.5/sip.so
#14 0x0045e0d5 in ?? ()
#15 0x00445b33 in ?? ()
#16 0x7f9aa03ab1ab in ?? () from /usr/lib/pymodules/python2.5/sip.so
#17 0x7f9aa03abac4 in ?? () from /usr/lib/pymodules/python2.5/sip.so
#18 0x7f9aa03acf81 in ?? () from /usr/lib/pymodules/python2.5/sip.so
#19 0x0045e0d5 in ?? ()
#20 0x7f9aa03ae9c2 in sip_api_common_dtor () from 
/usr/lib/pymodules/python2.5/sip.so
#21 0x7f9aa4edf3b9 in ?? () from /usr/lib/pymodules/python2.5/PyQt4/QtGui.so
#22 0x7f9aa3ac5861 in QObjectPrivate::deleteChildren() () from 
/usr/lib/libQtCore.so.4
#23 0x7f9aa3fd06a2 in QWidget::~QWidget() () from /usr/lib/libQtGui.so.4
#24 0x7f9aa439d210 in QSplitter::~QSplitter() () from /usr/lib/libQtGui.so.4
#25 0x7f9aa4c8e798 in ?? () from /usr/lib/pymodules/python2.5/PyQt4/QtGui.so
#26 0x7f9aa3ac5861 in QObjectPrivate::deleteChildren() () from 
/usr/lib/libQtCore.so.4
#27 0x7f9aa3fd06a2 in QWidget::~QWidget() () from /usr/lib/libQtGui.so.4
#28 0x7f9a9ea30eb5 in KMainWindow::~KMainWindow() () from 
/usr/lib/libkdeui.so.5
#29 0x7f9a9ade6c9d in sipKXmlGuiWindow::~sipKXmlGuiWindow() () from 
/usr/lib/pymodules/python2.5/PyKDE4/kdeui.so
#30 0x7f9a9adb534d in ?? () from 
/usr/lib/pymodules/python2.5/PyKDE4/kdeui.so
#31 0x7f9aa03acf79 in ?? () from /usr/lib/pymodules/python2.5/sip.so
#32 0x0045e0d5 in ?? ()
#33 0x0041f933 in ?? ()
#34 0x004387c2 in ?? ()
#35 0x00445b33 in ?? ()
#36 0x00445b33 in ?? ()
#37 0x0045e15c in ?? ()
#38 0x00444047 in ?? ()
#39 0x00445e4a in PyDict_SetItem ()
#40 0x00447e56 in _PyModule_Clear ()
#41 0x004a34c4 in PyImport_Cleanup ()
#42 0x004aeed6 in Py_Finalize ()
#43 0x00414037 in Py_Main ()
#44 0x7f9aa5dc85c6 in __libc_start_main () from /lib/libc.so.6
#45 0x004139d9 in _start ()

greetings,
 jonas

-- System Information:
Debian Release: 

Bug#544773: [pkg-cryptsetup-devel] Bug#544773: Update to cryptsetup 2:1.0.7-2 breaks booting

[Jonas Meurer]

hey,

On 04/09/2009 Paul Millar wrote:
 On Thursday 03 September 2009 19:43:28 Jonas Meurer wrote: 
  [...] please run the following command:
  
  # sh -x mkinitramfs -o /tmp/initramfs 2/tmp/initramfs.log
  
  and send /tmp/initramfs.log to the bugreport.
 
 Attached.
 
 Incidentally, I opened up the resulting initrd image (/tmp/initramfs) and 
 found that the conf/conf.d/cryptsetup file is still absent.  The problem is 
 at 
 least reproducible on this laptop.

thanks. please also send me the output of the following commands:

# ls -l /dev/mapper

# cat /etc/mtab

i guess that you discovered the same bug as #544487.

could you try downgrading to cryptsetup 2:1.0.7-1, regenerating the
initramfs and see whether the bug disappears? if it's related to device
files in /dev/mapper being links to /dev/dm-* then the bug should be
reproducible with old cryptsetup as well.

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#544773: [pkg-cryptsetup-devel] Bug#544773: Update to cryptsetup 2:1.0.7-2 breaks booting

[Jonas Meurer]

hey,

On 02/09/2009 Paul Millar wrote:
 After upgrading a few packages (listed below) I discovered my laptop was 
 unable to boot.  The laptop 
 uses a Luks partition with LVM (this was using a standard guided partitioning 
 option back when I was 
 installing Debian).  The boot fails at around the same time I would normally 
 be prompted for the 
 passphrase to unlock the Luks partition.
 
 One (or more) of the upgraded packages triggered a rebuild of the initrd.  
 Suspecting that this 
 might be the cause of the problem, I tried adjusting the boot process.  Using 
 grub's built-in 
 editor, I changed the initrd from the usual value to the backup copy (which 
 has the filename with 
 .bak appended).  When booting from the backup copy of the initrd the 
 computer booted without any 
 problem.
 
 I then took the two initrd images, unpacked them and compared their contents. 
  There was a number of 
 differences, but the most noticable change was that the file:
 
 conf/conf.d/cryptroot
 
 that was present in the backup initrd was missing in the new initrd.  This 
 file contained 
 cryptographic options for establishing the LVM ontop of the Luks partition.  
 I've copied the 
 contents here:
 
 target=sdb2_crypt,source=/dev/sda2,key=none,rootdev,lvm=vedrfolnir-root
 target=sdb2_crypt,source=/dev/sda2,key=none,lvm=vedrfolnir-swap_1
 
 Suspecting that the absence of this file was causing the problem, I copied 
 the missing 
 conf/conf.d/cryptroot file into the new initrd's contents and repacked the 
 initrd file.  Booting off 
 this modified version of new initrd was successful.
 
 Therefore, I conclude that the laptop was unable to boot due to the missing 
 conf/conf.d/cryptroot 
 file in the initrd.

it seems like the initramfs generation process is broken. unfortunately
i'm unable to reproduce the bug on several different setups. please run
the following command:

# sh -x mkinitramfs -o /tmp/initramfs 2/tmp/initramfs.log

and send /tmp/initramfs.log to the bugreport.

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#544773: [pkg-cryptsetup-devel] Bug#544773: Update to cryptsetup 2:1.0.7-2 breaks booting

[Jonas Meurer]

hey,

On 03/09/2009 Linus Lüssing wrote:
 Yes, I'm having the same problem here. I updated cryptsetup yeseterday to
 2:1.07-2 and now I can't boot my usual 2.6.30-1-amd64 anymore.
 My other kernels on this machine seem unaffected, just my usual
 kernel-image does not boot. So I can select/boot 2.6.30-1-686,
 2.6.29-2-amd64 or 2.6.29-2-686 with grub-pc for example.

please send /tmp/initramfs.log to the bugreport after running the
following command:

# sh -x mkinitramfs -o /tmp/initramfs 2.6.30-1-amd64 2/tmp/initramfs.log

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#544669: [pkg-cryptsetup-devel] Bug#544669: cryptsetup: /sbin/blkid is not in initramfs

[Jonas Meurer]

reassign 544669 util-linux
severity 544669 normal
tag 544669 +patch
thanks

hey,

On 02/09/2009 Mario 'BitKoenig' Holbe wrote:
 cryptsetup 1.0.7-2 recommends to replace vol_id and un_vol_id by blkid
 and un_blkid. Both of these scripts depend on /sbin/blkid.
 However, /sbin/blkid is not available in the initramfs image.

thanks for the bugreport. cryptroot doesn't support checkscripts, thus
check and precheck options are ignored for cryptroot devices anyway. i'm
downgrading severity to normal for that reason.

 Considering your changelog statement that udev will remove vol_id soon,
 I'm not sure whether this bug should really be fixed in cryptsetup
 itself or if /sbin/blkid should be included in the initramfs either by
 initramfs-tools or util-linux directly.

yes, you're correct. util-linux should copy blkid to the initramfs
directly. initramfs-tools will need to be migrated to blkid anyway.
currently it's using vol_id. so the propper fix for this is to ship
/usr/share/initramfs-tools/hooks/util-linux within util-linux. the
script should contain something like:

---snip---
#!/bin/sh -e

PREREQ=

prereqs()
{
echo $PREREQ
}

case $1 in
prereqs)
prereqs
exit 0
;;
esac

. /usr/share/initramfs-tools/hook-functions

copy_exec /sbin/blkid
---snap---

this mail downgrades the bug to normal, adds the 'patch' tag, and
reassigns it to the package 'util-linux'.

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#543667: [Python-modules-team] Bug#543667: The same

[Jonas Meurer]

hey,

On 27/08/2009 Nahuel ANGELINETTI wrote:
 I have the same problem today, and I do not find the new package, where
 can I find it? Or at least the source to build it myself?

i've uploaded a fixed package today (1.2.2-10). it should be available
on the mirrors tomorrow. until then you can find it at debian incoming:
http://incoming.debian.org/python-mysqldb_1.2.2-10_amd64.deb
http://incoming.debian.org/python-mysqldb_1.2.2-10_i386.deb

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#542928: [pkg-cryptsetup-devel] Bug#542928: Bug#542928: cryptsetup fail with kernel 2.6.30-6

[Jonas Meurer]

hey,

On 26/08/2009 Guillaume JAOUEN wrote:
 You'll find in this mail all the output log.
 
 I add also dmesg output dpkg get-selections, lshw and lspci output.
 
 I hope it may help you understand what's happening :
 - dpkg-gzt-selections.txt was made under 2.6.29-2 kernel boot.
 - cat-proc-crypto.log was made under 2.6.30-1 kernel boot.
 - cat-proc-crypto-2.6.29-2.log was made under 2.6.29-2 kernel boot.
 - cat-proc-devices.log was made under 2.6.30-1 kernel boot.
 - cat-proc-devices-2.6.29-2.log was made under 2.6.29-2 kernel boot.
 - cat-proc-modules.log was made under 2.6.30-1 kernel boot.
 - cat-proc-modules-2.6.29-2.log was made under 2.6.29-2 kernel boot.
 - config-2.6.29-2-amd64 and config-2.6.30-1-amd64 were generated into /boot
 - dmesg.log was made under 2.6.30-1 kernel boot.
 - dmesg.2.6.29-2.log was made under 2.6.29-2 kernel boot.
 - lshw-2.6.29-2.log was made under 2.6.29-2 kernel boot.
 - lspci-2.6.29-2.log was made under 2.6.29-2 kernel boot.
 - ps-aux.log was made under 2.6.30-1 kernel boot.
 - uname.log was made under 2.6.30-1 kernel boot.
 - cat-etc-crypttab-2.6.29-2.log was made under 2.6.29-2 kernel boot.
 - cat-etc-fstab-2.6.29-2.log was made under 2.6.29-2 kernel boot.
 
 With these elements I hope I give you the maximum details about my
 hardware and software configuration.

ok, i just tried to reproduce the bug with similar setup (lvm over luks)
and a selfcompiled kernel using your config-2.6.30-1-amd64, but i
failed. the system still boots as expected.

 My laptop doesn't use xen hypervisor even if the kernel message
 display this information.

some of the xen packages you've installed don't exist in the archive
any longer, xen 3.2 has been replaced by xen 3.4 in the meanwhile.

 I agree with you when you're saying that the lvm setup is broken
 that's what my system complain about since the upgrade of the kernel
 and it's link to the fact that as the device /dev/sda5 isn't
 decrypted, my lvm setup wasn't available on boot process.

in another mail you wrote:

 Output during boot :
 debian kernel 2.6.30-1-amd64
 ...
 failure : failed to assemble all array volume group debian not found.
 skipping volume group debian.
 unable to find LVM volume debian/root
 unable to find LVM volume debian/swap_1
 done.
 begin : waiting for root file system... done
 gave up waiting for root device. common problems :
 - boot args cat /proc/cmdline
 - check rootdelay =(did the system wait long enough?)
 - check root =(did the system wait for the right device?)
 - missing modules ( cat /proc/modules)
 ALERT! /dev/mapper/debian-root does not exist
 dropping to a shell.
 busybox V.1.13.3 (debian 1:1.13.3-1) built-in shell (ash)
 Enter 'help' for a list of built-in commands.
 /bin/sh: can't access tty: job control turned off.
 (initramfs)

could you verify that this is the exact output you get at trying to boot
the broken linux kernel 2.6.30-1-amd64?
this is the output i get at booting with a linux kernel 2.6.30-1-amd64
built with your kernel config:
 Volume group debian not found
 Skipping volume group debian
Unable to find LVM volume debian/root
 Volume group debian not found
 Skipping volume group debian
Unable to find LVM volume debian/swap_1
Unlocking the disk /dev/hda2 (hda2_crypt)
Enter passphrase:

the LVM errors are harmless. they only appear for the reason that lvm
is started both before and after cryptroot. that's to support both lvm
over luks and luks over lvm setups.

if the boot output above is what you get, then a broken initramfs file
which misses the cryptroot initramfs script might be the reason.
please attach the output of the following commands as well (from a
working system, i.e. with kernel 2.6.29-1-amd64):

ls -al /boot/
[ -f /boot/grub/menu.lst ]  cat /boot/grub/menu.lst
[ -f /boot/grub/grub.conf ]  cat /boot/grub/grub.conf

and attach /tmp/initramfs-2.6.30-1-amd64.log after executing

sh -x mkinitramfs --supported-target-version=2.6.30-1-amd64 \
-o /tmp/initramfs-2.6.30-1-amd64 2/tmp/initramfs-log

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#542928: [pkg-cryptsetup-devel] Bug#542928: Bug#542928: cryptsetup fail with kernel 2.6.30-6

[Jonas Meurer]

hey,

On 27/08/2009 Guillaume JAOUEN wrote:
 I start again the laptop with kernel 2.6.30-1 amd64 and write
 carefully the output during the boot :
 
 ...
 Begin : Assembling all MD arrays... mdadm : No arrays found in
 config file or automatically
 Failure : failed to assemble all arrays.
 done.
Volume group debian not found
 Skipping volume group debian
 Unable to find LVM volume /debian/root
Volume group debian not found
 Skipping volume group debian
 Unable to find LVM volume /debian/swap_1
 done.

up to here, everything seems fine: mdadm is started but no software raid
configured, then lvm is started but no volume group available yet.

 Begin: Waiting for root file system... done
 Gave up waiting for root device.

that one indicates that the root device is not available to cryptroot.
for some reason, the encrypted device (/dev/sda5) is not available.
either missing hardware driver or wrong device might be reasons.

 Common problems:
 - Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Check root= (did the system wait for the right device ?)
 - Missing modules (cat /proc/modules;ls /dev)
 ALERT! /dev/mapper/debian-root does not exist. Dropping to a shell !
 BusyBox v1.13.3 (Debian 1:1.13.3-1) built-in shell (ash).
 Enter 'help' for a list of built-in commands.
 /bin/sh : can't access tty : job control turned off
 (initramfs)

in the initramfs emergency shell, please give output of the following
commands:

cat /conf/conf.d/cryproot

ls -al /dev/sda5

and if the device file exists, try unlocking it manually:

cryptsetup luksOpen /dev/sda5 sda5_crypt
lvm vgchange -a y
ls -al /dev/mapper/debian-root

if the device doesn't exist, then please give output of 'ls -al /dev'
from initramfs as well.

 You'll find the output of this command in attachement :
 dell-xps:/boot/grub# sh -x mkinitramfs
 --supported-target-version=2.6.30-1-amd64 \
  -o /tmp/initramfs-2.6.30-1-amd64 2/tmp/initramfs-log
 dell-xps:/boot/grub#

sorry, the command was wrong. please use the following instead:

sh -x mkinitramfs -o /tmp/initramfs 2.6.30-1-amd64 2/tmp/initramfs.log

and attach /tmp/initramfs.log to the mail.

also, please update your initramfs, try to reboot with the broken
kernel afterwards and seee whether that helps:

mv /boot/initramfs-2.6.30-1-amd64 /boot/initramfs-2.6.30-1-amd64.orig
update-initramfs -c -k 2.6.30-1-amd64

sorry for asking that many questions, but i simply don't have a straight
idea what the problem on your system might be. apparently the same
kernel and system setup works for me.

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#542928: [pkg-cryptsetup-devel] Bug#542928: Bug#542928: cryptsetup fail with kernel 2.6.30-6

[Jonas Meurer]

hey again,

On 25/08/2009 Guillaume JAOUEN wrote:
 I use a standard sid install with only nvidia proprietary driver :

thanks for the information. i run several debian/sid installations with
linux-image-2.6.30-1-amd64 (2.6.30-6) without any issues, and so far I
was unable to reproduce the bug you reported. let's see ...

 This kernel also runs on a Xen hypervisor.  It supports only unpriviledged
 (domU) operation.

so the system on which you discovered the bug runs as domU, right?

 Output during boot :
 debian kernel 2.6.30-1-amd64
 ...
 failure : failed to assemble all array
 volume group debian not found.
 skipping volume group debian.
 unable to find LVM volume debian/root
 volume group debian not found.
 skipping volume group debian.
 unable to find LVM volume debian/swap_1
 done.
 begin : waiting for root file system... done
 gave up waiting for root device. common problems :
 - boot args cat /proc/cmdline
 - check rootdelay =(did the system wait long enough?)
 - check root =(did the system wait for the right device?)
 - missing modules ( cat /proc/modules)
 ALERT! /dev/mapper/debian-root does not exist
 dropping to a shell.
 busybox V.1.13.3 (debian 1:1.13.3-1) built-in shell (ash)
 Enter 'help' for a list of built-in commands.
 /bin/sh: can't access tty: job control turned off.
 (initramfs)

do you use lvm? seems like the lvm setup is broken. in case that your
root device is on lvm (the default for guided encrypted partitioning
in debian-installer), then that might be the real issue here.

 output of cat /proc /cmdline :
 (initramfs) root=/dev/mapper/debian-root ro

 output of mount /dev/sda1 /boot/ :
 mount: mounting /dev/sda1 on /boot/ failed no such file or directory.
 
 output of ls / :
 bin
 boot ( I had to create it with mkdir)

ok, and is it possible to mount /dev/sda1 after creating /boot?

i.e. 'mkdir /boot  mount -t ext3 /dev/sda1 /boot'

 output of ls /dev/sd* :
 sda
 sda1
 sda2
 sda5

from the initramfs, please give the output of
'for dev in /dev/sda[125]; do echo $dev:; fstype $dev; done'

 I can't mount any file system, they are in ext3 format.

what is the exact error message if you try to mount them?

on your system (booted with a working kernel), please give the output of
/etc/fstab and /etc/crypttab.

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#542928: [pkg-cryptsetup-devel] Bug#542928: cryptsetup fail with kernel 2.6.30-6

[Jonas Meurer]

hello,

On 22/08/2009 Guillaume JAOUEN wrote:
 Since upgrade of the kernel to 2.6.30-6, my laptop fail to start and
 doesn't ask for the lucks passphrase so my LVM setup can't start and
 the system lost debian-root and debian-swap filesystem...
 
 Rebooting with 2.6.29 old kernel start properly.

thanks for your bugreport. in order to detect the problem it would be
very useful if you could provide further information:

- do you use a selfcompiled kernel, or did you install the default
  debian kernel (in package linux-image-2.6.30-1-amd64)?

- if you use a selfcompiled kernel, could you attach the .config of both
  the working 2.6.29 kernel and the broken 2.6.30 kernel?

- when you boot the broken 2.6.30 kernel, what exactly happens? do you
  get some message like 'root filesystem not found'? do you see an
  emergency shell of the initramfs?

- from the initramfs shell, please give the output of 'cat /proc/crypto'
  and 'cat /proc/modules'.
  you can do that by saving the output into a logfile on the boot fs.
  i.e. if your boot partition is /dev/sda1, do the following:
  mount /dev/sda1 /boot
  cat /proc/crypto  /boot/proc_crypto_log
  cat /proc/modules  /boot/proc_modules_log

  afterwards reboot with the working 2.6.29 kernel and attach both
  logfiles from /boot to your reply mail.

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#540157: Bug#540158: doesnt use invoke-rc.d

[Jonas Meurer]

hey,

On 09/08/2009 Jonas Meurer wrote:
 ok, after discussing this with kobold, i finally implemented the
 following changes:
 
 - zope-debhelper uses invoke-rc.d in maintainer scripts
 - dzhandle uses invoke-rc.d for DZRestartPendingInstances.run()
 - zope2.1[01] init scripts support [ZEOSERVER|INSTANCE]=... as second
   argument
 
 - zope-common breaks zope2.[789] and old zope2.1[01] packages
 - zope-debhelper adds depends on recent zope-common to packages that use
   dh_installzope*
 - zope2.1[01] build-depend on recend zope-debhelper and pre-depend on
   recent zope-common
 
 please test the packages (especially install|upgrade|remove|purge) with
 as many different setups as possible (no|one|many zope instances,
 zope2.1[01]-sandbox installed|upgraded|...).
 
 you can find all packages (amd64 and i386) at
 http://people.debian.org/~mejo/zope/
 
 i'll upload zope-common and zope-debhelper to unstable within the next
 days if nobody objects. once both are in unstable for one or two days,
 i'll upload zope2.10 and zope2.11 as well.

as nobody except kobold commented on this yet, i just went ahead and
uploaded zope2.10 and zope2.11 to unstable. zope-common/zope-debhelper
were already uploaded two days ago.

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#540159: Bug#540158: doesnt use invoke-rc.d

[Jonas Meurer]

hello again,

On 08/08/2009 Jonas Meurer wrote:
 On 06/08/2009 Holger Levsen wrote:
  during a test with piuparts I noticed your package starts processes where 
  it 
  shouldnt. This is very probably due to not using invoke-rc.d as mandated by 
  policy 9.3.3.2. This is seriously disturbing! ;-)
  
  See http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3 
  and /usr/share/doc/sysv-rc/README.invoke-rc.d.gz as well 
  as /usr/share/doc/sysv-rc/README.policy-rc.d.gz
  
  From the attached log (scroll to the bottom...):
  
Setting up zope2.11-sandbox (2.11.3-1) ...
. 
daemon process started, pid=17342
Processing triggers for python-support ...
  [...]
  0m41.7s ERROR: FAIL: Processes are running inside chroot:
 
 i suggest to fix these bugs the following way: patch the initscripts to
 support INSTANCE=instance or ZEOSERVER=zeoserver as second
 argument ($2) and start the particular given server/instance.
 
 then fix all zope-debhelper scripts to use invoke-rc.d with appropriate
 arguments instead of using dzhandle zeoctl|zopectl directly.
 
 i already commited the relevant changes to zope-debhelper, zope2.11 and
 zope2.10 to the svn repository.
 
 only package that is left is zope3. i left that one open to others as i
 don't know nothing about zope3.
 
 any objections? if not, i would suggest to upload zope-debhelper
 within the next days, wait until it reached unstable and then upload
 zope3/zope2.11/zope2.10 with build-depends on new zope-debhelper.
 
 only drawback is, that building old zope3/2.11/2.10/... packages with
 new zope-debhelper will break. do you think that adding a Breaks: header
 to zope-debhelper for old zope packages would be necessary?

ok, after discussing this with kobold, i finally implemented the
following changes:

- zope-debhelper uses invoke-rc.d in maintainer scripts
- dzhandle uses invoke-rc.d for DZRestartPendingInstances.run()
- zope2.1[01] init scripts support [ZEOSERVER|INSTANCE]=... as second
  argument

- zope-common breaks zope2.[789] and old zope2.1[01] packages
- zope-debhelper adds depends on recent zope-common to packages that use
  dh_installzope*
- zope2.1[01] build-depend on recend zope-debhelper and pre-depend on
  recent zope-common

please test the packages (especially install|upgrade|remove|purge) with
as many different setups as possible (no|one|many zope instances,
zope2.1[01]-sandbox installed|upgraded|...).

you can find all packages (amd64 and i386) at
http://people.debian.org/~mejo/zope/

i'll upload zope-common and zope-debhelper to unstable within the next
days if nobody objects. once both are in unstable for one or two days,
i'll upload zope2.10 and zope2.11 as well.

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#540157: Bug#540158: doesnt use invoke-rc.d

[Jonas Meurer]

hey,

On 06/08/2009 Holger Levsen wrote:
 during a test with piuparts I noticed your package starts processes where it 
 shouldnt. This is very probably due to not using invoke-rc.d as mandated by 
 policy 9.3.3.2. This is seriously disturbing! ;-)
 
 See http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3 
 and /usr/share/doc/sysv-rc/README.invoke-rc.d.gz as well 
 as /usr/share/doc/sysv-rc/README.policy-rc.d.gz
 
 From the attached log (scroll to the bottom...):
 
   Setting up zope2.11-sandbox (2.11.3-1) ...
   . 
   daemon process started, pid=17342
   Processing triggers for python-support ...
 [...]
 0m41.7s ERROR: FAIL: Processes are running inside chroot:

i suggest to fix these bugs the following way: patch the initscripts to
support INSTANCE=instance or ZEOSERVER=zeoserver as second
argument ($2) and start the particular given server/instance.

then fix all zope-debhelper scripts to use invoke-rc.d with appropriate
arguments instead of using dzhandle zeoctl|zopectl directly.

i already commited the relevant changes to zope-debhelper, zope2.11 and
zope2.10 to the svn repository.

only package that is left is zope3. i left that one open to others as i
don't know nothing about zope3.

any objections? if not, i would suggest to upload zope-debhelper
within the next days, wait until it reached unstable and then upload
zope3/zope2.11/zope2.10 with build-depends on new zope-debhelper.

only drawback is, that building old zope3/2.11/2.10/... packages with
new zope-debhelper will break. do you think that adding a Breaks: header
to zope-debhelper for old zope packages would be necessary?

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#534013: zope2.10: FTBFS: /bin/sh: line 0: cd: z: No such file or directory

[Jonas Meurer]

Hello again,

On 03/07/2009 Lucas Nussbaum wrote:
 On 03/07/09 at 04:17 +0200, Jonas Meurer wrote:
  On 02/07/2009 Lucas Nussbaum wrote:
if you take a look at debian/rules, there are several
more commands in unpack-stamp than just the 'tar xfz'. According to your
logfile, the build-arch-stamp and patch-stamp targets are executed in
the middle of the unpack-stamp target.

I'm unable to reproduce that bug in a clean amd64 debian/unstable
pbuilder chroot.

here's the relevant parts of debian/rules:
[...]
   
   Actually, the relevant part is before that:
   ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
   NUMJOBS = $(patsubst parallel=%,%,$(filter 
   parallel=%,$(DEB_BUILD_OPTIONS)))
   MAKEFLAGS += -j$(NUMJOBS)
   endif
   
   You seem to be missing some dependencies between your rules.
  
  ah, thanks for the hint. I hope to have fixed that now, could you give
  the packages at http://people.debian.org/~mejo/zope2.11/ give a try?
 
 Bah, if you just removed the lines about that, I would suggest uploading
 it, since it's unlikely to break ;)

what I actually did, is trying to fix the dependencies of different
targets.

only issue that I don't know what to do about, is that the dpatch
patch(-stamp) target would need to depend on the unpack(-stamp)
target. but I don't know how to define that dependency, as the dpatch
patch(-stamp) target isn't defined in debian/rules directly but rather
in the dpatch include file /usr/share/dpatch/dpatch.make.

greetings,
 jonas



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

Bug#534013: zope2.10: FTBFS: /bin/sh: line 0: cd: z: No such file or directory

[Jonas Meurer]

Hello Lucas,

On 21/06/2009 Lucas Nussbaum wrote:
 Package: zope2.10
 Version: 2.10.8-1
 Severity: serious
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20090620 qa-ftbfs
 Justification: FTBFS on amd64
 
 Hi,
 
 During a rebuild of all packages in sid, your package failed to build on
 amd64.
 
 Relevant part:
  tar xfz Zope-2.10.8-final.tgz
  test -d debian/patched || install -d debian/patched
  cd z  CFLAGS=-Wall -g -O2 ./configure \
  
  --prefix=/build/user-zope2.10_2.10.8-1-amd64-315F5a/zope2.10-2.10.8/debian/zope2.10/usr/lib/zope2.10
   \
  --with-python=/usr/bin/python2.4
  /bin/sh: line 0: cd: z: No such file or directory
  make: *** [build-arch-stamp] Error 1
 
 About the archive rebuild: The rebuild was done on about 50 AMD64 nodes
 of the Grid'5000 platform, using a clean chroot.  Internet was not
 accessible from the build systems.

could you provide the exact command that your archive rebuild uses to
build a package? if you take a look at debian/rules, there are several
more commands in unpack-stamp than just the 'tar xfz'. According to your
logfile, the build-arch-stamp and patch-stamp targets are executed in
the middle of the unpack-stamp target.

I'm unable to reproduce that bug in a clean amd64 debian/unstable
pbuilder chroot.

here's the relevant parts of debian/rules:

 ZOPE  := zope$(ZVER)
 PACKAGE   := zope$(ZVER)
 DEBIAN:= $(shell pwd)/debian/$(PACKAGE)
 
 [...]
 unpack: unpack-stamp
 unpack-stamp:
   tar xfz $(ZBASE).tgz
   mv $(ZBASE) z
   touch unpack-stamp
 
 [...]
 build: build-arch build-indep
 
 build-arch: unpack-stamp patch-stamp build-arch-stamp
 build-arch-stamp:
 cd z  CFLAGS=$(CFLAGS) ./configure \
 --prefix=$(DEBIAN)/usr/lib/$(ZOPE) \
 --with-python=$(PYTHONBIN)
 cd z  make
 touch build-arch-stamp
 

according to your logfile, the build system ran target build-arch-stamp
just in between of 'tar xfz $(ZBASE).tgz' and 'mv $(BASE) z':

 [...]
 dpkg-source: info: building zope2.10 in zope2.10_2.10.8-1.dsc
  debian/rules build
 tar xfz Zope-2.10.8-final.tgz
 test -d debian/patched || install -d debian/patched
 cd z  CFLAGS=-Wall -g -O2 ./configure \
   
 --prefix=/build/user-zope2.10_2.10.8-1-amd64-315F5a/zope2.10-2.10.8/debian/zope2.10/usr/lib/zope2.10
  \
   --with-python=/usr/bin/python2.4
 /bin/sh: line 0: cd: z: No such file or directory
 make: *** [build-arch-stamp] Error 1
 make: *** Waiting for unfinished jobs
 dpatch  apply-all  
 applying patch deb-zopeconf to ./ ... failed.
 make: *** [patch-stamp] Error 1
 mv Zope-2.10.8-final z
 touch unpack-stamp
 dpkg-buildpackage: error: debian/rules build gave error exit status 2
 [...]


the same applies to your bugreport #533975 against zope2.11.

greetings,
 jonas


signature.asc
Description: Digital signature

Bug#534013: zope2.10: FTBFS: /bin/sh: line 0: cd: z: No such file or directory

[Jonas Meurer]

On 02/07/2009 Lucas Nussbaum wrote:
  if you take a look at debian/rules, there are several
  more commands in unpack-stamp than just the 'tar xfz'. According to your
  logfile, the build-arch-stamp and patch-stamp targets are executed in
  the middle of the unpack-stamp target.
  
  I'm unable to reproduce that bug in a clean amd64 debian/unstable
  pbuilder chroot.
  
  here's the relevant parts of debian/rules:
  [...]
 
 Actually, the relevant part is before that:
 ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
 NUMJOBS = $(patsubst parallel=%,%,$(filter 
 parallel=%,$(DEB_BUILD_OPTIONS)))
 MAKEFLAGS += -j$(NUMJOBS)
 endif
 
 You seem to be missing some dependencies between your rules.

ah, thanks for the hint. I hope to have fixed that now, could you give
the packages at http://people.debian.org/~mejo/zope2.11/ give a try?

greetings,
 jonas



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